marfrit-packages/arch/libva-v4l2-request-ohm-gl-fix

libva-v4l2-request-ohm-gl-fix

⚠ DEPRECATED — use libva-v4l2-request-fourier instead

This package is the predecessor experimental build (tarball pin

• 18 stacked patches) and is no longer maintained as of 2026-05-16. Its successor libva-v4l2-request-fourier tracks the campaign fork's git history directly (git.reauktion.de/marfrit/libva-v4l2-request-fourier) so iteration sweeps (DEBUG removal, follow-up bugfixes) land in a clean linear log, and adds the iter38 multi-device probe that lets a single libva session serve rkvdec H.264/HEVC/VP9 + hantro MPEG-2/VP8 without needing LIBVA_V4L2_REQUEST_VIDEO_PATH overrides.

libva-v4l2-request-fourier declares replaces=('libva-v4l2-request-ohm-gl-fix'), so installing it will remove this package automatically. Kept in-tree as historical reference for the ohm_gl_fix Phase 6 audit trail.

---

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; see phase3_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 (see phase3_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.