# 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.