Enabling HEVC in a transcoding pipeline is not the same as getting HEVC’s bitrate savings. In most real pipelines the thing you actually turn on is x265 — the open-source encoder that MulticoreWare builds and maintains — and what x265 delivers depends entirely on how you configure it. Flip the switch with default settings and you might see a modest bitrate reduction. Configure it to realise HEVC’s full coding gain and the same clip can cost roughly an order of magnitude more encoder compute. That gap is the whole story, and it is why naming the encoder correctly matters more than most teams expect. The common assumption goes like this: HEVC (H.265) is a codec standard that saves about half the bitrate of H.264 at the same quality, so switching the pipeline to HEVC gives us that saving automatically. The codec standard does define the tools that make those savings possible — larger coding tree units, more prediction modes, better entropy coding. But a standard is a specification for a decoder. It says nothing about how hard the encoder has to work to find the good decisions. That work is where the cost lives, and it is entirely the encoder implementation’s problem. Who MulticoreWare is, and why the distinction matters MulticoreWare is the software company that leads development of x265, the dominant open-source HEVC encoder. When an FFmpeg-based pipeline “switches to HEVC,” it is almost always calling libx265 under the hood. So there are three separate things people routinely conflate: HEVC / H.265 — the codec standard, defining what a compliant bitstream looks like. x265 — a specific encoder implementation that produces HEVC-compliant bitstreams, developed by MulticoreWare. MulticoreWare — the company that engineers x265 (and other encoders, including VVC work). This is not pedantry. The distinction changes which knobs you tune to move cost-per-stream. You do not tune “HEVC” — the standard has no dial for compute. You tune x265: its preset, its rate-control mode, its psychovisual and analysis flags. We cover the company and its wider encoder portfolio in MulticoreWare Explained: x265, HEVC/VVC encoders and what they mean for streaming; this article is about the one decision that dominates the bill. How do x265 presets trade compute against bitrate efficiency? x265 exposes a single headline control — preset — that ranges from ultrafast through superfast, veryfast, faster, fast, medium, slow, slower, veryslow, up to placebo. The preset is not a quality dial in the usual sense. At a fixed quality target, a slower preset spends more compute searching for encoding decisions that let it reach that quality at a lower bitrate. Faster presets give up on that search and settle for a higher bitrate to hit the same quality. So the three quantities move together: hold quality fixed, and the preset trades encode compute against output bitrate. That is the coupling that breaks the naive “HEVC saves half the bits” expectation. HEVC’s headline efficiency is only realised at the slower presets that actually run the exhaustive rate-distortion search. Run ultrafast to keep your encoder farm cheap and you leave much of the coding gain on the table — you have paid for HEVC decode complexity downstream without collecting the bandwidth saving upstream. The practical decision is not “HEVC yes/no.” It is: which point on the x265 compute-versus-bitrate curve is right for this catalogue, given how many times each title will be streamed? x265 preset trade-off at a fixed quality target The table below is a decision rubric, not a benchmark. The relative directions are structural to how x265’s search works; the exact magnitudes depend on content, resolution, and your quality metric, and should be measured on your own material (observed pattern across encoding engagements — not a published benchmark). Preset band Encode compute per title Bitrate at matched VMAF Best fit ultrafast–veryfast Lowest Highest (weakest coding gain) Live / latency-bound, low-replay content fast–medium Moderate Moderate General VOD, balanced farms slow–slower High Low (strong coding gain) High-replay catalogue titles veryslow–placebo Highest (often diminishing returns) Lowest, with shrinking marginal gain Rarely worth it outside archival masters The important read: moving from medium to veryslow can multiply encode time several-fold while the bitrate improvement narrows sharply near the slow end. placebo is almost never economically justified — the marginal bits saved cost far more compute than they are worth. The sweet spot for most VOD catalogues sits in the slow/slower band for high-replay titles only, because the bandwidth saving is amortised across every playback. Which x265 options most affect cost-per-stream? Preset is the coarse control. Underneath it, three families of settings move the economics, and they interact with the preset rather than replacing it. Rate-control mode. x265 offers constant rate factor (--crf), two-pass average bitrate (--pass 1/2 --bitrate), and constant quantiser (--qp). CRF is quality-targeted and single-pass, which makes it cheap and predictable for per-title work. Two-pass ABR gives you a bitrate ceiling — necessary when a CDN contract or ABR ladder rung caps the stream — at the cost of a full analysis pass. Choosing CRF where a hard cap is not required removes an entire encode pass from every title. Tuning and analysis flags. --tune (for psnr, ssim, or grain), psychovisual rate-distortion (--psy-rd), and analysis-reuse options change both quality-per-bit and search cost. Grain-heavy source content in particular is expensive to encode well, and the wrong tune setting either wastes bits or smears detail. Where it runs. x265 is a CPU encoder. Its compute lands on cores, and its cost scales with how much of the rate-distortion search you enable via the preset. That is a different economic model from a hardware HEVC encoder (NVENC, Quick Sync, AMF), which we return to below. For the software side of that choice, H.265 encoder software: how HEVC encoders work in transcoding pipelines walks through the CPU-encode path in more detail. How do we benchmark x265 configurations before committing a catalogue? The failure we see most often is committing a whole catalogue to a preset chosen on intuition, then discovering the encoder farm bill or the bitrate savings landed nowhere near the plan. The fix is to measure the curve on your own content before you commit, not after. A workable method: Pick a representative sample. Not one clip — a handful spanning your hardest cases: high-motion sport, film grain, animation, dark scenes. Content type moves the curve more than most people expect. Fix a quality target, not a bitrate. Encode each sample across a preset sweep (veryfast, medium, slow, veryslow) at matched quality — VMAF is the standard perceptual metric here; PSNR and SSIM are cheaper proxies. Match on the metric, then read off the resulting bitrate and encode time. Record both axes. For each preset, log encode wall-clock and CPU utilisation and the bitrate needed to hit the quality target. Now you have the compute-versus-bitrate trade curve for your material. Weight by replay. Multiply the per-title bandwidth saving by expected streams-per-title. A title streamed a million times justifies a slow preset; a long-tail title streamed a hundred times does not. This turns “which preset?” from an argument into a spreadsheet. The bandwidth saving is a one-time encode cost against a recurring delivery saving, and the crossover point is specific to each catalogue tier. That framing — measure the encode cost rather than assume it — is exactly what a [streaming-transcoding cost sprint](Inference Cost-Cut Pack) is built to produce. When does hardware HEVC make more sense than software x265? Software x265 wins on coding efficiency — its slow presets reach bitrates hardware encoders generally cannot match at the same quality. Hardware encoders win on throughput-per-watt and latency. The decision hinges on the workload shape. Live and latency-bound — hardware HEVC (NVENC and equivalents) almost always wins. You cannot afford a slow x265 preset in a real-time path, and hardware delivers many parallel streams at fixed, predictable cost. High-value, high-replay VOD — software x265 at a slow preset often wins, because the one-time encode compute is amortised across millions of streams and the bitrate saving is real money on CDN egress. Long-tail VOD — usually hardware or a fast x265 preset; the replay count does not justify slow-preset compute. We unpack the hardware side in H.265 encoder hardware: how hardware HEVC encoding works and when it pays off. The broader point is that the encoder-implementation choice is downstream of the codec-bottleneck decision described in how codec choice becomes the bottleneck in AI video pipelines — and it plays out concretely across the media and telecom broadcast pipelines we work on. FAQ What matters most about MulticoreWare in practice? MulticoreWare is a software engineering company that leads development of x265, the dominant open-source HEVC encoder. In practice, when a transcoding pipeline “switches to HEVC” through FFmpeg, it is usually running MulticoreWare’s libx265. What that means operationally is that your HEVC results are governed by x265’s configuration — preset, rate control, tuning flags — not by the codec standard alone. What is x265 and how does it relate to the HEVC/H.265 standard versus MulticoreWare the company? Three distinct things get conflated: HEVC/H.265 is the codec standard defining a compliant bitstream; x265 is a specific encoder implementation that produces HEVC-compliant output; MulticoreWare is the company that engineers x265. The standard specifies what a decoder must accept, but says nothing about how hard the encoder works to find good decisions — that cost lives entirely in the x265 implementation. How do x265 presets trade encode compute against bitrate efficiency at a fixed quality target? At a fixed quality target, a slower preset spends more compute searching for encoding decisions that reach that quality at a lower bitrate, while faster presets settle for a higher bitrate. Holding quality fixed, the preset trades encode compute against output bitrate. HEVC’s headline efficiency is only realised at the slower presets, so running ultrafast leaves much of the coding gain unclaimed. Which x265 rate-control and tuning options most affect cost-per-stream in a transcoding pipeline? Rate-control mode matters most: CRF is cheap and quality-targeted single-pass, while two-pass ABR adds a full analysis pass to enforce a bitrate ceiling. Tuning and analysis flags such as --tune, --psy-rd, and analysis reuse change both quality-per-bit and search cost. Because x265 is a CPU encoder, its compute scales with how much rate-distortion search the preset enables. How do we benchmark x265 configurations against a quality metric like VMAF before committing a catalogue? Pick a representative content sample spanning your hardest cases, fix a quality target (VMAF is the standard perceptual metric), then encode a preset sweep at matched quality and record both encode time/CPU utilisation and the bitrate needed to hit the target. That gives you the compute-versus-bitrate curve for your own material. Weight the per-title saving by expected streams-per-title to find the crossover point. When does a hardware HEVC encoder make more sense than software x265 for a given workload? Hardware HEVC (NVENC and equivalents) wins on live, latency-bound, and long-tail workloads where throughput-per-watt and predictable cost matter more than squeezing the last bits. Software x265 at a slow preset wins on high-value, high-replay VOD, because the one-time encode compute is amortised across millions of streams and the bitrate saving is real CDN egress money. Where the cost actually gets decided The codec win and the encoder configuration are inseparable. You do not save bandwidth by enabling HEVC; you save it by choosing where on x265’s compute-versus-bitrate curve each catalogue tier belongs, and by measuring that curve on your own content instead of assuming it. The failure class to watch for is a catalogue committed to a preset chosen by intuition — the encode bill or the bandwidth saving lands nowhere near plan, and by then the compute is spent. When cost-per-stream is the question, the honest move is to benchmark the x265 configuration against your quality target before the catalogue is locked, not after the invoice arrives.
