WebRTC as RTMP re-publishing

[Alex Vorona]

Ни на FB ни на YT не работает на версии 5.0.2541
В flashphoner_manager.log появляется rtmp_ поток в статусе playing, и меньше чем через секунду в статусе stopped
В flashphoner.log ничего подозрительного нет

09:50:31,466 INFO                     B - Thread-1080 Rtmp client connected to a.rtmp.youtube.com/173.194.10.21:1935

09:50:31,466 INFO                     J - pool-196-thread-2 using client version 4CDBBD00

09:50:31,802 WARN                     A - pool-196-thread-2 ignoring server command: [1 COMMAND_AMF0 c3 #0 t0 (0) s21] name: onBWDone, transactionId: 0, object: null, args: []

09:50:32,118 INFO                     B - pool-196-thread-2 Close publisher stream rtmp_Cam_53

На https://wcs5-eu.flashphoner.com:8888/dashboard.xhtml WebRTC as RTMP та же картина, PUBLISHING и failed через секунду.
Куда можно посмотреть?

 

[Max]

По-умолчанию к имени потока добавляется префикс rtmp_
Это сделано для того, чтобы не было конфликтов имен при ре-публикации на localhost.
Настройка flashphoner.properties

rtmp_transponder_stream_name_prefix =rtmp_

Поэтому, когда вы задаете поток "stream1", он уходит на YouTube как "rtmp_stream1".
YouTube ждет потока "stream1" и не аутентифиуирует поток "rtmp_stream1", поэтому завершает соединение.
Поэтому из настроек префикс нужно удалить если нужно публиковать поток с заданным в точности именем стрима:

rtmp_transponder_stream_name_prefix =

 

[Alex Vorona]

Указание

rtmp_transponder_stream_name_prefix =

и перезапуск flashphoner ничего не изменили. RTMP push делаю как через rest-api так и через dashboard.xhtml WebRTC as RTMP re-publishing.
Поясните пожалуйста, что значит YT ждет потока stream1 ? Я же не могу публиковать в flashphoner webrtc-потоки с именем, совпадающим с ключом трансляции YT. У FB вообще имя потока постоянно новое и неизвестное заранее.

 

[Max]

Я же не могу публиковать в flashphoner webrtc-потоки с именем, совпадающим с ключом трансляции YT

Почему нет? Можете. И именно так и надо публиковать чтобы YT его принял.
Или вопрос про безопасность, что пользователь увидит клчюч-имя потока?

У FB вообще имя потока постоянно новое и неизвестное заранее.

Когда мы тестировали
https://flashphoner.com/transliruem-videopotok-s-veb-stranic/?lang=ru
было так:
1. YT или FB, при создании трансляции выдают 1) URL 2) имя потока.
2. Публикуем поток с таким именем через WebRTC и далее делаем ре-публикацию в RTMP по указанному URL и с указанным именем.

 

[Max]

Попробуйте также проверить, будет ли работать с нашим демо-сервером. Он настроен без префикса.
https://wcs5-us.flashphoner.com:888...republishing/webrtc-as-rtmp-republishing.html
Если нет, будем разбираться что поменялось с facebook.

 

[Alex Vorona]

Или вопрос про безопасность, что пользователь увидит клчюч-имя потока?

Вопрос в том, что поток запускается до того как принимается решение ре-публиковать его в FB/YT, в том числе одновременно в оба.

Попробуйте также проверить, будет ли работать с нашим демо-сервером. Он настроен без префикса.

По ссылке webrtc-as-rtmp-republishing.html работает на us-сервере и на нашем сервере, не работает на вашем eu-сервере. Вчера тестировал на ещё одном нашем сервере на версии с серверным микшированием аудио, на ней не работает.
Также нигде не работает re-publishing существующего стрима с обычным именем через REST, как описано в https://habrahabr.ru/company/flashphoner/blog/327986/ , а именно re-publishing существующего стрима в FB/YT нам и нужен. curl возвращает 200 и json c объектом транспондера

{"mediaSessionId":"4v2k39d9s38rgactllkhip9p3u","streamName":"94a2","rtmpUrl":"rtmp://a.rtmp.youtube.com/live2/XXXX-XXXX-XXXX-XXXX","width":320,"height":240,"muted":false,"soundEnabled":false,"options":{}}

но на YT ничего нет и во flashphoner_manager.log - started и через секунду stopped.

 

[Alex Vorona]

Такое ощущение что в REST-API streamName добавляется в rtmpUrl, если rtmpUrl уже не заканчивается на streamName

 

[Max]

Да, для RTMP-потока использовалось то же имя, что передавалось в streamName.

Возможность использования для RTMP-потока имени из rtmpUrl не была добавлена для последней реализации RTMP-агента, которая используется по умолчанию. Добавлено в версии 2547.

Для републикации на FB/YT нужно проапдейтить сервер и в WCS_HOME/conf/flashphoner.properties
- убрать

rtmp_transponder_stream_name_prefix =rtmp_

- добавить

rtmp_transponder_full_url =true

 

[Alex Vorona]

Извиняюсь за наглость, когда можно ждать этот фикс в ветке wcs5_monitoring ? Хотя у нас на ней даже с нужным именем стрима не работает сабж.

 

[Max]

когда можно ждать этот фикс в ветке wcs5_monitoring ?

Перенесли в wcs5_monitoring в сборке 2548 но еще не тестировали.

 

[Mani]

Hello guys,

Have u managed to make this work.I am also facing the same issue even i tried with your given link above still not able to publish it to facebook. i am using 2551. If yes can u pls help me with the solution

 

[Max]

not able to publish it to facebook

Hello,

For republishing to Facebook or YouTube,
1. In WCS_HOME/conf/flashphoner.properties
- remove

rtmp_transponder_stream_name_prefix =rtmp_

- add

rtmp_transponder_full_url =true

2. Restart the WCS server to apply configuration changes
3. Specify full RTMP URL (i.e. Server URL + Stream Key) as rtmpUrl in push/startup
So, the REST request body would be like this:

{
"streamName": "webrtcstream",
"rtmpUrl":"rtmp://live-api-a.facebook.com:80/rtmp/537055626776335?ds=1&a=ATgB40Qmf1bbS6kP"
}

In case of further questions, please create a new thread in https://forum.flashphoner.com/forums/web-call-server-5.13/

 

[Alex Vorona]

ре-паблишинг десктоп-шаринга на YT/FB работает нестабильно, иногда приходится отправлять push/startup повторно, иногда YT показывает что трансляция начата, но ни звука ни видео нет, при этом Flashphoner шлет rtmp на youtube на порт 1935. Как-то можно это подебажить ?
Наблюдаем также, что воспроизведение на FB/YT дергается, и в результате этого видео отстает от звука.

 

[Max]

Какой приоритет кодеков в настройке codecs= конфига flashphoner.properties ?
Попробуйте выставить vp8 кодек в приоритет.
YouTube и Facebook Live требуют ровного захода трафика по RTMP.
Плавного захода можно достичь только с использованием VP8 на стороне WCS.
Еще, в дополнение, можно попробовать выкрутить минимальный битрейт в 1 Mbps в настройке flashphoner.properties

webrtc_cc_max_bitrate=2000000

webrtc_cc_min_bitrate=1000000

чтобы предотвратить падение битрейта при скриншаринге.
Если вы зажали битрейт между 400kbps и 500kbps, скриншаринг 720p работать нормально не будет, т.к. нужна более широкая полоса

webrtc_cc_max_bitrate=500000

webrtc_cc_min_bitrate=400000

Все хорошо должно быть видно в chrome://webrtc-internals
Если разрешение скриншаринга 720p, 30 FPS, то нужно раздвигать полосу до 2 Mbps с кодеком VP8 для нормального скриншаринга, либо уменьшать FPS / разрешение, чтобы войти в ограниченную полосу.

 

[Alex Vorona]

VP8 осознанно не используем, тк webrtc Safari и iOS нужны. Есть какие-то варианты совместить ?
Битрейт со стороны сервера давно поднят до 2.6мбита, встроенный дефолт в хром 2.5мбита.

webrtc_cc_min_bitrate=2600000
webrtc_cc_max_bitrate=3000000

В логах один из вариантов отключения какой-то такой

много строк с Not enough data in audio buffer
11:38:43,016 WARN  -mpeg4-generic/44100 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Not enough data in audio buffer, current data size 1921
11:38:43,147 WARN  -mpeg4-generic/44100 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Not enough data in audio buffer, current data size 1981
11:38:43,290 WARN  -mpeg4-generic/44100 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Not enough data in audio buffer, current data size 2041
11:38:43,309 WARN  -mpeg4-generic/44100 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Synchronization time drop, requested 3719669923201 current 3719580444718
11:38:43,447 WARN  -mpeg4-generic/44100 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Not enough data in audio buffer, current data size 1817
11:38:43,451 INFO      MediaTransponder - pool-294-thread-2 Terminate media transponder
11:38:43,456 INFO  e7-b0ea-558d3d2ed834 - pool-294-thread-2 STOP DISTRIBUTOR
11:38:43,456 INFO     VideoEncoder-H264 - pool-294-thread-2 Stop video stream encoder
11:38:43,460 INFO  e7-b0ea-558d3d2ed834 - pool-294-thread-2 STOP DISTRIBUTOR
11:38:43,461 INFO          MediaSession - pool-294-thread-2 Stop MediaSession id: 8sslctedct23p07oke4oierupj
11:38:43,463 INFO    AbstractRtpSession - pool-294-thread-2 RtpSession with id 8sslctedct23p07oke4oierupj terminated.
11:38:43,465 INFO    AbstractRtpSession - pool-294-thread-2 RtpSession with id 8sslctedct23p07oke4oierupj terminated.
11:38:43,468 INFO  e7-b0ea-558d3d2ed834 - AudioProcessor-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 STOP DISTRIBUTOR
11:38:48,444 INFO  e7-b0ea-558d3d2ed834 - AudioDistributor-PROXY-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Ended with queue size 0
11:38:48,447 INFO  e7-b0ea-558d3d2ed834 - AudioDistributor-mpeg4-generic-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Ended with queue size 0
11:38:48,460 INFO  e7-b0ea-558d3d2ed834 - VideoDistributor-H264-640x480-524288-74fc1af0-c95d-11e7-b0ea-558d3d2ed834 Ended with queue size 0

 

[Max]

VP8 осознанно не используем, тк webrtc Safari и iOS нужны. Есть какие-то варианты совместить ?

Должно работать из коробки.
Если в приоритете VP8:

vp8,h264

То Chrome при публикации потока будет использовать vp8+Opus.
iOS Safari 11 при воспроизведении потока будет использовать h.264+Opus
Т.е. появится одна транскодинг сессия vp8-h.264.
Если вы используете ветку wcs5_monitoring, на ней в мониторинге видно транскодинг сессии в меню Monitoring - Streams - Real Time - Transcoding
Например, если один Chrome стримит один поток vp8+Opus, а на него подписываются N - браузеров iOS Safari 11, то будет всего 1 транскодинг сессия. Т.е. количество публикуемых потоков равно количеству транскодинг сессий.

 

[Max]

В логах один из вариантов отключения какой-то такой

Подскажите версию сервера. Попробуем воспроизвести у себя.
Тестируем RTMP re-publishing скриншаринга с микрофоном на Facebook правильно?

 

[Alex Vorona]

Да, похоже vp8 в приоритете решает проблему. Спасибо!

 

[Alex Vorona]

Подскажите версию сервера.

5.0.2549

Попробуем воспроизвести у себя.

это на h.264, если увидим на vp8 - сообщим.

Тестируем RTMP re-publishing скриншаринга с микрофоном на Facebook правильно?

в приведенном логе с youtube отвалилась камера 640x480 30fps.