Repository navigation
fix(mux): start fMP4 passthrough video at a sync sample - #6743
Conversation
Quest-Claim: 59c0063404e1a60d
A passthrough video track joined mid-GOP, at the start or after a seek, published its leading non-sync samples as the start of a group. Video tracks now start orphaned, and seek orphans them again, so both modes drop samples until the next sync sample through the edit-list rule. The unwrapped path's MissingKeyframe skip is unreachable and goes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
kixelated
left a comment
There was a problem hiding this comment.
Automated review by review (OpenAI)
Reviewed commit: 78dac27
No actionable bugs found in the changed code. Reusing the orphaned-sample filter for initial joins and seeks is a focused fix: both output modes wait for a sync sample, while passthrough trimming preserves retained samples' decode/composition timing. Removing the downstream MissingKeyframe swallow follows from that shared invariant without a second mechanism.
Verification: static review of the patch and surrounding filtering, fragment rewriting, grouping and producer code. The regression covers whole-fragment drops, a sync sample inside a fragment and post-seek drops in both modes. I did not run tests or independently verify reported test results.
|
Warning Review limit reachedYou'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 30 minutes. View limit details
No actionable comments were generated in the recent review.
|
|
Landing as is: CI is green, Codex and the OpenAI review of 78dac27 found nothing actionable, and (Written by Claude Opus 5.5) |
# Conflicts: # quest/m1/README.md
|
Left the merge queue on a conflict with main. Merged main: only (Written by Claude Opus 5.5) |
Summary
An fMP4 passthrough video track that joined mid-GOP published its leading non-sync samples as the start of a group, frames a decoder cannot use. The unwrapped path already skipped them.
Both modes now share one rule, the
Fmp4Track::orphanedflag from moq-dev/moq#6686: a video track starts orphaned, sorundrops every sample until the first sync sample. A fragment that starts mid-GOP and reaches a sync sample is trimmed through the existingkeptrewrite, so passthrough opens its group on the sync sample.Choices made without asking:
Import::seekorphans video tracks too, since a seek is the other mid-stream join. Before, passthrough opened the seeked group on whatever fragment came next; unwrapped skipped viaMissingKeyframe.MissingKeyframeswallow is unreachable, so it is gone and an unexpected one now fails loud.unwrapno longer reports whether a group opened; a skipped fragment never reaches it.Impact
fmp4::Import::seekdocs now say video resumes at its next sync sample.Tests
video_joined_mid_gop_starts_at_a_sync_samplecovers both modes: a fully non-sync first fragment, a fragment whose sync sample is in the middle, and a mid-GOP fragment afterseek. Before the fix, passthrough failed it.just rs test -p moq-mux: 1743 passed.just check: passed (the one shear warning, an unlinkedmoq-audiofile, predates this branch).Closes the quest
quest/m1/fmp4-passthrough-sync.md.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code