Ask a broadcast engineer what x265 does and the answer is usually “it gives you HEVC’s bitrate savings.” That is half true, and the half that gets left out is the half that decides your bill. x265 is an encoder, not a codec, and it exposes a preset ladder that trades encode time against compression efficiency. The realised saving over H.264 is not a fixed number that arrives when you drop x265 into the pipeline — it is a function of which preset you can actually afford at your throughput. That distinction matters because teams routinely treat “use x265” as synonymous with “get HEVC’s roughly 40–50% bitrate reduction for free.” The reduction is real, but it is the ceiling the standard permits, not the floor the encoder guarantees at a middle preset running fast. Miss that, and you either overspend on compute chasing a saving your CDN egress does not justify, or you under-encode and leave bandwidth savings on the table. What is x265, exactly? x265 is an open-source software library that encodes video into the HEVC / H.265 format. It is developed primarily by MulticoreWare and licensed under GPL (with a commercial license available), and it has become the most widely deployed open-source software encoder for HEVC. If you have run ffmpeg -c:v libx265, you have used it. The word “encoder” is the load-bearing one. HEVC / H.265 is the standard — a specification, published by ITU-T and ISO/IEC, that defines the bitstream a compliant decoder must be able to read. It says nothing about how you produce that bitstream. x265 is one implementation of an encoder that emits a compliant HEVC stream. A hardware block in an NVIDIA GPU (NVENC) is another. They target the same standard and produce interoperable output, but they make very different quality-versus-speed trade-offs. We cover that boundary in more depth in our explainer on how HEVC encoding works and what it costs at scale. So the first correction is simple: x265 is not “HEVC.” It is a set of levers that produce HEVC. The levers are where the money is. How does x265 relate to HEVC — codec or encoder? Think of it as a three-layer stack. The codec (HEVC / H.265) is the format contract. The encoder (x265, or NVENC, or Intel Quick Sync’s HEVC path) is the software or silicon that compresses your source into that format. The decoder is whatever plays it back — a browser, a set-top box, a phone SoC. A stream encoded by x265 and a stream encoded by NVENC are both valid HEVC and both decode identically on the same client; what differs is how many bits each encoder needed to reach a given perceptual quality, and how long it took to get there. This is why “does my device support HEVC” and “which HEVC encoder should I use” are unrelated questions. Client support is a property of the codec. Cost-per-stream is a property of the encoder configuration. The relationship between MulticoreWare’s tooling and the wider HEVC/VVC encoder landscape is worth reading if you are choosing between builds — see what the MulticoreWare and x265 encoder choice means for transcoding cost. What do x265’s presets actually trade off? x265 ships a preset ladder running from ultrafast through superfast, veryfast, faster, fast, medium (the default), slow, slower, veryslow, and placebo. Each preset is a bundle of internal settings — motion-search range, the set of coding-unit partition sizes the encoder will evaluate, rate-distortion optimisation depth, reference-frame count, and so on. The trade-off is compression efficiency against encode time. Slower presets let the encoder search a larger space of coding decisions, so they find cheaper ways to represent the same picture — fewer bits at matched quality. Faster presets skip most of that search to hit throughput. Here is the part that surprises people: the return is steeply diminishing. Moving from ultrafast to medium buys a large efficiency gain. Moving from medium to veryslow buys a much smaller one — often a single-digit percentage of extra bitrate saving — while the encode time can grow by an order of magnitude. placebo exists mostly to prove the point; it is rarely worth it in production. x265 preset ladder: what each tier trades Preset Relative encode time Compression gain vs. medium Typical use ultrafast / superfast Fastest Worst (larger files) Live / low-latency, throughput-bound veryfast / faster Fast Below medium High-volume real-time transcode medium (default) Baseline Baseline General VOD default slow / slower Several× slower Modest gain Quality-sensitive VOD veryslow ~10× slower than medium Small single-digit % gain Premium catalogue, offline placebo Extreme Negligible over veryslow Benchmarking curiosity Directionality is a well-established property of the x265 ladder; exact ratios depend on content, resolution, and rate-control mode, so treat the “relative” columns as illustrative rather than a benchmark for your titles. How much cost does each preset add, and does the saving offset it? This is the question that turns x265 from a checkbox into an engineering decision. Two numbers are in tension: Compute cost — CPU-hours (x265 is a CPU encoder) or, if you route to a hardware path, GPU-hours per title. Slower presets multiply this. Bandwidth-egress cost — what you pay every time a smaller file is delivered. A better preset shrinks the file once and saves egress on every view. The economics hinge on how many times a title is viewed. A piece of long-tail catalogue watched a handful of times cannot amortise a veryslow encode; the extra CPU-hours dwarf the egress it saves. A hero title streamed millions of times can justify a very expensive encode, because the per-title compute cost is fixed while the egress saving scales with views. That is the crux of the whole decision: the right x265 preset is the one where the marginal compute you spend on a slower encode is repaid by the marginal egress you save across the title’s actual viewership. For an unwatched title, that point sits near medium or faster. For a mega-hit, it can sit at veryslow. Picking one preset for the whole library ignores this and is almost always wrong at the extremes. For the streaming-specific version of this bitrate-and-storage argument, our piece on how HEVC x265 cuts bitrate and storage cost for streaming works through the delivery-side numbers. How do tune and rate-control settings affect quality at matched bitrate? Preset is not the only lever. x265’s tune options and rate-control mode shape what kind of quality you get for a given bitrate. By default x265 optimises for PSNR-style fidelity, but tune ssim biases toward structural similarity, and there are tunings intended to preserve perceptual detail (film grain, for example) that a pure fidelity metric would happily smooth away. The catch is that these choices change which quality metric flatters your output. An encode that scores well on PSNR can look worse to a human eye than one tuned for perceptual quality at the same bitrate — which is why teams increasingly evaluate with VMAF rather than PSNR alone. Rate control is the other half. Constant Rate Factor (CRF) targets a quality level and lets bitrate float; two-pass average-bitrate (ABR) or capped-CRF targets a bit budget. For adaptive-streaming ladders the rate-control choice interacts with your per-rung bitrate caps, and getting it wrong produces either overspend or visible quality cliffs at the low rungs. None of this is visible if you benchmark a single clip at a single setting — it only shows up across a representative content set. When should I use x265 versus hardware HEVC or AV1? There is no universal answer, which is exactly why this is a decision rather than a default. The variables that actually move it: x265 vs. hardware HEVC vs. AV1: what decides it Factor Favours x265 (software HEVC) Favours hardware HEVC (NVENC / Quick Sync) Favours AV1 Latency requirement Offline / VOD Real-time, live Depends on encoder maturity Throughput per box Lower (CPU-bound) Very high (dedicated silicon) Lower (compute-heavy) Compression at matched quality Best of the HEVC options Below x265 slow presets Best of the three, but costliest Compute cost per title High at slow presets Low Highest Client decode support Broad Broad Narrower, growing Licensing / royalty posture HEVC royalties apply HEVC royalties apply Royalty-free The short version: x265 wins when you can afford CPU time and want the best HEVC quality-per-bit, especially for high-view catalogue titles encoded offline. Hardware HEVC wins when throughput or latency dominate — live channels, high-volume real-time transcode. AV1 wins on pure compression and licensing posture but costs the most compute and reaches fewer old clients today. If VVC is on your roadmap, our x266 / VVC explainer covers where the next-generation codec fits. This is observed-pattern framing drawn from transcoding work, not a single benchmark — your content and viewership will shift the boundaries. How do I measure whether an x265 config improved cost-per-stream? You cannot reason about this from specs; you have to profile against your workload. The measurement loop that actually answers the question: Fix a quality target. Pick a VMAF (or PSNR/SSIM) score you consider acceptable at each ladder rung, and hold it. Comparing bitrate at unmatched quality is meaningless. Encode a representative content set — not one clip — across the candidate presets, tunes, and rate-control modes. Record two costs per configuration: bitrate (or file size) at the matched quality target, and encode wall-clock plus CPU/GPU-hours per title. Model egress against viewership. Multiply the per-view file-size delta by expected views to get the bandwidth saving, and charge the encode compute against it. Pick the preset where the net is positive for that title tier — and re-check it when your content mix, viewership distribution, or cloud pricing changes. That last point is the whole thesis restated: the encoder is a set of levers, and the payoff only holds when the configuration is profiled against your workload rather than assumed. A streaming-transcoding sprint from our [inference and transcoding cost-cut pack](Inference Cost-Cut Pack) does exactly this — profiles which x265 preset and tune minimise cost-per-stream for your titles and throughput, instead of accepting a default and hoping the HEVC saving showed up. FAQ What is x265? x265 is an open-source software library, developed primarily by MulticoreWare, that encodes video into the HEVC / H.265 format. It is the most widely deployed open-source software encoder for HEVC and is what runs behind ffmpeg -c:v libx265. How does x265 relate to HEVC/H.265 — is it the codec or the encoder? x265 is the encoder, not the codec. HEVC / H.265 is the standard that defines a compliant bitstream; x265 is one implementation that produces such a stream. Hardware encoders like NVENC target the same standard, so their output decodes identically on the same client — what differs is bits-per-quality and encode time. What do x265’s presets (ultrafast to placebo) actually trade off, and how do I pick one? Presets trade compression efficiency against encode time. Slower presets search a larger space of coding decisions and find cheaper representations, but the return diminishes steeply — moving from medium to veryslow often buys a single-digit percentage of extra saving for roughly ten times the encode time. Pick the slowest preset your throughput and per-title economics can actually afford. How much encode time and CPU/GPU cost does each x265 preset add, and does the bitrate saving offset it? Slower presets multiply CPU-hours per title, so the offset depends on viewership. A title watched a few times cannot amortise a veryslow encode; a hero title streamed millions of times can, because compute cost is fixed per title while egress saving scales with views. The right preset is where marginal compute is repaid by marginal egress saved. How do x265 tune and rate-control settings affect quality-of-experience at matched bitrate? tune options bias the encoder toward different quality definitions (fidelity, structural similarity, perceptual detail), which changes what a given bitrate looks like — an encode that scores well on PSNR can look worse than a perceptually tuned one at the same bitrate, which is why VMAF is increasingly used. Rate-control mode (CRF, two-pass ABR, capped-CRF) governs how bits are budgeted and interacts with your adaptive-streaming ladder rungs. When should I use x265 versus a hardware HEVC encoder or an alternative like AV1? Use x265 when you can afford CPU time and want the best HEVC quality-per-bit, typically for high-view catalogue encoded offline. Hardware HEVC (NVENC, Quick Sync) wins when latency or throughput dominate, such as live channels. AV1 offers the best compression and a royalty-free posture but costs the most compute and reaches fewer legacy clients today. How do I measure whether an x265 configuration improved cost-per-stream without degrading quality? Fix a VMAF/PSNR quality target, encode a representative content set across candidate configurations, and record both the bitrate at matched quality and the encode CPU/GPU-hours per title. Model egress savings against expected viewership, charge the encode compute against it, and pick the configuration where the net is positive — then re-check when content mix or pricing shifts. Treat x265 the way you would any other configurable cost surface: the default preset is a starting hypothesis, not an answer. The question worth carrying out of this is not “should we use x265” but “for which slice of our catalogue does each rung of the preset ladder actually net out positive once compute is charged against egress” — and that is a number you measure, not one you inherit from the codec’s headline claim.
