α-16 OUTPUT byte dump: libva HEVC frame 1 = 96893 bytes = 1 ANNEX-B
start code + 96890 byte IDR NAL with header 0x28 (nal_unit_type 20 =
IDR_N_LP, correct). Byte-compared against input file's raw HEVC
ANNEX-B stream (after VPS+SPS+PPS): 0 bytes differ over 96890 byte
overlap. The 1-byte tail diff is an inter-NAL boundary marker, not
slice payload.
Libva submits BYTE-IDENTICAL slice bytes as what the input contains
and what kdirect submits. Combined with iter11's wire-byte audit
showing every libva-vs-kdirect control diff is in a field rkvdec
ignores, AND iter12's RFC v2 substrate upgrade producing zero
codec-correctness change, AND iter13's DMA_BUF_IOCTL_SYNC ioctl
working but inert:
Cumulative iter8-iter14: 13 hypotheses eliminated. Libva backend
is empirically byte-correct on its side. Bug 4 + Bug 5 are
KERNEL-SIDE failures specific to how rkvdec processes the libva
ioctl sequence vs the kdirect sequence — NOT a libva backend bug.
iter15+ candidates:
- Full ioctl-sequence trace diff (libva vs kdirect, find first
divergence in syscall order/args).
- kernel-side rkvdec ftrace/eBPF kprobe instrumentation; route
via kernel-agent.
- Campaign close-out: VP9+MPEG-2 PASS direct, HEVC+H.264+VP8 narrowed
to kernel-side with byte-clean libva submission.
Backend SHA fa2098b6... 8 cumulative iter11-iter14 commits all ship
clean (wire-correctness, env-gated diagnostics, zero regression).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
