Encoder comparisons are useful only after the workload has been matched to the compute architecture that will carry it.
At a glance
Encoding strategy usually starts too low, with software vs. hardware, presets, and codecs, when the first question should be which class of silicon carries the workload. CPU, GPU, FPGA, and purpose-built VPU turn the same codec and bitrate into very different outcomes for density, power, thermal behavior, and cost, so let the dominant work choose the architecture rather than brand familiarity.
Match the workload, service requirement, and operational model to the silicon first, then compare encoders inside the system that will run them at production scale, holding codec, resolution, bitrate, and quality constant while measuring throughput, latency, power, and stability. The goal is not one chip for everything but a heterogeneous architecture where the CPU stays the control plane and a VPU carries dense video, with the encoder decision downstream of that choice.
Encoding strategy often begins with some initial discussion of software vs. hardware, preset to use, rate-control selection, and codecs. That sequence is familiar, but it starts one layer too low. Before choosing an encoder, an architecture team should decide which class of silicon is best suited to the workload.
This decision affects stream density, power, thermal behavior, deployment cost, and predictability under load. The same codec and nominal bitrate can produce very different infrastructure outcomes depending on whether the work runs on a CPU, a GPU, an FPGA, or a purpose-built VPU (Video Processing Unit).
The workload should choose the silicon
No compute architecture is best at everything. The correct choice depends on the dominant work in the pipeline, the required level of programmability, and the economic unit that matters to the operator.
CPU: maximum flexibility
A CPU is the default because it is programmable, widely supported, and already present in every server. It is excellent for application logic, orchestration, packaging, networking, storage, and workloads whose volume or shape changes frequently. Software encoders also offer a wide tuning range and can deliver high compression efficiency when latency and compute budgets allow.
The cost is shared-resource behavior. At high concurrency, video sessions compete with the host operating system and every other process. Scaling is influenced by more than core count because encoding also pressures caches, memory bandwidth, I/O, and thermal limits. CPU encoding is often the right starting point, but it should not remain the default without measurement.
GPU: broad parallel compute plus fixed-function video
Modern GPUs often include dedicated video engines such as NVENC in addition to general-purpose shader or tensor resources. That makes them useful when a workflow combines encoding with graphics, computer vision, AI inference, compositing, or other parallel operations.
When encoding is the dominant task, the economic question becomes whether the platform is paying for a much larger device whose broader compute capability is not being used. A GPU can still be the right answer, especially where its ecosystem or adjacent workloads matter, but the comparison should be based on total useful work per device and per watt rather than brand familiarity.
FPGA: programmable hardware for specialized pipelines
FPGAs are useful when a system needs programmable logic, unusual I/O, deterministic signal processing, or functions that are not efficiently available in standard devices. They can be helpful in contribution, broadcast, and highly specialized appliances. The tradeoff is a more specialized development and maintenance model. If the main requirement is conventional encoding, decoding, scaling, and high density transcoding, FPGA may add complexity (and cost) without adding business value.
VPU: purpose-built media processing
A VPU is designed around sustained video operations.[1] Its role is narrow by design: move the media plane away from general compute while leaving orchestration, application logic, and platform control on the CPU.
The capacity unit becomes a video profile instead of an abstract percentage of host utilization. The NETINT Quadra T1U consumes just 17 watts while encoding up to 32 1080p30, eight 4Kp30, or two 8Kp30 streams across H.264, HEVC, and AV1.[2] Production density will vary with codec settings and features, but the specification illustrates the architectural difference: the device is sized and described in video workloads.
FIGURE 2B
How much of the chip is actually built for video.
Share of silicon dedicated to the video workload
Quality must be compared with throughput
Silicon selection should not become a race to the highest stream count. The output must meet the service requirement. A useful comparison holds codec, resolution, bitrate, GOP, rate control, and quality target as constant as possible, then measures aggregate throughput, latency, power, and stability.
A NETINT-published test using Akamai virtual machines compared x264/x265 on a 12-core host with one Quadra T1U attached to the same class of host. At 32 parallel HEVC sessions, the CPU path averaged 2.47 frames per second per session, while the VPU path averaged 18.99.[3] This is one defined test that demonstrates why concurrency behavior of an encoding system is important to understand.
Use a better decision sequence
- Define the workload: live or VOD, steady-state or burst, codec mix, resolutions, frame rates, and ladder structure.
- Define the service requirement: quality, latency, rate-control behavior, output compliance, and failure tolerance.
- Define the operational model: cloud, on-premises, hybrid, or edge, including available power, cooling, and rack space.
- Select the silicon class: match the silicon architecture based on the dominant work load and need for programmability or future enhancement.
- Choose and tune the encoder path: validate with representative content and concurrency. Resist the temptation to make a buying decision based on “lab results.” This may mean that you put the encoder under test into a production environment. At a minimum, you should approximate production as closely as possible.
This order prevents a common mistake: selecting an encoder because it produces an attractive result in isolation such as the lab, only to discover that the surrounding compute model cannot sustain the workload economically.
FIGURE 2B
Match the workload to the architecture that carries it.
Cloud does not remove the silicon question
Cloud services abstract procurement and operations, but every instance still maps to physical processors. General-purpose cloud compute can be ideal for development, burst, and uncertain demand. Steady-state live channels and recurring transcode volumes deserve a separate calculation because convenience premiums compound over thousands of processing hours.
The objective is not to standardize on one chip for every task. It is to create a heterogeneous architecture in which each workload runs where it is most efficient. The CPU can remain the control plane, a GPU can handle AI or graphics, and a VPU can carry dense video processing. That is a more precise architecture than forcing every function onto the same compute device.
The encoder decision is downstream
Encoder choice still matters. It determines quality, bitrate, compatibility, and latency. But those characteristics must be evaluated inside the system that will deliver them at production scale. Start with the workload, choose the architecture (CPU or silicon are the only two that make sense for most use cases), then select the encoder. Reversing that sequence risks optimizing the software while preserving the wrong infrastructure.
Technical sources
[1] NETINT, Product and engineering FAQs: https://netint.com/products/
[2] NETINT, Quadra Product Line Specifications: https://info.netint.com/hubfs/TechnicalSpec/Quadra-T1-T2-T4_TechSpec.pdf
[3] NETINT, Akamai Throughput and Quality Report: https://docs.netint.com/vpu/quadra/appnotes/akamai/throughput-and-quality-report/
STREAMING ARCHITECTURE & ENCODING EFFICIENCY | Stockholm Technical Series
NETINT and SCALSTRM brought together video engineering and infrastructure professionals in Stockholm for a practical discussion on encoding efficiency, hardware acceleration, cost, power, and live workflow design. This article series captures the key technical themes from the event, from silicon architecture and CPU vs VPU performance to FFmpeg integration and carrier-grade live workflows.
- Encoding Efficiency Is Becoming an Infrastructure Decision (What We Learned in Stockholm)
- Stop Asking Which Encoder. Start Asking Which Silicon.
- How Video Encoding Actually Runs
- VPU Migration Without Rebuilding Your Video Pipeline
- From libx265 to h265_ni_quadra_enc
- From VPU Acceleration to Carrier-Grade Live Workflows
- Encoding Efficiency, Power, and Resilience in Nordic Streaming Infrastructure
