This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1372 [details] patch to add an ogg bytestream segment Ogg already fits pretty naturally in the Media Source extension model— and a number of things that need to be additionally specified for other container types are just the normal mandatory mode of operation for Ogg (at some cost for non-streaming usage)... But it would still probably be helpful to have an Ogg bytestream segment in the specification. I've attached an attempt at adding this in unified diff format.
Here are my initial comments on the proposed text: - The text needs to be reworded in terms of UA behavior like the other sections were reworded to resolve Bug 22117 - I think Section 12.4.2 bullet 2 is unnecessarily restrictive and would prevent out-of-order appends. Why is it needed? - I think skeleton headers should be required at the beginning of initialization segments so that init segments w/o any intervening media segment can't accidentally be interpretted as one larger this initialization segment. - I think there should be a restriction that preskip == preroll or that the max of these 2 values will always be used for formats like Opus. It is pretty easy for out of order appends and applying timestamp offset adjustments can obscure whether preskip or preroll sample dropping should be applied. In MSE there is no easy way to determine if a page was originally the first one in an Ogg file. - I don't really understand what 12.4.3 is trying to convey. Perhaps a definition or link to what "sparse random access points" means would be helpful. It would also be nice to outline what other possible RAP types there are. - I think Section 12.4.4 could use more detailed text. At a minimum references to RAP related text for the most popular codecs in Ogg would be helpful. As it is, I don't feel the section is very helpful. Aside from these changes, I think we should use Ogg as an opportunity to define how additional bytestream specs should be written and setup some sort of registry for bytestream specifications. Everyone trying to get their favorite format into the spec, just won't scale. I welcome definitions of new formats for MSE, but I think we need to find a home for them outside the MSE spec and just provide a link to the registry. The current formats in the spec could also be moved to this registry. They were only included in the spec originally to give people concrete examples of how MSE could be used with existing formats and get everyone on the same page so that they all implemented MP4, WebM, or MPEG2-TS support the same way. Establishing a registry was briefly discussed on the June 25th Media TF telecon(http://lists.w3.org/Archives/Public/public-html-media/2013Jun/0031.html) and the participants on the call were supportive of this suggestion.
I've filed Bug 23441 for establishing the bytestream format registry. Part of resolving that bug will include defining processes for submitting new bytestream formats to the registry. You can use that process to get Ogg support specified. I'm closing this as WONTFIX because we'll be moving all bytestream format specs out of the MSE spec. A bug about adding Ogg to the MSE spec is no longer appropriate. Once the registry process has been defined feel free to register Ogg.