Simulcast causes lipsync problem
Reported by
selenkar...@gmail.com,
Jan 27 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36 Steps to reproduce the problem: 1.Enable native simulcast 2.Start Conference 3.Jitter Buffer and Current Delay increases suddenly. It is up to 2500 ms 4.Change the simulcast type to Simple Simulcast which basically gets two streams with webkitGetUserMedia. One for low quality, one for high quality. 5.Refresh the session. 6.Jitter Buffer and Current Delay is around 150 ms which is not disturbing Codec is VP8. What is the expected behavior? Not to have lipsync problem What went wrong? lipsync problem Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.76 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0 As far as I understood from the below discussion, jitter buffer should not be increased this much, " > How does Chrome handles clock drift between the sender and the receiver? This is handled by the jitter buffers and associated time-warping done to avoid jitter buffer buildup. Basically, the mechanisms for an adaptive jitter buffer as a side-effect will compensate for clock drift between sender and receiver. " https://groups.google.com/forum/#!topic/discuss-webrtc/ZS4W4ZKbrKM Codec is VP8. Regards, Selen
,
Jan 29 2017
,
Jan 30 2017
Adding TE-NeedsTriageHelp label as it seems to be out of TE-scope.
,
Jan 30 2017
Owner of the component will triage.
,
Feb 1 2017
sprang@: Can you take a look? Please triage further or bounce back to me if necessary.
,
Feb 18 2017
Hi Sprang, Are there any information that you need in order to investigate further? Regards,
,
Feb 20 2017
I have not seen this issue before. Can you give some details on how you enable simulcast? +philipel, is there any issue you are aware of from a jitter buffer perspective?
,
Feb 20 2017
We make choice of simulcast method configurable in terms of our client. If it is configured as native. We use chrome's native simulcast method.
,
Feb 20 2017
sprang@, M56 does not use the new jitter buffer and there are no issues with the current jitter buffer that I'm aware of.
,
Feb 20 2017
What's the receiving client on the other side? Another chrome or something else? Could you provide a log file?
,
Feb 21 2017
Both sides are Chrome. I will provide the chrome_debug.log but it is too large to attach. Where else can I transfer the file for you?
,
Feb 21 2017
Hm, upload to drive maybe? So on the receiver end, are you receiving and displaying multiple resolutions at the same time..?
,
Mar 13 2018
sprang@: Is this bug still valid? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pucchakayala@chromium.org
, Jan 28 2017