- From: <bugzilla@jessica.w3.org>
- Date: Thu, 07 Feb 2013 23:59:14 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901 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 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 7 February 2013 23:59:15 UTC