fresnel-fourier/phase8_iteration16_close.md

Iteration 16 — Phase 8 (close)

Closes 2026-05-14. iter16 = α-16 OUTPUT byte verification on VP8 + consolidation of Bug 4/5/6 cause-class. PARTIAL close. No code changes; pure narrowing.

Outcome

Bug 6 (VP8 libva partial output, hash bcc57ed5…) verified via the same α-16 methodology applied to HEVC at iter14:

libva VP8 frame 1 OUTPUT dump:    300614 bytes
input IVF frame 1 size:           300624 bytes  (+10-byte VP8 uncompressed header)

Byte-identity check with +10 offset (stripping VP8 uncompressed header):
  0 bytes differ

VAAPI consumer (ffmpeg-vaapi) parses the VP8 uncompressed header client-side and forwards only the compressed first-partition bytes onward. libva backend writes those bytes to OUTPUT buffer, byte-identical to what kdirect would write.

Bug 4 + Bug 5 + Bug 6 = same cause class

Cumulative verification across iter8–iter16:

Bug	Codec	libva controls (rkvdec-read fields)	libva OUTPUT bytes	Result
Bug 4	H.264	byte-equal to kdirect (10 fields verified)	byte-identical to input slice NAL	partial 16×32 leak
Bug 5	HEVC	byte-equal to kdirect (every rkvdec-read SPS/PPS/slice/decode_params field)	byte-identical to input IDR NAL	all-zero
Bug 6	VP8	(similar pattern; controls + OUTPUT verified by α-16 here)	byte-identical to input frame minus uncompressed header	74.8% zero with partial real bytes

All three bugs are kernel-side rkvdec / hantro failures specific to how the driver processes libva's V4L2 ioctl sequence on these per-codec paths. VP9 + MPEG-2 work via the same libva backend on the same hardware, ruling out a categorical libva problem.

What libva has shipped through iter8–iter16 (cumulative)

8 wire-correctness or diagnostic commits, all zero-regression:

iter	Commit	Description
8	7eae6ea	γ env-gated CAPTURE buffer dump
8	66ecbef	IMP-1 env-gated CAPTURE pre-zero diagnostic
8	6f4e583	stdlib.h fix-forward
8	0226684	α-2: pass H.264 POC values through unchanged
9	e0be4e6	α-7: per-context monotonic timestamp counter
11	8e2c04f	α-13 + α-14: HEVC SPS reorder_pics + IRAP/IDR flags
13	ca4dd88	α-17: DMA_BUF_IOCTL_SYNC around CAPTURE read
14	522fb6d	α-16: env-gated OUTPUT byte dump
15	3760a70	α-19: explicit S_FMT CAPTURE

Plus campaign infrastructure for diagnostic instrumentation (env-gated dumps for both CAPTURE post-DQBUF and OUTPUT pre-QBUF).

What's shipped at the kernel level

Kernel substrate linux-fresnel-fourier 7.0-1 → 7.0-2 (iter12):

• 3 RFC v2 vb2_dma_resv producer fence patches integrated.
• Compositor / explicit-sync consumers benefit from real dma_resv fences.
• Libva pixel readback path is orthogonal — unchanged.

Campaign-level scoreboard

Codec   | Site      | Status        | libva-side state | Kernel-side root cause
========|===========|===============|=============|====================================
H.264   | rkvdec    | PARTIAL       | byte-correct | Bug 4 (kernel HEVC + H.264 paths
HEVC    | rkvdec    | DEGRADED *    | byte-correct |   produce wrong/zero output via
VP9     | rkvdec    | PASS direct   | works        |   libva's particular ioctl pattern,
MPEG-2  | hantro    | PASS (env)    | works        |   work via kdirect's pattern)
VP8     | hantro    | PARTIAL (env) | byte-correct | Bug 6 (kernel hantro VP8 partial)

VP9 + MPEG-2 are direct passes via libva. H.264 / HEVC / VP8 reach the kernel correctly from libva, but the kernel produces wrong output for libva's pattern (works for kdirect).

Memory rule already saved

feedback_libva_byte_correct_kernel_bug.md was saved at iter14 close. iter16 confirms the rule extends to Bug 6 (VP8). The rule is now codec-agnostic for HEVC + H.264 + VP8 (and presumably any other libva-failing codec on this kernel).

iter17+ candidates (ordered)

1. kernel-side rkvdec hot-path trace — read RK3399 rkvdec source carefully; instrument via ftrace / eBPF kprobe; compare what kernel state evolves for the same bitstream when libva vs kdirect triggers decode. Heaviest investment. Route via kernel-agent.

2. Pivot to iter4-B1b backlog — multi-decoder routing in libva backend (RK3399 has rkvdec for H.264/HEVC/VP9, hantro for MPEG-2/VP8). One backend instance routes per codec to the right /dev/media*. Architectural refactor, ~200-400 LOC, no kernel work.

3. Re-anchor regression baselines — codify the 5 stable hashes as a regression test suite in the fork's CI infrastructure (if any).

4. Campaign close-out / handoff documentation — long-form deliverable describing the libva backend's byte-correctness, the kernel-side gap, and what would need to land upstream / in mainline rkvdec for Bug 4/5/6 closure.

The iter17 productive direction is kernel-side investigation. Per feedback-libva-byte-correct-kernel-bug, libva-side changes are now confirmed inert for these bugs.

Substrate state at iter16 close

• Fork tip 3760a70 on noether + fresnel + gitea (unchanged from iter15).
• Backend SHA c1d4bb53… on fresnel.
• Kernel 7.0-2.
• 5-codec anchors preserved.

Iter16 contribution

Just an empirical confirmation that Bug 6 is in the same cause class as Bug 4/5. No code changes. The OUTPUT byte verification methodology generalizes cleanly across codecs.