Нет изображения на некоторых стримах
- Thread starter Maksym
- Start date
1. Подскажите, если я поменяю ${com.flashphoner.fms.AppHome} в файле log4j.properties на путь к нужной мне директории, то надо ли будет перегружать WCS или все же на горячую все сработает?
2. Для полного логирования стои ли добавить настройку(что бы выслать вам)
2. Для полного логирования стои ли добавить настройку(что бы выслать вам)
Code:
log4j.logger.WSServerHandler=trace, wsAppender
log4j.logger.WSClient=debug, wsAppender
log4j.appender.wsAppender=org.apache.log4j.DailyRollingFileAppender
log4j.appender.wsAppender.DatePattern='.'yyyy-MM-dd-HH
log4j.appender.wsAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.wsAppender.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p %20.20c{1} - %t %m%n
log4j.appender.wsAppender.File=${com.flashphoner.fms.AppHome}/logs/server_logs/websocket.logПолучилось найти стрим и собрать доп инфу, помимо клиентских логов.
Сейчас все запакую и структурирую, а так же скину свои мысли на основе данных от рест'a.
Так что сегодня/завтра будет что изучать. Довольно интересная инфа получилась, если верить ресту
Update: отправил все на почту
Сейчас все запакую и структурирую, а так же скину свои мысли на основе данных от рест'a.
Так что сегодня/завтра будет что изучать. Довольно интересная инфа получилась, если верить ресту
Update: отправил все на почту
Last edited:
Добрый день.
Мы хотели бы получить отчет в следующем виде:
1. Проблема воспроизвелась на одном сервере (Origin)
2. Имя потока: 12345
3. Время на сервере 12:25:51
4. При попытке воспроизвести поток с IP адреса xxx.xxx.xxx.xxx не было картинки, был статус PLAYING
5. Дебаговые логи доступны для скачивания.
На текущий момент вы не указали на конкретный стрим у которого проблемы с воспроизведением на одном конкретном Origin сервере.
Соответственно мы не можем на этот стрим выйти и посмотреть по логам что с ним произошло.
REST не даст полезной информации.
Т.е. возвращаемся снова к вопросу.
Убираем Edge серверы из схемы. Воспроизводится ли проблема только с Origin, если играть стрим с него напрямую в браузере? Если да, то с каким стримом? Где клиентские дебаговые логи этого стрима.
Если удобно можете не собирать логи, а дать доступ к серверу по SSH с указанием файла логово или времени, по которому искать.
Мы хотели бы получить отчет в следующем виде:
1. Проблема воспроизвелась на одном сервере (Origin)
2. Имя потока: 12345
3. Время на сервере 12:25:51
4. При попытке воспроизвести поток с IP адреса xxx.xxx.xxx.xxx не было картинки, был статус PLAYING
5. Дебаговые логи доступны для скачивания.
На текущий момент вы не указали на конкретный стрим у которого проблемы с воспроизведением на одном конкретном Origin сервере.
Соответственно мы не можем на этот стрим выйти и посмотреть по логам что с ним произошло.
REST не даст полезной информации.
Т.е. возвращаемся снова к вопросу.
Убираем Edge серверы из схемы. Воспроизводится ли проблема только с Origin, если играть стрим с него напрямую в браузере? Если да, то с каким стримом? Где клиентские дебаговые логи этого стрима.
Если удобно можете не собирать логи, а дать доступ к серверу по SSH с указанием файла логово или времени, по которому искать.
ОХ. И чего же было ждать 4 дня(пусть даже 2 дня выходных)
Писал же:
1) На стейдже не воспроизводиться
2) На проде ВООБЩЕ НЕ РЕАЛЬНО УБРАТЬ ЭДЖЫ, так как это прод.
3) Сейчас буду по памяти воспроизводить название стримов Естественно IP только серверов смогу дать. Клиентов не могу, так как не знаю. Траблы на продакшине
Писал же:
1) На стейдже не воспроизводиться
2) На проде ВООБЩЕ НЕ РЕАЛЬНО УБРАТЬ ЭДЖЫ, так как это прод.
3) Сейчас буду по памяти воспроизводить название стримов Естественно IP только серверов смогу дать. Клиентов не могу, так как не знаю. Траблы на продакшине
Edge-серверы убирать не нужно. Нужно проиграть стрим вручную напрямую с Origin и проверить играет он или нет.
Если не играет - это наш кандидат, логи которого нам требуются.
IP нужен ваш, т.к. если вы проверили стрим и он не играет, IP появится в логах и по нему будет легче отыскать эту попытку воспроизведения.
Если не играет - это наш кандидат, логи которого нам требуются.
IP нужен ваш, т.к. если вы проверили стрим и он не играет, IP появится в логах и по нему будет легче отыскать эту попытку воспроизведения.
ОК. Скину.
Пока скажу так:
1) Не играл ни с ориджина ни с эджа. Сейчас гляну по письмам и если вспомню что и как делал и это подойдет - отпишусь в формате- который Вы написали выше
Update:
придется опять ждать стрима, который лагает, так как я не помню, смотрел ли с ориджина проблемный стрим(имя которого я все же указывал, правда и без временной метки на сервере). Но по памяти скажу так - все стримы, которые лагают - не воспроизводятся ни на ориджине ни на эдже
Пока скажу так:
1) Не играл ни с ориджина ни с эджа. Сейчас гляну по письмам и если вспомню что и как делал и это подойдет - отпишусь в формате- который Вы написали выше
Update:
придется опять ждать стрима, который лагает, так как я не помню, смотрел ли с ориджина проблемный стрим(имя которого я все же указывал, правда и без временной метки на сервере). Но по памяти скажу так - все стримы, которые лагают - не воспроизводятся ни на ориджине ни на эдже
Last edited:
Большое спасибо за проделанную работу и предоставленную информацию. Мы проанализировали дебаг-логи. Похоже, что проблема возникает на этапе публикации, причем на стороне публикующего приложения.
Во-первых, на проблемном стриме видеопакеты приходят значительно реже, чем аудио, а начиная с определенного момента, перестают приходить вообще.
Во-вторых, метка времени для синхронизации в аудиопакетах проставляется, а в видеопакетах, когда они приходят, всегда равна -1.
Если дорожки в стриме не удается синхронизировать или одна из них отсутствует, а клиент ждет и аудио, и видео, стрим у клиента воспроизводиться не будет.
Кроме того, публикующее приложение представляется серверу как браузер: iOS 11.4.0 browser: Boink/2.4.3. Можно ли уточнить, что это за браузер и в чем причины использования именно такого экзотичного решения, которое даже Гугл путает с платформой для распределенных вычислений?
Во-первых, на проблемном стриме видеопакеты приходят значительно реже, чем аудио, а начиная с определенного момента, перестают приходить вообще.
Во-вторых, метка времени для синхронизации в аудиопакетах проставляется, а в видеопакетах, когда они приходят, всегда равна -1.
Если дорожки в стриме не удается синхронизировать или одна из них отсутствует, а клиент ждет и аудио, и видео, стрим у клиента воспроизводиться не будет.
Кроме того, публикующее приложение представляется серверу как браузер: iOS 11.4.0 browser: Boink/2.4.3. Можно ли уточнить, что это за браузер и в чем причины использования именно такого экзотичного решения, которое даже Гугл путает с платформой для распределенных вычислений?
Хотел уточнить, по нашему последнему общению:
Сейчас произошла такая же ситуация, но есть небольшое отличие. Заключается оно в том, что при публикации видео, был выставлен флаг "record": true
И видео записалось нормально. Видео и аудио синхронны.
Подскажите, как такое может быть, что WCS нормально записывает на ориджине этот стрим, но при этом не отдает его для просмотра с этого же ориджина через админку
Сейчас произошла такая же ситуация, но есть небольшое отличие. Заключается оно в том, что при публикации видео, был выставлен флаг "record": true
И видео записалось нормально. Видео и аудио синхронны.
Подскажите, как такое может быть, что WCS нормально записывает на ориджине этот стрим, но при этом не отдает его для просмотра с этого же ориджина через админку
Запись и воспроизведение потока - разные операции. При записи, условно говоря, достаточно сложить пакеты, получаемые от публикующей стороны, в файл, а при воспроизведении эти пакеты необходимо дополнительно обработать.
Если у Вас есть дебаговые логи для этой ситуации, пришлите их, пожалуйста. Если нет - мы в данный момент работаем над тем, чтобы включать отладку для определенных клиентов "на лету", это позволит собирать логи для проблемных стримов сразу, как только проблемы замечены. Как только выведем такую возможность в продакшн, мы сообщим.