# AV1 vs VP9 vs HEVC vs H.264

Canonical: https://rendobar.com/blog/av1-vp9-hevc-h264-measured/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-08-20

---

## Key takeaways

- SVT-AV1 beat VP9 on all three axes at once: 35% smaller, 4.8x faster to encode, and 63% cheaper. There is no axis on which VP9 won.
- libaom-av1 produced the smallest file by a distance, 146 KB against H.264's 433 KB, but took 4,769 ms against 898 ms.
- HEVC landed between them: 233 KB in 1,674 ms, roughly half of H.264's size for under twice the encode time.
- The AV1 encoder you pick matters more than the codec choice. SVT-AV1 and libaom-av1 differ by 4.3x in encode time and 53% in output size.
- Each codec ran at its own conventional CRF, because comparing codecs at an identical CRF number compares nothing.

Codec 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.

## 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](/blog/video-codec-comparison/).