Executive Summary
Moving transcoding from CPUs or GPUs to NETINT Quadra video processing units (VPUs) is less a hardware swap than a pipeline migration — and the difference between a smooth migration and a painful one is decided before the first card is racked. Arcadian, a NETINT partner, has developed a ten-step deployment methodology built around a simple principle: measure everything against your own content and your own pipeline, and never let a production stream depend on an assumption you haven't tested.
The good news for engineering teams is that the integration surface is smaller than most expect. Quadra presents to the host as an NVMe device, with a libavcodec patch sitting between the device interface and the FFmpeg and GStreamer software layers. If your pipeline is built on either framework, your filter graphs, packaging, and orchestration logic largely survive the migration intact. What changes is the encode stage —and that is precisely what this methodology is designed to de-risk.
This paper walks through each step of the process, names the concrete deliverable each step produces, and shows the benchmark reporting format we use to validate density, quality, and total cost of ownership with measured numbers rather than quoted ones. The end state we engineer toward is straightforward: the first production stream behaves exactly like the last test stream.
Why VPUs, Why Now
Every VPU project we deploy starts with a trigger. The specifics vary, but the underlying pattern is the same: areal-time video workload has outgrown the economics of general-purpose compute. The triggers we see most often:
- Rackspace — Rack space and density ceilings. The facility is full, and adding CPU encode capacity means adding racks, power circuits, and cooling that don't exist.
- Power — Power and cooling budgets under pressure. Sustained software encoding burns tens of watts per stream; at channel-count scale, the power bill becomes an architecture decision.
- Codec efficiency — An AV1 or HEVC mandate that CPU encoding can't economically meet. Modern codecs demand dramatically more compute per frame; real-time AV1 in software is possible but rarely affordable at density.
- Cloud cost — Cloud transcode spend that scales linearly with growth. Per-minute cloud encoding pricing that made sense at launch stops making sense at scale, and egress compounds it.
- Control — Latency, data-sovereignty, or on-premises requirements that rule out managed cloud encoding entirely.
The Quadra family is purpose-built for exactly these conditions: one Codensity G5 silicon architecture across four form factors, selected by deployment environment and power envelope — from the M.2-based T1M for edge and space-constrained deployments to the dual-ASIC T2A, which delivers up to 64 streams of AV1, HEVC, and H.264 in roughly 40 watts. For teams that want turnkey density rather than card-level integration, the 1RU Quadra Video Server runs ten VPUs and ships with NETINT's Bitstreams management software preinstalled.
Recognizing the trigger is step one of the methodology. The remaining nine steps are how we turn that recognition into a production system without betting a channel lineup on a datasheet.
The Arcadian Deployment Methodology
Step 1 —Problem Recognition
This step usually happens before we're in the room but making it explicit matters: the trigger defines the success criteria for everything downstream. A power-constrained facility measures success in watts per stream. A team facing an AV1 mandate measures it in quality-per-bit at real-time speed. A cloud repatriation project measures it in three-year TCO. We begin every engagement by writing the trigger down and agreeing on the metric that will ultimately declare the project successful.
Deliverable: A one-page problem statement with the primary success metric and its target value.
Step 2 —Evaluation Intent & Workload Profiling
This is the step most vendors skip and the step that determines whether the hardware sizing in Step 3 is engineering or guesswork. We profile the actual workload: codec mix (H.264, HEVC, AV1, and any transition plans between them), ABR ladder profiles and renditions per channel, live-to-VOD ratio, peak and steady-state concurrency, latency budget, and —critically — the existing software stack. Whether the pipeline is FFmpeg, GStreamer, or a custom application against the SDK changes the integration plan materially.
We also capture the operational envelope:available rack units, power per rack, host server inventory and PCIe generation, and the monitoring stack the new hardware must report into. The output is a workload specification that both Arcadian and the customer engineering team sign off on. Every subsequent step traces back to this document.
Deliverable: A signed-off workload specification: codec mix, ladder profiles, concurrency, latency budget, software stack, and operational envelope.
Step 3 —Solution & Hardware Fit
With the workload spec in hand, hardware selection becomes arithmetic rather than persuasion. The Quadra family shares one silicon architecture across four form factors, so the question is which package fits the deployment environment: the T1M (M.2) for edge and space-constrained systems, the T1U (U.2) and T1A (PCIe add-in card) for standard data-center scale-out, and the T2A (dual-ASIC, single slot) when slot count is the binding constraint and cost per stream is the priority. Where the customer prefers a turnkey platform, the Quadra Video Server provides ten VPUs in 1RU with Bitstreams preloaded.
The sizing document shows its math: streams per card for the customer's specific ladder (not a generic 1080p30 figure), cards per host given PCIe lanes and thermals, hosts per rack given the power budget, and the resulting headroom against projected growth. We size for the workload spec plus an explicit growth margin — never to the datasheet maximum.
Deliverable: A sizing document with streams-per-card, cards-per-host, and hosts-per-rack calculations shown, including growth headroom.
Step 4 — Proof of Concept & Benchmarking
The POC exists to replace every number in the business case with a measured one. We benchmark against the customer's own content — their sports feed, their film grain, their screen-share webinars —never canned demo clips, because encoder behavior is content-dependent and the only benchmark that predicts production is one run on production-representative sources.
Quality is scored with VMAF (and PSNR where the customer's QC process requires it) against the output of the incumbent encoder at matched bitrates, reported as both mean and low-percentile scores. Density is measured as sustained concurrent ladders per host under thermal steady state, not burst. Power is measured at the wall, per stream. These measured figures feed a TCO model comparing the VPU build against the incumbent CPU, GPU, or cloud spend over a three-year horizon — and it is this validated TCO, not the raw performance data, that typically carries the project through budget approval.
For teams that want to validate before any hardware ships, NETINT VPU capacity is now available as-a-service through partners such as Net Actuate, allowing benchmarks to run on rented Quadra-equipped infrastructure. Arcadian can execute the same POC protocol on rented capacity and carry the results directly into an on-premises sizing.
Deliverable: A benchmark report (format below) with measured VMAF, density, and watts per stream, plus a three-year TCO model built from measured values.
Step 5 —Architecture & Integration Design
Quadra integrates at the encode stage of the pipeline: the card presents as an NVMe device, and a libavcodec patch bridges the device interface to FFmpeg and GStreamer. In practice this means filter graphs, packaging (CMAF, HLS, DASH), DRM hand-offs, and orchestration logic are retained; the encoder invocation changes. The architecture design covers where the cards sit in the media flow, load management across multiple cards and hosts, failure modes and stream-level failover behavior, and how card health, temperature, and utilization surface into the customer's existing monitoring (Prometheus, Zabbix, or Bitstreams' dashboard where the Quadra Video Server is in play).
This step also fixes the firmware and driver baseline and the supported FFmpeg/GStreamer versions for the deployment, so that the staging environment in Step 7 and production in Step 8 are built from an identical, version-pinned stack.
Deliverable: An integration design document: media-flow placement, load management, failover behavior, monitoring integration, and a version-pinned software baseline.
Step 6 —Deployment Model Selection
With the architecture defined, the deployment model is a business decision made with engineering consequences on the table: fully on-premises, colocation, hybrid (VPU capacity for steady-state load with cloud burst retained for peaks), or a phased model that runs VPU infrastructure alongside existing cloud encoding while confidence builds. There is no universally correct answer — the workload spec from Step 2 and the TCO model from Step 4 make the trade-offs explicit, and the choice determines the rollout sequencing in Step 8.
Deliverable: A deployment model decision record with the selected model, the alternatives considered, and the rollout sequencing it implies.
Step 7 — Pilot & Staging Validation
Staging is where the design meets production-shaped reality. We run the pinned software stack on production-identical hardware under representative load: full ladders, real channel counts, soak tests measured in days rather than minutes, and deliberate failure injection — card removal, host loss, process kill — to confirm that fail over behaves as designed and that monitoring alerts fire where and when they should. Operational runbooks are written and exercised here, by the people who will own the system, before any production stream depends on them.
Deliverable: A staging validation report: soak results, failover test outcomes, alert verification, and signed-off operational runbooks.
Step 8 —Production Rollout & Migration
We never big-bang a channel lineup. Rollout is phased: a first tranche of lower-risk channels cuts over with the incumbent encode path kept warm as rollback, followed by progressively larger tranches as confidence accumulates. Each tranche has explicit entry criteria (staging sign-off, monitoring green), exit criteria (a defined observation window at production quality), and a rehearsed rollback procedure. Because staging was version-pinned and production-identical, cutover is an operational exercise rather than a discovery process — the first production stream behaves exactly like the last test stream, and if it doesn't, the process failed before the rollout did, which is exactly where failures belong.
Deliverable: A migration plan with per-tranche entry/exit criteria and rollback procedures, executed and signed off tranche by tranche.
Step 9 —Optimization & Scale-Out
Once production is stable, tuning begins capped-CRF and rate-control profiles refined against real traffic for predictable CDN cost, ladder pruning where AV1 efficiency allows renditions to be consolidated, and utilization review to reclaim headroom. Scale-out follows the same sizing math as Step 3, now calibrated by months of production telemetry rather than POC data. This is also where codec-transition plans (H.264 to HEVC to AV1) execute incrementally, since the same silicon handles all three.
Deliverable: A quarterly optimization review: rate-control tuning changes, ladder adjustments, utilization and capacity forecast.
Step 10 —Ongoing Support & Lifecycle Management
VPU infrastructure is long-lived, and its operational lifecycle is where a partner earns its keep. Arcadian provides firmware and driver lifecycle management against NETINT's release stream (including validation of upgrades in staging before production), monitoring and alert response, capacity planning as channel counts grows, and a define deescalation path into NETINT engineering for issues that require it. The goal is that the customer's engineering team spends its time on their product, not on encoder plumbing.
Deliverable: A support agreement covering firmware/driver lifecycle, monitoring, capacity planning, and vendor escalation paths.
How We Report POC Results
Every Arcadian POC produces a benchmark report in a consistent format so that results are comparable across candidate configurations and directly against the incumbent baseline. The table below shows the reporting skeleton with illustrative values; in an actual engagement every figure is measured on the customer's content and hardware.
Values shown are illustrative of report format only. All figures in a customer engagement are measured, not projected. VMAF is scored against source; density is sustained at thermal steady state; power is measured at the wall.
Two conventions worth noting. First, we always report low-percentile VMAF alongside the mean — averages hide the frames viewers actually complain about. Second, the TCO row is computed from the measured density and power rows above it, on the customer's actual power rate and rack cost, so the business case and the benchmark are the same document.
The Integration Surface, Honestly Stated
Engineering leads rightly distrust the phrase "drop-in replacement," so here is the accurate version. If your pipeline is FFmpeg- or GStreamer-based, the Quadra SDK integrates through a libavcodec patch, and you encode invocations change while your surrounding pipeline logic does not. Supported FFmpeg and GStreamer versions are documented and version-pinned per deployment; running outside the supported matrix is where avoidable pain lives, which is why Step 5 fixes the baseline and Steps 7–8 never deviate from it.
If your pipeline is a custom application, integration is against the SDK directly and the effort is larger — this is exactly the case the workload profiling in Step 2 exists to surface early, soit is scoped in the plan rather than discovered in staging. In both cases, load management across multiple cards, stream-level failover, and health monitoring are solved problems with established patterns; the architecture design in Step 5 selects among them rather than inventing them.
Working With Arcadian
Arcadian is a streaming media operations and technology company and a formal NETINT Technologies partner, with engineering and operations teams across the US, Europe, and Asia-Pacific. We have deployed and operated video infrastructure across live and VOD workloads for broadcasters, platform operators, and service providers — and the methodology in this paper is the one we actually run, deliverable by deliverable.
If you are evaluating VPU-based transcoding —whether the trigger is power, density, AV1, or cloud spend — the fastest way to a decision you can defend is a profiled workload and a benchmark on your own content. That is Steps 1 through 4, and it is where every engagement begins.
