качество webrtc->rtmp

[Denis Shevhenko]

добрый день!

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

При публикации на ваш wss://demo.flashphoner.com все ок.

В конфиге сервера:

webrtc_sdp_min_bitrate_bps=500000
webrtc_sdp_max_bitrate_bps=1400000

webrtc_cc_min_bitrate=500000
webrtc_cc_max_bitrate=1400000
ice_tcp_transport=true /// включал - отключал, не влияет

В клиенте все по умолчанию

 

[Max]

Добрый день.
Пожалуйста, соберите отчет, как описано здесь, включая дебаговые логи публикации и проигрывания, и пришлите, используя эту форму. Если размер архива превышает 30 Мб, выложите на облачный диск и дайте ссылку на архив.

 

[Max]

Здравствуйте.

Ссылку на архив удалили. Архив с логами содержит номер лицензии, IP адреса и эту информацию нежелательно размещать в публичном доступе. Можно отправить через приватную форму, которая есть для каждой форумной темы.

Что касается качества.
У вас в настройках в приоритете кодек VP8.
Стрим ковертируется в RTMP H.264, поэтому происходит транскодинг.
Скорее всего, потеря качества вызвана транскодингом из VP8 в H.264 на фоне недостатка ресурсов CPU и памяти.

Вторая возможная причина: использование Java 11 вместо рекомендуемых Java 12, Java 14, и т. д. Следующая проблема конфигурации - недостаточный Heap -Xmx1024m.

Поэтому рекомендации будут следующие:

1. Поменять в flashphoner.properties и тем самым убрать транскодинг:

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h264,flv,mpv

на

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv

2. Установить программу htop и дать скриншоты загрузки CPU по ядрам во время транскодинга.
У вас четыре виртуальных CPU с неопределенной производительностью. Для транскодинга требуются физические ядра.

3. Установить одну из рекомендуемых Java 12,14,15,16,17 https://docs.flashphoner.com/pages/viewpage.action?pageId=9241031

4. В конфиге wcs-core.properties выставить
-Xms2g -Xmx2g

в соответствии с рекомендациями: https://docs.flashphoner.com/pages/viewpage.action?pageId=14255501

5. Протестировать публикацию стрима в Media Devices, убедиться, что битрейт разгоняется до 1 Mbps.

Если это не поможет, сообщите пожалуйста как тестируете пошагово и со скриншотами.
Как отправляете и как забираете поток, чтобы мы могли воспроизвести проблему через ваш сервер.

 

[Denis Shevhenko]

Добрый день!
Спасибо за рекомендации.
Java обновил до 17, конфиг прописал, скрин htop:

При тестировании в Mediadevices обнаружил, что сервер меняет разрешение. Возможно, в этом и есть проблема. Как отключить преобразование?

 

[Max]

Добрый день!
Спасибо за рекомендации.
Java обновил до 17, конфиг прописал, скрин htop:

Большой нагрузки на CPU не видно. Также из скриншота Media Devices видно, что при публикации H264 битрейт на стороне зрителя соответствует опубликованному битрейту

При тестировании в Mediadevices обнаружил, что сервер меняет разрешение. Возможно, в этом и есть проблема. Как отключить преобразование?

Протокол WebRTC предусматривает автоматическое снижение разрешения при недостаточной пропускной способности канала между публикующим клиентом и сервером, отключить это поведение нельзя, но можно им управлять. Попробуйте переключить в примере Media Devices настройку Content Hint в detail

В этом случае браузер будет удерживать разрешение, но может сбрасывать FPS. Детали см здесь: Управление типом публикуемого контента в Chromium браузерах
Также Вы можете переключиться на TCP при публикации

Возможно, по TCP канала между Вашими клиентом и сервером будет достаточно для выбранного разрешения и битрейта. Детали см здесь: Управление WebRTC транспортом на стороне клиента

 

[Denis Shevhenko]

Спасибо, проблема решена выбором Content Hint.

 

[Denis Shevhenko]

Еще вопрос - можно ли оптимизировать, заменив rtmp на сырой входящий поток (rtp?), что бы избавиться от накладных расходов и лишних задержек при переупаковке контейнеров.

Схема моего комплекса ниже, проблемные места выделены красным.

 

[Max]

Еще вопрос - можно ли оптимизировать, заменив rtmp на сырой входящий поток (rtp?), что бы избавиться от накладных расходов и лишних задержек при переупаковке контейнеров.

Эти задержки незначительны по сравнению с теми, которые дает RTMP протокол сам по себе (до 3 секунд, т.к. базируется на TCP).
На сырой RTP поток заменить нельзя. WCS поддерживает WebRTC и RTMP для републикации на другой узел.
Можно также забирать с WCS поток по RTSP (желательно выставить порт, который отличается от RTSP порта по умолчанию 554, например rtsp.port=2554) и публиковать RTP поток на WCS по RTSP. MPEG-TS по UDP тоже поддерживается, только для публикации, сейчас работаем еще над публикацией MPEG-TS по SRT.
В любом случае, это не будет сырой RTP поток: поскольку передача сырого RTP потока плохо стандартизирована, лучше его оборачивать в какие-то протоколы.
Уточните: в этой схеме Вы забираете с WCS поток по RTMP, или републикуете его с WCS на Ваш сервер с C++ приложением? В зависимости от этого, качество звука настраивается немного по-разному (при републикации по умолчанию используется кодек AAC, если играть поток с сервера, то PCMA), но изображение идет с одинаковыми параметрами (H264, разрешение, битрейт и GOP соответствуют опубликованному в настоящий момент).

 

[Denis Shevhenko]

Спасибо.

RTMP поток забираю своим приложением.

Попробую забрать и отдать rtsp.