iter6 close: A∪I GREEN — per-slot request_fd binding via REINIT

Single architectural fix lands at libva-v4l2-request-fourier
commit a09c03c (`iter6 fix: per-OUTPUT-slot request_fd binding via
REINIT`). Closes both:

- candidate I (Firefox VIDIOC_QBUF EINVAL after multi-surface decode)
- candidate A (cap_pool resolution-change race) — organically
  exercised and verified on YouTube avc1 4 cap_pool_init events
  handled cleanly

Phase 1 success criterion met across all three consumer paths:
- Firefox bbb_1080p30_h264.mp4: 35s+ clean, RDD holds /dev/video1
  + /dev/media0 throughout, zero per-frame errors
- Firefox YouTube avc1 (Enhancer for YouTube forcing h264): ~95s
  sustained, zero errors, 4 cap_pool_init resolution
  renegotiations clean
- mpv vaapi-copy regression: clean 50-frame run, EOF reached

Phase 5 sonnet design review (front-loaded) refuted the pool-
exhaustion competing hypothesis via experiment, endorsed
direction 3 (REINIT). Phase 5 sonnet code review:
APPROVE-WITH-CHANGES (one comment attribution corrected).

Memory updates:
- feedback_request_fd_lifecycle.md: rewritten. iter4's
  case-against-REINIT was a DPB-payload confounder. iter6
  reinstates REINIT with per-slot binding as the correct
  discipline. Meta-lesson recorded: when a prior "rule out X"
  was about an unrelated bug, X is back on the table.

firefox-fourier/README.md: YouTube codec-negotiation note added
(Enhancer for YouTube / enhanced-h264ify needed to force avc1
since FF150 auto-negotiates AV1).

WiFi-IRQ-induced frame drops observed during YouTube playback
documented as out-of-scope system concern (decode pipeline
unaffected; presentation-schedule slips under brcm/iwlwifi IRQ
spikes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-05 21:44:45 +00:00
parent 793409b960
commit 104abd1624
2 changed files with 107 additions and 0 deletions
+4
View File
@@ -94,6 +94,10 @@ sudo cp build/src/v4l2_request_drv_video.so /usr/lib/dri/
Then either patched Firefox OR `MOZ_DISABLE_RDD_SANDBOX=1` will work for HW decode.
### YouTube codec note
YouTube negotiates the highest codec the browser advertises support for. Without forcing avc1, FF150 picks AV1 from YouTube on most modern hardware and SW-decodes — the v4l2_request driver only handles H.264, so libva isn't engaged. To exercise HW decode on YouTube, install [`Enhancer for YouTube`](https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-youtube/) or [`enhanced-h264ify`](https://addons.mozilla.org/en-US/firefox/addon/enhanced-h264ify/) and configure it to force h264 codec.
## Upstream status
Not upstreamed at this writing (campaign discipline: no PR/MR without explicit operator instruction). The patch is Mozilla-bug-and-PR-ready in shape and ~50 lines across two files. Whoever picks it up to file with Mozilla should reference the existing `Bug 1833354` and `Bug 1965646` (V4L2-M2M precedent) as related work; this is the V4L2-stateless analogue.