Проблема с воспроизведением RTMP через WebRTC

Discussion in 'Web Call Server 5' started by Evgenii, Dec 4, 2019 at 2:16 PM.

  1. Evgenii

    Evgenii New Member

    Добрый день, тестирую ваш продукт и возникла проблема с отображением видео, публикуемого с OBS Studio по RTMP в браузере через WebRTC.

    Публикую из OBS Studio, экран, с настройками по умолчанию (насколько мне известно).
    Настройки сервера:

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

    #websocket ports
    ws.port =8080
    wss.port =8443
    rtmp_transponder_stream_name_prefix=

    webrtc_sdp_min_bitrate_bps=3000000
    webrtc_cc_min_bitrate=1000000
    streaming_video_decoder_fast_start=false
    webrtc_cc2_twcc=false
    rtmp_use_stream_params_as_connection=true
    rtmp_appkey_source=app
    keep_alive.enabled=websocket,rtmfp
    record_flash_published_streams=true

    Пытаюсь проиграть через браузер Chrome, используя код из примера для WebRTC. Поток довольно быстро переходит в состояние PLAYING, но секунд 10 ничего не отображается. Потом появляется картинка, но она постоянно замирает на длительные периоды времени (примерно на 10 секунд), после чего проигрывается в очень ускоренном темпе. Возможно, некоторые параметры, которые приведены в конфиге выше влияют на это? Я использовал их для стриминга через сторонний RTMP сервер (публикация из браузера через WebRTC с указанием rtmpUrl), иначе качество картинки было очень низким.
  2. Max

    Max Administrator Staff Member

    Попробуйте в настройках OBS выставить опции x264 ultrafast.
    Возможно стрим идет с B-фреймами в высоком профиле. В результате возникают такие проблемы.
    Про то как определять B-фреймы можно посмотреть здесь.
    Дайте пожалуйста скриншоты настроек OBS - как именно сконфигурирован стрим: разрешение, опции кодирования, и т.д. Попробуем у себя воспроизвести проблему.
  3. Evgenii

    Evgenii New Member

    Попробовал выставить ultrafast, результат тот же (частые замирания).
    Скрин с настройками приложил, разрешение 1920x1080, fps 30.
    С этими настройками в клиентских логах часто вижу следующие предупреждения:
    INFO eoSessionGroup-PROXY - VideoProcessor-996edfd8-24c3-4526-81f9-601b7eb40908 Request K-Frame from far end
    WARN VideoSession - VideoProcessor-996edfd8-24c3-4526-81f9-601b7eb40908 Can't send rtcp video feedback PLI, no support at far end

    Вообще с ultrafast замирания стали реже, но все равно случаются. В момент замирания в логах много раз повторяется WARN выше, после чего следующее сообщение

    RTMP-pool-14-thread-4 Set I-Frame h264CodecConfig - 1920x1080

    И отмирает, до следующего раза.

    Attached Files:

    Last edited: Dec 5, 2019 at 5:56 AM
  4. Max

    Max Administrator Staff Member

    Видимо, OBS долго не присылает ключевой фрейм, и сервер пытается его запросить
    а это сообщение означает, что сервер получил ключевой фрейм.
    Попробуйте в настройках OBS выставить интервал ключевых кадров, отличный от нуля (например, 2 секунды).
  5. Evgenii

    Evgenii New Member

    Выставил интервал в 1 секунду, это помогло, но замирания все равно случаются (довольно часто, раз в 10-15 секунд), но длятся гораздо меньше (около секунды). Возможно есть еще какие-либо идеи как обойтись совсем без замираний?
  6. Evgenii

    Evgenii New Member

    Заметил еще, что при проигрывании с помощью HLS (пример HLS Player в админке) замираний не наблюдается, но там ожидаемо высокая задержка (плюс низкое качество, но это возможно можно исправить).
  7. Max

    Max Administrator Staff Member

    Это и подводит нас к решению. При проигрывании RTMP потоков больших разрешений с соответствующим битрейтом по WebRTC (по умолчанию WebRTC бегает по UDP) проявляются потери, ключевые фреймы могут просто не долетать до браузера, потому он их и запрашивает повторно. В этом случае необходимо играть WebRTC по TCP.
    Установите на стороне сервера настройку
    Code:
    ice_tcp_transport=true
    и попробуйте проиграть поток в примере Media Devices, там есть переключатель Transport
    upload_2019-12-5_14-59-52.png
    При использовании транспорта TCP подфризы должны уйти.

Share This Page