Video codec comparison, measured
Compare AV1, HEVC, VP9 and H.264 on size, speed, cost and VMAF quality, measured on one file. AV1 delivered 20 more VMAF points at an identical byte budget.
Most codec comparisons fix the encoder setting and report the resulting size. That is easy to run and close to meaningless, because CRF 23 does not mean the same thing to x264 and to libaom and there is no conversion between them.
This page does it both ways: at each codec’s own conventional setting, and again with the file size held constant and the quality measured. The second is the one that settles arguments.
The comparison that settles it
Hold every codec to a 150 KB ceiling, let a search find the setting that lands there, and score the result with VMAF.
| Case | Verdict | Codec | VMAF | Size | Probes |
|---|---|---|---|---|---|
| codec auto | low | h264 | 64.3 | 146.5 KB | 6 |
| codec h264 | low | h264 | 64.3 | 146.5 KB | 6 |
| codec hevc | low | hevc | 76.2 | 140.2 KB | 5 |
| codec av1 | acceptable | av1 | 84.8 | 146.1 KB | 6 |
| Codec | Size | VMAF |
|---|---|---|
| H.264 | 146.5 KB | 64.3 |
| HEVC | 140.2 KB | 76.2 |
| AV1 | 146.1 KB | 84.8 |
20.5 points of measured quality, at the same number of bytes. VMAF above 90 is hard to distinguish from source, the 80s are good, and the 60s are where most viewers would complain. So at this bitrate H.264 produces something people notice and AV1 produces something they do not.
That is the entire modern-codec argument, stated the only way that is not arguable. Full detail in AV1 vs H.264 VMAF compared.
At each codec’s own settings
The other way round: give each codec its conventional CRF and see what falls out.
| 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. SVT-AV1 produced a file 35% smaller in 4.8x less encode time for 63% less cost. Not a tradeoff, a straight loss on every axis measured.
That matters because VP9’s argument was never technical, it was practical: the royalty-free codec with real browser support while AV1 encoders were too slow to use. SVT-AV1 removes it.
The encoder matters more than the codec. The two AV1 rows are the same codec and barely comparable: libaom produced a file 35% smaller than SVT-AV1 and took 4.3x longer. A benchmark that says “AV1” without naming the encoder and the speed preset has not told you anything actionable. Detail in AV1 vs VP9 vs HEVC vs H.264.
Choosing an AV1 speed preset
| Variant | Encode | Size | Cost |
|---|---|---|---|
| preset 4 | 2399 ms | 174.6 KB | $0.0058 |
| preset 6 | 1585 ms | 197.3 KB | $0.0043 |
| preset 8 | 1105 ms | 224.4 KB | $0.0028 |
| preset 10 | 653 ms | 229.7 KB | $0.0021 |
| preset 12 | 614 ms fastest | 219.7 KB | $0.0021 |
Preset 4 to preset 12 is 3.91x in time for 25.8% in size, so the dial is real but narrower than AV1’s reputation suggests.
One rung is worth skipping entirely: preset 12 was both faster and smaller than preset 10, so preset 10 is strictly dominated on this content. That is the same non-monotonicity that appears in x264’s presets, and the same cause: -crf targets quality, so size is emergent.
Preset 8 is the sensible default, at 2.2x faster than preset 4 for 28% more bytes. Detail in SVT-AV1 presets compared.
Hardware encoding
| Variant | Encode | Size | Cost |
|---|---|---|---|
| libx264 medium (CPU) | 913 ms fastest | 433.0 KB | $0.0030 |
| libx264 veryfast (CPU) | 1371 ms | 388.4 KB | $0.0031 |
| h264_nvenc p4 (GPU) | 1225 ms | 956.2 KB | $0.0018 |
| h264_nvenc p7 (GPU) | 1762 ms | 1127.4 KB | $0.0011 |
| hevc_nvenc p4 (GPU) | 1171 ms | 501.1 KB | $0.0008 |
hevc_nvenc on an L4 cost $0.0008 where the same libx264 command measured $0.0023 to $0.0039 across ten runs. The GPU sits below that entire band, so call it three to five times cheaper per job.
It also produced 2.2x the bytes at a nominally comparable quality setting, because NVENC’s rate control is simpler than x264’s.
That is the actual trade, and it is not the one the marketing describes. You are not buying speed; on a five-second clip we could not separate the two on time at all. You are buying cheaper jobs at the cost of larger files, and which way that lands depends on whether you pay more for compute or for bandwidth. Detail in NVENC vs libx264 compared.
Still images
The same argument runs for images, with a cleaner result.
| Variant | Encode | Size | Cost |
|---|---|---|---|
| JPEG q3 | 126 ms | 39.2 KB | $0.0015 |
| JPEG q8 | 124 ms fastest | 23.4 KB | $0.0022 |
| WebP q80 | 168 ms | 24.6 KB | $0.0015 |
| AVIF crf30 | 428 ms | 13.4 KB | $0.0017 |
| PNG lossless | 197 ms | 264.3 KB | $0.0016 |
AVIF produced 13.4 KB against JPEG’s 23.4 KB and WebP’s 24.6 KB on the same frame, so 43% and 45% smaller respectively. PNG produced 264.3 KB, nearly twenty times the AVIF, which is why it does not belong on a delivery path for photography.
WebP came out marginally larger than JPEG at comparable settings, which is not its reputation. The widely repeated “30% smaller than JPEG” claim is usually measured against a badly tuned JPEG. Detail in AVIF vs WebP vs JPEG compared.
Audio
| Variant | Encode | Size | Cost |
|---|---|---|---|
| Opus 64k | 128 ms | 50.5 KB | $0.0022 |
| Opus 128k | 101 ms | 93.2 KB | $0.0016 |
| AAC 128k | 257 ms | 80.2 KB | $0.0017 |
| AAC 192k | 170 ms | 119.4 KB | $0.0017 |
| MP3 192k | 108 ms | 118.7 KB | $0.0016 |
| FLAC lossless | 62 ms fastest | 453.0 KB | $0.0016 |
Opus at half the nominal bitrate of AAC produced 37% fewer bytes, which is why WebRTC, Discord and most modern voice stacks standardised on it. AAC still wins on playback support, particularly on older Apple hardware.
One detail that breaks storage estimates: Opus delivered 16% more bytes than its nominal bitrate predicts, because libopus defaults to variable bitrate and Ogg carries more container overhead. Nominal bitrate is a request, not a receipt. Detail in Opus vs AAC vs MP3 vs FLAC.
What to actually use
Web video, broad audience: H.264 in MP4 with yuv420p and +faststart. It is the largest of the options and it plays on everything, and that is usually the right trade. The settings around it matter more than you would think, and FFmpeg encoding settings compared has the full set measured.
Web video, modern players: AV1 via SVT-AV1 at preset 8, with an H.264 fallback. Worth 20 VMAF points at the same size.
Large library, cost-sensitive: NVENC. Several times cheaper per job, and the extra bytes only matter for files people actually watch.
Archival: libaom-av1 at a slow preset, or a lossless codec if the source is a master rather than a delivery copy.
Audio: Opus where support allows, AAC where it does not, and never FLAC over a network.
About the quality settings
In the second table each codec ran at its own conventional value: CRF 23 for x264, 28 for x265, 32 for VP9, 35 for both AV1 encoders. These scales are not interchangeable, so read that table as “what you get at each codec’s normal setting” rather than as matched quality.
The first table has no such caveat, which is why it leads this page. Fixing the size and measuring the quality needs a search that probes candidate encodes and scores each one, and that is what produced the VMAF column.
How these numbers were produced
Every figure came from a job run against a live API on one fixed source, a 5-second 1280x720 clip with audio stripped for the video tests. The codec sweeps here total 106 encodes plus 92 VMAF-scored probe encodes for the matched-size comparison.
Sizes are exact and repeatable. The same command produced byte-identical output on all ten runs we checked. Timings are single samples unless a sweep states otherwise, and identical work varied up to 2.13x on this infrastructure, so treat small timing differences as noise. That is documented in FFmpeg benchmark variance.
Where this stops
One clip, one resolution, one content type. Grain and motion move codec rankings more than almost anything else, and a 5-second clip flatters fast encoders because slow ones have less opportunity to amortise their analysis.
VMAF is a model of human perception rather than human perception, and it is known to be generous to some blur and harsh on some grain. A 20-point gap is far outside the range where that would reverse an ordering; a 2-point gap would not be.
Before you encode anything
Picking a codec assumes you know what you are holding. The source’s container, streams and durations decide half of these choices, and the container duration disagrees with the video stream by up to 493 ms on files that carry audio. How to get video duration with ffprobe has the measurements, and common ffprobe commands compared has the command set.
For letting the codec be chosen per file rather than picked once, see how to compress video to a target size, where a search over 120 jobs chose h264 47 times, AVIF 41 and AV1 only 7.
Frequently asked questions
Which video codec is best?
AV1 for efficiency and H.264 for compatibility. Held to the same file size, AV1 scored VMAF 84.8 where H.264 scored 64.3, but H.264 decodes on essentially every device made in the last fifteen years.
Is AV1 better than HEVC?
On our matched-size test, yes. AV1 scored 84.8 against HEVC's 76.2 at the same byte budget, and AV1 has no patent licensing burden. HEVC still has broader hardware decode support.
Is VP9 still worth using?
On this evidence, no. SVT-AV1 beat it on size, encode time and cost simultaneously. VP9's historical argument was that AV1 encoders were too slow, and SVT-AV1 removed it.
How much smaller is AV1 than H.264?
At matched quality settings rather than matched size, libaom-av1 produced 146.5 KB against H.264's 433 KB on the same clip, which is 66% smaller. The tradeoff is encode time.
Should I use hardware encoding?
If cost per job dominates, yes. NVENC on an L4 cost a fraction of libx264 per job while producing 2.2x the bytes, so it suits transcoding large libraries that are mostly never watched.
What is VMAF?
A perceptual video quality metric from Netflix, trained on human scoring. Above 90 is hard to distinguish from source, the 80s are good, and the 60s are where most viewers would call a result bad.
