Skip to main content

anchor_count

Function anchor_count 

Source
fn anchor_count(
    codec: Codec,
    api_major: u32,
    invalidation: bool,
    ltr: Option<i32>,
    dpb: u32,
    acknowledged: bool,
) -> usize
Expand description

Persistent anchors only where the negotiated API exposes them, the device can invalidate references and the DPB leaves two recent pictures beside them. AV1 gained the LTR fields in SDK 13; drivers negotiated down to an older API keep the unanchored path. AV1 keeps one, a frame every forty-eight, unless the consumer acknowledged what its clients hold and the device has room for two: then the newest every client holds is pinned beside the one the schedule marks. H.264 keeps one whatever the consumer says: OpenH264’s decoder, Firefox’s for WebRTC H.264 where it has no FFmpeg that decodes it, finds a long-term picture of a CABAC stream by a number no marking sets, so of two it reaches only the first, and decodes a frame naming the second against another picture without an error; and a key frame marked long-term leaves a second index past MaxLongTermFrameIdx besides.