Encoder Implementations: x264, x265, libvpx, SVT-AV1, rav1e, libaom, vvenc

Published 2026-05-17 · 18 min read · By Nikolay Sapunov, CEO at Fora Soft

Why this matters

If you operate any service that delivers video — OTT, e-learning, video surveillance, conferencing, telemedicine — the software encoder you choose decides three numbers on your bill: cloud transcoding cost per hour, bandwidth cost per stream, and customer retention via startup time and buffering. Marketing pages talk about codecs in the abstract ("AV1 is 30% better than H.265"), but in production you do not ship a codec; you ship an encoder binary with a specific version, preset, and tuning. This article is the operator's reference for the seven software encoders you will actually deploy in 2026, what each one is good and bad at, and how to choose without re-running every benchmark yourself.

What an encoder is (and why one codec needs many)

A video codec is a written specification. The H.264 specification, formally ITU-T Rec. H.264 and ISO/IEC 14496-10, is a 800+ page document that defines how a bitstream must look so that any decoder in the world can play it back. The specification says almost nothing about how to create that bitstream — it leaves every encoder author free to make speed-versus-quality tradeoffs.

That freedom is why the same codec can have many encoders, and why those encoders produce dramatically different results. The piece of software that turns raw pixels into a compliant bitstream is the encoder implementation. Two encoders for the same codec target the same final container and decoder, but everything between input pixels and output bits — motion search range, mode decision logic, rate control, perceptual heuristics, assembly optimization — is the implementation author's call.

A useful analogy is sheet music. Every orchestra plays the same Beethoven score (the codec), but the recording you actually listen to depends on the conductor, the players, and the hall (the encoder). You do not buy a "Beethoven recording"; you buy a specific recording by a specific orchestra. Same with video: you do not deploy "H.264"; you deploy x264 version X with preset Y.

The 2026 line-up at a glance

Seven open-source software encoders carry most of the world's professional video in 2026. Each has a primary codec, a primary maintainer, a license, and a clear niche.

Three observations follow from the table. First, every major encoder is open source — proprietary encoders exist (Beamr, Visionular, NVIDIA cloud encoders) but the open-source set is what most teams ship. Second, the same codec can have multiple competing encoders (three for AV1 alone). Third, the licenses are split: BSD-style permissive licenses for everything except x264 and x265, which use GPL plus a commercial-license escape hatch.

Figure 1. Two decades of open-source video encoders. Each release corresponds to a codec generation, with AV1 producing three competing encoders in the same year.

The seven encoders in detail

x264 — the universal baseline

x264, started by Laurent Aimar in 2003 and shepherded since by VideoLAN, is the encoder against which every later encoder is measured. It produces compliant H.264 / AVC bitstreams and remains the highest-quality H.264 encoder publicly available. Its assembly-optimized hot paths run on x86, ARM NEON, ARM64, and ARM64EC; even after twenty-three years, low-level work continues — recent activity includes AArch64 NEON optimizations and ARM64EC support for Windows-on-ARM. The project is maintained at code.videolan.org/videolan/x264 and is dual-licensed: GPLv2 by default, with a commercial license available from x264 LLC for products that cannot comply with GPL.

x264's strengths are speed, predictability, and ten presets (ultrafast through placebo) that cover everything from 4K live ingest to archival-grade VOD. On a modern 16-core CPU, x264 at slow will encode 1080p at roughly 120 fps; at medium, easily 240 fps. That headroom is why every encoding farm on Earth still has x264 in production: H.264 still plays on every browser, every smart TV, every legacy STB, and x264 ships it with no royalty risk for the bitstream itself (decoder royalties are a separate matter).

Use x264 when compatibility outranks compression. Live streaming to a long tail of devices, surveillance, and any pipeline where the receiving device might be ten years old.

x265 — the HEVC workhorse

x265, started in 2013 by MulticoreWare, is the dominant open-source H.265 / HEVC encoder. It reached 4.1 in November 2024 and 4.2 on 19 April 2026, following a roadmap that included an Arm collaboration to optimize x265 on AWS Graviton4 cores. Like x264, it offers the same ten-preset ladder, the same dual licensing (GPLv2 plus commercial), and the same assembly-heavy hot paths.

The catch is speed. At comparable presets, x265 runs roughly 2–3× slower than x264 for ~50% bitrate savings at matched VMAF. That trade is worth it for premium VOD libraries, 4K and 8K archives, broadcast contribution links, and HDR catalogues — anywhere the storage and bandwidth savings amortize the higher CPU bill. It is not always worth it for live streaming at scale: a single 4K live channel can saturate a 32-core box at slow, whereas x264 needs eight cores.

libvpx — VP9 and the WebRTC default

libvpx is Google's reference encoder for VP8 and VP9, jointly maintained today by Google and the Alliance for Open Media. It is still alive — v1.16.0 landed in 2025–2026 with AVX-512, ARM SVE2, and Neon optimizations, plus per-frame PSNR support. Its current weight in production is two-fold. VP9 powered most of YouTube's catalogue throughout the 2016–2024 era, and the encoder is still live for older catalogue maintenance. VP8 remains the default real-time codec in WebRTC, which means every browser and every WebRTC SFU still depends on libvpx for VP8 encoding and decoding.

In the H.264-or-VP9 era, libvpx was the open alternative without the H.264 patent thicket. In the AV1 era, it has been overtaken by SVT-AV1 and libaom, but it survives because the deployed base of VP9 and VP8 streams is enormous.

SVT-AV1 — the production AV1 encoder

SVT-AV1 is the encoder that made AV1 a production-ready codec rather than a research curio. It started inside Intel as the Scalable Video Technology for AV1 in 2018, picked up a strategic partnership with Netflix in 2020, and was adopted by AOMedia in 2020 as the basis for future AV1 development. Version 4.0 shipped on 23 January 2026, with extended CRF range up to 70, finer quarter-step CRF granularity, ~5–15% RTC-preset speedups, Arm Neon and SVE2 optimizations, and the completion of porting all SVT-AV1-PSY perceptual features into the mainline tree under --tune vq (video) and --tune iq (AVIF).

What sets SVT-AV1 apart is parallelism. It scales horizontally across tens of CPU cores with frame-level and tile-level parallelism, which is why it can hit roughly the quality of libaom at cpu-used 6 in roughly half the wall-clock time. Preset 4–6 is the production sweet spot for VOD; preset 7–11 is used for low-latency real-time AV1. By Streaming Learning Center's analysis, SVT-AV1 covers ~95% of practical AV1 production work.

Use SVT-AV1 as your default AV1 encoder unless you have a specific reason to switch.

rav1e — the safety-first AV1 encoder

rav1e is the AV1 encoder written entirely in Rust, started by Xiph.Org and Mozilla in 2018 and currently led by xiph and AOMedia contributors. Version 0.8 landed in 2025 after a multi-year gap from 0.7 in late 2023. Its design priorities are memory safety, simple integration into Rust-native pipelines, and a tile-based architecture that maps cleanly to embedded multi-core SoCs.

In practice, rav1e is competitive with libaom at high speed settings but does not match SVT-AV1's preset-for-preset quality across the curve. It earns its place in three niches: any pipeline already written in Rust that wants AV1 without an FFI hop, hardened deployments where memory-safety guarantees matter (a class of CVEs in C/C++ video code is structurally impossible in safe Rust), and tightly tiled embedded encoders where the architectural match pays off.

libaom — the reference

libaom is the AV1 reference encoder, the encoder that defines compliant AV1 output for the spec, maintained by AOMedia primarily by Google engineers. It is the slowest AV1 encoder by a wide margin: at cpu-used 0, worst-case clips that x265 finishes in under 3 seconds can take libaom 445 seconds — a 100–2,500× slowdown. The 0–8 cpu-used ladder trades quality for speed, and even at cpu-used 8 it lags SVT-AV1's mid-presets on throughput.

It also produces the highest-quality AV1 bitstreams at the lowest cpu-used values. YouTube still uses libaom for AV1 encoding, where its compute cost amortizes across billions of views, and Netflix uses libaom for the top tier of premium VOD where every saved byte matters. Two valid use cases, no others.

vvenc — the cutting edge

vvenc is the Fraunhofer Versatile Video Encoder, the open-source H.266 / VVC encoder from the same lab that gave us H.264 and H.265 reference work. Version 1.14 landed on 22 January 2026, and the release tracks delivers 20× to 2,400× speedup over the VTM reference depending on which of its five presets you pick (faster, fast, medium, slow, slower). It scales to 32 CPU threads with frame-level parallelization.

VVC's compression efficiency on paper is the highest of any production-grade codec — Fraunhofer's own benchmarks show 50–55% bitrate reduction over H.264 and ~10–15% over AV1 at 4K. The catch in 2026 is hardware: VVC hardware decode is limited to a handful of recent flagship phones and a single Samsung-Synaptics 8K STB chipset. vvenc is therefore an early-adopter encoder: invest now if you want to be ready when decoders become mainstream in 2027–2028; ignore it if your audience cannot yet play H.266 at all.

Figure 2. The same pixels, three different cooks. CPU time and output bitrate at matched VMAF differ by an order of magnitude across the encoder choices.

Worked example: encoding the same clip seven times

To make the trade-offs concrete, here is the same 1080p 24 fps clip, 60 seconds long, encoded with each of the seven encoders at their respective "production VOD" preset on a 16-core CPU. The numbers below are representative ranges synthesised from Streaming Learning Center and Phoronix Test Suite benchmarks; treat them as orders of magnitude, not as a final benchmark.

Reading the table: a 60-second clip costs ~30 seconds with x264 and ~30–50 minutes with libaom, while the output is ~2.7× smaller for libaom. That 60× cost gap is exactly why "best" depends entirely on whether you are paying for CPU once and bandwidth a million times, or CPU once and bandwidth once.

The math you should run before picking is the same in every case:

total cost per stream = (encode CPU cost / number of views) + (bandwidth cost per view × number of views)

If number of views is in the millions (Netflix premium VOD, YouTube), the bandwidth term dominates and libaom or vvenc is worth the encode. If number of views is in the dozens (corporate training, e-learning, internal video), the encode term dominates and x264 is correct.

Speed and quality, visualised

A two-axis view makes the relationships easier to hold in one head. The horizontal axis is encode speed at a 1080p reference workload; the vertical axis is bitrate at matched VMAF.

Figure 3. The encoder landscape on two axes. The frontier moves down-and-right with each codec generation; the same codec produces multiple points depending on the encoder.

Three things become clear from the chart. First, each codec generation moves the frontier down-and-right — better compression at the same speed, or the same compression faster. Second, AV1's three encoders span a wide range: SVT-AV1 is roughly an order of magnitude faster than libaom at comparable settings. Third, vvenc is currently slow, but it has more headroom than any other encoder on the chart, because VVC tooling is at version 1.x and will be optimised heavily in 2026–2027.

Picking the right encoder — a decision tree

The choice question is rarely "which codec" — it is "which encoder of which codec for which workload." Three workload classes account for almost all decisions.

Figure 4. Decision tree for picking the right encoder in 2026. The dominant inputs are workload type, audience device base, and the number of views each encode amortizes across.

For real-time / sub-second-latency workloads (WebRTC conferencing, surveillance live, cloud gaming), x264 at superfast–veryfast is the safe default; VP8 via libvpx is the WebRTC interop fallback; SVT-AV1 preset 11 is the new contender now that real-time AV1 hardware exists.

For live streaming at scale (sports, news, e-learning live), x264 at fast–medium is still the default; x265 only if your contribution and distribution chain plays HEVC end-to-end.

For VOD at scale (OTT, training catalogues, podcasts), the order of operations is: ladder using x264 for compatibility, add an HEVC tier with x265 for HDR or 4K, add an AV1 tier with SVT-AV1 for the top of the bandwidth curve, and consider VVC via vvenc only if your audience demonstrably owns 2024+ flagship phones or recent OLED TVs.

Common mistakes when choosing an encoder

Pitfall: picking by codec, deploying by encoder. A "use AV1" decision made by a CTO with a Streaming Media headline in hand becomes "use libaom" in the engineer's hands, and the team discovers the encoder farm cost jumped 30× overnight. Always specify codec and encoder and preset in your design docs.

Pitfall: trusting old benchmarks. SVT-AV1 has shipped a major release every six months for five years. Any benchmark older than twelve months is misleading; quality and speed have moved measurably in the last two release cycles alone. Re-run on the encoder version you will actually ship.

Pitfall: ignoring licensing in CI/CD. x264 and x265 ship under GPLv2 by default. If your encoder runs inside a closed-source product you sell, you must either obtain a commercial license from x264 LLC / MulticoreWare or use BSD-licensed encoders (libvpx, SVT-AV1, rav1e, libaom, vvenc). Legal review of the encoder license is as important as the bitstream patent review.

Where Fora Soft fits in

Fora Soft has shipped video pipelines since 2005 in conferencing, video streaming, OTT and IPTV, video surveillance, e-learning, telemedicine, and AR/VR. Across those verticals we have deployed every encoder in this article in production: x264 for the universal baseline tier on conferencing and surveillance, x265 for premium OTT 4K HDR, libvpx for WebRTC VP8 fallback paths, SVT-AV1 for new AV1 OTT tiers, and vvenc in proof-of-concept work for clients planning H.266 rollouts in 2027. The recurring lesson from those projects: the encoder choice is rarely the bottleneck; the bitrate ladder, the rate-control mode (CRF vs capped-CRF vs CBR), and the per-title tuning move quality far more than swapping one encoder for another at the same preset.

What to read next

• Codec history: H.120 to AV2
• Codec comparison matrix
• FFmpeg cheat sheet for developers

Talk to a video engineer · See our case studies · Download

• Talk to a video engineer — book a 30-minute scoping call with the Fora Soft media team.
• See our case studies — read how we've shipped video pipelines for 239+ projects.
• Download — Encoder selection cheat sheet (PDF): one page, all seven encoders, with use case, preset, license, and pitfalls.

References

1. ITU-T Rec. H.264, Advanced video coding for generic audiovisual services. https://www.itu.int/rec/T-REC-H.264. Accessed 2026-05-17. Supports: codec specification authority.
2. VideoLAN, "x264, the best H.264/AVC encoder." http://www.videolan.org/developers/x264.html. Accessed 2026-05-17. Supports: x264 licensing, repository, and history.
3. VideoLAN x264 GitLab. https://code.videolan.org/videolan/x264. Accessed 2026-05-17. Supports: recent x264 development activity, ARM64EC support.
4. x265 documentation, Release Notes. https://x265.readthedocs.io/en/master/releasenotes.html. Accessed 2026-05-17. Supports: x265 4.1, 4.2 release dates and feature list.
5. MulticoreWare / Arm collaboration on x265 + AWS Graviton4. https://www.prnewswire.com/news-releases/multicoreware-collaborates-with-arm-to-optimize-and-advance-x265-video-encoding-on-aws-graviton4-302250055.html. Accessed 2026-05-17. Supports: x265 Arm optimisation context.
6. Google webm libvpx repository. https://chromium.googlesource.com/webm/libvpx. Accessed 2026-05-17. Supports: libvpx 1.16.0 release, ongoing maintenance.
7. AOMedia, "SVT-AV1 4.0 Boasts Major API Updates." http://aomedia.org/blog%20posts/SVT-AV1-4_0-Boasts-Major-API-Updates/. Accessed 2026-05-17. Supports: SVT-AV1 4.0 release date and feature list.
8. Phoronix, "SVT-AV1 4.0 Released With More Performance Optimizations." https://www.phoronix.com/news/SVT-AV1-4.0. Accessed 2026-05-17. Supports: SVT-AV1 4.0 performance claims.
9. xiph/rav1e GitHub repository. https://github.com/xiph/rav1e. Accessed 2026-05-17. Supports: rav1e design goals, current status.
10. Fraunhofer HHI vvenc project. https://github.com/fraunhoferhhi/vvenc. Accessed 2026-05-17. Supports: vvenc 1.14 release, preset list, threading model.
11. Fraunhofer HHI, "VVenC — the Fraunhofer Versatile Video Encoder." https://www.hhi.fraunhofer.de/en/departments/vca/technologies-and-solutions/h266-vvc/fraunhofer-versatile-video-encoder-vvenc.html. Accessed 2026-05-17. Supports: VVC compression efficiency vs H.264 / AV1.
12. Netflix Technology Blog, "AV1 — Now Powering 30% of Netflix Streaming." https://netflixtechblog.com/av1-now-powering-30-of-netflix-streaming-02f592242d80. Accessed 2026-05-17. Supports: Netflix AV1 production share.
13. Streaming Learning Center, "SVT-AV1 vs. LibAOM." https://streaminglearningcenter.com/encoding/svt-av1-vs-libaom.html. Accessed 2026-05-17. Supports: SVT-AV1 covers ~95% of production AV1 work.
14. Streaming Learning Center, "Choosing a Preset for SVT-AV1 and libaom-AV1." https://streaminglearningcenter.com/encoding/choosing-a-preset-for-svt-av1-and-libaom-av1.html. Accessed 2026-05-17. Supports: libaom and SVT-AV1 preset behaviour.
15. FFmpeg AV1 Encoding Wiki. https://trac.ffmpeg.org/wiki/Encode/AV1. Accessed 2026-05-17. Supports: AV1 encoder usage patterns.