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_H264_ENCODER) — and turbojpeg for JPEG.
VA-API hardware H.264 encoder for Intel / AMD GPUs via FFmpeg.
Hardware-accelerated H.264 encoding on VA-API through FFmpeg’s h264_vaapi
encoder. Frames reach the GPU by one of three entry points — a Wayland
DRM-PRIME dmabuf (encode_dmabuf), a host BGRA frame from the X11 capture
path (encode_host_argb), or already-planar pixels (encode_raw) — and an
FFmpeg filter graph runs VA-VPP (scale_vaapi) to land the pixels on the GPU
in BT.709 limited range before encode, so no colorspace conversion happens on
the CPU.
The software H.264 encoder this build resolved to, fixed by the crate features: "x264"
whenever gpl is on (libx264 wins even if openh264 is also enabled), "openh264" for
a GPL-free build. It is what the striped software path and the full-frame software fallback
under NVENC/VA-API both encode with; exposed to Python as pixelflux.SOFTWARE_H264_ENCODER.
Whether the build’s software H.264 encoder carries a 4:4:4 (video_fullcolor) request:
libx264 does (High 4:4:4, full range); OpenH264 is 4:2:0-only and encodes such a request
4:2:0. Every “is this software stream 4:4:4” decision reads it from here.
The Colorspace: field of a stream log line, from what the session negotiated rather than
what was asked for: a hardware encoder can refuse 4:4:4, and only the software encoder
carries it at full range. Shared so the X11 and Wayland logs describe an identical session
identically.