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

Issue 687860 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug


Previous locations:
webrtc:7074


Sign in to add a comment

Native Simulcast causes lipsync problem

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

Issue description

What steps will 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

What is the expected result?
Not to have lipsync problem

What do you see instead?
lipsync problem

Regards,
Selen

What version of the product are you using? On what operating system?
Windows 7-10, Chrome 56.0.2924.76

Please provide any additional information below.
Please see the attachment for receiving endpoint webrtc stats.


 
native_simulcast_lipsync_problem.xlsx
248 KB Download
Codec is VP8.
Components: Audio
Labels: OS-Windows
Components: -Audio
Moving to Chromium bug tracker.
Project: chromium
Moved issue webrtc:7074 to now be  issue chromium:687860 .
Components: Blink>WebRTC>Audio
Owner: sprang@chromium.org
Status: Assigned (was: Unconfirmed)
sprang@: can you take a look? perhaps this is a duplicate of a previous bug.
Cc: sprang@chromium.org
Owner: philipel@chromium.org
Is this a regression you've observed only recently?
+philipel, you did some timing changes for the new jitter buffer, right?
Cc: philipel@chromium.org peah@chromium.org
Owner: ----
Status: Unconfirmed (was: Assigned)
I haven't done any recent changes to the timing for the current jitter buffer, only for the new jitter buffer (which is not in use yet).

Also, this is Chrome 56, so it includes no recent changes from webrtc. I guess one way to find out when this regression occurred is to bisect the 56.0.2924.X versions of chrome.

I guess someone in the audio team might want to look at this, +peah, do you know someone we can assign it to?

Comment 9 by tommi@chromium.org, Mar 11 2017

Owner: peah@chromium.org
Status: Assigned (was: Unconfirmed)
Assigning to peah@ as per comment #8.

Comment 10 by peah@chromium.org, Mar 12 2017

Cc: hlundin@chromium.org
hlundin@: Do you know of any changes in the jitter buffer timing that could have caused this?
Labels: Needs-Feedback
Owner: hlundin@chromium.org
Thanks for reporting!

I'm going to need some more information to be able to debug this. I don't understand your setup. Can you provide an example of how you are calling the APIs? 

As an alternative, an RtcEventLog recorded on the receiver would be helpful. Go to chrome://webrtc-internals, expand the "Create Dump" section, and check "Enable diagnostic packet and event recording". Upload to this bug, or share the file with me directly.
Also, does it reproduce with newer versions of Chrome?
Status: WontFix (was: Assigned)
Closing due to lack of feedback. Feel free to provide the requested feedback and reopen.

Sign in to add a comment