NVIDIA Video Codec SDK 13.1 in 2026: AV1 B-Frames Tested

NVIDIA Video Codec SDK 13.1 landed with the one feature AV1 encoding on NVENC has been missing since Ada shipped in 2022: B-frames. Bidirectional prediction in hardware AV1 is worth roughly 10-20% bitrate at matched VMAF, and it costs nothing but a driver update and a flag. Pair that with the new zero-copy CUDA-to-NVENC path — which eliminates a full VRAM round-trip per frame — and frame-accurate seek in NVDEC, and the per-stream economics of GPU transcoding move materially in your favor for the first time in two years. If you run a transcode farm, a live streaming ladder, or an AI video pipeline that decodes, mangles, and re-encodes at scale, this is the release where you re-run your capacity spreadsheet.

What’s new in NVIDIA Video Codec SDK 13.1

The headline is NVENC AV1 B-frames. Prior SDK releases exposed AV1 encoding on Ada (AD10x) and Blackwell (GB20x) silicon, but the encoder ran a low-delay configuration: I-frames and P-frames only, no bidirectional reference structure. AV1’s spec has always supported hierarchical prediction with alt-ref and overlay frames; NVENC just didn’t drive it. SDK 13.1 exposes a B-frame count and a reference structure control for AV1, which lets you build a pyramid GOP where B-frames reference both past and future anchors. That is where the bitrate savings come from — the same reason H.264 and HEVC on NVENC have leaned on B-frames for a decade.

Second, the zero-copy CUDA-to-NVENC path. Historically, if you decoded with NVDEC, ran a CUDA kernel (scaling, denoise, an inference pass, an overlay), and re-encoded with NVENC, the frame made at least one extra trip through device memory because the encoder wanted its own input surface in its own layout. SDK 13.1 lets you register a CUDA device pointer directly as an encoder input surface with matching stride and format, so the kernel writes once and NVENC reads that same allocation. On a 4K60 pipeline that is roughly 1.5 GB/s of memory bandwidth per stream you stop burning, plus the latency of the copy and the synchronization around it. Bandwidth binds dense transcode nodes far more often than encoder throughput does.

Third, frame-accurate seek in NVDEC. The decoder API now exposes a seek that lands on the exact requested presentation timestamp rather than the preceding keyframe, handling the intermediate decode-and-discard internally. Anyone who has hand-written the “seek back to the IDR, decode forward, throw away frames until PTS matches” loop — which is every dataset-extraction and clip-generation pipeline in existence — can delete that code. It also matters for AV1 with the new B-frame pyramids, where display order and decode order diverge more aggressively and hand-rolled seek logic gets subtly wrong.

Why it matters

• Storage and egress drop 10-20% for free. A CDN bill scales with bytes. Re-encoding a library with NVENC AV1 B-frames at the same VMAF target trades a one-time GPU spend for a permanent bandwidth reduction — usually the fastest-paying infrastructure change available.
• Density per GPU goes up on memory-bound nodes. Zero-copy GPU transcode removes a copy per frame per stream. If your box tops out on VRAM bandwidth before it tops out on NVENC sessions, a software change buys you real additional streams instead of a hardware purchase.
• AV1 finally clears the hardware-vs-software quality gap enough to matter. SVT-AV1 at preset 8-10 has been the pragmatic software choice; hardware AV1 with B-frames now sits close enough that the 20-50x speed advantage wins for most ladders.
• AI video pipelines get simpler and faster. Decode with NVDEC, run inference on the decoded surface in CUDA, encode the result — all without leaving device memory. That is the exact shape of every video captioning, upscaling, and generative-edit workload being built right now.
• Dataset extraction stops being a correctness hazard. NVDEC frame-accurate seek means the frame you asked for is the frame you get. Off-by-a-few-frames extraction has quietly poisoned more than one training set.
• Latency-sensitive workloads have a choice to make. B-frames add reordering delay. For VOD it is pure win; for sub-second live you will keep bf=0 and take the bitrate hit. Know which bucket each ladder rung is in.

How to use NVIDIA Video Codec SDK 13.1 today

1. Confirm your driver and hardware. AV1 B-frame encode requires Ada or Blackwell NVENC and a driver new enough to expose the 13.1 capability set. Turing and Ampere have no AV1 encoder at all — they will silently fall back or fail.

   nvidia-smi --query-gpu=name,driver_version --format=csv
   nvidia-smi -q -d ENCODER_STATS | head -40

2. Verify FFmpeg sees the new AV1 options. You need an FFmpeg build linked against nv-codec-headers matching SDK 13.1. Check that -bf is honored on av1_nvenc rather than ignored.

   ffmpeg -hide_banner -h encoder=av1_nvenc | grep -E "bf|b_ref_mode|tune|rc|multipass"

3. Run a baseline vs. B-frame comparison on your own content. Do not trust anyone’s numbers, including these. Encode the same source twice at a fixed quality target and compare bitrate at matched VMAF.

   # Baseline: no B-frames (pre-13.1 behavior)
   ffmpeg -y -hwaccel cuda -hwaccel_output_format cuda -i source.mp4 \
     -c:v av1_nvenc -preset p6 -tune hq -rc vbr -cq 30 \
     -bf 0 -g 240 -c:a copy out_nobf.mp4
   
   # 13.1: hierarchical B-frames with middle-frame references
   ffmpeg -y -hwaccel cuda -hwaccel_output_format cuda -i source.mp4 \
     -c:v av1_nvenc -preset p6 -tune hq -rc vbr -cq 30 \
     -bf 3 -b_ref_mode middle -g 240 -c:a copy out_bf.mp4

4. Score it, don’t eyeball it. Matched-quality bitrate is the only number that matters. Run VMAF against the source for both outputs, then compare file sizes at equal scores.

   ffmpeg -i out_bf.mp4 -i source.mp4 \
     -lavfi "[0:v]scale=1920:1080:flags=bicubic[d];[1:v]scale=1920:1080:flags=bicubic[r];[d][r]libvmaf=n_threads=8:log_fmt=json:log_path=vmaf_bf.json" \
     -f null -
   
   ls -l out_nobf.mp4 out_bf.mp4

5. Wire up the zero-copy path if you own the C/C++ pipeline. The pattern: allocate once in CUDA, register that pointer as an encoder input resource, map it per frame, and never call cudaMemcpy between your kernel and NVENC.

   NV_ENC_REGISTER_RESOURCE reg = { NV_ENC_REGISTER_RESOURCE_VER };
   reg.resourceType     = NV_ENC_INPUT_RESOURCE_TYPE_CUDADEVICEPTR;
   reg.resourceToRegister = (void*)dptr;   // your CUDA kernel's output
   reg.width  = width;
   reg.height = height;
   reg.pitch  = pitch;                     // must match the kernel's stride
   reg.bufferFormat = NV_ENC_BUFFER_FORMAT_NV12;
   nvEncRegisterResource(enc, &reg);
   
   NV_ENC_MAP_INPUT_RESOURCE map = { NV_ENC_MAP_INPUT_RESOURCE_VER };
   map.registeredResource = reg.registeredResource;
   nvEncMapInputResource(enc, &map);
   // map.mappedResource -> NV_ENC_PIC_PARAMS.inputBuffer, no copy

6. Use frame-accurate seek instead of your decode-and-discard loop. In Python, PyNvVideoCodec exposes the same capability; the point is that you stop reimplementing GOP walking.

   import PyNvVideoCodec as nvc
   
   dec = nvc.SimpleDecoder("input.mp4", use_device_memory=True)
   frames = dec.get_batch_frames_by_index([120, 900, 4501])  # exact indices
   for f in frames:
       tensor = f  # already a CUDA device surface, feed inference directly

7. Measure sessions and bandwidth under real load. Density claims mean nothing off a single-stream test. Ramp concurrent streams until frames drop, and watch encoder utilization separately from memory throughput.

   nvidia-smi dmon -s um -d 1
   # 'enc' column = NVENC utilization; 'mem' = memory controller load
   # If mem saturates before enc, zero-copy is your win.

How it compares

Option	AV1 B-frames	Relative speed	Quality per bit	Best fit
NVENC AV1 (SDK 13.1, Ada/Blackwell)	Yes	Very high (real-time multi-stream)	Good — close to SVT-AV1 fast presets	Transcode farms, live ladders, AI video pipelines
NVENC AV1 (SDK 12.x)	No	Very high	Fair — 10-20% worse at matched quality	Legacy deployments not yet on 13.1
SVT-AV1 (preset 4-6, CPU)	Yes	Low — CPU-bound, expensive per stream	Excellent	Archival masters, premium VOD where quality dominates cost
Intel QSV AV1 (Arc / Xe)	Yes	High	Good	Cheap density where CUDA is not required elsewhere
AMD AMF AV1 (RDNA 3/4)	Limited	High	Fair to good	Existing Radeon fleets, desktop capture
NVENC HEVC	Yes	Very high	Fair vs. AV1 — but universally decodable	Compatibility-first delivery, older client devices

The honest read: SVT-AV1 at slow presets still wins on pure quality per bit, and it always will — software encoders get to spend arbitrary CPU time on rate-distortion search that fixed-function silicon cannot. But the question was never “which encoder is best,” it is GPU transcoding cost per stream. On that axis, one Ada or Blackwell GPU running 13.1 replaces a rack of CPU encoders, and B-frames just closed most of the remaining quality argument for anything short of an archival master.

What’s next

Watch the Blackwell NVENC encoder capability spread. Blackwell shipped with multiple independent NVENC engines on the higher-SKU parts, and the interesting question is how 13.1’s B-frame support and split-frame encoding interact when a single stream is distributed across engines. If NVIDIA lets you split a 4K or 8K frame across engines while maintaining a hierarchical GOP, the per-stream ceiling moves again — and 8K60 AV1 in real time on a single card stops being a demo.

On the software side, expect the FFmpeg and GStreamer plumbing to lag the SDK by a release or two, as it always does. The av1_nvenc B-frame options land first; well-tuned defaults, sane preset mapping, and correct behavior under -rc cbr with low-latency tunes take longer to shake out. If you are building anything production-critical in the next quarter, pin your FFmpeg build and your driver version together, and re-validate the pair before you upgrade either.

The bigger trend to track is the collapse of the boundary between “video pipeline” and “AI pipeline.” Zero-copy GPU transcode plus NVDEC frame-accurate seek plus CUDA-resident tensors means the decode-infer-encode loop never touches host memory. That is the substrate every video-understanding and generative-video product is being built on, and NVIDIA is quite deliberately making sure the substrate is CUDA. Whether Intel and AMD close that integration gap — not the raw encoder quality gap, the pipeline gap — is the thing worth watching over the next two years.

Frequently Asked Questions

Do AV1 B-frames work on my RTX 30-series card?

No. Ampere (RTX 30-series) has NVDEC AV1 decode but no AV1 encoder at all. AV1 encoding requires Ada (RTX 40-series, L4, L40S) or Blackwell (RTX 50-series and datacenter equivalents). If your workload is AV1 encode, Ampere is not a partial solution — it is not a solution.

How much bitrate do B-frames actually save?

Roughly 10-20% at matched VMAF on typical mixed content, with the high end on high-motion material where bidirectional prediction has the most to work with. Low-motion talking-head content sees less because P-frames were already cheap there. Test on your own library — content type dominates the result far more than any published average.

Should I enable B-frames for live streaming?

Usually not below about a second of acceptable latency. B-frames require reordering, which adds delay proportional to the B-frame count. For VOD, ABR ladder generation, and anything with a buffer, turn them on. For interactive or sub-second live, keep -bf 0 and accept the bitrate. Some ladders reasonably split the difference: B-frames on the archival rendition, none on the live path.

Does zero-copy require rewriting my FFmpeg-based pipeline?

Not entirely. FFmpeg with -hwaccel cuda -hwaccel_output_format cuda already keeps frames in device memory across the decode-filter-encode chain, and it inherits the SDK improvements when rebuilt against the new headers. The explicit registration API matters when you own the C/C++ or CUDA code and are inserting custom kernels or inference between decode and encode.

Is there a session limit on consumer GPUs?

Historically NVIDIA capped concurrent NVENC sessions on GeForce cards, with datacenter parts unrestricted. That cap has loosened considerably over recent driver generations, but it is driver-and-SKU dependent and it is exactly the kind of thing that changes without a headline. Verify the concurrent session behavior on your specific card and driver before you size a fleet around consumer hardware.

Do I need to re-encode my existing AV1 library?

Only if bandwidth or storage cost is a real line item for you. The math is straightforward: multiply your monthly egress by 10-20%, compare it to the GPU-hours needed to re-encode the catalog, and see how many months it takes to pay back. For a large, actively-streamed library the answer is usually weeks. For a small or cold archive, leave it alone.