用途：根据本指南可独立完成「查格式支持 → 查性能基准 → 计算解码路数 → 实测验证」的完整评估流程。
业务场景：多路解码 + 抽帧送推理（VLM），不含编码/转码，因此本文档只覆盖 NVDEC 解码侧；NVENC 编码内容仅作背景保留。
一、信息来源（官方地址）
| 文档 | 地址 | 回答什么问题 |
|---|---|---|
| Video Encode and Decode Support Matrix | https://developer.nvidia.com/video-encode-decode-support-matrix | 能不能：每款 GPU 的 NVENC/NVDEC 代际、引擎数量、支持的格式/位深/色度采样；会话上限列仅在编码表中（解码表无此列） |
| NVDEC Application Note（解码性能） | https://docs.nvidia.com/video-technologies/video-codec-sdk/13.0/nvdec-application-note/index.html | 解多快：各代单引擎 1080p 解码帧率（Table 2），时钟缩放与多引擎聚合规则 |
| NVENC Application Note（编码性能） | 同站将路径中 nvdec 换成 nvenc | 编多快：各代单引擎编码帧率（本业务无编码，仅备查） |
| Video Codec SDK 文档总目录 | https://docs.nvidia.com/video-technologies/video-codec-sdk/ | 切换 SDK 版本、查历史文档 |
| SDK 本体下载（头文件 + AppDecode/AppEncode 示例） | https://developer.nvidia.com/nvidia-video-codec-sdk | 需 NVIDIA Developer 账号登录 |
| nvidia-smi 工具文档 | https://developer.nvidia.com/nvidia-system-management-interface | 查本机视频时钟、解码器利用率 |
二、怎么查
2.1 查某款 GPU 支持什么格式
页面结构：编码（NVENC）5 张表 + 解码（NVDEC）5 张表，各按产品线分 GeForce / 专业卡 / 数据中心 / DGX / Jetson。注意：解码区块默认折叠，需点 “Click to expand” 展开。
- 打开 Support Matrix，按产品线和编/解码定位到对应表
- 找到型号所在行，读关键列：
- NVENC/NVDEC Generation（代际）与 Total # of NVENC/NVDEC（引擎数）
Max # of concurrent sessions只在编码（NVENC）表里（第 7 列）——所有解码表都没有此列，官方未文档化解码会话上限（与实测"解码无硬限制"一致）
- 回到页面顶部的代际能力总表，用代际查具体格式：
- 编码总表：H.264、HEVC 4K/8K/10-bit/4:4:4/无损、AV1、4:2:2
- 解码总表：MPEG-1/2/4、VC-1、VP8、VP9、H.264、HEVC、AV1 各位深与 4:2:2/4:4:4
关键例外（查表时必看备注）：
- Turing 内部割裂：RTX 20 系是 7 代编码器；GTX 1630/1650 GDDR5/MX550 仍是 6 代（Pascal 水平）
- Hopper H100、A100/A30：NVDEC 停留在 4th Gen（Turing 水平），无 AV1 解码，且无 NVENC
- Maxwell 二代高端卡（GTX 970/980/Titan X）：NVDEC 仅为 1st Gen，不支持 HEVC/VP9 解码；仅 GM206（GTX 750/950/960）支持
- Pascal 的 VP8/VP9 10-bit 解码按芯片分裂：GP104 有 VP8 无 VP9 10-bit；GP102/106/107 相反
- 大量低端型号（MX 系列、GT 1030 编码端等）无媒体引擎
2.2 查单引擎性能基准
打开 NVDEC Application Note → Table 2 “NVDEC decoding performance (indicative)”：
| 架构 | H.264 | VP9 | VP9 10-bit | HEVC | HEVC Main10 | AV1 |
|---|---|---|---|---|---|---|
| Pascal | 694 | 846 | — | 810 | 789 | — |
| Turing | 771 | 932 | 925 | 1316 | 1158 | — |
| Ampere | 748 | 1075 | 1120 | 1415 | 1299 | 790 |
| Ada | 903 | 1290 | 1342 | 1641 | 1520 | 1018 |
| Blackwell | 2172 | 1445 | 1498 | 1872 | 1818 | 1119 |
单位：帧/秒，1080p YUV 4:2:0，单 NVDEC 引擎，各代最高视频时钟下实测
（基准时钟：Pascal 1544 / Turing 1860 / Ampere 1665 / Ada 2160 / Blackwell 2362 MHz）
2.3 三个工具各管各的（重要，别混淆）
| 想知道什么 | 用什么 | 说明 |
|---|---|---|
| 视频时钟多少 MHz | nvidia-smi -q -d CLOCK | 硬件频率，直接读取；看 Clocks → Video 和 Max Clocks → Video |
| 实际解得多快（fps） | ffmpeg ... -f null - | 跑真实解码，看输出里的 fps= 值 |
| 解码时时钟与利用率变化 | nvidia-smi --query-gpu=index,clocks.video,utilization.decoder --format=csv -l 1（每秒刷新，含 Video Clock）或 nvidia-smi dmon -s uc | 边解码边实时观察（dec 列 = 解码器利用率 %）。注意 dmon 指标字母须连写，-s u,c 带逗号会报错；dmon 时钟列不含 Video Clock |
Clocks → Video 与 Max Clocks → Video 的区别（什么时候用哪个）：
字段 含义 什么时候看 Clocks → Video当前视频时钟，实时动态变化（空闲时自动降频，如 555 MHz） 实时监控/排查问题时用 Max Clocks → Video视频时钟的上限，硬件能力天花板（如 1950 MHz） 计算吞吐量永远用这个
- GPU 空闲时视频引擎自动降频省电；一旦开始解码，驱动会在毫秒内 boost 到接近上限，无需人工干预
- 用空闲时的当前值计算会严重低估能力；解码中当前值升到接近 Max 属正常
- 排查：解码中当前值卡在低位不升 → 负载太轻未触发 boost，或有功耗/温度墙（用
nvidia-smi -q -d PERFORMANCE查降频原因）一句话：计算用上限，监控看现值。
注意：ffmpeg 命令测的是解码速度（fps），不是视频时钟；时钟只能通过 nvidia-smi 读取。
2.4 实测校准（理论值一般打 8~9 折）
# 单路纯解码跑分（测 fps，不测时钟；单趟解码各版本均可，循环用法见下方注意事项）
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -f null -
参数含义：
-hwaccel cuda— 用 NVDEC 硬件解码-hwaccel_output_format cuda— 解码帧保留在显存，避免拷回内存成为瓶颈（否则测出的不是 NVDEC 真实速度）-f null -— 输出丢弃，不编码、不写盘，排除干扰
运行后看输出末尾的 fps= 值，即为实测解码帧率。示例（RTX 3090 + 1080p25 H.264 测试片实测）：
frame= 4679 fps= 873 q=-0.0 ... time=00:03:07.16 ... speed=34.9x
实测 873 fps ≈ 理论计算 876 fps（3.2 节第二步），误差仅 0.3%——说明时钟缩放公式可靠。你的卡/片源不同，数值会不同，用自己的实测值代入第三章公式即可。
推荐验证姿势（两个窗口同时开，一次验证两件事）：
# 窗口 1：跑解码测试
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -f null -
# 窗口 2：实时观察时钟 boost 与解码器利用率
nvidia-smi --query-gpu=index,clocks.video,utilization.decoder --format=csv -l 1
解码开始后可看到：Video Clock 从空闲值 boost 到接近 Max 值，dec 利用率逼近 100%——即时钟拉满 + 单引擎性能到顶，两者同时确认。
ffmpeg 使用注意事项（实测踩过的坑）：
- 后台批量跑 ffmpeg 必须加
-nostdin：ffmpeg 默认从 stdin 读交互命令，后台进程无终端输入会被 SIGTTIN 挂起（jobs 显示 Stopped，实际没在解码） - ffmpeg 4.4 的坑是
-stream_loop×-hwaccel_output_format cuda组合（不是不支持 cuda 输出格式）：单趟解码完全正常（实测 873 fps ≈ 理论 876）；但加-stream_loop -1循环时，循环重放点重建滤镜链失败（Error reinitializing filters! / Conversion failed!），所有进程启动即退出。循环压测时二选一：去掉 cuda 输出格式（自动下载回内存，1080p 场景 PCIe 带宽足够），或升级 ffmpeg 6.x/7.x - 清理后台测试进程用
pkill -9 -f stream_loop（单词匹配，带-nostdin的命令行也能匹配到）
Windows 下还可用 DXVAChecker 直接列出每个格式支持的最大分辨率/帧率。
三、怎么计算
3.1 核心公式
单引擎吞吐(fps) = 官方基准 fps × (本卡 Max Video Clock ÷ 基准时钟)
聚合吞吐 = 单引擎吞吐 × NVDEC 引擎数量 ← 仅多路并发时有效
实时路数 = 聚合吞吐 ÷ 目标帧率
最终路数 = min( 实时路数 , 显存允许的路数 ) ← 解码无驱动会话锁，详见第四章
显存允许的路数 = 显存总量 ÷ 每路实占显存。 每路实占多少取决于架构（停车位比喻：解码缓冲是"车位"，CUDA 上下文是每进程独占的"门卫室"）：
| 架构 | 每路实占（1080p） | 24GB 可容纳 |
|---|---|---|
| 进程式（一路一进程） | ~460MB = 车位 60MB + 门卫室（CUDA 上下文）300~400MB | ~52 路 |
| 单进程多会话（共享 1 个上下文） | ~60MB（门卫室只盖一间，全局摊销） | 数百路，瓶颈回到吞吐 |
分辨率换算：NVDEC 按像素量干活，fps 随像素数反比缩放。以 1080p（约 200 万像素/帧）876 fps 为例：
1080p: 876 fps
4K: 876 ÷ 4 ≈ 219 fps （4K 一帧 = 1080p 的 4 倍像素）
8K: 876 ÷ 16 ≈ 55 fps （8K 一帧 = 1080p 的 16 倍像素）
两条铁律（水管比喻：单引擎吞吐 = 一根固定流量的水管，多路只能分着用）：
- 单路速度 ≤ 单引擎性能——开 1 路最多独享 876 fps；开 35 路每路分 25（刚好实时）；开 52 路每路只剩 17（不够实时）。即使卡上有多个 NVDEC，多引擎也只在多路之间分担（驱动自动负载均衡），无法合起来加速单独一路
- GeForce 每卡只有 1 个 NVDEC——3090 只有一根水管；部分专业卡/数据中心卡有 2~7 根（如 L4 有 4 根），多路容量直接按引擎数翻倍
一句话：先被显存卡住（52 路）还是被吞吐卡住（35 路实时），取决于架构——这正是第六章容量结论的依据。
3.2 计算示例：RTX 3090（完整计算过程）
已知条件（怎么来的）：
| 条件 | 值 | 来源 |
|---|---|---|
| 架构 | Ampere（GA102） | Support Matrix 查 RTX 3090 所在行 |
| NVDEC 引擎数 | 1 个（GeForce 全系单引擎） | Support Matrix Total NVDEC 列 |
| 官方基准吞吐（Ampere，H.264） | 748 fps @ 基准时钟 1665 MHz | NVDEC Application Note Table 2 |
| 本卡 Max Video Clock | 1950 MHz | nvidia-smi -q -d CLOCK → Max Clocks → Video |
| 显存 | 24 GB | 型号规格 |
第一步：算时钟缩放比
官方基准是在 1665 MHz 下测的，本卡能跑到 1950 MHz，性能按比例放大：
时钟比 = 1950 ÷ 1665 ≈ 1.171
第二步：算单引擎吞吐（基准 × 时钟比）
H.264: 748 × 1.171 ≈ 876 fps （实测 873 fps，误差 0.3%，公式验证通过）
HEVC: 1415 × 1.171 ≈ 1657 fps
AV1: 790 × 1.171 ≈ 925 fps
第三步：算实时路数（吞吐 ÷ 目标帧率）
以 H.264 为例：
1080p25: 876 ÷ 25 = 35 路
1080p30: 876 ÷ 30 = 29 路
1080p60: 876 ÷ 60 = 14 路
4K30: (876 ÷ 4) ÷ 30 = 219 ÷ 30 = 7 路 ← 4K 先按像素 ÷4 换算吞吐
4K60: (876 ÷ 4) ÷ 60 = 219 ÷ 60 = 3 路
8K30: (876 ÷ 16) ÷ 30 = 55 ÷ 30 = 1 路 ← 8K 按像素 ÷16
第四步：套显存约束，取较小值
进程式架构：显存允许 = 24GB ÷ 460MB ≈ 52 路
最终路数 = min( 实时路数 , 52 )
完整结果表（H.264 / HEVC / AV1）：
| 场景 | H.264 计算过程 | 结果 | HEVC | AV1 |
|---|---|---|---|---|
| 1080p25 | 876÷25=35，min(35,52) | 35 | min(66,52)=52 | min(37,52)=37 |
| 1080p30 | 876÷30=29，min(29,52) | 29 | 52（显存限） | 30 |
| 1080p60 | 876÷60=14 | 14 | 27 | 15 |
| 4K30 | 219÷30=7 | 7 | 13 | 7 |
| 4K60 | 219÷60=3 | 3 | 6 | 3 |
| 8K30 | 55÷30=1 | 1 | 3 | 1 |
只有 HEVC 1080p 两行撞到显存约束（66/55 > 52），其余场景都是吞吐先成为瓶颈。
若改单进程多会话架构（每路 ~60MB，显存约束≈400 路），所有场景都只看吞吐。
四、会话上限（“撞限”）
核心结论：解码（NVDEC）没有驱动层会话数限制；这个限制只加在编码（NVENC）上。纯解码业务无需关心，此处仅作结论备忘。
| 产品类别 | 编码（NVENC） | 解码（NVDEC） |
|---|---|---|
| GeForce 全系（RTX 50/40/30/20、GTX 16/10 等） | 官方标称 12（早年 2~3，逐步放宽） | 无限制 |
| 入门专业卡（T400/P400/RTX A400 等） | 8 | 无限制 |
| 中高端专业卡 / 数据中心（L4/A10 等）/ DGX / Jetson | 无限制 | 无限制 |
依据：
- 官方 Support Matrix 的
Max # of concurrent sessions列只出现在编码表，所有解码表均无此列 - 编码限制本质是市场区隔策略（多路转码/云游戏是数据中心卡卖点）；一路转码占 2 个会话（解码+编码各 1），本业务纯解码不涉及
提醒：解码没有会话锁 ≠ 能无限开。真实约束有两个：
- 显存——每路占用随架构而不同：进程式架构（一路一进程）每路 ~460MB（含每进程独占的 CUDA 上下文），单进程多会话架构每路仅 ~60MB，同一张卡容量差近 8 倍（详见 3.1）
- NVDEC 吞吐——多路均分单引擎总吞吐（见 3.2）
且"能开起来的路数"≠"每路实时跑满的路数"，最终容量结论见第六章。
五、一页速查：评估流程
① 查 Support Matrix
→ 得 NVDEC 代际、引擎数（解码表无会话上限列；会话锁只在编码侧，本业务不用管）
② 查 NVDEC Application Note Table 2
→ 得该代际单引擎 1080p 基准 fps 和基准时钟
③ nvidia-smi -q -d CLOCK
→ 得本卡 Max Video Clock
④ 套公式
→ 吞吐 = 基准 × 时钟比；实时路数 = 吞吐×引擎数÷帧率；
最终路数 = min(实时路数, 显存总量÷每路显存)
⑤ ffmpeg + nvidia-smi --query-gpu=... -l 1 实测校准（理论打 8~9 折）
六、本业务容量结论（8× RTX 3090，1080p25 H.264）
| 口径 | 单卡路数 | 整机（8 卡） | 约束 |
|---|---|---|---|
| 能开起来（会话/显存，进程式架构） | 52 | ~416 | 显存 ~460MB/进程 |
| 每路实时跑满 25fps | ~35 | ~280 | NVDEC 吞吐 876 fps |
| 全流水线稳定运行（含后处理/推理） | 20~32 | 160~256 | 工程经验水位 |
抽帧模式（-skip_frame nokey 只解关键帧） | ~52 | ~416 | 吞吐约束解除，瓶颈回到显存 |
扩容路径优先级：① 抽帧降负载 → ② 单进程多会话架构（显存每路 460MB→60MB）→ ③ 加卡/换多 NVDEC 数据中心卡。
6452
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
