Repository navigation
quest(archive): DVR serves HLS past the live end through the wildcard claim #4553
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,13 +27,33 @@ served stays in `moq_net`'s track cache until the pool reclaims it. Decide | |
| whether expiry during a seek needs a group eviction API in `moq-net`. | ||
|
|
||
| `moq-hls` reads a timeline from the catalog's own broadcast, and an | ||
| `archive.replay` path only marks it non-durable. Decided (09-29): the exporter | ||
| does not follow `replay`, and viewers don't address a separate replay | ||
| broadcast. A recording is the broadcast. Under the | ||
| [wildcard](/quest/m0/wildcard/README.md) plan the archive serves the source | ||
| path through the root claim, and a live announcement shadows it. So when live | ||
| ends, `moq-hls` resolves the same name and falls through to the recording: | ||
|
Comment on lines
+33
to
+35
There was a problem hiding this comment.
The recording cannot currently satisfy this HLS handover: Useful? React with 👍 / 👎.
Collaborator
Author
There was a problem hiding this comment. Agreed. 2c29bdd adds Replay catalog to Required and says the fall-through needs the recording to publish its catalog live, since (Written by Claude Opus 5.5) |
||
| playlists keep serving for rewind and for players finishing the last | ||
| segments. The fall-through needs the recording to publish its catalog live, | ||
| since `moq-hls` subscribes to it rather than FETCHing it. Decided (09-29): | ||
| that republishing moves into `moq-archive`, so any host of the archive | ||
| behind the root claim does it, not only `moq-cli`; update [Replay | ||
| catalog](/quest/m1/archive/replay-catalog.md) to match. | ||
|
|
||
| During live, rewind needs no handover: a recorded broadcast's live timeline | ||
| is durable, and every group it lists is promised available, so a seek past | ||
| the live window FETCHes old groups through the normal miss chain down to the | ||
| archive. `moq-hls` needs no special path. `moq-hls` gains | ||
| no linger (the `hls-linger` quest was dropped, because an unannounced | ||
| broadcast can't be FETCHed and a linger would only serve the cache). Test | ||
| the handover: a live HLS session keeps its playlist URIs and media sequence | ||
| numbers when the name moves from the live publisher to the archive. | ||
|
|
||
| ## Required | ||
|
|
||
| - [Per-track timelines](/quest/m1/archive/track-timeline/README.md) - seeks through per-track timelines | ||
| - [Replay catalog](/quest/m1/archive/replay-catalog.md) - the recording publishes its catalog live, so `moq-hls` finds it after the handover | ||
|
Comment on lines
54
to
+55
There was a problem hiding this comment.
If this quest is scheduled from its declared Useful? React with 👍 / 👎.
Collaborator
Author
|
||
| - [Wildcard](/quest/m0/wildcard/README.md) - the archive's root claim serves the source path once the live announcement ends | ||
|
|
||
| ## Closes | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For an HLS viewer rewinding while the broadcast is still live, these decisions leave no path to the recorded groups: the concrete live claim shadows the archive catch-all (
quest/m0/wildcard/README.md:94-125), while the exporter neither followsarchive.replaynor treats a catalog containing it as durable (rs/moq-hls/src/export/mod.rs:373-379). The playlist therefore remains bounded by the live HLS window, so a viewer cannot seek through the DVR and return to live as this quest's goal requires. Preserve access to the recording during the live claim, for example by followingarchive.replayor exposing an equivalent overlay.Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one reopens the 09-29 decision that the exporter does not follow
archive.replay, so I am flagging it for the maintainer instead of changing the plan.The gap is real as written: while the live claim shadows the archive,
moq-hlsonly sees the live timeline, bounded by its window, so rewinding past that window during a live broadcast has no path to the recorded groups. The options I see are to (1) scope this quest to rewind after live ends and cover in-live rewind separately, (2) let the live timeline itself be durable for a recorded broadcast, so old groups are FETCHed through the normal miss chain that already reaches the archive, or (3) followreplayafter all. My recommendation to the maintainer is (2), since it keeps one name and one timeline and the plan already says old groups are FETCHed through the miss chain.(Written by Claude Opus 5.5)