You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: archive.json
+141-3Lines changed: 141 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
{
2
2
"magic": "E!vIA5L86J2I",
3
-
"timestamp": "2026-06-23T00:38:26.529830+00:00",
3
+
"timestamp": "2026-07-12T00:27:50.158551+00:00",
4
4
"repo": "mondain/msfts",
5
5
"labels": [
6
6
{
@@ -62,9 +62,17 @@
62
62
"labels": [],
63
63
"body": "## Scope of this review\n\nWe are evaluating m2ts packaging as a **native broadcast-contribution / satellite-\nreplacement** carriage: a whole MPEG-TS multiplex handed off byte-faithfully to an\nIRD at the far end, the way SRT/Zixi/RIST carry it today. \n\n## 1. \u00a75.5 retain-list drops DVB/ATSC SI (SDT/EIT/TDT/TOT/NIT)\n\n\u00a75.5 lists what a per-program m2ts track contains: null packets (optional), a\nrewritten PAT, the selected PMT, and every PID listed in that PMT. PSI/SI tables\nthat live on **fixed PIDs and are not referenced by the PMT** are therefore not\nretained:\n\n- SDT/BAT (PID 0x0011) \u2014 service name and service descriptors\n- EIT (PID 0x0012) \u2014 now/next and schedule EPG\n- TDT/TOT (PID 0x0014) \u2014 broadcast wall-clock and local-time offset\n- NIT (PID 0x0010) \u2014 network / delivery-system info\n- (ATSC equivalents: PSIP on the base PID)\n\nA publisher implementing \u00a75.5 verbatim emits a stream with no service identity,\nno EPG, and no broadcast time. An IRD ingesting that for redistribution loses the\nservice name and EPG it would normally relay. The reference implementation\n`moq2ts` shows this concretely: its packetizer keeps only\n`{PAT, PMT, PCR, PMT-listed ES}` and drops everything else, so a SPTS feed comes out without SDT (service name), NIT, or TDT/TOT.\n\n**Suggestion:** add an SI subsection (or extend \u00a75.5) that says a publisher\nSHOULD retain the SI tables required by the target deployment (DVB: SDT, EIT,\nTDT/TOT, NIT; ATSC: PSIP), or at minimum note that these are dropped by the \u00a75.5\nfilter and that their preservation is the publisher's responsibility. A catalog\nhint listing retained SI PIDs would let subscribers know what to expect.\n\n## 2. \u00a75.5 null-packet removal breaks CBR byte-clock / PCR-to-byte fidelity\n\n\u00a75.5 lets a publisher remove PID 0x1FFF null packets at its discretion, and \u00a75.6\ncorrectly notes that Object/Group boundaries don't alter PCR continuity. But\nremoving nulls changes the **byte distance between successive PCRs**, which is\nexactly the quantity a constant-bitrate egress (and many hardware IRDs) uses to\nreconstruct the mux clock and re-stuff to a fixed rate. A feed that was CBR on the\ncontribution link arrives VBR-shaped, and the downstream device must re-derive a\nrate it was never told.\n\n**Suggestion:** note this trade-off explicitly. Either (a) recommend retaining\nnulls when byte-faithful CBR reconstruction matters, or (b) define an advisory\ncatalog field for the source mux rate (bits/s) so an egress can re-stuff\ndeterministically. This pairs with point 4.\n\n## 3. Add an explicit transparent / whole-multiplex profile\n\nThe draft's center of gravity is \"one program per track, filtered.\" Broadcast\ncontribution frequently needs the opposite: carry the **entire multiplex\nverbatim** (all programs, all SI, nulls, continuity counters, scrambling intact)\nso the far end receives bit-for-bit what was sent, and program selection happens\nat the IRD as it does today.\n\n\u00a76.4 already allows this implicitly (\"When absent, a track MAY carry multiple\nprograms\"), but it is phrased as an exception rather than a first-class mode, and\nnothing ties it to \"preserve the whole TS untouched.\"\n\n**Suggestion:** define a transparent profile \u2014 e.g. a boolean track field\n(`m2tsTransparent: true`, or reuse \"program number absent\" with explicit wording)\nmeaning *no filtering, no PAT rewrite, no null removal; the track is the source\nmultiplex unchanged*. This is the lane that makes m2ts a true satellite\nreplacement, and it removes any ambiguity about whether SI/nulls survive.\n\n## 4. (Minor) Source mux-rate / timing hint for deterministic egress\n\nTied to point 2: a receiver regenerating a physical TS for an IRD has to choose an\noutput bitrate. Today it must infer it. An optional advisory field for the source\nconstant mux rate (or a statement that the timeline + PCR are authoritative and\nthe egress MAY pace to PCR) would make egress behavior interoperable.\n\n## Note on what we did and didn't test\n\nOur hands-on testing to date was a **single-program (SPTS)** feed and exercised a\n*different* implementation (the moq-dev media-aware `mpegts` lane), not this draft.\nNothing we tested validates or invalidates the \u00a75.5 **multi-program** rules, and\nwe are not claiming the MPTS handling is wrong. Points 1\u20134 above are observations\nabout the draft text and the `moq2ts` reference implementation, not extrapolations\nfrom our SPTS runs.\n\n(Written by Claude)",
64
64
"createdAt": "2026-06-22T20:34:18Z",
65
-
"updatedAt": "2026-06-22T20:34:18Z",
65
+
"updatedAt": "2026-07-09T17:10:41Z",
66
66
"closedAt": null,
67
-
"comments": []
67
+
"comments": [
68
+
{
69
+
"author": "gwendalsimon",
70
+
"authorAssociation": "COLLABORATOR",
71
+
"body": "These are valid points. Thank you for the detailed feedback.\n\nI have opened four independent PRs to address each of them:\n\n- #8 \u2014 Transparent whole-multiplex carriage mode (point 3): new `m2tsMpts` catalog field for carrying a complete MPTS without filtering or PAT rewrite\n- #10 \u2014 Null packet removal and CBR fidelity (point 2): warning in \u00a75.5 and new advisory `m2tsMuxRate` field so subscribers can restore the original mux rate\n- #11 \u2014 SI table preservation (point 1): note that the PMT-centric filter drops DVB/ATSC SI tables, with guidance and a new `m2tsSiPids` field listing retained PIDs\n- #12 \u2014 CC/PID preservation and PCR timing (points 4 and general fidelity): explicit MUST NOTs for continuity counter modification and PID remapping, plus a non-normative note on inter-packet PCR timing for IRD deployments\n\nEach PR is self-contained and can be reviewed independently. Feel free to comment on any of them.",
"body": "## Summary\n\nAddresses point 3 of #7 \u2014 the request for an explicit transparent profile for whole-multiplex carriage.\n\n- Defines a new boolean catalog field `m2tsMpts` that, when true, signals that the track carries the full multi-program transport stream without program selection, PID filtering, or PAT rewrite\n- Names the field after its content rather than publisher behavior, distinguishing it from per-program transparent forwarding of a SPTS\n- Propagates the constraint and semantics across all affected sections of the draft\n\n## Changes\n\n**\u00a75.2 Object Boundaries** \u2014 scopes the \"Group starts with PAT and PMT\" guidance to single-program video tracks\n\n**\u00a75.5 Multi-Program Source Handling** \u2014 adds two paragraphs defining the `m2tsMpts` mode; Group boundaries use a fixed Object count unless the publisher can identify RAPs and sets `m2tsRandomAccess`\n\n**Catalog table and field definitions**\n- New `m2tsMpts` entry and section\n- `m2tsProgramNumber`, `m2tsPmtPid`, `m2tsPcrPid`: each gains a MUST-be-absent clause when `m2tsMpts` is true\n- `m2tsPsiInterval`: distinguished between normative SHOULD (single-program) and advisory (MPTS)\n- `initData`: closing paragraph noting that MPTS requires extracting PAT and all program PMTs\n\n**\u00a77 Examples** \u2014 rename per-program example to avoid confusion; add Transparent MPTS Carriage example\n\n**\u00a78 Subscriber Processing** \u2014 clarify \"PMT for the track\" to \"PMT for the program to be decoded\"\n\n**\u00a710 Switching** \u2014 add MUST NOT prohibiting `m2tsMpts` tracks from `altGroup`",
"body": "## Summary\n\nMOQT relays forward and cache Objects based on MOQT-layer metadata: namespace, track, Group ID, Object ID, and delivery metadata. They have no mechanism to read MSF catalog fields, which are application-layer information exchanged between publishers and subscribers outside the relay's scope.\n\nThe removed section conditioned relay cache behavior on `m2tsRandomAccess`, an MSF catalog field. Because a relay cannot read catalog fields, this guidance was unenforceable and incorrect. The remaining text \u2014 that relays are not required to parse MPEG-2 Transport Stream syntax and may discard Groups per MOQT cache policy \u2014 is already implied by MOQT being payload-agnostic and adds no m2ts-specific normative content.\n\nRelay behavior for m2ts tracks is fully governed by the base MOQT specification; no m2ts-specific relay section is needed.",
"body": "## Summary\n\nAddresses point 2 of #7 \u2014 null packet removal breaks CBR byte-clock and mux-clock recovery.\n\nPoint 2 notes that \u00a75.5 permits null packet removal at publisher discretion, but removing null packets changes the byte distance between successive PCRs. Constant-bit-rate receivers use that spacing to reconstruct the mux clock; without it, a downstream device must re-derive a rate it was never told. The issue suggested either recommending that nulls be retained for CBR reconstruction, or defining an advisory catalog field for the source mux rate.\n\nThis PR implements the catalog field option.\n\n## Changes\n\n**\u00a75.5 Multi-Program Source Handling** \u2014 adds a paragraph warning that removing null packets changes the inter-packet byte spacing that constant-bit-rate receivers use to recover the mux clock, and that publishers removing null packets SHOULD declare `m2tsMuxRate`.\n\n**Catalog table** \u2014 new `m2tsMuxRate` entry.\n\n**New field `m2tsMuxRate`** \u2014 optional advisory Number (bits/s). A subscriber reconstructing a constant-bit-rate output stream MAY use this value to restore the original mux rate when null packets have been removed.",
"body": "## Summary\n\nAddresses point 1 of #7 \u2014 the \u00a75.5 retain filter silently drops DVB and ATSC service information tables.\n\nPoint 1 observes that the PMT-centric retain list in \u00a75.5 does not include SI tables carried on fixed well-known PIDs: SDT/BAT (0x0011), EIT (0x0012), TDT/TOT (0x0014), and NIT (0x0010), or their ATSC PSIP equivalents. A publisher implementing \u00a75.5 without additional care produces a track with no service identity, no EPG, and no broadcast time \u2014 a disqualifier for IRD-based deployments. The issue suggested either a normative note or a catalog hint for retained SI PIDs.\n\nThis PR implements both.\n\n## Changes\n\n**\u00a75.5 Multi-Program Source Handling** \u2014 adds a paragraph noting that the PMT-centric filter silently drops DVB and ATSC SI tables, listing the affected PIDs, and stating that publishers targeting broadcast or IRD deployments SHOULD retain the required SI tables and SHOULD declare the retained PIDs using `m2tsSiPids`.\n\n**Catalog table** \u2014 new `m2tsSiPids` entry.\n\n**New field `m2tsSiPids`** \u2014 optional advisory Array of packet identifiers retained in the filtered track beyond those listed in the Program Map Table. Subscribers MAY use this list to verify which service information tables are present without inspecting the packet stream.",
"body": "## Summary\n\nTwo related clarifications for contribution and IRD deployments, addressing fidelity concerns raised in #7.\n\n**\u00a75.2 \u2014 continuity counter and PID preservation**\n\nThe existing text describes continuity counters, PIDs, and other transport-stream syntax as \"remaining inside the source packets\" \u2014 a description of what is carried, not a prohibition on modification. A publisher forwarding a source transport stream could technically rewrite continuity counters or remap PIDs while complying with the current text. Both modifications are silent disqualifiers for IRD receivers: a broken continuity counter sequence triggers decoder errors; PID remapping breaks demultiplexing and conditional access without warning. This PR adds explicit MUST NOTs to match the byte-faithful carriage requirement described in #7.\n\n**\u00a75.5 \u2014 PCR arrival timing**\n\nThe PCR and Timing section correctly handles PCR value continuity and discontinuity signaling but says nothing about inter-packet timing. Hardware IRDs derive the mux clock from the rate at which PCR-bearing packets arrive, not only from their encoded values. MOQT does not guarantee that Object delivery preserves inter-packet timing; packets arrive in bursts shaped by QUIC rather than at source mux rate. A non-normative note acknowledges this constraint, addressing the second option raised in point 4 of #7 \u2014 a statement that PCR is authoritative and that the egress should pace to it.\n\n## Changes\n\n**\u00a75.2 Object Boundaries** \u2014 add MUST NOT modify continuity counters and MUST NOT remap PIDs when forwarding a source transport stream.\n\n**\u00a75.5 PCR and Timing** \u2014 add non-normative note on inter-packet PCR timing and IRD mux-clock recovery.",
0 commit comments