x264 vs x265 vs AV1 & NVENC: 2026 Quality-Speed Test

Updated November 2026: SVT-AV1 4.3 speed gains, a new x264 vs x265 section (the CRF 23 vs 28 default, 10-bit and licensing), NVIDIA's AV1 UHQ claim for Blackwell, and three new FAQ answers.

x264 vs x265 vs AV1: the short answer

At equal quality, x265 (HEVC) needs about 38% less bitrate than x264 at the medium preset, and SVT-AV1 (AV1) needs about 46–58% less, depending on the preset. The more efficient encoder is usually slower, though: x265 medium encodes about 4× slower than x264 medium, and SVT-AV1 at preset 4 about 20× slower. Hardware AV1 encoders on recent GPUs (NVIDIA NVENC on RTX 40-series and newer, Intel Quick Sync on Arc) save about 38–40% at roughly 400–480 frames per second at 1080p, at their highest-quality presets. On our house benchmark (published June 2026; VMAF, 1080p, one reference machine), every x264 and x265 setting we tested is beaten on both speed and efficiency by at least one SVT-AV1 or GPU (NVENC HEVC or AV1) setting. x264 and x265 stay in production because of decode compatibility, not efficiency. Licensing is the other half of the decision: HEVC is licensed through patent pools, while the Alliance for Open Media offers AV1 royalty-free (Sisvel separately runs an AV1 patent pool, so have counsel check both). How many of your viewers can decode AV1 is covered in the state of AV1 in 2026.

In pairs: AV1 vs x265: SVT-AV1 preset 8 needs about 20% less bitrate than x265 medium at equal VMAF (51% vs 38% below x264 medium) and still encodes faster (30 vs 22 fps). x264 vs x265: x265 saves 38–46% at equal quality but costs 4–30× the encode time, and H.264 still plays on every device. SVT-AV1 vs NVENC AV1: software wins efficiency by 6 to 18 BD-rate points and hardware wins speed by 8× to 400×, going from SVT-AV1 preset 10 to preset 2.

Encoders at a glance. Figures come from Table 1 below: house benchmark published June 2026, one reference machine. Hardware speeds are at each vendor's highest-quality preset.

x264 vs x265: what is the difference?

x264 and x265 are free software encoders for two different codecs: x264 writes H.264 (AVC) and x265 writes H.265 (HEVC). On our 1080p benchmark, x265 reaches the same VMAF as x264 with about 38% less bitrate at the medium preset and 46% less at veryslow (both against x264 medium), but it encodes about 4× slower at medium (22 vs 95 fps) and its files need an HEVC decoder to play. Pick x264 when the file must play everywhere or encode fast. Pick x265 when bitrate or storage matters more than encode time and your devices decode HEVC but not AV1.

x264 vs x265 at a glance. Bitrate and speed come from Table 1 below (house benchmark published June 2026, one reference machine); CRF defaults come from the FFmpeg H.265 encoding guide.

Most home-made x264 vs x265 comparisons go wrong on the CRF numbers. CRF is a quality target on each encoder's own scale, not a shared one, so CRF 23 in x264 and CRF 23 in x265 are different qualities. FFmpeg's guide says x265's default CRF 28 "should visually correspond to libx264 video at CRF 23", at about half the file size. On our content the measured saving at equal VMAF is closer to 38% at medium. If CRF 28 really halves the file, it is landing at a somewhat lower quality than x264 CRF 23, not at the same one. Start from CRF 28, then lower it until VMAF matches your x264 encode on your own footage, instead of trusting the two defaults. The saving also shifts with content and resolution: the 38–46% here is for 1080p, and the method for rerunning it is in the free download below.

x265 is not the most efficient option either. At equal VMAF, SVT-AV1 preset 8 needs about 20% less bitrate than x265 medium and still encodes faster, which is why both x264 and x265 sit below the frontier in the next sections. They stay in production ladders for decode reach, not efficiency.

Why this matters

Picking a codec is the famous decision, but the encoder and preset are what set your bandwidth bill and your compute bill. This article is for the streaming engineer, encoding lead, or technical product owner who has chosen AV1 or HEVC on paper and now has to decide which AV1 encoder to run, at which speed, for a live channel versus a VOD archive. We measure the quality-versus-speed trade-off at equal quality, on the content our products actually ship, with the encoding time shown next to the saving. A claim like "we use AV1" tells you nothing until you say which encoder and preset produced the file. The goal is a number you can plan a pipeline around and a method you can rerun on your own footage.

The codec is the ceiling; the encoder is what you reach

People often blur three things together, and the whole article depends on keeping them apart. A codec (short for coder-decoder) is the standard, such as H.264, HEVC or AV1, that defines what a compressed bitstream is allowed to look like and how a decoder must read it. An encoder is a specific program that produces such a bitstream: x264 produces H.264, x265 produces HEVC, SVT-AV1 produces AV1, and the dedicated silicon in your GPU (NVIDIA's NVENC, Intel's Quick Sync, AMD's AMF) produces any of them in hardware. A preset is the speed setting you run that encoder at, which controls how hard it is allowed to work on each frame.

The codec fixes the ceiling. The AV1 standard allows more efficient ways to describe a frame than H.264 does, and no encoder can beat its own codec's ceiling. Two encoders for the same codec can still land far apart, because reaching the ceiling means searching an enormous space of coding choices, and how much of that space an encoder explores depends on how much time it gets. The headline codec savings in our codec comparison (HEVC about 44% smaller than H.264, AV1 about 55%) were measured with mature software encoders given real effort. Run the same codec in a fixed-function hardware block tuned for speed and you give some of that saving back. This article is about that give-back: the gap between what a codec can do and what a particular encoder does do at a particular speed.

This article covers measurement, not mechanics. It measures how the encoders perform and what they cost in time. It does not explain how x264, x265, or SVT-AV1 work internally, or what NVENC's fixed-function block does on the die. For the implementation internals (partitioning, motion search, rate-distortion optimization, the hardware pipeline), see the Video Encoding section's encoder implementations, hardware acceleration (NVENC, VPU, ASIC), and the encoder benchmark. We link to the cause side and stay on the measurement side.

Two numbers, not one: efficiency and speed

A codec comparison needs one number: the bitrate saving at equal quality. An encoder comparison needs two. An encoder that saves bandwidth but cannot keep up with your throughput is useless, and so is one that runs fast but wastes bandwidth. Every configuration in this article is therefore scored on two axes at once.

The first axis is efficiency, expressed as BD-rate against a single shared anchor. BD-rate (Bjøntegaard Delta rate) is the average percentage difference in bitrate between two encodes at matched quality, across a range of quality (Bjøntegaard, VCEG-M33, 2001). We use x264 at its medium preset as the anchor, since it is the universal baseline that runs everywhere, and report every other configuration as a saving against it. A BD-rate of −40% means that configuration reaches the same VMAF as x264 medium at 40% less bitrate; +5% means it needs 5% more. The sign convention is a constant source of confusion, so to repeat: negative is a saving, and BD-rate is a saving, not a quality score. Quality here is VMAF on the default v0.6.1 model (a 1080p living-room television), mean-pooled, with each encode decoded back to the source resolution before scoring. This is the same specification as the rest of Block 7's methodology. The full reading of VMAF (model, pooling, confidence interval) is VMAF explained.

The second axis is speed, expressed as encoding throughput in frames per second at 1080p on one stated reference machine. Frames per second is the right unit because it maps directly onto the only question that matters in production: can this encoder keep up with my content volume, and what does the compute cost? A figure of 30 fps means a 30-frames-per-second clip encodes in real time; 3 fps means it takes ten times as long as the clip runs; 480 fps means it is done almost before it started. Speed is only comparable on identical hardware, so every fps number here comes from the same machine, recorded in the dataset's provenance.

Holding both axes to the same anchor and the same machine is what makes the comparison fair. The most common way an encoder comparison misleads is by mixing the axes: quoting a slow software encoder's efficiency against a fast hardware encoder's speed, as if you could have both at once. You cannot, and the plane below shows the actual choice.

The preset is a quality-speed dial

Before comparing encoders, it helps to understand the dial inside each one. Every modern software encoder exposes a preset, a named bundle of settings that trades encoding speed for compression efficiency. In x264 and x265 the presets run, from fastest to slowest, ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, and placebo, with medium as the default (x265 documentation, accessed 2026). The preset does not change the quality target you ask for; it changes how hard the encoder works to hit it. A slower preset may test more ways to encode each block and keep the best one.

Walking x265 from fast to slow turns on the expensive tools: the number of reference frames the encoder may look back to rises from 1 to 5, the motion search widens from a small diamond pattern to a star, sub-pixel refinement deepens, rate-distortion analysis goes from a cheap approximation to a full evaluation, and rectangular and asymmetric block partitions switch on (x265 documentation, accessed 2026). Each of these finds a few more bits to save, and each costs time. SVT-AV1, the production AV1 encoder, uses a numeric dial instead of names, but the idea is the same. For file-based VOD encoding it has offered presets from 0 (slowest, most efficient) to 10 (fastest) since version 3.0 (February 2025), and version 3.1 (July 2025) added presets 11 and 12 for the real-time --rtc mode (SVT-AV1 release notes, 2025). As a rough speed map, SVT-AV1 preset 8 lands near x265 medium and preset 6 near x265 slow (SVT-AV1 project guidance; community benchmarks, 2026).

SVT-AV1 or libaom? libaom (aomenc) is the Alliance for Open Media's reference AV1 encoder, and the "aom AV1" in many comparisons. In Jan Ozer's 17-clip test with 2022 versions, SVT-AV1 matched libaom's quality at 1.36% lower bitrate and encoded much faster at comparable effort, while libaom's slowest preset took 187 times longer than its fastest (Streaming Learning Center, December 2022). Both write the same AV1 codec, whose ceiling sits far above H.264's. SVT-AV1 gets there in far less time, which is why it is the AV1 encoder on our plane. For how the two are built differently, see how x264, x265, SVT-AV1 and libaom work inside.

Measuring at the right point changes the decision. If you compare presets at equal bitrate, slower presets look pointless: one careful analysis found x265's slow preset delivering only about 0.87% higher VMAF than medium while more than doubling the encoding time, and ultrafast still reaching 98% of veryslow's score (Ozer, OTTVerse, 2021). Read that way, paying double for under a point of VMAF looks like a bad deal. But equal bitrate is the wrong frame for streaming. Measure the same two presets at equal quality (the BD-rate question) and the slow preset cuts the top-rung bitrate by about 23% and the whole ladder by about 26% (Ozer, OTTVerse, 2021). The extra effort did not buy a higher score at the same size. It bought the same score at a smaller size, and that smaller size is the bandwidth you pay for. A preset's value is invisible at equal bitrate and obvious at equal quality, and that lesson about measuring at matched quality runs through this whole section.

The headline: the quality-speed plane

Put every configuration on one plot, with efficiency up the side and speed along the bottom, and the choice turns into a frontier instead of a list of encoders.

Figure 1. The quality-speed plane. Each point is one encoder at one preset: horizontal is encoding speed (fps at 1080p, log scale), vertical is bitrate saving versus x264 medium (higher is more efficient). The connected line is the Pareto frontier, the set of configurations that no other configuration beats on both axes at once. Software AV1 (SVT-AV1) owns the efficient end, the GPU encoders own the fast end, and everything else sits below the line.

The measured numbers behind the plot, sorted from fastest to slowest:

Table 1. Illustrative house results (benchmark published June 2026), anchored on x264 medium (VMAF default model, log-domain BD-rate over the overlapping range, single reference machine). The frontier is the set of configurations that nothing else beats on both speed and efficiency. The downloadable dataset and tool reproduce every figure in this table.

Figure 2. The efficiency axis alone, as bitrate saving versus x264 medium. Software AV1 at a slow preset saves the most (about 58%); hardware AV1 saves about 40%; hardware H.264 barely beats the anchor. The same AV1 codec spans an 18-point range from SVT-AV1 preset 2 to NVENC AV1. That spread is the implementation gap.

Reading the frontier: x264 and x265 are dominated

The plot's bluntest result is that every x264 and every x265 configuration sits below the frontier. Each one is dominated: some other configuration is always both faster and more efficient. x265 slow (−44% at 9 fps) is beaten by SVT-AV1 preset 6 (−55% at 11 fps), which is more efficient and faster. x265 medium (−38% at 22 fps) is beaten by SVT-AV1 preset 8 (−51% at 30 fps). x264 medium, the anchor, is beaten on speed by every hardware encoder and on efficiency by every configuration except x264 veryfast and NVENC H.264.

This does not mean x264 and x265 are obsolete. The plot leaves out one axis: decode support. A frontier of efficiency and speed ignores whether the viewer's device can play the file at all. H.264 decodes on essentially everything ever built, HEVC on most modern hardware, and AV1 on a large, fast-growing, but not universal base. So x264 stays in the ladder as the compatibility floor (the rung you serve to the old smart TV and the corporate laptop), and HEVC fills the middle where AV1 decode is still missing. They earn their place on reach, not on quality per bit per second. The device-support and adoption picture is the Video Encoding section's state of AV1 in 2026; this article supplies the measured cost of choosing them anyway.

Read right to left, the frontier is a clean menu. At the far right, where raw throughput matters above all, NVENC H.264 is the fastest configuration on the board but barely beats the anchor on efficiency. One step left, the GPU AV1 and HEVC encoders give a large efficiency gain at almost the same speed. Further left is SVT-AV1's preset ladder, which trades speed for efficiency one preset at a time down to preset 2, the most efficient configuration measured and also the slowest. Every point on that frontier is a valid choice; the right one depends entirely on how much time you can spend per frame.

Software versus hardware: the real trade

The deepest split on the plane is between software and hardware, and it follows from how each is built. A software encoder is a program running on a general-purpose CPU. It can spend as long as you allow searching for the cheapest way to encode a block, which is why its slow presets reach the efficiency frontier. A hardware encoder is a fixed-function block etched into the GPU: dedicated silicon that runs a deliberately bounded search at enormous speed and very low latency, encoding hundreds of frames per second with almost no CPU load. The trade is structural. The hardware block cannot try every tool a slow software preset tries, so at equal quality it spends more bitrate.

NVIDIA's own measurements put numbers on it. On the Ada Lovelace generation, the AV1 hardware encoder reaches about 40% bitrate savings over the same chip's H.264 encoder at 1080p60, at a throughput around 500 fps, roughly nine times faster than the x264 software encoder it was compared against (NVIDIA, 2023). That is a strong result, and it is close to our −40% for NVENC AV1, although ours is measured against x264 medium and NVIDIA's against its own H.264 block. Note the baselines, though: the hardware H.264 encoder and a fast software encoder. Against SVT-AV1 given real time, the same NVENC AV1 trails by about 15 points (−40% versus −55% at preset 6), because the software encoder explores choices the fixed block cannot. Both facts hold at the same time: hardware AV1 crushes software H.264, and software AV1 beats hardware AV1.

The hardware-AV1 field has three players, and they are close. In our measurements NVIDIA's NVENC AV1 is marginally ahead on efficiency, Intel's Quick Sync AV1 (on Arc-class GPUs) just behind, and AMD's AMF AV1 a step further back. The spread is a few BD-rate points, consistent with independent testing that has generally rated the Intel and NVIDIA AV1 blocks at the front and AMD's behind (community testing, 2023–2025). AMD and NVIDIA both shipped newer encoder generations in 2025; the section on encoder releases below covers what they change. The differences between hardware vendors are small next to the gap between any of them and a slow software preset. If your constraint is throughput (live channels, real-time transcoding, encoding farms measured in streams per watt), that gap is the price of admission, and a 40% saving at 480 fps is an excellent deal. Hardware AV1 is also the natural choice for live and user-generated content, where there is no time for a slow preset and no pristine reference to measure against.

The figure to remember is the implementation gap: on our content, the same AV1 codec ranges from −40% (NVENC, tuned for speed) to −58% (SVT-AV1 preset 2, tuned for efficiency). Those 18 BD-rate points are decided entirely by which encoder and preset produced the file, not by the codec. Anyone who says "we encode in AV1" has told you almost nothing about the bitrate until they say with what.

Figure 5. The structural trade in one view. A software encoder spends time to reach the efficiency frontier; a hardware block accepts a fixed efficiency cost in exchange for enormous speed and low latency. Each is the right tool for a different job.

The encoding-time cost, shown

Efficiency is paid for in compute, and the bill is steep enough to change decisions. Take a single ten-minute clip at 1080p30 (600 seconds × 30 frames per second = 18,000 frames) and divide the frame count by each throughput in Table 1 to get the wall-clock encode time:

NVENC AV1   (480 fps):  18,000 / 480  =     37.5 s   (~0.6 min)
x264 medium  (95 fps):  18,000 /  95  =    189 s     (~3.2 min)
SVT-AV1 p6   (11 fps):  18,000 /  11  =  1,636 s     (~27 min)
SVT-AV1 p4  (4.5 fps):  18,000 / 4.5  =  4,000 s     (~67 min)
x265 veryslow (3 fps):  18,000 /   3  =  6,000 s     (~100 min)

The hardware AV1 encoder finishes the ten-minute clip in well under a minute. SVT-AV1 at preset 4 takes over an hour for the same clip to gain an extra 17 BD-rate points (−57% versus NVENC's −40%). That is about 107× the compute for about 28% less bitrate than NVENC AV1. Whether the trade is worth it is an economics question rather than a quality one, and the answer flips with scale and viewership.

Figure 3. The compute bill for one ten-minute 1080p30 clip, by configuration (log time axis). The hardware encoder finishes in seconds; the slowest software preset shown takes about 100 minutes. Encoding cost is paid once per asset; bandwidth saving is harvested on every view.

The deciding fact is that encoding cost is paid once, and bandwidth saving is harvested forever. A title streamed a million times pays its slow-preset encode bill once and banks the 17-point saving on every view, which makes SVT-AV1 at a slow preset an easy win. A clip watched a few hundred times never recovers the compute, so the fast hardware path is the right call. For a large catalog the slow-preset bill becomes real money: a thousand hours of content at preset 4's 4.5 fps is on the order of nine months of single-stream encoding (parallelized across a farm in practice), against a couple of days on hardware AV1. The break-even depends on views per asset and on the ratio of your compute cost to your bandwidth cost. The same logic sets a quality target and budget and drives the per-title and per-shot decision to spend more compute where it pays.

What changed in 2025–2026: encoder releases to account for

The plane comes from one benchmark run, and encoders keep changing. The releases below matter when you rerun it on your own hardware. None of them reorders the frontier, but each shifts a point:

• SVT-AV1 4.0 (January 2026) through 4.3 (November 2026). Version 4.0 reports a 10–25% speedup for presets M7 down to M0 in VOD (random-access) mode with fast-decode 1 and 2, and completed the port of the SVT-AV1-PSY perceptual features into --tune vq. Version 4.2 adds the VMAF-targeted tune and a new CBR rate controller for low-delay (RTC) encoding (SVT-AV1 release notes, 2026). Version 4.3 (November 1, 2026) reports a 5–8% cycle-efficiency gain at similar quality across all presets and a 10–11% run-time cut in multi-threaded mode, plus low-delay tile parallelism and retuned presets for real-time (RTC) encoding (SVT-AV1 4.3.0 release notes, November 2026). On a current build, the software AV1 points move right, toward more speed at the same efficiency.
• x265 4.2 (April 19, 2026) adds experimental threaded motion estimation: up to 1.5× faster at 1080p on many-core machines, and little or no gain on high-clock machines with few cores (x265 release notes, 2026). x265 moves right, not up; even at 1.5× it stays below SVT-AV1 presets 8 and 10, and remains off the frontier. As of November 2026, 4.2 is still the current x265 release.
• NVIDIA Blackwell NVENC (GeForce RTX 50 series, 2025) adds 4:2:2 encoding and improved motion estimation and rate-distortion optimization (NVIDIA, February 2025). An independent HEVC test measured the RTX 5090 at a 5.59% bitrate saving over the previous-generation RTX 4080 Super at equal VMAF (Codec Calamity, February 2025). Video Codec SDK 13.1 (July 2026) adds hierarchical B-frames for AV1, up to 31 of them (NVIDIA, July 2026). The 40% in Table 1 matches NVIDIA's Ada-generation figure; expect Blackwell a few points better, still well short of a slow SVT-AV1 preset. NVIDIA also says the ultra-high-quality (UHQ) tuning that SDK 13.0 extended to AV1 makes Blackwell AV1 encoding "comparable to software AV1 encoding with ~3X throughput" (NVIDIA Video Codec SDK page, accessed November 2026). It does not name the software preset behind that comparison, and UHQ is a slower tuning than the p7 high-quality setting in Table 1, so measure it before you move a hardware point up the plane. SDK 13.1 is still the current release.
• AMD RDNA 4 (Radeon RX 9070 series, March 2025) added B-frames to the AV1 encoder; AMD claims 25% better low-latency H.264 quality and 11% better HEVC than the previous generation (TechSpot, March 2025). On RDNA 4 cards, expect the AMD gap in Table 1 to be narrower; measure before relying on it.
• AV1 is mainstream in VOD. Netflix reported in December 2025 that AV1 carries about 30% of its on-demand viewing and uses about a third less bandwidth than its AVC and HEVC sessions (Netflix Technology Blog, December 2025). AV2 1.0 was released by the Alliance for Open Media in June 2026, but no production hardware encodes or decodes it yet, so it does not belong on a 2026 production plane (AOMedia, June 2026).

The measurement side changed too: Netflix open-sourced VMAF v1 in June 2026 (Netflix Technology Blog, June 2026). Every number on this page uses the v0.6.1 model, and scores from the two models are not interchangeable, so compare BD-rates only within one model version.

Which encoder for which job

The plane reduces to a short decision rule once you know two things about the job: how much time you have per frame, and which devices must play the result.

Figure 4. The decision rule. It does not rank encoders: the right encoder depends on whether encoding must run in real time, how heavily the asset is viewed, and what the target devices can decode. Each leaf names a configuration from Table 1.

For live and real-time work (broadcast, conferencing, cloud gaming, anything where the encode must keep pace with the source), use hardware, and hardware AV1 (NVENC, Quick Sync) where the devices decode it. Live needs exactly what it offers: a 40% saving at hundreds of frames per second, plus the low latency live cannot do without. For high-volume VOD, a catalog streamed far more often than it is encoded, software AV1 at a slow preset (SVT-AV1 preset 4–6) gives the best efficiency, because the one-time compute is amortized across millions of views. For archival or mezzanine masters where bitrate matters more than time, the slowest practical SVT-AV1 preset is worth its hours. Underneath all of it, x264 stays in the ladder as the compatibility floor, and HEVC covers devices that decode it but not AV1. Most production services run several of these at once and serve each device the best stream it can play; the Video Encoding section's encoder implementations article covers the codec side.

Table 2. The decision rule as a table. The job's constraint picks the encoder. There is no single "best", and each row is the right answer for its own case.

A common mistake: the unfair preset, and gaming the metric

The classic bad encoder comparison is not faked. It is unfair in a way the reader cannot see, and it usually takes one of three forms. The first is mismatched effort: a slow, high-effort preset of the favored encoder is compared against a fast preset of the rival, and the efficiency gap is reported as if the codec or the implementation caused it. The fix is the discipline behind this whole block: keep the comparison apples-to-apples or, as we do here, place both encoders on a quality-speed plane where the effort difference shows up as a position on the speed axis instead of staying hidden.

The second is comparing speed across machines. Frames per second means something only on identical hardware: a software encoder on a 64-core server and the same encoder on a laptop are different data points. Every fps figure here comes from one machine, recorded in the provenance, and yours should too.

The third is subtle and specific to measurement: tuning the encoder for the metric you then report. x265 offers --tune psnr and --tune ssim, which switch off the encoder's perceptual optimizations so that the PSNR or SSIM number comes out higher. The documentation states that by default x265 "tunes for highest perceived visual quality," and that you should only switch to a metric tune if you intend to benchmark against that metric (x265 documentation, accessed 2026). If you benchmark an encoder while it is tuned to flatter your scoring metric, you measure the tuning rather than the quality a viewer would see. We score on VMAF with the encoders in their default perceptual tuning, and we call out this trap because it is everywhere. It took a new form in 2026: SVT-AV1 4.2 added a VMAF-targeted tune, which its developers say targets about a 15% VMAF BD-rate improvement with minimal PSNR loss (SVT-AV1 release notes, July 2026; not measured here). That tune is a fair choice when VMAF is your delivery target, but a VMAF comparison of SVT-AV1 in that tune against x265 in its default perceptual tune measures the tune, not the encoder. Every objective metric is a proxy validated against human opinion, and optimizing the encoder for the proxy instead of the viewer is the oldest way to win a benchmark and lose the audience. When the metric and a careful viewing disagree, the viewing wins.

Encoder comparison FAQ

Is AV1 better than x265?

Yes on compression: at equal VMAF, SVT-AV1 saves 46–58% bitrate against x264 medium and x265 saves 38–46%. Head to head, SVT-AV1 preset 8 needs about 20% less bitrate than x265 medium and also encodes faster on our machine (30 vs 22 fps). x265 still wins on reach, because HEVC decodes on many devices that cannot decode AV1.

Is x265 better than x264?

x265 matches x264's quality at about 38% less bitrate at the medium preset (46% at veryslow, both against x264 medium), but at medium it encodes about 4× slower, and it needs HEVC decode support. x264 is faster and plays on essentially every device, so it stays as the compatibility rung.

What are x264 and x265?

x264 and x265 are free, open-source software encoders: x264 writes H.264 (AVC) video and x265 writes H.265 (HEVC) video. They are programs, not codecs. The codec is the standard, and the encoder is the implementation that produces it.

SVT-AV1 or NVENC AV1: which is better?

SVT-AV1 at presets 4–6 saves 55–57% against x264 medium. NVENC AV1 saves about 40% but runs about 40–110× faster (480 fps vs 4.5–11 fps at 1080p). Use software AV1 for heavily viewed VOD and hardware AV1 for live and real-time encoding.

NVENC vs AV1: what is the difference, and how does NVENC AV1 compare with NVENC H.264?

NVENC is NVIDIA's hardware encoder block; AV1 is a codec that NVENC can write on RTX 40-series and newer GPUs. NVIDIA measured about 40% bitrate saving for NVENC AV1 over its own H.264 encoder at 1080p60 (NVIDIA, 2023). On our content, NVENC H.264 needs 5% more bitrate than x264 medium and NVENC AV1 needs 40% less.

Is aom AV1 (libaom) better than x264?

On compression, yes: libaom writes AV1, and in our codec comparison AV1 needs about 55% less bitrate than H.264 at equal quality when the encoder is given time. libaom and SVT-AV1 reach similar quality, but libaom's file-based mode is much slower (its separate real-time mode is used mainly in WebRTC), which makes SVT-AV1 the practical choice for VOD.

Which SVT-AV1 preset should I use?

Preset 8 encodes slightly faster than x265 medium (30 vs 22 fps) at a 51% saving against x264 medium. Preset 6 (55%, 11 fps) suits most VOD, and presets 4 and below pay off only for heavily viewed titles and archives. Since version 3.0 the VOD scale has run from 0 to 10; version 3.1 added presets 11 and 12 for the --rtc real-time mode.

AOM AV1 vs SVT-AV1: which AV1 encoder is better?

For file-based encoding, SVT-AV1. In Jan Ozer's 17-clip test with 2022 versions it matched libaom's quality at 1.36% lower bitrate, a gap within measurement noise, and encoded much faster at comparable effort (Streaming Learning Center, December 2022). Speed, not quality, is what separates them. libaom (aomenc) is still the Alliance for Open Media's reference encoder, and its real-time mode is the one used mainly in WebRTC.

Is NVENC better than x265?

On efficiency, no: on our plane NVENC HEVC saves 30% against x264 medium, while x265 medium saves 38%. On speed, NVENC HEVC is about 23× faster (500 vs 22 fps). If your devices decode AV1, NVENC AV1 (40% saving at 480 fps) matches x265 medium on efficiency, within measurement noise, at about 22× the speed. These hardware figures use the p7 high-quality preset, not UHQ tuning.

What x265 CRF matches x264 CRF 23?

FFmpeg's H.265 guide says x265's default CRF 28 should look about the same as x264 at CRF 23. Use it only as a starting point: on our content x265 saves about 38% at equal VMAF rather than half, so CRF 28 tends to land slightly below x264 CRF 23 in quality. Lower the x265 CRF until VMAF matches before you set a ladder.

Should I use SVT-AV1 for a movie archive if x265 is not available?

Yes, if your playback devices decode AV1. SVT-AV1 at presets 2–4 saved 57–58% in our test, more than any x265 preset (46% at veryslow). Keep a high-bitrate or lossless master if you expect to re-encode later, since every generation of lossy encoding adds loss.

What watts-per-channel benchmark should you use to compare encoding hardware?

First fix a quality target (for example a VMAF score per ladder rung). Then measure how many channels each box encodes in real time at that target, and divide the wall-socket power under that load by the channel count. Report BD-rate against a shared anchor alongside it, because channels per watt at a lower quality cannot be compared with channels per watt at a higher one.

Where Fora Soft fits in

Fora Soft has built video streaming, OTT, conferencing, e-learning, telemedicine, and surveillance software since 2005, and in each of these the encoder choice sets both the bandwidth bill and the compute bill. A conferencing product encoding live needs the hardware path. An OTT catalog streamed millions of times wants the slow software preset, which is the trade our OTT and Internet TV platform developers set up when they build a VOD encoding pipeline. A surveillance system recording a hundred channels has a throughput-per-watt constraint that decides the encoder for it. We measure the trade the way this article describes: at equal quality, on the content categories our products handle, with the encoding time shown next to the saving. We do it this way because a pipeline decision defended with "we use AV1" falls apart as soon as someone asks which encoder, at which preset, on what hardware. The benchmark here is our own, published with its dataset so it can be checked and cited. Our video transcoding software developers pick the encoder and preset for your content and hardware, and our streaming development team builds the ladder and the encoding farm around it.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook that walks the whole video stack, from a single pixel to a running production system, across more than 9,000 pages - enough to design and build one yourself. Volume 1, Video Encoding, is the one that sits directly under this article: it works through the partitioning, motion search and rate-distortion decisions a slow preset is buying you, what the fixed-function block on a GPU does instead, and the PSNR, SSIM and VMAF machinery every BD-rate figure here rests on. Volume 3 turns the saving into money - ABR ladders, CDNs and the delivery bill that decides whether an hour of compute per clip is worth it - and Volume 6 covers the learned encoding work now creeping into the same decisions. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. G. Bjøntegaard. "Calculation of Average PSNR Differences Between RD-Curves." ITU-T SG16 Q.6 VCEG, document VCEG-M33, Austin, TX, April 2001. Tier 1 (metric author's defining document). The BD-rate method and sign convention (the average bitrate difference at equal quality), used for every efficiency figure in this article. https://www.itu.int/wftp3/av-arch/video-site/0104_Aus/VCEG-M33.doc
2. Netflix. "VMAF Models" (models.md), VMAF Development Kit documentation. Accessed 2026-06-25. Tier 1 (metric author documentation). The default v0.6.1 model targets a 1080p living-room television; the model is part of the measurement. Basis for the metric specification used to score every encode. https://github.com/Netflix/vmaf/tree/master/model
3. Recommendation ITU-R BT.500-15 (2023). "Methodologies for the subjective assessment of the quality of television pictures." International Telecommunication Union, 2023. Tier 1 (official standard). The subjective ground truth every objective metric is validated against; when a metric and a careful viewing disagree, the viewing wins. Basis for the measurement-honest framing and the metric-tuning caveat. https://www.itu.int/rec/R-REC-BT.500
4. Recommendation ITU-T P.1401 (07/2020). "Methods, metrics and procedures for statistical evaluation, qualification and comparison of objective quality prediction models." ITU, 2020. Tier 1 (official standard). The procedure for comparing objective scores honestly, including the rule that a difference smaller than the uncertainty is not a difference. Basis for not over-reading small BD-rate gaps. https://www.itu.int/rec/T-REC-P.1401
5. MulticoreWare. "Preset Options" and "Command Line Options," x265 documentation. Accessed 2026-06-25. Tier 3 (first-party tooling). The ten x265 presets ultrafast to placebo with medium as default, the exact parameters each preset toggles (references, motion search, RD analysis, partitions), and the --tune psnr/--tune ssim behavior that disables perceptual optimization for benchmarking. Basis for the preset-dial section and the metric-tuning pitfall. https://x265.readthedocs.io/en/stable/presets.html
6. Alliance for Open Media / SVT-AV1 project. "SVT-AV1 encoder user guide and release notes (4.0.0)." Accessed 2026-06-25. Tier 3 (first-party tooling). SVT-AV1's numeric preset dial (0 slowest to 10 fastest for VOD since 3.0; 11–12 in --rtc mode since 3.1), the 4.0.0 release (2026-01-23), and the rough speed mapping to x265 presets. Basis for the SVT-AV1 preset behavior and version pinning. https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/CommonQuestions.md
7. P. Muthana, S. Mishra, A. Patait. "Improving Video Quality and Performance with AV1 and NVIDIA Ada Lovelace Architecture." NVIDIA Technical Blog, January 2023. Tier 4 (hardware vendor engineering). NVENC AV1 on Ada reaches ~40% bitrate savings over NVENC H.264 at 1080p60 and ~1.5–2 dB higher PSNR at equal bitrate, at ~500 fps (~9× the x264 baseline tested); presets p1–p7 with quality/latency tunings. Basis for the NVENC AV1 efficiency and speed figures. https://developer.nvidia.com/blog/improving-video-quality-and-performance-with-av1-and-nvidia-ada-lovelace-architecture/
8. J. Ozer. "Choosing an x265 Preset: An ROI Analysis." OTTVerse / Streaming Learning Center, October 2021. Tier 6 (expert practitioner). At equal bitrate, x265 slow gives ~0.87% higher VMAF than medium while more than doubling encode time, and ultrafast reaches ~98% of veryslow's score; reframed at equal quality, slow cuts the top rung ~23% and the ladder ~26%. Basis for the equal-bitrate-versus-equal-quality reframing. https://ottverse.com/choosing-an-x265-preset-an-roi-analysis/
9. FFmpeg. "Hardware acceleration introduction; libvmaf, psnr, ssim filters; H.264/HEVC/AV1 encoding guides." FFmpeg documentation, accessed 2026-06-25. Tier 3 (first-party tooling). The command-line interface to x264, x265, SVT-AV1, and the NVENC/QSV/AMF hardware encoders, and the full-reference scaling that quality measurement requires. Basis for the encoder invocation and resolution-handling notes. https://ffmpeg.org/ffmpeg-filters.html
10. Tom's Hardware; PCWorld; G. Rosato. "Hardware AV1 encoder comparisons: Intel Arc QSV vs NVIDIA NVENC vs AMD AMF." 2023–2025. Tier 6 (expert practitioner / press testing). Independent comparisons generally placing the Intel and NVIDIA AV1 hardware blocks at the front and AMD's behind, with small spreads between vendors. Basis for the hardware-vendor ordering. https://www.tomshardware.com/news/intel-arc-av1-encoder-dominates-nvenc
11. C. Herglotz, H. Och, A. Meyer, et al. "The Bjøntegaard Bible: Why Your Way of Comparing Video Codecs May Be Wrong." IEEE, 2023; arXiv:2304.12852. Tier 5 (peer-reviewed). Shape-preserving interpolation over cubic overshoot, log-domain integration, and overlap-only computation: the BD-rate practice the bundled tool implements. https://arxiv.org/pdf/2304.12852
12. Alliance for Open Media / SVT-AV1 project. "SVT-AV1 release notes, v3.0.0 (2025-02-20) to v4.2.0 (2026-07-14)." Accessed 2026-10-11. Tier 3 (first-party tooling). VOD preset scale capped at M10 since 3.0, real-time presets 11–12 in --rtc mode (3.1.0), 10–25% speedup for M7–M0 (4.0.0), VMAF-targeted tune aiming at ~15% VMAF BD-rate (4.2.0). https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases
13. Alliance for Open Media / SVT-AV1 project. "SVT-AV1 v4.3.0 release notes." Released 2026-11-01, accessed 2026-11-10. Tier 3 (first-party tooling). ~5–8% cycle-efficiency improvement at similar quality across all presets, ~10–11% run-time reduction in multi-threaded mode, low-delay tile parallelism and RTC preset retuning. https://github.com/AOMediaCodec/SVT-AV1/releases/tag/v4.3.0
14. NVIDIA. "NVIDIA Video Codec SDK" product and download page. Accessed 2026-11-10. Tier 4 (hardware vendor). SDK 13.1 current; SDK 13.0 extends UHQ mode to AV1, which NVIDIA says makes Blackwell AV1 encoding comparable to software AV1 at ~3× throughput. https://developer.nvidia.com/video-codec-sdk/download
15. FFmpeg. "H.265/HEVC Video Encoding Guide," FFmpeg wiki. Accessed 2026-11-10. Tier 3 (first-party tooling). libx265 default CRF 28, said to visually correspond to libx264 at CRF 23. https://trac.ffmpeg.org/wiki/Encode/H.265
16. MulticoreWare. "x265 Release Notes, version 4.2." Release date April 19, 2026. Tier 3 (first-party tooling). Experimental threaded motion estimation, up to 1.5× at 1080p on many-core machines. https://x265.readthedocs.io/en/4.2/releasenotes.html
17. NVIDIA. "NVIDIA Video Codec SDK 13.0 Powered by NVIDIA Blackwell." NVIDIA Technical Blog, February 24, 2025; and "NVIDIA Video Codec SDK 13.1: Zero-Copy Transcode, AV1 B-Frames and Frame-Accurate Seek," July 31, 2026. Tier 4 (hardware vendor engineering). Blackwell NVENC 4:2:2, ME/RDO improvements; AV1 hierarchical B-frames up to 31. https://developer.nvidia.com/blog/nvidia-video-codec-sdk-13-0-powered-by-nvidia-blackwell/
18. C. Griffith. "Nvidia RTX 5090 Video Encoding: First Look." Codec Calamity, February 14, 2025. Tier 6 (expert practitioner). HEVC NVENC p7 UHQ, RTX 5090 vs RTX 4080 Super, BD-rate −5.59% at equal VMAF. https://codecalamity.com/nvidia-rtx-5090-video-encoding-first-look/
19. TechSpot. "AMD RDNA 4 GPUs bring major encoding and ray tracing improvements." March 2, 2025. Tier 6 (press). AMD's claims for RDNA 4: AV1 B-frames, +25% low-latency H.264 and +11% HEVC encode quality. https://www.techspot.com/news/106986-amd-rdna-4-gpus-bring-major-encoding-ray.html
20. J. Ozer. "SVT-AV1 vs. LibAOM." Streaming Learning Center, December 13, 2022. Tier 6 (expert practitioner). 17 clips: SVT-AV1 matched libaom quality at 1.36% lower bitrate; libaom preset time range 187×, not live-capable. https://streaminglearningcenter.com/?p=17343
21. Netflix Technology Blog. "AV1: Now Powering 30% of Netflix Streaming." December 2025. Tier 2 (operator engineering). AV1 ~30% of on-demand viewing, about a third less bandwidth than AVC and HEVC sessions. https://netflixtechblog.com/av1-now-powering-30-of-netflix-streaming-02f592242d80
22. Netflix Technology Blog. "VMAF v1: Good Is Not Good Enough." June 2026. Tier 1 (metric author). VMAF v1 open-sourced; scores are not interchangeable with the v0.6.1 model used on this page. https://netflixtechblog.com/vmaf-v1-good-is-not-good-enough-60d7e4244ea8
23. Alliance for Open Media. "Alliance for Open Media Releases AV2 Codec." Press release, June 9, 2026. Tier 1 (standards body). AV2 1.0 released; software decoder in progress, no hardware timeline. https://aomedia.org/press%20releases/Alliance-for-Open-Media-Releases-AV2-Codec/