Module software 

CPU-based striped H.264 (libx264 or OpenH264, by build) / JPEG encoder with per-stripe change detection. CPU-based striped encoder: H.264 through the build’s software encoder — libx264 with the gpl feature, Cisco OpenH264 without it (software_encoder) — and turbojpeg for JPEG.

Frames are split into horizontal stripes processed in parallel via rayon. Each stripe is independently hashed against the previous frame for change detection, and only dirty stripes are encoded. The H.264 path maintains per-stripe encoder state across frames for inter-prediction, and both libraries emit the same per-stripe wire framing; the JPEG path is stateless.

Structs

EncodedStripe

One encoded stripe: the compressed bytes plus geometry and identity metadata.

FrameTiming

When a frame was captured and when its encode began and ended, as CLOCK_MONOTONIC nanoseconds, so a consumer can attribute a frame’s age to the host rather than the network or the decoder. An encoder leaves them zero; the capture that ran it stamps every stripe of the frame.

H264EncoderWrapper

One long-lived libx264 session for a stripe, holding the raw x264_t handle alongside a mirror of its live parameters so the encoder can be retuned per frame instead of rebuilt.

StripeState

Everything one horizontal stripe must remember between frames: its reused buffers, its own live encoder, and the motion / paint-over / damage bookkeeping that drives its send decision.

Constants

MAX_STRIPE_CAPACITY

Upper bound on the horizontal stripes the CPU encoder splits a frame into, so the persistent per-stripe state vector can be reserved to a fixed capacity once, up front.

Functions

acknowledge_reference

Every consumer holds frame frame_id, or where not held was sent it: OpenH264 confirms the long-term reference it marked there. x264 keeps none.

encode_cpu

The software encoder’s per-frame entry point: split the frame into horizontal stripes, decide per stripe whether it needs sending, and encode only those as JPEG or H.264 (libx264 or OpenH264, by build) across the rayon pool.

invalidate_reference

How many horizontal stripes a frame of height is split into, which is the choice of how much encode parallelism to spend on it.

stripe_bit_depth

The bits per sample the striped H.264 path codes settings at: 10 where they ask for it and the build’s libx264 opens such a session, else 8.

stripe_count

stripes_held_still

Whether a frame that holds still codes a stripe at the paint-over quality instead of the session’s (encode_cpu): at a constant quality, a stripe whose cleanup falls due, whose burst is held, or which keeps the quality it was cleaned up at. A constant rate holds none there.

stripes_hold_quantizer

Whether the striped software path holds a stripe’s cleanup at the quantizer asked for: libx264 does under either rate control, and OpenH264 moves its quantizer only at a constant quality (Openh264Encoder::update_qp), so a stripe that holds none is cleaned up by a refresh and burst at its rate control’s own quality, never a key frame, which that would starve.