AV1 vs VP9 vs HEVC vs H.264
Compare four video codecs measured on one file, with encode times, output sizes and cost. SVT-AV1 beat VP9 on every axis, which settles a common argument.
Abdelrahman Essawy 4 MIN READCodec comparisons usually arrive as a table of claims with no commands attached. We ran four codecs on one file and recorded what came back.
Short version. SVT-AV1 is the surprise: it beat VP9 on size, on encode time and on cost simultaneously, which means there is no remaining axis on which VP9 wins this comparison. If you are still reaching for VP9 out of habit, this is the number to look at.
| Variant | Encode | Size | Cost |
|---|---|---|---|
| H.264 (libx264) | 898 ms fastest | 433.0 KB | $0.0024 |
| HEVC (libx265) | 1674 ms | 233.0 KB | $0.0032 |
| VP9 (libvpx-vp9) | 5347 ms | 346.6 KB | $0.0071 |
| AV1 (libsvtav1) | 1111 ms | 224.4 KB | $0.0026 |
| AV1 (libaom-av1) | 4769 ms | 146.5 KB | $0.0062 |
VP9 is dominated
Set the two side by side:
| VP9 | SVT-AV1 | |
|---|---|---|
| Output | 346.6 KB | 224.4 KB |
| Encode | 5,347 ms | 1,111 ms |
| Cost | $0.0071 | $0.0026 |
SVT-AV1 produced a file 35% smaller in 4.8x less encode time for 63% less money. Not a tradeoff, a straight win on every axis measured.
This matters because VP9’s historical argument was practical rather than technical: it was the royalty-free codec with real browser support while AV1 encoders were too slow to use. SVT-AV1 removes that argument. On this clip it encodes faster than VP9 by a wide margin.
The AV1 encoder matters more than the codec
The two AV1 rows are the same codec and they are barely comparable:
- libsvtav1: 224.4 KB in 1,111 ms
- libaom-av1: 146.5 KB in 4,769 ms
libaom produced a file 35% smaller than SVT-AV1 and 66% smaller than H.264, and took 4.3x longer to do it. Both are AV1. A benchmark that says “AV1” without naming the encoder and the speed setting has not told you anything actionable.
That also cuts against reading too much into any single AV1 number, including ours. -preset 8 on SVT-AV1 and -cpu-used 8 on libaom are both fast settings. Slower settings on either will shrink the files further and cost more time.
H.264 is still the right default, and that is fine
H.264 was the fastest of the four at 898 ms and the cheapest at $0.0024. It also produced the largest file at 433 KB. That is the entire modern case for it: it decodes on everything ever made, it encodes quickly, and you pay for that in bytes.
HEVC at 233 KB in 1,674 ms is the unglamorous middle option, roughly half the size of H.264 for under twice the encode time. Its problem has never been the numbers, it is the licensing and the patchy browser support.
About the CRF values
Each codec ran at its own conventional quality setting: CRF 23 for x264, 28 for x265, 32 for VP9, 35 for both AV1 encoders. This is deliberate and it is the part most codec comparisons get wrong.
CRF is not a shared scale. CRF 23 does not mean the same thing to x264 and to libaom, so running every codec at an identical number produces a table that looks rigorous and compares nothing. The values above are the ones each codec’s own documentation and community treat as a sensible default, which is the closest available thing to a fair fight without a full quality-metric run.
What that means for reading the table: the sizes are comparable as “what you get at each codec’s normal setting”, not as “at matched quality”. A proper matched-quality comparison needs VMAF or SSIM scoring on every output, which is a longer piece of work and a different post.
Where this stops
One 5-second 1280x720 clip, audio stripped. Short clips flatter fast encoders, because a longer source gives slow encoders more opportunity to amortise their analysis. Content matters too: grain and motion change codec rankings more than almost anything else.
The whole sweep, twenty-one encodes across three benchmarks, cost $0.073. The commands are in the table and each is one API call, so running this on your own footage is an afternoon at most.
This is one of several codec comparisons on the same source. The matched-size version and the rest are in Video codec comparison, measured.
Frequently asked questions
Is AV1 better than VP9?
On this clip SVT-AV1 beat VP9 on every axis at once: 35% smaller, 4.8x faster to encode and 63% cheaper. VP9's historical argument was that AV1 encoders were too slow, and SVT-AV1 removes it.
Which AV1 encoder should I use?
SVT-AV1 for anything with a time budget and libaom-av1 when size matters most. We measured libaom producing a 35% smaller file than SVT-AV1 while taking 4.3x longer.
Should I still use H.264?
For maximum compatibility, yes. It was the fastest and cheapest of the four and decodes on essentially everything, and you pay for that in bytes.
Why not compare all codecs at the same CRF?
Because CRF is not a shared scale. CRF 23 means something different to x264 and to libaom, so an identical number compares nothing. Each codec here ran at its own conventional setting.