[Bug 17072] New: Define behavior for a break in contiguous appending

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

           Summary: Define behavior for a break in contiguous appending
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: acolwell@chromium.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Currently the text in the spec says that media segments can be appended in any
order but it doesn't outline any way to signal that a non-contiguous append is
going to happen. The initial thinking was that the media segment starting
timestamp would provide enough information to detect this automatically. 

Our work on updating the Chromium implementation has revealed that this is only
true if you always know the exact duration of the media segment and the
duration of the last blocks in the segment for each track. This is not the case
for WebM, at least, given our current definitions for that format. Typically no
duration information is stored in the cluster and block durations are
determined by computing the difference between adjacent blocks. There is a way
in WebM to specify block durations, but there is no requirement for the last
block in the cluster to supply this information. 

Non-contiguous appends can throw off this block duration calculation logic. An
append for data earlier in the timeline can be detected, but requires dropping
the last blocks in the previous cluster because we won't get the blocks from
the next contiguous cluster to compute their duration. Appending data for a
point later in the timeline can cause incorrect block duration calculations
because the UA has no way to differentiate this new segment from the one that
is actually the next contiguous one. 

This problem raises several questions:
1. Can this happen in ISO BMFF or other formats we might want to support?
2. How should we signal that a discontinuity is happening?
3. Should the WebM section be updated to mandate duration information on the
last frames? This requirement would likely exclude discontiguous appends on a
majority of current WebM content.
4. Should we restrict the situations where non-contiguous appends can occur?

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Saturday, 19 May 2012 10:34:56 UTC