A catalog describes what a track is: let encoders state it, and keep channel measurements out #7067

Activity

1. coderabbitai commented on Oct 28, 2026

   

   coderabbitaiBot

   on Oct 28, 2026 – with coderabbitai

   Contributor

   More actions

   🔗 Related PRs

   #6783 - feat(hang)!: opt-in per-rendition hls records replace the root archive [merged]
   #6527 - refactor(mux): m1 simplification audit [merged]
   #6937 - feat(mux)!: publish HLS records by default [merged]
   #6781 - feat(rate)!: native publishers disable simulcast rungs the grant cannot fund [merged]

   ---

   📝 Issue Planner

   _{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

   • Create Plan

   ---

   🧪 Issue enrichment is currently in open beta.

   You can configure auto-planning by selecting labels in the issue_enrichment configuration.

   To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

   issue_enrichment:
     auto_enrich:
       enabled: false

   💬 Have feedback or questions? Drop into our discord!
2. kixelated

   added

   questBeing tracked/planned in a quest. See `quest/`Being tracked/planned in a quest. See `quest/`

   on Oct 28, 2026
3. kixelated commented on Oct 28, 2026

   

   kixelated

   on Oct 28, 2026

   Collaborator

   More actions

   Thanks for the numbers. Planned in #7124 as quest/m1/catalog-estimates.md:

   1. jitter and delay stay in hang. @moq/watch, moq-audio and the TS export use them as latency floors, and a receiver can't measure cross-track skew. Instead of an opt-out, hang republishes them only when a rise crosses the next multiple of the track's frame duration, which folds the ~8 ms delay creep into one update.
   2. MSF differs from hang. It skips identical republishes. With no hint, it waits until every track's first group has closed, then freezes the estimated fields (MSF-01 §5.3) and republishes only for track-list or identity changes.
   3. HLS records go away entirely with the planned time-addressed export. A declared media.join.interval replaces them, and feat(moq-c)!: supply bitrate and group duration hints #7068's group_duration_us hint then declares that interval.

   #7068 is reviewed on its own.

   (Written by Claude Opus 5.5)
4. kixelated commented on Oct 28, 2026

   

   kixelated

   on Oct 28, 2026

   Collaborator

   More actions

   The plan from #7124 is in the merge queue. In short: jitter and delay stay in hang, but a rise republishes only when it crosses the next multiple of the frame duration. MSF skips duplicate catalogs. With no hint, MSF waits until each track's first group closes, then freezes its estimates. There is no opt-out.

   quest/m1/catalog-estimates.md tracks it. To donate tokens, run /quest-start quest/m1/catalog-estimates.

   (Written by Claude Opus 5.5)
5. kixelated

   added 2 commits that reference this issue on Oct 28, 2026

   quest: import moq-dev#7067, moq-dev#7088, moq-dev#7101 and moq-dev#7102…

   ...

   396fc0c

   fix(mux): settle catalog estimates before they churn

   ...

   e83ad80
6. michaelstuurman commented on Oct 29, 2026

   

   michaelstuurman

   on Oct 29, 2026

   ContributorAuthor

   More actions

   Thanks for planning this. Quantizing fixes the churn. Before it lands, I'd like to propose a different home for the measured values, one MSF already has.

   What the publisher measures is worth keeping. jitter and delay come from the publisher's write order: the largest media span written together, a container's PTS−DTS, and how far a track's timestamps trail what another track already wrote. That is clean, with no network in it. A receiver can measure the same skew from arrivals once media flows live, but not while it joins: a joining FETCH or a relay cache delivers the head of a group in a burst. So a late joiner does need the publisher's figure. I agree with that part.

   Part of it belongs in the catalog. The reorder delay is the largest PTS−DTS offset: the SPS/VUI gives max_num_reorder_frames, CMAF carries composition offsets, and hang's reorder already declares it. An encode budget and the group duration are configuration. Those are facts of the encoding, ideally supplied by the encoder as #7068 does for bitrate, with a promised bound as MSF-01's buffers.max (§5.2.9).

   The runtime part doesn't. Warm-up, load and restarts vary. As a field that only rises, one start-up spike sets the floor for the whole broadcast. For example, with libmoq 0.6.17, video encode warm-up could peak at ~550 ms against a steady ~255 ms. delay then settled at ~423 ms, and every viewer buffered ~440 ms instead of ~290 ms. MSF freezing its estimates at first declaration would keep such a spike too.

   MSF's Media Timeline already carries it. MSF-01 §7 records [mediaPTS, [group, object], wallclock] in the first object of each group, for the tracks in its depends, and a catalog may hold several timelines. With one timeline per media track, a receiver reads the source delay as the wallclock difference between tracks at the same PTS, and the source jitter as the spread of wallclock − PTS. Both come from the publisher's clock alone, so no viewer clock sync is needed. A late joiner gets the current values from the latest group, they fall back after a spike, and the catalog never republishes for them. A safe bound is then the player's choice: the maximum over the timeline it has read, or the catalog's promised bound.

   This is how RTP splits it (RFC 3550): SDP describes the stream, RTCP Sender Reports map media time to an NTP wallclock (§6.4.1), and the receiver computes interarrival jitter itself (§6.4.1, A.8). It matters most for ingest, which MoQ will carry a lot of: an RTSP or SRT source arrives with network jitter the publisher can't know up front, and a gateway can fill the timeline from the source's Sender Reports.

   So the proposal:

   1. Catalog: configured values and promised bounds only, changing with the track list or a track's identity (MSF-01 §5.3). For MSF, no non-standard jitter/delay estimates: MSF-01 has neither.
   2. Timing: a Media Timeline per media track, with the wallclock taken when the object is handed to the transport. hang could carry the same, beside its root clock (which maps PTS zero once).
   3. Receiver: derives source delay and jitter from the timelines and adds what it measures on the network, as @moq/watch already does for arrival spread.

   Two points need the MSF draft, and I'll raise them there: which instant the timeline's wallclock marks ("encoded" isn't precise enough for delay), and keeping timelines per track rather than per render group (moq-wg/msf#203), since tracks aligned in PTS aren't aligned in when they're produced.
7. kixelated

   closed this as completedin #7161on Oct 29, 2026