#[non_exhaustive]pub struct Config {
pub kind: Kind,
pub output: Output,
pub scale_hint: Option<Size>,
}Expand description
Decoder configuration: the codec implementation and the frames it hands back.
Nothing here is about the track: where a Consumer
starts and how far it may lag live are its Options.
#[non_exhaustive]: build via Config::new (or default()) and set the
optional fields, so future knobs don’t break callers.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.kind: KindWhich backend to use.
output: OutputWhere decoded pictures live.
Output::Native hands back whatever the backend decoded into: a
CVPixelBuffer from VideoToolbox, a Direct3D11 texture from Media
Foundation, a CUDA buffer from NVDEC, a DMA-BUF from VAAPI, CPU I420 from
OpenH264. A consumer that draws imports those directly (render::Renderer),
and a transcoder re-encodes them in place. Output::Cpu delivers every
picture as Surface::I420: a backend that can
decode straight to system memory does, the rest download each picture.
Ask for it when the pixels are headed for the CPU anyway, since a GPU
surface handed out and downloaded later costs an allocation the backend
could have skipped.
scale_hint: Option<Size>Ask the decoder to scale its output to this size (both dimensions even) instead of the stream’s native one.
A hint, not a contract: a hardware decoder with a built-in scaler (NVDEC)
honors it for free, every other backend ignores it, so the frames still
carry whatever size they decoded at. A caller that needs exactly this
size checks each Frame::size and applies
Frame::resize to the rest; the hint only lets a
decoder that can make that a no-op do so.