[Bug 18933] Segment byte boundaries are not defined

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

--- Comment #4 from Steven Robertson <strobe@google.com> 2012-09-20 19:02:03 UTC ---
(In reply to comment #3)
> Whilst DASH allows you to distribute sidx boxes around the file, I would expect
> them to be parsed by the script - in order to find the positions of the media
> segments - and not passed to the Media Source.

Sure, that's common for VOD, but for the typical case in live media, each live
DASH segment (sidx-moof-mdat*) is provided at a separate URL, which serves as
sufficient framing and thus removes the requirement for the app to parse the
media. In this case, I would suggest that implementors anticipate receiving
(and ignoring) 'sidx' atoms.

> You could apply the rules I suggested (or those rules together with your rule
> about moof box references) with the assumption that unrecognized boxes,
> including sidx, are ignored by the UA. 

Agreed! Chrome's implementation ignores every recognized top-level apart from
'moov', 'moof', and 'mdat'. (It rejects any top-level not defined in any
version of 14496-12, since we've found it very difficult for authors to track
down the source of framing errors on append without that.)

> So if you get <box> <box> <box> <moov>
> (where <box> is an unrecognized box or sidx) you consider the "first box" to be
> the moov.

IIUC: you're suggesting that for the purposes of avoiding adding a fourth
conceptual parse state ('parsing something which is neither an initialization
nor a media segment', in addition to 'parsing an initialization segment',
'parsing a media segment', and 'not parsing anything / at a parse-frame
boundary'), consider unrecognized boxes to be a prefix of the init/media
segment that they precede? If so, I agree here as well.

(I'm less a fan of suffixes, since for a hypothetical parser that did not do
incremental parsing and instead waited for complete media segments, and a
hypothetical app that only appended complete segments, a full extra segment
would be required before data would be visible.)

-- 
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 Thursday, 20 September 2012 19:02:04 UTC