Bug 22371 - [MSE] Ogg byte streams
Summary: [MSE] Ogg byte streams
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2013-06-14 23:52 UTC by Greg Maxwell
Modified: 2013-10-11 22:36 UTC (History)
5 users (show)

See Also:

patch to add an ogg bytestream segment (24.36 KB, patch)
2013-06-14 23:52 UTC, Greg Maxwell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Maxwell 2013-06-14 23:52:52 UTC
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.
Comment 1 Aaron Colwell 2013-08-08 00:19:08 UTC
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.
Comment 2 Aaron Colwell 2013-10-04 23:50:21 UTC
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.