Scope of this review
We are evaluating m2ts packaging as a native broadcast-contribution / satellite-
replacement carriage: a whole MPEG-TS multiplex handed off byte-faithfully to an
IRD at the far end, the way SRT/Zixi/RIST carry it today.
1. §5.5 retain-list drops DVB/ATSC SI (SDT/EIT/TDT/TOT/NIT)
§5.5 lists what a per-program m2ts track contains: null packets (optional), a
rewritten PAT, the selected PMT, and every PID listed in that PMT. PSI/SI tables
that live on fixed PIDs and are not referenced by the PMT are therefore not
retained:
- SDT/BAT (PID 0x0011) — service name and service descriptors
- EIT (PID 0x0012) — now/next and schedule EPG
- TDT/TOT (PID 0x0014) — broadcast wall-clock and local-time offset
- NIT (PID 0x0010) — network / delivery-system info
- (ATSC equivalents: PSIP on the base PID)
A publisher implementing §5.5 verbatim emits a stream with no service identity,
no EPG, and no broadcast time. An IRD ingesting that for redistribution loses the
service name and EPG it would normally relay. The reference implementation
moq2ts shows this concretely: its packetizer keeps only
{PAT, PMT, PCR, PMT-listed ES} and drops everything else, so a SPTS feed comes out without SDT (service name), NIT, or TDT/TOT.
Suggestion: add an SI subsection (or extend §5.5) that says a publisher
SHOULD retain the SI tables required by the target deployment (DVB: SDT, EIT,
TDT/TOT, NIT; ATSC: PSIP), or at minimum note that these are dropped by the §5.5
filter and that their preservation is the publisher's responsibility. A catalog
hint listing retained SI PIDs would let subscribers know what to expect.
2. §5.5 null-packet removal breaks CBR byte-clock / PCR-to-byte fidelity
§5.5 lets a publisher remove PID 0x1FFF null packets at its discretion, and §5.6
correctly notes that Object/Group boundaries don't alter PCR continuity. But
removing nulls changes the byte distance between successive PCRs, which is
exactly the quantity a constant-bitrate egress (and many hardware IRDs) uses to
reconstruct the mux clock and re-stuff to a fixed rate. A feed that was CBR on the
contribution link arrives VBR-shaped, and the downstream device must re-derive a
rate it was never told.
Suggestion: note this trade-off explicitly. Either (a) recommend retaining
nulls when byte-faithful CBR reconstruction matters, or (b) define an advisory
catalog field for the source mux rate (bits/s) so an egress can re-stuff
deterministically. This pairs with point 4.
3. Add an explicit transparent / whole-multiplex profile
The draft's center of gravity is "one program per track, filtered." Broadcast
contribution frequently needs the opposite: carry the entire multiplex
verbatim (all programs, all SI, nulls, continuity counters, scrambling intact)
so the far end receives bit-for-bit what was sent, and program selection happens
at the IRD as it does today.
§6.4 already allows this implicitly ("When absent, a track MAY carry multiple
programs"), but it is phrased as an exception rather than a first-class mode, and
nothing ties it to "preserve the whole TS untouched."
Suggestion: define a transparent profile — e.g. a boolean track field
(m2tsTransparent: true, or reuse "program number absent" with explicit wording)
meaning no filtering, no PAT rewrite, no null removal; the track is the source
multiplex unchanged. This is the lane that makes m2ts a true satellite
replacement, and it removes any ambiguity about whether SI/nulls survive.
4. (Minor) Source mux-rate / timing hint for deterministic egress
Tied to point 2: a receiver regenerating a physical TS for an IRD has to choose an
output bitrate. Today it must infer it. An optional advisory field for the source
constant mux rate (or a statement that the timeline + PCR are authoritative and
the egress MAY pace to PCR) would make egress behavior interoperable.
Note on what we did and didn't test
Our hands-on testing to date was a single-program (SPTS) feed and exercised a
different implementation (the moq-dev media-aware mpegts lane), not this draft.
Nothing we tested validates or invalidates the §5.5 multi-program rules, and
we are not claiming the MPTS handling is wrong. Points 1–4 above are observations
about the draft text and the moq2ts reference implementation, not extrapolations
from our SPTS runs.
(Written by Claude)
Scope of this review
We are evaluating m2ts packaging as a native broadcast-contribution / satellite-
replacement carriage: a whole MPEG-TS multiplex handed off byte-faithfully to an
IRD at the far end, the way SRT/Zixi/RIST carry it today.
1. §5.5 retain-list drops DVB/ATSC SI (SDT/EIT/TDT/TOT/NIT)
§5.5 lists what a per-program m2ts track contains: null packets (optional), a
rewritten PAT, the selected PMT, and every PID listed in that PMT. PSI/SI tables
that live on fixed PIDs and are not referenced by the PMT are therefore not
retained:
A publisher implementing §5.5 verbatim emits a stream with no service identity,
no EPG, and no broadcast time. An IRD ingesting that for redistribution loses the
service name and EPG it would normally relay. The reference implementation
moq2tsshows this concretely: its packetizer keeps only{PAT, PMT, PCR, PMT-listed ES}and drops everything else, so a SPTS feed comes out without SDT (service name), NIT, or TDT/TOT.Suggestion: add an SI subsection (or extend §5.5) that says a publisher
SHOULD retain the SI tables required by the target deployment (DVB: SDT, EIT,
TDT/TOT, NIT; ATSC: PSIP), or at minimum note that these are dropped by the §5.5
filter and that their preservation is the publisher's responsibility. A catalog
hint listing retained SI PIDs would let subscribers know what to expect.
2. §5.5 null-packet removal breaks CBR byte-clock / PCR-to-byte fidelity
§5.5 lets a publisher remove PID 0x1FFF null packets at its discretion, and §5.6
correctly notes that Object/Group boundaries don't alter PCR continuity. But
removing nulls changes the byte distance between successive PCRs, which is
exactly the quantity a constant-bitrate egress (and many hardware IRDs) uses to
reconstruct the mux clock and re-stuff to a fixed rate. A feed that was CBR on the
contribution link arrives VBR-shaped, and the downstream device must re-derive a
rate it was never told.
Suggestion: note this trade-off explicitly. Either (a) recommend retaining
nulls when byte-faithful CBR reconstruction matters, or (b) define an advisory
catalog field for the source mux rate (bits/s) so an egress can re-stuff
deterministically. This pairs with point 4.
3. Add an explicit transparent / whole-multiplex profile
The draft's center of gravity is "one program per track, filtered." Broadcast
contribution frequently needs the opposite: carry the entire multiplex
verbatim (all programs, all SI, nulls, continuity counters, scrambling intact)
so the far end receives bit-for-bit what was sent, and program selection happens
at the IRD as it does today.
§6.4 already allows this implicitly ("When absent, a track MAY carry multiple
programs"), but it is phrased as an exception rather than a first-class mode, and
nothing ties it to "preserve the whole TS untouched."
Suggestion: define a transparent profile — e.g. a boolean track field
(
m2tsTransparent: true, or reuse "program number absent" with explicit wording)meaning no filtering, no PAT rewrite, no null removal; the track is the source
multiplex unchanged. This is the lane that makes m2ts a true satellite
replacement, and it removes any ambiguity about whether SI/nulls survive.
4. (Minor) Source mux-rate / timing hint for deterministic egress
Tied to point 2: a receiver regenerating a physical TS for an IRD has to choose an
output bitrate. Today it must infer it. An optional advisory field for the source
constant mux rate (or a statement that the timeline + PCR are authoritative and
the egress MAY pace to PCR) would make egress behavior interoperable.
Note on what we did and didn't test
Our hands-on testing to date was a single-program (SPTS) feed and exercised a
different implementation (the moq-dev media-aware
mpegtslane), not this draft.Nothing we tested validates or invalidates the §5.5 multi-program rules, and
we are not claiming the MPTS handling is wrong. Points 1–4 above are observations
about the draft text and the
moq2tsreference implementation, not extrapolationsfrom our SPTS runs.
(Written by Claude)