Изображение с камеры сильно фризит при переключении вкладки.

[Ilya K.]

Здравствуйте.
Версия v.2.0.198-5.2.1031

Через приложение публикуем стрим. Также, через приложение на другом браузере и ПК, его воспроизводим (микшированный поток с Edge).
Воспроизводится всё относительно нормально (с небольшими фризами) до тех пор, пока публикующий не переключит вкладку браузера. В этом случае сразу начинают наблюдаться сильные фризы потока с камеры публикующего (проверили, фризы есть уже на Origin во входящем потоке. Соответственно микшированный с edge воспроизводится также с фризами. Битрейт входящего потока падает). В отчете участок кода приложения, где создаётся подключение, файл отчета.

 

[Max]

Добрый день.
К сожалению, в Вашем отчете не содержится ни кода Вашего приложения (предоставленная веб страница не содержит кода публикации), ни серверного лога, поэтому мы не можем даже определить используемый Вами в тестировании браузер. Дамп, который Вы собрали, также бесполезен без серверного лога и клиентских отладочных логов. Кроме того, проблема не воспроизводится при следующем тесте:
1. Публикуем поток из Chrome на наш демо сервер (5.2.1032) в примере Media Devices
2. Играем его в другом экземпляре Chrome на этом же ПК или на другом ПК
3. Переключаем вкладку в том браузере, откуда идет публикация, или сворачиваем окно браузера
4. Поток с камеры продолжает играть без фризов
Тестируем именно на ПК, т.к. переключение вкладки или сворачивание в мобильном браузере приводит к остановке публикации
В связи с этим, просим уточнить следующее:
1. Что означает

пока публикующий не переключит вкладку браузера

сворачивание всего окна, переход на другую вкладку?
2. В каком браузере тестируете? Включено или отключено аппаратное ускорение?
3. Если

проверили, фризы есть уже на Origin во входящем потоке

то, скорее всего, проблема на стороне браузера. Проверьте, воспроизводится ли проблема в примере Media Devices на нашем демо сервере и на Вашем сервере. Если не воспроизводится, проблема может быть в Вашем коде. В этом случае рекомендуем проверить нагрузку на процессор ПК, с которого публикуется поток, провести профилирование Вашего кода.
Проверьте также, воспроизводится ли проблема при подключении другой камеры к тому же ПК, либо с другого ПК.
На стороне сервера необходимо проверять метрики входящего потока на наличие потерь по изменению счетчиков VIDEO_NACK, VIDEO_LOST. Если потери увеличиваются при сворачивании вкладки, это также говорит о проблемах в браузере.

 

[Max]

Проверили Ваш следующий отчет. Сам по себе отчет содержит ровно то же самое. Но по предоставленному коду можно предположить, что Вы используете в качестве источника картинки канвас. В этом случае фризы при уходе страницы в фон являются ожидаемым поведением. Использование setTimeout в этом случае позволяет перерисовывать картинку в фоне, но дает большую нагрузку по сравнению с requestAnimationFrame, а этот способ, в свою очередь, гарантированно останавливается в фоне.
Кроме того, в мобильных браузерах отрисовка на канвасе с setTimeout также останавливается в фоне полностью.
Рекомендуем либо отказаться от использования канваса (который нужен, суда по коду, только для того, чтобы наложить логотип), либо не допускать сворачивания страницы браузера в фон или переключения на другую вкладку. Если Вы используете микшер, логотип можно накладывать на картинку в микшере, как описано здесь.

 

[Ilya K.]

Отправил повторно.

сворачивание всего окна, переход на другую вкладку?

Переход на другую вкладку

2. В каком браузере тестируете? Включено или отключено аппаратное ускорение?

Chrome, Firefox. Аппаратное ускорение включено, отключать не можем. Используем sdp хуки для решения проблемы с низким битрейтом. Есть во вложенном файле.

Проверьте, воспроизводится ли проблема в примере Media Devices на нашем демо сервере и на Вашем сервере

Не воспроизводится. Вероятно, проблема в публикации.
Метрики говорили только о снижении битрейта такого потока.

 

[Ilya K.]

Сначала отправил, потом получил комментарий. Понял, спасибо.