test0r
b47938e0bc
build and publish packages / distcc-avahi-aarch64 (push) Successful in 1m3s
build and publish packages / lmcp-any (push) Successful in 9s
build and publish packages / lmcp-debian (push) Successful in 4s
build and publish packages / claude-his-any (push) Failing after 4s
build and publish packages / ffmpeg-v4l2-request-aarch64 (push) Has been skipped
build and publish packages / claude-his-debian (push) Has been skipped
Mirrors phase6/step1/ from the ohm_gl_fix campaign. Contract-correct
hantro multi-planar / chromium-149-era stateless H.264 port of
bootlin's libva-v4l2-request, patches 0001..0018 + fourier-local.
Honest characterisation in README:
- Builds cleanly on chromium-builder LXC (boltzmann)
- vainfo enumerates H.264 profiles cleanly with LIBVA_DRIVER_NAME=v4l2_request
- NOT on Brave's decode path on ohm_gl_fix stack — Brave uses
Chromium's own V4L2VideoDecoder in media/gpu/v4l2/.
- Most likely useful for a future Firefox-via-libavcodec-vaapi
campaign, modulo a separate Mesa-panfrost WSI pitch issue.
- DEBUG patches (0010, 0011, 0014) intentionally kept in series
for development; remove for cleaner production runs.
Audit trail in the source repo at ohm_gl_fix:
phase6/step1/audit_0008_decode_params_2026-05-01.md
phase6/step1/api_contract_findings_2026-05-01.md
phase3_remeasure_2026-05-02/B3_decoder_discovery.md (why this
isn't on Brave's path)
104 lines
4.2 KiB
Diff
104 lines
4.2 KiB
Diff
From: Markus Fritsche <fritsche.markus@gmail.com>
|
|
Date: 2026-05-01
|
|
Subject: [PATCH] context: pre-STREAMON device controls and minimum OUTPUT pool
|
|
|
|
Two related fixes that surfaced during the first hantro-vpu (RK3568)
|
|
smoke test of the multiplanar build:
|
|
|
|
1. **OUTPUT queue must be non-empty at STREAMON.** Hantro's
|
|
vb2_start_streaming rejects an empty queue with EINVAL. Some
|
|
VA-API callers (notably ffmpeg's vaapi-copy path) call
|
|
vaCreateContext with num_render_targets=0 and allocate render
|
|
targets lazily. The OUTPUT (bitstream-input) pool must NOT be
|
|
sized off surfaces_count alone — it is a request-time resource,
|
|
not per-surface. Quick fix: floor the pool to 4 buffers when
|
|
the caller passes 0. (A proper decoupling of OUTPUT pool from
|
|
surface lifecycle is documented in upstreamable_design.md.)
|
|
|
|
2. **Device-wide stateless H.264 controls before STREAMON.** The
|
|
V4L2 stateless framework requires V4L2_CID_STATELESS_H264_
|
|
DECODE_MODE and START_CODE be set on the device fd
|
|
(request_fd=-1) before stream start. Per-request controls
|
|
(SPS/PPS/SLICE_PARAMS/etc.) attached to a request_fd come
|
|
later via h264_set_controls(). hantro-vpu accepts only
|
|
DECODE_MODE_FRAME_BASED; START_CODE_ANNEX_B matches what the
|
|
existing slice-assembly path emits.
|
|
|
|
This is set unconditionally for now (errors silently ignored)
|
|
to keep cedrus and other backends compatible — they may
|
|
default to SLICE_BASED and not expose DECODE_MODE at all.
|
|
Probe-then-set via VIDIOC_QUERYCTRL is the upstream-correct
|
|
approach (see upstreamable_design.md §3).
|
|
|
|
After this patch, vainfo still enumerates as before, but the first
|
|
mpv vaapi-copy attempt advances past STREAMON and into actual
|
|
decode submission.
|
|
|
|
Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>
|
|
---
|
|
src/context.c | 38 +++++++++++++++++++++++++++++++++++++-
|
|
1 file changed, 37 insertions(+), 1 deletion(-)
|
|
|
|
--- a/src/context.c
|
|
+++ b/src/context.c
|
|
@@ -64,6 +64,7 @@ VAStatus RequestCreateContext(VADriverContextP context, VAConfigID config_id,
|
|
VAContextID id;
|
|
VAStatus status;
|
|
unsigned int output_type, capture_type;
|
|
+ unsigned int output_buffers_count;
|
|
unsigned int index_base;
|
|
unsigned int index;
|
|
unsigned int i;
|
|
@@ -90,8 +91,16 @@ VAStatus RequestCreateContext(VADriverContextP context, VAConfigID config_id,
|
|
}
|
|
memset(&context_object->dpb, 0, sizeof(context_object->dpb));
|
|
|
|
+ /*
|
|
+ * The OUTPUT (bitstream-input) queue must be non-empty before
|
|
+ * VIDIOC_STREAMON or hantro-class drivers reject with EINVAL.
|
|
+ * VA-API callers (e.g. ffmpeg's vaapi-copy path) may invoke
|
|
+ * vaCreateContext with num_render_targets=0; allocate a small
|
|
+ * minimum pool independent of the caller's surface count.
|
|
+ */
|
|
+ output_buffers_count = surfaces_count > 0 ? surfaces_count : 4;
|
|
rc = v4l2_create_buffers(driver_data->video_fd, output_type,
|
|
- surfaces_count, &index_base);
|
|
+ output_buffers_count, &index_base);
|
|
if (rc < 0) {
|
|
status = VA_STATUS_ERROR_ALLOCATION_FAILED;
|
|
goto error;
|
|
@@ -138,6 +147,33 @@ VAStatus RequestCreateContext(VADriverContextP context, VAConfigID config_id,
|
|
surface_object->source_size = length;
|
|
}
|
|
|
|
+ /*
|
|
+ * Stateless H.264 device-wide controls. The kernel V4L2 stateless
|
|
+ * framework requires DECODE_MODE and START_CODE be set on the
|
|
+ * device fd (request_fd=-1) before VIDIOC_STREAMON; per-request
|
|
+ * controls (SPS/PPS/etc.) attached to a request_fd come later.
|
|
+ *
|
|
+ * hantro-vpu (RK3568) accepts only DECODE_MODE_FRAME_BASED.
|
|
+ * START_CODE_ANNEX_B preserves leading 0x00000001 in the slice
|
|
+ * payload that h264.c assembles. Errors here are not fatal: not
|
|
+ * every backing driver supports both controls (e.g. cedrus may
|
|
+ * default to SLICE_BASED without exposing DECODE_MODE).
|
|
+ */
|
|
+ {
|
|
+ struct v4l2_ext_control dev_ctrls[2] = {
|
|
+ {
|
|
+ .id = V4L2_CID_STATELESS_H264_DECODE_MODE,
|
|
+ .value = V4L2_STATELESS_H264_DECODE_MODE_FRAME_BASED,
|
|
+ },
|
|
+ {
|
|
+ .id = V4L2_CID_STATELESS_H264_START_CODE,
|
|
+ .value = V4L2_STATELESS_H264_START_CODE_ANNEX_B,
|
|
+ },
|
|
+ };
|
|
+ (void)v4l2_set_controls(driver_data->video_fd, -1,
|
|
+ dev_ctrls, 2);
|
|
+ }
|
|
+
|
|
rc = v4l2_set_stream(driver_data->video_fd, output_type, true);
|
|
if (rc < 0) {
|
|
status = VA_STATUS_ERROR_OPERATION_FAILED;
|