[Bug 18933] Segment byte boundaries are not defined

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

--- Comment #3 from Mark Watson <watsonm@netflix.com> 2012-09-20 18:08:45 UTC ---
(In reply to comment #2)
> For Chrome, the current definitions we used are:
> 
> - Initialization Segment is a complete 'moov' box. Start is signaled by the
> 'moov' header, end is signaled by getting the number of bytes signaled in the
> 'moov' header.

There may be other boxes ahead of the moov. ftyp, styp for example, that should
be considered part of the Initialization Segment (even if you do not use them).

> 
> - Media Segments begin with a 'moof' box header. Once the header is received,
> the furthest extent of the media data referenced in that 'moof' may be
> calculated. The end of the media segment is considered the end of the 'mdat'
> atom containing the furthest byte referenced by the 'moof'.
> 
> This avoids any heuristics about e.g. number of 'mdat' atoms per segment, while
> still being able to identify the end of a media segment at the actual end of
> that segment, instead of waiting for extra data like a new box header or an
> explicit EOS.
> 
> (Under Mark's proposal, the 'sidx' atom would be considered the start of an
> initialization segment. Since DASH Live profile typically uses a new 'sidx'
> atom in front of every 'moof', this would break, since an initialization
> segment must contain a 'moov'.)

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.

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

-- 
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 18:08:48 UTC