AV1 vs H.265

What you are looking at

These are the two codecs a new streaming service actually chooses between in 2026; H.264 is the fallback, not the candidate. On this clip AV1 leads HEVC by 12.2 VMAF points at 500 kbps, 6.6 at 1 Mbps and 3.0 at 2.5 Mbps. Read the other way: to match HEVC's quality at 2.5 Mbps (VMAF 93.16), SVT-AV1 needs about 65% fewer bits, and AV1's 500 kbps encode already outscores HEVC's 1 Mbps one. Where HEVC over H.264 was an evolutionary step, this is the bigger one.

Look at the dark grass and the sky gradients at 500 kbps: HEVC bands and blocks there, AV1 keeps them smooth. AV1's film-grain synthesis, larger block sizes and better in-loop filtering are aimed at exactly the low-bitrate regime where a starved encoder falls apart. At 2.5 Mbps both are past the point where VMAF differences are easy to see, which is the honest reading of the right-hand end of the chart.

What the licence buys, and what it costs

HEVC's advantage is a decade of silicon: every phone, television and laptop GPU made since about 2016 decodes it, and most encode it in hardware. AV1 playback is widespread in current browsers, but Safari on Apple devices requires supported hardware such as A17 Pro or M3; keep a fallback for older devices. Hardware encoding is still limited to the newest GPUs. In software the gap is smaller than its reputation: SVT-AV1 at preset 6 took about a fifth longer than x265 at medium on these clips (timings in the methodology), though the slower AV1 presets that squeeze out the last few percent cost many times that. The trade is bits against patent fees: AV1 saves bandwidth for free and forever; HEVC has the wider hardware base today and bills you for the right to ship it. The encoder benchmark will show which of the two your own machine has silicon for.

Methodology

The source is a 10-second, 1080p30 excerpt of Big Buck Bunny (© Blender Foundation, CC-BY 3.0), scaled once to a near-lossless 720p reference. Each codec then encodes that reference at 500, 1000 and 2500 kbps, all 4:2:0, using FFmpeg 8.1: x264 and x265 at preset medium with a 1.5× rate cap, libvpx-vp9 in two passes at the "good" deadline with the same cap, SVT-AV1 at preset 6 in plain ABR (it refuses a cap alongside a target). VP9 gets two passes because one pass overshoots its target by a third on this clip, which would hand it more bytes than the others; with two it lands within 3%. VMAF is computed against the same reference, and the chart plots each encode's actual achieved bitrate rather than the nominal target.

Encoding time, since every page above mentions it: on the machine that produced these clips, the 1 Mbps encode of the 10-second 720p reference took x264 3.5 s, x265 5.4 s, SVT-AV1 6.6 s, and libvpx-vp9 32 s for its two passes. One run each, one clip, one CPU; the ratios are the point, not the seconds.

Fair-fight caveats: one short animated clip is not a corpus; animation compresses differently than camera footage (and tends to flatter modern codecs). Encoder presets matter enormously, and the source itself is a high-bitrate H.264 master, not a pristine original. Treat this page as an honest demonstration of the shape of the gap, not a benchmark to cite in a codec war. The pipeline is in the site repo; one command regenerates every number here.

If a side will not play

The player asks your browser whether it can decode each codec before it loads anything, and says so above the frame when the answer is no. HEVC is the usual culprit: Chrome, Edge and Firefox only decode it through a licensed decoder in the operating system or GPU, so the same page works on one laptop and not the next. The scores and the chart do not depend on playback, so they are right either way. The browser report lists what yours can do.