fn anchor_count(
codec: Codec,
api_major: u32,
invalidation: bool,
ltr: Option<i32>,
dpb: u32,
acknowledged: bool,
) -> usizeExpand 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.