AV1 vs H.264

What you are looking at

The widest gap on the site. At 500 kbps, a bitrate that leaves H.264 blocking in every shadow, AV1 produces a picture most viewers would accept; at 2.5 Mbps AV1 is still 5.0 VMAF ahead, and to match H.264's quality there it needs about 72% fewer bits. The two codecs between them, H.265 and VP9, each have their own page and sit on the chart below so the whole generation can be read at once.

The price of the saving is encoding effort: SVT-AV1 at preset 6 is a sensible production setting and took about twice as long as x264 at medium on these clips (timings in the methodology), slower presets cost far more, and hardware AV1 encoders only exist on the newest GPUs. 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 devices without AV1 support.

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.