Skip to content

feat(moq-mux): opaque MPEG-TS carriage lane (byte-faithful, no demux) for contribution / IRD hand-off #1861

Description

@t0ms

Summary

Add a second, opaque MPEG-TS lane that carries the transport stream byte-for-byte (no demux, no re-mux), alongside the existing media-aware lane (#1842). This is Option B from #1799 and the only path that delivers true contribution / IRD-grade fidelity.

Why

The media-aware lane (#1815/#1842/#1843) is now faithful at the codec + ancillary-PID level: a real broadcast feed round-trips with all elementary streams and original PIDs intact and a correct DTS timeline (verified on main @ 6893b1c4). But because it re-originates the mux on egress, it inherently cannot preserve what an IRD/MVPD relies on:

  • SI / SDT — service name, provider, service type (round-trip drops CNNI EMEA HD / Warner Bros. Discovery / type 0x19 to (unknown) / 0x00).
  • Constant mux rate — PCR-locked CBR + stuffing. The re-mux is VBR-ish; tsanalyze can't even derive a stable bitrate.
  • PCR cadence / jitter budget as transmitted, PMT PID, EIT/TDT/TOT/NIT, CC continuity counters, scrambling / CAS (CW, ECM/EMM), and MPTS (multiple services).

For satellite replacement the customer expectation is "the bytes I send are the bytes the IRD receives." Only an opaque lane meets that.

Proposed design

  • A packaging mode that treats the inbound TS as an opaque, fixed-size-chunk byte stream on a single MoQ track (e.g. 188-byte-aligned packet runs grouped on a cadence), with a catalog packaging marker (m2ts / ts-opaque) so consumers know it's whole-mux carriage rather than per-ES.
  • No parsing beyond what's needed to find a safe group boundary (a TS packet boundary; optionally a RAI/PUSI for clean joins). Discontinuity/CC and PCR ride through untouched.
  • CLI: surface as moq-cli publish ts --opaque (or a distinct --format ts-opaque on both ends). The subscriber writes the original bytes back out.
  • Browsers are unaffected — they consume the existing hang catalog / media-aware tracks and never need TS, so this adds no player work (the concern raised earlier). Opaque carriage is for native/contribution consumers only.

Trade-offs (call them out, not hide them)

  • No transcode, no ABR, no per-rendition selection on this lane — it's a pipe. That's the point; it's the contribution/distribution tier, not the OTT tier.
  • Bandwidth ~= source mux rate (stuffing included). Acceptable for contribution.
  • The relay stays media-agnostic (it already is) — opaque carriage is more aligned with "the CDN knows nothing about media", not less.

Relationship to existing work

Acceptance

A captured broadcast TS published via the opaque lane and re-emitted by a subscriber is bit-identical (or PID/PSI/PCR/CC-identical, allowing only for chosen group boundaries) to the source, and tsanalyze reports the same service identity, bitrate, and zero added discontinuities.

(Written by Claude)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions