WP-D leg 1 (.25 RADV, distinct mode) root causes, both real:
1. Output starvation: the fixed 4-deep ring lost to a stream that keeps
max_dpb_frames+1 = 8 pictures pending. Zero-copy fix (user
requirement, no copies): one picture pool of required_slots +
HOLD_HEADROOM(8) images decoupled from DPB slots — a re-activated
slot binds a fresh free image, so a delivered picture is never a
decode target; the WP-B pin layer became dead and is deleted.
Per-image timeline semaphores carry the AVVkFrame contract: decode
signals value+1, the presenter waits and signals back, later decodes
wait the image's latest value — layout traffic ordered against
reference reads with no copy anywhere.
2. RESULT_STATUS queries HANG RADV's VCN firmware (ring timeout,
DEVICE_LOST): queryResultStatusSupport=false on the decode family.
Queries are now caps-gated; without them poll/wait degrade to
timeline-completion verdicts (FFmpeg parity — and the likely reason
upstream never wired nb_queries). The Ally-X-class detection runs
where drivers advertise the query; .173 probes NVIDIA/Windows-AMD.
Also: slice-only bitstream feeding (the field-proven consumer shape),
graveyarded pool retirement keyed by release tokens + generation,
decode-current-AU-before-status attribution, take_ready drained,
H264-bit gating, teardown short-circuit on disconnected channel.
On-glass: 48 AUs green on .25 holding 4 frames like the real client.
Gates: fmt clean, container clippy -D warnings zero, 27+121+52 green
both platforms.
enricobuehler
6331ae7fd9