feat(gst): moqsrc follows referenced broadcasts' announcements by kixelated · Pull Request #6394 · moq-dev/moq

kixelated · 2026-10-22T21:24:17Z

Completes quest/m0/broadcast-epoch/moqsrc-sibling-follow.md: moqsrc follows a catalog-referenced sibling's announcements through moq_mux::follow, restarting the rendition on the same pad for each instance, never past a named epoch.

Builds on moq-dev/moq#6254 (moq_mux::follow, the waiting Source::bind), now on main; this diff is the moqsrc part split from it. It lands before sink restart follow, which then moves the catalog broadcast's own follow onto the same follower.

Design: one follower per referenced path

The maintainer chose a follower per referenced sibling path over per-rendition pumps. The catalog loop no longer keeps per-rendition tasks or an active map.

Run (follow_catalog): on each catalog update it lists the renditions on the pad table and groups them by the path their reference resolves to. It then sends each group to that path's follower as a plan over a watch. A path no enabled rendition reads any more gets an empty plan. Its follower stays reachable while a disabled rendition names the path or a delisted one drains, so a re-enable or relist reaches the same follower and its finished records. Once it plays nothing, it wakes the run, which lets it go unless the last plan sent names a rendition or a disabled rendition holds the path. Only the run drops a follower, so no plan is lost to a follower exiting on its own. A follower with no renditions left also ends once the catalog closes. A follower whose broadcast failed is followed again on the next update.
Follower: one task per referenced path. It owns:
- the path's follow::Instances, following every instance (the catalog's own broadcast is the single fixed instance);
- the current instance, its number, and its timeline: the first instance shares the run's timeline, and each later one gets its own. An End releases the instance's consumer (discussion_r4355691716). The same channel announced again keeps its readers;
- the number and timeline of each instance a return would resume, by epoch: the current one and each one a rendition pins, so an instance that wins its path back, even after another won it for a while, restarts its readers on that state (discussion_r4355963961). An epochless return cannot prove its identity and counts as new;
- the finished records: one per (listed rendition, kept instance), naming the track it last played to the end. A record goes with its instance or its retired pad. Keeping one track per record bounds them by the catalog (discussion_r4356159635), so a rendition switched back to a track it finished before another one replays that track's last group (discussion_r4355963968);
- one entry per rendition: its shape, its reader, and whether it is draining.
Its behavior:
- A Start restarts every rendition on that instance whose named epoch, if any, the instance does not disprove.
- An End idles them.
- A reshape restarts that one rendition.
- A delisted rendition that owns its pad drains the instance it reads, then leaves. A disabled one, or one that moved to another broadcast, stops at once.
- Once the catalog closes, the renditions no longer change. The final plan starts what it adds or reshapes, even when it arrives together with the close (discussion_r4356239365), and restarts no reader that already ended. A sibling's follower keeps following its instances until the catalog's broadcast ends, which then idles its renditions and holds their pads. The catalog's own follower ends once its readers drain.
Reader: one task per (rendition, instance). It subscribes, claims the rendition's pad, and streams until its track ends, its instance goes, or the follower cancels it. Its exit goes back to the follower that owns it. Readers stay separate tasks so a push blocked downstream never stalls another rendition.
Pads: the pad table records which renditions the latest catalog lists.
- A claim refuses an unlisted rendition, checked under the same lock the update takes.
- Delisting a rendition retires its pad. The retirement waits for the reader to let go, then checks the listing again, so a relist in between keeps the pad.
- This replaces the PumpState compare-exchange.

Whether a rendition is reading, idle, or draining is now follower state, not a task. So the held CodeRabbit Major (discussion_r4345973572: a pump that returned but was not yet joined sat in active, so a relist in that window started nothing) cannot happen. A relist always reaches the follower that owns the rendition.

One window remains: a delist and a relist that the plan watch folds into one update while a reader goes to claim its pad. The claim reports that the rendition was unlisted, and the follower starts the reader again if the catalog lists it by then.

Earlier moqsrc sibling-state findings, under the new design

Restarted sibling renditions each set their own timeline (discussion_r4345693018): the follower holds one timeline per instance and hands it to every reader on that instance. No run-wide registry is left, so nothing outlives the path's follower (discussion_r4354840070).
A rendition still subscribing when a replacement took over kept the old timeline (discussion_r4345772628): a takeover cancels every reader, and the new readers start with the new instance's timeline.
A finished sibling track ended the rendition (discussion_r4345772641): a reader's exit leaves the entry idle until the next Start.
A delisted rendition idling on a finished track restarted on the next instance (discussion_r4345862971): a delisted entry without a live reader is removed, so no later instance starts it.
finished keyed by path silenced later instances after a reshape (discussion_r4345884091, discussion_r4345959760): the follower records the serving instance's number, and each reader checks it for its own instance. No broadcast clone is held (discussion_r4354840075).

Docs

doc/bin/gstreamer.md and doc/concept/hang.md say moqsrc follows sibling announcements. The quest is deleted, and the epoch epic carries its own size again.

Public API and wire

moqsrc: sibling renditions restart and idle on announcements (behavior only).
Wire: none.

Tests

Relist after a reader exited:
- a_sibling_rendition_relisted_while_draining_does_not_replay_its_finish (new, discussion_r4355432451).
- a_sibling_no_rendition_reads_does_not_outlive_its_catalog (new, discussion_r4355614370).
- a_rendition_delisted_while_subscribing_takes_no_pad_until_relisted (new relist step).
- a_relisted_sibling_rendition_follows_the_next_instance (new).
End then Start: a_late_sibling_starts_its_rendition_and_returns_after_an_end, a_reannounced_sibling_instance_does_not_replay_its_finish (new, discussion_r4355481216), and a_sibling_is_followed_past_its_catalogs_close (new; it also checks that the catalog's broadcast ending lets go of the sibling, discussion_r4355345886, discussion_r4355392186).
Replacement: sibling restart with an epoch and epochless on the same pad, and a reference naming the old epoch idling until that instance returns.
Final snapshot: a_closing_catalog_plays_the_rendition_its_final_snapshot_adds (new).
Pinned failover: a_pinned_instance_winning_its_path_back_does_not_replay_its_finish (new).
Findings, in order:
- a_rendition_joining_a_sibling_instance_shares_its_timeline (new; it fails when a reader gets its own timeline)
- a_finished_sibling_track_returns_on_the_next_instance
- a_delisted_sibling_rendition_follows_no_later_instance
- a_reenabled_sibling_rendition_plays_the_next_instance_after_a_finish (now also checks that the re-enable replays nothing on the finished instance, discussion_r4355125383)
- an_epoch_handoff_after_a_sibling_finish_plays_the_new_instance
Removed: the plan_reconcile set-math tests, a_pump_either_goes_live_or_is_cancelled, and the Siblings registry test, along with the code they covered.
No benchmark: each catalog update is a full snapshot, and the work per update is linear in it. See discussion_r4354840077.

Checks

Passed:
- cargo test -p moq-gst --lib source: 58 passed, three runs in a row.
- cargo clippy -p moq-gst --all-targets: clean.
- just check, except its flake module, which fails here building the github-runner VM image (unshare is not permitted in this environment; unrelated to this change).
Not run: just test interop --all (no wire, FFI, or gateway change).

🤖 Generated with Claude Code

(Written by Claude Opus 5.5)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Add moq_mux::Follow (Source::follow, Follow::new), built on announced_broadcast: each instance serving a sibling is handed out as it starts or takes over, and its end is reported. A reference naming an epoch follows only its own instance (best effort over epochless routes). moqsrc pumps follow their sibling: the first start binds the rendition, an end idles its pad, and another instance restarts the stream on the same pad. Exporters bind a sibling once it is first announced instead of failing, and end the rendition when that instance goes. @moq/watch drops a rendition whose broadcast proves another epoch from its effective catalog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Delete the quest, point sink-restart-follow at moq_mux::Follow, and size the now-childless broadcast epoch epic. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Public Source::bind, resolve, and subscribe_track keep answering for the routes as they stand: HLS answers per request and moq play picks renditions inline, so neither can wait on a sibling that left. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…och/reference-announcements # Conflicts: # quest/m0/broadcast-epoch/reference-announcements.md # quest/m1/reference-epoch-bindings.md # quest/m1/sink-restart-follow.md

…ollow::* Source::bind, resolve, and subscribe_track wait for a sibling nothing announces yet, through routed_broadcast, instead of failing Unroutable. A binding answers its pinned instance once the path is pinned, so a sibling that announced and then left answers its ended broadcast rather than waiting for the next. moq-hls drops its own re-issue loop, and its disconnected-sibling test now names the sibling it means to bind. Move Follow/Followed to moq_mux::follow::{Instances, Event}. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ed self-follow moqsrc renditions restarting on the same sibling instance now share that instance's timeline, so audio and video fix one segment mapping instead of each starting from its own first frame. Source::follow fails a self-reference whose epoch the catalog instance contradicts with EpochMismatch, rather than parking forever on a fixed feed no other instance can join. Binding and follow share one epoch check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

… idles Every moqsrc rendition picks its sibling instance's timeline when it starts reading it, not only once it owns a pad, so one still subscribing when a replacement takes over shares the replacement's mapping. The first instance at a path keeps the run's timeline. A sibling track finishing while its instance stays up idles the pad and keeps following, so the instance that replaces it starts a new stream there; the finish record clears once a new instance starts on the pad. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A rendition the catalog delists drains the instance it reads, then ends its pad instead of idling for, or restarting on, the sibling's next instance. One already idle when the delist lands ends right away. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

moqsrc recorded a finished track by rendition and path, so a catalog update that replaced an idle sibling pump (a disable and enable, or an epoch handoff) skipped the rendition for every later instance, leaving its pad silent. The record now keeps the instance that finished, and the pump checks it once it knows which instance it reads, instead of reconcile skipping the rendition. A sibling pump idles past a finished instance, holding its pad if it has one; the catalog's own rendition still stops. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

# Conflicts: # cpp/moq/MIGRATE.md # dart/moq/MIGRATE.md # dart/moq_ffi/MIGRATE.md # dart/moq_ffi/lib/src/moq.dart # go/ffi/MIGRATE.md # go/wrapper/MIGRATE.md # kt/moq-ffi/MIGRATE.md # kt/moq/MIGRATE.md # py/moq-ffi/MIGRATE.md # py/moq-rs/MIGRATE.md # quest/m0/broadcast-epoch/README.md # quest/m1/reference-epoch-bindings.md # rs/moq-c/MIGRATE.md # rs/moq-ffi/MIGRATE.md # rs/moq-ffi/src/consumer.rs # rs/moq-mux/MIGRATE.md # rs/moq-mux/src/container/source.rs # rs/moq-mux/src/source.rs # swift/MIGRATE.md # swift/ffi/MIGRATE.md

moqsrc keeps today's sibling handling: a rendition binds its sibling through `Source::bind`, which now waits for the first announcement and keeps that instance. Following a sibling's later instances moves to the moqsrc sibling follow quest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Each pump follows its rendition's `moq_mux::follow::Instances`: Start binds, End idles the pad, and another instance restarts the stream on the same pad with a timeline shared by every rendition reading that instance. A finished sibling track idles, recorded per instance; a delisted rendition drains its instance and ends its pad. Split from #6254 with the code its review rounds covered. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ExportSource treated any read error as the instance's end once the sibling closed, so malformed media followed by a close exported as a clean EOF. Only a transport error ends the rendition with its instance. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A transport failure such as a protocol violation read after the sibling closes failed nothing: any moq-net error counted as the instance's end. Only an orderly shutdown (dropped, cancelled, closed, going away, or a cancelled session) ends the rendition; every other error fails the export. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

`Dropped` means a producer went away without finishing, so content is incomplete rather than ended. It no longer counts as an orderly end of the sibling instance. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…enditions moqsrc kept one long-lived pump per rendition, each following its own broadcast's announcements, plus an `active` map the catalog loop diffed against. A pump that exited on its own stayed in `active` until pruned, so a relist landing in that window started nothing. Each broadcast the catalog references now gets one follower task that owns its instances (`Source::follow`) and its renditions' state: a start reads every rendition on that instance, an end idles them, a takeover restarts them on the same pads. A reader is a task per (rendition, instance), and its exit reaches the follower that owns it, so idle and draining are follower state rather than tasks. The pad table tracks which renditions the latest catalog lists, so a claim and a retirement decide under one lock, replacing the PumpState compare-exchange. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T00:06:45Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector · 2026-10-23T00:06:50Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-23T06:59:01.691748Z	`e381fb7`	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9776abfef4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

A follower per (path, epoch) needed a run-wide registry to share an instance's timeline across followers, which kept every sibling path seen in the run and parked broadcast clones in it and in the finished records. One follower per path now follows every instance and checks each rendition's named epoch itself. It numbers its instances, gives the first the run's timeline and each later one its own, and records finished tracks by instance number, so it holds no broadcast it no longer reads and forgets a path once the catalog stops referencing it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T00:20:35Z

@codex review

(Written by Claude Opus 5.5)

kixelated · 2026-10-23T00:51:13Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e940e7ea3b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2cb8230695

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

follow::Instances hands out the same instance again after it returns, and the follower treated it as a new one: a fresh serial dropped the record of a track it finished, so its last group replayed on the pad, and a fresh timeline remapped it. The follower keeps its last instance across an end. The same channel announced again keeps its readers; the same epoch served again after an end resumes with its serial and timeline. An epochless return after an end cannot prove its identity and still counts as new. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T02:44:22Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1f44597dc3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

…pdate A sibling path the catalog stopped reading kept its follower, with its instance consumers, until the next catalog update or the end of the run. A follower now wakes the run when it runs out of renditions, and the run drops it once the plan it sent last is empty and no disabled rendition names the path, the same rule an update applies. A follower with no renditions left also ends once the catalog closes, since no plan can add any. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T03:00:26Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 46ea01cbfb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

The follower kept the ended instance's consumer to recognize its return, which held the broadcast's state while the sibling stayed offline. It now keeps only the epoch, serial, and timeline across an end, and holds the consumer only while the instance serves. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T03:08:50Z

@codex review

(Written by Claude Opus 5.5)

kixelated · 2026-10-23T03:59:09Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c2bfc01f0e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

…ck switch Two ways a finished sibling track replayed its final group on its pad: - An instance a rendition pins finished its track, another instance won the path, and the pinned one won it back with a new serial. The follower now keeps the serial and timeline of each instance a rendition pins, by epoch, next to the current one, so its return resumes them. - A rendition finished one track, then another on the same instance, then switched back. The finished records now hold every track per instance rather than only the last. Records stay bounded by the instances the follower keeps and the tracks they served on listed pads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T04:40:59Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 93fad07b51

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

…tance Keeping every track a rendition finished let a publisher grow the records without bound by renaming a rendition's track and finishing each one. Keep only the last finished track per rendition and kept instance, which the catalog bounds. A rendition switched back to a track it finished before another replays that track's last group, which is the accepted cost. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T04:55:15Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9ce3862a7e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

A final snapshot and the catalog's close could reach a follower as one plan, and a closed plan started no reader, so a rendition the snapshot added or reshaped never played. The final plan now starts exactly the renditions it added or reshaped, and still restarts no reader that already ended. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T05:33:46Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector · 2026-10-23T05:38:54Z

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 3787aa6f0d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

coderabbitai · 2026-10-23T06:37:07Z

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 41 seconds.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: 456591bb-2ef5-44c5-b88f-243aec046bde

📥 Commits

Reviewing files that changed from the base of the PR and between 60e07e4 and e381fb7.

📒 Files selected for processing: 6

doc/bin/gstreamer.md
doc/concept/hang.md
quest/m0/broadcast-epoch/README.md
quest/m0/broadcast-epoch/moqsrc-sibling-follow.md
quest/m1/sink-restart-follow.md
rs/moq-gst/src/source/imp.rs

Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

#6254 landed on main. Conflicts in the docs and quest files keep this branch's side, which describes moqsrc following siblings as done, and the completed moqsrc-sibling-follow quest stays removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

kixelated · 2026-10-23T06:54:34Z

@codex review

(Written by Claude Opus 5.5)

chatgpt-codex-connector · 2026-10-23T06:59:00Z

Codex Review: Didn't find any major issues. Nice work!

Reviewed commit: e381fb747c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

kixelated and others added 14 commits October 21, 2026 20:50

quest: claim reference-announcements

9e8a3d2

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

quest: finish reference announcements

3bba0a2

Delete the quest, point sink-restart-follow at moq_mux::Follow, and size the now-childless broadcast epoch epic. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge remote-tracking branch 'origin/main' into quest/m0/broadcast-ep…

8e1e7b2

…och/reference-announcements # Conflicts: # quest/m0/broadcast-epoch/reference-announcements.md # quest/m1/reference-epoch-bindings.md # quest/m1/sink-restart-follow.md

Merge remote-tracking branch 'origin/main' into ref-ann-iterate

3910d67

kixelated mentioned this pull request Oct 22, 2026

feat(mux): follow referenced broadcasts' announcements #6254

Merged

kixelated and others added 7 commits October 22, 2026 14:33

Merge branch 'agent-aaafe-6254' into agent-aaafe-moqsrc

2800930

Merge branch 'agent-aaafe-6254' into agent-aaafe-moqsrc

a795ae5

fix(mux): a sibling's unfinished track fails the export

f6ab8e6

`Dropped` means a producer went away without finishing, so content is incomplete rather than ended. It no longer counts as an orderly end of the sibling instance. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Merge branch 'agent-aaafe-6254' into agent-aaafe-moqsrc

13c582d

kixelated marked this pull request as ready for review October 23, 2026 00:06

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

Comment thread rs/moq-gst/src/source/imp.rs Outdated

Comment thread rs/moq-gst/src/source/imp.rs

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

chatgpt-codex-connector Bot reviewed Oct 23, 2026

View reviewed changes

Comment thread rs/moq-gst/src/source/imp.rs Outdated

Base automatically changed from quest/m0/broadcast-epoch/reference-announcements to main October 23, 2026 06:37

kixelated added this pull request to the merge queue Oct 23, 2026

Merged via the queue into main with commit b9e91f2 Oct 23, 2026
11 checks passed

kixelated deleted the quest/m0/broadcast-epoch/moqsrc-sibling-follow branch October 23, 2026 14:51

kixelated mentioned this pull request Oct 23, 2026

test(interop): fail a misapplied pre-skip; clip Opus pre-skip in moqsrc #6490

Merged

Conversation

kixelated commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Design: one follower per referenced path

Earlier moqsrc sibling-state findings, under the new design

Docs

Public API and wire

Tests

Checks

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codex Review Summary

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

kixelated commented Oct 23, 2026

Uh oh!

chatgpt-codex-connector Bot commented Oct 23, 2026

Uh oh!

coderabbitai Bot commented Oct 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

kixelated commented Oct 22, 2026 •

edited

Loading

chatgpt-codex-connector Bot commented Oct 23, 2026 •

edited

Loading

coderabbitai Bot commented Oct 23, 2026 •

edited

Loading