Skip to main content

FrameDataSource

frame_source

Trait FrameDataSource 

Source 
pub trait FrameDataSource {

Show 13 methods    // Required methods
    fn width(&self) -> u32;
    fn height(&self) -> u32;
    fn frame0_time(&self) -> Option<DateTime<FixedOffset>>;
    fn average_framerate(&self) -> Option<f64>;
    fn skip_n_frames(&mut self, n_frames: usize) -> Result<()>;
    fn estimate_luminance_range(&mut self) -> Result<(u16, u16)>;
    fn has_timestamps(&self) -> bool;
    fn timestamp_source(&self) -> &str;
    fn decode_order_iter<'a>(
        &'a mut self,
    ) -> Box<dyn Iterator<Item = Result<FrameData>> + 'a>;

    // Provided methods
    fn camera_name(&self) -> Option<&str> { ... }
    fn gamma(&self) -> Option<f32> { ... }
    fn srt_truncation(&self) -> Option<SrtTruncation> { ... }
    fn presentation_order_iter<'a>(
        &'a mut self,
    ) -> Result<Box<dyn Iterator<Item = Result<FrameData>> + 'a>> { ... }

}
Expand description

A source of FrameData

The frame0_time method return value is an Option because we want to be able to parse sources without an absolute time for the first frame, such as normal MP4 video files. Similarly, we do not have a len method indicating number of frames because some sources (e.g. an .h264 file) do not store how many frames they have but rather must be parsed from beginning to end.

Required Methods§

Source

fn width(&self) -> u32

Get the width of the source images, in pixels.

Source

fn height(&self) -> u32

Get the height of the source images, in pixels.

Source

fn frame0_time(&self) -> Option<DateTime<FixedOffset>>

Get the timestamp of the first frame.

Note that (in case they can differ), this is the time of the first frame rather than the creation time in the metadata.

Source

fn average_framerate(&self) -> Option<f64>

Get the average framerate

Value in frames per second.

Source

fn skip_n_frames(&mut self, n_frames: usize) -> Result<()>

Set source to skip the first N frames.

Note that this resets frame0_time accordingly.

Source

fn estimate_luminance_range(&mut self) -> Result<(u16, u16)>

Scan over the input images and estimate the luminance range

Returns Ok<(min, max)> when successful.

Source

fn has_timestamps(&self) -> bool

Whether timestamps are available.

If no timestamp is available, the frame “timestamp” with contain a fraction of completeness.

Source

fn timestamp_source(&self) -> &str

A string describing the source of the timestamp data

Source

fn decode_order_iter<'a>( &'a mut self, ) -> Box<dyn Iterator<Item = Result<FrameData>> + 'a>

Get an iterator over all frames in decode order (the order samples are stored in the stream).

For streams with B-frames this is not presentation order: the reported per-frame Timestamps are not monotonic in this order. Decode order is what you want when feeding an H.264 decoder or re-muxing an H.264 bitstream (where reordering is reconstructed from per-sample composition offsets). If you want frames in display order, use Self::presentation_order_iter.

Provided Methods§

Source

fn camera_name(&self) -> Option<&str>

Source

fn gamma(&self) -> Option<f32>

Source

fn srt_truncation(&self) -> Option<SrtTruncation>

Set when an SRT-file timestamp source ran out of usable stanzas before covering every frame in the container, in which case the source was truncated to the last complete group of pictures a stanza is available for every frame of. None for sources not using an SRT file, or when the SRT covered every frame.

Source

fn presentation_order_iter<'a>( &'a mut self, ) -> Result<Box<dyn Iterator<Item = Result<FrameData>> + 'a>>

Get an iterator over all frames in presentation (display) order, with monotonically non-decreasing timestamps.

The default implementation is the identity over Self::decode_order_iter, which is correct for every source without inter-frame reordering (FMF, TIFF, and H.264 without B-frames). Sources that can reorder (H.264) override this to buffer and reorder frames.

Returns an error up front when display order cannot be recovered (e.g. a raw Annex B .h264 stream carrying neither per-sample timestamps nor a decodable picture order count), so callers fail loudly rather than silently receiving decode order.

Implementors§