Understanding Video Codecs: H.264, HEVC (H.265), VP9, and AV1
Published by MediaDocks Engineering Team
Explore the technology behind digital video compression: why H.264 remains universal, how VP9 powers YouTube, why HEVC faced licensing hurdles, and how AV1 shapes the future of streaming.
Table of Contents
- 1.What Does a Video Codec Actually Do?
- 2.H.264 (AVC): The Universal Workhorse
- 3.H.265 (HEVC): Efficiency & Licensing Complexities
- 4.VP9: Google's Open Web Alternative
- 5.AV1: The Open Media Standard
- 6.Codec Comparison Matrix
- 7.Hardware and Software Encoders Differ
- 8.Bit Depth, Chroma Subsampling & Colour
- 9.Choosing a Codec in Practice
What Does a Video Codec Actually Do?
Uncompressed digital video is astronomically large. A single minute of raw 1080p video at 60 frames per second with 8-bit color requires roughly 22 Gigabytes of bandwidth. Without compression, streaming or storing video on consumer devices would be physically impossible.
A video codec applies advanced mathematical transforms, spatial redundancy reduction (intra-frame), and temporal motion estimation (inter-frame) to compress that raw video by a ratio of 200:1 to 1000:1 with minimal perceptible loss in visual clarity.
H.264 (Advanced Video Coding - AVC)
Ratified in 2003, H.264 is the most successful and widespread digital video standard in history. Dedicated silicon decoding units are embedded into virtually every processor built in the last 15 years, meaning an H.264 video decodes with near-zero CPU usage and minimal battery consumption.
Its limitation is compression efficiency compared to modern standards. Achieving crisp 4K playback with H.264 requires substantial bitrates (30-50 Mbps), which can strain residential broadband connections.
H.265 (High Efficiency Video Coding - HEVC)
Introduced in 2013, HEVC delivers roughly 50% better compression than H.264 at equivalent visual quality. It supports 10-bit color depths, HDR10, and resolutions up to 8K.
Despite technical excellence, HEVC adoption on the open web was severely stunted by fractured patent pools (MPEG LA, HEVC Advance, and Velos Media) demanding high royalties. While Apple embraced HEVC natively across iOS and macOS, Google Chrome and Mozilla Firefox historically resisted supporting it for open web video.
VP9: Google's Open Web Alternative
In response to HEVC's licensing hurdles, Google released VP9 as a free, open-source video codec in 2013. VP9 matches HEVC's compression efficiency (roughly 40-50% better than H.264) and became the primary codec powering YouTube's 1440p and 4K streams.
Because VP9 is royalty-free, it was universally adopted across all desktop web browsers, making high-resolution web video viable without licensing friction.
AV1: The Open Media Standard
Developed by the Alliance for Open Media (AOMedia)—a consortium comprising Google, Apple, Microsoft, Amazon, Netflix, Meta, Intel, and NVIDIA—AOMedia Video 1 (AV1) is the successor to VP9 and H.264.
AV1 provides approximately 30% higher compression efficiency than VP9/HEVC and over 60% better compression than H.264. Modern mobile chips (Apple A17 Pro/M3+, Qualcomm Snapdragon 8 Gen 3, Google Tensor G3) feature dedicated AV1 hardware decoding blocks, making it the emerging standard for global streaming.
Codec Comparison Matrix
Review the technical differences across the four major video codecs in production today:
| Codec | Release Year | Compression vs H.264 | Licensing | Hardware Support |
|---|---|---|---|---|
| H.264 (AVC) | 2003 | Baseline (1.0x) | Royalty (MPEG LA) | Universal (100% of devices) |
| H.265 (HEVC) | 2013 | ~50% smaller | Multiple Royalty Pools | Universal on Mobile/TVs; spotty in web browsers |
| VP9 | 2013 | ~45% smaller | Royalty-free (Google) | All modern web browsers, Android, PC, Mac |
| AV1 | 2018 | ~65% smaller | Royalty-free (AOMedia) | Recent GPUs (RTX 3000+, Apple M3+, modern phones) |
Hardware and Software Encoders Are Not Interchangeable
Naming a codec does not fully describe what produced a file. H.264 is a specification describing how a decoder must interpret a bitstream; it says very little about how an encoder should decide what to put in that bitstream. Two encoders targeting the same codec at the same bitrate can produce visibly different results, and the gap between them is often larger than the gap between codec generations.
Software encoders such as x264 and x265 run on the CPU and are free to spend as long as they like evaluating options: trying multiple block partitionings, searching widely for motion matches, and running two passes so the second can benefit from knowing where the difficult material is. Hardware encoders — NVIDIA's NVENC, Intel Quick Sync, Apple's VideoToolbox, the equivalent blocks in phone chips — are fixed-function silicon built for speed. They encode in real time or faster at almost no CPU cost, and they get there by making quicker, shallower decisions.
The practical consequence is that a hardware encoder typically needs a noticeably higher bitrate to match the visual quality of a good software encode. That is an excellent trade for live streaming, game capture and screen recording, where finishing in real time is the entire requirement. It is a poor trade for a final master or an archive copy, where the file will be encoded once and watched many times, and where letting x264 take ten minutes instead of thirty seconds buys you a smaller file that looks better.
Bit Depth, Chroma Subsampling and Colour
Resolution gets all the attention, but how a codec represents colour affects perceived quality just as much, and it explains several artefacts people routinely misdiagnose as low bitrate.
Bit depth is the number of distinct levels available per colour channel. Eight-bit video offers 256 steps per channel, which sounds generous until you look at a clear sky or a slow fade to black, where the available steps are too coarse to describe a gradual transition. The result is banding: visible stripes where there should be a smooth gradient. Ten-bit video provides 1,024 steps per channel and largely eliminates the problem. Counterintuitively, encoding in 10-bit often produces a slightly smaller file than 8-bit at equal perceived quality, because the encoder's internal maths suffers less rounding error.
Chroma subsampling is a separate economy. Human vision is far more sensitive to brightness than to colour, so almost all delivery codecs store full-resolution luma and reduced-resolution chroma. The 4:2:0 scheme used by essentially every streaming platform keeps colour information at half resolution in both directions, discarding three quarters of it. This is invisible on normal footage and very visible on saturated red text, fine coloured detail, and chroma-key edges — which is why editing and mastering formats use 4:2:2 or 4:4:4 even though delivery does not.
| Property | Typical delivery | Typical mastering | Visible when wrong |
|---|---|---|---|
| Bit depth | 8-bit (10-bit for HDR) | 10-bit or 12-bit | Banding in skies and fades |
| Chroma | 4:2:0 | 4:2:2 or 4:4:4 | Smeared red text, rough key edges |
| Colour range | Limited (16–235) | Full (0–255) | Washed-out or crushed blacks |
Choosing a Codec in Practice
Most codec decisions collapse into a single question: do you know what will play this file? If the answer is no, the decision is already made. H.264 in an MP4 container with AAC audio is the only combination that is genuinely safe everywhere, and choosing anything else in exchange for a smaller file is trading certainty for bytes.
When you do control the playback environment, efficiency becomes worth pursuing. Serving video from your own site to modern browsers makes VP9 or AV1 sensible, because the bandwidth saving is multiplied across every visitor and you can supply an H.264 fallback for the ones who need it. Archiving footage you will edit later argues for a high-bitrate 10-bit intermediate rather than any delivery codec, since each re-encode of a delivery format compounds generational loss.
One thing worth not overthinking: for a file you downloaded and intend to watch once, the codec it arrived in is almost certainly the right one. Re-encoding it to something more efficient costs you a generation of quality and an hour of waiting, to save storage that costs a fraction of a penny.
- Unknown playback target: H.264 + AAC in MP4. Not negotiable.
- Your own website, modern browsers: VP9 or AV1, with an H.264 fallback.
- Archive for future editing: 10-bit intermediate, not a delivery codec.
- Watching once: leave it alone. Re-encoding costs more than it saves.
How MediaDocks Works
Learn how our server multiplexes adaptive video and audio tracks in memory.
Questions about this topic
Why does my media player only play audio and show a black screen?
Which codec does MediaDocks use when multiplexing 1080p and 4K?
Why do I see banding in skies and gradients even at a high bitrate?
Is a hardware-encoded file lower quality than a software-encoded one?
More guides in this library
MP4 vs WebM: Complete Comparison of Video Container Formats
A technical comparison between MP4 and WebM containers: compatibility across Apple, Windows, and Android ecosystems, compression ratios, and which to choose for web publishing or archiving.
Video FormatsVideo Resolutions Explained: 720p, 1080p, 1440p, and 4K UHD
A complete guide to video resolutions: understanding pixel dimensions, aspect ratios, bitrate requirements, and how to choose the right download rung for your device and bandwidth.
Audio ProcessingAudio Bitrate Explained: Comparing 128 kbps, 192 kbps, and 320 kbps
A pragmatic look at digital audio quality: how lossy encoding works, what bitrate you actually need for podcasts versus music, and why 320 kbps is often redundant.