forked from marfrit/marfrit-packages
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)
59 lines
2.5 KiB
Markdown
59 lines
2.5 KiB
Markdown
# 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.
|