VP9 vs H.264

What you are looking at

VP9 is Google's royalty-free answer to HEVC, finalised the same year (2013), and it is the codec most of YouTube has been delivered in for a decade. Against H.264 at 500 kbps it is a different class of picture: VMAF 80.73 against 64.54, with the blocking in H.264's shadows replaced by soft but coherent detail. At 1 Mbps the lead is 5.9 points, and to match H.264's quality there VP9 needs about 40% fewer bits.

Then the lead evaporates. At 2.5 Mbps the two codecs are within 0.2 VMAF of each other and x264 is fractionally ahead. That is not a fluke of this clip: libvpx's strength is holding a picture together when bits are scarce, and x264, after twenty years of tuning, is extremely good once it has enough bits to spend. For a service serving mobile viewers at low bitrates, VP9 is a clear win; for a high-bitrate archive it buys little, and AV1, which keeps its lead at every rate, is the codec that actually retired H.264.

The cost of the saving

The clips here took libvpx nine times as long to produce as the x264 ones (timings in the methodology), and that is with the "good" deadline rather than "best". VP9 also needs two passes to hit a bitrate target at all: one pass overshot by a third on this clip, which is why the methodology below runs it twice. Playback is the easy part: every current browser, Safari included, decodes VP9, and it is the only one of the three modern codecs that plays on every Android device ever made with Chrome on it. In a WebM container, which is where it lives; see containers vs codecs for why MP4 is the odd one out here.

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.