- From: <bugzilla@jessica.w3.org>
- Date: Wed, 16 May 2012 00:07:30 +0000
- To: public-html@w3.org
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