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
Status: WontFix
Last visit 27 days ago
Closed: Aug 3
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, May 9 2013 Back to list
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, May 13 2013
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, May 13 2013
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, 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, 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, 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, May 20 2013
No, this is code path is currently only active for Mac, where it works as expected.
Project Member Comment 7 by, Jun 7 2014
Ronghua, please comment on what might need to be done here.
Comment 8 by, 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. 

Project Member Comment 9 by, 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, 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, Jun 12 2014
Labels: Mstone-38 Area-Internals
SGTM, let's target this for M38.
Comment 12 by, Jun 12 2014
Labels: Timestamp
Comment 13 by, Jun 12 2014
Labels: -Timestamp Timestamps
Comment 14 by, Jul 25 2014
Labels: -Mstone-38
Status: Untriaged
Assign to Magnus for reassign.
Project Member Comment 15 by, Jul 26 2014
Status: Assigned
Project Member Comment 16 by, 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, Aug 3
Status: WontFix
Sign in to add a comment