[Bug 18602] Unclear requirements for WebM byte streams

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

--- Comment #2 from Philip J <philipj@opera.com> 2012-08-20 08:37:12 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#webm
> > 
> > (One bug for a number of minor issues.)
> > 
> > "Exactly one Segment Information element must appear after the Segment header."
> > "Exactly one Tracks element must appear after the Segment Information element."
> > 
> > It's not clear if this is intended to mean "directly after" or not. Presumably
> > it's OK to have other elements in between.
> 
> 
> How about this:
> "Exactly one Segment Information element must appear after the Segment header.
> Only a single CRC-32 element, one or more Void elements, and/or a single Meta
> Seek Information element may appear between the Segment header and the Segment
> Information Element."
> 
> "Exactly one Tracks element must appear directly after the Segment Information
> element."
> 
> > 
> > "Meta Seek Information, Cues, Chapters, and various Global Elements may follow
> > the Segment header but the contents of these elements will be ignored.
> > Note: This enables the use case where the contents of a WebM file are simply
> > appended without any inspection or reformatting."
> > 
> > "various Global Elements" isn't very clear. Presumable any unknown element
> > should be ignored? "will be ignored" should be "should be ignored" or "must be
> > ignored" to be normative.
> 
> How about this:
> "Meta Seek Information, Cues, Chapters, CRC-32, and Void may follow
>  the Segment header but the contents of these elements must be ignored."

I think that the rules should be such that if we introduce new elements,
implementations of the current rules shouldn't fail. How about requiring that
there must exist a Segment Information element and Tracks element in that
order, and that any other elements before, in between or after are ignored?
Having more checks than that just seems like more code to write and test,
without any obvious benefit... or am I missing something?

> > "If the most recent WebM initialization segment describes multiple tracks, then
> > blocks from all the tracks must be present and interleaved in time increasing
> > order."
> > 
> > This could be read as requiring that blocks for all tracks be included in all
> > segments, which may not be intentional. For text tracks there may simply be no
> > data for a particular segment, and for sufficiently small segments suboptimal
> > muxing could cause the requirement to fail.
> 
> How about this:
> "If the most recent WebM initialization segment describes multiple tracks, then
> blocks from all the tracks must be interleaved in time increasing order. At
> least one block from all audio and video tracks must be present."
> 
> I want to discourage suboptimal muxing as much as possible.

WFM, we can always relax it later if necessary.

> > Finally, for all of these requirements it must be defined what should happen if
> > they are violated, presumably causing a decoding error.
> 
> Oops. Looks like I need to add a step between steps 4 & 5 of append()
> (http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#dom-append)
> 
> How about:
> "5. If data contains invalid or malformed initialization segment or media
> segment information, then run the media element's error handling code to signal
> a MediaError.MEDIA_ERR_DECODE error, and abort these steps."
> 
> Step 5 becomes 6...etc

Looks good, as long as "malformed" is defined as clearly defined as violating
any requirement of the byte stream format specification.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 20 August 2012 08:37:13 UTC