From 4df33443396b34d23cea7681bafe73e1d29f21e6 Mon Sep 17 00:00:00 2001 From: claude-noether Date: Tue, 5 May 2026 19:45:47 +0000 Subject: [PATCH] iter6 Phase 1: lock candidate I (Firefox H.264 EINVAL) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- phase0_findings_iter6.md | 44 ++++++++++++++++++++++------------------ 1 file changed, 24 insertions(+), 20 deletions(-) diff --git a/phase0_findings_iter6.md b/phase0_findings_iter6.md index 35357a8..be64e06 100644 --- a/phase0_findings_iter6.md +++ b/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."