Module vaapi 

VA-API hardware sessions on a DRM render node, driven through libva directly. VA-API hardware sessions on a DRM render node for every video codec, driven through libva directly.

The session owns what a hardware encoder needs owned: the surfaces, the parameter buffers, and, for the codecs that take them, the packed headers, so it also owns each picture’s reference lists. A frame a client lost is left out of the predictions the way NVENC and libx264 allow (encoders/reference.rs): H.264 and HEVC keep the decoded picture buffer the level admits and name the newest surviving frame in the slice header, VP9 and AV1 address their eight buffer slots, and VP8 steers its three buffers. A driver that writes its own slice headers predicts from the previous frame alone, so such a session declares a one-frame buffer.

Pixels reach the codec on a VA surface – a Wayland dmabuf imported in place, or a packed host frame uploaded – and the video processor converts to the surface format on the GPU, so no colorspace conversion happens on the CPU. Chroma follows video_fullcolor where the codec carries 4:4:4 (HEVC, and VP9 as profile 1), and the sample depth video_bit_depth where the driver encodes the codec’s 10-bit profile (HEVC Main 10 and Main 4:4:4 10, VP9 profiles 2 and 3, AV1), a session staying at 8 bits where it does not. A 4:4:4 session tries the surface formats the driver allocates and its video processor renders, read through a VAProfileNone configuration, until one survives the surface pool, the convert, and the codec open. Every session converts with the BT.709 matrix the sRGB source’s own primaries and transfer belong to, at limited range, and declares it; VP8 is held to BT.601, the only matrix its bitstream can name. libva itself is loaded at run time, so the host’s copy serves the driver it was built for, and a test can put its own functions behind the same table.

The constant quantizer runs uncapped where a caller asks for a capped one (RateSettings::capped): the rate-control mode is fixed with the session’s configuration (VAConfigAttribRateControl), so a constant-quantizer session takes no peak, nor goes over to a constant rate while one binds, as NVENC’s does, short of a new configuration and the key frame it opens with.

Modules

av1 🔒

The AV1 arm: the sequence and picture parameters, the packed sequence header and frame header OBUs, and the tile group behind them. Main profile, one tile group of as many tiles as the picture width needs, and the eight buffer slots addressed by timestamp: every frame refreshes its own slot and names the slot of the newest frame the client still has as all seven of its references, which is also where its probability contexts load from. The frame header is written with the bit positions of the quantizer, loop filter, and CDEF fields, which a constant-rate driver rewrites in place and a constant-quantizer session fills itself, and with OBU sizes of the fixed width it asks for.

h264 🔒

The H.264 arm: the sequence, picture, and slice parameters, the packed SPS, PPS, and slice headers, and the reference lists behind them. The stream is High profile with CABAC and the 8x8 transform where the driver serves High, a single reference per slice, and a decoded picture buffer of the frames the level admits: a frame predicts from the newest one the client still has, which the slice header’s reference list modification names whenever that is not the previous frame.

h265 🔒

The HEVC arm: the sequence, picture, and slice parameters, the packed VPS, SPS, PPS, and slice headers, and the reference picture set behind them. Main profile, Main 10 at 10 bits, or the range extensions’ Main 4:4:4 and Main 4:4:4 10 for a 4:4:4 session, with the coding tools and block sizes the driver reports, one reference per slice, and a decoded picture buffer of the frames the level admits: every slice header carries an explicit short-term reference picture set naming the frames the decoder keeps, with the newest one the client still has as the one used. Where the driver says a predicted slice has to carry both reference lists (VA_PREDICTION_DIRECTION_BI_NOT_EMPTY, Intel’s low-power encoder), a predicted frame is a B slice whose two lists name that same frame, which codes what a P slice would: such an encoder fails a P slice on some generations and takes it on others.

vp8 🔒

The VP8 arm: the sequence and picture parameters and the quantizer matrix; the driver writes the frame header. The three buffers, LAST, GOLDEN, and ALTREF, follow the session’s slot plan, and no frame updates the entropy probabilities, so a frame a client lost leaves nothing behind that a later one depends on.

vp9 🔒

The VP9 arm: the sequence and picture parameters; the driver writes the uncompressed header. The eight buffer slots hold the last eight frames by timestamp, a frame refreshes its own and predicts from the slot of the newest frame the client still has, and every frame is coded in the error-resilient mode, since a decoder otherwise takes the previous frame’s motion vectors and probability contexts whatever the reference says.

Structs

Buffers 🔒

The parameter buffers of one picture, in the order they are rendered.

ColorDescription 🔒

A color description as the video processor is told it: the ISO/IEC 23091-2 code points and the range, and whether the picture is RGB, whose matrix is fixed.

Device 🔒

A VA display opened on a render node, terminated with the device.

Frame 🔒

One frame as the codec arms see it: what it is, where its reconstruction and coded output go, and what it may predict from.

HostUpload 🔒

The host frame’s way onto a surface: through the surface’s own image where the driver derives one, else through an image the driver copies in.

Negotiated 🔒

What the session negotiated at open, which the codec arms read.

VaapiEncoder

One VA-API encoder session, hardware, for one capture.

Enums

Arm 🔒

The codec arm of a session.

ConstantRate 🔒

What bounds the frames of a constant-rate session, by what the driver’s rate control does with each bound.

Input

How frames reach a session: a Wayland DRM-PRIME dmabuf, or packed host pixels in B,G,R,A (rgba: false) or R,G,B,A (rgba: true) byte order.

References 🔒

The references a session keeps: a decoded picture buffer, or VP8’s three buffers.

Constants

DMABUF_IMPORTS 🔒

The dmabuf imports a zero-copy session keeps, past the few buffers any capture cycles.

FULLCOLOR_FOURCCS 🔒

The 8-bit 4:4:4 surface formats a session tries, in order. The order only breaks a tie on a driver whose video processor renders both: every frame reaches either through the convert, so neither is nearer the host.

HELD_KEY_BITS_PER_PIXEL 🔒

The bits a pixel a held key frame of a constant rate is given at least (held_key_bits): VCE spends a frame’s budget down the picture and codes the rows it runs out on at its coarsest, so a key frame short of what the picture needs at the paint-over quality comes out sharp at the top and smeared below: 1080p text in 0.8 bits a pixel came to 271 kB at 25.5 dB (H.264, 52 dB in the top rows, 18 in the bottom ones) and 307 kB at 39.0 (HEVC), in 1.6 to 463 kB at 51.5 and 380 kB at 47.1. The driver’s best quality level for the key frame changed nothing.

IHD_AV1_BUFFER_S 🔒

Seconds of the target iHD’s AV1 rate control is given as a buffer (ConstantRate).

INTEL_VDENC_NATIVE_ROI 🔒

The zones Intel’s low-power H.264 encoder codes regions of interest in natively.

PSNR_ROW_STEP 🔒

The rows a reconstruction is compared with its source on (VaapiEncoder::last_psnr): one in this many.

REFINE_BITS_PER_PIXEL 🔒

The bytes a coded buffer holds: the uncompressed picture and some, an upper bound on any frame. The frame budget, in bits a pixel, under which radeonsi’s rate control cannot refine a still screen it says no quantizer of, so the cleanup ends on a key frame (refines). 1080p text, pixelflux alone, the cleanup through the rate control at 0.004 / 0.008 / 0.016 / 0.03 / 0.12 bits a pixel a frame: H.264 18.0 (60 fps 0.5 Mbit/s) / 30.0-38.2 / 40.1-52.6 / 43.4 / 56.4 dB, HEVC 29.1 / - / 46.2 / 33.1 / -, each the full 10 s at the session’s rate (2.1 MB at 60 fps 2 Mbit/s); a key frame at HELD_KEY_BITS_PER_PIXEL came to 51.5 dB (H.264) and 47.1 (HEVC) on 0.4-0.55 MB.

REFINE_FINER 🔒

Quality index steps finer than the paint-over one a refined block is coded at (VaapiEncoder::refines): on Intel’s iHD (N97) 1080p H.264 text beside a video went from 41.3 dB to 44.1, 45.4, and 47.1 at a constant quantizer at 0, 3, and 6 steps finer, where the driver’s cleanup of the still screen reaches 46.2; at a constant rate, held to REFINE_REACH, from 31.0 to 33.3 at 8 Mbit/s and from 19.0 to 21.1 at 2, the video unchanged.

REFINE_REACH 🔒

The most quantizer steps off the frame’s own a refined region is coded at (VaapiEncoder::refines): on Intel’s iHD (N97, H.264 on the low-power entry point, 3 Mbit/s CBR at 1080p60) a region 10 finer came out at a quantizer 7 under the rest with the rate held, 25 finer at 20 under it at 54 Mbit/s, the rate control lost; 5 finer, a delta the driver codes natively, moved nothing.

SLICES 🔒

The slices an H.264 or HEVC picture is cut into, a decoder threading a frame across them. AMD’s VCE is the exception for H.264: it codes a picture cut into four slices at less than half its one-slice rate (Radeon Pro VII, 2160p: 44.6 against 20.4 ms a frame, 1080p: 8.7 against 5.7), where its HEVC and every other engine measured here cost nothing for them. The low-power H.264 of Skylake and Broxton is the other (whole_picture_vdenc), one slice where a session takes it, which it does only where the driver offers no full entry point.

UNREADABLE_DB 🔒

The PSNR under which a reconstruction is no picture of its source (picture_psnr): the coarsest quantizer leaves a screen of text near 19 dB.

Functions

amd_vce 🔒

Whether the render node fd is an amdgpu device whose video encoder is VCE rather than VCN. The kernel reports the video blocks a device carries (AMDGPU_INFO_HW_IP_COUNT, the query Mesa reads to pick its encoder): a VCE-generation part answers for VCE and refuses the query for VCN’s encoder. Any other driver is not asked.

arm_block 🔒

The block a codec’s slices are counted in: a macroblock, or the coding tree unit.

coded_buffer_size 🔒

color_standard 🔒

The color standard a video processor is told for wanted: the explicit one where the driver takes it, since the properties then say everything; else the standard whose matrix, transfer, and primaries come closest, weighted four, two, and one, or none when nothing matches at all.

error_text 🔒

fourcc_name 🔒

The name of a surface format, for the session log.

held_key_bits 🔒

The bits a key frame held at a constant rate of bps is given for a width x height picture: HELD_KEY_BUDGET_S of the rate, and at least HELD_KEY_BITS_PER_PIXEL, the maintainer’s rule that a key frame is capped only where the cap leaves the picture good.

image_format 🔒

The driver’s image format of fourcc, with the masks it wants an image created with.

libva 🔒

The libva of this process, loaded once, or why it could not be.

log_error 🔒 ^⚠

log_info 🔒 ^⚠

object_identity 🔒

The dma-buf object fd names, as its device and inode: two fds of one buffer give the same.

probe_codecs 🔒

The video codecs the VA-API driver of the render node behind encode_node_index encodes: those one of whose profiles the driver lists with an encode entry point, which is what vainfo reports and what a session checks first. The device is opened the way a session opens it and released. An error names the step that failed: no such node, no VA driver on it, or a libva the probe cannot reach.

probe_codecs_on 🔒

probe_codecs on an open device: each codec a profile of its 8-bit 4:2:0 ladder encodes, and whether the profile each other format’s session opens under encodes and renders that format’s surfaces too.

profile_ladder 🔒

The VA profiles a session opens under, in order of preference: for 8-bit 4:2:0, the ones such a session comes up as; for 4:4:4 or 10 bits, the profile that carries the format, or nothing where the codec has none the session serves. AV1’s main profile carries both of its depths, told apart by the surface format.

refines 🔒

Whether a constant rate of bps at fps gives a width x height frame the budget radeonsi’s rate control refines a still screen in (REFINE_BITS_PER_PIXEL).

roi_regions 🔒

The regions of interest a frame may name (Negotiated::roi_regions), from the driver’s VAConfigAttribEncROI: none where it reports none, or at a constant rate whose rate control takes no quantizer deltas (bit 9). On Intel’s low-power entry point at a constant quantizer no more than INTEL_VDENC_NATIVE_ROI: iHD’s VDEnc from Gen9 to Gen12 copies the delta of every region it is handed into a stack array of three when they share at most three deltas, which one refinement always does, so a fourth region writes past it and a frame naming a dozen aborted the process on __stack_chk_fail inside vaEndPicture (N97, a window dragged at 144 fps). Its rate control hands the regions to the firmware instead.

rt_format 🔒

The render target format of a chroma and sample depth.

skylake_or_broxton 🔒

Whether an Intel PCI device id is a Skylake or a Broxton part’s.

slice_layout 🔒

How many slices a picture of rows block rows is cut into and how many rows each takes, for wanted slices under the driver’s slice structure and at most max_slices: arbitrary rows as asked, equal rows with a shorter last slice where the driver wants them equal (iHD’s H.264), a power of two of rows where that is all it takes, one row each where it takes only that. A slice a row is 68 slices at 1080p, none predicting from the row above and each restarting the entropy coder: on Intel Arc a scroll of text at one quantizer cost 12.4 kB a frame so cut and 8.6 kB in four slices, at the same PSNR.

strip_zero_padding 🔒

Drop the zero bytes a driver’s constant rate pads an H.264 or HEVC frame with (iHD fills a frame up to the target after the last slice): trailing zero bytes are no part of a NAL unit, whose last byte carries the stop bit.

surface_fourccs 🔒

The surface formats a session of this chroma and sample depth tries, in order.

whole_picture_vdenc 🔒

Whether the render node fd is an Intel part whose low-power H.264 encoder walks a picture once, top to bottom, wherever its slices are cut: Skylake and Broxton, told by the PCI device the kernel names, since their drivers list the entry point, and iHD a slice structure, as they do for the later parts that code the cut. A picture of four slices came out corrupt below the first there (HD 530), and whole from the full entry point.

Type Aliases

Served 🔒

A codec a device encodes, with the formats it encodes the codec in.