Черный экран на iOS (трансляция с камеры)

[alexosh]

Добрый день.

Проблема на iOS клиентах. Трансляция с веб-камеры, на сервере дефолтные настройки. Используется кастомизированный embed player, в mediaProviders указано WebRTC,MSE (или пробовали наоборот), transport: TCP. Стрим подключается по и показывается нормально. Видео без звука (он отключен, т.к. не нужен). Через несколько минут (5-10,15) - черный экран, при этом плеер не меняет состояния последнее событие PLAYING.

Думали может это только каналом что-то на мобильном LTE, но на wifi тоже самое происходит. Подскажите, какие шаги предпринять, чтобы выяснить в чем причина и решить?

И может у плеера все же есть еще какие-то события чтобы он мог оповестить что что-то не так? Наверняка он должен тоже "почувствовать" черный экран. Хотя мы добавляли `.on(CONNECTION_QUALITY.UPDATE,...)` он там ничего не стреляет. Черный экран и последнее событие PLAYING.

 

[Max]

Добрый день,

Уточните, пожалуйста, как именно публикуется поток (клиент), и есть ли проблема с воспроизведением не на iOS. Возможно, видео с камеры перестает отправляться.

 

[alexosh]

С камеры публикуется RTSP. Нет, на других клиента все отлично идет в этот же момент. Чисто проблема iOs, на Android таких вещей не наблюдается, все работает в этот же момент.

 

[Max]

К сожалению, проблема не воспроизводится на нашем demo сервере. При публикации RTMP потока из ffmpeg

ffmpeg -stream_loop -1 -y -re -rtbufsize 1k -i /root/bunny360p.mp4 -an -f flv -preset ultrafast -vcodec h264 -g 50 -strict -2 rtmp://demo.flashphoner.com:1935/live/test

и проигрывании в примере Embed Player в Safari на iOS 14.6 (iPhone 7) в течение 30 минут поток продолжает играть.
Попробуйте воспроизвести проблему на нашем demo сервере. Уточните параметры публикации потока.
Если проблема не воспроизводится на нашем демо сервере, попробуйте воспроизвести ее на своем сервере с примером Embed Player без модификации, из коробки, или в примере Media Devices, он покажет статистику WebRTC, количество потерянных пакетов и то, принимаются ли пакеты вообще.
Если проблема не воспроизводится на Вашем сервере без модификации Embed Player, то проблема скорее всего в модификации кода.
Также обязательно уточните параметры публикации потока:
- чем публикуете?
- для ffmpeg приведите командную строку, для OBS - скриншоты настроек
Уточните, на каком устройстве и с какой iOS воспроизводится проблема.
Если проблема воспроизводится на Вашем сервере с примерам из коробки, соберите отчет, как описано здесь, и пришлите, используя эту форму.

 

[alexosh]

Публикуется с IP-камеры просто RTSP, в общем попробовали зашли на ваш сервере (demo.flashphoner.com) зашли в Player (тоже самое в Streaming). Запустили стрим (ссылку я стрим скину в support форму). Через меньше чем 10 минут, сначала замерзло совсем и через несколько секунд черный экран.

Все это в Safari на iPhone 7 тоже 14.x.

Актуальные настройки камеры на скрине.

 

[Max]

Проверили воспроизведение Вашего стрима. С ним есть следующие проблемы:
1. По UDP стрим играет с большим количеством потерянных пакетов и ростом Nack. Поэтому рекомендуется играть его только по TCP.
2. Статистика WebRTC показывает скачки битрейта даже при условно статичной картинке. Если есть возможность задать CBR на стороне камеры, лучше это сделать
3. Периодически кратковременно проваливается FPS. Это может говорить о буферизации на стороне камеры.
4. Ключевые фреймы идут раз в 12 секунд, иногда больше. Это приводит к долгому проключению стрима (появлению картинки), если начать его играть
При добавлении настройки

h264_strict_kframe_detect=true

стрим играет в течение 30 минут на iOS Safari, проблема не воспроизводится. При этом в тех случаях, когда проблема воспроизводилась (без этой настройки), браузер не выводил никаких ошибок. Возможно, камера присылает нестандартный ключевой фрейм, который ломает что-то внутри WebRTC-движка именно в iOS Safari, т.к. браузер продолжает получать пакеты с данными, но просто их не показывает.
Если эта настройка не поможет, рекомендуем транскодировать поток для проигрывания на iOS Safari, например, создать транскодер по REST API

POST /rest-api/transcoder2/startup HTTP/1.1
HOST: localhost:8081
content-type: application/json
 
{
    "uri": "transcoder2://tcode2",
    "localStreamName": "rtsp_stream_ios",
    "remoteStreamName": "rtsp://**.**.**.**:**/media/video1 ",
    "encoder": {
      "height": 1080,
      "keyFrameInterval": 80,
      "fps": 20,
      "bitrate": 2000,
      "videoCodec": "H264"
    }
}

и играть транскодированный поток rtsp_stream_ios
Обращаем внимание, что транскодинг Вашего потока потребует 2 ядра CPU на один поток.
Также, поскольку поток заведомо не содержит аудио, рекомендуем играть его без аудио с constraints: {audio: false, video: true}

 

[alexosh]

Добавление `h264_strict_kframe_detect=true` в `flashphoner.properties` не помогло, то же самое - минут 10-15 и черный экран (возможно стало чуть дольше без черного экрана, хотя не факт, он все равно наступает). Странно, что у вас работает, на demo.flashphoner.com эта настройка стоит?

constraints в опциях `createStream` тоже поставили. Транскодинг еще не пробовали, хотелось бы обойтись без лишних усложнений и нагрузки на сервер в нашем случае. Отпишемся по результату.

Может что-то на камере поменять попробовать?

 

[Max]

Может что-то на камере поменять попробовать?

Попробуйте выставить постоянный битрейт (не переменный, как сейчас), и более короткий keyframe interval. Также, возможно. в настройках камеры есть параметры буферизации (как мы писали выше, скачки битрейта и FPS характерны для случая, когда кадры отправляются пачками).
Если все это не поможет, остается два варианта: менять камеру или включать транскодинг.

 

[alexosh]

Поставили постоянный битрейт и самое низкое значение. Все равно 10 минут - черный экран стабильно. Но подключаться видео (появляться изображение) стало быстрее (1-2 секунды).

Вопрос, может это все таки как-то отлаживается, чтобы точную причину то понять почему черный экран? Всё равно странно, что даже не понять никак (программно), что что-то пошло не так.

У нас про камеру вот такое написано:
Одной из последних новинок является UNIVIEW IPC322SR3-DVSPF28-B. Эта компактная купольная камера оснащена мощным цифровым сигнальным процессором, который поддерживает современный кодек H.265 (High Efficiency Video Coding). Это позволяет снизить видеопоток на 50 % в сравнении с популярным H.264 при сохранении высокого уровня качества. Дополнительно к этому алгоритм глубокой адаптивной компрессии UNIVIEW U-Code помогает уменьшить объем видеопотока до 95 % без потери детализации. Система UNIVIEW U-Code анализирует кадр и сохраняет высокую детализацию в области движения. При этом статичные части кадра (это может быть фасад здания или газон) максимально сжимаются для экономии дискового пространства.


Есть возможность использовать H.265?

 

[Max]

Вопрос, может это все таки как-то отлаживается, чтобы точную причину то понять почему черный экран? Всё равно странно, что даже не понять никак (программно), что что-то пошло не так.

Браузер продолжает получать поток, но его не отрисовывает в HTML5 video элементе. Ошибок при этом никаких не выдает. Похоже, от камеры прилетает проблемный фрейм, который ломает что-то внутри браузера.
Рекомендуем обновить WCS до последней сборки 5.2.1014, а также пробовать воспроизвести проблему в примере Media Devices. Также предоставьте, пожалуйста, доступ к Вашему серверу при помощи этой формы, чтобы мы могли тестировать поток на нем.

Есть возможность использовать H.265?

Пока нет. Создан тикет WCS-3106, но к его реализации еще не приступали. Сообщим, как только будет движение по этому тикету.

 

[alexosh]

Кстати, проблема это не только iOs как оказалось, на андройде в опере например тоже через 8-10 минут, только не черный экран, застывшая картина.

Сборку обновили, доступ отправили.

Как работать с примером Media Device я не поняли: Failed to get media devices, что там нужно сделать?

UPD: Еще заметили, что если после того как черный экран появится (или сделать это даже во время нормальной картинки) остановить видео и запустить - то видео может проигрываться без дальнейшей остановки в течении длительного времени, но это нестабильно (иногда все же опять через нек время возникает черный экран). Тем не менее, первая остановка, после запуска если ничего не делать приходит стабильно 8-10 минут.

 

[Max]

>Как работать с примером Media Device я не поняли: Failed to get media devices, что там нужно сделать?

Media Devices - это пример для тестирования настроек камеры, микрофона, плеера, и т. д. Поэтому он ищет микрофон и камеру для работы.
Если не находит, выдает "Failed to get media devices". Разрешите доступ к камере и микрофону, если используете этот пример.

 

[Max]

Media Devices работает только через https://
Поэтому должен быть настроен домен и SSL сертификат
Без этого подключение к серверу по порту 8443 не заработает с iOS Safari

Media Devices нам нужен для того чтобы быстро протестировать с TCP и убедиться что трафик идет через TCP. Пока не понятно как в ваших тестах идет трафик через TCP или через UDP.

 

[Max]

При тестировании в Media Devices TCP, в статистике видно, что потери нулевые: Lost, Fir, Pli, Nack.
Проверьте в хроме на десктопе действительно ли у вас включен TCP и потери 0.

 

[Max]

/usr/local/FlashphonerWebCallServer/logs/cdr/sdr.log

Еще посмотрите в sdr.log
Этот лог показывает, что воспроизведение идет с помощью MSE а не WebRTC
Проверьте ваш плеер и убедитесь что он играет по WebRTC. В логах должно быть WebRTC после завершения воспроизведения стриима.

 

[alexosh]

> Пока не понятно как в ваших тестах идет трафик через TCP или через UDP.

У нас везде TCP в createStream передается TCP, если включаем UDP там постоянные проблемы с фризами.

> Этот лог показывает, что воспроизведение идет с помощью MSE а не WebRTC

Это версия сайта разработки которая работает по HTTP, соответственно там MSE, HTTPS версия тестируется ios, там WebRTC, в mediaProviders передаем `WebRTC,MSE,WSPlayer`

Т.е. часть клиентов по MSE (там где WebRTC не играет) часть по WebRTC (на мобильных)

Речь ведь о проблемах именно на мобильных клиента, у вас скрин со стримом, вроде бы с десктопа, на десктопах такого не наблюдается, на мобильных стабильно, после около 10 минт прерывание, интересно, что затем если остановить и снова запустить стрим, он можете уже не прерываться.

 

[alexosh]

В общем, удалось установить внутренний симптом, что video элемент стрима оказывается в этот момент на паузе (video.paused == true). Статус стрима при этом "PLAYING". Соответственно, чтобы обойти это после этого можно остановить стрим, и перезапустить снова.

Вам виднее что может вызывать такое поведение клиента, но он, скорее всего, должен уметь такое каким-то образом обрабатывать.

 

[Max]

Вам виднее что может вызывать такое поведение клиента, но он, скорее всего, должен уметь такое каким-то образом обрабатывать.

Завели тикет WCS-3297. Как решение, Вы можете обработать событие видео элемента onpause, и вызвать метод play(), чтобы возобновить воспроизведение.

 

[alexosh]

Завели тикет WCS-3297. Как решение, Вы можете обработать событие видео элемента onpause, и вызвать метод play(), чтобы возобновить воспроизведение.

Да, примерно так и сделали.

 

[alexosh]

Добрый день, есть еще такой вопрос по проблемам трансляции.

Так же наблюдаем иногда проблемы со фризом (в основном на Android). При этом событий опять же нет (статус PLAYING) video элемент в данном случае уже не оказывается paused или stopped. Просто фриз, и никаких оповещений.

В итоге пара вопросов:

1) Почему flashphoner клиент при фризе не меняет статус, не срабатывают никакие события, он не может такую ситуацию определить? Что-то вообще происходит потенциально в этом случае на клиенте, он вообще как-то может понять, что полный фриз произошел, и если нет, то почему?

Есть прямо идея отслеживать это с помощью периодической отрисовки на два разных канваса содержания видео и сравнения попиксельно их содержимого, и если картинка не меняется, то перезапускать стрим - но это выглядит довольно жестким хаком.

2) Должно ли как-то подобное поведение на клиенте отображаться в логах сервера? Как такое вообще можно потенциально отслеживать? Поставили на сервере `client_log_level=DEBUG` и `enable_extended_logging=true` и смотрим содержимое `server_logs/flashphoner.log` там ничего нет при таком фризе.

Еще в документации говорится, что клиентские логики пишутся в каталог `/usr/local/FlashphonerWebCallServer/logs/client_logs`, пробуем смотреть файл `/usr/local/FlashphonerWebCallServer/logs/client_logs/flashphoner-client-logs.log` (как делаем с серверным там пусто), каталогов там много и файлов, но что и как смотреть неясно.

В общем как правильно смотреть и настраивать клиентские логи и может ли это помочь нам в нашем случае в проблеме с фризами?