claude-noether
794bac72df
Goal: VAAPI consumers (mpv, VLC, GStreamer-VAAPI, browsers) can decode AV1 via libva backend, same HW path that ffmpeg-v4l2request kdirect already uses bit-perfectly (Phase 0). Plan ~800 LoC across 7 files (new av1.c ~700 LoC, av1.h, plus edits to codec.c, config.c, picture.c, surface.h, Makefile.am). Canonical reference: Kwiboo/FFmpeg v4l2-request-n8.1 libavcodec/v4l2_request_av1.c (636 LoC) — exact field mappings for v4l2_ctrl_av1_sequence/_frame/_film_grain/_tile_group_entry. Architectural pattern: existing vp9.c (700+ LoC) in the backend. 6 open architectural questions for Janet review before Phase 2 code: Q1 4-control batching (vs vp9's 2) Q2 film_grain conditional vs unconditional submit Q3 SEQUENCE caching strategy Q4 VAOpaqueAV1 opaque payload semantics Q5 vpu981 vs rkvdec device selection in cap_pool Q6 multi-device probe extension (iter38b pattern + vpu981 for AV1) Phase 2 starts after Janet sign-off. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ampere-av1-enablement
AV1 hardware decode verification on Rockchip RK3588 ampere (CoolPi CM5 GenBook).
Status (2026-05-17 09:00)
VERIFIED WORKING bit-perfect first-try using mainline 7.0.0-rc3 + ffmpeg-v4l2request kdirect path on the hantro vpu981 AV1 driver. Zero new code required.
Sibling campaign ampere-vp9-enablement closed at structural-impossibility on rkvdec/vdpu381 VP9; Janet PIVOT verdict pointed to AV1; verification confirmed AV1 works out-of-the-box.
Verification
$ ssh ampere
$ ffmpeg -hwaccel v4l2request -hwaccel_output_format drm_prime \
-i /tmp/av1_larger.ivf -vf 'hwdownload,format=nv12' \
-f rawvideo -pix_fmt nv12 /tmp/hw-av1-all.nv12
[AVHWFramesContext] Using V4L2 media driver hantro-vpu (7.0.0) for AV1F
Byte-compare against ffmpeg's libdav1d SW reference, all 10 frames of the av1-1-b8-23-film_grain-50.ivf test vector (352×288, includes film-grain feature):
frame 0: exact=100.0000%
frame 1: exact=100.0000%
...
frame 9: exact=100.0000%
Smaller test vector (av1-1-b8-01-size-208x208.ivf, 2 frames): also 100% match.
Driver stack
- IP:
vpu981(Rockchip's dedicated AV1 hardware on RK3588, MMIO at fdc70000) - Kernel driver:
drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c(in-tree) - DT compatible: presumably
rockchip,rk3588-vpu981-av1-dec(verified loaded vialsmod | grep hantro_vpu) - V4L2 node:
/dev/video4(enumerates AV1F format) - Userspace path: ffmpeg
-hwaccel v4l2request(kdirect, not libva)
What's NOT done
- libva-v4l2-request-fourier backend AV1 dispatch — backend has no AV1 codec module. ffmpeg-v4l2request kdirect works without libva. Adding libva AV1 support would make AV1 available to other VAAPI consumers (VLC, mpv with VA-API, GStreamer-VAAPI, browsers via VAAPI/VDPAU). Estimated effort: 1-2 days mirroring the existing HEVC/H.264/VP9 dispatch patterns in
~/src/libva-v4l2-request-fourier/src/(sibling repo). - Fluster
AV1-TEST-VECTORScomprehensive validation (only ran 2 of the AOM test vectors). - Stress test (long bitstream, 1080p+, complex features beyond film_grain).
Out of scope
- Adding AV1 to rkvdec/vdpu381 (would duplicate the working hantro-vpu981 path)
- Reviving the failed VP9 work from sibling campaign
Process
This is a verification campaign more than an enablement campaign. The work was done upstream by Verisilicon + Collabora; this repo documents that it works on ampere out-of-the-box.