H.264 vs HEVC vs AV1: Compression, Decoding Load, Hardware Support and Licensing

Introduction

From streaming to video calls, game recording and archiving, the choice of video codec decides three things at once: how good the picture looks at a given bitrate, how much CPU or battery it costs to encode and decode, and which devices can play the result at all. The three codecs that matter for most projects today sit at different points on that triangle. H.264 (2003) plays on practically everything. HEVC (2013) needs roughly half the bitrate for similar quality but arrived with a fragmented patent licensing situation. AV1 (2018) was designed by an industry alliance to be royalty-free and compresses better still, at the price of much slower software encoding.

The practical consequence is that most real services do not pick one. They ship H.264 as a baseline every device can play and add HEVC or AV1 renditions for the devices that can decode them. The question is usually “which codecs, in which order, for which content”, and the rest of this article works through that decision.

When to Use H.264, HEVC, or AV1?

Aspect	H.264 (AVC)	HEVC (H.265)	AV1
Strength	Low decoding load, universal support	Bitrate reduction at same quality	Best compression, royalty-free licensing
Main caveat	Highest bitrate of the three	Licensing and browser support	Encoding time, hardware decoder coverage
Typical use	Maximum compatibility, live	4K, HDR, Apple ecosystem	Web and OTT at scale

---

Quick Comparison

Feature	H.264 (AVC)	HEVC (H.265)	AV1
Standard	ITU-T H.264 / MPEG-4 AVC	ITU-T H.265 / MPEG-H	AOMedia Video 1 (AV1)
Approx Compression Efficiency (same quality)	Baseline (1×)	~40-50% reduction vs H.264 typical	~20-30% additional reduction vs HEVC often reported
Encoding Speed (same hardware)	Fastest	Slower than H.264	Often slower than HEVC (software)
Decoding	Almost all devices	Modern TV, mobile, GPU (old unsupported)	Modern browsers, chipsets (old restricted)
Royalty	Patent pool (per-product fee structure exists)	Several patent pools plus independent holders	AOMedia royalty-free license (third-party claims exist)
Typical Profile/Use	Baseline~High, broadcast, web, storage	Main/Main 10, 4K, HDR	8/10bit, web streaming, VOD

The efficiency percentages are the most quoted and the least reliable numbers in any codec comparison. They come from test sets encoded under specific conditions, and the gap between codecs is largest at high resolutions and low bitrates, where the newer tools (larger block sizes, better intra prediction, more flexible partitioning) have the most room to help. At 1080p with generous bitrate, the practical difference between a good H.264 encode and an HEVC encode can be much smaller than “half”. The encoder implementation matters as much as the format: x264 is an exceptionally well-tuned encoder, and a hardware H.264 encoder on a phone produces much larger files than x264 at the same quality.

---

Codec Details

H.264 (AVC)

Feature: The closest thing to a universal video format, with a hardware decoder in essentially every phone, TV, browser and set-top box made in the last fifteen years. Still the default for live and low-latency work. Pros

• Best playback compatibility from smart TVs to old mobile and embedded devices
• Mature encoder ecosystem (x264 in particular), low real-time encoding cost Cons
• Largest bitrate of the three at the same quality
• Efficiency limits at 4K, and HDR support in H.264 is rarely usable in practice because consumer decoders mostly handle only 8-bit 4:2:0 FFmpeg Example (libx264)

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 \
  -pix_fmt yuv420p -c:a aac -b:a 128k output.mp4

-crf 23 is x264’s default constant-quality level; lower numbers mean higher quality and bigger files, and each step of about 6 roughly doubles or halves the bitrate. The -preset controls how hard the encoder searches, trading encoding time for file size at the same quality, not quality itself. -pix_fmt yuv420p looks redundant but prevents a common playback failure: given a 4:4:4 or 10-bit source, x264 keeps that format and produces a High 4:4:4 or High 10 stream that browsers and most hardware decoders cannot play.

HEVC (H.265)

Feature: Designed to cut bitrate substantially at the same subjective quality compared with H.264. Widely used for 4K and HDR, and the native recording format of modern iPhones and many cameras. Pros

• Real bandwidth and storage savings, especially at 4K
• Hardware encoding and decoding on nearly all devices from the last several years
• Mature HDR support (Main 10 profile, HDR10, HLG, Dolby Vision) Cons
• Licensing is split across several patent pools and independent patent holders, which slowed adoption in browsers and open-source software for years
• Browser support depends on the operating system’s hardware decoder; there is no universal software fallback in browsers FFmpeg Example (libx265)

ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 \
  -tag:v hvc1 -c:a aac -b:a 128k output.mp4

x265’s default CRF is 28, chosen to give roughly the same visual quality as x264’s 23, which is a reminder that CRF numbers are not comparable across encoders. The -tag:v hvc1 flag changes the sample entry in the MP4 container from FFmpeg’s default hev1 to hvc1, which stores the parameter sets in the container header. Apple’s players (QuickTime, Safari, iOS) require hvc1 and refuse to play the same stream tagged hev1, typically showing a black frame or an error with no useful message, which is one of the most common “HEVC doesn’t work on Mac” reports.

AV1

Feature: Open codec developed by the Alliance for Open Media (Google, Netflix, Amazon, Microsoft, Apple and others) with a royalty-free patent license. Large platforms such as YouTube and Netflix serve it at scale to devices that can decode it. Pros

• Best compression of the three, varying by content and encoder settings
• Royalty-free license from AOMedia members, attractive for services with large volume
• Efficient software decoding (the dav1d decoder) on desktops where no hardware decoder exists Cons
• Software encoding is CPU-heavy; hardware encoders exist only on recent GPUs and SoCs
• Older phones and TVs lack hardware decoding, and software decoding on a phone costs battery
• A third-party patent pool has claimed that AV1 implementations need a license, which AOMedia disputes; for most services the practical risk has been low, but it means “royalty-free” is a position rather than a guarantee FFmpeg Example (libaom-av1 / libsvtav1)

# SVT-AV1: Speed and quality balance often used in practice
ffmpeg -i input.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -c:a libopus -b:a 128k output.mkv

SVT-AV1 presets run from 0 (slowest, best compression) to 13 (fastest). Around 4 to 6 is a common range for video on demand; above 10 is intended for real-time use. Its CRF scale runs from 0 to 63, so the number 30 here does not correspond to x264’s 30. The reference encoder libaom-av1 compresses slightly better at its slowest settings but is far slower, which is why production pipelines mostly use SVT-AV1.

---

Performance Comparison

Absolute numbers vary greatly by resolution, frame rate, content complexity, preset and CRF. Below are relative trends commonly observed on the same machine with comparable settings.

Metric	H.264	HEVC	AV1
File size at similar visual quality	Largest	Medium	Often smallest
Encoding time (software)	Short	Medium	Long
Real-time encoding	Easy	Easy with hardware (NVENC, Quick Sync, VideoToolbox)	Needs a recent hardware encoder or fast presets
Decoding cost	Lowest	Moderate, usually hardware	Higher in software, fine with hardware

The encoding-time gap is the part that surprises people in practice. On a CPU, an AV1 encode at a quality-oriented preset can take many times longer than an x264 encode of the same file, so a pipeline that handled a day’s uploads overnight with H.264 may need several times the compute for AV1. That is why the usual strategy is to encode AV1 only for content that will be watched enough to earn back the encoding cost in bandwidth, while long-tail content stays H.264.

Visualization: Selection Decision Flow

flowchart TD
  A[Codec Selection] --> B{Top Priority?}
  B -->|All device playback| C[H.264]
  B -->|Bandwidth reduction + modern devices| D[HEVC or AV1]
  B -->|Minimize royalty| E[AV1 + H.264 fallback]
  C --> F[Maximum compatibility]
  D --> G[Check decoder support matrix]
  E --> H[Multi-codec pipeline]

When measuring: compare encodes of the same source with an objective metric such as VMAF (or SSIM/PSNR as secondary checks) and record encoding time, then play the results on real target devices. Comparing codecs at the same CRF number is meaningless; compare file sizes at the same VMAF score, or VMAF at the same file size. When I first compared encoders, the mistake I made was using a short, easy test clip: a talking-head video compresses well with anything, and the differences only showed up on grain, water, confetti and fast motion. Build a test set that includes your hardest content.

---

Recommendations by Scenario

Scenario	Recommendation	Reason
Wide compatibility (web, embedded)	H.264	Best decoder availability
4K/HDR VOD, modern TV	HEVC or AV1	Bandwidth & storage efficiency
Low-latency live	H.264 or HW HEVC	Encoding latency & stability
Long-term archive + cost	Keep the best master you have; derive AV1/HEVC for delivery	Future re-encoding without generational loss
Game recording, editing compatibility	H.264 (editing tools, sharing)	Simplify workflow

Practical decision order: (1) confirm which decoders your audience’s devices actually have, from your player analytics rather than assumptions, (2) the encoding budget in time and compute, (3) CDN cost per gigabyte multiplied by expected views. The third factor is why large platforms adopt AV1 first: at billions of views, a 30% bandwidth saving dwarfs encoding cost, while for a small site the extra encoding complexity rarely pays for itself.

Live streaming deserves a note of its own. Latency comes mostly from the encoder’s lookahead and B-frames plus the player’s buffer, not from the codec itself. x264 with -tune zerolatency disables the features that add delay, and hardware encoders in all three codecs can run with minimal latency. H.264 remains the default for live mainly because every ingest server, CDN and player accepts it.

---

Migration Guide

H.264 → HEVC

1. Check HEVC decoding support on the target platforms; in browsers it depends on the operating system and hardware, so verify with real devices.
2. Set the container tag (-tag:v hvc1) so Apple devices play the MP4.
3. Keep serving the H.264 rendition to clients that cannot decode HEVC, either in the same adaptive-streaming manifest or at a separate URL.

# H.264 to HEVC
ffmpeg -i input_h264.mp4 -c:v libx265 -preset medium -crf 28 \
  -tag:v hvc1 -c:a copy output_hevc.mp4

HEVC/H.264 → AV1

1. For software encoding, pick the preset from your time budget first, then tune CRF for quality; enable tiles or parallel chunked encoding to use many cores.
2. Fallback: configure adaptive streaming (HLS/DASH) so players that cannot decode AV1 select the H.264 or HEVC renditions.
3. Keep masters: store the highest-quality source separately so future re-encodes start from it.

# H.264 to AV1
ffmpeg -i input_h264.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -c:a libopus -b:a 128k output_av1.webm

Transcoding from one lossy format to another always stacks a second generation of compression artifacts on the first. An H.264 file re-encoded to AV1 at a “higher quality” setting can still look worse than the H.264 it came from, because the AV1 encoder spends bits faithfully reproducing the H.264 blocking and noise. Encode from the original master whenever it exists.

Caution: patent and distribution policies vary by product and region, so always check legal and vendor guidance for commercial products.

---

Delivery and Fallback

Mixed Pipeline (e.g., MP4 + H.264 + AAC)

• Compatible baseline: H.264 + AAC in MP4 plays on almost all clients.
• High-efficiency layer: add AV1 or HEVC variants of the same content and let capable clients choose them; the bandwidth saving helps users on slow connections most, since they get better quality at the bitrate they can sustain.

Fallback Strategy

1. <video> + multiple <source> elements (the browser picks the first one it can decode).
2. HLS/DASH: separate renditions by codec; the player selects based on its capabilities.
3. Server transcoding: keep the master (e.g., ProRes or a high-bitrate mezzanine file) and derive distribution codecs from it.

<video controls>
  <source src="trailer.av1.mp4" type='video/mp4; codecs="av01.0.08M.08"'>
  <source src="trailer.hevc.mp4" type='video/mp4; codecs="hvc1.1.6.L93.B0"'>
  <source src="trailer.h264.mp4" type="video/mp4">
</video>

Order matters: the browser takes the first <source> it believes it can play, so the most efficient codec goes first and the universal fallback last. The codecs parameter is what lets the browser decide without downloading anything, so it must describe the file accurately; the HEVC string must use the same hvc1/hev1 tag as the file, and a wrong profile or level string can make a browser skip a file it could have played, or pick one it cannot. MediaSource.isTypeSupported() and navigator.mediaCapabilities.decodingInfo() answer the same question from JavaScript, and the latter also reports whether decoding will be smooth and power-efficient, which is the difference between hardware and software decoding.

Encoding Best Practices

# H.264 baseline (maximum compatibility)
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -profile:v high -level 4.1 \
  -pix_fmt yuv420p -c:a aac -b:a 128k -movflags +faststart h264.mp4
# HEVC (4K, bandwidth reduction)
ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 -tag:v hvc1 \
  -c:a aac -b:a 128k -movflags +faststart hevc.mp4
# AV1 (next-gen, royalty-free)
ffmpeg -i input.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -c:a libopus -b:a 128k av1.webm

-movflags +faststart moves the MP4 index (the moov box) to the start of the file. Without it, a browser playing the file over HTTP must fetch the end of the file before it can start playback, which shows up as a long delay before the first frame on large files. -profile:v high -level 4.1 caps the stream at settings that virtually every hardware decoder of the last decade supports up to 1080p. For adaptive streaming, all renditions should also share the same keyframe interval (for example -g equal to two seconds of frames with scene-cut keyframes disabled) so players can switch between them at segment boundaries.

---

Common Questions

Q1. Can I use same CRF number for H.264, HEVC, and AV1? No. Each encoder has its own CRF scale; x264’s 23, x265’s 28 and an SVT-AV1 value somewhere in the 30s can all produce similar quality. Tune each separately and compare at equal VMAF.

Q2. Does AV1 always create smaller files than HEVC? The trend exists, but short clips, simple content and fast presets can shrink or erase the difference. Always validate with samples of your own content.

Q3. What is suitable for real-time broadcasting? If low latency and stability are the priority, H.264 or a verified hardware HEVC encoder are the common choices. Real-time AV1 is practical with recent hardware encoders; in software it needs fast presets and a lot of CPU.

Q4. AV1 on iOS Safari? Apple supports AV1 playback only on devices with a hardware AV1 decoder, which excludes many iPhones and iPads still in use. Check current compatibility tables and always provide an HEVC or H.264 fallback for Apple devices.

Q5. For HDR? Both HEVC and AV1 support 10-bit HDR, but HDR metadata (HDR10 static metadata, HDR10+ or Dolby Vision dynamic metadata, HLG) and player support vary widely. Validate on the actual target platforms; an HDR file that plays with washed-out colors usually means the metadata or color signaling flags were lost somewhere in the pipeline.

---

Conclusion

• If compatibility is the top priority, H.264 is still the safest default.
• If bandwidth and storage costs are significant, add HEVC or AV1, weighing decoder support and encoding cost together.
• AV1 is attractive long-term for its licensing model and efficiency, but plan for fallback renditions and encoding time. To cover all devices, default to H.264 and add HEVC/AV1 as additional layers when efficiency matters.

Quick Decision Guide

Maximum compatibility? → H.264
4K/HDR + modern devices? → HEVC
Royalty-free priority? → AV1 (with H.264 fallback)
Real-time low latency? → H.264 or HW HEVC
Long-term archive? → Keep the original master; derive AV1/HEVC for delivery

---

Related Articles

• H.264 (AVC) Encoding in Practice
• HEVC (H.265) Practical Guide
• AV1 Next-Generation Codec Guide

---

Frequently Asked Questions (FAQ)

Q. Is it worth re-encoding an existing H.264 library to HEVC or AV1?

A. Re-encoding a lossy file to another lossy codec adds a second generation of artifacts, so you never get back quality that was lost in the first encode. The storage or bandwidth savings can still pay off for heavily viewed titles, but it is better to encode from the original masters when you have them. For rarely watched content, the compute cost of re-encoding often outweighs the savings, and serving the existing H.264 files keeps compatibility broad.

---