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

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Aug 2017
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Clock drift between Chrome and WebRTC's clock implementation on Windows

Project Member Reported by justinlin@chromium.org, May 9 2013 Back to list

Issue description

The clock implementation in WebRTC and Chrome seem to drift apart sometimes and never sync up again. The Clock implementations should be made consistent for capture timestamps to be used.
 

Comment 1 by holmer@google.com, May 13 2013

Cc: mflodman@webrtc.org
First we should fix the issue where the offset in the webrtc clock on Windows is wrong, as we are currently generating incorrect timestamps. Next we should align the clocks used by Chrome and WebRTC.

There are a couple of options for aligning:
1. Inject an implementation of webrtc::Clock from Chrome to WebRTC.
2. Use the same clock implementation in WebRTC as in Chrome, possibly copying/syncing the source files.

I personally would prefer 1), and that is something we have been aiming at doing. What do you think?
Project Member

Comment 2 by justinlin@chromium.org, May 13 2013

Cc: justinlin@chromium.org hclam@chromium.org
Owner: stefan@webrtc.org
I think #1 is the better option as well. I briefly tried to do #2 as a quick fix, but it was pretty hairy.

Stefan, assigning to you because you might be a better person to figure out the WebRTC API for this?


Also, I think the same should be done for audio as well if possible. By driving both from the same clock created in Chrome, we can probably better align the capture timestamps for the screencapture case since we have access to video playing information in Chrome, and it should be possible to figure out which audio sample each frame is associated to.

Comment 3 by juberti@google.com, May 13 2013

Agree regarding #1. We may need to do the same for libjingle as well (in base/timeutils.h), so that all parts of the system share a common clock.
Project Member

Comment 4 by stefan@webrtc.org, May 20 2013

Heads up that this is unlikely to get into M29. We should prioritize or reassign if we think it's important.

Comment 5 by ddo...@gmail.com, May 20 2013

Would this be the cause of a long-running videoconference session where it seems like the peer slowly gets further and further 'behind' you (similar to the delay you'd see on TV with news reporters across the world being several seconds behind in discussion?).  If so, IMO this is a pretty big bug and needs to be fixed before anyone can really use WebRTC in the real world as a 'high quality' videoconference substitute for those costly proprietary systems (that being said, does the clock drift occur on the encoding side or the playback side?)
Project Member

Comment 6 by stefan@webrtc.org, May 20 2013

No, this is code path is currently only active for Mac, where it works as expected.
Project Member

Comment 7 by juberti@webrtc.org, Jun 7 2014

Owner: wu@webrtc.org
Ronghua, please comment on what might need to be done here.

Comment 8 by wu@webrtc.org, Jun 11 2014

Based on the injection approach discussed previously, we will need a way to switch the default clock implementation for libjingle and webrtc. I'm not sure what's the best way to do that.

We probably don't want to change all the code to use an injected clock, so one solution can be a global clock pointer that we can modify from chrome. But then we will have synchronization problem between the read and write of the clock pointer. 

Thoughts?
Project Member

Comment 9 by stefan@webrtc.org, Jun 11 2014

I'd still prefer to add the possibility to inject a clock to webrtc. We should at least get an understanding of how much work it would be. A global clock pointer sounds very brittle.
Project Member

Comment 10 by mflodman@webrtc.org, Jun 11 2014

Agree about prefering to inject a clock.

We can inject a clock in the RTP module today, not wired up through Video Engine though, and we could focus on injecting a clock where needed for this task. I don't think that should be too much work, even though it's touching a lot of the code.

Comment 11 by wu@webrtc.org, Jun 12 2014

Labels: Mstone-38 Area-Internals
SGTM, let's target this for M38.

Comment 12 by wu@webrtc.org, Jun 12 2014

Labels: Timestamp

Comment 13 by wu@webrtc.org, Jun 12 2014

Labels: -Timestamp Timestamps

Comment 14 by wu@webrtc.org, Jul 25 2014

Labels: -Mstone-38
Owner: mflodman@webrtc.org
Status: Untriaged
Assign to Magnus for reassign.
Project Member

Comment 15 by tnakamura@webrtc.org, Jul 26 2014

Status: Assigned
Project Member

Comment 16 by tnakamura@webrtc.org, Nov 4 2015

This bug hasn't been modified for more than a year. Is this still a valid open issue?
Project Member

Comment 17 by mflodman@webrtc.org, Aug 3 2017

Status: WontFix

Sign in to add a comment