The important change is not the encoder name. It is the construction of a continuous, hardware-aware frame path from decode through scaling and encode.
SERIES: STREAMING ARCHITECTURE & ENCODING EFFICIENCY
AT A GLANCE
Migrating from software encoding to dedicated hardware requires more than replacing one FFmpeg encoder with another. Building an efficient hardware-aware pipeline means keeping decode, scaling, and encode operations on the device while minimizing unnecessary frame transfers.
This article walks through the practical differences between CPU and Quadra-based FFmpeg workflows, explains the role of hardware frames and hardware filters, and highlights the configuration and monitoring practices that maximize performance and scalability.
Hardware migration is easier to understand at the command line than in an architecture diagram. The software and VPU workflows both use FFmpeg to describe an input, a decode path, filters, an encoder, rate control, and an output. What changes is where the frames live and where the expensive operations execute.
The examples below are based on NETINT Quadra Release 5.7 documentation.[1]
Start with the software path
A simplified CPU-based H.264-to-HEVC transcode might decode the source in software, scale it on the CPU, and encode with x265:
ffmpeg -i input.mp4 \
-vf "scale=1920:1080" \
-c:v libx265 \
-b:v 4000k -maxrate 4000k -bufsize 8000k \
-an output_cpu.mp4
The command is compact because frame placement is implicit. Decoded frames live in host memory, the software scaler reads them, and x265 performs the encode on CPU threads. This is easy to operate, but each concurrent job consumes the same shared host resources.
The encoder name changes. The frame path is the real change.
Both describe input, decode, filters, encoder, rate control, output – only the execution location moves.
Source: NETINT Quadra Integration & Programming Guide
Move decode and encode to Quadra
A basic Quadra path makes the device stages explicit. NETINT’s guide shows the following pattern for H.264 decode and HEVC encode:
ffmpeg -vsync 0 \
-c:v h264_ni_quadra_dec -dec 0 \
-xcoder-params "out=hw" \
-i input.h264 \
-c:v h265_ni_quadra_enc -enc -1 \
-xcoder-params "RcEnable=1:vbvBufferSize=3000:bitrate=4000000" \
output.h265
Each change has a purpose. h264_ni_quadra_dec selects the Quadra decoder. -dec 0 selects a decoder device. out=hw keeps the decoded result as a hardware frame. h265_ni_quadra_enc selects the HEVC encoder. In the documented multi-stage pattern, -enc -1 places the encoder on the same device as the decoder, avoiding unnecessary YUV transfers.[1]
Why hardware frames matter
A hardware encoder can accept frames uploaded from host memory, but a full hardware path is more efficient when decode, filter, and encode stages remain on the device. NETINT’s hardware-frame application note states that Quadra hardware filters require hardware frames. If the decoder already uses out=hw, an additional upload is not required; software-originated frames must be uploaded before those filters can run.[2]
This matters because uncompressed frames are large. At 8-bit 4:2:0, a 1080p frame contains about 3.1 MB of luma and chroma samples before alignment. At 60 frames per second, a single uncompressed stream represents roughly 187 MB/s. Downloading and uploading that frame repeatedly for several renditions creates avoidable bus traffic.
Add hardware scaling for an ABR ladder
NETINT’s programming guide provides a multi-output pattern that decodes once, keeps frames in hardware, splits them, scales selected branches, and feeds multiple encoders:
ffmpeg -c:v h264_ni_quadra_dec -dec 0 \
-xcoder-params "out=hw" -i input.h264 \
-filter_complex \
"[0:v]ni_quadra_split=3:0:0[out1080][in720][in480]; \
[in720]ni_quadra_scale=1280:720[out720]; \
[in480]ni_quadra_scale=854:480[out480]" \
-map "[out1080]" -c:v h265_ni_quadra_enc -enc -1 \
-xcoder-params "RcEnable=1:vbvBufferSize=3000:bitrate=10000000" 1080p.h265 \
-map "[out720]" -c:v h265_ni_quadra_enc -enc -1 \
-xcoder-params "RcEnable=1:vbvBufferSize=3000:bitrate=4000000" 720p.h265 \
-map "[out480]" -c:v h265_ni_quadra_enc -enc -1 \
-xcoder-params "RcEnable=1:vbvBufferSize=3000:bitrate=1000000" 480p.h265
The precise ladder, muxing, audio mapping, and device allocation will differ in production. The architectural point is stable: decode once, minimize frame movement, generate the required sizes in the hardware path, and map each branch to an encoder on the intended device.
Decode once. scale to the whole ladder on the device.
Source: Multi-output pattern from the NETINT Programming Guide.
Rate control and latency still require engineering
Hardware acceleration does not make encoder settings interchangeable. RcEnable, bitrate, and vbvBufferSize define rate-control behavior in the examples. GOP structure, lookahead, RDO, and quality settings also affect both output and density. Comparisons should match service requirements rather than merely matching option names.
Low-latency operation requires a compatible GOP. NETINT documents that lowDelay=1 must be used with an in-sequence low-delay GOP, such as supported presets 1, 3, 7, or 9. Enabling low-delay mode with a high-delay GOP returns an error.[1] A representative encoder option string is:
-xcoder-params "gopPresetIdx=3:lowDelay=1:RcEnable=1:bitrate=4000000"
Monitor the device, not only the host
After offload, low CPU utilization is expected and does not prove that the system has spare video capacity. NETINT’s ni_rsrc_mon utility exposes decoder and encoder load, instance count, device identifiers, and memory information.[3] In a multi-card host, monitor each device and make placement explicit so one card does not saturate while another remains idle.
Validate the workflow, not the command
A successful migration test should cover output quality, bitrate conformance, keyframe placement, latency, aggregate throughput, device utilization, frame drops, and downstream muxing or packaging. Test long duration, input changes, and the filters actually used in production.
The most common implementation error is to replace libx265 with h265_ni_quadra_enc and stop. That may produce output, but it does not guarantee an efficient pipeline. Decode location, hardware frames, filter compatibility, device placement, rate control, and monitoring determine whether the migration delivers its intended density and predictability.
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, 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
[3] NETINT, Quadra Demo Server Usage Application Note: https://docs.netint.com/pdf/quadra/APPS572_Quadra_Demo_Server_Usage_Application_Note_v1.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
