Struct ExactFrameReader 

pub struct ExactFrameReader { /* private fields */ }

Presentation-indexed exact-frame access over decode-order compressed samples.

Implementations

impl ExactFrameReader

pub fn new( factory: &dyn VideoDecoderFactory, configuration: VideoDecoderConfig, samples: Vec<EncodedVideoSample>, limits: Limits, ) -> Result<Self>

pub fn set_seek_previews( &mut self, previews: Option<Arc<dyn SeekPreviewSource>>, )

Attaches (or, with None, detaches) the preview source Self::seek answers from.

The source is normally a zvidlib::previews::PreviewIndex filling itself on a decoder of its own, and it is shared rather than owned so a reader can start answering seeks from it while its pass is still walking the track.

pub fn seek(&mut self, presentation_index: FrameIndex) -> Seek

Answers “what is at this position of the timeline” without decoding anything.

This is the seek path, and it is bounded by ARCHITECTURE.md section 3.2: it takes the same time whichever position of whatever track it is asked about, because it only ever looks at pictures that are already decoded. It reads the presentation cache first - a seek back to somewhere the reader has just been is exact for nothing - and then the attached seek preview index, and it returns Seek::Pending rather than blocking when neither holds anything.

Reaching the exact frame is Self::get, which is unbounded by construction: the frame depends on every frame back to its random-access point and they all have to be decoded. A caller that wants both draws what this returns and walks to the exact frame behind it.

pub fn get( &mut self, presentation_index: FrameIndex, cancellation: &CancellationToken, ) -> Result<VideoFrame>

Returns exactly the requested presentation frame, and the frames behind it that the cache can hold, so a request that comes back for one of those is answered for nothing.

This is the destination of a seek. A walk that is going to keep walking forwards should ask for its intermediate frames with get_step instead, which converts the frame it was asked for and nothing else.

pub fn get_step( &mut self, presentation_index: FrameIndex, cancellation: &CancellationToken, ) -> Result<VideoFrame>

Returns exactly the requested presentation frame and converts nothing else.

A step is a picture on the way to somewhere, not somewhere: the caller is going to ask for a frame further forward next, so the frames behind this one that get would keep are converted for a request that never comes. That tail is bounded per call and so is affordable for one seek, but a walk that publishes as it goes pays it once per published picture, and once the stride is shorter than the tail the tails overlap and the walk converts every picture it passes rather than the few it publishes (issue #402).

Frames at or after the target in presentation order are still kept, exactly as get keeps them: on a stream with B-pictures those are the reordered frames the next request asks for, and dropping them would reset the decoder and re-walk the group of pictures.

pub fn drain(&mut self, cancellation: &CancellationToken) -> Result<usize>

Drains delayed output into the bounded presentation cache.

pub fn reset(&mut self) -> Result<()>

Clears decoder, reorder, and frame-cache state.

pub const fn statistics(&self) -> DecodeStatistics

pub fn cached_frames(&self) -> usize