Abstract

This document extends the MOQT Streaming Format (MSF) by registering the "m2ts" packaging value for carrying MPEG-2 Transport Stream and M2TS source packets over Media Over QUIC Transport. It defines catalog fields for transport-stream track description and specifies receiver and relay behavior for joining, switching, and validating packetized streams.¶

About This Document

This note is to be removed before publishing as an RFC.¶

The latest revision of this draft can be found at https://mondain.github.io/msfts/draft-gregoire-moq-msfts.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-gregoire-moq-msfts/.¶

Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/.¶

Source for this draft and an issue tracker can be found at https://github.com/mondain/msfts.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Media Over QUIC Transport (MOQT) [MoQTransport] delivers named tracks as ordered groups of objects. The MOQT Streaming Format (MSF) [MSF] defines a catalog model and common streaming conventions for describing tracks delivered over MOQT. This document extends MSF by registering the "m2ts" packaging value for carrying MPEG-2 Transport Stream packets as defined by [ISO138181] and M2TS source packets that prefix each transport-stream packet with a four-octet source-packet timestamp.¶

The format is intended for publishers that already produce packetized MPEG-2 Transport Stream output, including contribution feeds, broadcast workflows, and systems that currently segment transport streams for HTTP-based delivery. It does not define a new elementary stream container. Instead, it preserves the packet stream and maps consecutive source packets into MOQT Objects.¶

This document describes version 1 of the packaging format.¶

2. MSF Extension

All specifications, requirements, and terminology defined in [MSF] apply to implementations of this extension unless explicitly noted otherwise in this document.¶

This document does not use the LOC packaging defined in [MSF]. MSF requirements that are conditioned on packaging: loc do not apply to m2ts-packaged tracks; equivalent behavior for m2ts tracks is defined in this document.¶

3. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 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.¶

This document uses the conventions detailed in Section 1.3 of [RFC9000] when describing the binary encoding.¶

The following terms are used throughout this document:¶

TS packet:

A 188-octet MPEG-2 Transport Stream packet as defined by [ISO138181].¶

M2TS source packet:

A 192-octet packet consisting of a four-octet source-packet timestamp followed by a 188-octet TS packet.¶

Source packet:

Either a TS packet or an M2TS source packet. The source-packet size is signaled by the catalog.¶

Access unit:

A coded audio, video, or metadata unit carried by the MPEG-2 Transport Stream.¶

Random access point:

A point in the packet stream at which a receiver can begin decoding after receiving the applicable transport-stream tables and decoder initialization.¶

Single-program transport stream:

A transport stream whose Program Association Table lists exactly one program.¶

Multi-program transport stream:

A transport stream whose Program Association Table lists two or more programs.¶

4. Scope

This specification defines:¶

• The "m2ts" packaging value for use in an MSF catalog.¶

• The mapping of consecutive TS or M2TS source packets into MOQT Objects.¶

• Catalog fields that describe packet size, program selection, packetization, timing, and joining behavior.¶

• Receiver processing rules for validating object payloads and reconstructing the packet stream.¶

This specification does not define:¶

• New MPEG-2 Transport Stream syntax.¶

• New audio, video, metadata, or subtitle codec signaling inside the transport stream.¶

• A replacement for Program Association Table, Program Map Table, PCR, PTS, DTS, continuity counter, or scrambling semantics defined by [ISO138181].¶

• A mandatory Adaptive Bitrate (ABR) switching model across separately encoded transport streams.¶

• A key management protocol.¶

6. Catalog

An m2ts track is described by the MSF catalog [MSF]. The catalog track name, delta update rules, variable substitution rules, authorization signaling, and common track fields are inherited from MSF.¶

This document defines additional fields for track objects whose packaging value is "m2ts". A parser MUST ignore fields it does not understand.¶

7. Catalog Examples

The following examples are non-normative.¶

{
  "version": 1,
  "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
    }
  ]
}

{
  "version": 1,
  "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
    }
  ]
}

{
  "version": 1,
  "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
    }
  ]
}

{
  "version": 1,
  "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
    }
  ]
}

{
  "version": 1,
  "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
    }
  ]
}

8. Subscriber Processing

A subscriber obtains the catalog using the MSF catalog workflow and subscribes to one or more m2ts tracks. For each received media Object, the subscriber:¶

1. Validates that the payload length is a non-zero integer multiple of m2tsPacketSize.¶

2. Validates the TS sync byte position for each source packet.¶

3. Reconstructs the packet stream by appending the source packets in MOQT object order.¶

4. Applies normal MPEG-2 Transport Stream demultiplexing, timing recovery, and decoder initialization.¶

If validation fails, the subscriber SHOULD discard the invalid Object and treat the reconstructed packet stream as discontinuous. A subscriber MAY continue processing at the next Object, but it SHOULD wait for a random access point before presenting decoded media.¶

When joining a live track, a subscriber SHOULD start at the newest Group whose first Object is available when m2tsRandomAccess is true. Otherwise, a subscriber SHOULD select a starting Group far enough back to encompass at least one complete PSI repetition cycle before its target presentation time; when m2tsPsiInterval is declared, that value bounds the maximum look-back interval needed. A subscriber MAY use the MSF Media Timeline [MSF] to resolve this time bound to a concrete MOQT Group location for use with a Joining FETCH [MoQTransport]. A subscriber MUST NOT begin media presentation until it has received a valid PAT and PMT for the track.¶

9. Relay Processing

MOQT relays are not required to parse MPEG-2 Transport Stream syntax. A relay can cache, forward, and prioritize m2ts Objects using MOQT namespace, track, Group ID, Object ID, and delivery metadata.¶

Relays MAY discard older Groups according to MOQT cache policy. For live content, when m2tsRandomAccess is true, relays that retain partial Groups SHOULD retain the first Object of each Group; by definition, publishers are required to populate that Object with a random access point together with the PAT and PMT packets needed by joining subscribers.¶

10. Switching and Alternate Renditions

Multiple m2ts tracks can be advertised as alternatives using the MSF altGroup field. Video tracks in the same alternate group MUST place Group boundaries at identical presentation positions; other tracks SHOULD align their Group boundaries to the same positions where possible. All tracks in the alternate group SHOULD set m2tsRandomAccess to true. This ensures that a subscriber can switch between alternate video tracks at any Group boundary without encountering a misaligned access point. A subscriber SHOULD switch between alternate m2ts tracks only at Group boundaries or at transport-stream random access points that it can independently decode.¶

This document does not require continuity counter values or PID assignments to match across alternate tracks. Receivers MUST treat a switch between tracks as a packet-stream discontinuity unless application-specific signaling establishes stronger continuity.¶

A receiver MUST treat a switch between alternate tracks as a PCR discontinuity and MUST re-initialize its system time clock (STC) recovery using the first PCR value received on the new track as the initial reference. In addition to the Group boundary alignment requirements above, publishers providing alternate tracks SHOULD align presentation timestamps at Group boundaries across tracks to enable seamless presentation switching at the application layer. Because PID assignments need not match across alternate tracks, a receiver MUST re-parse the PAT and PMT of the new track after every track switch before routing elementary-stream packets to a decoder.¶

11. Content Protection

This packaging format preserves any scrambling or conditional access information present in the MPEG-2 Transport Stream. Transport-stream scrambling is opaque to MOQT relays and to this specification.¶

Object-level encryption MAY be applied using a mechanism such as MoQ Secure Objects [SecureObjects] when signaled by the catalog. When object-level encryption is used, source packet validation is performed after successful decryption.¶

12. Authorization

Authorization requirements can be advertised using MSF catalog authorization fields. For example, a publisher can use Common Access Token signaling [C4M], Privacy Pass authorization [PrivacyPassAuth], or an application defined authorization scheme.¶

13. Security Considerations

The security considerations of MOQT [MoQTransport], MSF [MSF], MPEG-2 Transport Stream [ISO138181], and any object encryption scheme apply.¶

Receivers need to treat transport-stream syntax as untrusted input. Invalid packet sizes, invalid sync bytes, malformed PSI, inconsistent continuity counters, excessive table repetition, and timestamp discontinuities can cause decoder failures or resource exhaustion if not bounded by implementation policy.¶

Catalog metadata is also untrusted input. Subscribers MUST validate packet sizes, payload lengths, Base64 values, PIDs, program numbers, and object ordering before using the values to allocate memory or configure decoders.¶

Object-level encryption protects MOQT Object payloads but does not hide MOQT namespace, track name, Group ID, Object ID, object size, or delivery timing from authorized relays. Applications that require confidentiality for media payloads SHOULD use an object encryption scheme in addition to transport security.¶

14. IANA Considerations

This document has no IANA actions.¶

If MSF establishes an IANA registry for packaging values, this document requests registration of the value "m2ts" with this document as the reference.¶

15. References

Appendix A. Acknowledgments

This document follows the repository and draft structure used by the MOQT Streaming Format work.¶

Authors' Addresses