Summary
draft-gregoire-moq-msfts has been restructured and now defines three named carriage modes for
MPEG-2 Transport Streams over MoQ. The third of them — "modified ES-level carriage", §5.5.3 — reads
as an attempt to describe a media-aware lane of the kind this repository implements. Read against
origin/main, it describes a different design, and the differences are structural rather than
cosmetic.
That matters now rather than later, because the draft is where this gets settled for anyone's
implementation, and because a subscriber cannot be written to satisfy both descriptions at once. This
issue sets out the divergence as I read it from the code, then asks for decisions. It does not
propose a patch, and it does not assume the draft is right where the two differ — on three of the six
points below I think the divergence favours what is implemented here, and would argue for the draft
moving rather than the code.
Draft text: https://mondain.github.io/msfts/draft-gregoire-moq-msfts.html
What the draft says mode 3 is
§5.5.3 When m2tsEsPid is present, the track carries a single elementary stream or signaling
table. The track payload contains only TS packets for the PID identified by m2tsEsPid; PAT, PMT,
and null packets are not included.
and
§5.5.3 A publisher producing multiple ES-level tracks for the same program MUST align Group
boundaries across all those tracks so that matching Group numbers correspond to the same
presentation position.
and, from §8 (excerpted — the paragraph opens with a requirement to align on the same starting Group
number across all subscribed ES-level tracks, which is the subject of point 4 below):
§8 The subscriber constructs the combined TS output by building a PAT listing the carried
program and a PMT listing the PIDs of all subscribed ES-level tracks, then interleaving packets
from all tracks. PCR is sourced from the track where m2tsPcrPid equals m2tsEsPid.
So: the payload unit is a 188-octet TS packet, filtered to one PID; continuity counters,
adaptation fields and PES framing travel inside those packets; the timing reference travels with the
media, in the PCR-bearing track; and group numbers are a cross-track synchronisation primitive.
What origin/main does
Read from rs/moq-mux/src/container/ts/{import,export,catalog}.rs:
|
MSFTS §5.5.3 |
moq-dev on origin/main |
| Track payload |
188-octet TS packets, one PID |
Decoded access units — N.avc3 length-prefixed NALUs, N.aac ADTS frames; reassembled PES payloads (N.ts) for undecoded ES; complete sections for SCTE-35 |
| Continuity counters |
preserved inside the packets |
observed for resync, then discarded; regenerated at export |
| PAT / PMT |
out of band in initDataList; subscriber constructs a PMT |
regenerated at export from catalog identity, re-emitted at keyframes and every 500 ms |
| PCR |
carried in the track where m2tsPcrPid == m2tsEsPid |
not carried. Export synthesises a uniform 25 ms grid; source PCR PID survives as an identifier |
| Group boundaries |
MUST align across ES tracks at one presentation position |
video cuts at keyframes; audio cuts every frame; verbatim PES per PES; sections per section |
| SI tables |
separate tracks, role: nit/sdt/eit/tdt |
NIT and SDT as opaque section sets in the catalog (mpegts.si, with an interval); EIT and TDT/TOT not carried |
| Mux rate |
m2tsMuxRate, though it MUST be absent in this mode |
no mux-rate concept in the TS code |
| Catalog |
MSF, packaging: "m2ts" |
Hang catalog with a typed mpegts extension; moq-msf's Packaging enum has no m2ts |
| MPTS |
mode 1 with m2tsMpts: true |
first non-zero PAT programme only; export rebuilds single-programme PSI |
So this is not mode 3. It is a fourth mode the draft does not have: access-unit carriage with
transport-stream re-synthesis at egress. m2tsPacketSize and m2tsPacketsPerObject have no
meaning for these tracks, because there are no source packets in the payload.
The view I hold, so it is on the record before the questions
I think the implementation's choice is the right one for a media-aware lane, and that the draft's
mode 3 sits between two coherent designs without committing to either.
Filtered-TS carriage preserves counters, adaptation fields and PES framing exactly, and it is a PID
filter rather than a demuxer, so it carries components the publisher does not understand. That is
real, and it is the honest form of "select the components you want".
But it buys selective component subscription, not media awareness, while taking on the full cost
of per-ES carriage: cross-track group alignment, PAT and PMT reconstruction, PCR sourced from a
different track, and re-interleaving N independently-flowing tracks into one multiplex that still has
to satisfy the T-STD. Access-unit carriage takes that same complexity and gets something for it —
group boundaries land on an IDR by construction, so a join is decodable without scanning; objects are
frame-sized, so priority and shedding are per frame; codec configuration reaches the catalog, so a
subscriber initialises without parsing TS.
The price of the implementation's choice is exactly what it regenerates, and it is not free. In our
own measurements the ungroomed egress of this lane carries no stuffing, thins PAT repetition from
8.04/s to 2.51/s, and puts 8.19 % of PCR intervals above 40 ms with a worst of 319.94 ms, against a
source with none above 40 ms in 600 s — cross-host, wire domain, eab960192. With a rate-controlled
egress in front of it the same lane measures 0 of 20,193 intervals above 40 ms over 300 s, and holds
that across a 24.01 h run. Nothing here has been graded on a hardware IRD, so those are software
conformance figures and not a lock claim.
None of that is an argument against the design. It is an argument that the format has to say the
egress must restore timing, which I have asked the draft for separately as
mondain/msfts#32.
The six decisions
Only you can make these, and a subscriber author needs every one of them answered.
- Is MSFTS compatibility an objective at all? Today the TS lane publishes a Hang catalog with an
mpegts extension, and MSFTS extends the MSF catalog with packaging: "m2ts". These are two
documents, not two dialects. If compatibility is wanted, the realistic first step is a published
mapping — the mpegts section is a superset of MSFTS's per-track fields in information content —
rather than a rewrite. If it is not wanted, that is a legitimate answer and the draft should stop
implying otherwise.
- Does the payload unit converge, and in which direction? Access units or filtered TS packets.
I think the draft should move, but this is the decision everything else hangs from.
- Does the timing reference travel with the media, or is it reconstructed at egress? The draft
assumes the former; the exporter does the latter, on a synthetic 25 ms grid. A subscriber cannot
do both, and a subscriber that expects source PCR and receives a regenerated grid will mis-measure
drift against the source. Whichever it is, it needs to be stated in the format — a regular 25 ms
grid is comfortably inside the 40 ms repetition limit and arguably better behaved than most
sources, but that is only true if the receiver is told it is looking at a new clock.
- Do you accept §5.5.3's group-alignment MUST? I do not think you can, and I do not think you
should. Audio cuts a group per frame here, which is a deliberate latency choice — one QUIC stream
per frame, so a lost audio frame does not head-of-line-block the next — and aligning audio groups
to video GOPs would cost up to a GOP of audio latency. The requirement is also unsatisfiable
literally: a 1024-sample AAC frame at 48 kHz is 21.333 ms against a 40 ms video frame at 25 fps, so
"the same presentation position" has no solution without splitting or padding, and the MUST sweeps
in sparse signalling tracks such as SCTE-35 whose sections have no presentation time of their own.
If you agree, saying so is what gets it restated as a presentation-time correspondence
requirement instead.
- SI in the catalog, or SI as tracks? The catalog route has an advantage the draft has not
considered: a joining subscriber gets SDT and NIT immediately, rather than waiting a repetition
cycle, and mpegts.si's interval is the same idea as m2tsPsiInterval. I would argue for the
draft permitting both and saying when to choose each. The counter-question is coverage: EIT and
TDT/TOT are not carried on origin/main, and broadcast time is something an IRD wants — is the
#2909 snapshot-track work intended for main, and is TDT/TOT in scope with it?
- Will the observed mux rate be recorded in the catalog? This is the smallest item and the one
with the largest effect. Null stripping is a genuine gain — our reference multiplex is 4.57 %
stuffing and this lane runs about 5.3 % below SRT on the same content, measured on a WAN path over
60 s — and MSFTS §5.5.2 already anticipates exactly this case and provides m2tsMuxRate for it.
Recording the rate observed at import in the mpegts section would make this lane's egress
re-pacable by any generic groomer, with no catalog convergence needed at all.
I have put the same argument to the draft's authors as
mondain/msfts#33, so this is not being raised in only one venue.
What I am not asking for
Not a patch, not a commitment, and not a change before you have a position. If the answer to (1) is
"no", then (2) through (5) stop being convergence questions and become documentation questions, and
that is a perfectly good outcome — it just needs to be said out loud, because the draft currently
reads as though this implementation is an instance of its mode 3.
Summary
draft-gregoire-moq-msftshas been restructured and now defines three named carriage modes forMPEG-2 Transport Streams over MoQ. The third of them — "modified ES-level carriage", §5.5.3 — reads
as an attempt to describe a media-aware lane of the kind this repository implements. Read against
origin/main, it describes a different design, and the differences are structural rather thancosmetic.
That matters now rather than later, because the draft is where this gets settled for anyone's
implementation, and because a subscriber cannot be written to satisfy both descriptions at once. This
issue sets out the divergence as I read it from the code, then asks for decisions. It does not
propose a patch, and it does not assume the draft is right where the two differ — on three of the six
points below I think the divergence favours what is implemented here, and would argue for the draft
moving rather than the code.
Draft text: https://mondain.github.io/msfts/draft-gregoire-moq-msfts.html
What the draft says mode 3 is
and
and, from §8 (excerpted — the paragraph opens with a requirement to align on the same starting Group
number across all subscribed ES-level tracks, which is the subject of point 4 below):
So: the payload unit is a 188-octet TS packet, filtered to one PID; continuity counters,
adaptation fields and PES framing travel inside those packets; the timing reference travels with the
media, in the PCR-bearing track; and group numbers are a cross-track synchronisation primitive.
What
origin/maindoesRead from
rs/moq-mux/src/container/ts/{import,export,catalog}.rs:moq-devonorigin/mainN.avc3length-prefixed NALUs,N.aacADTS frames; reassembled PES payloads (N.ts) for undecoded ES; complete sections for SCTE-35initDataList; subscriber constructs a PMTm2tsPcrPid == m2tsEsPidrole: nit/sdt/eit/tdtmpegts.si, with aninterval); EIT and TDT/TOT not carriedm2tsMuxRate, though it MUST be absent in this modepackaging: "m2ts"mpegtsextension;moq-msf'sPackagingenum has nom2tsm2tsMpts: trueSo this is not mode 3. It is a fourth mode the draft does not have: access-unit carriage with
transport-stream re-synthesis at egress.
m2tsPacketSizeandm2tsPacketsPerObjecthave nomeaning for these tracks, because there are no source packets in the payload.
The view I hold, so it is on the record before the questions
I think the implementation's choice is the right one for a media-aware lane, and that the draft's
mode 3 sits between two coherent designs without committing to either.
Filtered-TS carriage preserves counters, adaptation fields and PES framing exactly, and it is a PID
filter rather than a demuxer, so it carries components the publisher does not understand. That is
real, and it is the honest form of "select the components you want".
But it buys selective component subscription, not media awareness, while taking on the full cost
of per-ES carriage: cross-track group alignment, PAT and PMT reconstruction, PCR sourced from a
different track, and re-interleaving N independently-flowing tracks into one multiplex that still has
to satisfy the T-STD. Access-unit carriage takes that same complexity and gets something for it —
group boundaries land on an IDR by construction, so a join is decodable without scanning; objects are
frame-sized, so priority and shedding are per frame; codec configuration reaches the catalog, so a
subscriber initialises without parsing TS.
The price of the implementation's choice is exactly what it regenerates, and it is not free. In our
own measurements the ungroomed egress of this lane carries no stuffing, thins PAT repetition from
8.04/s to 2.51/s, and puts 8.19 % of PCR intervals above 40 ms with a worst of 319.94 ms, against a
source with none above 40 ms in 600 s — cross-host, wire domain,
eab960192. With a rate-controlledegress in front of it the same lane measures 0 of 20,193 intervals above 40 ms over 300 s, and holds
that across a 24.01 h run. Nothing here has been graded on a hardware IRD, so those are software
conformance figures and not a lock claim.
None of that is an argument against the design. It is an argument that the format has to say the
egress must restore timing, which I have asked the draft for separately as
mondain/msfts#32.
The six decisions
Only you can make these, and a subscriber author needs every one of them answered.
mpegtsextension, and MSFTS extends the MSF catalog withpackaging: "m2ts". These are twodocuments, not two dialects. If compatibility is wanted, the realistic first step is a published
mapping — the
mpegtssection is a superset of MSFTS's per-track fields in information content —rather than a rewrite. If it is not wanted, that is a legitimate answer and the draft should stop
implying otherwise.
I think the draft should move, but this is the decision everything else hangs from.
assumes the former; the exporter does the latter, on a synthetic 25 ms grid. A subscriber cannot
do both, and a subscriber that expects source PCR and receives a regenerated grid will mis-measure
drift against the source. Whichever it is, it needs to be stated in the format — a regular 25 ms
grid is comfortably inside the 40 ms repetition limit and arguably better behaved than most
sources, but that is only true if the receiver is told it is looking at a new clock.
should. Audio cuts a group per frame here, which is a deliberate latency choice — one QUIC stream
per frame, so a lost audio frame does not head-of-line-block the next — and aligning audio groups
to video GOPs would cost up to a GOP of audio latency. The requirement is also unsatisfiable
literally: a 1024-sample AAC frame at 48 kHz is 21.333 ms against a 40 ms video frame at 25 fps, so
"the same presentation position" has no solution without splitting or padding, and the MUST sweeps
in sparse signalling tracks such as SCTE-35 whose sections have no presentation time of their own.
If you agree, saying so is what gets it restated as a presentation-time correspondence
requirement instead.
considered: a joining subscriber gets SDT and NIT immediately, rather than waiting a repetition
cycle, and
mpegts.si'sintervalis the same idea asm2tsPsiInterval. I would argue for thedraft permitting both and saying when to choose each. The counter-question is coverage: EIT and
TDT/TOT are not carried on
origin/main, and broadcast time is something an IRD wants — is the#2909snapshot-track work intended formain, and is TDT/TOT in scope with it?with the largest effect. Null stripping is a genuine gain — our reference multiplex is 4.57 %
stuffing and this lane runs about 5.3 % below SRT on the same content, measured on a WAN path over
60 s — and MSFTS §5.5.2 already anticipates exactly this case and provides
m2tsMuxRatefor it.Recording the rate observed at import in the
mpegtssection would make this lane's egressre-pacable by any generic groomer, with no catalog convergence needed at all.
I have put the same argument to the draft's authors as
mondain/msfts#33, so this is not being raised in only one venue.
What I am not asking for
Not a patch, not a commitment, and not a change before you have a position. If the answer to (1) is
"no", then (2) through (5) stop being convergence questions and become documentation questions, and
that is a perfectly good outcome — it just needs to be said out loud, because the draft currently
reads as though this implementation is an instance of its mode 3.