[jcelerier]

Re-enables the Vulkan compute-shader decoders (ProRes, FFV1) that 42f0e43 refused, as long as the libavcodec actually loaded has FFmpeg master's ProRes fixes.

codecSupportsHWPixelFormat() now refuses them only when vulkanComputeDecodersAreReliable() is false, i.e. when avcodec_version() < 63.2.0:

• the FFmpeg 9.0 release branch is lavc 63.1.x and stays buggy, so Linux builds against a distribution's 9.0.x keep the software decoder;
• master fixed the decoder on 2026-09-20 at lavc 63.14. Its latest bump went from 63.20 to 63.2 (0ec6a0872d, meant 63.21), which is why the bound is 63.2 rather than 63.15. The price is that master snapshots from between 9.0's branch point (June) and 2026-09-20 would also count as fixed.

Needs the SDK on FFmpeg master: ossia/sdk#51. Unchanged: FFV1 still isn't in ffmpegCanDoHardwareDecoding(), so it only reaches Vulkan when explicitly requested. FFmpeg warns that Vulkan FFV1 "may be very slow" with few slices, so automatic selection would deserve its own measurement.

Tested (linux-x86_64; Intel Arc ARL on Mesa 26.2.4 ANV and RTX 5090 on NVIDIA 615.78, each forced first with MESA_VK_DEVICE_SELECT)

tests/corpus/run-hwdec.sh with HWDEC_ACCELS=vulkan on the FATE prores/ set and the generated ProRes files. The tester was built from this branch against FFmpeg master 71403a21b0 (+ the SDK's rebased rpi patch):

file	FFmpeg master, Intel and NVIDIA (identical)	system FFmpeg 9.0.2
Sequence_1 ProRes 422 / HQ / LT / Proxy	engaged vulkan, PIXEL_MISMATCH_MINOR, max delta 1	HW_FALLBACK (gate)
Sequence_1 ProRes with Alpha	engaged vulkan, minor, max delta 1	HW_FALLBACK
gray.mov	engaged vulkan, PIXEL_DRIFT, max delta 1	HW_FALLBACK
prores4444_with_transparency.mov	engaged vulkan, minor, max delta 1	HW_FALLBACK
generated prores-std / -4444 / -odd	engaged vulkan, PIXEL_DRIFT, max delta 1	HW_FALLBACK

test_unit_gpu_formats passes against both FFmpeg master and 9.0.2.

FFmpeg-level comparison over all 30 frames (-hwaccel vulkan + hwdownload vs software; details in ossia/sdk#51). On 9.0.2 the FATE 422 Proxy/LT files are up to 147 off with ~0.1% of samples grossly wrong; on master everything is ±1, except:

• Known remaining FFmpeg bug. When neither dimension is a multiple of 16 (generated prores-odd.mov, 322×178), the chroma of the bottom-right partial macroblock is wrong in some frames: up to 161 off, 72 samples over 30 frames. run-hwdec.sh doesn't see it, because the tester classifies a file by its first mismatching frame only, and here that is frame 0 (max delta 1). It isn't gated: the gate can't see frame sizes, and ProRes material is practically always a standard size.
• Clean aperture. prores4444_with_transparency.mov has a MOV clap (1888×1062 of 1920×1080). On a hardware frame FFmpeg crops the top by 8 instead of 9. score's direct path doesn't apply container crops to hardware frames at all (no crop_* handling for any codec), which is why the tester sees the full frame and a clean match. Not addressed here.

🤖 Generated with Claude Code

[coveralls]

coverage: 48.868% (-0.3%) from 49.16% — fix/vulkan-compute-decoders into master