Трансляция через XSplitBroadcaster - ошибки на сервере

[extr]

Добрый день.
Поступают жалобы от пользователей XSplit Broadcaster:
`Пропадает видео, звук остается`
`Тормозит видео`

Проблема воспроизводится, XSplit Broadcaster 3.8
После старта стрима, сервер сыпет ошибками:

05:43:04,820 ERROR        ServerHandler - RTMP-pool-12-thread-6 RTMP error {}[id: 0x1406bff0, /83.246.137.102:65525 :> /67.22.42.117:1934]
java.lang.NullPointerException
        at com.flashphoner.server.rtmp.rtmp.server.G.channelClosed(Unknown Source)
        at org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(Unknown Source)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.channelClosed(Unknown Source)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(Unknown Source)
        at org.jboss.netty.handler.codec.frame.FrameDecoder.channelClosed(Unknown Source)
        at com.flashphoner.server.rtmp.rtmp.server.C.handleUpstream(Unknown Source)
        at org.jboss.netty.handler.timeout.IdleStateAwareChannelHandler.handleUpstream(Unknown Source)
        at org.jboss.netty.handler.timeout.IdleStateHandler.channelClosed(Unknown Source)
        at org.jboss.netty.channel.Channels.fireChannelClosed(Unknown Source)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(Unknown Source)
        at org.jboss.netty.channel.socket.nio.NioWorker.read(Unknown Source)
        at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(Unknown Source)
        at org.jboss.netty.channel.socket.nio.DeadlockAwareNioWorker.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Версия сервера 5.2.385
Обновление до 5.2.526 не помогло
В чем может быть проблема?

 

[Max]

Добавили внутренний тикет WCS-2564 для проверки с XSplit Broadcaster, сообщим о результатах.

 

[Max]

Уточните, пожалуйста, с какими настройками XSplit воспроизводится проблема с видео.
Чтобы в потоке не было B-фреймов, нужно использовать ultrafast preset.

 

[extr]

Уточните, пожалуйста, с какими настройками XSplit воспроизводится проблема с видео.
Чтобы в потоке не было B-фреймов, нужно использовать ultrafast preset.

Настройки по-умолчанию
При использовании ultrafast preset сильно страдает качество картинки. Тем не менее проблема с видео действительно проходит, но ошибка продолжает сыпать в лог.

Есть ли вариант удаления (игнора) bframes на стороне сервера (без поломки стрима)?

 

[Max]

Для того, чтобы публиковать потоки с B-frames и нормально эти потоки проигрывать, необходимо включить транскодинг на сервере

disable_streaming_proxy=true

и переключить декодер на OPENH264

decoder_priority=OPENH264,FF

По поводу ошибок в логе, мы их воспроизвели, будем исправлять в рамках тикета WCS-2564

 

[extr]

Для того, чтобы публиковать потоки с B-frames и нормально эти потоки проигрывать, необходимо включить транскодинг на сервере

disable_streaming_proxy=true

и переключить декодер на OPENH264

decoder_priority=OPENH264,FF

Добрый день!
При установке данных параметров в конфигурацию сервера, картинка стала еще хуже чем использовать ultrafast preset на стороне стримера.
Возможно есть еще какие-то варианты чтобы стрим B-frames не ломался? (проигрыватель webrtc в данном конкретном потоке не нужен, только rtmp-push)

По поводу ошибок в логе, мы их воспроизвели, будем исправлять в рамках тикета WCS-2564

Хорошие новости, спасибо

 

[Max]

Возможно есть еще какие-то варианты чтобы стрим B-frames не ломался? (проигрыватель webrtc в данном конкретном потоке не нужен, только rtmp-push)

Чтобы B-фреймы не мешали проигрывать поток по WebRTC, необходимо использовать транскодинг.
Если Вы используете ретрансляцию потока на другой сервер по RTMP, в этом случае транскодинг включается автоматически.
Таким образом, у Вас на сервере сейчас, скорее всего, работает транскодинг. Картинка, вероятно, становится хуже, т.к. сервер не справляется, судя по данному вопросу. Поэтому рекомендации будут теми же, что и в той теме: либо не использовать транскодинг и избегать B-фреймов в потоке, либо увеличивать производительность сервера.

 

[extr]

Добрый день!
> либо не использовать транскодинг и избегать B-фреймов в потоке, либо увеличивать производительность сервера.
По параметрам железки отвечу в той теме, транскодинга видимо не избежать, потому-как используем rtmp-push.
Поэтому настройка стримера является единственным решением

 

[extr]

Добрый день!

5.2.555 - 13 Mar 2020 WCS-2518 | Fixed: B-frames do not work with FF decoder

Похоже что поломка исправилась в этой версии.
Но ошибки все еще есть. Спасибо.

 

[Max]

Добрый день.
Да, этот фикс затрагивает обработку входящих потоков с B-фреймами при транскодинге.
Что касается Null pointer exception, эта проблема проявляется только в связке с XSplit, который, по всей видимости, открывает дополнительные RTMP соединения и сразу их сбрасывает. Над этой проблемой мы пока работаем, публикации потока это не мешает.

 

[Max]

транскодинга видимо не избежать, потому-как используем rtmp-push

В WCS версии 5.2.560 транскодинг при RTMP push без указания разрешения включаться не будет.

 

[extr]

Добрый день!
После обновления до версии 5.2.560 ситуация с потоками, где есть B-фреймы ухудшилась.
Видео снова стало тормозить и зависать
В client_logs следующее:

12:32:41,724 WARN   BitstreamNormalizer - RTMP-pool-12-thread-409 It is B-frame!
12:32:41,765 ERROR       H264AccessUnit - RTMP-pool-12-thread-409 Failed to get config, H264 can't generate AVC Config without sps/pps
12:32:41,765 ERROR       H264AccessUnit - RTMP-pool-12-thread-409 Can't generate extradata, H264 can't generate extra data without sps/pps

 

[Max]

Добрый день.
К сожалению, доступ к Вашему серверу больше не работает, в том числе для публикации. Пожалуйста, соберите логи по этой инструкции, включая вывод страниц статистики http://wcs:8081/?action=stat и http://wcs:8081/?action=stat&format=json&groups=transcoding_stats, и вышлите на support@flashphoner.com
Предварительно можно предположить, что после отключения транскодинга при републикации RTMP (в этом случае B-фреймы сохраняются в потоке) Ваш кодировщик начал получать B-фреймы на вход и теперь не может их обработать. Проверьте, как играется поток c сервера в VLC без републикации (например, если Вы публикуете поток rtmp://wcs:1934/live/test, то и играть нужно поток с этим же URL). Если при проигрывании потока фризов нет, то проблема в B-фреймах на входе стороннего кодировщика, либо, если Вы разнесли WCS и кодировщик по разным серверам, в канале между WCS и кодировщиком. Если же есть фризы и лаги в этом случае, проблема может быть в канале публикации.

 

[extr]

Добрый день.

Проверьте, как играется поток c сервера в VLC без републикации (например, если Вы публикуете поток rtmp://wcs:1934/live/test, то и играть нужно поток с этим же URL). Если при проигрывании потока фризов нет, то проблема в B-фреймах на входе стороннего кодировщика, либо, если Вы разнесли WCS и кодировщик по разным серверам, в канале между WCS и кодировщиком. Если же есть фризы и лаги в этом случае, проблема может быть в канале публикации.

1. WCS и кодировщик по разным серверам.
2. Визуально rtmp играется нормально с WCS, но имеется впечатление что fps занижен (плавности нет)
3. Воспроизведение rtmp входящего на кодировщик, уже хуже чем с WSC

  Duration: N/A, start: 68.547000, bitrate: N/A
    Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp
    Stream #0:1: Video: h264 (High), yuv420p(progressive), 1280x720, 30.30 fps, 30 tbr, 1k tbn, 60 tbc
[aac @ 000002101e3b55c0] This decoder does not support parameter changes, but PARAM_CHANGE side data was sent to it.
[aac @ 000002101e3b55c0] Error applying parameter changes.
[h264 @ 000002101e093a40] mmco: unref short failureq=    0B f=0/126
[h264 @ 000002101e09eb00] co located POCs unavailable    0B f=0/382
[h264 @ 000002101e089b80] co located POCs unavailable    0B f=0/682
[h264 @ 000002101e0935c0] co located POCs unavailable    0B f=0/1118
[h264 @ 000002101e089b80] co located POCs unavailable    0B f=0/1214
[h264 @ 000002101e093140] co located POCs unavailable    0B f=0/1645
[h264 @ 000002101e089b80] co located POCs unavailable    0B f=0/1715
[h264 @ 000002101e093a40] co located POCs unavailable    0B f=0/2049
[h264 @ 000002101e093140] co located POCs unavailable    0B f=0/2507
[h264 @ 000002101e0935c0] co located POCs unavailable    0B f=0/2748
[h264 @ 000002101e0935c0] co located POCs unavailable    0B f=0/3201
[h264 @ 000002101e09eb00] co located POCs unavailable    0B f=0/3236
[h264 @ 000002101e089b80] co located POCs unavailable    0B f=0/3272

4. Воспроизведение rtmp выходящего с кодировщика, совсем плохо

  Duration: N/A, start: 112.000000, bitrate: N/A
    Stream #0:0: Video: h264 (Main), yuv420p(progressive), 1280x720, 30.30 fps, 120 tbr, 1k tbn, 60 tbc
    Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp
[aac @ 0000020639da6840] This decoder does not support parameter changes, but PARAM_CHANGE side data was sent to it.
[aac @ 0000020639da6840] Error applying parameter changes.
[flv @ 0000020632f35800] DTS 114890 < 114957 out of order 0B f=23/25
124.30 A-V:  0.024 fd=  94 aq=   26KB vq=  110KB sq=     0B f=154/178

Замечу, если rtmp-поток запулить на кодировщике без транскодинга, просто нарезка HLS/DASH
При воспроизведении видео получается слайд-шоу.

Замечу, если поток с B-frames напрямую из OBS/XSplit транслировать на кодировщик, то подобной проблемы нет.
Админ на карантине - завтра будет доступ.
Спасибо

 

[extr]

Добрый день, вернули доступ и публикацию, проверьте
Спасибо

 

[Max]

Добрый день.
При публикации потока из XSplit на Ваш сервер и воспроизведении его по RTMP c него же поток играет плавно, ffplay показывает потери кадров на входящем потоке, но это связано с каналом (публикация и воспроизведение идут через один внешний канал)

[NULL @ 00000257399d1dc0] missing picture in access unit with size 57
[h264 @ 0000025741a6ccc0] no frame!
[h264 @ 0000025741a80b00] no frame!4KB vq=  339KB sq=    0B f=0/729

Метрики потока, снятые запросом /rest-api/stream/metrics, показывают стабильный fps 73-75

curl -s -H "Content-Type: application/json" -X POST http://localhost:8081/rest-api/stream/metrics -d '{"name":"fp_test"}' | jq
{
"VIDEO_SYNC": 423000,
"VIDEO_K_FRAMES": 6556,
"AUDIO_SYNC": 422997,
"VIDEO_NACK": 0,
"AUDIO_RATE": 98880,
"AUDIO_LOST": 0,
"VIDEO_LOST": 0,
"VIDEO_CODEC": 119,
"VIDEO_B_FRAMES": 18824,
"VIDEO_PLI": 0,
"AUDIO_CODEC": 102,
"VIDEO_RATE": 4145104,
"VIDEO_WIDTH": 0,
"VIDEO_HEIGHT": 0,
"VIDEO_FPS": 73,
"VIDEO_P_FRAMES": 6345
}

К сожалению, Вы не предоставили IP кодировщика, вынесенного на отдельный сервер, поэтому мы не смогли проверить трансляцию на кодировщик.
Если в Ваших тестах RTMP поток, входящий на кодировщик, хуже, чем поток, играемый с WCS, это может означать проблемы с каналом (потери, сниженная пропускная способность) между серверами, либо, если Вы публикуете и играете все потоки на одном и том же ПК, нехватку канала на одновременное воспроизведение и проигрывание FullHD с высоким битрейтом.
Канал можно проверить, например, при помощи iperf, один из вариантов использования описан у нас в документации.

 

[extr]

Отправил на почту

 

[Max]

Добрый день,

Мы провели от себя следующие тесты:
- републикация RTMP через WCS на кодировщик
- прямая публикация на кодировщик
- проигрывание потоков на входе и выходе кодировщика
Заметной разницы между републикацией через WCS и прямой публикацией при проигрывании HLS в VLC не увидели, в обоих случаях иногда были кратковременные фризы, в статистике потери кадров, вероятно, это влияние нашего канала.
В браузере (например, в Chrome при использовании videojs) картинка действительно дергается, если браузер не поддерживает B-фреймы. К сожалению, большинство десктопных браузеров по нашим тестам пока не поддерживают HLS с B-фреймами.
В связи с этим, поскольку WCS и кодировщик разнесены по серверам, и производительности сервера, на котором сейчас установлен WCS, должно хватить, рекомендуем использовать транскодинг на WCS, указав ширину и высоту картинки в /push/startup

{
    "streamName": "test",
    "rtmpUrl":"rtmp://encoder:1955/encoder_app/test",
    "width":1920, "height":1080
}

В дальнейшем, после вывода функции HLS ABR в продакшн, Вы сможете использовать эту функцию WCS без стороннего кодировщика.

 

[extr]

Добрый день,
Мы провели от себя следующие тесты:
- републикация RTMP через WCS на кодировщик
- прямая публикация на кодировщик
- проигрывание потоков на входе и выходе кодировщика
Заметной разницы между републикацией через WCS и прямой публикацией при проигрывании HLS в VLC не увидели, в обоих случаях иногда были кратковременные фризы, в статистике потери кадров, вероятно, это влияние нашего канала.

Это очень странно, что с вашей стороны не видно разницу. Если публикуешь напрямую на кодировщик, даже без транскодинга проблема исчезает при воспроизведения любого формата (rtmp,mpegts,mse,hls)

В связи с этим, поскольку WCS и кодировщик разнесены по серверам, и производительности сервера, на котором сейчас установлен WCS, должно хватить,

Я провел тест ре-публикации на кодировщик внутри одной железки, чтобы исключить проблему внутренней сети:
Источник: OBS x264 720p@2000K keyframe=2 preset=veryfast остальное по-умолчанию (значит будут bframes)
При аттачил логи:
1. Воспроизведение потока mpeg-ts через выход кодировщика
ffplay_mpegts_wcs_push.log - через wcs
ffplay_mpegts_direct.log - напрямую
2. Дебаг с кодировщика (не уверен что потребуется)
rtmppublisher_wcs_push.log - через wcs
rtmppublisher_direct.log - напрямую
Как видно по логам наполнение немного отличается, не смотря на то что потоки идентичны (источник один)
Возможно-ли как-то исправить ситуацию, без транскодинга на стороне WCS?

рекомендуем использовать транскодинг на WCS, указав ширину и высоту картинки в /push/startup
В дальнейшем, после вывода функции HLS ABR в продакшн, Вы сможете использовать эту функцию WCS без стороннего кодировщика.

Звучит хорошо, я подумаю как можно реализовать сценарий по схеме cdn, но сперва нужно пофиксить данную проблему.
Спасибо.

 

[Max]

Добрый день.

Как видно по логам наполнение немного отличается, не смотря на то что потоки идентичны (источник один)

По логам есть различие в аудиопотоке.
Рекомендуем явно прописать SDP для публикации и републикации RTMP. Для этого создайте в каталоге /usr/local/FlashphonerWebCallServer/conf файл flash_handler_publish.sdp со следующим содержимым:

v=0
o=- 1988962254 1988962254 IN IP4 0.0.0.0
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
m=video 0 RTP/AVP 119
a=rtpmap:119 H264/90000
a=fmtp:119 profile-level-id=4de01f;packetization-mode=1
a=sendonly
m=audio 0 RTP/AVP 108 96 109 98 99 100 102 103 104
a=rtpmap:108 mpeg4-generic/48000/1
a=rtpmap:96 mpeg4-generic/8000/1
a=rtpmap:109 mpeg4-generic/11025/1
a=rtpmap:98 mpeg4-generic/12000/1
a=rtpmap:99 mpeg4-generic/16000/1
a=rtpmap:100 mpeg4-generic/22050/1
a=rtpmap:104 mpeg4-generic/24000/1
a=rtpmap:102 mpeg4-generic/32000/1
a=rtpmap:103 mpeg4-generic/44100/1
a=sendonly

и файл media_transponder.sdp

v=0
o=- 1988962254 1988962254 IN IP4 0.0.0.0
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
m=video 0 RTP/AVP 95 96
a=rtpmap:95 H264/90000
a=fmtp:95 profile-level-id=4de01f;packetization-mode=0
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de01f;packetization-mode=1
a=recvonly
m=audio 0 RTP/AVP 103 96 97 98 99 100 102 108 104
a=rtpmap:108 mpeg4-generic/48000/1
a=rtpmap:96 mpeg4-generic/8000/1
a=rtpmap:97 mpeg4-generic/11025/1
a=rtpmap:98 mpeg4-generic/12000/1
a=rtpmap:99 mpeg4-generic/16000/1
a=rtpmap:100 mpeg4-generic/22050/1
a=rtpmap:104 mpeg4-generic/24000/1
a=rtpmap:102 mpeg4-generic/32000/1
a=rtpmap:103 mpeg4-generic/44100/1
a=recvonly

Этими файлами можно до определенной степени менять параметры потока при ретрансляции. Можно, например, для аудио оставить только 48000 Гц, в этом случае звук пойдет на выход WCS без ресемплинга. Отметим, что при изменении кодеков видео или звука, либо режима пакетизации на сервере включится транскодинг.

Возможно-ли как-то исправить ситуацию, без транскодинга на стороне WCS?

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