marfrit/libva-multiplanar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

README: add TL;DR explaining libva, firefox-fourier, sister campaigns

Browse Source 
TL;DR section at the top covers:
- What libva is (standard userspace shim, backends per hardware,
  what v4l2_request is in this lineage)
- Why firefox-fourier exists (Firefox 150 RDD sandbox blocks
  /dev/media* + linux/media.h ioctls; the ~50-line patch opens
  just what V4L2-stateless decoders need)
- Sister fourier-series campaigns: kwin-fourier (compositor /
  scanout-plane fixes) + chromium-fourier (Chromium VAAPI on aarch64
  + GL-stack workarounds for Mali-G52/Panfrost)

Skim-friendly intro for new readers; the rest of the README stays
the campaign-discipline detail.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (noether)
2026-05-05 18:16:59 +00:00
parent fe3522e419
commit 067a221bc6
1 changed files with 12 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12
View File
@@ -1,5 +1,17 @@
# libva-multiplanar
## TL;DR
**libva** (= "Linux Video Acceleration API") is the standard userspace shim that lets video apps — Firefox, Chromium, mpv, GStreamer, vlc — talk to GPU/VPU hardware decoders without per-vendor code. Apps call libva; libva loads a backend driver (`.so` in `/usr/lib/dri/`) for the local hardware. Common backends: `intel-iHD` (Intel iGPUs), `mesa-va-gallium` (AMD), `nvidia-vaapi-driver`, and **`v4l2_request`** for V4L2-stateless ARM/embedded decoders (Rockchip hantro, Allwinner cedrus, Sun*, etc.). This campaign hardens a fork of the v4l2-request backend to actually work on Rockchip hantro (PineTab2 RK3568 first), end-to-end, for real consumers.
**`firefox-fourier`** ([build instructions](firefox-fourier/README.md)) exists because Firefox 150's RDD-process sandbox blocks two things V4L2-stateless decoders need: `/dev/media*` request-API nodes (broker policy never lists them) and `linux/media.h` ioctls (seccomp policy doesn't admit magic byte `'|'`). Stock Firefox on hantro/cedrus/sun* hardware therefore SW-decodes everything unless you set `MOZ_DISABLE_RDD_SANDBOX=1` (which turns the whole sandbox off). The `firefox-fourier` patch — ~50 lines across two files — opens *just* what V4L2-stateless decoders need, sandbox stays on. Tested working with the iter5-end libva backend.
**Sister campaigns** in the operator's "fourier" series — same hardware, different layers of the pipeline:
- [`kwin-fourier`](https://git.reauktion.de/marfrit/marfrit-packages/src/branch/master/arch/kwin-fourier) — KWin compositor patches addressing scanout-plane / dmabuf-fence behavior on RK3568. Decode-side fix in this campaign + render-side fix in kwin-fourier are complementary; together they make HW video work end-to-end on PineTab2.
- `chromium-fourier` — Chromium fork enabling VAAPI on aarch64 + GL-stack workarounds for Mali-G52/Panfrost. Stock Brave doesn't even reach VAAPI on this rig (GPU process dies at GL bindings); chromium-fourier unblocks it. Verifying compatibility with iter5 driver is iter6 candidate C.
---
Single-question campaign on the libva V4L2-stateless backend: **make multi-planar libva work, end-to-end, on Rockchip hantro hardware, for production VA-API consumers (Brave/Chromium, Firefox via libavcodec, mpv `--hwdec=vaapi`, vainfo as smoke test)**.
The deliverable is a libva-v4l2-request fork that any VA-API consumer can dlopen and get H.264 (initially) and MPEG-2 hardware-decoded NV12 dmabufs out of, on PineTab2 RK3568 first, with the same plumbing intended to extend to RK3399 (fresnel) and RK3588 (boltzmann/ampere) once the RK3568 path is solid.