Video freezes after multiple upgrade/downgrade when on audio call
Reported by
manjuks1...@gmail.com,
Mar 16 2018
|
||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36 Steps to reproduce the problem: 1. We have an internal webrtc app and we initiated 1-1 audio call 2. Upgrade the call to video and after few seconds downgrade to audio call 3. Repeat step 2 couple of times from one peer. Video and audio are good 4. Repeat step 2 from another peer. When the other peer upgrades to video, video freezes on the remote side What is the expected behavior? Both video and audio should be fine What went wrong? Video freezes and observed packet loss increasing steadily and bitsSentPerSecond also decreases. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 65.0.3325.162 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Mar 19 2018
,
Mar 20 2018
manjuks1991@ Thanks for the issue. Request you to provide the URL where this issue can be reproduced, which will help in further triaging. Thanks..
,
Mar 20 2018
susan - the application is internal for now and cannot be shared. If required we can provide any requested traces
,
Mar 21 2018
Creating a dump from chrome://webrtc-internals might help? Not sure.
,
Mar 21 2018
Nevermind, I see you already did.
,
Mar 21 2018
What APIs are involved in the steps to repro the problem?
,
Mar 26 2018
Hi hbos, What APIs are we looking for here? If it is standard WebRTC APIs, then below are the APIs used - 1. navigator.getUserMedia 2. webrtc's createOffer/createAnswer 3. setLocalDescription/setRemoteDescription Please let us know if you are looking for information on any specific API
,
Mar 26 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 26 2018
This could be a race between setRemoteDescription() and addStream()/addTrack(), a deadlock in WebRtcMediaStreamTrackAdapterMap. I've identified a problem with regards to another bug (813574).
You could see if the problem goes away if you to a setTimeout(() => {...}, 0); to delay adding the track to avoid the race.
,
Mar 27 2018
Hi hbos, We tried wrapping stream addition logic inside setTimeOut() with a delay of 0. This does not seem to work. We still observe the video freeze issue after 3-4 consecutive video upgrades
,
Mar 27 2018
Thank you! On second though I don't think 0 is enough. Can you try with a larger delay like 500? If this is a duplicate of https://crbug.com/813574 we should merge the fix into M65 as well.
,
Mar 27 2018
Assuming this does not also delay the setRemoteDescription() logic so that there is a period of time between addTrack/addStream and setRemoteDescription.
,
Mar 27 2018
,
Apr 2 2018
Hi hbos, We tried to delay adding the track/stream in promisified createAnswer() function, this results in losing the audio and video still freezes after 3-4 upgrade attempts. Additionally, we also tried with lesser delay (250ms) and there is no change in behavior.
,
Apr 5 2018
Hi, can you check if this is this still reproducible in latest Canary which has a fix for a similar problem? |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by krajshree@chromium.org
, Mar 19 2018