The difference between CPU and VPU encoding becomes clear when the pipeline is viewed as a sequence of frame-processing stages and resource transfers.
SERIES: STREAMING ARCHITECTURE & ENCODING EFFICIENCY
AT A GLANCE
Video encoding performance depends on more than the encoder itself. Every transcode moves through a pipeline that includes decoding, preprocessing, encoding, and packaging, with each stage placing different demands on the underlying compute architecture.
This article explains how video encoding actually runs on CPUs versus dedicated video hardware, why data movement and resource contention matter at scale, and how purpose-built VPUs improve throughput, efficiency, and infrastructure scalability.
Video encoding is usually discussed through its output: bitrate, codec, resolution, latency, VMAF, or file size. Infrastructure decisions require a different view. We need to follow the media through the pipeline and identify where each operation executes.
A typical transcode has five stages: demux the input, decode compressed video into frames, preprocess those frames, encode them into a new representation, and mux or package the result. Encoding is often the largest compute consumer, but decode and filters can also become material at high resolutions, high frame rates, or large ladder counts.
The pipeline starts before the encoder
The container or transport layer is parsed first so the application can separate video, audio, captions, and metadata. Compressed video is then decoded into a frame representation. The frame may be scaled, deinterlaced, color-converted, cropped, overlaid, or otherwise prepared before it reaches the encoder. After compression, the output is muxed or packaged for storage and delivery.
This sequence matters because acceleration at one stage can be undermined by unnecessary transfers at another. A hardware encoder can reduce encode load, but a pipeline that repeatedly moves uncompressed frames between host memory and device memory may lose part of the benefit. The execution path must therefore be evaluated as a whole.
Every transcode is five stages - encoding is the heavy one.
Acceleration at one stage can be undone by unnecessary transfers at another. Source: NETINT TECHNOLOGIES- Streaming Tech Sweden 2026.
What happens on a CPU
A VPU moves the repetitive media operations to a purpose-built ASIC. Software still creates sessions, passes compressed packets or frames, sets encoder parameters, receives output, and handles errors. The host CPU remains essential, but it no longer performs the same volume of pixel-level encode work.
NETINT’s Quadra software stack exposes the hardware through FFmpeg plugins, GStreamer, or the libxcoder API. These interfaces communicate with the device firmware through an NVMe driver.[1] That design preserves familiar application frameworks while changing where the decode, 2D processing, and encode functions run.
Concurrency exposes the difference
A published NETINT test on Akamai virtual machines illustrates the execution model. The CPU and VPU tests used the same 12-core, 24 GB host class; the VPU configuration used one Quadra T1U. With 32 parallel 1080p HEVC sessions, the software x265 path averaged 2.47 frames per second per session, while the VPU path averaged 18.99. For H.264, the corresponding figures were 4.83 and 16.00 frames per second per session.[2]
These figures should be read carefully. They are results for specific commands, source material, bitrate, presets, and virtual machines. They do not prove that every VPU workload is seven times faster than every CPU workload. They do show that offloading the media plane can preserve substantially more aggregate throughput as session count rises.
Aggregate throughput is the useful comparison
At 32 sessions, per-session speed falls because the total device throughput is divided among more jobs. The relevant question is whether the aggregate frame rate meets the required number of real-time channels or the target VOD completion window.
Hardware frames control data movement
When a NETINT decoder is configured with out=hw, the decoded frame remains represented as a hardware frame on the device. Hardware-aware filters such as ni_quadra_scale can operate without first downloading the full frame to host memory. NETINT documentation notes that its hardware filters require hardware frames; software frames must be uploaded when the pipeline starts outside the device path.[3]
Keeping decode, scaling, and encode on the same device reduces avoidable YUV transfers. This becomes especially important for adaptive-bitrate ladders because uncompressed video is large. A single 1920×1080 8-bit 4:2:0 frame is roughly 3 MB before alignment and metadata. Moving many copies across the bus for every rendition can create a significant bandwidth and latency burden.
Where the frames live decides how well hardware helps.
Source: NETINT Technologies — Streaming Tech Sweden 2026.
Control plane and media plane remain distinct
Dedicated hardware does not eliminate software responsibility. The application must still decide where sessions run, recover from failures, manage packaging and timing, expose monitoring, and protect downstream systems from overload. In live workflows it must also handle input discontinuities, captions, audio, metadata, and redundancy.
The clean architecture is a division of labor. General-purpose compute handles the flexible and variable control plane. Dedicated hardware handles continuous frame processing. This is not hardware replacing software. It is workload placement that reduces contention and makes capacity easier to express in video-specific terms.
Size by profiles, not percentages
CPU dashboards encourage teams to size around utilization. Video services are deployed as channels, renditions, and ladders. A dedicated media architecture lets capacity planning map to those units: codec, resolution, frame rate, bit depth, rate-control mode, filters, and concurrent sessions. That is a more useful model because it describes the work the platform must deliver, not merely the resources it happens to consume.
Technical sources
[1] NETINT, Quadra Integration and Programming Guide, Release 5.7: https://releases.netint.com/quadra/v5.7.0/IntegrationProgrammingGuideQuadra_V5.7.pdf
[2] NETINT, Akamai Throughput and Quality Report: https://docs.netint.com/vpu/quadra/appnotes/akamai/throughput-and-quality-report/
[3] NETINT, Software and Hardware Frame YUV Bypass Application Note: https://docs.netint.com/pdf/quadra/APPS548_Codensity_Quadra_Software_and_Hardware_Frame_YUVbypass_Application_Note_v2.0.pdf
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
