This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
2.1 Attributes, activeSourceBuffers "activeSourceBuffers of type SourceBufferList, readonly Contains the subset of sourceBuffers that are providing the selected video track, the enabled audio track(s), and the "showing" or "hidden" text track(s)." The order of entries in the SourceBufferList are underspecified. Intuitively, activeSourceBuffers should have the same order as sourceBuffers, but a naive implementation may order them depending on what SourceBuffer reached a "Add the SourceBuffer to activeSourceBuffers" step first.
Why does order matter here? I don't particulary object to mandating that the order match sourceBuffers, but I don't really understand why it matters. Won't the application always have to manually inspect the lists if sourceBuffers.length != activeSourceBuffers.length? Why let the application treat the == case differently?
(In reply to Aaron Colwell from comment #1) > Why does order matter here? Well, honestly, because WebKit's implementation fails some of the proposed W3C Media Source testsuite tests which expect a particular order. Specifically, the mediasource-buffered.html will fail if the order of activeSourceBuffers is not the same as sourceBuffers.
Also, the general trend toward array-like objects in W3C specs, and particularly in the Text Track specs, has been to give those arrays an explicit, deterministic order.
Ok. Fair enough. I'll make the change. Thanks for your input.
Change committed. https://dvcs.w3.org/hg/html-media/rev/13056a200b38