W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

[Bug 20901] New: contiguous splice/append without knowing media segment internal timestamps

From: <bugzilla@jessica.w3.org>
Date: Thu, 07 Feb 2013 23:59:14 +0000
To: public-html-media@w3.org
Message-ID: <bug-20901-5436@http.www.w3.org/Bugs/Public/>

            Bug ID: 20901
           Summary: contiguous splice/append without knowing media segment
                    internal timestamps
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: mthornbu@adobe.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

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

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.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 7 February 2013 23:59:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:32 UTC