Phase 1 amended: scope merged (A: cap_pool resolution-change race
+ I: Firefox VIDIOC_QBUF EINVAL) after Phase 2 telemetry showed
they're facets of the same buffer-pool / surface-recycle lifecycle
weakness.
Phase 2 findings:
- Original "S_EXT_CTRLS fails on frame 1" was transient state, does
not reproduce on iter6-DX diagnostic build.
- Reproducible failure: OUTPUT VIDIOC_QBUF EINVAL after a varying
number of successful frames (1, 19, 53 across three runs).
- mpv-vaapi-copy clean — single-surface recycle pattern doesn't
trigger the race; Firefox's multi-surface MediaSource pattern does.
- DQBUF index-mismatch theory: ruled out.
- Control payload divergence: ruled out (first 64 bytes byte-identical
between mpv and Firefox).
- Surviving hypothesis: request_fd lifecycle race — fd=30 reused on
every frame after close, kernel-side request object may not release
synchronously, next QBUF on REQUEST_FD=30 collides with stale state.
Phase 4 leading approach: C — extend iter4's "drain before reuse"
discipline from request_fd to OUTPUT pool slot. Mirror picture.c's
cap_pool unbind-before-rebind pattern in the OUTPUT lifecycle.
iter6-DX diagnostic build is local on ohm (/home/mfritsche/iter6-fork-dx).
Diagnostics are not committed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Re-tested the iter5-amend binary on YouTube with Enhancer for YouTube
forcing h264 (avc1). Captured a richer failure pattern:
- Multiple cap_pool_init events (4 decode attempts on one tab)
- Zero seccomp violations (Track F still GREEN under YT load)
- "Unable to set control(s): Invalid argument" — VIDIOC_S_EXT_CTRLS EINVAL
on one of SPS/PPS/SLICE_PARAMS/DECODE_PARAMS/SCALING_MATRIX (cannot
identify which without per-control TRY isolation, which iter5
sweep d3a299b removed)
- "Unable to queue buffer: Invalid argument" — VIDIOC_QBUF EINVAL
The S_EXT_CTRLS EINVAL is the more diagnostic of the two — points
to a compound H.264 control payload mismatch between Firefox's libva
path and what mpv-vaapi-copy sends.
Updated iter6 candidate I:
- Added the YouTube failure pattern alongside the bbb pattern
- Step-1 of diagnostic plan: reinstate per-control TRY isolation
temporarily (do not commit; diagnosis-only)
- Cross-reference with FFmpeg v4l2_request_h264.c per existing memory
- Reproducibility: now 100% on YT-avc1 OR bbb-h264
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Patched libmozsandbox.so (sha 4e6c7d58…, +1824 bytes vs iter5-G)
deployed to ohm via temporary HTTP server on boltzmann:18080
(vpn route was closed; ohm has lan route to boltzmann.fritz.box).
Sandbox gate is fully open. With LIBVA_DRIVER_NAME=v4l2_request +
sandbox enabled + bbb_1080p30_h264.mp4, Firefox 150 emits:
v4l2-request: cap_pool_init: 24 slots ready
v4l2-request: Unable to queue buffer: Invalid argument
vs pre-amendment which had the seccomp violation +
"Unable to allocate media request: Function not implemented"
between those two lines. Track F closes GREEN.
YouTube test (watch?v=7DAPd5MGodY) didn't engage v4l2_request
because YT negotiated VP9/AV1 with FF150 (no h264ify); v4l2_request
only handles H.264. Codec-negotiation issue, not sandbox issue.
New iter6 candidate I documented: Firefox VIDIOC_QBUF EINVAL on
first frame is consumer-specific (mpv-vaapi-copy clean at 2000
frames on same driver). Diagnostic plan and repro included.
phase8_iteration5_close.md: appended Track F GREEN evidence +
post-amendment status table + iter6 candidate referral.
phase0_findings_iter6.md: added candidate I (Firefox QBUF EINVAL),
listed under recommended pairings as strong iter6-lock candidate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Carries forward from iter5 close: cap_pool race fix (sonnet C4),
msync verify (sonnet C3), upstream prep (gated), perf cell, MPEG-2
audit, V4L2_MEMORY_DMABUF.
NEW from iter5 stock-Brave investigation: candidate C — verify
chromium-fourier + iter5 driver compatibility. Stock Brave doesn't
even reach VAAPI (GL bindings die before decoder selection); the
chromium-fourier campaign is still required for the GL-stack fix.
Open question: which of chromium-fourier's libva-side patches are
obsoleted by iter4+iter5 fixes.
Recommended primary: A+B (cap_pool race fix + msync verify) —
both are iter5 sonnet caveats, small scope, prereqs for upstream.
Or A+B+D if iter6 becomes the upstream-prep iteration.
Phase 1 lock awaits user pick.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
claude-noether