FFmpeg 9.0 Bets the GPU Stack on Vulkan

FFmpeg 9.0 "Lei" shipped on August 3, about four and a half months after 8.1 "Hoare" and almost exactly a year after the enormous 8.0 "Huffman" release. The changelog is shorter than 8.0's, and that's fine — this isn't a release you upgrade for one headline feature. It's the release where FFmpeg's multi-year Vulkan bet stops looking like an experiment and starts looking like the plan: a single, vendor-neutral GPU layer for video work that fixed-function silicon will never cover. And, almost as a bonus, it finally closes one of the project's most irritating everyday gaps: FFmpeg can now decode animated WebP.

Vulkan stopped being an experiment

Look at the arc. FFmpeg 6.0 rebuilt Vulkan video decode around the Khronos video extensions. 8.0 brought Vulkan AV1 encoding and compute-shader codecs; 8.1 pushed the compute-codec work further. Now 9.0 adds Vulkan hardware acceleration for APV — Samsung's Advanced Professional Video codec, which FFmpeg picked up in 8.0 — plus Vulkan-accelerated ProRes RAW, and v360_vulkan, a GPU implementation of the 360-degree reprojection filter.

The pattern matters more than the individual items. APV and ProRes RAW are exactly the codecs that dedicated decode ASICs will never touch: too niche, too professional, too new. Traditional hwaccel meant waiting for NVDEC, VA-API, QSV, AMF, and VideoToolbox to each grow support — which for acquisition codecs never happens. Compute-based Vulkan acceleration sidesteps the whole zoo: write the shaders once, run them on any GPU with a competent Vulkan driver, across vendors and operating systems. That's a structurally different answer to GPU video than the five-API patchwork developers have been juggling for a decade, and 9.0 is the clearest signal yet that FFmpeg intends Vulkan to be the default answer for anything the fixed-function blocks don't do.

v360_vulkan is the sleeper here. The CPU v360 filter is the standard tool for equirectangular-to-cubemap remapping in VR and 360-video pipelines, and it's painfully slow at 8K — often the bottleneck of the whole transcode. Moving that projection math onto the GPU, in the same process that's already decoding there, removes a round-trip that VR delivery pipelines have been eating for years.

The WebP gap, finally closed

FFmpeg has been able to write animated WebP for ages via libwebp. Reading one back got you the first frame at best, plus a stream of "skipping unsupported chunk: ANIM" warnings — an asymmetry that generated years of confused bug reports, because WebP is what every chat app and sticker platform actually emits. Patches circulated on the mailing list through eleven revisions before landing. In 9.0, this just works:

ffmpeg -i sticker.webp -pix_fmt yuv420p -movflags +faststart sticker.mp4

If you run user-generated-content ingestion, this quietly deletes a whole workaround layer — the anim_dump frame-extraction shims, the libwebp sidecar tooling, the "sorry, we don't support that format" error paths for a format users upload constantly. Thumbnailers, media proxies, and moderation pipelines can now treat animated WebP like any other input. That's a small line in the changelog and a real operational simplification.

The vendors are showing up

The AMD story in 9.0 is sustained investment rather than a one-off: the AMF color converter gains HDR capabilities, a new vf_frc_amf filter does hardware frame-rate conversion, and AMF gets hardware memory mapping — the unglamorous plumbing that keeps frames on the GPU between decode, filter, and encode instead of bouncing through system RAM. AMD has historically been the least-loved vendor in FFmpeg hardware pipelines; three releases of steady AMF work suggests they've noticed where transcoding actually happens.

NVIDIA users get a CUDA transpose filter and a cleanup with teeth: 9.0 removes deprecated NVENC options and support for Video Codec SDK versions before 11.1. In practice that sets a driver floor around NVIDIA's 470-era branches — if you're running transcode fleets on older pinned drivers (common in datacenters that treat driver upgrades as a capital project), NVENC stops working when you move to 9.0. Audit driver versions before you touch base images.

The most forward-looking item is the DNN backend for ONNX Runtime with GPU execution-provider support. FFmpeg's neural filters have cycled through TensorFlow and OpenVINO backends that mostly nobody built against. ONNX is the format models actually ship in, and execution providers mean the same filter graph can hit CUDA, DirectML, or CoreML underneath. Running super-resolution or denoising models inline via dnn_processing — no Python sidecar, no frame export — becomes genuinely practical for the first time.

There's charm in the margins, too: a video encoder and muxer for Playdate, Panic's 1-bit handheld; HE-AAC 960 decoding for DAB+ digital radio; LCEVC track muxing in MP4; and a bitstream filter that splits multi-layer Dolby Vision HEVC — a job that previously meant reaching for dovi_tool in a separate pipeline step. The removals are painless: the standalone pre-Opus CELT decoder is gone, and no, that doesn't affect Opus.

The upgrade math

This is a major release, and FFmpeg majors are where the ABI breaks land: library sonames bump and APIs deprecated during the 8.x cycle are gone. If you ship the CLI in a container or use static builds, upgrade now — there's no behavioral landmine here, and the WebP decoder alone justifies it for UGC workloads. If you link against libavcodec and friends, budget a real migration: rebuild, chase the deprecation warnings you've been ignoring since 8.0, and expect distro packages to lag — rolling releases within weeks, Ubuntu and Fedora at their next cycles, enterprise distros effectively never.

The honest read on 9.0: it's a consolidation release, and that's a compliment. FFmpeg has settled into a rhythm of two feature releases a year, with the majors carrying an architectural thesis. The 8.0 thesis was breadth. The 9.0 thesis is that Vulkan becomes the substrate — for codecs vendors won't bless with silicon, for filters that were CPU-bound, and increasingly for whatever GPU work a media pipeline needs. Nobody's ripping out NVENC or VideoToolbox tomorrow. But if you're designing a new pipeline today and wondering which acceleration path has momentum, the answer just got clearer.