# Video codec comparison, measured Canonical: https://rendobar.com/blog/video-codec-comparison/ Author: Abdelrahman Essawy Published: 2026-08-20 Updated: 2026-08-20 --- ## Key takeaways - Held to one 150 KB budget, AV1 scored VMAF 84.8, HEVC 76.2 and H.264 64.3. That is the comparison that settles it, because size is the constant. - SVT-AV1 beat VP9 on every axis at once: 35% smaller, 4.8x faster and 63% cheaper. There is no remaining argument for VP9 on this evidence. - The AV1 encoder matters more than the codec. libaom produced a file 35% smaller than SVT-AV1 and took 4.3x longer to do it. - NVENC on an L4 was several times cheaper per job than libx264 and produced 2.2x the bytes, which is a cost-versus-bandwidth trade rather than a speed win. - For still images AVIF was 43% smaller than JPEG and 45% smaller than WebP on the same frame. 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. _Each case asked for the same 150 KB ceiling. The job probed candidate encodes and scored each with VMAF, so size is the constant and quality is the measurement._ | 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](/blog/av1-vmaf-matched-size/). ## At each codec's own settings The other way round: give each codec its conventional CRF and see what falls out. **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](/blog/av1-vp9-hevc-h264-measured/). ## Choosing an AV1 speed preset 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](/blog/svt-av1-presets-measured/). ## Hardware encoding `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](/blog/nvenc-vs-libx264-measured/). ## Still images The same argument runs for images, with a cleaner result. 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](/blog/avif-webp-jpeg-measured/). ## Audio 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](/blog/audio-codecs-measured/). ## 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](/blog/ffmpeg-encoding-settings/) 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](/blog/measurement-noise-ffmpeg-benchmarks/). ## 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](/blog/ffprobe-video-duration/) has the measurements, and [common ffprobe commands compared](/blog/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](/blog/compress-video-target-size/), where a search over 120 jobs chose h264 47 times, AVIF 41 and AV1 only 7.