Phase 7 verification on fresnel (kernel 7.0-14 / linux-fresnel-fourier).
C1 vainfo enumeration: PASS — VAProfileH264High10 + VAProfileHEVCMain10
both listed; iter38 baseline 10 profiles intact at 12 total.
C5 iter38 5/5 baseline preserved: PASS — H.264 / HEVC / VP9 / VP8 /
MPEG-2 all libva == kdirect bit-exact, no regression from iter39
backend changes.
C2 Hi10P bit-exact vs kdirect: N/A — kdirect ALSO fails with EINVAL
(0 bytes output). The kernel ctrl table advertises Hi10P + NV15
CAPTURE but RK3399 HW doesn't actually decode 10-bit H264. Verified:
S_FMT(CAPTURE, NV15) succeeds; decode submits cleanly; CAPTURE buffer
returns all-zero. xxd 64 bytes of 0x00. SW reference has 222 unique
luma bytes.
C3 Main10 bit-exact vs kdirect: untested — system x265 is 8-bit-only
build, no kvazaar/x265-hbd in Arch repos, no Main10 sample downloaded
successfully. Same kernel-vs-HW caveat may apply.
Two backend fixes landed during Phase 7 (both pushed to gitea master):
a13215d — skip pre-S_FMT NV15 CAPTURE format probe (rkvdec only
advertises NV15 AFTER S_FMT(OUTPUT) + S_EXT_CTRLS(SPS))
63fed87 — advertise P010 unconditionally in QueryImageFormats
(ffmpeg-vaapi queries before CreateContext fires; gating
on is_10bit hid the format from early consumers)
Without these the 10-bit decode pipeline can't even start. With them
it reaches the kernel cleanly.
Memory entry filed:
feedback_rk3399_h264_hi10p_advertised_not_functional.md
(kernel ctrl table necessary but NOT sufficient — always cross-check
with kdirect before treating a profile as truly HW-supported)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
marfrit