fresnel-fourier/phase7_iter5b_verification_v2.md

# Iteration 5b — Phase 7 v2 (verification, β + Commit D)

Captured 2026-05-12 evening on fresnel `linux-fresnel-fourier 7.0-1`, fork tip `70196f8`, backend SHA `2c6ff82cbdc156ff8910d0c7fe58e75eeecdfd6e6a1caabb049c8adf43a098b8`. β architecture survived empirical contact; Commit D fix-forward addressed the ffmpeg-vaapi-copy-passes-surfaces_count=0 surprise the first run revealed.

## Verdict

**PARTIAL PASS.** VP9 unblocked directly. MPEG-2 maintained. VP8 mechanically unblocked (decode runs, output diverges from kdirect). HEVC unchanged (separate kernel-rejection issue, pre-existing). H.264 unchanged (Bug 4 deferred as planned).

| Codec | Pre-β | Post-β + D | kdirect | sw | Verdict |
|---|---|---|---|---|---|
| H.264 1080p30 | `71ac099b…` keyframe partial | `71ac099b…` unchanged | `1e7a0bc9…` | `1e7a0bc9…` | **PARTIAL** — Bug 4 (deferred to iter6) |
| HEVC 720p | `06b2c5a0…` all-zero | `06b2c5a0…` still all-zero | `9340b832…` | `9340b832…` | **FAIL** — separate kernel-rejection issue |
| VP9 720p | `06b2c5a0…` all-zero | **`4f1565e8…`** | `4f1565e8…` | `4f1565e8…` | **PASS** ✓✓✓ (libva == kdirect == sw) |
| MPEG-2 720p | `19eefbf4…` worked | `19eefbf4…` maintained | `19eefbf4…` | `7be8cad7…` | **PASS** (libva == kdirect; HW≠SW is codec precision drift, not Bug 2) |
| VP8 720p | `06b2c5a0…` all-zero | `bcc57ed5…` real content but diverges | `136ce5cb…` | `136ce5cb…` | **PARTIAL** — decode runs, output mismatch (256 unique bytes, real keyframe content `93 8e 8a 89 …`) |

## Per Phase 1 lock criteria

1. **HEVC + VP9 + VP8 libva == kdirect == sw**: **PARTIAL — 1 of 3 (VP9 only).**
2. **MPEG-2 unchanged**: **PASS** (after Commit D fix-forward — pre-D was all-zero, post-D matches pre-iter5b).
3. **H.264 keyframe still decodes**: **PASS** (unchanged).
4. **Control-payload anchors hold**: **PASS** (β didn't touch control submission).

## What happened in two acts

### Act 1 — β alone: regression on MPEG-2, no progress elsewhere

Initial post-β sweep returned all-zero for every libva codec. Strace of HEVC: kernel decoder returned `DQBUF` with `V4L2_BUF_FLAG_ERROR` for every frame. Strace of MPEG-2 (post-β): kernel decoder succeeded (10 DQBUF, 0 ERROR) but the userspace read still got all-zero. The MPEG-2 success/userspace-zero combination pointed at a surface-state issue.

Phase 3 baseline cross-check showed:
- Pre-iter5b HEVC trace.11115+: every DQBUF had ERROR flag too — **pre-iter5b HEVC was already broken at the kernel level**, β didn't introduce this.
- Pre-iter5b MPEG-2 trace.11169: 0 ERROR, decode succeeded, userspace got real pixels — **pre-iter5b MPEG-2 worked end-to-end via libva**.

So β fixed the OUTPUT pixel format mismatch (cosmetic improvement for HEVC; correct format for VP9/VP8) but exposed an MPEG-2 regression. Root cause traced to `context.c:262` comment: `ffmpeg vaapi-copy passes surfaces_count==0 to vaCreateContext`. My β walk of `surfaces_ids[]` for the destination_* fill was therefore a no-op for vaapi-copy → `destination_planes_count` stayed 0 → `surface_bind_slot`'s `for (j=0; j<0; ...)` was a no-op → `destination_data[]` never assigned → `copy_surface_to_image` memcpy of 0 bytes from a NULL src.

### Act 2 — Commit D: cache format-uniform state in driver_data, walk surface_heap, lazy-fill on late CreateSurfaces2

Commit `70196f8` adds:
- `request.h` driver_data fields: `fmt_valid`, `fmt_planes_count`, `fmt_buffers_count`, `fmt_format_height`, `fmt_sizes[]`, `fmt_bytesperlines[]`.
- `surface.h/c`: new `surface_fill_format_uniform(driver_data, surface_object)` helper, idempotent on `destination_planes_count != 0`.
- `context.c::RequestCreateContext`: populates the cache after `v4l2_get_format(CAPTURE)`; walks `surface_heap` (not just `surfaces_ids[]`) to fill every existing surface.
- `context.c::RequestCreateContext`: lazy-fill via the helper after surface allocation.
- `context.c::RequestDestroyContext`: invalidates `fmt_valid = false`.

Post-D sweep: MPEG-2 restored, VP9 PASS, VP8 partial, HEVC unchanged.

## The remaining failures

### HEVC: pre-existing kernel-rejection issue

Pre-β HEVC trace.11115 (Phase 3 baseline, same kernel) showed 4 of 4 DQBUFs with `V4L2_BUF_FLAG_ERROR`. Post-β: same. The kernel rkvdec driver rejects HEVC decode for some reason independent of OUTPUT pixel format.

Per the iter2-close docs, HEVC was claimed PASS via transitive proof: backend control payload byte-matched kdirect's payload. The transitive proof verified controls were CORRECTLY SHAPED, not that the kernel ACCEPTED them. Kdirect submits the same shape and the kernel decodes; libva submits the same shape and the kernel returns ERROR. The difference must be in V4L2 protocol order, request_fd binding, sequence numbers, or some other contract aspect not captured in the control-payload bytes.

**Bug 5** (new): HEVC libva decode triggers `DQBUF` `V4L2_BUF_FLAG_ERROR` from rkvdec. Same kernel + same controls + same fixture works via kdirect. Difference is in the libva backend's V4L2 protocol behavior. Out of iter5b scope.

### VP8: partial — decode runs but output diverges

VP8 libva returns `bcc57ed5…` (4 147 200 bytes, 256 unique bytes, 74.8% zero, real keyframe content). Pre-β was all-zero `06b2c5a0…`. So β did unlock VP8 decode at some level. But the output bytes differ from kdirect's `136ce5cb…`.

Frame 1 first 16 bytes: `93 8e 8a 89 85 72 8c 6d 82 79 92 7e 80 80 80 80` — plausible BBB intro pixels (neutral grey-to-mid-tone). Frames 1, 2, 3 differ from each other (motion content present).

Likely candidates:
- Slot rotation: backend reads from one cap_pool slot while kernel wrote to another (similar pattern as H.264 inter-frame Bug 4).
- Partial fill: each frame's lower portion is zero (74.8% zero is a lot).
- Per-frame DPB binding issue.

**Bug 6** (new): VP8 libva decode produces non-zero but non-matching output. Out of iter5b scope.

## Architecture verdict

The β refactor delivered its core goal: **CreateSurfaces2 no longer touches V4L2 device state; CreateContext owns the OUTPUT-side lifecycle**. The Phase 7 α' failure mode is structurally eliminated — there's no in-CreateSurfaces2 destructive teardown branch to corrupt state mid-stream.

The 2-CRIT findings from Phase 5 v2 (CRIT-1 NULL guard, CRIT-2 missing `request_pool_destroy`) were correct and incorporated; without them, Phase 7 wouldn't have gotten past the first CreateContext.

Commit D was the surprise: the architecturally cleaner β created a new edge case (vaapi-copy late-surface flow) that pre-β didn't have because CreateSurfaces2's "fill destination_* immediately" pattern happened to handle it. The fix-forward restores the equivalent behavior via lazy-fill at both sites.

## What iter5b-β actually shipped

- **VP9 directly verifiable** (no more transitive-proof dependency). Campaign scoreboard: 5/5 with 1 newly direct + 4 mixed (1 prior direct MPEG-2, 1 keyframe-partial H.264, 2 partial/transitive VP8+HEVC).
- **MPEG-2 not regressed.**
- **H.264 not regressed.**
- **Bug 5** (HEVC kernel rejection) and **Bug 6** (VP8 partial output) exposed for iter6+ work.
- **Architecture cleaned up.** surface.c::CreateSurfaces2 is now ~70 LOC (was ~250). context.c::RequestCreateContext owns the OUTPUT lifecycle clearly.

## Substrate state at Phase 7 close

- Fork tip `70196f8` on noether + fresnel + gitea.
- Backend installed SHA `2c6ff82cbdc156ff8910d0c7fe58e75eeecdfd6e6a1caabb049c8adf43a098b8`.
- Kernel `linux-fresnel-fourier 7.0-1` (unchanged).
- Test fixtures unchanged.
- Phase 7 sweep artifacts at `/tmp/iter5b_p7v2/` on fresnel.

## Memory rules — candidates at iter5b-β close

The Phase 5 v2 reviewer's "before claiming no change needed, grep all call sites" discipline saved Phase 6 from CRIT-2 silently breaking the second CreateContext. Worth a memory rule:

**Proposed**: `feedback_grep_all_callsites_before_no_change_claim.md` — When a plan says "no change needed" for a code region, grep all symbols/functions/macros the change touches and enumerate the call sites. The author's surface read at Phase 4 v2 missed `request_pool_destroy` not being in DestroyContext; only the reviewer's enumeration caught it.

The Commit D fix-forward exposes a sibling rule: **trust but verify the iter6 comment**. The iter6 comment at context.c:262 explicitly named the ffmpeg-vaapi-copy surfaces_count=0 case. Phase 4 v2 plan acknowledged the comment but didn't trace the implication for the destination_* walk. Comment read → implication not derived.

Both rules can be folded into one: **plans that touch lifecycle code must enumerate ALL existing comments AND grep ALL call sites for affected symbols; "no change needed" claims must be backed by explicit enumeration**. Defer the memory rule write to Phase 8 close.

## Phase 7 → Phase 8 handoff

Phase 7 closes here. iter5b reaches partial-PASS:

- ✓ VP9 directly unblocked (the primary iter5b-β goal achieved for 1 of the 3 target codecs).
- ✓ MPEG-2 not regressed (Commit D fix-forward).
- ✓ H.264 not regressed.
- ✗ HEVC remains broken (Bug 5 — pre-existing, exposed).
- ✗ VP8 partial (Bug 6 — new, decode-runs-but-output-diverges).

The campaign scoreboard becomes "5/5 with 1 direct (MPEG-2) + 1 newly direct (VP9) + 3 mixed (H.264 keyframe-partial + VP8 partial + HEVC transitive-claimed-but-empirically-failing)."

Phase 8 close documents the iter5b-β shipped state and lists Bug 5 + Bug 6 + Bug 4 as iter6+ work targets. Memory rule update covers the empirical lessons.