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

extr

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

Проблема воспроизводится, XSplit Broadcaster 3.8
После старта стрима, сервер сыпет ошибками:
Code:
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

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

Max

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

extr

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

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

Max

Administrator
Staff member
Для того, чтобы публиковать потоки с B-frames и нормально эти потоки проигрывать, необходимо включить транскодинг на сервере
Code:
disable_streaming_proxy=true
и переключить декодер на OPENH264
Code:
decoder_priority=OPENH264,FF
По поводу ошибок в логе, мы их воспроизвели, будем исправлять в рамках тикета WCS-2564
 

extr

New Member
Для того, чтобы публиковать потоки с B-frames и нормально эти потоки проигрывать, необходимо включить транскодинг на сервере
Code:
disable_streaming_proxy=true
и переключить декодер на OPENH264
Code:
decoder_priority=OPENH264,FF
Добрый день!
При установке данных параметров в конфигурацию сервера, картинка стала еще хуже чем использовать ultrafast preset на стороне стримера.
Возможно есть еще какие-то варианты чтобы стрим B-frames не ломался? (проигрыватель webrtc в данном конкретном потоке не нужен, только rtmp-push)
По поводу ошибок в логе, мы их воспроизвели, будем исправлять в рамках тикета WCS-2564
Хорошие новости, спасибо
 

Max

Administrator
Staff member
Возможно есть еще какие-то варианты чтобы стрим B-frames не ломался? (проигрыватель webrtc в данном конкретном потоке не нужен, только rtmp-push)
Чтобы B-фреймы не мешали проигрывать поток по WebRTC, необходимо использовать транскодинг.
Если Вы используете ретрансляцию потока на другой сервер по RTMP, в этом случае транскодинг включается автоматически.
Таким образом, у Вас на сервере сейчас, скорее всего, работает транскодинг. Картинка, вероятно, становится хуже, т.к. сервер не справляется, судя по данному вопросу. Поэтому рекомендации будут теми же, что и в той теме: либо не использовать транскодинг и избегать B-фреймов в потоке, либо увеличивать производительность сервера.
 

extr

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

extr

New Member
Добрый день!
5.2.555 - 13 Mar 2020 WCS-2518 | Fixed: B-frames do not work with FF decoder
Похоже что поломка исправилась в этой версии.
Но ошибки все еще есть. Спасибо.
 

Max

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

Max

Administrator
Staff member
транскодинга видимо не избежать, потому-как используем rtmp-push
В WCS версии 5.2.560 транскодинг при RTMP push без указания разрешения включаться не будет.
 

extr

New Member
Добрый день!
После обновления до версии 5.2.560 ситуация с потоками, где есть B-фреймы ухудшилась.
Видео снова стало тормозить и зависать :(
В client_logs следующее:
Code:
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

Administrator
Staff member
Добрый день.
К сожалению, доступ к Вашему серверу больше не работает, в том числе для публикации. Пожалуйста, соберите логи по этой инструкции, включая вывод страниц статистики 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

New Member
Добрый день.
Проверьте, как играется поток c сервера в VLC без републикации (например, если Вы публикуете поток rtmp://wcs:1934/live/test, то и играть нужно поток с этим же URL). Если при проигрывании потока фризов нет, то проблема в B-фреймах на входе стороннего кодировщика, либо, если Вы разнесли WCS и кодировщик по разным серверам, в канале между WCS и кодировщиком. Если же есть фризы и лаги в этом случае, проблема может быть в канале публикации.
1. WCS и кодировщик по разным серверам.
2. Визуально rtmp играется нормально с WCS, но имеется впечатление что fps занижен (плавности нет)
3. Воспроизведение rtmp входящего на кодировщик, уже хуже чем с WSC
Code:
  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 выходящего с кодировщика, совсем плохо
Code:
  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

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

Max

Administrator
Staff member
Добрый день.
При публикации потока из XSplit на Ваш сервер и воспроизведении его по RTMP c него же поток играет плавно, ffplay показывает потери кадров на входящем потоке, но это связано с каналом (публикация и воспроизведение идут через один внешний канал)
Code:
[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
Code:
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, один из вариантов использования описан у нас в документации.
 

Max

Administrator
Staff member
Добрый день,

Мы провели от себя следующие тесты:
- републикация RTMP через WCS на кодировщик
- прямая публикация на кодировщик
- проигрывание потоков на входе и выходе кодировщика
Заметной разницы между републикацией через WCS и прямой публикацией при проигрывании HLS в VLC не увидели, в обоих случаях иногда были кратковременные фризы, в статистике потери кадров, вероятно, это влияние нашего канала.
В браузере (например, в Chrome при использовании videojs) картинка действительно дергается, если браузер не поддерживает B-фреймы. К сожалению, большинство десктопных браузеров по нашим тестам пока не поддерживают HLS с B-фреймами.
В связи с этим, поскольку WCS и кодировщик разнесены по серверам, и производительности сервера, на котором сейчас установлен WCS, должно хватить, рекомендуем использовать транскодинг на WCS, указав ширину и высоту картинки в /push/startup
Code:
{
    "streamName": "test",
    "rtmpUrl":"rtmp://encoder:1955/encoder_app/test",
    "width":1920, "height":1080
}
В дальнейшем, после вывода функции HLS ABR в продакшн, Вы сможете использовать эту функцию WCS без стороннего кодировщика.
 

extr

New Member
Добрый день,
Мы провели от себя следующие тесты:
- републикация 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, но сперва нужно пофиксить данную проблему.
Спасибо.
 

Attachments

Max

Administrator
Staff member
Добрый день.
Как видно по логам наполнение немного отличается, не смотря на то что потоки идентичны (источник один)
По логам есть различие в аудиопотоке.
Рекомендуем явно прописать SDP для публикации и републикации RTMP. Для этого создайте в каталоге /usr/local/FlashphonerWebCallServer/conf файл flash_handler_publish.sdp со следующим содержимым:
Code:
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
Code:
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, и не нашли различий в качестве воспроизводимого потока между входом и выходом стороннего сервера. в связи с этим, рекомендуем также подключить к решению вопроса техподдержку используемого Вами кодировщика.
 
Top