Carrying real MPEG-TS over MoQ

1Start with the installed base

MoQ is designed¹ for live media distribution over QUIC². Its relay layer does not need to understand codecs, ad markers or television standards. That is a strength: the network can fan out media without becoming a media appliance.

The application layer still has to meet the source. In broadcast, that source is often MPEG-TS delivered over IP, ASI or SDI-connected infrastructure. It has PAT and PMT tables, independent elementary PIDs, timing, cue messages and ancillary services accumulated across decades of standards and equipment.

PR #1587 established the upstream MPEG-TS import/export bridge for H.264, H.265 and AAC. That is the modern, web-friendly case. The next question is whether the same architecture can carry the feeds operators actually have, without requiring a plant-wide codec migration first.

2What a real feed contains

We inspected a live MPEG/IP multicast service coming from a Kyrion with a Sencore MRD. It was not an exotic archive. It was an ordinary television feed:

An importer that recognizes only H.264, H.265 and AAC cannot represent most of this service. The network is not the limitation. The missing piece is an application mapping for each component.

3WebCodecs changes playback, not transport

A browser player normally decodes MoQ media with WebCodecs³. WebCodecs commonly exposes H.264, VP8, VP9, AV1, Opus and AAC; H.265 support remains platform-dependent. It does not provide a general MPEG-2 or AC-3 decoder.

The wrong conclusion is that MoQ therefore cannot carry legacy broadcast. MoQ transports bytes and timing; WebCodecs only determines what one class of consumer can render. The implication is blunt: if the downstream consumer is a browser, the legacy codecs must be transcoded, and MoQ carries the already-transcoded renditions; if the consumer is broadcast gear, you have more options, including touching nothing at all. A broadcast receiver can subscribe to the original rendition while a browser subscribes to a transcoded one.

4One model, fidelity per track

The system becomes simpler when MPEG-TS is treated as a collection of timed components rather than one indivisible file. In the per-track path, each selected component becomes a MoQ track and gets the treatment appropriate to its downstream consumer.

This is not a generic untyped data bucket inside the base media catalog. The base catalog remains focused on video and audio. The merged catalog API lets applications extend the root to describe their own tracks; PR #1617 defined the SCTE-35 section that uses it, while the track payload retains the source bytes required for faithful egress.

That separation is useful beyond broadcast. The MoQ layer provides delivery. The application defines what a track means. A relay does not need SCTE-35 logic any more than it needs to understand a video codec.

5Three useful paths through the same system

Demux and transcode

Split the transport into tracks and create web-compatible renditions where necessary. This gives browsers low-latency playback and lets them select only the tracks they can decode.

Demux and remux

Split the transport for MoQ delivery, preserve selected tracks verbatim, then reconstruct MPEG-TS at the destination. This supports SDI or decoder output while retaining per-track routing and fan-out inside the network.

Opaque whole-TS passthrough

Opaque whole-TS passthrough is technically achievable with the current MoQ primitives. Carry the complete transport stream as one opaque track. This is the maximum-fidelity fallback and the least useful representation for a browser. It remains valuable when the only requirement is transporting an existing service unchanged.

These are not competing architectures. Whole-TS passthrough is the limit case where every component stays inside one opaque track. The per-track bridge gives up some simplicity in exchange for routing, adaptation and multiple consumer types.

6What exists today

The upstream work now has three distinct layers:

7Why SCTE-35 comes next

SCTE-35⁴ is small in bandwidth and large in operational consequence. It identifies splice opportunities, arrives ahead of the intended splice point, and often has to survive a complete import, network and remux path before a downstream device acts on it.

The safe foundation is the complete splice_info_section. A structured event can always be parsed from those bytes. The exact original section cannot always be reconstructed from a simplified event model. Carrying the section verbatim therefore preserves both present-day MPEG-TS round trips and future structured consumers.

That implementation exposed the questions that generic media demos rarely encounter: SCTE-35 uses private sections rather than PES, its PID is identified through CUEI signaling, sections cross TS packet boundaries, continuity loss requires resynchronization, and the frame timestamp represents arrival on the program timeline rather than the splice time encoded inside the cue.

8Does this scale? Yes

A fair question: SCTE-35 is one data type, but a real transport stream carries far more (closed captions, teletext, subtitles, AFD, timecode, KLV metadata, interactive carousels). Does the per-track verbatim model reach all of it? It does, because broadcast data sorts into three buckets by how it travels, and the bucket decides the effort. The first two are the verbatim pattern we already built; the third rides along verbatim for broadcast gear too, and needs extra work only to render it in a browser.

If we extend it, in priority order:

1. SMPTE 2038: highest value for the lowest effort. It is PES-based (reuses the existing path), carried verbatim, and in a single PID it hauls CC, AFD, SCTE-104 and timecode opaquely for remux to TS. The architecture applies directly: reuse the PES reader, route to a verbatim data track. The best next brick.
2. CEA-608/708 captions: ubiquitous and FCC-mandatory. For a broadcaster they cost nothing: they ride verbatim, and a caption-aware transcode (e.g. ffmpeg a53cc) keeps them in the new SEI; only a naive transcoder drops them. The one place they need lifting into a separate timed-text track is the browser, because WebCodecs can't read in-band SEI. That extraction is a nice-to-have web feature, not a transport requirement.
3. Everything else (SCTE-27, DSM-CC, DVB subtitles/teletext, KLV, ID3): more of the same per-track verbatim pattern, cheap, added on demand by market or vertical rather than speculatively.

9Where this goes, and why it beats a slide

The path forward is incremental, and it is driven by one question: who consumes downstream?

• Today: broadcast-first, our priority at EDIS Interactive. The base bridge is merged; SCTE-35 ingest is merged upstream (PR #1617); egress is in review in PR #1685. A real TS already maps onto MoQ tracks.
• When the content is already web-friendly (H.264 + AAC), bound for TS gear. The easy case, and exactly what PR #1587 already does: the codecs need no transcode, so one set of renditions serves a browser and modern TS gear alike. A web-compatible feed headed to TS gear behaves just like a web client, with the remux to TS as the only extra step.
• When the egress is the web. Add MPEG-2/AC-3 demux plus an on-the-fly transcoder (H.264/Opus). This is new work, but the rendition model already accommodates it, and the ffmpeg-next encode library is already a workspace dependency (it backs another tool, moq-boy), so the building block is on hand.
• When the egress is TS gear. Demux + remux extended to MPEG-2/AC-3 (per-track egress in PR #1685, byte-exact round-trip validated on synthetic and real captures) if you also want web renditions in parallel; or opaque whole-TS passthrough (a separate PR; byte-identical by design, not yet implemented) for broadcast-only egress.

A note on the landscape. The ad-insertion conversation is real and welcome: at the IETF MoQ interim (Boulder, February 2026), Synamedia and Akamai demonstrated SGAI signaling over MoQ⁵, modeling SCTE-35 as structured events on a dedicated Event Timeline track. That is the ad-decisioning layer, presented as ongoing work. We work one layer down: faithfully carrying real transport streams onto MoQ. Their work addresses how ad cues are represented and consumed; ours preserves the broadcast source those applications depend on. Our focus is staying compatible with the mechanisms the industry already runs on.

And the stakes here are MoQ's, not only ours. A protocol that ingests only what a modern web encoder emits leaves the existing broadcast plant (and the millions of dollars already sunk into it) on the far side of a wall no operator will pay to climb. Meeting the widest range, legacy included, is how MoQ earns the broadcast industry, and that is exactly what we are building.

The same pattern can be extended further. Dreaming beyond what is built today: GStreamer bindings could let existing plant pipelines hand off to MoQ with minor retooling; a WebAssembly decoder in the browser could open MPEG-2 and AC-3 without a server-side transcoder, since the original track is already on the wire and a WASM player would subscribe to it like any other consumer. Transcoding becomes a requirement only when a legacy consumer cannot handle the source, not the toll every path pays. None of it is a fixed roadmap, and that is the point.

Engineering report for technical reference. Upstream status is current as of June 11, 2026 and may change. Measurements describe one observed broadcast service and are illustrative, not normative. Codec, container and standards names are used for identification.