Captures the post-Phase-5-design-review experiment:
- pool=4 -> 16 only delayed failure (1/19/53 -> 62 frames),
refuting pool exhaustion as the dominant cause
- Surviving hypothesis: kernel-side buffer-state contention with
fd-reuse on close+alloc cycle, surfaced by Firefox's multi-
surface MediaSource pattern
- Three Phase 4 directions weighed; operator chose 3 (REINIT)
with 1 (kernel analysis) as fallback if 3 failed
This file now serves as the iter6 Phase 2 reference for future
iterations — the "Phase 5 (front-loaded design review)" section
documents the back-and-forth with sonnet that shaped the final
fix shape.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
claude-noether