Module decode 

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.

ExportedFrame

One decoded picture, left in the surface the hardware wrote it into.

Frame

One decoded picture, downloaded to client memory as tightly packed NV12.

Functions

probe

Checks that display’s driver can decode H.264, which is what Decoder::new needs of a render node.