Стабилизация потока, оптимизация качества, микширование.

[Ilya K.]

Здравствуйте. Постараюсь детально описать задачи и проблемы, которые были выявлены при тестах.

Версия:
5.2.838 (тестировали на этой версии, планируется обновление)
Окружение:
1 Origin, 1 Edge (автоматическое развертывание дополнительных серверов средствами AWS). CPU, RAM периодически меняются. минимум 8 CPU, 16 GB RAM. Тип инстансов в AWS: c5a. Используем только webrtc.
Максимальное количество видеотрансляций в одном миксере - 6. (edge раздаёт микшированный поток с 6 видео и соответственно аудио)
decoder_priority=FF,OPENH264
encoder_priority=FF,OPENH264
codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
codecs_exclude_sip=mpeg4-generic,flv,mpv
codecs_exclude_sip_rtmp=opus,g729,g722,mpeg4-generic,telephone-event,vp8,mpv
codecs_exclude_streaming=flv,telephone-event


1. Оптимизация качества, стабилизация потока публикующий - Origin.
Столкнулись с тем, что качество каналов может быть разным:
стабильно высокий битрейт
стабильно низкий битрейт
меняющийся битрейт в одном и том же потоке.
Публикация проводилась по UDP, уже поменяли на TCP, будем перепроверять (обнаружили, что пакеты от некоторых опубликованных потоков терялись). Соответствующая настройки на origin:
ice_tcp_channel_high_water_mark=52428800
ice_tcp_channel_low_water_mark=5242880
ice_tcp_receive_buffer_size=1048576
ice_timeout=120
ice_tcp_send_buffer_size=1048576
ice_tcp_transport=true
ice_tcp_nio=true
webrtc_cc_max_bitrate=4000000
webrtc_cc_min_bitrate=60000
При таких настройках наблюдалось прерывание аудио, видео, фризы.
Разрешения экранов при публикации разные. Хотим достичь максимальной стабилизации (отсутствия прерывания видео, аудио), возможно ухудшив качество изображения.
Вопросы:
- Оптимальные значения webrtc_cc_max_bitrate, webrtc_cc_min_bitrate.
- Другие настройки для стабилизации видео/аудио
- Поможет ли занижение framerate

2. Микширование.
Как писал выше, максимальное количество потоков в миксере - 6 (может незначительно меняться).
Разрешения экранов, битрейт исходных для микширования потоков могут быть разными. Наблюдалось следующее:
Исходные для микширования потоки были доступны для проигрывания (раздел мedia devices) как с origin, так и с edge. В то же время в микшированном потоке иногда наблюдалось либо отсутствие аудио одного из потоков (было видно, что спикер говорит, но звука нет, остальные спикеры его слышат), либо зависание изображения также с потерей звука (остальные спикеры также слышат говорящего).
Вопросы:
- Как избавиться от проблемы зависания/пропадающего звука
- Посоветуйте пожалуйста оптимальные настройки для микширования с учетом разного качества каналов. Предполагается, что публиковаться потоки будут по TCP.

3. Демонстрация рабочего стола.
Здесь хотели бы выдержать максимальное качество. Желательно, чтобы совпадало с разрешением рабочего стола публикующего. Минимальная цель - читаемый текст на рабочем столе публикующего.
Вопросы:
- Посоветуйте, как оптимизировать качество/стабильность такого потока.

4. Проблемы с macOS
Несколько раз наблюдались перезагрузки, сильный нагрев и быстрый расход батареи при трансляции в MacOS.
Можно ли каким-то образом исправить эту проблему?

В целом хотели бы максимально снизить проблемы на стороне клиентов (браузеров), перенеся ёмкие по ресурсам задачи на сторону сервера.

Заранее спасибо.

 

[Max]

Добрый день.

decoder_priority=FF,OPENH264
encoder_priority=FF,OPENH264

Эти настройки можно не менять. По умолчанию, кодировщик FF не входит в поставку сервера, поэтому для кодирования всегда иcпользуется OPENH264. В последних сборках, по нашим тестам, этот кодировщик обеспечивает достаточную производительность и качество.
1. По качеству публикаций

webrtc_cc_max_bitrate=4000000
webrtc_cc_min_bitrate=60000

У вас сильно раздут максимальный битрейт. Рекомендуем оставить обе эти настройки по умолчанию, либо ограничить только минимальный битрейт, если при публикациях он сильно падает.
Если разрешение и битрейт потока превышают пропускную способность канала, то вы получите

прерывание аудио, видео, фризы.

Использование TCP в качестве транспорта помогает только предотвратить потери пакетов, но, если канала не хватает, единственный выход - снижать разрешение публикации и битрейт.

Поможет ли занижение framerate

В данном случае занижение fps не поможет.
Для качественной картинки необходимо также обеспечить регулярное поступление ключевых кадров от браузера. Для этого включите настройку

periodic_fir_request=true

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

periodic_fir_request_interval=2000

поскольку размер ключевых фреймов сравнительно велик, и частая их отсылка может нагрузить канал.
Также почитайте, пожалуйста, эту статью. Вы можете реализовать индикатор качества канала для публикующего участника, и снижать разрешение/битрейт публикации при падении качества канала.
2. По микшированию
Уточните, пожалуйста, настройки микшера, которые вы используете

Как избавиться от проблемы зависания/пропадающего звука

Проблема прежде всего во входящих потоках. Канала публикации должно хватать с запасом для потока с указанным разрешением и битрейтом. Например, для публикации одного потока 720p с битрейтом 2 Мбит/с нужен канал не менее 5 Мбит/с. Если пользователь еще и смотрит другие потоки, емкость канала должна быть выше.
С точки зрения оптимизации работы самого микшера, если вы используете MCU (т.е. дополнительно к кодированию одного видеопотока на микшер кодируется еще столько же аудио потоков, сколько в микшере участников), могут оказаться полезными настройки многопоточности микшера

mixer_type=MULTI_THREADED_NATIVE
mixer_mcu_multithreaded_mix=true
mixer_audio_threads=10
mixer_video_threads=4
mixer_mcu_multithreaded_delivery=true

но на 6 потоках в микшере это не критично.

Посоветуйте пожалуйста оптимальные настройки для микширования с учетом разного качества каналов.

Желательно использовать микшер реального времени. В этом случае при ухудшении качества канала одного из участников будет фриз только этого участника, но не всего микшера. По умолчанию эта настройка включена

mixer_realtime=true

Отключите собственный видеопроцессор микшера, если вы его включили

mixer_lossless_video_processor_enabled=false

Можно также менять в сторону увеличения буферизацию входящих потоков (по умолчанию 200 мс)

mixer_in_buffering_ms=600

Отметим, что, чем больше буферизация, тем больше будет задержка.
3. По демонстрации рабочего стола

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

Для максимального качества, пропускная способность канала публикации должна быть достаточной для 4K потоков (поскольку сейчас все больше таких мониторов, начиная от Retina на MacBook), т.е. минимум 10 Мбит/с на upload.
Поэтому рекомендуем ограничить разрешение компромиссным с точки зрения чтения (1080p или 720p). Чтобы картинка не замыливалась, битрейт для публикации экрана рекомендуется не ниже 500 кбит/с. В составе сборки 5.2.838 уже идет сборка WebSDK 0.5.28.2753.152 (GitHub), в которой поддерживается установка разрешения, битрейта и FPS при публикации экрана без расширения из браузера Chrome и его производных. В Safari экран всегда публикуется в полный размер.
Устанавливать ограничение минимального битрейта на стороне сервера нецелесообразно, т.к. при этом начнутся фризы в потоках других участников, которые не публикуют экран и при этом сидят на плохом канале. Поэтому битрейт нужно устанавливать на стороне клиента.
4. По проблеме с MacOS

Несколько раз наблюдались перезагрузки, сильный нагрев и быстрый расход батареи при трансляции в MacOS.
Можно ли каким-то образом исправить эту проблему?

Это. скорее всего, связано с кодированием видео в браузере. Мы не можем на это повлиять на со стороны сервера, ни даже из WebSDK. Попробуйте включит/отключить использование аппаратного ускорения, станет ли лучше или хуже?
С этим вопросом лучше обратиться к разработчикам браузера.

 

[Ilya K.]

Здравствуйте.
Отправил письмо на helpdesk@flashphoner.com. Приложил ссылку на примеры с видео и файл настроек flashphoner.properties

 

[Max]

К сожалению, письмо не получено. Пожалуйста, отправляйте все материалы при помощи кнопки Report в теме. Если необходима помощь в тестировании, предоставьте SSH доступ к серверу при помощи этой формы.

 

[Ilya K.]

Отправил данные через формы.

 

[Max]

Мы проверили присланные Вами ролики. В обоих случаях это проблемы с входящим потоком:
1. Запись original1 показывает, что оригинальный поток шел с низким FPS и фризами, в VLC запись играет почти слайдшоу. В таком случае в микшере будет фриз этого участника. 720p явно много для его канала.
2. Во втором случае видно, что поток проблемного участника играет, по сравнению с остальными, с низким FPS и подфриживаниями. Скорее всего, нет синхронизации между звуком и видео, в этом случае звука в микшере может не быть. Оригинальный поток мог не записаться также по отсутствию синхронизации.
Рекомендации пока остаются тем же: контролировать качество каналов, при необходимости снижать разрешение, включать TCP для проблемных клиентов, контролировать FPS.
Вы можете также несколько увеличить допустимый границы расхождения по времени между потоками участников (по умолчанию от 0.95 до 1.05), например

mixer_incoming_time_rate_lower_threshold=0,85
mixer_incoming_time_rate_upper_threshold=1,15

и снизить минимально допустимый FPS (по умолчанию 15)

mixer_video_stable_fps_threshold=10

но это может привести к ухудшению на потоках остальных участников, у которых не наблюдается проблем.
Рекомендуем также почистить настройки сервера, например, установить WCS с нуля и добавить в настройки только то, что необходимо.

 

[Ilya K.]

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

"720p явно много для его канала."
К сожалению, мы не можем не только влиять на каналы публикующих/подписчиков, но и знать об их качестве/пропускной способности. Подозреваю, что на сервере невозможно будет полностью настроить так, чтобы для всех было приемлемо.

Можно каким-то образом динамически регулировать разрешение, FPS в одном потоке в зависимости от качества канала? Плохой канал - разрешение становится ниже, хороший - выше. Если да, можно ли будет записывать/воспроизводить такие потоки? Если динамически невозможно, то может быть есть ещё какие-то варианты?
В статье https://docs.flashphoner.com/pages/viewpage.action?pageId=14255999 похоже, описано то, что нужно.
Теоретически можно замерить качество в начале стрима, например, если в течение какого-то времени после начала стрима с разрешением1280x720 качество не падает ниже GOOD, то можно начинать основной стрим. Но тогда вопрос. Как быть в случае, если в течение какого-то времени качество хорошее, потом резко падает в BAD или UNKNOWN и держится довольно долго?
Посоветуйте пожалуйста, каким образом в целом регулировать качество стрима в зависимости от качества канала.

 

[Max]

Можно каким-то образом динамически регулировать разрешение, FPS в одном потоке в зависимости от качества канала?

В WebRTC такие возможности есть на уровне протокола, и браузер при публикации пытается оценить качество канала и сбросить разрешение/битрейт, но не всегда успешно. Поэтому в WCS реализован свой механизм контроля качества

Как быть в случае, если в течение какого-то времени качество хорошее, потом резко падает в BAD или UNKNOWN и держится довольно долго?
Посоветуйте пожалуйста, каким образом в целом регулировать качество стрима в зависимости от качества канала.

В конце статьи есть общие рекомендации для стороны публикации и подписчика.
Как правило, если качество падает в BAD или UNKNOWN и держится в этом состоянии, нужно остановить публикацию и опубликовать поток заново с меньшим разрешением и битрейтом. FPS крутить, как правило, нецелесообрано.
Нужно учитывать, что качество оценивается по сравнению значений битрейта на отправляющей и принимающей сторонах. Расчет идет не по мгновенным значениям, а по усредненным при помощи фильтра Кальмана. Поэтому, когда оценка качества канала меняется, нет необходимости в длительной выдержке времени после этого, все уже усреднено.
Кроме того, можно, например, по умолчанию публиковать UDP, а если качество канала публикации падает, останавливать публикацию и публиковать заново, но уже с использованием TCP транспорта. Либо использовать TCP транспорт по умолчанию для всех публикаций, если мы исходно предполагаем каналы с потерями, либо публикацию толстых потоков. Отметим, что TCP транспорт позволяет бороться только с потерями, при низкой пропускной способности канала при использовании TCP также рекомендуется снижать разрешение и битрейт.