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

Discussion in 'Web Call Server 5' started by extr, Feb 26, 2020.

  1. extr

    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 не помогло
    В чем может быть проблема?
  2. Max

    Max Administrator Staff Member

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

    Max Administrator Staff Member

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

    extr New Member

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

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

    Max Administrator Staff Member

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

    extr New Member

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

    Max Administrator Staff Member

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

    extr New Member

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

    extr New Member

    Добрый день!
    Похоже что поломка исправилась в этой версии.
    Но ошибки все еще есть. Спасибо.
  10. Max

    Max Administrator Staff Member

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

    Max Administrator Staff Member

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

    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
  13. Max

    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 и кодировщиком. Если же есть фризы и лаги в этом случае, проблема может быть в канале публикации.
  14. extr

    extr New Member

    Добрый день.
    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 транслировать на кодировщик, то подобной проблемы нет.
    Админ на карантине - завтра будет доступ.
    Спасибо
  15. extr

    extr New Member

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

    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, один из вариантов использования описан у нас в документации.
  17. extr

    extr New Member

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

    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 без стороннего кодировщика.
  19. extr

    extr New Member

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

    Я провел тест ре-публикации на кодировщик внутри одной железки, чтобы исключить проблему внутренней сети:
    Источник: 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?
    Звучит хорошо, я подумаю как можно реализовать сценарий по схеме cdn, но сперва нужно пофиксить данную проблему.
    Спасибо.

    Attached Files:

  20. Max

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

Share This Page