H.265 vs H.264

What you are looking at

HEVC was designed to deliver H.264's quality at half the bitrate, and on broadcast-style content with slow encoder settings it can get close. Measured here, with both encoders at preset medium, the saving is real but more modest: to match H.264's quality at 1 Mbps (VMAF 81.26), x265 needs about 23% fewer bits; to match it at 2.5 Mbps (VMAF 91.15), about 16%. The gap is widest where bits are scarcest: at 500 kbps H.264 is visibly struggling (VMAF 64.54, blocking in every dark area) while HEVC holds the picture together at 76.72. By 2.5 Mbps the two are 2.0 points apart and you will need the slider to tell them apart.

Why less than the headline 50%? Partly the content: a clean animated clip leaves less for HEVC's larger transform blocks and better motion prediction to exploit than noisy camera footage does. Partly the resolution: HEVC's tools pay off more at 1080p and 4K than at 720p. And partly honesty about presets: encoder comparisons that claim the full 50% usually run x265 at its slowest settings against x264 at sensible ones. The storage calculator uses 40% as a planning estimate, separate from this one-clip 720p experiment. The measured curve does not cover the H.264 quality target at 500 kbps, and these results do not establish savings at higher resolutions.

The catch is not quality, it is reach

Every HEVC file carries a licensing question, and the practical consequence is that Chrome, Edge and Firefox only play it when the operating system or GPU brings its own licensed decoder. Safari and every iPhone play it natively. So HEVC is the safe upgrade for an Apple-heavy audience or for files that never leave a media server, and a gamble on the open web, which is the gap AV1 was built to fill. If the player above says your browser cannot show the right-hand side, you have just met that gap in person.

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.