“We’ll switch the catalogue to HEVC and the bitrate savings drop straight to the bottom line.” That sentence sounds right, and it is the most expensive assumption in a codec migration. H.265/HEVC does roughly halve the bitrate of H.264 at comparable quality — that part holds up in published comparisons. But bitrate reduction is a delivery-side number. Cost-per-stream is what you actually pay, and it lives on both sides of the ledger: the encode compute you spend making the file, and the decode support across the devices that have to play it back. HEVC’s savings only reach the bottom line when both of those are accounted for. This is an explanation article, not a sales pitch for a codec. The goal is to make the encoder legible — what it is doing when it produces a smaller file, why that work costs more, and how the device population you are serving decides whether the trade lands in your favour or against it. How does encoder H.265 work in practice? At the level that matters for cost, an H.265 encoder is doing the same job as an H.264 encoder — throwing away redundancy in space and time — but with more tools and larger units to work with. The single biggest structural change is the coding unit. Where H.264 tops out at 16×16 macroblocks, HEVC uses coding tree units up to 64×64, recursively split into a quadtree of smaller coding units. Large flat regions — sky, a studio backdrop, a static graphic — get encoded as one big block instead of dozens of small ones. That is a large share of where the bitrate goes. The second lever is prediction. HEVC has 33 angular intra-prediction directions versus H.264’s 8, and its motion compensation uses more reference options and finer sub-pixel interpolation. Better prediction means the residual — the difference the encoder actually has to store — is smaller. The deblocking filter is joined by a sample-adaptive offset stage that cleans up artefacts the transform introduces. None of this is free. Every one of those tools is a decision the encoder has to make per block: which CTU split, which prediction mode, which motion vector. A rate-distortion optimised encoder evaluates a large search space to pick the combination that minimises bits for a target quality. That search is the compute cost. It is why a slow HEVC preset can take several times longer per frame than an equivalent H.264 encode. The smaller file is bought with encode-side CPU or GPU cycles — the encoder is spending your compute to save the network’s bandwidth. Where does the bitrate saving actually come from versus H.264? It helps to separate the codec from the encoder. The codec (the HEVC standard) defines the toolset — CTUs, prediction modes, SAO. The encoder (x265, NVENC, a hardware ASIC) decides how hard to search that toolset. Two HEVC encodes of the same clip at the same bitrate can differ substantially in quality because one searched harder. This is why “HEVC saves 50%” is a statement about the standard’s ceiling, not a promise any given encoder run will hit. The commonly cited figure — roughly half the bitrate of H.264 at matched quality — traces to the codec-comparison literature, most prominently a widely-referenced study by the JCT-VC group and follow-on academic work (published-survey class; the exact number depends on content, resolution, and quality metric). In practice we see the gap widen at 4K and HDR, where the larger coding units and better prediction have more redundancy to exploit, and narrow on low-resolution or high-motion content where the tools have less to bite on. That content dependence is the first reason a blanket “re-encode everything to HEVC” rarely delivers the headline number uniformly across a catalogue. If you want the encoder-mechanics layer in more depth — presets, rate control, and where the search cost concentrates — the open-source reference implementation is a good anchor, and we cover it in what x265 is and its cost trade-offs. For how bitrate reduction converts into a held quality target rather than a raw percentage, see how HEVC encoders cut bitrate at a held quality target. When does moving to HEVC actually reduce cost-per-stream? Here is the reframe. Bitrate savings are a gross number. Cost-per-stream is the net after two adjustments: Encode overhead — the additional compute per title to run HEVC’s larger search, amortised over how many times that title is streamed. Compatibility fallback — every device that can’t decode HEVC in hardware still needs an H.264 rendition, which means you may be storing and serving both, not replacing one with the other. The savings survive when a title is streamed enough times that the one-time encode cost is trivial per view, and when a large enough share of your audience decodes HEVC in hardware that the delivery reduction is real for most streams. They evaporate on the wrong end of both axes: a long-tail title watched a few hundred times, encoded on a slow preset, delivered to a device mix that mostly falls back to H.264 anyway. Decision table: does the HEVC trade land? Condition Favours HEVC Cancels the win Views per title High (popular catalogue, live events at scale) Low (long-tail, archival) Resolution / dynamic range 4K, HDR, high-fidelity content SD / low-bitrate content Device decode support Majority hardware-decode HEVC Broad old-device or browser mix on H.264 Encode farm GPU-accelerated or well-profiled fleet Under-profiled CPU farm on slow presets Rendition strategy HEVC replaces H.264 for most streams Must ship both HEVC and H.264 in parallel Evidence class: observed-pattern across media-transcoding engagements; the specific break-even depends on your view distribution and device telemetry, not a published benchmark. The pattern we see repeatedly: the codec decision that looks like a codec decision is really an economics decision, and the numbers that decide it are your view distribution and your device telemetry — not the codec spec sheet. How do device-class decode support and hardware acceleration change the calculus? Decode is the quiet half of the equation. A stream is only cheaper if the receiving device can play it efficiently. HEVC decode in hardware has been standard on most mobile SoCs, smart TVs, and recent GPUs for years, but coverage is not universal — some browser and older-device combinations either lack HEVC decode or gate it behind licensing that vendors declined to ship. Where hardware decode is absent, the device either falls back to software decode (battery and thermal cost, poor experience) or to your H.264 rendition (no delivery saving on that stream). This is why the honest first step is not “encode a HEVC ladder” but “pull the device telemetry.” What fraction of your actual streams terminate on a hardware-HEVC-capable device? That number, not the codec’s theoretical efficiency, sets the ceiling on your realisable saving. The encode-hardware side of the same question — when a dedicated HEVC ASIC or NVENC block pays off versus CPU encoding — is covered in how hardware HEVC encoding works and when it pays off. How do we measure HEVC quality against H.264 rather than assuming equivalence? “Comparable quality” is doing a lot of work in the 50% claim, and it is where teams get burned. Matching bitrate is not matching quality; matching quality is not matching bitrate. You have to fix one and measure the other. The industry-standard approach is to encode both codecs across a bitrate ladder and score each rendition with a perceptual metric — VMAF is the common choice — then compare the bitrate needed to hit the same VMAF score. That gives you a defensible “HEVC needs X% fewer bits for the same perceived quality on this content.” Do this per content class, not once. Animation, sports, film grain, and screen content behave differently. And do it against the device classes that will actually render the stream, because decode-side post-processing differs. Assuming equivalence across your whole catalogue from one test clip is how a migration ships worse quality on the content that mattered most. What role does GPU-accelerated encoding play in making HEVC economical? The encode-side compute is the cost that most surprises teams, and it is where GPU acceleration changes the shape of the problem. A fixed-function encoder block — NVIDIA’s NVENC, for example — runs HEVC encode at a small fraction of the power and wall-clock time of a high-quality CPU (x265) encode, at the cost of some compression efficiency. That is a genuine trade, not a free lunch: hardware encoders are faster and cheaper per title but typically need a slightly higher bitrate to match a slow CPU preset’s quality. For a large transcoding fleet, the fleet-level question is which titles justify the slow, high-quality CPU encode (popular, streamed millions of times, where every saved bit compounds) and which are fine on fast hardware encode (long-tail, where encode cost dominates and delivery savings are marginal). Mixing both, driven by view-count telemetry, is usually cheaper than a single policy. This is precisely the kind of profiling a [video-transcoding cost sprint](Inference Cost-Cut Pack) exists to do before a re-encode is committed. The software-encoder side of that decision is unpacked in how HEVC encoders work in transcoding pipelines, and the broader picture of how the codec choice becomes the pipeline bottleneck sits in our broadcast codec-bottleneck analysis. FAQ What’s worth understanding about encoder H.265 first? An H.265 encoder removes spatial and temporal redundancy using larger coding tree units (up to 64×64), more prediction directions, and finer motion compensation than H.264. In practice it produces a smaller file for the same quality, but it spends significantly more encode-time compute searching for the best per-block coding decisions — the smaller file is bought with encoder CPU or GPU cycles. How does H.265/HEVC differ from H.264, and where does the bitrate saving actually come from? HEVC extends H.264’s toolset: bigger coding units, 33 intra-prediction angles versus 8, better motion compensation, and an added sample-adaptive offset stage. The saving comes from spending more compute to shrink the residual the encoder must store. Published codec comparisons place it at roughly half the bitrate of H.264 at matched quality, but the gap widens on 4K/HDR and narrows on low-resolution or high-motion content. When does moving to HEVC reduce cost-per-stream, and when does the added encode compute cancel the delivery savings? It reduces cost-per-stream when titles are streamed enough that the one-time encode cost is trivial per view, and when most of your audience decodes HEVC in hardware. It cancels out on long-tail titles encoded on slow presets, on low-resolution content, or on device mixes that mostly fall back to H.264 — where you pay the encode overhead and still ship both renditions. How do device-class decode support and hardware acceleration affect whether HEVC is worth deploying? A stream is only cheaper if the device can decode it efficiently. Hardware HEVC decode is common on modern mobile, TV, and GPU silicon but not universal — some browser and older-device combinations lack it. The fraction of your streams that terminate on hardware-HEVC-capable devices, taken from telemetry, sets the ceiling on your realisable saving. How do we measure HEVC quality against H.264 across device classes rather than assuming equivalence? Fix one variable and measure the other: encode both codecs across a bitrate ladder, score each rendition with a perceptual metric like VMAF, and compare the bitrate needed to hit the same score. Do this per content class and against the device classes that will render the stream, because behaviour differs across animation, sports, grain, and screen content. What role does GPU-accelerated encoding play in making HEVC economical on a transcoding fleet? Fixed-function encoders like NVENC run HEVC encode far faster and cheaper per title than a high-quality CPU (x265) encode, at a small cost in compression efficiency. On a fleet, the economical policy usually mixes both — slow high-quality CPU encodes for popular titles where every bit compounds, fast hardware encodes for long-tail content — driven by view-count telemetry. Does switching to HEVC always reduce quality or cost, or is it content- and device-mix dependent? It is content- and device-mix dependent. HEVC can reduce cost and hold quality when content is high-resolution, titles are popular, and devices decode in hardware; it can add cost without a real saving on low-resolution long-tail content served to an H.264-heavy device mix. The codec spec sheet does not decide the outcome — your view distribution and device telemetry do. The uncomfortable conclusion is that “should we move to HEVC?” is not answerable from the codec’s efficiency number alone. It is answerable from two datasets you already own: how your views are distributed across titles, and what your audience’s devices can decode. Profile those against your broadcast transcoding economics before you re-encode, and the codec question resolves into an arithmetic one — where the bitrate saving survives the encode cost and the decode mix, and where it quietly does not.
