fix(mux): derive missing video geometry - #2840
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9ec6e875c3
ℹ️ 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".
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
🚧 Files skipped from review as they are similar to previous changes (3)
WalkthroughThe change resolves video geometry from catalog metadata, codec descriptions, and encoded payloads. fMP4 and MKV exporters now wait for required geometry before emitting initialization headers. Legacy fMP4 synthesis uses resolved video configuration and rejects missing or invalid dimensions. AV1 sequence-header parsing now supports dimension extraction. Tests cover dimension discovery, initialization delays, error handling, and shared VP8 configuration setup. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches✨ Simplify code
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. Comment |
9ec6e87 to
bd1c8c6
Compare
Co-Authored-By: GPT-5 <noreply@openai.com>
Teach the one-shot fMP4 muxer to wait for and derive missing video geometry before synthesizing an init segment, so fetch-on-demand HLS can bootstrap dimensionless VP8/VP9/AV1 catalogs from their keyframes. Share the codec parser with the streaming exporter and cover the HLS path with real VP8 media. Co-Authored-By: GPT-5 <noreply@openai.com>
Treat permanent codec metadata parse failures as export errors instead of waiting indefinitely for dimensions that can never be resolved. Co-Authored-By: GPT-5 <noreply@openai.com>
1b19ec7 to
f4b26da
Compare
Summary
The root cause was that catalog dimensions are optional and may arrive independently from media, but the exporters treated codec readiness as sufficient to freeze their headers. A codec-only catalog could therefore produce a permanent 0x0 fMP4 init segment or an MKV header without geometry. The one-shot fMP4 path instead failed before fetching media because it tried to synthesize its init segment immediately. Both cases occur with in-tree RTC VP8/VP9 publishers, which do not currently put dimensions in the catalog.
Fixes #2797.
Public API changes
moq-mux.Test plan
nix develop --command just fixnix develop --command just checknix develop --command just test(1,192 Rust tests and 50 Python tests passed)No wire format or public catalog API changed, so the cross-package wire/draft sync rows do not apply.
(Written by GPT-5)