claude-noether
695588aaaf
Janet re-review verdict on v2: PROCEED with no architecture changes. Two minor plan-text amendments: A. cap_pool init for vpu981 — at backend init (NOT lazy). Three explicit init calls in VA_DRIVER_INIT_FUNC. Lazy init creates race window where concurrent VP8 (legacy hantro) and AV1 (vpu981) sessions can alias cap_pool state across the wrong device. B. Lock the F1 test vector: av1-1-b8-23-film_grain-50.ivf (AOM data set). Already used in Phase 0 kdirect; reuse via libva for byte- compare. Default 1080p encodes may be single-tile and never exercise F1; a named conformance vector locks the test surface. Cross-compile hazard documented: _Static_assert validates against COMPILE-TIME kernel headers. Sibling-campaign pattern is native arm64 build on ampere — no cross-compile in scope. Comment added near the assert for future Makefile changes. Phase 2 entry checklist locked. Plan stack: v1 → v2 (Q5 BLOCKER fix) → v3 amendment (Janet PROCEED + 2 fixes). Implementation starts with request.c third-device scaffolding (smallest atomic change), then small file edits, then NEW av1.h, then NEW av1.c (~700 LoC), then build + Phase 3 hardware test. 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.