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)
60 lines
2.6 KiB
Diff
60 lines
2.6 KiB
Diff
From: Markus Fritsche <fritsche.markus@gmail.com>
|
|
Date: 2026-05-01
|
|
Subject: [PATCH] context: enable ANNEX_B start-code emission to match device
|
|
|
|
Patch 0002 sets V4L2_CID_STATELESS_H264_START_CODE to ANNEX_B on the
|
|
device, telling the kernel that OUTPUT-buffer payloads will contain
|
|
0x00 0x00 0x01 NAL start codes. picture.c::codec_store_buffer has
|
|
the prepend logic guarded by `if (context->h264_start_code)`, but
|
|
that boolean is set ONLY inside h264_get_controls() — a function
|
|
that exists but is never called.
|
|
|
|
Result: device expects ANNEX_B, libva-v4l2-request feeds raw NAL
|
|
payloads with no start codes, kernel cannot find slice boundaries,
|
|
hantro emits a zeroed CAPTURE buffer. mpv reports successful decode
|
|
because the V4L2 round-trip succeeds (no EINVAL); the visual output
|
|
is a flat dark-green frame (NV12 zero through BT.709).
|
|
|
|
Identified via:
|
|
- Patch 0006 cleared the EINVAL cluster-rejection (128 → 0 on
|
|
bbb_1080p30) but visual output remained flat green.
|
|
- GStreamer reference (gstv4l2codech264dec.c:1363-1377) confirms
|
|
start codes are required when ANNEX_B is selected.
|
|
- Source-archaeology of fourier's picture.c:67-74 showed the gate
|
|
on context->h264_start_code.
|
|
|
|
Fix: in context.c::RequestCreateContext, immediately after patch
|
|
0002's device-control block, set context_object->h264_start_code =
|
|
true to match the ANNEX_B mode we just programmed. Hardcoded for
|
|
now (matches 0002's hardcoded set); replaced with a runtime probe
|
|
in the planned probe-then-set commit.
|
|
|
|
Signed-off-by: Markus Fritsche <fritsche.markus@gmail.com>
|
|
---
|
|
--- a/src/context.c 2026-05-01 20:48:59.884816330 +0000
|
|
+++ b/src/context.c 2026-05-01 20:59:54.446340219 +0000
|
|
@@ -146,6 +146,23 @@
|
|
dev_ctrls, 2);
|
|
}
|
|
|
|
+ /*
|
|
+ * Mirror the ANNEX_B start-code mode set on the device above
|
|
+ * into context_object->h264_start_code so picture.c::
|
|
+ * codec_store_buffer prepends 0x00 0x00 0x01 to each slice
|
|
+ * payload it copies into the OUTPUT buffer. Without this, the
|
|
+ * kernel — which we just told to expect ANNEX_B — sees a raw
|
|
+ * NAL stream with no start codes, fails to find slice
|
|
+ * boundaries, and emits a zeroed CAPTURE buffer (visually a
|
|
+ * flat dark-green frame).
|
|
+ *
|
|
+ * h264_get_controls() exists for this purpose but is never
|
|
+ * called in the current code path; the planned probe-then-set
|
|
+ * commit will replace this hardcoded assignment with a runtime
|
|
+ * read of the kernel's accepted START_CODE value.
|
|
+ */
|
|
+ context_object->h264_start_code = true;
|
|
+
|
|
rc = v4l2_set_stream(driver_data->video_fd, output_type, true);
|
|
if (rc < 0) {
|
|
status = VA_STATUS_ERROR_OPERATION_FAILED;
|