 claude-noether
|
9a71dbf4c3
|
iter4 Phase 0 + Phase 1 lock: VP9 on rkvdec
Opens iter4 immediately after iter3 close (d5d4beb). Targets VP9
Profile 0 as the fifth (final) codec to pass boolean-correctness
on fresnel via libva-v4l2-request-fourier — completes the campaign
codec scope.
Locked research question:
mpv --hwdec=vaapi bbb_720p10s_vp9.webm engages backend cleanly
on rkvdec, and HW pixel readback yields byte-identical output
to a software-decoded reference for the same frames.
Five Phase 1 boolean criteria:
1. vainfo enumerates VAProfileVP9Profile0 on rkvdec env binding
2. vaCreateConfig(VAProfileVP9Profile0, VLD) = SUCCESS
3. ffmpeg -hwaccel vaapi VP9 5-frame decode exit 0
4. HW=SW byte-identical with HW engagement verified per memory
feedback_hw_decode_engagement_check.md (mpv -v log inspection
before claiming match). If mpv falls back to SW for VP9 like
it did for iter3 VP8, OR if rkvdec exhibits the same dma_resv
kernel issue as hantro, fall through to transitive proof per
memory reference_dmabuf_resv_blocker.md (libva backend
payload == kernel-direct payload AND kernel-direct decode ==
SW reference).
5. FOUR-codec regression block: H.264 + MPEG-2 + HEVC + VP8
reference hashes hold
Substrate carry-forward (re-verified):
- fork tip e1aca9c (post-iter3-close)
- /usr/lib/dri/v4l2_request_drv_video.so SHA256 0ab5b2ba...4ef
- linux-eos-arm 6.19.9-99-eos-arm
- bbb_720p10s_vp9.webm fixture on fresnel ~/fourier-test/ (3.4 MB)
- rkvdec OUTPUT_MPLANE VP9F + 2 VP9 stateless controls
(V4L2_CID_STATELESS_VP9_FRAME = 0xa40b2c, COMPRESSED_HDR =
0xa40b2d)
- cross-validator anchor confirmed: rkvdec advertises VP9 per
Phase 0 V4L2 inventory
- Reference sources local:
references/ffmpeg-kwiboo/libavcodec/v4l2_request_vp9.c
references/ffmpeg-kwiboo/libavcodec/vaapi_vp9.c
references/linux-mainline/drivers/staging/media/rkvdec/
rkvdec-vp9.c (verify presence at Phase 2)
Predicted scope:
- config.c: ADD VP9 enumeration block + RequestCreateConfig case
+ RequestQueryConfigEntrypoints case (3 sites; same shape as
iter3 VP8)
- src/vp9.c NEW file (~250-350 LOC; 2 V4L2 controls per frame:
FRAME + COMPRESSED_HDR; 8-entry DPB vs VP8's 3)
- src/vp9.h NEW file
- src/meson.build add 'vp9.c' + 'vp9.h' entries
- picture.c codec_set_controls VP9 dispatch + codec_store_buffer
cases for 2 VAAPI VP9 buffer types (Picture + Slice; NO
Probability + IQMatrix unlike iter3 VP8)
- surface.h params union extend with vp9 member
- context.c: NO changes expected (no init-time menus per FFmpeg
ref pattern)
- buffer.c: predicted no Commit D needed (VP9 uses Picture +
Slice + SliceData buffer types — all already whitelisted by
H.264 path); plan for fix-forward if runtime miss surfaces
per memory feedback_runtime_enumerates_allowlists.md
Predicted total: ~400-500 LOC, 3-4 commits + 0-1 fix-forwards.
Larger than iter3 VP8 (370 LOC) but comparable to iter2 HEVC
(470 LOC).
VP9 contract surface:
- 2 controls per frame batched in single S_EXT_CTRLS:
FRAME (struct v4l2_ctrl_vp9_frame) + COMPRESSED_HDR
(struct v4l2_ctrl_vp9_compressed_hdr — probability updates
from compressed header)
- 8 reference frames in DPB (active_ref_frames[8])
- Tile-based decoding (VP9 has 1..N tiles per frame)
- Profile 0 only (8-bit 4:2:0); Profile 1/2/3 OUT-OF-SCOPE
Phase 2 source-read targets queued: config.c enumeration pattern,
picture.c dispatch + per-buffer-type cases, surface.h params union,
VAAPI <va/va_dec_vp9.h>, kernel UAPI v4l2_ctrl_vp9_frame +
v4l2_ctrl_vp9_compressed_hdr (lines 2696-2870), kernel rkvdec-
vp9.c driver, FFmpeg v4l2_request_vp9.c + vaapi_vp9.c.
Memory carry-forward (all 9 entries apply unchanged):
feedback_gitea_as_claude_noether
feedback_no_session_termination_attempts
feedback_header_deletion_check
feedback_runtime_enumerates_allowlists (NEW iter3)
feedback_review_empirical_over_theoretical (BOTH directions)
feedback_rockchip_pixel_verify_path
feedback_fresnel_hostname (NEW iter3)
feedback_hw_decode_engagement_check (NEW iter3)
reference_dmabuf_resv_blocker (NEW iter3)
Open questions inherited from iter3 close (not blocking iter4
lock):
- Does mpv 0.41.0 engage HW for VP9 hwdec=vaapi or fall back
like it did for VP8? Phase 0+3 verifies via mpv -v log.
- Does rkvdec exhibit the same vb2_dma_resv kernel issue as
hantro? Likely no (different driver subsystem; iter1+iter2
mpv-DMA-BUF-GL paths worked on rkvdec). Phase 3 baseline
answers via ffmpeg-vaapi-hwdownload non-zero check.
iter4 = final codec in campaign scope. Clean close → 5/5 codecs
passing → campaign complete.
Refs:
phase0_findings_iter1.md (iter1 MPEG-2 lock template)
phase0_findings_iter2.md (iter2 HEVC lock template)
phase0_findings_iter3.md (iter3 VP8 lock template)
phase8_iteration3_close.md (immediate predecessor close)
phase0_evidence/2026-05-07/v4l2_inventory_findings.md (rkvdec
VP9 capability)
phase0_evidence/2026-05-07/test_fixtures.md (bbb_720p10s_vp9.
webm provenance)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
2026-05-08 23:36:04 +00:00 |
|