From c7c0bcae7255ffd4d09c6c614716ea7cd8b92e9d Mon Sep 17 00:00:00 2001 From: claude-noether Date: Tue, 5 May 2026 19:42:32 +0000 Subject: [PATCH] iter6 candidate I: enrich with YouTube avc1 telemetry MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- phase0_findings_iter6.md | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/phase0_findings_iter6.md b/phase0_findings_iter6.md index 90bc2d2..35357a8 100644 --- a/phase0_findings_iter6.md +++ b/phase0_findings_iter6.md @@ -71,9 +71,26 @@ The campaign's original substrate question — "make multi-planar libva work end **Why this is a new candidate, not a Track A regression**: mpv `--hwdec=vaapi-copy` decoded 2000 frames clean on the same iter5-end driver build (sha `4bed52ec5d44b389…`). Only Firefox triggers the EINVAL. So the bug lives in the Firefox-specific consumer path through libva, not in the per-frame request_fd/DPB logic that iter4 closed. -**Diagnostic plan**: strace the Firefox Utility process during initial VIDIOC_QBUF, capture the exact `v4l2_buffer` struct payload, compare against what mpv-vaapi-copy sends at the same call site. Likely culprits: surface handle lifecycle differences (Firefox uses VAImage / VAExportSurfaceHandle paths mpv doesn't), VABufferType ordering (Firefox might submit slice data before SPS/PPS in some frames), or zero-copy DMA-buf attach state. +**Failure modes observed (iter5-amend telemetry, 2026-05-05)**: +``` +bbb_1080p30_h264.mp4 (single decode attempt): + v4l2-request: cap_pool_init: 24 slots ready + v4l2-request: Unable to queue buffer: Invalid argument -**Reproducibility**: 100% on `file:///home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` with `LIBVA_DRIVER_NAME=v4l2_request` env vars + iter5-amend Firefox 150 + sandbox enabled. +YouTube avc1 (Enhancer for YouTube forcing h264, multiple decode attempts on same tab): + v4l2-request: cap_pool_init: 24 slots ready (×4) + v4l2-request: Unable to set control(s): Invalid argument + v4l2-request: Unable to queue buffer: Invalid argument +``` + +The S_EXT_CTRLS EINVAL is the more diagnostic signal — one of the compound H.264 controls (SPS/PPS/SLICE_PARAMS/DECODE_PARAMS/SCALING_MATRIX) is being rejected by the kernel. iter5 sweep removed the iter4 per-control TRY isolation (`d3a299b`); reinstating it temporarily (or strace) is iter6 step one. + +**Diagnostic plan**: +1. Reinstate per-control VIDIOC_TRY_EXT_CTRLS isolation in v4l2.c (the iter4 diagnostic that pinpointed which compound control fails). Do not commit; use only for diagnosis. +2. Strace the Firefox Utility process during decode init. Capture exact `v4l2_ext_control` payloads. Cross-reference with FFmpeg's `v4l2_request_h264.c` (cached at `references/ffmpeg-kwiboo/`, the empirical authority per memory). +3. Once the offending control is identified, look at how Firefox's libva path constructs it differently from mpv-vaapi-copy. Likely: a header field Firefox doesn't populate, an order-of-operations difference, or a VAImage / VAExportSurfaceHandle side effect that perturbs driver state. + +**Reproducibility**: 100% on either `file:///home/mfritsche/fourier-test/bbb_1080p30_h264.mp4` OR YouTube avc1 (with enhanced-h264ify or Enhancer for YouTube forcing h264) + `LIBVA_DRIVER_NAME=v4l2_request` env vars + iter5-amend Firefox 150 + sandbox enabled. **Risk**: medium. Could be a 5-line fix in v4l2.c QBUF prep, or could surface a fundamental Firefox-vs-mpv divergence in libva surface management.