Enable x265, take the default preset, and treat the bitrate drop over H.264 as a free playback-quality win — that is where most HEVC migrations stop reasoning. The saving is real, but the interesting question is not whether files shrink. It is which line on your delivery bill the shrinkage actually touches, and whether that line is the one dominating your spend in the first place. HEVC (H.265), encoded through the open-source x265 encoder, typically lands roughly 30–50% lower bitrate than H.264 (x264) at an equivalent perceptual-quality target (an efficiency range widely reported across codec-comparison studies — a published-survey-class figure, not a guarantee for your specific content). That much is well established. What teams overlook is the second-order effect: a lower per-rendition bitrate changes both how many gigabytes you store per title and how many bytes leave the CDN per playback session. Those are two different cost buckets with two different sensitivities, and x265 does not help them equally. What does HEVC x265 do, and what does it mean in practice? x265 is a software HEVC encoder — the H.265 counterpart to x264. It compresses video more aggressively than H.264 by using larger, more flexible coding-tree units, richer intra-prediction modes, and better motion compensation. The practical consequence for a streaming operator is that a rendition encoded to the same visual quality carries fewer bits per second. If you were shipping a 1080p rendition at, say, 5,000 kbps in H.264, an equivalent-quality x265 rendition might sit closer to 3,000–3,500 kbps. That is the mechanism most people understand. The mechanism most people skip is what the bit saving costs you and where it pays back. x265 spends more encode compute to find that compression — often several times the CPU-seconds per frame of x264 at comparable presets — and the resulting stream can only be decoded by clients that support HEVC. So the honest framing is not “x265 is smaller and therefore better.” It is a three-way trade between encode compute, storage-and-egress savings, and decoder reach. Our walkthrough of how H.265 encoding works and what it costs at scale covers the encoder mechanics in depth; this article is about how the bit saving lands on the bill. How much bitrate reduction, and how is it measured? “Equivalent perceptual quality” is doing a lot of work in the 30–50% figure, so it is worth being precise about how the comparison is made. The industry-standard way to hold quality constant while comparing codecs is VMAF (Video Multimethod Assessment Fusion), a perceptual metric that correlates far better with human opinion than raw PSNR. You pick a target VMAF — say 93 for a premium 1080p tier — and find the bitrate each codec needs to hit it. The gap between the H.264 bitrate and the x265 bitrate at that same VMAF is the real, comparable saving. Two things follow from measuring it this way. First, the saving is content-dependent: high-motion sport compresses differently from a static talking-head interview, so a single catalogue-wide percentage is a planning heuristic, not a per-title truth. Second, the saving is preset-dependent — a faster x265 preset gives back some of the efficiency to save encode time. If you want the codec-versus-codec efficiency comparison at a held quality target in more detail, see how HEVC encoders cut bitrate at a held quality target. The number you actually care about is not the percentage. It is the resulting average bitrate per rendition in kbps at your target VMAF, because that number is what propagates into every downstream cost. How does a lower bitrate become S3 and egress cost? This is the step that turns a codec choice into a finance conversation. A rendition’s bitrate drives two independent costs: Storage — bitrate × duration = bytes stored. A 3,000 kbps rendition of a 90-minute title is roughly 2.0 GB; the same title at 5,000 kbps in H.264 is roughly 3.4 GB. Multiply by every rendition in the ladder and every title in the catalogue, then by your S3 cost-per-GB-month. This is a recurring cost that persists whether or not anyone watches. Egress — bitrate × watch-time-seconds = bytes delivered per session. A viewer who streams the full 90-minute title pulls those same ~2.0 GB versus ~3.4 GB through the CDN, priced at your egress cost-per-GB. This is a per-play cost that scales with popularity. Here is the divergence that the naive “x265 is a free win” framing misses entirely. If your S3 bill is dominated by egress — a hit-driven catalogue where a handful of popular titles are streamed millions of times — a 35% bitrate cut is close to a 35% cut on your largest line item, and x265 is an excellent lever. If your bill is dominated by cold-rendition storage — a deep, long-tail library where most renditions sit unwatched — then bitrate reduction saves you on gigabytes you are storing but nobody is pulling, and a storage-lifecycle policy (moving cold renditions to cheaper tiers, or pruning rarely-watched ladder rungs) is the sharper tool. x265, lifecycle policy, and rendition pruning are three different instruments for three different dominant costs. The codec choice only “pays off” relative to which one you are actually paying for. What is the encode-compute premium, and how do presets trade it? The saving is not free. x265 costs materially more encode compute than x264 at a comparable quality target — a difference you feel directly on a per-hour-of-content basis, whether you rent CPU cores or GPU encode capacity. The x265 preset ladder (ultrafast through placebo, with medium as default) is precisely the dial that trades encode time against bitrate efficiency: slower presets search harder and squeeze out more bits, faster presets finish sooner but leave efficiency on the table. Lever What it costs What it saves When it dominates the decision x265 slower preset More encode CPU/GPU-seconds per hour of content Lower bitrate → less storage + less egress High-replay titles where per-play egress swamps one-time encode x265 faster preset Modest encode compute; some efficiency given back Faster time-to-publish, cheaper encode Live or fast-turnaround content, low-replay long tail Lifecycle policy (no re-encode) Engineering time; retrieval latency on cold tiers Storage cost on cold renditions Deep library dominated by unwatched cold storage Rendition pruning Reduced ladder coverage; QoE risk Storage + encode + egress on removed rungs Over-provisioned ladders with rungs nobody selects Evidence class: the cost directions above are observed-pattern from cost-modelling work on streaming catalogues, not a benchmarked per-title rate; your bitrate, VMAF target, and CDN contract set the actual magnitudes. The point of the table is that encode compute is a one-time cost per rendition, while egress recurs per play. For a title streamed millions of times, spending a slower preset’s compute once to shave egress on every play is obviously correct. For a title streamed a hundred times over its life, the slower preset may never earn back its encode premium. The choice of x265 as your encoder — and what that MulticoreWare-maintained encoder means for transcoding cost — sits underneath all of this. When does client-decoder support limit the saving? A bitrate saving you cannot deliver is not a saving. HEVC decoder support is broad on modern devices — recent Apple hardware, most current smart TVs, and many mobile SoCs decode it — but browser and older-device coverage is narrower and more fragmented than H.264, which is effectively universal. If a meaningful slice of your viewers cannot decode HEVC, you cannot retire your H.264 renditions; you end up storing and serving both, which inflates storage rather than reducing it. This is the trap. The storage saving assumes x265 replaces H.264. If it only supplements it for the subset of clients that can decode it, your storage footprint per title goes up, not down, and the egress saving only applies to the HEVC-capable share of sessions. So the decoder-reach question is not a compatibility footnote — it directly gates how much of the modelled saving is real for your specific viewer mix. The right way to size this is to segment your delivery logs by device/browser capability, estimate the HEVC-decodable share of your sessions and bytes, and only credit x265 with the egress it can actually address. A codec that reaches 60% of your bytes delivers, at best, 60% of the modelled egress saving. FAQ How does hevc x265 work? x265 is a software HEVC (H.265) encoder that compresses video more aggressively than H.264 using larger coding-tree units, richer intra-prediction, and better motion compensation. In practice it produces a rendition at the same visual quality carrying fewer bits per second — but at a higher encode-compute cost and with narrower client-decoder support than H.264. How much bitrate reduction does x265 achieve over H.264 at equivalent perceptual quality, and how is that measured? Codec-comparison studies widely report roughly 30–50% lower bitrate at equivalent perceptual quality (a published-survey-class range, not a per-title guarantee). Quality is held constant using VMAF: you pick a target VMAF, find the bitrate each codec needs to reach it, and the gap is the comparable saving. The saving is content- and preset-dependent, so the catalogue-wide percentage is a planning heuristic. How does a lower per-rendition bitrate translate into S3 storage cost and CDN egress cost? Bitrate × duration gives bytes stored (recurring S3 cost per rendition), and bitrate × watch-time gives bytes delivered per session (per-play CDN egress). A ~35% bitrate cut therefore reduces both, but egress savings scale with popularity while storage savings apply to every stored rendition regardless of views — so which one matters depends on your catalogue’s play distribution. What is the encode-compute premium of x265, and how do presets trade encode time against efficiency? x265 costs materially more encode compute than x264 at a comparable quality target. The preset ladder (ultrafast to placebo, default medium) is the dial: slower presets search harder and squeeze out more bits at higher compute cost, faster presets finish sooner but leave efficiency on the table. Encode is a one-time cost per rendition while egress recurs per play, which sets whether a slower preset pays back. When does HEVC’s client-decoder support limit whether you can rely on it for cost savings? When a meaningful share of your viewers cannot decode HEVC, you must keep H.264 renditions alongside the x265 ones — storing and serving both, which raises storage rather than lowering it. The egress saving then applies only to the HEVC-decodable share of sessions, so you should credit x265 only with the bytes it can actually address across your device and browser mix. Given the three S3 cost levers — storage, egress, requests — when is an x265 migration the right lever versus lifecycle policy or rendition pruning? When egress dominates the bill (hit-driven catalogue, high replay), bitrate reduction attacks your largest line item and x265 is the strong lever. When cold-rendition storage dominates (deep long-tail library), lifecycle policy or rendition pruning is sharper, because bitrate reduction only saves on gigabytes nobody is streaming. How do you decide which renditions or catalogue tiers to re-encode in x265 first? Prioritise by egress exposure: re-encode the highest-replay titles and their most-selected ladder rungs first, since egress recurs per play and those renditions earn back the one-time encode premium fastest. Cold, rarely-selected renditions in the long tail are lower priority for re-encode and are often better handled by lifecycle or pruning. Where this lands x265 is not a free win and it is not a trap — it is a compute-versus-storage-versus-egress trade whose payoff is set entirely by which S3 lever dominates your catalogue and how much of your viewer base can decode HEVC. Model the per-rendition bitrate at your target VMAF, push it through your storage and egress costs, subtract the encode-compute premium and the decoder-reach discount, and the codec decision becomes arithmetic rather than faith. That arithmetic is exactly the encoding-side lever of a broader cost-per-stream picture, which we treat as a candidate action inside an [inference-cost-cut sprint](Inference Cost-Cut Pack) — evaluated only after the audit identifies egress or storage as the dominant cost, the same inference-cost-audit methodology that attributes encode compute against downstream savings. If broadcast delivery economics are the problem you are sitting on, our media and telecom broadcast work starts from the same question this article does: which line on the bill are you actually trying to move?
