Skip to main content

Module reference

Module reference 

Source
Expand description

Which frame a delivered frame predicts from, kept true across the frames a client reports lost.

Structs§

KeyAge 🔒
How far a frame id lies behind the newest frame recorded, in capture frames counted across the id’s wrap, and whether it went out at or after the last key frame. A session can run far longer than the id takes to wrap between key frames, so the ids alone cannot order a frame against the key.
ReferenceSlots
The buffers a VP8 or VP9 encoder predicts from, with the frame each holds and whether a client reported it lost.
ReferenceWindow
The reference frames a session’s decoder holds, in encode order, with the ones a client reported lost marked.
SlotPlan
How the next frame predicts and which buffers it refreshes.
SlotRefresh
The buffers a frame refreshes, as a bit per slot: LAST, GOLDEN, ALTREF for VP8, the eight in order for VP9.

Enums§

Invalidation
What an invalidation asks of the encoder.
Reference
The frame a delivered frame predicts from.
ReferenceReport
What the consumers say of a frame, applied in the order they said it ahead of an encode.

Constants§

ANCHORS
The most long-term frames a window keeps as anchors, out of the decoded picture buffer, so a loss older than every recent frame still finds one before it.
ANCHOR_ALONE_EVERY 🔒
One anchor takes a frame every ANCHOR_ALONE_EVERY frames after a key frame: a loss just before it is reported once it has moved on, which a longer period makes rarer.
ANCHOR_EVERY 🔒
Two anchors take a frame every ANCHOR_EVERY frames after a key frame by turns, the lost or older one first, so one is always twelve to twenty-three frames old.
ANCHOR_PERIOD 🔒
VP8’s GOLDEN and ALTREF each take every ANCHOR_PERIODth frame, half a period apart.
HOLD_LAG 🔒
A lone anchor every consumer holds is not marked over while the newest frame they were all sent runs more than HOLD_LAG frames ahead of the newest they all hold, as when a consumer’s link goes dark: a consumer reporting its loss once it is back is predicted past only from an anchor it holds. Past HOLD_MAX frames it is marked over all the same, a consumer that far behind taking a key frame.
HOLD_MAX 🔒
PENDING_PERIODS 🔒
The schedule keeps an anchor every consumer was sent until they all hold it, for up to PENDING_PERIODS anchor periods: a consumer slower to report than a period, as one on a narrow link is, would otherwise never see an anchor pinned past the key frame.
RECENT_FRAMES 🔒
How many recent frames are remembered by id, about eight seconds at 60 frames a second: a consumer whose clients hold a pinned anchor may report a run lost that long ago and have it predicted past (acknowledge); the anchors alone reach twenty-three back.
REFERENCE_FRAMES
How many frames back a prediction may reach: the decoded picture buffer every session asks for, where its level admits it.
RING 🔒
VP9 keeps the last RING frames, and every RINGth frame in as many buffers again.
SETTLE_RECENT 🔒
Of two anchors, the one marked predicts from the frame every consumer was sent (settle) only where that is one of the SETTLE_RECENT newest recent frames, which the buffer keeps beside two anchors on every device (nvenc::anchor_count). Further back the anchor costs the moving picture: NVENC’s HEVC on a 1080p page scrolling at 8 Mbit/s, every consumer’s acknowledgement late, averaged 49.3 dB from two frames back, 49.0 from three, 38.5 from four and 27.4 from the other anchor a period back (the frame sent to all of them past the recent ones), against 49.7. The anchor predicts from the frame before it then, and a consumer that loses frames is predicted past from the pinned anchor on its own report.
SETTLE_SLACK 🔒
An anchor predicts from the newest frame every consumer was sent (settle) only within an anchor period and SETTLE_SLACK frames of it, a consumer that took the last anchor. One further behind, for which every anchor would predict from far back and cost every consumer the bits, is predicted past on its own report instead (from the pinned anchor, where it comes to that). The frame where H.264’s frame_num wraps reaches back however far: a decoder that misses it cannot be predicted past.

Functions§

frame_num_range_line
The line saying the frame_num range an H.264 key frame carries, where it differs from the one the stream carried before (0 for none yet); None where it is the same or unknown (0).