Качество микшированного потока на origin

[Ilya K.]

Здравствуйте. Провели тестирование через наше приложение. В итоге, fps всё равно снижается. Наблюдается следующее:
-Первое время fps держится относительно высоким у всех участников, дальше плавно падает.
-По истечении времени fps начинает падать у всех, кроме одного, участника. Версии браузеров у всех одинаковы. Параметры публикации заданы в коде, тоже одинаковы. У всех включено аппаратное ускорение.
-Для видео с камеры задано videoContentHint: "motion".

Потоки на origin:
116584wCX5wxh9TxYGHyL
116584jvJcp9jrnWoHvIY
1165842jEf4IwsPAAEnJ4
1165842Ix5fPfhggXiv2A

1165842jEf4IwsPAAEnJ4 -в этоппотоке fps не падало,в остальных в разной степени снижалось.

Вторая проблема - В потоке 1165842jEf4IwsPAAEnJ4 по какой-то причине не было звука в период примерно c 8:40 по 8:47.

Ссылку с отчетом отправляю через report
Есть ли варианты по настройке удержания fps, либо это только возврат к публикации с VP8 до тех пор, пока в Chrome не устронят проблему?

 

[Max]

1165842jEf4IwsPAAEnJ4 -в этоппотоке fps не падало,в остальных в разной степени снижалось.

Уточните, пожалуйста, как и где измеряли FPS:
- на Origin сервере по метрикам
- на Edge сервере по метрикам
- визуально для потока
- визуально в потоке микшера
Последнее не дает правильной картины, поскольку для микшера у Вас установлено ограничение в настройках в 15 FPS, поэтому, даже если входящие потоки меняются быстрее, играть все рано будет 15 FPS
Наиболее правильным будет снимать метрики потока на том сервере, куда он публикуется, либо периодически по REST API, либо собирать метрики всех публикаций в Prometheus и затем строить график в Grafana. Общие рекомендации по настройке связки Prometheus+Grafana для мониторинга сервера есть в статье 10 важных метрик WebRTC стриминга и настройка мониторинга Prometheus +Grafana

Вторая проблема - В потоке 1165842jEf4IwsPAAEnJ4 по какой-то причине не было звука в период примерно c 8:40 по 8:47.

Единственная публикация потока с данным именем в логах закончилась остановкой сессии паблишера в 08:37:40.
Если звука в потоке нет длительное время, нужно снимать метрики и смотреть число потерянных аудио пакетов AUDIO_LOST, значение синхронизации аудио AUDIO_SYNC и битрейт аудио AUDIO_RATE. Битрейт порядка 12000-14000 кбит/с и ниже говорит о тишине, рост числа потерянных пакетов говорит о потерях в канале, нулевые значение синхронизации говорит об отсутствии аудио пакетов.
Также можно подключиться к Origin, где опубликован поток, проиграть поток в примере Media Devices и посмотреть WebRTC статистику, которую пример отображает.

Есть ли варианты по настройке удержания fps, либо это только возврат к публикации с VP8 до тех пор, пока в Chrome не устронят проблему?

Если вы используете WebSDK 2.0.180 и новее (в более ранних версиях эта опция не поддерживается), и выставили при при публикации потока опцию videoContentHint: "motion", как описано в документации, то на этом возможности по удержанию FPS исчерпаны, далее браузер сам принимает решение.
При публикации VP8 необходимо играть также VP8, чтобы избежать транскодинга. Но поток микшера идет всегда в H264, в этом случае необходимо исключать или не исключать H264 в зависимости от того, какой поток играет у клиента: транскодинг потока микшера с Вашими параметрами (1080p, 4 Mbps) из H264 в VP8 сильно нагрузит сервер.
Если удержание FPS для Вас настолько критично, рекомендуем использовать Firefox для публикации H264.

 

[Ilya K.]

Уточните, пожалуйста, как и где измеряли FPS:
- на Origin сервере по метрикам
- на Edge сервере по метрикам
- визуально для потока
- визуально в потоке микшера

На origin сервере по метрикам (/rest-api/stream/metrics) и визуально. Ограничение установлено в 15, падало до 2-4. Именно входндные потоки, не микшированный.

При публикации VP8 необходимо играть также VP8, чтобы избежать транскодинга. Но поток микшера идет всегда в H264, в этом случае необходимо исключать или не исключать H264 в зависимости от того, какой поток играет у клиента: транскодинг потока микшера с Вашими параметрами (1080p, 4 Mbps) из H264 в VP8 сильно нагрузит сервер.

Я правильно понимаю, что при публикации в VP8, в любом случае будет транскодинг, т.к. микшированный проигрывается исключительно в H264? Что имеется ввиду под необходимостью исключать H264 в зависимости от того, какой поток играет? При публикации на не Chromium-браузерах исключаем H264, на остальных не исключаем, т.к. уменьшения fps не наблюдается?

 

[Max]

На origin сервере по метрикам (/rest-api/stream/metrics) и визуально. Ограничение установлено в 15, падало до 2-4. Именно входндные потоки, не микшированный.

Предоставьте, пожалуйста, доступы к серверам (Origin и Edge), на которых это поведение воспроизводится (SSH доступ и доступ к WCS админке для публикации/воспроизведения) для проведения тестов, используя эту форму.

Я правильно понимаю, что при публикации в VP8, в любом случае будет транскодинг, т.к. микшированный проигрывается исключительно в H264?

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

Что имеется ввиду под необходимостью исключать H264 в зависимости от того, какой поток играет?

Выходной поток микшера нужно играть в H264. Входные потоки участников, которые публикуются как VP8, нужно играть как VP8, если Вы их играете отдельно на клиенте.

 

[Ilya K.]

Отправил запрашиваемые данные.

 

[Max]

Проверили Ваш сервер. На нем используются следующие сборки:
WCS: 5.2.969
WebSDK: 2.0.170
Данная сборка WebSDK не содержит фикса, связанного с вышеупомянутым багом Chrome, и опция videoContentHint в ней не поддерживается (но игнорируется, если указать). Пожалуйста, обновите WebSDK до 2.0.180 или новее, как мы уже рекомендовали выше, и повторите тесты.
Также отметим, что язык разметки собственных вариантов размещения картинок в микшере не поддерживается в сборке WCS 5.2.969. Если Вы тестируете эту возможность, обновите WCS до сборки 5.2.1020 или новее (эта сборка также содержит фиксы для встроенного варианта размещения картинок, предназначенного для публикации десктопа в микшере).