FFmpeg 9.0 was released on August 3, and the entry most people will notice first is animated WebP, which now has both a decoder and a demuxer in the tree. Under that headline sits a longer list: an APV Vulkan hardware acceleration path, a v360_vulkan filter, a transpose_cuda filter, four separate additions on AMD's AMF, ProRes RAW acceleration through VideoToolbox, and an ONNX Runtime backend for the DNN filters with GPU execution provider support. Three things were removed. If you build FFmpeg yourself or pin flags in an encoding pipeline, the removals are the part of this release that can actually cost you an afternoon.
The short answer
FFmpeg 9.0 shipped on August 3, 2026. Additions include an animated WebP decoder and demuxer, an APV Vulkan hardware acceleration path, a v360_vulkan filter, a transpose_cuda filter, ProRes RAW acceleration via VideoToolbox, LCEVC track muxing in MP4, SMPTE 2094-50 metadata passthrough, a bitstream filter to split multi layer Dolby Vision HEVC, HE-AAC 960 decoding for DAB+, and an ONNX Runtime DNN backend with GPU execution provider support. AMD AMF gains extended HDR in the colour converter plus frame rate conversion and video quality enhancer filters. Removed: CELT decoding, OGG CELT parsing, and deprecated NVENC options along with pre 11.1 SDK support.
There is a reliable rhythm to reading an FFmpeg release. You skim the additions, you feel briefly optimistic, and then you get to the removals and go and grep your own scripts. FFmpeg 9.0, out on August 3, is a good example of why that order is the wrong way round.
Start with what was removed
Three entries, and they are not equally dangerous.
CELT decoding support is gone, and OGG CELT parsing with it. The changelog notes explicitly that this does not affect Opus, which is the point worth internalising. Opus embeds CELT as one of its internal layers and is entirely unaffected. What disappears is the ability to decode standalone CELT, a codec that was superseded by Opus in 2012 and survives mostly in archives. If that is you, you know it already.
The NVENC removal is the one to check. Deprecated NVENC options have been dropped, along with support for NVIDIA Video Codec SDK versions before 11.1. Two different populations get hit by that. If you build FFmpeg against an old SDK, the build stops. If you have encoding commands carrying NVENC flags that have been printing deprecation warnings for a few releases, and warnings are easy to stop seeing, those commands now fail outright.
Neither is hard to fix. Both are much easier to fix on a Tuesday afternoon than at two in the morning when a transcode queue has stopped.
Animated WebP, read only
The headline addition is a pair of entries: an animated WebP decoder and an animated WebP demuxer. Together they mean FFmpeg can now ingest an animated WebP directly and turn it into frames, into an MP4, into anything else it writes.
What is not there is a muxer or an encoder. Writing animated WebP still goes through libwebp tooling. That asymmetry is worth stating plainly because the changelog line is easy to read optimistically, and because ingest was genuinely the harder half of the problem. Animated WebP has been widespread on the web for years while being irritating to get into a pipeline, and it now behaves like an ordinary input.
Vulkan keeps growing, and so does AMF
Vulkan gets two entries: an APV hardware acceleration path and a v360_vulkan filter for 360 degree video projection. Vulkan acceleration is attractive precisely because it is not tied to one vendor's runtime, though in practice how well it works still comes down to your driver.
AMD's AMF gets four separate entries, which is the largest single vendor investment in this release. The existing vf_vpp_amf colour converter has its HDR capabilities extended. Two new filters arrive: vf_frc_amf for frame rate conversion and vf_vqe_amf for video quality enhancement. And AMF gains hardware memory mapping support, which is the sort of plumbing change that shows up as fewer copies between host and device rather than as a new feature.
NVIDIA's addition is a transpose_cuda filter, which does rotation and flipping on the GPU. Apple platforms get ProRes RAW hardware acceleration through VideoToolbox.
The quieter entries that solve real problems
Three additions in this release exist because someone hit a specific wall.
LCEVC track muxing support in the MP4 muxer matters if you work with the enhancement layer codec, since carrying LCEVC has meant working around the muxer rather than through it. SMPTE 2094-50 metadata support and passthrough is dynamic HDR metadata, and passthrough is the operative word: it means the metadata survives a remux instead of being silently dropped, which is a category of bug that costs people a great deal of time.
The bitstream filter to split multi layer Dolby Vision HEVC is the most specific of the three and the most welcome if you need it. Multi layer Dolby Vision carries a base layer and an enhancement layer in one stream, and separating them without a purpose built tool has been unpleasant.
Rounding out the list, HE-AAC 960 decoding covers a DAB+ digital radio variant, there is a Playdate video encoder and muxer for Panic's handheld console, and Phoronix reports additional AVX-512 optimisations for pixel format conversion.
What we would do
Upgrade the workstation, stage the pipeline.
On a machine where you are cutting, converting and experimenting, 9.0 is straightforwardly better and the removals are unlikely to touch you. On anything running unattended, spend twenty minutes first: take your real command lines, run them against a 9.0 build on representative inputs, diff the output, and read the logs for anything that used to warn. That is the whole of the risk in this release, and it is entirely findable in advance.
Sources and further reading
- FFmpeg 9.0 released with more Vulkan acceleration, animated WebP and more AMD AMF, Phoronix, August 3, 2026
- Official FFmpeg changelog, version 9.0 section
- FFmpeg download and release page
- FFmpeg release history on endoflife.date
Frequently asked questions
What actually breaks when I move to FFmpeg 9.0?
Three removals, and only one of them is likely to reach you. CELT decoding support is gone, along with OGG CELT parsing. This does not affect Opus, which embeds CELT internally and continues to work exactly as before, so unless you are decoding raw CELT streams or CELT in an Ogg container, which is a rare and largely historical format, nothing changes. The removal that has teeth is on NVENC: deprecated options are gone and support for SDK versions before 11.1 has been dropped. If you have an encoding pipeline carrying old NVENC flags copied from a tutorial years ago, those invocations will now fail rather than warn, and if you are building against an old NVIDIA Video Codec SDK the build itself will stop. Both are fixable in minutes, but only if you find out before your pipeline does.
Does animated WebP support mean I can create them now?
No, and the changelog is precise about this. FFmpeg 9.0 adds an animated WebP decoder and an animated WebP demuxer. Both are read paths. You can now take an animated WebP and turn it into frames, into a video file, or into any other format FFmpeg writes, using nothing but FFmpeg. What is not in this release is an animated WebP muxer or encoder, so writing an animated WebP still means going through libwebp tooling such as img2webp or webpmux. That still leaves the release genuinely useful, because animated WebP has been common on the web for years while remaining awkward to ingest, and a demuxer means it now behaves like any other input rather than a special case you handle outside the pipeline.
What is the ONNX Runtime DNN backend for?
FFmpeg has carried a DNN subsystem for some time, used by filters that run a neural network over frames, such as super resolution, denoising and the classification and detection filters. That subsystem needs a backend to execute the model, and the existing options have been narrow enough that many people simply did the inference outside FFmpeg. Version 9.0 adds an ONNX Runtime backend with GPU execution provider support, which matters for two reasons: ONNX is the format most training frameworks can already export to, and the GPU execution provider means the model runs on the accelerator rather than on the CPU. In practice this makes it more realistic to keep a model inference step inside a single FFmpeg invocation instead of splitting the pipeline into decode, infer and re-encode stages.
How much of the new hardware acceleration applies to my machine?
Look at the vendor prefix on each entry, because this release is split three ways. AMD gets the most: the vf_vpp_amf colour converter picks up extended HDR capabilities, and there are three new filters, vf_frc_amf for frame rate conversion and vf_vqe_amf for video quality enhancement, plus AMF hardware memory mapping support. NVIDIA gets a transpose_cuda filter and the NVENC cleanup mentioned above. Apple silicon and macOS get a ProRes RAW VideoToolbox hardware acceleration path. The APV hardware acceleration is Vulkan based, which means it is vendor neutral in principle and depends on your driver in practice. The v360_vulkan filter, for 360 degree video projection, is the same story.
Should I upgrade straight away?
On a workstation, yes, once your distribution or your build ships it. On a production encoding pipeline, we would stage it. The reason is not that 9.0 looks fragile, it is that a major FFmpeg version is exactly where option removals live, and encoding pipelines accumulate flags nobody remembers adding. The cheap version of due diligence is to run your existing command lines against a 9.0 build on a handful of representative inputs, compare the output, and check the logs for anything that used to print a deprecation warning. If you are on a distribution package rather than your own build, you will get 9.0 whenever your distribution decides, and the same check is worth doing before that happens rather than after.