ampere-fourier/phase4_plan.md

Phase 4 — Plan (iter1)

Drafted 2026-05-16, post-Phase-3-measurements. iter1 is a characterize-and-baseline iteration, not a change-the-system iteration: Phase 3 showed the libva-v4l2-request-fourier backend (hand-built 0c9a7efaab…, source 7ac934e) functions correctly on ampere's clean v7.0-rc3 kernel for the 3 in-scope codecs. Phase 4 plans the closure: criterion refinements, follow-up issue filings, and the iteration close artifact.

No source code changes touch the backend, ffmpeg, mpv, or firefox-fourier in iter1. Each blocker codec (HEVC, VP9, AV1) is a future iteration with its own Phase 0 entry.

What changes (Phase 6 will execute)

1. Refine C4 to per-codec SSIM Y floors

Phase 3 surfaced that the iter1 default C4 (SSIM Y ≥ 0.99 for every codec at frame 720) is the wrong shape. Replace with per-codec floors anchored to Phase 3 observations + memory entries:

Codec	Original C4	Refined C4 floor	Basis
H.264	SSIM Y ≥ 0.99	document at 0.6676, no PASS threshold (treat as known cumulative drift between libavcodec SW and rkvdec HW; mirrors fresnel iter1 0.6431)	memory feedback_pixel_compare_in_yuv_not_png + fresnel measurements_iter1.md; documented as decoder-tolerance phenomenon, not a regression
VP8	SSIM Y ≥ 0.99	SSIM Y ≥ 1.000 (byte-identical, all frames)	Phase 3 observed 1.000000 with diff_bytes=0; raises bar instead of lowering it
MPEG-2	SSIM Y ≥ 0.99	SSIM Y ≥ 0.9997	memory feedback_mpeg2_hw_sw_idct_precision — hantro IDCT is conformant per IEEE 1180 but ≤3 LSB off SW; Phase 3 observed 0.999720

The H.264 entry does not get a PASS threshold for iter1; it's an accepted observation. Future iterations may want to investigate whether a specific x264 encode setting (e.g. -tune psnr, -no-cabac) reduces drift, but that's not iter1 scope.

2. File 3 follow-up issues for blocker codecs

Per the user's policy that ampere stays on a clean kernel and codec-enablement happens via kernel-agent experiments OR backend iterations:

• HEVC kernel OOPS → file an issue against marfrit/kernel-agent with prefix [ka:experiment] requesting a candidate fix for rkvdec_hevc_prepare_hw_st_rps (RK3588 mainline rkvdec, NULL/unmapped pointer in __pi_memcmp during HEVC RPS preparation). Include full Phase 0 dmesg trace + reproducer (ffmpeg -hwaccel vaapi -i bbb_60s_720p.hevc.mp4 -vf hwdownload -f null -). Suggest upstream search: linux-media list mainline -rc1..-rc3 for rkvdec HEVC commits, possibly later -rc has a fix.
• VP9 not exposed on RK3588 rkvdec → file an issue against marfrit/kernel-agent with prefix [ka:experiment] requesting VP9 enablement on the RK3588 rkvdec variant_ops (per memory feedback_rkvdec_patch_reachability: confirm patches target VDPU381/383 path, not the RK3399 legacy rkvdec path that fresnel uses). Include v4l2-ctl -d /dev/video1 --list-formats-out showing S264 + S265 only as the current state.
• AV1 unprobed by libva backend (third decoder fd) → file an issue against marfrit/libva-v4l2-request-fourier requesting iter39: extend the 2-fd request_data to a 3-fd or table-driven model, add request_device_kind_for_profile() 'a' → av1-vpu-dec routing, find AV1 test clip. Pure backend work, no kernel involvement.

Each issue is a discrete deliverable — Phase 6 produces them as final atoms of iter1.

3. Update issue #6 on marfrit/kernel-agent

Add a comment on the original issue with the per-iter1 outcome (bootstrap closed by neighbour, baseline validated for 3/6 codecs, the other 3 spawned as separate issues per the experiment policy). Close #6 once the 3 follow-up issues are created and cross-linked. Don't leave an open umbrella issue that's effectively superseded.

4. Phase 7 verification sweep — re-run Phase 3 measurements

After Phase 6 lands the issues, re-execute p3_engage.sh + p3_bitexact.sh + p3_bench.sh once more (N=1 verification, not N=3 — this is a "still works after issue-filing housekeeping" gate, not a load-bearing measurement). Predicted outcome: bit-for-bit reproduction of the Phase 3 numbers (no state change in iter1 should affect decode behavior). If the verification deviates, Phase 7's loopback edge fires.

5. iter1 close artifact

Write iter1_close.md summarizing: baseline-validated codec set, per-codec C1-C6 results, follow-up issue links, what carries to iter2+.

What does NOT change

• /usr/lib/dri/v4l2_request_drv_video.so: still the hand-built 0c9a7efaab…. Don't touch — marfrit-packages#17 is the CI-build fix issue, not iter1's problem.
• linux-ampere-fourier 7.0rc3.kafr1-1: baseline kernel, untouched. Per operator policy, no codec patches on the ampere baseline.
• firefox-fourier 150.0.1-5: installed but C7 deferred. No prefs added or removed.
• Source clips in ~/measurements/encoded/: immutable for iter1; carry forward to iter2+ for the blocker-codec iterations.
• mpv-fourier, ffmpeg-v4l2-request-fourier: pinned versions, no changes.

Expected outcome (Phase 7 will verify, in Phase 1/3 measurable terms)

Criterion	Predicted result	Anchor
C1 (decode completes)	PASS all 3 codecs unchanged	Phase 3 N=1 was clean
C2 (HW engagement)	PASS — ioctl counts within ±5 % of Phase 3 (allow for run-to-run noise on probe phase)	strace counts on a closed system are nearly deterministic
C3 (frame 0 byte-identical)	PASS all 3 — same sha 3214803d8be74416	deterministic decoder for I-frame
C4 (frame 720 per refined floors)	PASS — VP8 1.000, MPEG-2 ≥ 0.9997, H.264 documented at ~0.667 ± 0.01	accumulated drift is RNG-free, should be deterministic
C5 (FPS N=1)	within ±1 % of Phase 3 mean — H.264 ~ 461, VP8 ~ 217, MPEG-2 ~ 200	hardware run-to-run variance is small (Phase 3 σ < 0.4 % CV)
C6 (dmesg clean)	PASS — empty diff	as long as Phase 6 doesn't touch HEVC, no oops triggered
C7 (firefox-fourier vendor-defaults)	still deferred; rig blocker (Wayland) unchanged	no action in iter1

If any Phase 7 measurement deviates >2 σ from the Phase 3 anchor, loop back to Phase 4 — something changed in iter1 that we didn't account for.

Risk register

Risk	Probability	Mitigation
Issue-filing API call against gitea fails	low	use claude-noether identity (proven, sibling issues filed today)
Phase 7 re-sweep reveals a regression that Phase 3 didn't catch	low — N=1 vs N=3 with same scripts	accept the deviation as the iter1 finding; don't synthesize plausible numbers
Some other workload on ampere (kids-media decode, etc.) interferes	very low — ampere is dev gear	no mitigation needed; if it happens, Phase 7 loopback applies
User wants iter1 to also include C7 before close	possible	call out the C7 deferral explicitly in iter1_close.md so it's a visible follow-up, not a hidden gap

Phase 4 close

Plan locked. Phase 5 review next: hand off Phase 0-4 artifacts to a second-model architect for an outside-look.