Applied iter14's α-16 OUTPUT byte verification to VP8. Result:
libva VP8 frame 1 OUTPUT dump: 300614 bytes
input IVF frame 1: 300624 bytes
diff with +10-byte offset (VP8 uncompressed header stripped by VAAPI
consumer client-side): 0 bytes differ.
Libva's VP8 OUTPUT bytes are byte-identical to the input frame minus
the 10-byte uncompressed header. Same correctness as iter14's HEVC
verification.
Cumulative finding: ALL THREE remaining campaign bugs (Bug 4 H.264
partial-fill, Bug 5 HEVC all-zero, Bug 6 VP8 partial) have:
- libva controls byte-equal to kdirect on rkvdec-read fields
- libva OUTPUT bitstream bytes byte-identical to input
- libva ioctl sequence structurally close to kdirect after iter15 α-19
But:
- VP9 + MPEG-2 work via the same libva backend on the same kernel.
- libva HEVC/H.264 hash to wrong output; kdirect HEVC/H.264 hash to
correct output. Same kernel.
Therefore Bug 4 + 5 + 6 are kernel-side rkvdec/hantro per-codec bugs
specific to libva's ioctl pattern. Per
feedback_libva_byte_correct_kernel_bug.md (saved iter14), libva-side
changes are confirmed inert for these bugs.
iter17 productive direction: kernel-side investigation via
kernel-agent workflow. Read rkvdec source, instrument via ftrace/
eBPF kprobe, compare kernel state evolution between libva-trigger
and kdirect-trigger for same bitstream.
No code changes in iter16. Substrate unchanged.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
