v2.1.0 "Deep Ink" — HEVC decodes, 10-bit is correct

Deep Ink — HEVC decodes through this driver for the first time, and 10-bit output is correct.

HEVC now works

HEVC had never decoded here, at any bit depth, for anyone: the driver advertised it, but there was no HEVC bitstream assembler, so the VPU received a stream it could not parse and handed back empty — the solid green frame RK3588 users have reported for two years. The assembler now exists: VPS synthesised, SPS/PPS reconstructed from the VA-API parameters, Annex B stitching, plus two requirements found only on hardware — a stateless VA-API bridge must declare no picture reordering, and the reference-picture-set layout must be taken from the parameter struct and never revised mid-stream (re-sending a changed SPS flushes the decoder's picture buffer and destroys the references B-frames depend on).

VAProfileHEVCMain (8-bit) is now advertised — it earned it. Both Firefox and Chrome hardware-decode 8-bit HEVC through this driver. Firefox needs media.hevc.enabled in about:config; on Linux it defaults off.

10-bit is correct, and fast

The VPU returns 10-bit frames as packed NV15; the driver exported those bytes labelled P010 — different layouts, hence corruption. They are now repacked to true P010, with a hand-written NEON path: dropped frames on 4K 10-bit fell from 318 to 6. A unit test proves the vectorised unpack bit-identical to the reference for every width.

HEVC Main10 stays unadvertised — it decodes correctly, but the GPU stack these BSP images ship (panfork, Mesa 23) cannot present 10-bit surfaces, and advertising it makes Chrome direct-play into a green screen. Copy-back clients can opt in per process with RKVA_ADVERTISE_ALL=1 and mpv --hwdec=vaapi-copy.

Verification

Every claim above was checked by decoding through the driver and comparing frames pixel-by-pixel against a software reference (tools/hevc-ladder.sh, committed). H.264, HEVC 8-bit, HEVC Main10 and VP9 Profile 2 all come back identical — mean difference 0.00/255 — including a full 12-minute 4096×1714 Main10 feature played end to end, all 17,616 frames, no failures.

Also

• vaDeriveImage is implemented against the decoded surface (previously it returned an empty image, so every copy-back reader silently got zeros)
• The unaligned-width VP9 fix from v2.0 is unchanged

Known issues

KNOWN-ISSUES — read KI-1 before upgrading: H.264 streams that use B-frames decode to a corrupted picture (ghosting, occasional green frames). This is present in v2.0 as well, not a regression, and is under active investigation; software decode plays those files correctly.

Install

sudo apt install ./rockchip-vaapi-driver_2.1.0_arm64.deb

Requires a BSP kernel exposing /dev/mpp_service.

Base driver: woodyst (Eduardo García-Mádico Portabella) · PR woodyst#2 fixes: truongsinh · this release: defcom5-rockchip, with Claude as co-engineer.