H.264, H.265, and AV1 are the three video codecs that matter in 2026. H.264 (AVC) is the universal lowest common denominator — every phone, browser, smart TV, and security camera decodes it in hardware. H.265 (HEVC) compresses roughly 50% better at the same visual quality but carries fragmented patent licensing (MPEG-LA, HEVC Advance, Velos Media) that has kept some platforms wary. AV1 is the newest codec, royalty-free under the Alliance for Open Media, compresses another 30–50% better than H.265, and is finally seeing universal hardware decode support on devices shipped since 2022. This article compares the three on bitrate efficiency, encoding cost, hardware decode, patent licensing, and use-case fit.
At-a-glance comparison
| Property | H.264 (AVC) | H.265 (HEVC) | AV1 |
|---|---|---|---|
| Standardized | 2003 (ITU-T / ISO MPEG-4 Part 10) | 2013 (ITU-T / ISO MPEG-H Part 2) | 2018 (Alliance for Open Media) |
| Compression vs predecessor | ~50% better than MPEG-2 | ~50% better than H.264 | ~30–50% better than H.265 |
| Max resolution | 4K (Main10 / High profiles) | 8K | 8K |
| Color depth | 8-bit standard, 10-bit High10 | Up to 16-bit | Up to 12-bit (Main and High profiles) |
| Software encode speed | Fast (x264 ~real-time on CPU) | Moderate (x265 ~2–4× slower than x264) | Slow (libaom 10–20× slower; SVT-AV1 closing gap) |
| Hardware encode | Universal | Common (most 2017+ silicon) | Limited (Intel Arc, Nvidia 40-series, Apple M3+) |
| Hardware decode | Universal | Widespread (smartphones, smart TVs, browsers via OS) | Growing (Apple M3+, Intel 11th gen+, Nvidia RTX 30+, modern Android) |
| Patent licensing | MPEG-LA pool, well understood | Fragmented (3+ pools) | Royalty-free under AOMedia patent license |
| Browser support | All major browsers | Safari natively; Chrome/Firefox via OS decoder | Chrome, Firefox, Edge; Safari 17+ |
| Streaming adoption | Default fallback everywhere | Premium tier (Netflix UHD, Apple TV+) | YouTube default, Netflix expanding, Twitch testing |
| Typical encoder | x264, NVENC, QuickSync, VideoToolbox | x265, NVENC HEVC, QuickSync HEVC | libaom (reference), SVT-AV1 (Netflix/Intel), rav1e |
Compression efficiency: what "50% better" actually means
The headline "AV1 is 50% better than H.264" is a rate-distortion claim measured by BD-rate (Bjøntegaard delta rate) on standardized test sequences. It means at the same perceived quality, AV1 needs roughly half the bitrate. Concretely, a 4K stream that needs 16 Mbps in H.264 needs about 8 Mbps in H.265 and about 4–5 Mbps in AV1. The savings show up most on:
- High-motion content (sports, gaming) where temporal redundancy is large.
- High-resolution content (4K, 8K) where block-based gains compound.
- Slow-tune encoder presets where the codec gets time to explore the rate-distortion landscape.
Savings shrink for low-resolution low-motion content (talking heads at 720p) where H.264 already has headroom.
Encoding cost: the practical asymmetry
Decoding is cheap on all three. Encoding is where the cost gap is enormous and where rollout has historically lagged:
- x264 (H.264 reference encoder) is so well-tuned that real-time 1080p30 encode is trivial on any modern CPU.
- x265 (H.265 reference encoder) is roughly 2–4× slower than x264 at comparable quality, even after a decade of optimization.
- libaom (AV1 reference) is roughly 10–20× slower than x264 — practically unusable for live streaming until SVT-AV1 (Intel + Netflix) brought encode times within ~2–5× of x264 at comparable quality.
This is why AV1 first appeared on platforms that can amortize encode cost across millions of viewers (YouTube, Netflix VOD) before reaching real-time use cases (Twitch, video conferencing).
Hardware decode: where adoption actually happens
A codec's real-world deployability is gated by hardware decoder availability. Software decode is possible but burns CPU and battery — phones can't ship that way. The hardware decode timeline:
- H.264: every consumer device since 2008. Universal.
- H.265: smartphones (iPhone 6+ for Apple, Snapdragon 805+ for Android), most 2015+ smart TVs, Apple TV, Roku Premiere+, most modern PC GPUs, browsers via OS decoder.
- AV1: Apple M3+, Intel 11th-gen+ Tiger Lake (decode) and Arc (decode+encode), Nvidia RTX 30-series+ (decode) and 40-series+ (encode), Snapdragon 8 Gen 1+, recent MediaTek Dimensity. Universal on 2024+ flagships; absent on most 2020 and earlier devices.
If your audience includes a long tail of older devices (broadcast TV viewers, embedded systems, security cameras), you're shipping H.264 either as the primary stream or as a fallback rung in an adaptive bitrate ladder.
Patent licensing: the AV1 differentiator
This is where AV1's strategic value sits:
- H.264 has one well-known pool (MPEG-LA / Via LA) with a cap. Most companies just pay and move on.
- H.265 has three+ pools (MPEG-LA, HEVC Advance, Velos Media) plus unaffiliated patent holders. Total cost is hard to predict. This fragmentation is widely credited with slowing H.265 adoption on the web.
- AV1 is royalty-free under the AOMedia patent license. The Alliance (Google, Netflix, Apple, Microsoft, Amazon, Meta, Nvidia, Intel, ARM, Samsung, Cisco, Mozilla) pooled patents and granted free licenses to encourage adoption.
For platforms where licensing per stream or per device is a material cost (YouTube ~5B hours/day, Netflix ~10B hours/quarter, large device OEMs), royalty-free AV1 is structurally cheaper at scale even when encode is slower.
Use-case decision matrix
| Use case | Recommended primary codec | Why |
|---|---|---|
| Universal compatibility (broadcast, legacy devices) | H.264 | Decoded by everything. Bandwidth penalty acceptable when reach > efficiency. |
| Premium streaming on Apple ecosystem | H.265 | iOS/macOS hardware decode is excellent; Apple favored HEVC for ProRes-quality 4K HDR. |
| Large-scale VOD (YouTube, Netflix, Twitch) | AV1 | Encode cost amortized across millions of viewers; royalty-free; best efficiency per byte served. |
| Real-time video calls | H.264 today, AV1 soon | H.264 still ubiquitous in browsers/SDKs; AV1 real-time encoders (SVT-AV1, hardware) maturing in 2024–2026. |
| Security cameras, NVR | H.264 / H.265 | Edge encode is constrained; H.265 increasingly default on modern IP cameras for bandwidth/storage savings. |
| Live sports, esports | H.265 today, AV1 piloting | Bitrate matters at scale; AV1 hardware encode (Intel Arc, NVENC) makes live AV1 feasible from 2023+. |
| Adaptive bitrate ladder for a web player | All three (ABR) | Ship H.264 baseline + H.265 + AV1 rungs; let the player pick the best codec the device decodes in hardware. |
How the codecs work under the hood
All three codecs share the same fundamental compression pipeline pioneered by H.264: divide each frame into blocks, predict each block from neighbors (intra) or previous frames (inter / motion estimation), transform the prediction residual into the frequency domain (DCT-like), quantize, and entropy-code. The differences are in:
- Block sizes: H.264 uses up to 16×16 macroblocks; H.265 introduced Coding Tree Units up to 64×64; AV1 extends to 128×128 superblocks. Larger blocks help smooth high-resolution content.
- Prediction modes: H.264 has 9 intra modes; H.265 has 35; AV1 has 56. More modes means better prediction but more encoder search cost.
- Transforms: H.264 uses 4×4 and 8×8 integer DCTs; H.265 adds asymmetric transforms; AV1 adds DST and identity transforms.
- Loop filters: H.265 added the Sample Adaptive Offset filter; AV1 added the Constrained Directional Enhancement Filter (CDEF) and the loop restoration filter.
- Entropy coding: H.264 uses CAVLC and CABAC; H.265 uses CABAC only; AV1 uses a range coder with adaptive probability models.
For a deeper look at how the underlying compression pipeline works, see H.264 Codec Fundamentals — most of the concepts (motion estimation, DCT, quantization, entropy coding) apply directly to H.265 and AV1 with extensions.
Reading further
- H.264 Codec Fundamentals (Part 1 of 3) — the encoding pipeline, block-based processing, motion estimation.
- H.264 Transform and Quantization (Part 2 of 3) — DCT, quantization, entropy coding.
- H.264 Implementation and Applications (Part 3 of 3) — profiles, levels, deployment patterns.
