MoQ MPEG-TS Catalog Extension

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 28 March 2027.¶

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. 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 [mpeg2] terminology for PID, PSI, PAT, PMT, PES, descriptor, section, and stream_type, and [hang] terminology for broadcast, track, group, and frame.¶

A verbatim track carries an elementary stream the publisher did not decode, byte-for-byte.¶

2. Introduction

A transport stream reaches MoQ in one of two shapes. A publisher can leave the multiplex intact and carry the packet stream as opaque payload, which is what [msfts] specifies. Or it can demultiplex, which is what this document addresses: each elementary stream becomes its own MoQ track with a codec description, so a relay can drop and prioritize per track and a subscriber can decode without a transport-stream parser (Section 3).¶

Demultiplexing loses everything that is not media: the PID layout, the PMT descriptors, the program identity, the service information, and any stream the publisher has no decoder for. The mpegts section records that. It defines no packaging and no container: decoded media keeps the container its catalog entry declares, and verbatim tracks use the framing in Section 5.¶

3. Comparison with m2ts Packaging

[msfts] carries the transport stream as it arrives: each object is a run of whole 188- or 192-byte packets, and the receiver demultiplexes as it always has. This document takes the stream apart at the publisher and discards the packetization layer, because MoQ already provides what it was there for:¶

• Packet framing interleaves elementary streams onto one serial pipe. MoQ delivers each track separately.¶

• Null packets pad a multiplex to a constant bitrate. There is no bitrate to pad to.¶

• The PCR distributes the multiplex's timebase. Each track carries its own timestamps.¶

• Continuity counters detect loss within a stream. That is the transport's job.¶

• PSI repetition lets a receiver join mid-stream. The catalog is a track a subscriber fetches on join.¶

What remains is media in a codec-neutral catalog, plus the signaling a demultiplexer cannot reconstruct: that is the mpegts section.¶

The two overlap only on program identity: m2tsProgramNumber and m2tsPmtPid against Section 4.3, and m2tsPsiInterval against a per-PID interval (Section 4.4). They do not collide, since those members sit on a track and this section sits at the root. A track is one shape or the other.¶

4. The mpegts Section

A publisher that demultiplexed a transport stream SHOULD add an mpegts root member to its catalog (Section 6):¶

type Mpegts = {
  "tracks": Map<TrackName, Track> | undefined,
  "programDescriptors": Descriptor[] | undefined,
  "program": Program | undefined,
  "si": Map<PidString, Si> | undefined,
  "muxRate": number | undefined,
}

Every member is optional and a publisher MUST omit an empty one, so a broadcast with nothing to record omits the section entirely.¶

type Track = {
  "pid": number,
  "descriptors": Descriptor[] | undefined,
  "verbatim": Verbatim | undefined,
}

type Program = {
  "transportStreamId": number,
  "programNumber": number,
  "pmtPid": number,
}

type Si = Map<TableIdString, SiEntry>

type SiEntry = {
  "track": string,
  "interval": number | undefined,
}

type Descriptor = {
  "tag": number,
  "data": string,
}

5. Verbatim Tracks

An elementary stream the publisher does not decode rides its own MoQ track, byte-for-byte:¶

type Verbatim = {
  "streamType": number,
  "framing": "pes" | "section",
  "streamId": number | undefined,
}

streamType is the PMT stream_type to re-announce: 0x86 for SCTE-35 [scte35], 0x06 for private PES, 0x05 for private sections.¶

framing says how the payload is framed, defaulting to "pes". With "pes" each frame is one complete PES payload, timestamped with its PTS, or 0 if it carried none. With "section" each frame is one complete section, header and CRC included, timestamped with the media time it arrived at. A consumer MUST refuse a catalog that names a framing it does not recognize, rather than guess.¶

streamId is the original PES stream_id, for example 0xBD (private_stream_1) for teletext, DVB subtitles, and DVB AC-3. It applies only to "pes" framing. A publisher SHOULD record it, since strict demultiplexers reject a relabeled PES; a consumer with none falls back to private_stream_1.¶

Each frame MUST be a keyframe in its own group: a verbatim payload is all-or-nothing.¶

A verbatim track has no codec, dimensions, or decoder configuration, so a publisher MUST NOT describe it as a media rendition and MUST describe it only by its tracks entry. Nothing there declares a container, so its frames use hang's legacy container ([hang]): a varint microsecond timestamp followed by the payload.¶

6. Carriage

The section is the same JSON in either catalog format.¶

7. Rebuilding a Transport Stream

A consumer rebuilding a transport stream:¶

• MUST place each track on its recorded pid, and MUST assign an unused PID to a track with none.¶

• MUST put the PMT on program.pmtPid and build the PAT and PMT from program.¶

• MUST re-emit each track's descriptors as its ES-level descriptors, and programDescriptors as the PMT's program_info.¶

• MUST re-emit each si entry's sections byte-for-byte on that entry's PID, reading them from its track (Section 4.5.1), at least as often as its interval when declared.¶

• MUST repacketize each verbatim track per its framing and streamType, using streamId when recorded.¶

• SHOULD pad the output with null packets to muxRate when present, so the rebuilt stream is constant-rate again; a source that exceeds the rate is passed through rather than delayed or dropped.¶

With no program the consumer synthesizes an identity, and SHOULD then omit any carried si, which describes a program that no longer exists.¶

A consumer MAY derive implied signaling: a program carrying a section-framed 0x86 stream and no programDescriptors implies the SCTE-35 CUEI registration descriptor. A consumer MUST NOT derive one that contradicts a recorded descriptor.¶

8. Security Considerations

Every binary field here is re-emitted without inspection, by a publisher that never parsed it and a relay that never looked, so a consumer MUST treat all of it as untrusted input.¶

Nothing bounds the number of entries in the section, nor the size of an SI track: a publisher controls both, and an EPG is large by nature. A consumer MUST bound what it accepts of each, and MUST reject a catalog it cannot bound rather than truncate it into a stream that silently differs from what was described. PIDs, program numbers, and stream types are 13-, 16-, and 8-bit values in a JSON document that can hold any number, so a consumer MUST range-check each one. A catalog can also name one PID twice, so a consumer MUST NOT emit a stream in which two elementary streams share a PID, or in which an SI table shares a PID with PAT, PMT, null packets, or an elementary stream.¶

The section makes a broadcast's provenance legible to anything that can read the catalog, relays included: the service name, provider, and network inside the carried SI, and the original PID layout. A publisher that does not want that MUST omit the section.¶

9. IANA Considerations

This document requests no registrations.¶

Should [msf] establish a registry of catalog root members, this document requests registration of mpegts with this document as the reference.¶

10. References

Appendix A: Example

A broadcast demultiplexed from a DVB transport stream: video and audio described as ordinary renditions, a verbatim SCTE-35 stream, and the source's SDT Actual (table_id 0x42 on PID 0x0011) carried opaquely on its own track.¶

{
  "mpegts": {
    "program": {
      "transportStreamId": 4660,
      "programNumber": 1,
      "pmtPid": 100
    },
    "programDescriptors": [
      { "tag": 5, "data": "Q1VFSQ==" }
    ],
    "tracks": {
      "video0": { "pid": 257 },
      "audio0": {
        "pid": 258,
        "descriptors": [ { "tag": 10, "data": "ZW5nAA==" } ]
      },
      "0.ts": {
        "pid": 500,
        "verbatim": { "streamType": 134, "framing": "section" }
      }
    },
    "si": {
      "17": {
        "66": { "track": "si/17/66", "interval": 2000 }
      }
    }
  }
}

Appendix B: Changelog

Acknowledgments

This document was drafted with the assistance of Claude, an AI assistant by Anthropic.¶

Author's Address