This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
some media formats, such as Apple's HTTP Live Streaming (HLS), do not include information about the internal timestamps of media segments in the format's index/manifest files (.m3u8 in the HLS case). the HLS semantic is that media segments are contiguous in their listed order, and timestamps are used only for media track synchronization within a continuity era. continuity eras are delimited by a discontinuity indicator in the manifest file (.m3u8 in this case). the current Media Source Extensions specification requires the application to know the internal media timestamps of media segments in order to position the segments in the time line. this information is unnecessary in the simple (linear contiguous append) case and, as stated above, may not be readily available without parsing the media segments themselves. there should be a way to perform at least a simple append of media segments into the decoder buffer for contiguous linear playback without knowing the internal media segment timestamps, while maintaining cross-track synchronization even when there are media stream/track discontinuities. a suggested solution is to provide an indicator to abort() to signal "beginning of next segment is aligned to timestampOffset". in the case of MPEG-2 Transport Streams, this would modify the calculation of MPEG2TS_timestampOffset at abort() and the following append; other media types would require the definition of a similar timestamp shift facility. this suggested solution may not be sufficient to maintain synchronization across multiple tracks when they are being appended separately. further study and discussion is required.
Changes committed. https://dvcs.w3.org/hg/html-media/rev/dcd406812201
I'm reopening this bug based on the discussion on the call: http://www.w3.org/2013/04/09-html-media-minutes.html#item04 The result of the change to fix this bug is that out-of-order appends are prohibited without calling abort(). We've observed that this results in needing to commonly call abort before each fragment is appended, which is unnecessary for some formats. It seems like a solution to the discontinuity issue ought to be needed only when using a format that has this characteristic. Prototyping support for this feature broke all our tests for ISO BMFF. We don't have a concrete proposal for how to solve this but wonder if something can be added to the appendXXX() methods so that applications using formats that need to deal with discontinuity can indicate whether the append is a continuation. For formats that contain timestamp data, this should not be needed.
both of the current "AbortMode"s are useful, and required for appending discontinuous media broken into separate files, for example separated video and audio. one would use "continuation" with one sequence (say, video) to establish what the new timestamps are, and use "timestampOffset" with the other sequence(s) (say, audio) after discovering what the timestampOffset is from the first sequence, to keep all sequences synchronized by their timestamps. without this capability and just the equivalent of "continuation", the separate sequences could go out of sync if they don't start all at exactly the same timestamp (which might easily be the case for separated video and audio tracks). how about keeping the current AbortMode optional parameter for abort(), but allow out-of-order appends without calling abort for all media containers which can reasonably accommodate this, and for situations where you want the discontinuity behavior for formats like ISO BMFF? it might only be necessary for MPEG-2 TS. the behavior for abort() when called with no parameters should have been the same as before the AbortMode parameter was added.
Discussed in F2F meeting - agreement that we want to make a change here. Editors will discuss and come up with a proposal that removes the overhead from applications that only deal with formats that don't need this capability. We still want to support this for formats like TS.
For the record, here is the discussion of the new proposal on public-html-media http://lists.w3.org/Archives/Public/public-html-media/2013May/0000.html
Changes committed https://dvcs.w3.org/hg/html-media/rev/9ff5e42736b6