
Your catalogue is already encoded in H.264. It plays on everything, it has for years, and nobody has ever filed a ticket about it. Then someone runs next year's delivery bill and asks the obvious question: why are we not using the codec that halves it?
It is a fair question with an uncomfortable answer. H.265 does compress better, and at 4K the difference is hard to ignore. But the saving arrives attached to a licensing bill, a heavier encoding load, a storage line that rises before it falls, and a fleet where a meaningful share of devices cannot decode the new codec properly. This article works through both halves of that trade, so you can price the migration before committing a catalogue to it.
H.265 compresses the same video into roughly half the bitrate as H.264, at the cost of more computation to encode and narrower device support to play back.
Both are video compression standards, and both go by two names. H.264 is also called AVC (Advanced Video Coding). H.265 is also called HEVC (High Efficiency Video Coding) — the same standard under two labels, which is worth stating plainly because the names are used interchangeably across specs, encoder settings and device datasheets.
H.264 arrived in 2003 and became the default for practically everything: broadcast, Blu-ray, IPTV, web video encoding, video calls. H.265 followed a decade later with one design goal — equivalent quality at about half the bitrate — aimed at the 4K and HDR content H.264 cannot carry economically.
The mechanism behind that gain is block size. H.264 divides each frame into fixed macroblocks of up to 16×16 pixels; H.265 replaces them with coding tree units up to 64×64 that subdivide adaptively, so a flat expanse of sky becomes one large block instead of sixteen small ones. That flexibility is where most of the efficiency comes from, and it is also why encoding takes longer.
| Attribute | H.264 (AVC) | H.265 (HEVC) |
|---|---|---|
| Finalised | 2003 | 2013 |
| Block structure | Macroblocks, up to 16×16 | Coding tree units, up to 64×64 |
| Compression target | Baseline | About 50% lower bitrate at equivalent quality |
| Typical 1080p bitrate | 5–8 Mbps | 3–4 Mbps |
| Typical 4K bitrate | 32–45 Mbps | 15–20 Mbps |
| Device decode reach | Effectively universal | Broad but uneven |
| Hardware decode | On essentially every shipped device | Modern devices; absent on older set-top boxes |
| Licensing | Effectively one patent pool | Several pools, with rates that move |
| Encoding compute | Low | Substantially higher |
| Best fit | Universal reach, the reliable floor | 4K, HDR, high-bitrate rungs |
Roughly half, and the saving grows with resolution — which means it matters most exactly where your bill is largest.
At 1080p the practical gain usually lands between 35% and 50%. At 4K it approaches, and sometimes passes, the standard's 50% design target, because a large frame holds more redundancy for adaptive block sizes to exploit. To model this against your own ladder rather than a generic table, our bitrate calculator and our guide to 4K streaming bandwidth will get you closer than any rule of thumb.
The important part is that this is not a one-off win. Global mobile data traffic stood at 146 exabytes per month at the end of 2025 and is forecast to reach 328 exabytes per month by 2031 (Ericsson Mobility Report, 2026). Halving per-stream bitrate does not just cut today's bill — it buys headroom against a curve that keeps climbing.
Far less than the compression numbers suggest in some regions, and far more in others — because what a gigabyte costs depends on where your subscribers are.
Delivery pricing is not uniform. Content delivery network rates in South America average around 2.8 times the per-gigabyte cost of North America, and capacity in some markets, such as Korea, has been quoted at roughly ten times North American pricing (Streaming Media Blog, 2026). Halving bitrate in a market at 2.8x pricing is worth almost three times what the same change is worth in a cheap one, so model this per region rather than globally.
There is a second reason the codec matters more than it used to: per-gigabyte prices have been drifting down only a few percent a year, nowhere near fast enough to absorb traffic growth on their own. Unit pricing will not rescue your delivery budget, which leaves encode efficiency as one of the few levers that still moves — alongside routing, which our overview of live streaming CDN strategy covers.
H.264 plays essentially everywhere. H.265 does not, and the gap is wider than most comparisons admit.
Across 363 million codec capability tests spanning 1.14 million real user sessions between January and March 2026, H.264 decode support reached 99.94% of sessions. H.265 support in the same dataset ranged from above 95% on Safari down to roughly 81% on Chrome for Windows and about 56% on Edge for Windows, and was close to absent on Firefox (WebCodecs Fundamentals, 2026).
For an operator, browser data understates the problem, because a subscriber fleet is not a browser population. Deployed set-top boxes, smart TVs bought five or seven years ago, and low-cost Android devices are what actually matters — and on those, H.265 is either decoded in hardware, decoded in software, or not decoded at all.
That middle case is the one that hurts. Software decode on a low-power device means heat, battery drain, dropped frames on high-bitrate rungs, and a support call that arrives labelled "buffering" rather than "codec." So audit what your installed base can decode in hardware before committing to an H.265 ladder — that audit, not the compression ratio, is what sets the timeline.
H.264's royalties come from what is effectively a single pool with well-understood terms. H.265's are divided across several pools, and the terms move.
That fragmentation is the practical difference: rather than one licence to evaluate, there are multiple rights holders, overlapping claims, and periodic repricing. Repricing does happen — one of the major HEVC pools put a 25% rate adjustment into effect for new licensees from 1 January 2026 (Access Advance via Business Wire, 2025).
So treat H.265 licensing as a moving line item rather than a fixed one-time cost, and get your exposure reviewed before you re-encode a catalogue. What you owe depends on your device volumes, distribution model and territories — a commercial question for your own counsel, not a technical one.
More compute per hour of video, and — for as long as the transition lasts — more storage rather than less.
Evaluating all those block-partitioning options is what makes H.265 encoding expensive. The multiplier depends on encoder, preset and content, but the direction never changes: the same library costs meaningfully more to transcode into H.265 than into H.264. At operator scale this is where the choice between hardware and software encoding stops being academic and starts showing up on an invoice.
Storage moves the wrong way first. If you add an H.265 ladder while keeping H.264 for reach — which, as the next section explains, is what almost everyone does — you are storing two encoded versions of every asset. The per-file saving is real, but the file count roughly doubles. That is not a reason to stay on H.264; it is a reason to budget the transition properly.
Barely, in the case of latency — and this is where most codec comparisons stop far too early.
Codec choice has little effect on end-to-end latency. That is determined by your protocol, segment length and player buffer, not by whether a frame was compressed with macroblocks or coding tree units. Where the codec helps is indirectly: lower bitrate means more headroom when demand spikes, and demand does spike — live sports events generate traffic peaks that can exceed normal usage by 30 to 40% (AppLogic Networks, 2025). Halving bitrate is one way to survive kick-off.
Advertising is where the codec decision has a consequence nobody warns you about. Server-side ad insertion works by stitching ad segments into the content stream, and that stitch only holds if the ad creative is encoded to match the ladder it is spliced into. Add an H.265 ladder and you have added a second encoding target for every piece of ad inventory. Skip that step and you get mid-roll failures on exactly the devices you added the ladder for.
Content protection is more forgiving. DRM operates at the packaging layer and applies to both codecs equally — though each extra ladder is another set of keys and playback paths to test.
Because neither codec covers the whole audience on its own.
The adoption data makes this unusually clear. H.264 is used by 79% of video developers and H.265 by 49% (Bitmovin, 2025). Those figures sum well past 100%, and the overlap is the finding: the common configuration is not H.264 or H.265, it is both.
The pattern that works is to treat H.264 as the floor and H.265 as the upgrade. Every rung of your adaptive bitrate ladder stays available in H.264 so no device is stranded, while H.265 is layered on top for devices reporting hardware support, concentrated on the high-resolution rungs where the saving is largest. It costs more than a single ladder, and it is the only configuration that captures the saving without trading away reach — which is why "should we switch?" is the wrong question. The right one is which rungs, for which devices, on what timeline.
Choose based on what your devices can decode and where your delivery costs land, not on which codec is newer.
Broad consumer audience on mixed devices: keep H.264 as the floor and add H.265 to the upper rungs — the saving where it is worth most, and nobody stranded.
A 4K or HDR catalogue: H.265 pays for itself fastest here. This is what the standard was designed for, and the bitrate gap at 4K carries the licensing and encoding cost on its own.
An ISP or TV operator with a managed set-top fleet: the decode audit comes first. Your fleet, not the market, sets the timeline — and if many boxes lack hardware H.265 decode, the honest answer may be to wait for the refresh cycle.
A content creator publishing through someone else's platform: the platform's ladder decides for you — upload the best master you can and let them handle the rest.
One thing has shifted the weighting here: viewing has moved to the living room. Streaming reached 48.6% of total TV watch-time in May 2026, against 19.2% for broadcast and 20.4% for cable (Nielsen, 2026). The decode question that matters most is now on the big screen, not in the browser.
If you would rather not build and maintain dual ladders yourself, that is the part we handle. inoRain runs multi-codec delivery across the devices operators actually have to support — Android TV, Samsung, LG, Roku, iOS and Android — with multi-CDN failover and multi-DRM built in, on tailored paths for ISPs, TV providers and broadcasters, and content creators. Whichever route fits, the decode audit is where we would start too.
Both exist, and neither changes the decision in front of you today. AV1 is royalty-free and compresses better than H.265, but device support is still uneven; H.266 (VVC) is newer and barely deployed. We cover that comparison in AV1 vs HEVC — but for a catalogue sitting in H.264 right now, H.265 is the migration on the table.
H.265 is not a straight upgrade over H.264 — it trades licensing cost, encoding load and device reach for a bitrate saving that is largest exactly where your bill is largest. Run that trade against your own fleet and your own regional delivery pricing, and the answer is usually "both codecs, in the right proportions" rather than one or the other.
That is a solvable problem, and it gets easier every refresh cycle as hardware H.265 decode reaches more of the installed base. If you want a second opinion on where your fleet stands, or help running dual ladders without doubling your operational load, contact us — we will start with the decode audit.
Digital Marketing Specialist
Creates digital campaigns that drive growth. Handles social media, SEO, and content marketing. and turns data into clear insights and results. Sona also helps create valuable evergreen content to deliver high-quality information to inoRain's audience.
Want to learn more about OTT technology and monetization? Leave your best email here, and we'll keep you updated with our weekly articles.
Loading...