Video Transcoding Basics: H.264 vs H.265 (HEVC) vs VP9

Three codecs solve the same problem, compressing video small enough to stream without wrecking quality, and the one a platform actually ships rarely comes down to which one compresses best. Licensing, hardware decode support, and browser politics have shaped which codecs actually get used as much as engineering has. Here's what H.264, H.265, and VP9 actually are, and why the "best" codec on paper isn't automatically the one that wins.

TL;DR:

• Transcoding means decoding a source file and re-encoding it into multiple output renditions, not a one-to-one format swap, the same pipeline behind the bitrate ladder this series has already covered.
• H.264 (AVC) is the oldest of the three and still the safest default, near-universal hardware decode support across two decades of devices.
• H.265 (HEVC) compresses meaningfully better than H.264, but its patent licensing is split across three separate pools plus major unaffiliated patent holders, a real reason its adoption has lagged its technical advantage.
• VP9, Google's royalty-free codec, powers YouTube's default 4K delivery and reaches roughly 96% browser decode support, with no licensing fee attached, only a defensive clause that revokes the patent grant if a user sues over VPx patents.
• AIOZ Stream supports exactly two codecs, H.264 and H.265, not VP9; its docs don't explain why, so treat that as a stated platform limit rather than a claim about which codec is objectively best.

What transcoding actually does

Transcoding isn't converting a file from one format to another the way renaming an extension might suggest. A source upload gets fully decoded back to raw video, then re-encoded from scratch into each output rendition a platform's bitrate ladder calls for, a 240p H.264 stream, a 1080p H.264 stream, a 4K H.265 stream, each one a genuinely separate encode with its own compression decisions, not a resize of a single master file. That's computationally expensive precisely because it happens once per rendition, which is the whole reason encoding cost scales with how many quality tiers and how many codecs a platform actually needs to produce for the same source video, covered in concrete API terms in the Pillar 1 hub's broader ingest-to-playback walkthrough. Choosing a codec happens at exactly this re-encoding step, not before it and not after, which is why the same source file can end up as three or four completely different-looking compressed streams depending on which codec each rendition targets.

H.264 (AVC): the default everyone can play

H.264, formally Advanced Video Coding, dates back to the early 2000s and remains the codec every device from a decade-old smart TV to a current flagship phone can decode in hardware without exception. That universality, not compression efficiency, is H.264's actual value proposition in 2026: it's the safe fallback rendition every ladder keeps around regardless of how much better a newer codec compresses, because a stream that a viewer's device can't decode at all is worse than one that's merely a bit larger than optimal. Hardware decode support matters specifically because software-only decoding drains battery and can visibly stutter on underpowered devices, a dedicated decode chip handles the same stream at a fraction of the power draw. That's a large part of why a platform's lowest rungs, the ones most likely to reach an older phone or a budget device, tend to stay on H.264 even after H.265 is available further up the same ladder: the newest codec is worth nothing to a viewer whose device has to fall back to software decoding, or can't decode it at all.

H.265 (HEVC): better compression, fragmented licensing

HEVC's compression advantage over H.264 is real and independently measured, covered in more depth in the 4K/8K encoding article. What that article didn't cover is why HEVC took so much longer than its technical merits alone would predict to become a default. The patents behind HEVC ended up split across three separate licensing pools rather than one: MPEG LA's pool held roughly 5,000 patents from about 50 licensors as of 2021, a separate pool run by Access Advance (formerly HEVC Advance) held nearly 14,000 patents from companies including Dolby, Google, Huawei, and Philips, and a third pool, Velos Media, covers patents from BlackBerry, Ericsson, Panasonic, Qualcomm, Sharp, and Sony with its own flat per-device royalty cap. On top of that, some significant patent holders, including Nokia, Microsoft, and TI, joined none of these pools at all. A company wanting to ship HEVC with full legal clarity had to potentially negotiate with all of them separately, a genuinely different proposition from licensing a single, unified pool, and that fragmented patent situation is widely cited as the reason browser vendors were slow to add native HEVC support, not a lack of interest in a codec that compresses meaningfully better than its predecessor. Contrast that with how MPEG LA's own H.264 pool worked years earlier: one pool, one negotiation, and licensing terms simple enough that hardware vendors baked H.264 decode into chips as a default rather than an optional extra, which is a real part of why H.264 support became so universal in the first place, not just its earlier release date.

VP9: Google's royalty-free answer

Google built VP9 as a direct response to exactly that licensing problem, releasing it in 2013 after acquiring On2 Technologies, the codec's original developer, for roughly $124.6 million in 2010. The patent grant behind VP9 is explicit: "no-charge, royalty-free," per Google's own published license, with one defensive condition, if a licensee sues Google or another implementer over VP9-related patent claims, that licensee's own patent rights under the grant terminate immediately. No ongoing fee, no per-device royalty, just a clause designed to prevent the exact kind of patent litigation that fragmented HEVC's licensing in the first place. YouTube, still VP9's largest deployment by volume, encodes its 4K output in VP9 by default, and browser support has grown to reach roughly 96% of desktop and mobile traffic per CanIUse tracking, with Safari adding native VP9 decode starting in iOS 14 and macOS Big Sur, years after Chrome, Firefox, and Edge already supported it natively. Royalty-free alone didn't make VP9 a universal replacement, though, and it's worth being clear about why: hardware decode chips for VP9 lagged years behind H.264's, meaning plenty of real-world devices, especially older phones and budget TVs, decode VP9 in software if at all, burning more battery and CPU than a dedicated H.264 decode chip would. That's exactly why YouTube, the platform most invested in VP9, still serves H.264 alongside it rather than replacing H.264 outright, the same device-compatibility logic that keeps H.264 on the bottom rung of nearly every ladder regardless of which newer codec sits above it.

Why AIOZ Stream supports exactly two codecs, not three

AIOZ Stream's API documentation is direct about this: only H.264 and H.265 are supported, VP9 isn't an option regardless of resolution or use case. The docs don't explain the reasoning behind that choice, so this is worth stating plainly as a documented platform limit rather than filling the gap with a guess about AIOZ's motivations. What can be said honestly is contextual, not a claim about AIOZ's own reasoning: an H.264-plus-H.265 pairing mirrors the same two-codec approach Apple's own HLS reference ladder uses, and it avoids the extra encoding and testing surface a third full codec ladder would add, a real tradeoff any platform faces when deciding how many codecs to support at all, not just how many resolutions. Someone specifically wanting VP9 output, for a YouTube-adjacent workflow or a project already standardized on it, would need to encode that rendition through a separate pipeline outside AIOZ Stream.

Frequently Asked Questions

What's the actual difference between transcoding and converting a file format?
Transcoding fully decodes a source file and re-encodes it into multiple independent output renditions, each with its own compression decisions, not a single reformatted copy of the original.

Why is H.264 still used if H.265 compresses better?
Device compatibility. H.264 has near-universal hardware decode support built up over two decades, making it the safe fallback rendition even on a ladder that also includes more efficient codecs.

Why did HEVC adoption lag behind its technical advantages?
Its patents are split across three separate licensing pools (MPEG LA, Access Advance, Velos Media) plus major unaffiliated patent holders, a fragmented, multi-pool licensing situation widely cited as the reason browser vendors were slow to add native support.

Is VP9 really free to use?
Yes, no ongoing royalty, per Google's own published license. The only condition is defensive: a licensee's patent rights terminate if they sue over VP9-related patent claims.

Does AIOZ Stream support VP9?
No. AIOZ Stream's API documentation supports only H.264 and H.265; VP9 isn't a valid codec option on the platform, and the docs don't state a reason for that limit.

What about AV1, the newer codec?
Worth its own dedicated look rather than a quick mention here, since it's a genuinely different codec with its own licensing model and adoption story, not just a faster VP9 or H.265.

Related Reading

• Video Container Formats Explained: the container layer these codecs actually get wrapped in, a separate question from compression
• What Is AV1 and Should You Use It: why AV1's hardware decode rollout is outpacing the VP9 adoption story covered here
• Widevine vs FairPlay vs PlayReady: how DRM's encryption layer wraps around the codec output covered here
• How Video Segmentation and M3U8 Manifests Actually Work: why closed GOPs specifically are required for the manifest-switching mechanics covered there
• What Is Adaptive Bitrate (ABR) Streaming and How It Works: how the codec choice covered here feeds into a real ABR ladder
• How to Encode 4K/8K Video via the API: H.264 vs H.265: the AIOZ-specific API contract and efficiency figures for the two codecs this platform actually supports
• How to Build a Video Bitrate Ladder: A Practical Guide: the encoding pipeline transcoding fits into

References

• Fora Soft: H.265/HEVC's Patent Situation Explained: the three-pool licensing breakdown cited above
• WebM Project: VP8/VP9 Patent License: the exact royalty-free grant and defensive-termination clause quoted above
• Bitmovin: VP9 Codec Status Quo: YouTube's VP9 deployment and browser-support figures cited above