iter6 Phase 1: lock candidate I (Firefox H.264 EINVAL)

Operator chose candidate I as iter6 sole scope after iter5 amendment
demonstrated it as the only known consumer hard-failure under the
post-amendment binary.

Phase 1 success criterion locked:
  Firefox 150 (iter5-amend, sandbox enabled, LIBVA_DRIVER_NAME=v4l2_request)
  plays bbb_1080p30_h264.mp4 ≥30s with HW decode actually engaged:
  - cap_pool_init succeeds, zero S_EXT_CTRLS / QBUF errors per-frame
  - lsof /dev/video1 shows Firefox Utility process holding it
  - about:support media decoder names vaapi-or-equivalent
  - Phase 5 sonnet must confirm fix-location and that
    mpv-vaapi-copy 2000-frame test still GREEN (no regression)

iter6 phases 2..8 proceed autonomously per "Stop only if user
is needed."

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

phase0_findings_iter6.md

@@ -140,9 +140,13 @@ Same as iter5. Plus for new candidates:
 - For E (perf): `pidstat -u` for CPU%, Mali-G52 freq via `/sys/class/devfreq/fde60000.gpu`.
 - For F (MPEG-2): need an MPEG-2 fixture (`mpv --dump-stream` from a public DVD or transcode bbb to MPEG-2).
 
-## In-scope (LOCKING DEFERRED — Phase 1 user input)
+## In-scope (LOCKED 2026-05-05 for iteration 6) — I (Firefox VIDIOC_S_EXT_CTRLS / VIDIOC_QBUF EINVAL)
 
-To be locked at Phase 1 from candidates A..G above. H is a separate top-level campaign decision, not an iter6 candidate.
+Operator locked candidate **I** (Firefox VIDIOC_QBUF EINVAL on first frame, enriched post-iter5-amend telemetry to also include S_EXT_CTRLS EINVAL).
+
+Why I: deterministic repro on two consumers (bbb fixture + YouTube avc1), narrowest scope of any candidate, gates the only known consumer hard-failure under the post-amendment binary. Also: iter5-amend just unblocked Firefox's path; closing this completes the Firefox HW-decode story end-to-end.
+
+Other candidates (A, B, C, D, E, F, G) deferred to iter7+. H (fourier-fresnel) remains separate top-level campaign.
 
 ## Out-of-scope (LOCKED 2026-05-05 for iteration 6)
 
@@ -152,26 +156,26 @@ To be locked at Phase 1 from candidates A..G above. H is a separate top-level ca
 - New codecs OUTSIDE H.264 / MPEG-2 (VP8/VP9/AV1/HEVC out per iter1 lock).
 - New target hardware (fresnel, ampere) — separate campaign (H above).
 
-## Phase 1 success criterion (will lock after user picks candidate)
+## Phase 1 success criterion (LOCKED 2026-05-05 for iteration 6)
 
-Pre-lock template:
-- For candidate A: "`vaCreateSurfaces` race-probe test program runs cleanly with no REQBUFS EBUSY events; mpv libplacebo --vo=gpu test still GREEN; iter5-end smoke test still 0 EINVAL."
-- For candidate B: "vaapi-copy 100-frame run produces frame-hash matching pre-iter5-sweep baseline; OR if divergence, msync restored and verified."
-- For candidate C: "chromium-fourier 149 builds + runs against iter5 driver. v4l2-request: traces present in stderr. Decode works at ≥24 fps. Patch matrix updated indicating which chromium-fourier libva-side patches are obsolete vs still required."
-- For candidate D: "Mozilla Bugzilla bug filed with firefox-fourier patch attached; bootlin issue filed against libva-v4l2-request with iter1-iter5 patch series."
-- For candidate E: "Anchored perf table for {mpv vaapi DMA-BUF, mpv vaapi-copy, Firefox-fourier HW, SW baseline} across drop count + CPU% + frame timing on bbb_1080p30. Reproducible from documented script."
-- For candidate F: "MPEG-2 fixture decodes through hantro G1 via libva-v4l2-request-fourier without crashes / EINVAL."
-- For candidate G: "vaapi-copy + vaapi --vo=null still produce real frames with V4L2_MEMORY_DMABUF-backed CAPTURE buffers; race window architecturally closed."
+> Firefox 150 (iter5-amend, sandbox enabled, `LIBVA_DRIVER_NAME=v4l2_request`) plays a known-h264 fixture (`bbb_1080p30_h264.mp4`) for ≥30 seconds with HW decode actually engaged: `cap_pool_init` succeeds, **zero `Unable to set control(s)` and zero `Unable to queue buffer`** in driver stderr, `lsof /dev/video1` shows the Firefox Utility process holding the device throughout playback, frames advance, no SW fallback in `about:support`'s "Decoder Backend" fields.
+>
+> Acceptance evidence (capture all three):
+> 1. Driver stderr lines: only the single per-process `cap_pool_init: 24 slots ready` log, no per-frame errors.
+> 2. `lsof /dev/video1` snapshot at t=15s into playback shows a Firefox process (PID parent or descendant of the launcher) with the device open.
+> 3. about:support's media decoder section names `vaapi`-or-equivalent for video/h264, not `ffvpx`.
+>
+> Phase 5 sonnet review must explicitly confirm that the fix is on the libva-side (or jointly libva + a Firefox-side patch), and that mpv-vaapi-copy 2000-frame test still GREEN (no regression introduced).
 
-## Stop point
+## Phase 1 LOCKED. Iteration 6 proceeds.
 
-**Phase 1 lock requires user input** — pick from A..G (and any pairing).
-
-Recommended primary: **A + B** (cap_pool race fix + msync verify) — both are iter5 sonnet review caveats, both small scope, both prerequisites for clean upstream submission. If the operator wants to make iter6 the upstream-prep iteration, **A + B + D** (the pair plus upstream filings) is the natural next step.
-
-Alternative leans:
-- **C alone** if "do we still need chromium-fourier?" is the more pressing question
-- **E alone** if perf measurement matters more than upstream prep
-- **F alone** if multi-codec coverage is a higher priority than refinement
+iter6 = candidate **I** alone. Phases 2..8:
+- Phase 2: situation analysis — strace the failing Firefox decode, identify the offending compound H.264 control payload field, compare to FFmpeg `v4l2_request_h264.c` and to mpv-vaapi-copy's payload at the same call site.
+- Phase 3: baseline anchor — capture the iter5-amend driver stderr + about:support decoder backend strings on the failing case, snapshot pre-fix.
+- Phase 4: plan + execute the fix in the libva-v4l2-request-fourier driver (or, if root cause is upstream Firefox, document and stop).
+- Phase 5: sonnet review.
+- Phase 6: deploy fixed driver to ohm.
+- Phase 7: verify against the success criterion above.
+- Phase 8: close.
 
 After lock, iter6 phases 2..8 proceed autonomously per "Stop only if user is needed."