MPEG-2 Transport Stream Packaging for Media Over QUIC Transport

5.1. Object Payload Format

The payload of each media Object is:¶

+===============+===============+=====+===============+
| source packet | source packet | ... | source packet |
+===============+===============+=====+===============+

The packet size is signaled by m2tsPacketSize (Section 6.2). The payload length of every media Object on an m2ts track MUST be an integer multiple of m2tsPacketSize.¶

If m2tsPacketSize is 188, every source packet MUST begin with the MPEG-2 TS sync byte 0x47. If m2tsPacketSize is 192, the TS packet begins four octets after the start of each source packet and the octet at that position MUST be 0x47. A receiver MUST treat a packet that fails this validation as invalid media data for that track.¶

The source packets from received Objects are concatenated in ascending Group ID and Object ID order to reconstruct the packet stream. A subscriber that skips or fails to receive an Object MUST consider the reconstructed packet stream discontinuous at that point until it reaches a subsequent random access point.¶

5.2. Object Boundaries

Object boundaries are packaging boundaries and do not change MPEG-2 Transport Stream semantics. Continuity counters, adaptation fields, PCR, PTS, DTS, Program Specific Information (PSI), and other transport-stream syntax remain inside the source packets.¶

A publisher MUST NOT modify the continuity counter of any source packet, and MUST NOT remap packet identifiers when forwarding a source transport stream. Either modification silently breaks program decoding or conditional access at the receiver.¶

A publisher SHOULD place an independently usable random access point at the first media Object of each MOQT Group. For single-program video tracks, this normally means that the Group begins at or before the transport-stream packets carrying a random access point and includes the PAT and PMT packets required for program demultiplexing. Codec-level initialization data is carried inside the elementary stream packets of the first video access unit and is therefore present whenever a random access point is included.¶

When m2tsRandomAccess (Section 6.10) is true, the first media Object in every Group MUST provide a valid random access starting point for the Group.¶

5.3. Group Numbering

For live streams, publishers SHOULD start a new MOQT Group at each point where the Group content is independently decodable without reference to prior Groups. For video, a valid Group start is any intra-coded access point at which all decoder references needed by that Group are present within the Group itself. Instantaneous Decoder Refresh (IDR) frames always satisfy this condition. A Clean Random Access (CRA) frame MAY serve as a Group start only if no subsequent Random Access Skipped Leading (RASL) pictures in that Group reference frames from a prior Group. Publishers are not required to start a new Group at every intra-coded access point: a CRA whose following RASL pictures reference only frames present earlier in the same Group may remain interior to that Group. The Object ID MUST increase by one for each Object within a Group unless MOQT delivery semantics permit gaps that are explicitly intended by the publisher.¶

For video-on-demand (VOD) streams, Group ID and Object ID assignment SHOULD be stable for a given asset so that relays and subscribers can cache and request repeatable ranges.¶

5.4. Packetization

Publishers SHOULD choose Object sizes that are large enough to amortize MOQT object overhead and small enough to avoid excessive head-of-line delay at the application layer. The number of source packets per Object can vary, but a publisher SHOULD keep it stable within a track unless adapting to network or encoder conditions.¶

If m2tsPacketsPerObject is present, it declares the usual number of source packets per media Object. The final Object of a Group MAY contain fewer source packets. Receivers MUST use the actual Object payload length rather than assuming every Object has the declared size.¶

5.5. Multi-Program Source Handling

When a publisher receives a multi-program transport stream (MPTS), it may either produce a separate m2ts track for each program by filtering the source, or carry the complete multiplex transparently by setting m2tsMpts (Section 6.13) to true.¶

When the source is already a single-program transport stream, a publisher MAY carry it without filtering. The source Program Association Table already lists exactly one program, so no PAT rewrite is required. Null packets and any service information tables present in the source MAY be retained. The per-program catalog fields m2tsProgramNumber, m2tsPmtPid, and m2tsPcrPid SHOULD be present to identify the carried program. A subscriber receiving such a track MAY forward it downstream without modification, since the stream has not been derived from a larger multiplex and is complete as received.¶

A publisher deriving per-program tracks from an MPTS source SHOULD filter the source packets so that each track contains only:¶

• Null packets with Packet Identifier (PID) 0x1FFF, which MAY be removed or retained at the publisher's discretion.¶

• Program Association Table packets (PID 0x0000), rewritten to list only the program present in this track.¶

• Program Map Table packets for the selected program (whose PID is listed in the Program Association Table entry for that program).¶

• All packets whose PID is listed in the Program Map Table of the selected program, including the PCR_PID and the PIDs of all elementary streams.¶

Removing null packets changes the inter-packet byte spacing that constant-bit-rate receivers use to recover the mux clock. A subscriber wishing to reconstruct a constant-bit-rate output stream cannot derive the original rate from the stream alone; publishers that remove null packets SHOULD declare the source mux rate using m2tsMuxRate (Section 6.8).¶

These rules apply to unscrambled transport stream sources. Publishers filtering scrambled transport streams MUST also retain the conditional access packets required for descrambling; conditional access integration is application-specific and outside the scope of this document.¶

The Program Map Table references only the PIDs of the selected program's elementary streams and PCR; it does not reference the service information (SI) tables defined by Digital Video Broadcasting (DVB) and the Advanced Television Systems Committee (ATSC): Network Information Table (NIT, 0x0010), Service Description Table and Bouquet Association Table (SDT/BAT, 0x0011), Event Information Table (EIT, 0x0012), and Time and Date Table with Time Offset Table (TDT/TOT, 0x0014), or their ATSC Program and System Information Protocol (PSIP) equivalents. The filter therefore drops these tables, leaving the resulting track without service identity, Electronic Program Guide (EPG), or broadcast time. Publishers producing tracks for broadcast or Integrated Receiver Decoder (IRD) reception SHOULD retain the SI tables required by the target standard. When SI tables are retained, publishers SHOULD declare the additional PIDs using m2tsSiPids (Section 6.9) so that subscribers can verify which tables are present. Because SDT and EIT carried from an MPTS describe all programs in the multiplex, publishers SHOULD filter or rewrite these tables to include only the service and schedule entries for the carried program; NIT and TDT/TOT are broadcast-wide and do not require per-program rewriting.¶

The m2tsProgramNumber field (Section 6.4) SHOULD be present on per-program tracks to identify the program carried. When multiple per-program tracks are derived from the same MPTS source, the publisher SHOULD use the MSF altGroup field if the programs are alternate renditions of the same content; programs that are independent services SHOULD be published as separate tracks.¶

A publisher MAY instead carry the complete multi-program transport stream without program selection or PID filtering, by setting m2tsMpts (Section 6.13) to true. In this mode, all source packets from the multiplex are emitted without PAT rewrite. Because no per-program filtering occurs, MOQT serves only as a scalable transport layer; per-track program subscription, per-program catalog fields, and the subscriber join behavior defined in this document do not apply. When m2tsMpts is true, m2tsProgramNumber, m2tsPmtPid, and m2tsPcrPid MUST be absent.¶

Group boundary placement for m2tsMpts tracks depends on whether the publisher can identify random access points across the multiplex: if it can, it MAY align Group boundaries to those points and set m2tsRandomAccess to true; otherwise it SHOULD start a new Group after a fixed number of Objects.¶

5.6. PCR and Timing

The Program Clock Reference (PCR) is carried inside adaptation fields of transport-stream packets as defined by [ISO138181]. MOQT Object and Group boundaries are packaging boundaries and do not alter PCR continuity within a track.¶

A publisher MUST NOT introduce a PCR discontinuity within a single MOQT Group. A publisher that introduces a PCR discontinuity between consecutive MOQT Groups MUST signal it by setting the discontinuity_indicator bit (ISO 13818-1 Section 2.4.3.5) in the adaptation field of the first TS packet carrying PCR in the new Group.¶

Note: Hardware IRDs recover the mux clock from the rate at which PCR-bearing packets arrive, not only from their encoded values. MOQT does not guarantee that Object delivery preserves the inter-packet timing of the source stream. Deployments targeting such receivers should account for this constraint and may require a rate-controlled egress that re-paces packets according to the source mux rate.¶

Note: The 33-bit PCR base field wraps around after approximately 26.5 hours of continuous stream time. For long-running live streams this is a normal event; receivers should handle it as a continuous timeline continuation rather than a discontinuity. Receivers that use the MSF Media Timeline [MSF] for playout timing can rely on its monotonic wall-clock abstraction independently of PCR wrap-around.¶

5.7. Splice Signaling

SCTE-35 splice information is carried transparently in the TS stream as splice_info_section() messages on their designated PID. Publishers MAY surface splice events via the MSF Event Timeline [MSF]. This document does not specify SCTE-35 processing.¶

6.1. Track Object Fields

Table 1 lists the m2ts-specific fields defined within a track object.¶

Use of the MSF initRef and initDataList fields by m2ts tracks is described in Section 6.14.¶

6.2. M2TS Packet Size

Required: Yes JSON Type: Number Location: Track Object¶

The source-packet size in octets. The value MUST be either 188 or 192. A value of 188 identifies ordinary MPEG-2 TS packets. A value of 192 identifies M2TS source packets with a four-octet timestamp prefix followed by a 188-octet TS packet.¶

6.3. M2TS Packets per Object

Required: Optional JSON Type: Number Location: Track Object¶

The usual number of source packets carried by each media Object. This field is advisory. Receivers MUST validate each Object using its actual payload length.¶

6.4. M2TS Program Number

Required: Optional JSON Type: Number Location: Track Object¶

The MPEG-2 Transport Stream program number carried by this track. When present, the track SHOULD carry packets from only that program. When absent and m2tsMpts is not true, subscribers MAY select a program using local policy or transport-stream signaling. This field MUST be absent when m2tsMpts is true.¶

6.5. M2TS PMT PID

Required: Optional JSON Type: Number Location: Track Object¶

The packet identifier carrying the Program Map Table for m2tsProgramNumber. This field is advisory and does not replace the Program Association Table or Program Map Table carried in the transport stream. It MUST be absent when m2tsMpts is true.¶

6.6. M2TS PCR PID

Required: Optional JSON Type: Number Location: Track Object¶

The packet identifier carrying the Program Clock Reference for the program identified by m2tsProgramNumber. This field is advisory and does not replace PCR signaling in the transport stream. It MUST be absent when m2tsMpts is true.¶

6.7. M2TS PSI Interval

Required: Optional JSON Type: Number Location: Track Object¶

The maximum interval, in milliseconds, at which the publisher expects the Program Association Table and Program Map Table to repeat in the packet stream. For single-program tracks, publishers SHOULD repeat PSI at an interval no larger than this value for live content. For m2tsMpts tracks, the publisher does not control PSI injection; when present, this field describes the source multiplex PSI repetition rate and is advisory only. Subscribers MAY use this value to estimate join latency in both modes.¶

6.8. M2TS Mux Rate

Required: Optional JSON Type: Number Location: Track Object¶

The nominal source mux rate of the transport stream in bits per second. This field is advisory. A subscriber reconstructing a constant-bit-rate output stream MAY use this value to restore the original mux rate when null packets have been removed.¶

6.9. M2TS SI PIDs

Required: Optional JSON Type: Array Location: Track Object¶

The packet identifiers of SI tables retained in the filtered track, in addition to those listed in the Program Map Table. This field is advisory. Publishers SHOULD include this field when they retain DVB or ATSC SI tables. Subscribers MAY use this list to verify which service information tables are present without inspecting the packet stream.¶

6.10. M2TS Random Access

Required: Optional JSON Type: Boolean Location: Track Object¶

When true, the first media Object in every MOQT Group provides a valid random access starting point for the Group. When absent or false, subscribers MUST inspect the transport-stream payload to determine where decoding can begin.¶

6.11. M2TS Timestamp Mode

Required: Optional JSON Type: String Location: Track Object¶

For 192-octet source packets, this field identifies the interpretation of the four-octet source-packet timestamp. The value "arrival-time" indicates an arrival-time or emission-time stamp associated with the following TS packet. The value "opaque" indicates that the timestamp prefix is carried without specified semantics. This field MUST NOT be present when m2tsPacketSize is 188.¶

6.12. M2TS SCTE-35 PID

Required: Optional JSON Type: Number Location: Track Object¶

The PID carrying SCTE-35 splice_info_section() messages for this track. This field is advisory; SCTE-35 messages are also discoverable via the PMT conditional access or registration descriptor. When present, receivers MAY use this value to locate splice events without parsing PMT. Publishers SHOULD include this field when the track carries SCTE-35 splice signaling.¶

6.13. M2TS MPTS

Required: Optional JSON Type: Boolean Location: Track Object¶

When true, this track carries a multi-program transport stream without program selection or PID filtering. m2tsProgramNumber, m2tsPmtPid, and m2tsPcrPid MUST be absent when this field is true.¶

6.14. Use of MSF Initialization Data

The initRef track field and the root initDataList field are defined by MSF; they are not fields defined by this extension. An m2ts track MAY use those fields to carry initialization data. The track sets initRef to the id of an initDataList entry whose type MUST be "inline". The Base64 [BASE64] decoded value of the entry's data field MUST be a sequence of whole source packets using the packet size declared by m2tsPacketSize.¶

Publishers SHOULD include current PAT and PMT packets in the referenced initialization data when those tables are not guaranteed to be available at the first Object of each Group. When PSI changes within a live track, the publisher SHOULD publish an updated initialization data entry in a new independent catalog before publishing media Objects that rely on the changed PSI. An update to the root initDataList MUST NOT be expressed as an MSF delta update. Receivers MUST NOT assume that referenced initialization data remains valid after the MPEG-2 PSI version_number changes; updated PSI in media Objects takes precedence.¶

For m2tsMpts tracks, producing referenced initialization data requires extracting the PAT and all program PMTs from the source multiplex. Publishers that do not inspect the source stream typically omit initRef and the corresponding initDataList entry; subscribers will encounter PSI within one PSI repetition cycle regardless of Group boundaries.¶

7.1. Live 188-octet Transport Stream

{
  "version": "draft-01",
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "program-1-ts",
      "namespace": "live.example.com/channel/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 6000000,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsProgramNumber": 1,
      "m2tsPmtPid": 256,
      "m2tsPcrPid": 257,
      "m2tsPsiInterval": 100,
      "m2tsRandomAccess": true
    }
  ]
}

7.2. Live 192-octet M2TS Source Packets

{
  "version": "draft-01",
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "program-1-m2ts",
      "namespace": "contribution.example.net/feed/a",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 500,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 12000000,
      "m2tsPacketSize": 192,
      "m2tsPacketsPerObject": 32,
      "m2tsProgramNumber": 1,
      "m2tsTimestampMode": "arrival-time",
      "m2tsRandomAccess": true
    }
  ]
}

7.3. VOD Transport Stream

{
  "version": "draft-01",
  "tracks": [
    {
      "name": "asset-main",
      "namespace": "vod.example.com/assets/1000",
      "packaging": "m2ts",
      "isLive": false,
      "trackDuration": 632000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 4500000,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 96,
      "m2tsProgramNumber": 1,
      "m2tsRandomAccess": true
    }
  ]
}

7.4. Multi-Program Source - Per-Program Tracks

This example shows a catalog for a publisher that receives a 2-program transport stream and publishes each program as a separate m2ts track. The two tracks share a namespace but are independent services; altGroup is not used because the programs carry different content.¶

{
  "version": "draft-01",
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "program-1",
      "namespace": "live.example.com/mux/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 6000000,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsProgramNumber": 1,
      "m2tsPmtPid": 256,
      "m2tsPcrPid": 257,
      "m2tsPsiInterval": 100,
      "m2tsRandomAccess": true
    },
    {
      "name": "program-2",
      "namespace": "live.example.com/mux/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 4000000,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsProgramNumber": 2,
      "m2tsPmtPid": 512,
      "m2tsPcrPid": 513,
      "m2tsPsiInterval": 100,
      "m2tsRandomAccess": true
    }
  ]
}

7.5. Transparent MPTS Carriage

This example shows a catalog for a publisher that carries a complete multi-program transport stream without program selection, so no per-program catalog fields are present. The m2tsPsiInterval field is included as an advisory hint; its value is not normative for MPTS tracks.¶

{
  "version": "draft-01",
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "mux-1",
      "namespace": "live.example.com/mux/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "mimeType": "video/mp2t",
      "bitrate": 20000000,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsMpts": true,
      "m2tsPsiInterval": 100
    }
  ]
}

7.6. ABR Alternate Renditions - Two Bitrate Tracks

This example shows a catalog for a live channel published at two bitrates as alternate renditions. Both tracks are in the same altGroup; video tracks MUST align Group boundaries at identical presentation positions. The tracks use different PID assignments: a subscriber switching between them MUST re-parse PAT and PMT on the new track before routing packets to a decoder.¶

{
  "version": "draft-01",
  "generatedAt": 1746104606044,
  "tracks": [
    {
      "name": "video-high",
      "namespace": "live.example.com/channel/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 6000000,
      "altGroup": 1,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsProgramNumber": 1,
      "m2tsPmtPid": 256,
      "m2tsPcrPid": 257,
      "m2tsPsiInterval": 100,
      "m2tsRandomAccess": true
    },
    {
      "name": "video-low",
      "namespace": "live.example.com/channel/1",
      "packaging": "m2ts",
      "isLive": true,
      "targetLatency": 1000,
      "role": "video",
      "mimeType": "video/mp2t",
      "bitrate": 2000000,
      "altGroup": 1,
      "m2tsPacketSize": 188,
      "m2tsPacketsPerObject": 64,
      "m2tsProgramNumber": 1,
      "m2tsPmtPid": 512,
      "m2tsPcrPid": 513,
      "m2tsPsiInterval": 100,
      "m2tsRandomAccess": true
    }
  ]
}

14.1. Normative References

[BASE64]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[ISO138181]

ISO/IEC, "Information technology - Generic coding of moving pictures and associated audio information: Systems", ISO/IEC 13818-1, 2023.

[MOQTransport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-19, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-19>.

[MSF]

Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, 2 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-msf-01>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

14.2. Informative References

[C4M]

Law, W., Lemmons, C., Simon, G., and S. Nandakumar, "Authorization scheme for MOQT using Common Access Tokens", Work in Progress, Internet-Draft, draft-ietf-moq-c4m-01, 18 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-c4m-01>.

[PrivacyPassAuth]

Nandakumar, S., Jennings, C. F., and T. Meunier, "Privacy Pass Authentication for Media over QUIC (MoQ)", Work in Progress, Internet-Draft, draft-ietf-moq-privacy-pass-auth-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-privacy-pass-auth-03>.

[SecureObjects]

Jennings, C. F., Nandakumar, S., and R. Barnes, "End-to-End Secure Objects for Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-secure-objects-01, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-secure-objects-01>.