Struct SwEncoderOptions 

pub struct SwEncoderOptions {
    pub codec: VideoCodec,
    pub width: u32,
    pub height: u32,
    pub time_base: Rational,
    pub frame_rate: Rational,
    pub bit_rate: usize,
    pub gop_size: u32,
}

Construction-time options for SwEncoder::new. width/height/ time_base must already be known — same convention as crate::elements::Scaler/crate::elements::Pacer — rather than inferred from the first frame, since avcodec_open2 needs them set before this can be opened at all.

Fields

codec: VideoCodec

width: u32

height: u32

time_base: Rational

Must match the pts unit of whatever frames this receives — e.g. crate::elements::TestVideoSource::time_base or a demuxed stream’s own time_base if this is a transcode pipeline. Deliberately not used to derive SwEncoderOptions::frame_rate (an earlier version of this did exactly that) — the two aren’t the same thing. A pts tick unit fine enough for accurate timestamps (say, microseconds) doesn’t mean a million frames actually happen per second, which 1 / time_base would wrongly claim.

frame_rate: Rational

The nominal rate the encoder uses for internal rate-control (targeting bit_rate per frame) and the frame-rate metadata it writes into the bitstream — not required to match the real interval between send_frame calls. For a source with its own genuinely fixed rate (e.g. crate::elements::TestVideoSource), that’s TestVideoOptions::framerate itself. For an irregular/VFR source (e.g. DxgiCaptureSource, whose frames arrive only on real desktop changes, capped but not paced to a fixed cadence), use its configured cap (DxgiCaptureOptions::max_fps) as the closest meaningful nominal rate — actual encoded packets still carry each frame’s real pts either way, so muxing stays correct regardless of how well this nominal rate matches the true one.

bit_rate: usize

gop_size: u32

How many frames between keyframes — AVCodecContext.gop_size directly (not a duration; multiply by frame_rate yourself, e.g. frame_rate * 2 for “roughly every 2 seconds”). Not every codec’s own default is a periodic interval at all — libopenh264 was found, building crate::elements::SegmentedMp4Muxer, to rely on scene-change detection alone and go an entire recording without a second keyframe against smoothly-changing content — so this is always set explicitly rather than left to whatever a given codec happens to default to. Matters beyond segmenting a recording, too: crate::elements::RtspSink/WebRtcTrackSink viewers/peers joining mid-stream can’t decode anything until the next keyframe, so an unbounded interval is a real join-latency problem, not just a segmenting one.

Trait Implementations

impl Clone for SwEncoderOptions

fn clone(&self) -> SwEncoderOptions

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for SwEncoderOptions

impl Debug for SwEncoderOptions

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.