fresnel-fourier/phase8_iteration6_close.md

Iteration 6 — Phase 8 (close)

Closes 2026-05-12. iter6 = Bug 6 (VP8 partial output post-iter5b-β) targeted; root-cause narrowed but not fixed. iter6 closes PARTIAL with the narrowing as the iter6 deliverable. Bug 6's actual fix lives in kernel territory, outside iter6's Phase 1 locked scope.

Summary

Metric	Value
Iteration target	Bug 6 — VP8 libva output diverges from kdirect (74.8% zero with real keyframe content)
Hardware	RK3399 hantro-vpu-dec for VP8
Fork tip start (iter5b-β close)	70196f8
Fork tip end (iter6 close)	70196f8 (unchanged — no patches landed)
Phase 1 criteria	5/6 PASS, 1/6 PARTIAL
Bug 6 status	narrowed to kernel-side (H-E); backend-side fix not available
Campaign scoreboard	unchanged from iter5b-β close: 5/5 with 2 direct (VP9, MPEG-2) + 3 mixed (H.264 keyframe-partial, VP8 partial-with-Bug-6, HEVC transitive-only with Bug 5)

Deliverable: Bug 6 root-cause narrowing

Phase 3 systematically eliminated 4 of 5 hypotheses via empirical investigation:

Hypothesis	Status	Evidence
H-A — slice data corruption in libva path	ELIMINATED	libva-dumped slice 0 (300614 bytes) byte-identical to raw VP8 frame 0 from .webm post-header (SHA 9e74956c…).
H-B — slices_size wrong on OUTPUT QBUF	ELIMINATED	slices_size = fp_size + sum(dct_part_sizes) = 22742 + 277872 = 300614 exactly.
H-C — CAPTURE-side cache coherency	ELIMINATED	VP9 uses same image.c::copy_surface_to_image path and works fine. msync attempt empirically no-op (output hash unchanged).
H-D — CAPTURE slot rotation mismatch	ELIMINATED (Phase 3 Candidate K)	Instrumented bind + read sites; slot v4l2_index matches between BeginPicture and vaGetImage for every surface tested. destination_data[0] pointer matches slot->map[0].
H-E — kernel-side hantro VP8 partial-write quirk	CONFIRMED by elimination	The control bytes are right, the slice bytes are right, the buffer pointers are right, the slot indices are right. Yet the kernel writes only a partial subset of the frame to the CAPTURE buffer (per-frame transition rows: frame 0 Y row 536, frame 0 UV row 134, frame 1 Y row 24 — erratic).

The libva backend is doing the right thing on the V4L2 protocol surface. The kernel-side hantro VP8 driver writes partial content to the CAPTURE buffer.

This narrowing is iter6's deliverable. Future investigation (iter7 or kernel-agent work) needs ftrace, hantro source-read, possibly a kernel patch.

Per-criterion verdict

#	Criterion	Verdict	Evidence
1	VP8 libva == kdirect	PARTIAL — kernel-side bug confirmed via systematic elimination, not fixed	post-β VP8 hash bcc57ed5…, kdirect 136ce5cb…
2	VP9 unchanged	PASS	4f1565e8… == kdirect (iter5b-β state preserved)
3	MPEG-2 unchanged	PASS	19eefbf4… == kdirect (iter5b-β state preserved)
4	H.264 keyframe-partial unchanged	PASS	71ac099b… (Bug 4 still deferred)
5	HEVC unchanged	PASS	06b2c5a0… all-zero (Bug 5 still deferred)
6	Control-payload anchors hold	PASS	No control-submission code changes in iter6

5 of 6 PASS. Criterion 1 PARTIAL: the locked goal of libva_vp8 == kdirect_vp8 not reached, but Phase 3 narrowed it from "unknown" to "kernel-side H-E confirmed."

Cost of iter6

• Phase 0+1+2+3 docs.
• 0 fork commits (no patches landed).
• ~3 hours of diagnostic instrumentation (slice-data dump, msync test, slot-index logging) all reverted at end of Phase 3.
• Substrate unchanged: fork tip 70196f8, backend SHA 2c6ff82c…. Net delta on fresnel: nil.
• Net deliverable: Phase 3 narrowing doc with crisp H-A/B/C/D elimination + H-E confirmation. The hypothesis space for future Bug-6 work shrinks from 5 → 1.

Lessons distilled

Transitive-proof blind spots (re-confirmed)

iter3 closed VP8 via "transitive PASS" verifying specific control fields (first_part_size, first_part_header_bits) matched kdirect. iter5b-β unblocked VP8 from the OUTPUT-format mismatch. iter6 Phase 3 confirmed: control payload is byte-identical to kdirect, slice data is byte-identical to the raw .webm, slices_size is correct — and the kernel STILL produces wrong output.

iter3's transitive proof, iter5b-β's β refactor, and iter6's Phase 3 narrowing are all consistent with each other. The kernel-side partial-write (H-E) was masked by the OUTPUT format mismatch pre-β (all-zero output regardless of what else was right). Once β fixed the format, H-E became visible.

Same shape as iter2-HEVC + Bug 5: transitive proofs against ONE artifact (control payload) don't catch bugs in OTHER artifacts (the kernel's actual decode behavior).

Phase 3 instrumentation hygiene

iter6 Phase 3 added/reverted instrumentation three times (slice dump, msync, slot indices). Each rebuild + run + analyze cycle was ~5 minutes. Total instrumentation overhead: maybe 30 minutes across 3 cycles. The discipline of "add diagnostic, run, revert" worked — fresnel ends at clean SHA 2c6ff82c… identical to iter5b-β close.

Worth a memory note: instrument-revert workflow is fast and safe for empirical narrowing. Future Phase 3 work should embrace the same pattern instead of trying to deduce from source alone.

iter6 didn't need Phase 4-7 because the Phase 3 verdict was "kernel-side, out of scope"

The 8(+1)-phase loop assumes Phase 3 narrows the fix site and Phase 4 plans the fix. When Phase 3 narrows OUT OF SCOPE (e.g., kernel-side when the iteration locked backend-only), Phase 4 onwards is moot. iter6 closes from Phase 3 directly to Phase 8 with the narrowing as the deliverable.

This is a legitimate close pattern, not a process violation. The dev process allows for "Phase 3 → Phase 0 loopback" or "Phase 3 → iteration close PARTIAL" when the empirical evidence demands it. iter6 demonstrates the latter.

Phase 4 cross-cutting backlog status (iter6 increment)

Unchanged from iter5b-β close:

• iter4-B1 device-discrimination: still open.
• iter4-B2 mpv-vaapi create-device: still open.
• iter4-Q6, COLOR_RANGE, B3-B6, L3: all still open.

iter6 NEW backlog items:

• Bug 6 narrowed to H-E: kernel-side hantro VP8 partial-write. Per-frame Y plane transitions at varying rows (536, 24, ...). Not slot rotation, not cache, not slice corruption, not bytesused. Investigation surface: hantro driver source (hantro_g1_vp8_dec.c likely), ftrace at kernel for VP8 decode path, possibly a hantro-VP8 kernel patch.

iter6 → iter7 handoff

Substrate at close:

• Fork tip 70196f8 (iter5b-β + Commit D). Identical to iter6 open.
• Backend SHA 2c6ff82c… on fresnel. Identical to iter6 open.
• Kernel unchanged.
• Test fixtures unchanged.

Candidates for iter7 Phase 0:

• Bug 6 H-E kernel-side fix — heavy, kernel work. Aligns with original iter5 Candidate B scope (vb2_dma_resv era kernel patches, plus new VP8 partial-write fix).
• Bug 4 H.264 inter race-loss — backend or kernel; iter4 partial work history.
• Bug 5 HEVC DQBUF FLAG_ERROR — iter2's transitive PASS masked it; need to find the V4L2 protocol gap between libva-HEVC and kdirect-HEVC.
• iter4-B1 auto-detect harden — backend, ~100 LOC, quality-of-life.
• Re-anchor regression hashes on β substrate — establish iter7+ regression invariants.

User picks at iter7 Phase 0 lock.

Memory rule note (deferred)

iter6's lesson about Phase-3-empirical-revert workflow is worth a memory entry; defer the write to iter7 close or to a dedicated memory-curation session.