docs(doc): document moq-video and moq-audio - #2567
Conversation
Neither crate had a documentation page, despite the renderer (#2552), playback (#2529), and echo cancellation (#2538) all landing in the last two weeks. That is the last non-hardware item on the #2481 adoption gate: iroh-live's users have to be able to find this stack before they delete theirs. Each page covers the whole crate rather than appending a section, since there was nothing to append to: the role modules, the feature flags and what pulling each one in costs, the backend set and its degrade-at-runtime rule, and short examples for publish, subscribe, render, playback, and AEC. Refs #2481 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @kixelated, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
|
Warning Review limit reached
Next review available in: 11 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughAdds documentation for the 🚥 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@doc/lib/rs/crate/moq-audio.md`:
- Around line 77-89: Make the playback example self-contained by importing the
required decode module and initializing audio as the documented decode::Consumer
before it is used for sample_rate, channels, and read. Keep the existing
playback::Engine, playback::Config, playback::Input, and sink.write flow
unchanged.
- Around line 26-29: The native dependency descriptions in both pages overstate
the stack as entirely pure Rust with no system requirements. Update the wording
at doc/lib/rs/crate/moq-audio.md lines 26-29 and doc/lib/rs/index.md lines 92-95
to consistently distinguish Rust-based components from platform audio
dependencies, codec requirements, and possible native/toolchain needs,
preserving the references to unsafe-libopus, cpal, rubato, sonora, and ALSA
where applicable.
In `@doc/lib/rs/index.md`:
- Around line 87-88: Update the crate overview description to explicitly limit
system-audio capture to macOS, using wording such as “microphone and macOS
system-audio capture” while preserving the existing codec, playback, and
echo-cancellation details.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 6b69f71c-8ccb-49bd-8b5a-f8725830c57d
📒 Files selected for processing (5)
doc/.vitepress/config.tsdoc/lib/rs/crate/index.mddoc/lib/rs/crate/moq-audio.mddoc/lib/rs/crate/moq-video.mddoc/lib/rs/index.md
An adversarial review caught three places where the new page promised more than the backends deliver: - openh264 was described as the end of every fallback chain. It registers for H.264 only, so H.265 with no usable hardware backend returns NoEncoder / NoDecoder rather than degrading. - Zero-copy was written as a property of hardware decoding generally. The renderer imports only Surface::PixelBuffer, so it is macOS-only today; a CUDA frame is downloaded before upload, and the Media Foundation decoder downloads its DXVA texture and hands back I420. Replaced with a per-platform matrix separating transcode from render, pointing at #2481 for the Vulkan/EGL importers and the Windows surface retention. - Color was described as carried end to end. VUI does not survive decoding and neither Windows nor CUDA surfaces report color, so the renderer infers from resolution. Documented the fallback and pointed at render::Config::color. Also drops a "pure-Rust fallbacks" line: openh264 is vendored C++, unlike moq-audio's stack. Refs #2481 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- "Everything is pure Rust ... no system codec anywhere in the graph" read as a promise that a Linux build needs nothing installed. The codecs and DSP really are Rust, but cpal links ALSA, so a build with `capture` or `playback` needs libasound headers. Says which part is which now. - System-audio capture is macOS-only (ScreenCaptureKit); the crate page scoped it but the library overview did not. - The playback example used an `audio` that appeared from nowhere. It now builds the decode::Consumer it documents, matching the subscribe example on the video page. Refs #2481 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1 participant
Summary
moq-videonormoq-audiohad a documentation page, so the renderer (feat(moq-video): render decoded frames on the GPU, and carry color spaces end to end #2552), playback (feat(moq-audio): play decoded PCM out a speaker #2529), and echo cancellation (feat(moq-audio): cancel the speaker's echo out of the microphone #2538) that landed over the last two weeks are undiscoverable outside docs.rs. This is the last non-hardware item on the Merge iroh-live's native media stack into moq-video/moq-audio (upstreaming plan) #2481 adoption gate: iroh-live's users need to find this stack before they delete theirs.moq-videodocuments the zero-copy story as a per-platform matrix rather than a blanket claim: macOS decodes to aPixelBufferand both transcodes and renders zero-copy, Linux transcodes NVDEC straight into NVENC but downloads for render, and the Media Foundation decoder downloads its DXVA texture today. The gaps point at Merge iroh-live's native media stack into moq-video/moq-audio (upstreaming plan) #2481. Also coversSurface::into_i420()as the universal fallback and thewgpu::Textureintegration seam.NoEncoder/NoDecoderwith no usable hardware backend),dlopenapplies to the Linux backends, and the renderer infers color from resolution when a surface carries none, since VUI does not survive decoding.moq-audiodocuments theEngine/Sinksplit,Sink::buffered()as the A/V pacing signal, and the AEC wiring (Engine::canceller->capture::Config::aec) with its 10 ms cost and microphone-only scope.Public API changes
None. Documentation only; no crate touched.
Cross-package sync
No rows apply: nothing under
rs/changed, so there is no paired package or draft to update. This PR is thedoc/half of the #2481 gate for work that already landed.Test plan
bun run checkindoc/(tsc + VitePress build, which fails the build on dead links) passes.bun remark doc --quiet --frailpasses.bun biome check doc/.vitepress/config.tspasses./codex:adversarial-reviewpass challenged the capability claims; all three findings were verified against the backend registrations and the renderer's import path, and the prose was corrected in a follow-up commit.capture::Config::sourceis aSource, not anOption<Source>, anddecode::Consumer::newtakes the rendition'sVideoConfig, not the catalog producer).Refs #2481
(Written by Opus 5)