Expand description
Thin VA-API H.264 decoder built on the vendored libva binding.
The mirror of crate::encode. It reuses the backend-agnostic bitstream
layer (crate::codec::h264) from discord/cros-codecs (BSD-3-Clause) for
SPS/PPS/slice parsing, reference marking, and DPB bumping, then drives libva
directly rather than vendoring cros-codecs’s generic multi-backend decoder
framework. The per-picture and per-slice VA buffer population is ported from
cros-codecs’s decoder/stateless/h264/vaapi.rs.
Feed Decoder::decode one Annex-B access unit at a time. Its picture is
submitted and completed before the call returns, rather than when the next
unit’s first slice arrives, so the hardware is never left holding a
half-submitted picture between calls.
Output trails input, and by more than the stream’s reorder depth: C.4.5.3
bumps the DPB only when a new picture needs the slot, so the delay follows
the sequence’s reference and reorder limits. A stream coded with three
reference frames trails by three pictures whether or not it uses B-frames.
Frame therefore carries the timestamp of the access unit it was coded in,
and Decoder::flush is what releases the tail at the end of a stream.
Progressive 8-bit 4:2:0 only: a sequence that is interlaced, deeper than 8
bits, or not 4:2:0 is rejected rather than decoded wrongly. That covers every
stream this crate’s encoder, WebRTC, or a browser’s VideoEncoder produces.
Left and top cropping are rejected; right and bottom cropping are supported.
Structs§
- Config
- H.264 decoder configuration.
- Decoder
- A VA-API H.264 decoder. Built once, fed Annex-B access units, emits NV12.
- Exported
Frame - One decoded picture, left in the surface the hardware wrote it into.
- Frame
- One decoded picture, downloaded to client memory as tightly packed NV12.