MPEG-2 TS Byte Stream Format

W3C Group Note

More details about this document
This version:
https://www.w3.org/TR/2024/NOTE-mse-byte-stream-format-mp2t-20240723/
Latest published version:
https://www.w3.org/TR/mse-byte-stream-format-mp2t/
Latest editor's draft:
https://w3c.github.io/mse-byte-stream-format-mp2t/
History:
https://www.w3.org/standards/history/mse-byte-stream-format-mp2t/
Commit history
Editor:
Mark Watson (Netflix Inc.)
Former editors:
(W3C Invited Expert) (Until February 2024)
Jerry Smith (Microsoft Corporation) (Until September 2017)
Aaron Colwell (Google Inc.) (Until April 2015)
Adrian Bateman (Microsoft Corporation) (Until April 2015)
Feedback:
GitHub w3c/mse-byte-stream-format-mp2t (pull requests, new issue, open issues)
public-media-wg@w3.org with subject line [mse-byte-stream-format-mp2t] … message topic … (archives)

Abstract

This specification defines a Media Source Extensions™ [MEDIA-SOURCE] byte stream format specification based on MPEG-2 Transport Streams [MPEG2TS].

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

The working group maintains a list of all bug reports that the editors have not yet tried to address; there may also be related open bugs in the GitHub repository of the Media Source Extensions™ specification.

This document was published by the Media Working Group as a Group Note using the Note track.

This Group Note is endorsed by the Media Working Group, but is not endorsed by W3C itself nor its Members.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This specification defines segment formats for implementations of Media Source Extensions™ [MEDIA-SOURCE] that choose to support MPEG-2 Transport Streams [MPEG2TS].

It defines the MIME-type parameters used to signal codecs, and provides the necessary format specific definitions for initialization segments, media segments, and random access points required by the Byte Stream Formats section of the Media Source Extensions™ specification. This document also defines extra behaviors and state that only apply to this byte stream format.

2. MIME-type info

The MIME-type/subtype pair of "video/MP2T", as specified in [RFC3551], MUST be used for byte streams that conform to this specification.

The following parameter can be used in the MIME-type passed to isTypeSupported() or addSourceBuffer().

codecs
A comma separated list of codec IDs used to specify what codecs will be used in the byte stream. Implementations SHOULD accept IDs in the form specified by [RFC6381].
Note
Implementations MAY only implement a subset of the codecs and profiles mentioned in the RFC.

3. General Transport Stream Requirements

MPEG-2 TS media segments and initialization segments MUST conform to the MPEG-2 TS Adaptive Profile [MPEG2TS].

The user agent MUST run the append error algorithm if any of the following conditions are met:

  1. Segments do not contain complete MPEG-2 TS packets.
  2. Segments do not contain complete PES packets and sections.
  3. Segments contain more than one program.
  4. At least one MPEG-2 TS packet has a non-zero transport_error_indicator.

4. Initialization Segments

An MPEG-2 TS initialization segment consists of a single PAT and a single PMT.

The user agent MUST run the append error algorithm if any of the following conditions are met:

  1. A PAT is not present in the initialization segment
  2. A PMT is not present in the initialization segment

The user agent MUST accept and ignore other SI, such as CAT, that are invariant for all subsequent media segments.

The user agent MUST source attribute values for id, kind, label and language for AudioTrack, VideoTrack and TextTrack objects as described for MPEG-2 Transport Streams in the in-band tracks spec [INBANDTRACKS].

5. Media Segments

The user agent MUST run the append error algorithm if any of the following conditions are met:

  1. A media segment relies on initialization information in another media segment.
  2. At least one PES packet does not have a PTS timestamp.
  3. PCR is not present in the Segment prior to the first byte of a TS packet payload containing media data.
The user agent will accept and ignore PSI that is identical to the information in the last initialization segment which may appear repeatedly throughout the segment.

6. Random Access Points

A random access point as defined in this specification corresponds to Elementary Stream Random Access Point as defined in [MPEG2TS].

7. Timestamp Rollover & Discontinuities

Timestamp rollovers and discontinuities MUST be handled by the UA. The UA's MPEG-2 TS implementation MUST maintain an internal offset variable, MPEG2TS_timestampOffset, to keep track of the offset that needs to be applied to timestamps that have rolled over or are part of a discontinuity. MPEG2TS_timestampOffset is initially set to 0 when the SourceBuffer is created. This offset MUST be applied to the timestamps as part of the conversion process from MPEG-2 TS packets into coded frames for the coded frame processing algorithm. This results in the coded frame timestamps for a packet being computed by the following equations:

Coded Frame Presentation Timestamp = (MPEG-2 TS presentation timestamp) + MPEG2TS_timestampOffset
Coded Frame Decode Timestamp = (MPEG-2 TS decode timestamp) + MPEG2TS_timestampOffset

MPEG2TS_timestampOffset is updated in the following ways:

8. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

9. Acknowledgments

The editors would like to thank Alex Giladi, Bob Lund, David Singer, Duncan Rowden, Glenn Adams, Mark Vickers, and Michael Thornburgh for their contributions to this specification.

A. References

A.1 Normative references

[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INBANDTRACKS]
Sourcing In-band Media Resource Tracks from Media Containers into HTML. Silvia Pfeiffer; Bob Lund. W3C. 26 April 2015. Unofficial Draft. URL: https://dev.w3.org/html5/html-sourcing-inband-tracks/
[MEDIA-SOURCE]
Media Source Extensions™. Jean-Yves Avenard; Mark Watson. W3C. 4 July 2024. W3C Working Draft. URL: https://www.w3.org/TR/media-source-2/
[MPEG2TS]
Information technology — Generic coding of moving pictures and associated audio information — Part 1: Systems. ISO/IEC. December 2023. Published. URL: https://www.iso.org/standard/87619.html
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3551]
RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne; S. Casner. IETF. July 2003. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3551
[RFC6381]
The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types. R. Gellens; D. Singer; P. Frojdh. IETF. August 2011. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6381
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174