New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 686039 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Simulcast causes lipsync problem

Reported by selenkar...@gmail.com, Jan 27 2017

Issue description

UserAgent: 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
 
native_simulcast_lipsync_problem.xlsx
248 KB Download
Cc: jansson@chromium.org
Looping in WebRTC TE to assign it accordingly for further verification as we do not have the setup at our end to verify the issue.

+ jansson@


Labels: Prestable-56.0.2924.76 Needs-Triage-M56
Labels: -Needs-Triage-M56 TE-NeedsTriageHelp
Adding TE-NeedsTriageHelp label as it seems to be out of TE-scope.
Owner of the component will triage.
Owner: sprang@chromium.org
Status: Assigned (was: Unconfirmed)
sprang@: Can you take a look? Please triage further or bounce back to me if necessary.
Hi Sprang,

Are there any information that you need in order to investigate further?

Regards,

Comment 7 by sprang@chromium.org, Feb 20 2017

Cc: philipel@chromium.org
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?
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.

sprang@, M56 does not use the new jitter buffer and there are no issues with the current jitter buffer that I'm aware of.
What's the receiving client on the other side? Another chrome or something else?
Could you provide a log file?
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?
Hm, upload to drive maybe?

So on the receiver end, are you receiving and displaying multiple resolutions at the same time..?
sprang@: Is this bug still valid?

Sign in to add a comment