Someone reads that a media pipeline runs on GPUs and concludes the encoder should too. x265 is the open-source HEVC (H.265) encoder, and it is one of the clearest cases where that assumption quietly wastes money. The encode stage looks like just another compute-hungry box in the pipeline diagram, so it gets folded into a fleet-wide “put it on the GPU” decision — and returns almost nothing for the GPU hours it consumes. The correct read is narrower and more useful. x265 is a CPU-bound workload. Its quality-per-bit advantage comes from rate-distortion optimisation that the encoder runs on the CPU, and that work does not map cleanly onto the same accelerators that carry the inference stages of content analysis. Profile the encode as its own workload with its own compute economics, and it stays on the CPU tier its cost structure justifies. Fold it into a GPU assumption, and you have paid accelerator prices for CPU work. What does the x265 HEVC encoder actually do? x265 implements the HEVC (H.265) video coding standard in software. Its job is to take raw or lightly compressed frames and produce a compliant HEVC bitstream that hits a target quality at the lowest bitrate it can manage within a compute budget. The standard defines the decoder’s obligations — what a valid bitstream looks like and how to reconstruct frames from it. It says almost nothing about how an encoder should decide which of the many legal encoding choices to make. That decision space is where the encoder earns its keep. For any block of pixels, an HEVC encoder can choose among many partitioning schemes, prediction modes, and transform options. Each choice produces a slightly different bitstream cost and a slightly different reconstructed-frame quality. x265 searches that space and picks combinations that minimise a joint cost of distortion and bitrate — the core of rate-distortion optimisation. The more of that search space it explores, the better the quality-per-bit it achieves, and the more CPU cycles it burns. That trade is the whole story of the encoder’s compute profile. This is a workload of branch-heavy, data-dependent search — not the wide, regular tensor arithmetic that GPUs accelerate well. Two of the citable points worth carrying out of this article: The quality advantage of x265 comes from CPU-side rate-distortion search, not from any operation that a GPU would run faster (observed pattern across the transcoding pipelines we profile; not a benchmarked speedup figure). Encode compute and content-analysis inference compute are distinct workload classes with distinct hardware economics, and treating them as one line item is the root of the misallocation. If you want the codec-level walkthrough of how HEVC cuts bitrate at a held quality target, the HEVC encoders explainer on bitrate reduction covers the coding-tool mechanics in more depth than we do here. Why is x265 CPU-bound rather than GPU-accelerated? The instinct to reach for a GPU is reasonable in isolation — video is data-parallel, and GPUs are good at data-parallel work. The instinct fails on x265 specifically because the expensive part of software HEVC encoding is not the arithmetic. It is the mode-decision search: a tree of dependent choices where the best option for one block depends on decisions already made for neighbouring blocks. That data dependency and branching is exactly the pattern GPUs handle poorly and CPUs handle well. This is why hardware HEVC — the fixed-function NVENC-style encoders on many GPUs and SoCs — is a different animal from x265. Hardware encoders do not run the same exhaustive rate-distortion search; they run a fixed, silicon-baked pipeline that is fast and power-efficient but explores far less of the decision space. That is a deliberate trade, and it is why the two paths land at different points on the quality-per-bit-per-watt curve. We unpack when the fixed-function path wins in how hardware HEVC encoding works and when it pays off. So when x265 shows up on a GPU-heavy fleet and someone asks “shouldn’t this be on the GPU?”, the honest answer is: only if you are willing to switch to the hardware encoder and accept its quality-per-bit profile. Running the software x265 encoder itself on GPU capacity does not make it a GPU workload — it makes it a CPU workload occupying an expensive seat. This is the same underutilisation pattern we describe in [why GPU capacity sits idle when workloads are mis-scoped](GPU engineering): the accelerator is present but the work does not use what makes it fast. How x265 encoding differs from content-analysis inference A media pipeline that does content recognition or moderation has two very different compute stages that get blurred together in budgeting. Naming the difference is what protects the GPU tier. Dimension x265 HEVC encode Content-analysis inference Core operation Rate-distortion mode-decision search Dense tensor math (convolutions, attention) Compute pattern Branchy, data-dependent, sequential deps Wide, regular, parallel Best hardware Multi-core CPU (software) or fixed-function ASIC GPU / accelerator What scales cost Preset depth × resolution × frame rate Model size × frames analysed × batch Quality lever Preset and rate-control settings Model accuracy and confidence thresholds Runs well on GPU? No (software x265) Yes The decode path deserves a note here too, because content analysis has to get frames before it can analyse them, and decode economics differ again from both encode and inference. The decode-path cost of object detection in video walks through why the frame-extraction stage is its own budget line. The point that ties the whole pipeline together: three distinct workload classes — decode, analysis inference, and encode — each want a different hardware tier, and the failure mode is pretending they are one. What do x265 presets and rate-control settings trade off? x265 exposes its compute-versus-quality trade through presets (from ultrafast to placebo) and through rate-control modes (constant rate factor, two-pass bitrate targeting, and constant quantiser among them). A slower preset tells the encoder to explore more of the rate-distortion search space per frame — better quality-per-bit, higher CPU cost, lower throughput. A faster preset does the opposite. Rate-control chooses how the quality budget is spent across the stream rather than how hard the encoder searches. The practical consequence for pipeline economics: preset selection is a throughput-per-core dial, and it is the main lever on how many encode streams a CPU tier can carry. This is a per-workload tuning decision, not a fleet default — the right preset for archival mastering is not the right preset for a moderation pipeline that only needs a lightly compressed intermediate. We treat the software-side tuning in more detail in where CPU encoding fits in a GPU analytics pipeline. A worked scoping example (explicit assumptions) Assume a moderation pipeline ingesting camera feeds. Suppose, for illustration, the analysis stage runs a detection model that genuinely needs GPU inference, and the pipeline must also re-encode the reviewed footage to HEVC for archival. If the team provisions one GPU-heavy instance per stream and runs x265 on that same instance: The GPU carries the detection inference — appropriate. The GPU instance’s expensive vCPU-and-accelerator seat also carries the x265 encode, which uses none of the accelerator. Encode throughput is now capped by whatever CPU share that GPU instance happens to have, which is usually thin. Split the encode onto a CPU-optimised tier instead, and each layer scales on its own economics: GPU instances sized to inference demand, CPU instances sized to encode-stream count and preset. The encode cost stops riding on the GPU bill. This is an illustrative allocation, not a measured benchmark — but the structure is the recurring one, and it is what a GPU performance audit scoped to video-analytics workloads is built to surface across a real function mix. Where should x265 run, and how does it affect cost-per-analytics-hour? The answer follows directly from the compute profile: software x265 belongs on the CPU tier, sized to the number of encode streams and the preset depth they run at, and kept off the GPU capacity that analysis functions need. When a pipeline scopes encoding this way, the encode compute cost is cleanly separated from the analysis compute cost, and cost-per-analytics-hour stops absorbing charges that have nothing to do with analytics. Get this wrong at fleet scale and the failure is quiet — no crash, no error, just GPU utilisation that never explains itself and an encode workload returning little from every accelerator hour it holds. The broadcast media pipeline practice we work in treats encode-tier placement as a first-order economic decision, not an implementation detail, precisely because the misallocation hides so well on a dashboard that only shows aggregate GPU spend. For readers who want the fuller cost-trade view of the encoder itself, what x265 is and its cost trade-offs sits alongside this article and goes deeper on the licensing and open-source dimension that we deliberately leave aside here. FAQ What should you know about x265 HEVC encoder in practice? x265 implements the HEVC (H.265) standard in software. It searches a large space of partitioning, prediction, and transform choices per block and picks the combinations that minimise a joint distortion-and-bitrate cost — rate-distortion optimisation. In practice this means x265 earns its quality-per-bit through CPU-side search, and how deeply it searches (the preset) directly sets both quality and CPU cost. What is HEVC (H.265), and how does the x265 encoder differ from hardware HEVC encoders? HEVC (H.265) is the video coding standard; the standard defines what a valid bitstream and decoder look like, not how an encoder should make its choices. x265 is a software encoder that runs an exhaustive rate-distortion search on the CPU. Hardware HEVC encoders run a fixed, silicon-baked pipeline that is far faster and more power-efficient but explores much less of the decision space, landing at a different quality-per-bit-per-watt trade. What is the compute profile of x265 — why is it CPU-bound rather than GPU-accelerated? The expensive part of software HEVC encoding is the mode-decision search: a tree of dependent, branchy choices where each block’s best option depends on its neighbours. That data-dependent branching is the pattern CPUs handle well and GPUs handle poorly. Running software x265 on a GPU does not make it a GPU workload — it puts CPU work on an expensive accelerator seat it cannot use. How does x265 encoding differ from the content-analysis inference stages in a media pipeline? Encode is branchy, sequential rate-distortion search best served by multi-core CPU; analysis inference is wide, regular tensor math best served by GPU. They scale on different variables — preset and stream count for encode, model size and frames analysed for inference — and want different hardware tiers. Treating them as one compute line item is the root of GPU misallocation. What do x265 presets and rate-control settings trade off between quality, bitrate, and encode speed? Presets set how much of the rate-distortion search space the encoder explores per frame: slower presets give better quality-per-bit at higher CPU cost and lower throughput. Rate-control modes (CRF, two-pass bitrate, constant quantiser) decide how the quality budget is spent across the stream. Preset selection is effectively a throughput-per-core dial and the main lever on how many encode streams a CPU tier can carry. Where should x265 encoding run in a pipeline, and how does that affect cost-per-analytics-hour and GPU utilisation? Software x265 belongs on a CPU tier sized to encode-stream count and preset depth, kept off the GPU capacity analysis functions need. Scoped this way, encode compute cost is separated from analysis compute cost, so cost-per-analytics-hour stops absorbing charges unrelated to analytics and GPU utilisation reflects only the work that actually uses the accelerator. When does hardware HEVC encoding beat software x265, and what does that mean for pipeline economics? Hardware HEVC wins when throughput and power efficiency at scale matter more than squeezing maximum quality-per-bit — its fixed-function pipeline is fast and cheap per stream but explores less of the decision space. Software x265 wins when quality-per-bit is the priority and CPU cycles are available. The economic point is that these are separate tiers with separate cost curves, and the choice should follow the workload rather than a fleet default. Where this bites hardest is the pipeline that never asked the question — the one that provisioned for analysis and let the encoder ride along on whatever tier was already there. If your GPU utilisation numbers have never quite explained themselves, the encode stage is worth profiling as its own workload before you buy another accelerator.
