This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18602 - Unclear requirements for WebM byte streams
Summary: Unclear requirements for WebM byte streams
Status: VERIFIED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Aaron Colwell (c)
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-17 13:31 UTC by Philip Jägenstedt
Modified: 2012-08-23 08:28 UTC (History)
3 users (show)

See Also:


Attachments

Description Philip Jägenstedt 2012-08-17 13:31:15 UTC
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.

"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.

"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.

Finally, for all of these requirements it must be defined what should happen if they are violated, presumably causing a decoding error.
Comment 1 Aaron Colwell (c) 2012-08-17 20:27:15 UTC
(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."

> 
> "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.

> 
> 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
Comment 2 Philip Jägenstedt 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.
Comment 3 Aaron Colwell (c) 2012-08-22 23:37:19 UTC
Changes committed.
http://dvcs.w3.org/hg/html-media/rev/340786fcae83
Comment 4 Philip Jägenstedt 2012-08-23 08:28:52 UTC
Verified, the changes fix the reported problems.