# AV1 vs VP9 vs HEVC vs H.264 at default settings

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

---

## Key takeaways

- Name the encoder, not just the codec. libaom and SVT-AV1 both write AV1 and behaved like different products on size and encode time.
- VP9 lost to SVT-AV1 on size, time and cost, but at libvpx's slow defaults. Set -row-mt 1 and a -cpu-used value before you judge the format.
- A table of codecs at their usual CRF ranks speed and cost. It cannot rank quality, because each encoder's CRF scale is its own.
- H.264 wrote the most bytes and still earns its place as the fallback, because it plays on everything.

At each encoder's usual CRF on one 720p clip, SVT-AV1 beat VP9 on size, encode
time and cost, and libaom-av1 wrote the smallest file of the five. Those settings
do not produce equal quality, so this page ranks bytes, speed and cost at
conventional settings and says nothing about which codec looks better. For
quality, [AV1 vs H.264 at a matched file size](/blog/av1-vmaf-matched-size/)
held every codec to 150 KB and scored it with VMAF, and AV1 came out about 20
points ahead of H.264.

Each row is one API job on the same 5-second 1280x720 clip with audio stripped.
The clip, the FFmpeg build and the timing rules are on
[how we benchmark](/blog/how-we-benchmark/).

The commands, exactly as they ran:

```bash
ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libx264 -crf 23 -preset medium -an -t 5 out.mp4
ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libx265 -crf 28 -preset medium -an -t 5 out.mp4
ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libvpx-vp9 -crf 32 -b:v 0 -an -t 5 out.webm
ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libsvtav1 -crf 35 -preset 8 -an -t 5 out.mp4
ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libaom-av1 -crf 35 -cpu-used 8 -an -t 5 out.mkv
```

Each codec ran at the CRF its own documentation and community treat as a
sensible default: 23 for x264, 28 for x265, 32 for VP9 and 35 for both AV1
encoders. CRF is not a shared scale, so the same number across codecs would look
rigorous and compare nothing. Read the table as what you get at each codec's
normal setting.

## VP9 lost at libvpx defaults

SVT-AV1 at preset 8 wrote 35% fewer bytes than VP9, encoded 4.8x faster and cost
63% less. Look at the VP9 command before reading that as a verdict on the format.
It sets no `-row-mt 1`, no `-cpu-used` and no `-deadline`, so libvpx ran at its
own defaults, which are slow, against an AV1 encoder at a fast preset. I did not
rerun it with those flags, so the fair claim is narrow. At libvpx defaults, VP9
lost to SVT-AV1 on all three axes. With row threading and a faster `-cpu-used`
the time gap would narrow, by an amount this sweep did not measure.

VP9 keeps one argument the table cannot show. Hardware VP9 decoders shipped in
phones and TVs years before AV1 decoders did, and that matters more than encode
time if your audience holds older devices.

## The AV1 encoder mattered as much as the codec

The two AV1 rows are the same format at the same CRF number. libaom wrote a file
35% smaller than SVT-AV1 and took 4.3x as long. **A benchmark that says "AV1"
without naming the encoder and its speed setting has not told you which of those
you get.** The same CRF number is not guaranteed to mean the same quality across
two AV1 encoders either, so even that 35% is a size, not a quality result.

Against x264, libaom's 150,038 bytes were 66% fewer than H.264's 443,351. That
66% is the size gap at conventional settings, not a saving at matched quality.
Both AV1 rows also used fast settings (`-preset 8` and `-cpu-used 8`), and slower
settings on either would shrink the files further at more encode time. A
5-second clip also flatters fast encoders, because a slow encoder has less
footage over which to spread its analysis.

## H.264 and HEVC

x264 wrote the largest file of the five. HEVC at CRF 28 wrote a little over half
of H.264's bytes. HEVC's encode took longer on this run, but by less than 2x from
a single sample, which is inside the spread identical work shows between runs,
and H.264 and SVT-AV1 encoded in about the same time. None of those timing gaps
is a finding.

HEVC's problem has never been its numbers. It is the patent licensing, and
browser playback that still depends on the device having a hardware decoder.

## Running it yourself

The sweep was five API calls with only the command changing between them, and
the five together billed about two cents. The SVT-AV1 row runs as written:

const rb = createClient({ apiKey: process.env.RENDOBAR_API_KEY });

const job = await rb.jobs.run({
  type: "ffmpeg",
  params: {
    command:
      "ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libsvtav1 -crf 35 -preset 8 -an -t 5 out.mp4",
  },
});

console.log(job.output.file.url);`}
  curl={`curl -X POST https://api.rendobar.com/jobs \\
  -H "Authorization: Bearer $RENDOBAR_API_KEY" \\
  -H "Content-Type: application/json" \\
  -d '{
    "type": "ffmpeg",
    "params": { "command": "ffmpeg -i https://cdn.rendobar.com/assets/examples/sample.mp4 -c:v libsvtav1 -crf 35 -preset 8 -an -t 5 out.mp4" }
  }'`}
/>

Swap in your own input URL and the other four commands to repeat the comparison
on your footage. Grain and motion move codec rankings more than almost anything
else, so one clip of slow animation is a starting point, not a result for your
library.

The [video codec comparison](/blog/video-codec-comparison/) puts this sweep next
to the matched-size VMAF test, hardware encoding and the SVT-AV1 preset curve.
Taken together, for a new web pipeline I would encode SVT-AV1 with an H.264
fallback and drop VP9, unless the audience leans on older hardware with VP9
decoders and no AV1 support.