claude-noether
c734a82c41
Janet v1 verdict was AMEND with 1 structural BLOCKER (Q5) + 3
implementation-time risks (F1-F3).
Q5 (BLOCKER) empirically confirmed on ampere: RK3588 has THREE
hantro-vpu instances (legacy MPEG2/VP8 at /dev/video2, encoder at
/dev/video3, vpu981 AV1 at /dev/video4). Current backend's 2-device
fd model (rkvdec + hantro) is "RK3399-shaped knowledge" per its own
comment — silently picks the wrong hantro on RK3588.
v2 fix: add third device slot (video_fd_vpu981 + media_fd_vpu981),
discriminate by V4L2_PIX_FMT_AV1_FRAME capability (not driver name),
extend request_device_kind_for_profile with 'a' kind for VAProfile-
AV1Profile0, extend cap_pool pair-of-flags layout per iter38 pattern.
Q1 amendment: tile_group_entry DYNAMIC_ARRAY size = sizeof * MAX(N,1);
add _Static_assert for kernel uAPI drift catch.
Q2 amendment: VIDIOC_QUERY_EXT_CTRL probe at context init for film_grain
availability; gate per-frame send on the flag.
Q3 PROCEED: per-frame SEQUENCE send (no caching).
Q4 PROCEED: ignore VAOpaqueAV1 (codec_store_buffer has default fallback).
Q6 PROCEED: V4L2_REQUEST_MAX_PROFILES=11 exactly full with AV1; add
comment for future bumps.
F1-F3 implementation risks catalogued for Phase 2 code review:
- mi_col/row_starts sentinel (silent corruption on multi-tile)
- superres_denom AV1_SUPERRES_NUM=8 default offset
- loop_restoration_size[] USES_LR flag gating
File estimate up from 800 to 880 LoC (added vpu981 scaffolding).
Phase 0 test vectors were single-tile (208×208 + 352×288); Phase 3
verification must include multi-tile 1080p+ AV1 to exercise F1.
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.