test0r
b47938e0bc
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)
2.5 KiB
libva-v4l2-request-ohm-gl-fix
Bootlin's libva-v4l2-request VA-API backend, with hantro-vpu multi-planar + chromium-149-era stateless H.264 patches developed in the ohm_gl_fix campaign Phase 6 Step 1 (2026-05-01..2026-05-02).
Patches 0001-0018 are contract-correct against the kernel V4L2
stateless H.264 UAPI, validated by inspection against
hantro_h264.c and v4l2_h264_init_reflist_builder() in linux 6.19.x.
See ohm_gl_fix's phase6/step1/audit_0008_decode_params_2026-05-01.md
and phase6/step1/api_contract_findings_2026-05-01.md for the
audit trail.
Honest characterisation
This package compiles cleanly, installs cleanly, and vainfo with
LIBVA_DRIVER_NAME=v4l2_request LIBVA_V4L2_REQUEST_VIDEO_PATH=/dev/video1
enumerates all H.264 profiles. It is, however, not on Brave's
critical decode path on the ohm_gl_fix Step-1+Step-2 stack —
Brave/Chromium uses its own V4L2VideoDecoder in
media/gpu/v4l2/, opens /dev/video1 directly, and never loads
libva. See phase3_remeasure_2026-05-02/B3_decoder_discovery.md
in the ohm_gl_fix repo for the strace/maps evidence.
For libva consumers that DO route through libva (mpv with
--hwdec=vaapi, ffmpeg-vaapi, Firefox with
media.ffmpeg.vaapi.enabled=true), this backend would in
principle engage hantro hardware decode — but each consumer hits
its own downstream issue:
- mpv
--vo=gpu-next: blocked by a Mesa-panfrost WSI pitch bug during EGL dmabuf import (out of scope for this package; seephase3_remeasure_2026-05-02/A3_mesa_wsi_pitch.md). - mpv
--vo=image: silently falls back to libavcodec SW decode rather than engaging the libva session (seephase3_remeasure_2026-05-02/A1_morning_pass_disambiguation.md). Reason not yet diagnosed.
The most likely use case where this backend cleanly delivers hardware decode end-to-end is Firefox via libavcodec-vaapi, on a stack that also has the Mesa pitch issue resolved (or that doesn't hit the EGL import path because Firefox's video element composites differently). Untested at time of writing.
DEBUG patches in the series
0010-DEBUG-hex-dump-output-capture.patch,
0011-DEBUG-sentinel-capture-buffer.patch, and
0014-DEBUG-vapic-bytes-dump.patch produce verbose stderr output
useful for diagnosing decode-path issues but excessive for
production. They are intentionally kept in the applied series
during development; remove for cleaner runs.
Status
Tagged stable as of 2026-05-02 against chromium-149 / linux-6.19.10 / libva-2.22.0. Contract-correct; ecosystem-validation-pending.