FFmpeg 8.1 landed this week with the kind of reception a foundational infrastructure project earns: 368 upvotes on Hacker News and a thread full of practitioners registering that something they depend on daily has shipped again. The changelog covers continued AV1 ecosystem improvements, maturing VVC support, hardware acceleration updates across NVIDIA, Intel, and AMD backends, and the usual accumulation of filter graph and container fixes.
The individual items are worth understanding, but they are more legible in context. FFmpeg has spent twenty-five years maintaining neutrality in one of the longer-running disputes in software: the contest between royalty-bearing video codecs and open alternatives. What 8.1 supports, and how it supports it, reflects where that contest currently stands.
The Problem H.264 Created for Open Source
H.264 (AVC) became the dominant web video codec through the mid-2000s on technical merit. The spec was excellent, and hardware support landed broadly across devices. The licensing terms were managed by the MPEG-LA patent pool, which kept things workable for large commercial players while creating genuine friction for open source projects and browser vendors who could not simply absorb per-unit royalties at web scale.
Mozilla’s refusal to ship H.264 in Firefox was not purely principled. It was a practical consequence of what royalty-bearing formats mean for software distributed under open source licenses. The web platform’s commitment to open standards sat in direct tension with the codec that everyone actually needed. For years the answer was Theora, a technically inferior codec that had the important property of being free to use.
FFmpeg implemented all of it, H.264 via libx264 and later hardware paths, Theora via libtheora, and everything in between. Its role was never to take sides. The library surface is a registry of what exists, and keeping that registry current is what the project has always done.
Google’s Bet and VP9
Google acquired On2 Technologies in 2010 and immediately open-sourced the VP8 codec as the foundation of the WebM project. The strategic logic was transparent: Google needed a royalty-free codec at H.264 quality for YouTube and Chrome, and buying On2 was cheaper than waiting for standards processes. VP8 was not technically superior to H.264, but it was free to use in all the ways H.264 was not.
The MPEG-LA spent time investigating whether VP8 was free of its patents. Google resolved that uncertainty by negotiating a cross-license in 2013. VP9 followed as Google’s internal successor, providing meaningful compression gains over VP8 and becoming the delivery codec for YouTube’s high-resolution content well before AV1 was ready.
FFmpeg tracked both. VP8 and VP9 encode and decode support landed and has been maintained continuously. The libvpx library handles software encoding; hardware VP9 decode paths via NVDEC, VAAPI, and VideoToolbox followed as hardware support arrived.
AV1: When the Industry Coordinated
The formation of the Alliance for Open Media in 2015 marked a shift in approach. Rather than one company betting on its own codec, a coalition that included Amazon, Apple, ARM, Cisco, Meta, Google, Intel, Microsoft, Mozilla, Netflix, and Nvidia committed to building a shared open alternative. The resulting codec, AV1, delivered roughly 30% better compression than VP9 at comparable quality and around 50% better than H.264.
FFmpeg now supports three distinct AV1 software encoders, each targeting a different point in the speed-quality tradeoff:
- libaom: the Alliance’s reference encoder. Highest quality ceiling, slowest by a wide margin. Suitable for archival and research encoding where turnaround time is not a constraint.
- libsvtav1: Intel’s Scalable Video Technology encoder, running roughly 4-8x faster than libaom at preset 6 with comparable quality, scaling well across CPU cores. Production AV1 pipelines default to this.
- librav1e: written in Rust by Xiph, targeting a different region of the speed-quality space and maintained independently of the other two.
# SVT-AV1 for VOD: CRF 35 is roughly equivalent to H.264 CRF 23 visually
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 35 -preset 6 -g 240 output.mp4On the decode side, dav1d is the result of a collaboration between VideoLAN and the FFmpeg project. It is consistently faster than libaom’s decoder with strong SIMD optimization for x86 and ARM, and it has been the default software AV1 decode path in FFmpeg for several years. Hardware AV1 decode via NVDEC on RTX 30/40 series and Intel Arc takes the decode story further.
# GPU-resident pipeline: NVDEC decode, CUDA scale, NVENC encode
ffmpeg -hwaccel nvdec -hwaccel_output_format cuda \
-i av1_input.mp4 \
-vf "scale_cuda=1280:720" \
-c:v h264_nvenc output.mp4The VVC Question and What It Tells You About Licensing
VVC (Versatile Video Coding, H.266) ratified in 2020 and achieves 30-50% better compression than HEVC at comparable quality, which is a meaningful gain at streaming bitrates. Two things are keeping it from fast adoption: encoding complexity and licensing history.
On encoding complexity, software VVC encoding runs well below real-time for 1080p on current hardware using the reference encoder. The practical open-source path is VVenC from Fraunhofer HHI, which reaches usable speeds at faster presets for VOD workflows where per-bit savings justify longer encode times.
On licensing, the HEVC situation is instructive. H.265 launched with multiple competing patent pools (MPEG-LA, HEVC Advance, Velos) that created genuine uncertainty about total licensing cost and slowed adoption relative to what the codec’s technical merit would have warranted. With VVC, the MPEG-LA and others are attempting more coordinated licensing, but the memory of the HEVC fragmentation means the major streaming platforms are cautious. Netflix has built its infrastructure around AV1. YouTube is on AV1. The incentive to adopt a new royalty-bearing codec when AV1 is shipping and improving is low.
FFmpeg has been building out VVC support regardless, which is consistent with its role. The VVdeC decoder from Fraunhofer integrates into FFmpeg for VVC decode. VVenC encoder integration has improved through the 8.x series. For broadcast pipelines that do adopt VVC, FFmpeg will be ready to handle the content. Whether those pipelines materialize at scale is a question FFmpeg does not need to answer.
Hardware Acceleration as the Third Dimension
Codec format is one dimension of the landscape. Hardware acceleration is another, and it compounds the maintenance surface considerably. FFmpeg’s hardware paths include NVENC/NVDEC for NVIDIA, QSV for Intel (which migrated from MediaSDK to oneVPL across the 8.x series), AMF for AMD, VAAPI on Linux, VideoToolbox on macOS, and Vulkan as a vendor-neutral compute path.
Each backend has its own API versioning and its own bugs around specific pixel format combinations. A release like 8.1 will contain fixes for issues that only surface under production conditions: an NVENC firmware version that drops frames under sustained load, a VAAPI driver that misreports capability flags, a VideoToolbox behavior change in a recent macOS update. Keeping all of these functional simultaneously, across codec and hardware combinations, is a significant fraction of the ongoing engineering work.
The Vulkan filter path is worth noting separately. Unlike the vendor-specific backends, Vulkan provides hardware-agnostic GPU compute that runs on any Vulkan-capable device. Scaling, format conversion, deinterlacing, and denoising filters all have Vulkan implementations in FFmpeg. For containerized transcoding pipelines running on heterogeneous hardware, Vulkan filters improve portability without requiring vendor-specific builds.
What the Accumulation Represents
The filter graph layer adds its own complexity. HDR content introduces HDR10 with static SEI metadata, HDR10+ with per-frame dynamic metadata, HLG with a different transfer function, and Dolby Vision with proprietary profile levels. Accurate HDR-to-SDR conversion for distribution requires precise tonemapping, which the zscale filter backed by libzimg handles with the color accuracy that broadcast pipelines require:
ffmpeg -i hdr_input.mp4 \
-vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,\
tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" \
-c:v libx264 -crf 18 sdr_output.mp4These improvements accumulate across point releases in ways that matter for production pipelines processing catalog content at scale, even if no single fix is a headline item.
FFmpeg dates to 2000, started by Fabrice Bellard when H.261 and MPEG-1 were the relevant codecs. It has tracked every significant format shift since then: the rise of H.264, the VP8 and VP9 era, AV1’s emergence as the open standard that finally had broad industry backing, and now VVC’s uncertain approach. The project maintains a mailing list patch workflow rather than pull requests, an unusual choice in 2026, and it has sustained one of the most technically demanding open source projects in existence using it.
The 8.1 release is continuation of all that. Three AV1 encoders maintained and improved. Hardware codec paths updated as vendor APIs shift. VVC decoder and encoder support maturing. The project does not need the format war to resolve to do its job; it needs only to track the landscape as it exists. That is what 8.1 is.