W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2012

[Bug 18933] Segment byte boundaries are not defined

From: <bugzilla@jessica.w3.org>
Date: Thu, 20 Sep 2012 16:37:30 +0000
Message-Id: <E1TEjko-0005Ug-E5@jessica.w3.org>
To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18933

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #1 from Mark Watson <watsonm@netflix.com> 2012-09-20 16:37:30 UTC ---
(In reply to comment #0)
> As far as I can tell, the MSE spec is not clear on how to determine where a
> segment ends. Since append() does not necessarily deliver complete segments, we
> need to be able to determine the size in bytes of both init and media segments
> based on the data provided by append().
> 
> With ISO BMFF, we currently assume that the last byte in an init segment is the
> last byte in the moov box, implying that an init segment will never have any
> other top-level boxes after the moov box.
> 
> For media segments, we assume that the last bytes is the last byte in the
> segment's last mdat box (we expect that the segment contains exactly as many
> mdat boxes as there are traf boxes inside the segment's moof box, one for each
> track). 
> 
> Since this is just guesswork, I think the spec should explicitly state how to
> determine init and media segment boundaries, for all possible container
> formats.

I think for ISO BMFF it is sufficient to define how the beginning of a segment
is detected - this implicitly signals the end of the preceding segment.

I propose that the beginning of a media segment is signalled by moof box header
and the beginning of an Initialization segment is signalled by any box header
which is not moof or mdat.

-- 
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 16:37:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:33 UTC