The best encoder path depends on the scenario, so a launch-day transcoding benchmark has to score live and video-on-demand (VOD) separately. In the vbench benchmark, GPU hardware encoders were an unqualified win for live transcoding. On VOD they traded compression for speed, and in its Popular scenario, for the most-watched titles, neither GPU produced a single valid transcode. Three rules follow. Compare encoders on VMAF at matched bitrate, not raw frames per second. Size capacity to the live peak, not the average. Price every bitrate difference in egress dollars before you set it against the compute saving.

That is why “what is the best GPU for video transcoding” has no single answer. An encoder that wins the live ladder can cost more on popular back-catalogue titles, where its bitrate penalty is paid on every view.

Should live-event and VOD transcoding get separate benchmark scores?

Yes. Report a live score and a VOD score, and let spiky live-event concurrency, not steady batch throughput, set the launch-day capacity requirement. A blended score averages away the peak. It understates what the live event needs and overstates the baseline the VOD fleet runs on.

LynxBenchAI measures AI performance on the hardware side of this decision. Its results compare AI throughput, latency and cost per unit of work across accelerators, which helps shortlist GPUs for AI stages such as upscaling. It does not run your transcoding ladder for you, so start from the LynxBenchAI published results for the cards you are considering.

vbench builds the difference between the two workloads into its scoring functions. The Live score is bitrate × quality (B×Q), and it only counts when the transcode keeps pace with the pixel rate of the output video. The VOD score is speed × bitrate (S×B), and it only counts if quality matches the reference or the transcode is visually lossless. The two references also encode differently. Live is single-pass and low-latency with a fixed bitrate target, while VOD is two-pass with a fixed bitrate target. The vbench authors argue for reporting the separate metrics alongside the score, because the balance between compute, storage and network costs depends on the service.

Real-time modes give up coding efficiency to cut latency, which means they are not directly comparable with ordinary rate-compression graphs. Treat them as two scores for two decisions, not two readings on the same scale.

Which concurrency pattern should set the launch-day capacity requirement?

The peak live burst should set it, using peak concurrent viewers rather than a forecast average. Google’s SRE book reports that some Google products had to handle launch spikes up to 15 times higher than first estimated. It also notes that the traffic mix during a launch spike can be very different from steady state, which throws off load-test results. The same chapter points out that if three deployments serve peak traffic, you need four or five to cover maintenance and failures.

Melbicom’s bandwidth guidance makes the same split on the delivery side. VOD spreads consumption across many sessions, major events produce extreme simultaneous loads, and each workload needs its own monthly-volume and peak-throughput calculation. Their peak formula multiplies peak concurrent viewers by a peak planning bitrate and a headroom factor. When batch and live share a fleet, OneUptime’s capacity guidance warns against averaging the two peaks over a day and throwing away the short window when both are busy.

Blend the scores only if the requirement explicitly asks for average utilisation rather than a guarantee that the peak is provisioned. Before adding capacity, profile the transcoding pipeline you already run. NVIDIA’s FFmpeg documentation notes that unnecessary frame copies to and from the host show up as higher PCIe throughput and lower end-to-end FPS. Profiling, not a rule of thumb, shows whether lost throughput comes from the pipeline.

Why compare VMAF at matched bitrate rather than raw encode FPS?

Encode FPS measures only one of three dimensions. vbench states that transcoding has to be judged on visual quality, video size and transcoding speed together. An encoder that is faster but needs more bits to reach the same quality does not remove cost. It moves the cost from compute into storage and network.

LynxBenchAI compares AI throughput, latency and cost per unit of work across accelerators, which covers the AI stages of this comparison, such as upscaling; start from its published results for the GPUs you are comparing.

TechnoLynx sets up quality-normalised comparisons of a team’s own transcoding pipelines. TechnoLynx starts by fixing the target bitrates, the content set and the quality metric for your workload. It then runs matched-bitrate encodes of the same source content on each vendor’s stack and checks that the settings match. The result is a reusable cost-quality report you can use for capacity planning and vendor negotiation.

Start from LynxBenchAI’s published results for the AI stages, such as upscaling, on the GPUs you are comparing.

How BD-rate and BD-VMAF put two pipelines on one scale

BD-rate is the average percentage of bitrate saved at the same visual quality, computed over the quality range two rate-distortion curves have in common. BD-VMAF swaps the axes. It gives the average VMAF gain at the same bitrate, computed over the bitrate range the curves share. You need several encodes per encoder across a bitrate ladder to get those curves. The AV1 real-time study by the authors of arXiv 2009.14165 measured VMAF at ten target bitrates before computing BD-rates.

Compare encoder implementations, not codec names. That same study found that implementations of one codec differ a lot in quality, and concluded that implementations should be compared rather than codecs. A November 2025 evaluation of hardware encoders (arXiv 2511.18686) found that the NVIDIA encoder needed 10 to 20 percent more bitrate than the Intel encoder to reach the same quality at the same resolution and codec.

Check which settings each published figure used. In constant-bitrate tests, the 2025 study found that NVIDIA’s encoder roughly matched the rate-distortion performance of software encoders at their best real-time presets. BlazingCDN’s comparison, by contrast, says NVENC HEVC needs roughly 15 to 25 percent more bits than x265 slow. BlazingCDN also says NVENC AV1 trails SVT-AV1 on CPU by 3 to 5 VMAF points at equivalent bitrates. The first compares against real-time software presets, the second against x265 slow. We give more weight to the 2025 arXiv study for the live case, and we treat the BlazingCDN figures as one CDN vendor’s estimates.

Encoder settings to pin before the numbers mean anything

Each of these settings shifts the quality, latency or speed trade-off, so fix it per scenario and record it:

• Preset. NVENC presets run from p1 (fastest, lowest quality) to p7 (slowest, best quality). On x265, Jan Ozer measured that moving from medium to slower added 2.16 VMAF points and made encoding 8.5 times slower.
• Rate control. Setting maxrate equal to the target bitrate forces CBR, which suits live streaming. Setting maxrate above the target allows VBR, which gives better quality for VOD.
• Multipass and lookahead. Multi-pass modes improve rate-control accuracy at the cost of encoding time and memory. The 2025 study used preset P7 with multipass and a 120-frame lookahead.
• Adaptive quantisation. That study turned spatial and temporal AQ off because they can lower objective metric scores. NVIDIA, on the other hand, recommends AQ when quality is judged by eye rather than by an objective metric. Whether AQ is on can therefore change your VMAF ranking.
• Parallel sessions. NVIDIA’s method for measuring throughput is to run several FFmpeg sessions at once on inputs longer than 15 seconds and add up their FPS, so that per-session start-up overhead disappears.
• Codec. NVIDIA recommends HEVC over H.264 for 4K60, and notes that AV1 compresses better still but needs a check on platform compatibility.
• VMAF model and variant. The 2025 study used the standard VMAF model, version 0.6.1, for 4K and below. Netflix’s developers recommend VMAF NEG for codec comparisons.

Where VMAF misleads

VMAF is an objective metric whose scores correlate well with viewers’ subjective scores. A study of 789 encoded streams rated by several hundred viewers (arXiv 2107.10220) found that VMAF correlated with visual quality better than PSNR, SSIM, MS-SSIM and VIF. The same study notes that video preprocessed specifically for the metric can lose visual quality, to the point where the correlation turns negative. VMAF NEG reduces that risk but correlates less well with viewers. The authors advise using a set of metrics, because a metric that does well on average can fail badly on individual clips.

Measuring quality has a cost too. NVIDIA reports that VMAF-CUDA on an L4 GPU reaches up to 4.4 times the FFmpeg throughput of a dual Xeon 8480 system, and that it can run during transcoding on GPU compute that NVENC leaves idle. Those are vendor figures, but they mean scoring every bake-off encode no longer has to be the slow part of the benchmark.

Will vendors agree to a witnessed bake-off under identical settings?

If a vendor declines, the fallback is an independent run on identical content and settings, with versions and options published.

Who can run a matched-bitrate encoder bake-off on our own content?

TechnoLynx runs this matched-bitrate comparison on a team’s own content through its media and broadcast engineering team. TechnoLynx frames the comparison on your catalogue, runs matched-bitrate encodes on each vendor’s stack, and reports VMAF, BD-rate and throughput together. It checks setting parity and reproducibility before any results are compared. For the AI stages on that hardware, LynxBenchAI is the measuring tool. Its published results inform the GPU shortlist, and your own encodes settle the codec questions.

There are limits. If your volumes are small enough that one well-tuned software preset covers everything, a bake-off costs more than it saves. Encoder vendors’ own reference tests are another route, as long as you reproduce them on your own content.

How do you turn a VMAF or BD-rate gap into a dollar figure?

Express the quality gap as a bitrate penalty, then price that penalty as delivered bytes. BlazingCDN’s October 2026 comparison states the rule this way: hardware encoding wins while the monthly compute saving exceeds the penalty fraction × delivered TB × price per TB. BD-rate gives you the penalty fraction, and your CDN price and delivered terabytes supply the other terms.

Worked example: live and VOD break-even

BlazingCDN’s live case is 100 channels, where NVENC saves $29,740 a month against x264 medium ($39,668 minus $9,928) at an 8 percent bitrate penalty. At $4 per TB delivered, the penalty costs 0.08 × $4 = $0.32 per TB, so break-even is 29,740 ÷ 0.32, or about 93,000 TB a month. At $20 per TB, the penalty costs $1.60 per TB and break-even falls to about 18,600 TB. A fivefold change in egress price moves the break-even by the same factor, which is why the formula needs your own delivery price, not a typical one.

The same source’s VOD case is a two-hour 1080p title at 6 Mb/s, which is 5.4 GB per full view (6 Mb/s × 7,200 s ÷ 8). Encoding its ladder with x265 slow costs about $1.80 in CPU time, against about $0.10 on a GPU. The CPU figure is the source’s own estimate (about 40 vCPU-hours at $0.045). With a 20 percent NVENC HEVC penalty, each view wastes about 1.08 GB, or $0.0043 at $4 per TB. Dividing the $1.70 encode difference by that per-view waste puts break-even at about 400 views at $4 per TB, and about 80 views at $20 per TB. Every title expected to pass that number should get the slow software encode.

Audience distribution changes the result as well. Jan Ozer measured tuned x265 delivering the same quality as tuned x264 at close to 33 percent less bitrate, the headline number. Once he accounted for which ladder rungs viewers actually watched, the realised bandwidth saving was only 16 to 27 percent. Encoding cost about 7.5 times more, and payback took between about 3,200 and 10,000 viewing hours depending on the audience. His inputs are encode cost per hour of content, CDN cost per GB, and the rung distribution of the audience.

Choosing hevc_nvenc when it scores a few VMAF points lower on fast-motion sports

Set a minimum VMAF first and treat it as a hard constraint. Only then compare cost on the encoder paths that clear it. CDN77, testing CPU, GPU and NETINT ASIC transcoders on hundreds of client videos, targeted VMAF scores above 80 or above 90 depending on content category. Sports deserves its own floor and its own test clips. vbench identifies frame rate as one of the features with the most impact on transcoding, because content above 30 frames per second needs more bits.

If hevc_nvenc clears the sports floor, price the remaining gap against the compute saving. You choose a dollar value per VMAF point, or you convert the gap into a bitrate penalty through BD-rate and run the break-even above. If the cheaper encoder still wins after that, it is the defensible choice even though it scores lower. Check fast-motion clips with a second metric, because a metric that does well on average can fail badly on individual clips.

Weight live and VOD differently

Weight them differently because their costs behave differently. Live transcoding has a bounded latency budget, while VOD can use two-pass encoding for higher quality and smaller files. When a video will be played many times, the cost of an advanced encoder is spread across its plays, and the bitrate saving is multiplied by them. In practice, the live weight should put the latency limit first, even at a cost in bitrate or quality. The VOD weight should favour cost, re-encoding a title when its view count crosses the break-even. CDN77 chose ASICs over GPUs for live transcoding mainly on power, because it runs out of data-centre power before rack space.

Scenario	Encoder path the evidence favours	What decides it
Live events	GPU hardware encoder (NVENC, Quick Sync)	Real-time constraint; software presets lose more quality when forced to real time
Popular VOD titles	Slow software encoder (x265, SVT-AV1)	Bitrate saving repaid on every view
Long-tail VOD	Depends on expected views	Break-even views at your price per TB
Power-limited live density	Fixed-function ASIC is worth testing	Power and density per stream

Folding encode, storage and egress into one unit, such as BlazingCDN’s cost per viewer-hour, is what lets you compare architectures on equal terms. The broader method of turning benchmark figures into a single comparable number is covered in making TCO decisions comparable with blended cost metrics.

Should we drop the AI upscaling tier or raise the price?

The same cost-quality model gives you the cost side of this decision, but not the revenue side. Your benchmark can measure the compute the upscaling tier uses per stream-hour. How many subscribers would leave without it has to come from churn data. Set it up as two levers: the tier cut and the price rise. Estimate churn for each from your own historical price elasticity, and keep the lever with the higher margin after churn.

The break-even subscriber count is the point where the tier pays for itself. That is where the revenue from subscribers who buy the add-on or stay because of it, multiplied by their margin, equals the tier’s compute cost. The compute cost is only saved if the GPUs are retired or reused. If they sit idle under a reservation, the saving on paper never arrives.

The published pricing evidence cited here comes from SaaS, not streaming. In arXiv 2512.20932, a uniform price uplift raised revenue by 8.3 percent while churn rose from 2.8 percent to 3.9 percent against static tiers. An elasticity-guardrailed approach raised revenue by 16.2 percent with churn at 2.3 percent. Treat these figures as a reason to measure your own elasticity, not as estimates for a video service.

If we cut bitrate at the same VMAF, how much egress does that save?

At a fixed traffic volume, the egress saving is roughly the bitrate reduction × monthly delivered TB × your price per TB. Melbicom’s formula for monthly volume (viewer-hours × average Mbps × 0.45 × an overhead factor, in GB) gives you the delivered-TB term from audience data.

TechnoLynx builds this business case from controlled before-and-after measurements. TechnoLynx chooses the compression approach (pre- or post-processing, super-resolution, or a neural codec), integrates it into your encoding pipeline on the target hardware, and measures bitrate and VMAF before and after on representative titles. TechnoLynx then converts the measured reduction into savings against your real traffic and egress pricing, and supports the production trial.

The size of the prize is the reason to be careful. BlazingCDN writes that CDN cost is often the largest single line item, bigger than encode compute, and quotes egress prices from $0.08 per GB down to $0.0025 to $0.005 per GB. It also claims that switching from a fixed six-rung ladder to per-title encoding typically cuts bitrate by 20 to 40 percent at equivalent VMAF. Ozer’s measured per-title ladder shows why the word “equivalent” needs checking. It cut delivered bitrate by 26 percent but also delivered 1.33 fewer VMAF points, because it targeted VMAF 93 at the top rung where the fixed ladder had scored 94 to 97. At $0.02 per GB, he puts the x265-over-x264 saving at over $800,000 per 100 million hours delivered to a top-heavy audience.

What to tell sponsors instead of “lossless”

Say “visually equivalent quality at X percent lower bitrate, measured with VMAF on these titles”. Never say “lossless”, because equal VMAF means equal predicted perceived quality, not identical pixels. The minimum evidence package we would put in front of a funding committee is:

1. Controlled before-and-after encodes on content sampled from the sponsor’s own catalogue, with settings pinned.
2. Bitrate and VMAF deltas per title or genre rather than one average, plus a second metric on the hardest clips.
3. Savings shown as a range tied to stated traffic assumptions and the actual egress contract, not as a single figure.
4. A production trial gate that opens only after the quality delta holds on representative content.

For the board, put compute, storage and network on one page. vbench names these three as the main costs of a video service, and a codec change trades between them.

When a codec-only benchmark stops being enough

Everything above assumes the fleet only transcodes. Two questions sit next to this one: which mix of codecs, resolutions and AI stages makes a benchmark representative of production, and how to build a reproducible test that loads transcoding and live AI inference together. Both are worth settling before the launch capacity figure is signed. A hardware choice that wins the encode-only test can still run short of capacity once captioning shares the GPU.