DEFINITIVE FINDING via pr_info in rkvdec_hevc_run on RK3399:
libva HEVC: w=0 h=0 reorder=0 chroma=0 nal_unit_type=0 decode_flags=0x0
kdirect HEVC: w=1280 h=720 reorder=2 chroma=1 nal_unit_type=20 decode_flags=0x3
The kernel sees ALL-ZERO control structs for libva HEVC, but CORRECT values
for kdirect. Same kernel, same code path, same /dev/video1, same
rkvdec_hevc_run_preamble fetching v4l2_ctrl_find(ctx->ctrl_hdl,
HEVC_SPS)->p_cur.p.
This overturns iter11-iter15's "wire-byte search exhausted" conclusion.
The S_EXT_CTRLS payloads ARE byte-correct at the strace observer level,
but the kernel sees zeros. The bug is in the
S_EXT_CTRLS -> request -> ctx->ctrl_hdl path, specifically for libva.
Five mechanisms hypothesized:
1. request_fd mismatch
2. REINIT clears controls before QUEUE
3. Compound-control copy deferred until QUEUE -> stack-locals stale
4. ctrl_hdl mismatch (libva submits to one, rkvdec reads another)
5. error_idx silently fails
Key difference observed:
libva stores SPS/PPS/decode_params as STACK LOCALS in h265_set_controls
kdirect stores them in heap-allocated hwaccel_picture_private
Mechanism 3 (kernel defers compound-ctrl copy_from_user) is the leading
hypothesis. iter18 α-21: heap-allocate libva's HEVC control structs;
if Bug 5 fixes, apply same pattern to H.264 (Bug 4) and VP8 (Bug 6).
This is the strongest narrowing since iter5b-β.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
