diff --git a/README.md b/README.md index b1ad322..32d92a7 100644 --- a/README.md +++ b/README.md @@ -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.