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