This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(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
(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.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/340786fcae83
Verified, the changes fix the reported problems.