981680 - audio/video sync busted in webrtc.org upstream 3.41 update

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[Randell Jesup [:jesup] (needinfo me)]

+++ This bug was initially created as a clone of Bug #964312 +++

> There have been reports of A/V sync issues with TURN (or with TURN TCP due to it being incorrectly selected) in recent weeks.  We need to investigate this.

Ok, while there may be a problem with TURN TCP (so I'm cloning the bug instead of repurposing it), I found that google badly broke a/v sync in 3.41 and did not correct it for some time (and never backported to fix to any stable branch).  While they had a/v sync module tests, they didn't have an end-to-end test until a while after they fixed this bug.

It was broken in Chrome 31 it appears, and the fix did not go out until Chrome 33; it can cause up to 5 seconds of A/V sync mismatch (though 2 seconds would be more common when it happens).  There might be a few cases where video is delivered significantly behind audio where the sync code will delay audio to match up better with video, but this should fix any case where video was leading audio.  We can look at disabling the "delay audio more" case, or limiting it extremely, if needed (it may already be handled reasonably).

It's unclear exactly when A/V would get bad with this bug; this may be where TURN TCP interacts with this bug to make sync go off.  From reports in the webrtc.org issue (2608), this is very bad on a high-loss or long-delay network (and the reporter was recommending Firefox to their users at the time).

The upstream patch applies cleanly and appears to solve the problem; my debugs for a/v offset dropped from hours or days to +- 20ms or so.  I have a smaller patch I did while investigating this before finding the upstream fix which might be acceptable for beta.

We should uplift the main patch here to Aurora asap after landing and basic manual tests.

Issue 2608: https://code.google.com/p/webrtc/issues/detail?can=1&q=2608
Fixed in r5102 landing: https://code.google.com/p/webrtc/source/detail?r=5102

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Upstream webrtc patch for avsync (r5102) rs=jesup

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Upstream webrtc patch for avsync (r5102) rs=jesup

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bf9adc1ce324

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: audio/video sync fix for Beta 28

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bf9adc1ce324

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 8388870 [details] [diff] [review]
Upstream webrtc patch for avsync (r5102) rs=jesup

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Landing of upstream 3.41 in 28

User impact if declined: audio/video sync will not work; webrtc.org reports from developers indicate on iffy networks you can get 2 or even 5 seconds of offset sync.

Testing completed (on m-c, etc.): on m-c, in upstream since Nov 8, in Chrome 33

Risk to taking this patch (and alternatives if risky): almost none.  There's a minimal patch on this bug that doesn't clean up as much (and is a subset of the upstream changes basically).

String or IDL/UUID changes made by this patch: none

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/db6787d76538