[Bug 21333] consequences of requirement in section 8 on initialisation segments

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21333

--- Comment #12 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #11)
> (In reply to comment #9)
> > I don't believe this should be a goal for v1. The existing spec is already
> > particularly taxing for existing media engines and I believe that this will
> > just add another huge amount of work that isn't really needed right now. I
> > think this is a "nice to have" not a "must have". If content providers & ad
> > providers decide not to unify their content, then that is a choice, but like
> > any choice there are consequences. I feel like we already have allowed much
> > more change then the current HTML5 spec allows so I think we should wait and
> > see how the things we've speced out so far pan out before adding something
> > like this.
> 
> i think a very common use case will involve ads from ad providers that will
> be multiplexed video and english-only audio (and no captions), and primary
> content with separated video and audio, with audio in multiple languages,
> and caption tracks in multiple languages.  video engines would already have
> to support being reconfigured on the fly under Javascript control. having it
> be automatic solves the problem once properly, decreases complexity for the
> JS programmer, and improves the user experience.

I think this is a bad idea. Ad providers won't do this if we don't let them. I
don't think this will simplify things. You would still have to provide mappings
for how the selected tracks change over time. This mapping would be
particularly fragile if the application allowed any sort of access to the video
element xxxTracks lists. Allowing track count & type changes within a
SourceBuffer also open a can of worms with reguard to how to map tracks with
eachother across these boundaries. 

I also think you are overestimating how many SourceBuffers initial
implementations of MSE are going to allow. The UAs have the ability to reject
SourceBuffer creation and will likely do so based on the limitations of the
existing media engines. Ad providers should not assume that they can just
create as many SourceBuffers as they want.

I think we should stick with the existing restrictions for v1, get some
implementation experience, and then see if it still makes sense to loosen the
restrictions to allow this sort of stuff in.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 26 March 2013 21:23:25 UTC