# 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](../../../ohm_gl_fix/) 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.