Issue metadata
Sign in to add a comment
|
WebRTC stop playing remote video when resolution changes
Reported by
dias.be...@gmail.com,
Nov 7 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/62.0.3202.75 Chrome/62.0.3202.75 Safari/537.36 Steps to reproduce the problem: 1. Connect to WebRTC video source 2. Got the live stream from video source 3. Set live stream to chrome video player 4. Change live stream resolution on the live stream source side What is the expected behavior? Live video and audio still playing What went wrong? Live video stop playing. If dynamicaly return start live stream resolution on the live stream source side - it continue playing. If refresh browser page - it continue playing in new resolution. Did this work before? Yes 61.0.3163 Does this work in other browsers? Yes Chrome version: 62.0.3202.75 Channel: stable OS Version: Kubuntu Linux 17.04 Flash Version:
,
Nov 9 2017
FYI: Codec video h264 and audio opus
,
Nov 9 2017
I'm not able to repro this. Can you give more details on the exact steps for reproducing? Also, using the chrome://webrtc-internals page, can you check where the frames are block when this happens? Ie, is it the input framerate, encode framerate or send framerate on the send-side, or is it something corresponding on the receive-side?
,
Nov 9 2017
When playing: googFrameRateDecoded 26 googFrameRateOutput 27 googFrameRateReceived 27 When changed resolution and stopped playing video: googFrameRateDecoded 1 googFrameRateOutput 1 googFrameRateReceived 27 Will try later today share with you platform to reproduce.
,
Nov 9 2017
To reproduce: 1) Goto https://www.wowza.com/_private/webrtc/4.7.0/play/ 2) Set SDP URL: wss://dev-wowza2.wwl.tv/webrtc-session.json Application Name: live Stream Name: c22_transcode 3) Press play. The resolution of the stream will change every 10-15 seconds Thank you
,
Nov 10 2017
Interesting. Yes, I can repro using your steps, thanks! Looks to me like a jitter buffer issue. brandtr@ / ssilkin@ you've done some work there recently, can you triage further?
,
Nov 10 2017
There is issue in SPS/PPS tracker. It always inserts out-of-band headers before IDR. When resolution changes decoder first receives new SPS/PPS and then ones from SDP. If headers have same IDs, and this is the case, decoder uses wrong SPS/PPS and fails to decode frames.
,
Nov 10 2017
There is issue in SPS/PPS tracker. It always inserts out-of-band headers before IDR. When resolution changes decoder first receives new SPS/PPS and then ones from SDP. If headers have same IDs, and this is the case, decoder uses wrong SPS/PPS and fails to decode frames.
,
Nov 10 2017
Will it be fixed?
,
Nov 13 2017
Yes, it will be fixed. As a workaround, I can suggest removing in-band SPS/PPS from SDP on server/sender or receiver side.
,
Nov 13 2017
,
Nov 13 2017
Sorry, I meant "...removing OUT-OF-band SPS/PPS". Another way to avoid this issue is to follow https://tools.ietf.org/html/rfc6184 that recommends to use different IDs for out-of-band and in-band parameters set (see 8.4).
,
Nov 15 2017
Thank you! |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Nov 8 2017