This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the language used to indicate that tracks in a MediaStream needs to be synchronized doesn't not carry much normativeness: "All tracks in a MediaStream are intended to be synchronized when rendered". I think there should be a conformance requirement that the user agent MUST keep tracks of a given MediaStream synchronized when rendering them. This has probably also some impact on MediaStream consumer if we resolve bug #22260
This is a difficult problem to address with strong normative language. For local playback, it's a no-brainer, but once the tracks traverse a network it's less clear-cut. In some cases it's better to let audio/video desync rather than suffer glitches, which tend to be more noticeable. Furthermore, some tests have indicated that synchronization imposes delays that have a negative affect on user perception. That is, the delays are worse than a little synchronization drift. Of course, applications that don't want synchronization could put MediaStreamTracks in separate MediaStreams, but that allows for unconstrained drift. That leaves me with the conclusion that it should be up to browsers to determine how they want to synchronize tracks.
I agree to Martin (and I think "All tracks in a MediaStream are intended to be synchronized when rendered" catches that pretty well).
OK, fair enough; should this be closed then?
(In reply to comment #3) > OK, fair enough; should this be closed then? Yes, that's at least my view.
While the intent of the current text is sufficient, it probably isn't enough information for an implementer to understand all the ramifications of the statement. We could expect that implementations will do the right thing, but it might be better to expand on that statement rather than just leave it lie. Dom isn't the only person who is likely to ask the question regarding conformance. I don't think that this sounds right, but something along these lines might be appropriate: "While the intent is to synchronize tracks, it could be better in some circumstances to permit tracks to lose synchronization. In particular, when tracks are remotely sourced and real-time (see WebRTC), it can be better to allow loss of synchronization than to accumulate delays or risk glitches and other artefacts. Implementations are expected to understand the implications of choices regarding synchronization of playback and the effect that these have on user perception."
I suggest that we take Martin's proposed text and insert it as a "NOTE" in section 4.1 (the only place we mention synchronization).
Harald's proposal seem straightforward. Assigning to Adam (to do the actual edit).
Proposed fix: https://github.com/fluffy/webrtc-w3c/commit/b71d87032a84ea46ca207b653495050e3622ee8f
Fixed in http://dev.w3.org/2011/webrtc/editor/archives/20140507/getusermedia.html