moq_video/lib.rs
1//! Native video capture, encoding, and publishing for Media over QUIC.
2//!
3//! Counterpart to [`moq-audio`](https://crates.io/crates/moq-audio) for
4//! video tracks. Sits on top of [`moq_mux`] (and the `hang` catalog) and
5//! adds the native pieces a desktop/CLI publisher needs:
6//!
7//! - [`capture`] describes a frame source ([`capture::Config`]) and grabs
8//! frames via libavdevice. Today that's a webcam (avfoundation / v4l2 /
9//! dshow); screen capture would slot in here too.
10//! - [`encode`] H.264-encodes frames and publishes them through
11//! [`moq_mux::codec::h264::Import`], which handles catalog registration
12//! and framing. Two entry points:
13//! - [`encode::publish_capture`] captures a webcam and publishes it (turnkey).
14//! It encodes strictly on demand: the track and catalog are advertised up
15//! front, but the camera opens only while a subscriber is watching and is
16//! released when the last one leaves.
17//! - [`encode::Producer`] publishes H.264 you encoded yourself.
18//!
19//! The decode/consume side (the mirror of `moq-audio`'s `AudioConsumer`) is
20//! not implemented yet; native subscribers can keep using `moq_mux` directly.
21//!
22//! ## API stability
23//!
24//! The public API is deliberately ffmpeg-free: no public type, signature, or
25//! error variant names an `ffmpeg-next` type. [`encode::Encoder`] takes raw
26//! RGBA bytes (not an ffmpeg frame), the camera capture/encode path stays
27//! internal, and [`Error::Ffmpeg`] carries a plain message.
28//! So a major `ffmpeg-next` bump is not a breaking change for consumers, and
29//! we don't re-export `ffmpeg-next`. Config structs are `#[non_exhaustive]`:
30//! build them via `default()`/`new()` and set fields, so new options stay additive.
31
32pub mod capture;
33pub mod encode;
34
35mod error;
36
37pub use error::Error;