OBS + NVENC 录制参数全解析

1.1 不压缩会有多大#

1920×1080 的一帧画面，按最基础的 YUV420 格式（每像素平均 12bit）算，体积大约 3MB 出头。60fps 的话，一秒钟原始数据量接近 190MB，换算成码率大约 1.5Gbps。这是完全没法存储或传输的数字——视频编码器存在的全部意义，就是想办法把这 1.5Gbps 压到几十 Mbps 甚至更低，同时让人眼看不太出差别，压缩比经常要做到 50~100 倍以上。

能压这么狠，靠的是两类“冗余”——画面里那些信息量不大、可以被预测出来的部分。

1.2 帧内压缩：一张画面自己的水分#

单独看一帧画面，天空是大片相近的蓝色，墙壁是大片相近的白色，相邻像素之间高度相关，不需要每个像素都独立记录完整信息，这就是空间冗余。JPEG 压缩照片、HEVC/H.264 里的**帧内预测（Intra Prediction）**利用的都是这种冗余：用已经解码的相邻像素去预测当前像素，只记录“预测值和实际值的差”，而不是完整像素值。

1.3 帧间压缩：帧与帧之间的水分#

视频比单张图片好压缩得多，原因在于还存在时间冗余——相邻两帧之间，绝大多数内容根本没怎么变（没剪切的话，背景可能完全没动，只有画面里一小块在动）。与其把下一帧完整重新编码一遍，不如告诉解码器：“这一块内容和上一帧那一块基本一样，只是往右移动了 3 像素”，这就是运动估计（Motion Estimation）和运动补偿（Motion Compensation）——编码器在参考帧里搜索内容最相似的区域，记录一个运动矢量加上很小的残差（预测值和实际值的差），数据量比重新编码整块像素小得多。

后面第三章会讲到，编码器“预设”越慢，很大一部分开销就花在把这个运动搜索做得更精细上。

1.4 三种帧：I、P、B 到底是什么#

有了帧内/帧间预测的概念，三种帧类型就清楚了：

I 帧（Intra frame，帧内帧/关键帧）：完全不参考任何其他帧，只用帧内预测，自己就能独立解码。放弃了时间冗余，压缩效率最低、体积最大，但它是“锚点”——解码器必须先拿到一个 I 帧才能开始解码后续依赖它的帧，拖动进度条本质上就是跳到最近的 I 帧开始解码。这也是为什么 OBS 要单独设“关键帧间隔”：间隔越短，跳转定位越精确，但 I 帧多了压缩效率就越低。

P 帧（Predictive frame，前向预测帧）：只参考“过去”已解码的帧（可以是 I 帧，也可以是更早的 P 帧），做单向运动预测。利用了时间冗余，比 I 帧小得多。

B 帧（Bidirectional frame，双向预测帧）：这是最容易被一句话带过、但其实最值得展开的部分。B 帧可以同时参考前面和后面的帧——“后面”指显示顺序上还没播放到的帧，但在编码/解码顺序上其实已经先被处理过了（马上解释）。因为能从两个方向找参考，B 帧压缩效率通常最高，原因主要两个：

1. 缓解遮挡问题（occlusion）：如果画面里一个物体从背景前面移开，露出了原本被挡住的背景，这块新露出来的内容在“过去”的帧里根本不存在（被挡住了），P 帧没法从过去找到匹配；但在“未来”某一帧，这块背景可能已经完整可见，B 帧就能从未来帧把这块内容“借”过来。反过来，某个东西即将被遮挡的情况，过去帧有完整信息、未来帧没有，B 帧同样可以选择从过去借。B 帧本质上是“哪边预测准就用哪边，甚至两边加权平均”，可选余地比单向的 P 帧大得多，残差自然更小。
2. 加权双向预测：B 帧还能把前后两个参考各取一部分加权平均作为预测值，对匀速运动或渐变内容，这个“平均”往往比任何单一方向的预测都更接近真实画面。

1.5 编码顺序 ≠ 播放顺序：GOP 是怎么排的#

因为 B 帧要参考“未来”的帧，直接后果是：B 帧必须等它需要参考的那个未来帧先被编码/解码出来，才能轮到自己。所以视频文件内部，编码/解码顺序和最终播放顺序是不一样的。举个简化的典型 GOP（Group of Pictures，画面组）排列：

1
播放顺序:      I1    B2    B3    P4    B5    B6    P7
2
参考对象:      -    I1,P4 I1,P4  I1   P4,P7 P4,P7  P4
3

4
编码/解码顺序: I1 → P4 → B2 → B3 → P7 → B5 → B6

可以看到，P4 虽然显示在 B2、B3 后面，却必须最先被编码出来，因为 B2、B3 要参考它。解码器拿到码流后，先按编码顺序解码，再按显示顺序重排后播放——这也是为什么大量用 B 帧的视频流需要更大的解码缓冲区，直播场景对延迟更敏感（第三章会讲到“低延迟”调节模式为什么会压缩 B 帧的使用）。

（这里为了讲清楚机制，用了每两个锚点之间插 2 个 B 帧的简化例子。速查表里“B 帧=4”这个数值代表的是最多允许连续多少个 B 帧，编码器结合前向考虑动态决定每一段实际用几个，不是每段都死板地按 4 来。）

从一个 I 帧到下一个 I 帧之前的这一整段，就是一个 GOP,GOP 的长度对应 OBS 里的“关键帧间隔”。

1.6 参考 B 帧：B 帧还能不能被别人参考#

正常情况下，B 帧是参考链的“末端”——只有 I 帧和 P 帧会被其他帧参考，B 帧用完就扔，不会被别的帧当参考对象（实现最简单，但也浪费了一部分潜力，因为 B 帧画质通常不差）。

NVENC（以及 x264/x265 等软件编码器）支持的**“B 帧作为参考帧”，允许 B 帧本身进入参考帧候选池，后面的 B 帧可以参考更靠近自己的 B 帧，而不必跨越更远距离去参考 I/P 帧。参考距离越近，内容变化通常越小、预测越准，残差越小，压缩效率进一步提升。这套机制业内一般叫分层 B 帧（hierarchical B-frames）或B 金字塔（B-pyramid）**。举个最简化的例子，连续 3 个 B 帧，只让中间那一帧被两边参考：

1
不开参考B帧:   P b b b b P    (每个b都只参考P,互相独立)
2
仅中间帧模式:  P b B b P      (中间的B先解码,成为两边b的参考点)

NVIDIA 在 2018 年 GTC 的一次分享里给过具体数字：这种“中间帧做参考”排列相比完全不参考，BD-PSNR 大约能提升 0.3dB。不过这组数据当时针对的是 H.264——那一代 NVENC 硬件其实还不支持 HEVC 的 B 帧，HEVC 的 B 帧要到后面几代 NVENC 硬件才加入。这也是为什么 GTX 10 系这类较老显卡不是“参考 B 帧可能有兼容性问题”，而是根本不支持 HEVC 的 B 帧这个功能，这一点是硬指标，不是概率性的兼容问题。

OBS“参考 B 帧”下拉框对应 NVIDIA API 里 disable/middle/each 三档中的后两档，“每一帧”（EACH）比上面例子里的“仅中间帧”（MIDDLE）更进一步——不止一帧能被参考，而不只是每组的正中间那帧。这里还有个值得知道的实际情况：NVIDIA 开发者论坛上有比较具体的报告，525/550 这两个驱动版本下，HEVC+“仅中间帧”模式组合会出现可测量的画质回退（VMAF 从 82.7 掉到 82 左右），但同样条件下“每一帧”模式没有这个问题。速查表里选的正是“每一帧”，不仅原理上更彻底，也刚好避开了这个已知问题。

无论选哪一档，代价都是编解码依赖链更复杂（需要在内存里维护更多参考帧），但对现代硬件这点开销完全不是问题——只要 B 帧数量大于 1，打开这个选项基本没理由不开。

2.1 量化（Quantization）：有损压缩的真正源头#

上一章讲的运动预测、帧内预测，严格说还没真正“丢弃”画面信息，只是把数据表达得更紧凑（残差本身通常就很小）。真正让视频编码变成有损压缩、让画质和码率之间出现权衡的一步，是量化。

预测完成后，残差（或帧内预测的差值）会先经过一次类似 DCT（离散余弦变换）的数学变换，把空间上的像素差值转换成“频域”系数——低频系数代表画面大体轮廓/渐变趋势，高频系数代表细节和噪点。量化，就是把这些系数统一除以一个“量化步长”再四舍五入取整——步长越大，越多细小系数会被直接舍入成 0，信息就这样被丢掉，压缩率越高，画质损失也越大。

这个“步长”由**QP（Quantization Parameter，量化参数）**控制，这是理解后面几乎所有画质/码率设置的核心概念。

2.2 QP、CRF、“目标质量”其实是一回事#

不同编码器叫法不同，本质相同：

• H.264/HEVC 标准本身定义的参数叫QP，取值 0-51，数字越小量化步长越小（越精细），画质越好、体积越大，反之亦然。
• x264/x265 提供了更顺手的**CRF（Constant Rate Factor，恒定速率因子）**模式，本质是让编码器根据内容动态调整每帧实际 QP，但整体锚定在你设的 CRF 数值附近波动，兼顾了固定 QP 的画质稳定性和内容自适应能力。
• OBS 里 NVENC 的**“目标质量”**，取值范围同样是 0-51（0 代表自动），概念上和 CRF 基本等价——你设的不是死 QP，而是编码器努力维持的“质量目标”，实际每帧用的 QP 会跟着内容复杂度浮动。

这几个概念数值范围一致不是巧合，都是从 H.264/HEVC 标准原生的 QP 刻度延伸出来的。

还有一条很实用的经验规律：QP 每变化 6，码率大致翻倍或减半（QP 升 6→ 步长翻倍 → 码率减半；QP 降 6→ 步长减半 → 码率翻倍）。这是因为标准里 QP 到量化步长的映射本身就是按“每 6 个 QP、步长翻一倍”设计的。所以目标质量从 22 调到 28，文件大概会缩小到一半左右；调到 16，大概会翻倍——这条规律能帮你快速估算调整数值大致带来多大的文件体积变化，不用每次都实测。

2.3 四种码率控制模式：到底该用哪个#

“比特率控制”下拉菜单本质是在选“用什么策略决定每一帧实际花多少码率”：

CBR（恒定码率）：不管画面简单还是复杂，尽量把码率摁在固定值附近。优点是码率可预测，不会有突发峰值冲垮直播上传带宽，这是直播平台几乎强制要求 CBR 的原因；缺点是简单画面“浪费”码率，复杂画面又可能因为码率不够出现糊/块状瑕疵。

VBR（可变码率，传统意义）：围绕一个目标平均码率上下浮动，比 CBR 灵活一点，但本质还是“以码率为中心”，不直接保证画质稳定。

CQP（恒定量化参数）/CRF：反过来，“以画质为中心”——固定质量目标，让编码器自己决定每帧该花多少码率来达到这个质量，简单场景自动省码率、复杂场景自动加码率。本地录制几乎总应该用这一类，因为通常不缺存储空间（不像直播不能缺带宽），追求的是稳定一致的画质。

CQVBR（具有目标质量的可变比特率）：NVENC 相对较新加入的模式，是 CQP 思路的加强版——本质还是按质量目标动态分配码率，但额外允许设一个“最大码率”上限兜底，防止极端复杂/高噪点画面把码率顶到离谱数值。对录制来说，这基本是 CQP 的全面升级：既有画质导向的核心逻辑，又多一层保险，所以 OBS 默认推荐的 CQVBR，是目前录制场景下的最优解。

“最大比特率”这一项，就是 CQVBR 这层安全网的具体数值——正常内容根本触发不到（目标质量 22,1080p 正常码率也就一二十 Mbps 量级，离 100Mbps 上限差得远），它存在的意义只是防御极端情况。

2.4 自适应量化（AQ）：把码率花在人眼真正在意的地方#

没有 AQ 的情况下，编码器倾向于对整帧画面用相对一致的 QP。但人眼对不同类型区域的“容错度”其实很不一样：

• 大片平坦/渐变区域（天空、白墙、皮肤大面积区域）：细节本身很少，理论上花很少码率就“够用”，但人眼对这类区域出现的色带、糊状瑕疵极其敏感——没有别的纹理去掩盖瑕疵，一旦出现马上就能看出来。
• 复杂/高频纹理区域（草地、树叶、水波纹、颗粒感强的画面）：信息量本身大，如果按统一标准量化，需要花大量码率才能维持和平坦区域同样的数学误差水平。但恰恰是这类区域，人眼对量化噪声的敏感度反而更低——真实的复杂纹理会天然“掩盖”量化引入的误差，这在心理视觉领域叫掩蔽效应（masking effect）。

所以 AQ 真正做的事情是：把平坦区域的 QP 调低（更精细、多花相对码率），把复杂纹理区域的 QP 调高一些（更粗糙、省一点码率）——总码率不变的前提下，平坦区域不容易出现难看色带，复杂区域即使量化粗糙一点人眼也很难察觉，总体主观画质因此提升，即使从纯数学误差（PSNR）角度看总分不一定更高。

这也是为什么 AQ 几乎“零成本高回报”：几乎不增加额外编码耗时，但对主观画质的提升往往很明显，保持开启没有争议。

（NVENC 底层其实还有”Temporal AQ”的概念，针对画面里长时间静止不变的区域，防止这类区域因编码器逐帧重新分配码率而出现肉眼可见的“画质忽好忽坏”闪烁感，和这里的 Spatial AQ 是互补的两个维度，不过 OBS 界面目前只暴露一个开关，对应的是 Spatial AQ。）

3.1 NVENC 是什么，为什么“不花钱”#

NVENC 是 NVIDIA 显卡芯片上独立的一块专用硬件编码电路，和负责游戏渲染的 CUDA 核心物理上是分开的模块。用 NVENC 编码录制，理论上完全不占用游戏渲染性能（前提是显存带宽、PCIe 带宽等共享资源没打满），这也是为什么“一边打游戏一边录屏”首选硬件编码而不是吃满 CPU 的 x264 软件编码。如果 P7 都吃不满显卡，本质上就是这块独立电路的算力相对录制分辨率/帧率还有富余——现在中高端显卡的 NVENC 单元性能相当充裕，这完全合理。

3.2 P1-P7 预设：编码器到底在“变慢”什么#

预设数字越大越慢、画质效率越高，变慢的时间基本花在这几件事的“穷举”程度上：

• 运动搜索范围与精度：快预设只在参考帧里搜索较小窗口、用较粗像素精度找运动矢量；慢预设搜索范围更大，能细化到亚像素级别（比如四分之一像素精度），找到的运动矢量更准，残差更小。
• 块划分决策：HEVC 把画面切成最大 64×64 的CTU（Coding Tree Unit，编码树单元），并可以递归再切成更小的块（最细到 8×8）。要给每一小块画面找到“切多细最划算”的答案，理论上需要挨个试不同切法、比较每种切法的“码率-画质”性价比，这个过程叫RDO（Rate-Distortion Optimization，率失真优化）。快预设用经验公式走捷径估算，慢预设做更穷尽的实际尝试比较。
• 预测模式选择：同理，帧内预测有十几种角度方向可选，帧间预测有多种模式（merge/skip 等）可选，慢预设会尝试更多候选再挑最优。

这些“多算几遍、多试几种可能”的工作，本质是拿编码时间换压缩效率——同样目标画质，预设越慢，最终文件通常越小；反过来说，同样码率，预设越慢画质越好。只要 NVENC 算力有富余、编码没掉帧，拉到 P7 几乎没理由不用。

3.3 调节（Tuning）：针对内容特性的策略预设#

“调节”本质是一整套配套参数的预设组合，针对不同场景优化：

• 低延迟：牺牲前向考虑的窗口大小、减少或不用多次编码，换取尽量小的编码延迟，直播/实时通讯场景用。
• 高质量：允许编码器充分利用前向考虑、多次编码等“慢工出细活”的手段，不特别在意延迟，录制/点播场景的标准选择。
• 超高质量：是“高质量”的加强版，专门针对真实摄像头拍摄内容里天然存在的传感器噪点做了特殊处理——普通编码器容易把噪点误判成“真实细节”从而浪费码率硬啃这些噪点，这个模式对此有专门优化，但计算量显著更高、吞吐量明显下降。纯游戏画面/屏幕录制本身没有传感器噪点，用不上这个模式的核心优势，选“高质量”就够。
• 无损：直接跳过量化步骤（或量化步长设到最小），数学上完全无损，代价是文件大小会离谱地大，一般只在特殊的工业/母版场景用得到。

3.4 前向考虑 vs 多次编码：两种不同的“未卜先知”#

这两个概念容易被搞混，但机制不一样：

**前向考虑（Look-ahead）**是在单次编码过程中，编码器在正式决定“这一帧怎么编”之前，先往后“偷看”一小段窗口（比如未来十几到几十帧）的内容，不真的编码它们，只是分析个大概，帮当前帧做更聪明的决策——比如提前发现几帧之后要切镜头了，就提前在切镜头前多留点码率余量，或者提前判断哪些帧适合编码成 B 帧。这是一个“滚动窗口”式的轻量分析，编码过程本身还是一次性顺序往前走。

**多次编码（Multi-pass）**则是真的把流程完整走两遍：第一遍（分析遍）对内容做一次通盘扫描，统计整体复杂度分布；第二遍（正式编码遍）才根据第一遍摸到的全局信息做真正的码率分配和编码。这比单纯前向考虑掌握的信息更全面（不受“窗口大小”限制），效果自然更好，但耗时也更长——“全分辨率”是分析遍也在原始像素分辨率下进行，信息最准确但最耗资源；“四分之一分辨率”是分析遍先把画面缩小四分之一再分析，牺牲一点分析精度换速度。

两者并不互斥。前向考虑和全分辨率二次编码同时开启，相当于“边走边看”加上“回头复查”，是目前 NVENC 能给到的最高质量组合，前提是显卡算力跟得上。

4.1 CTU：比 H.264 宏块更灵活的积木#

H.264 把画面固定切成 16×16 的宏块（Macroblock）作为基本处理单元，不管画面内容是大片天空还是密集文字，都用同一网格粒度处理。HEVC 引入CTU（编码树单元），最大可以到 64×64，并能按四叉树递归细分到最小 8×8——一大片平坦天空可以直接用一个 64×64 的大块高效处理，复杂区域再细分成小块精细处理。这种“该粗则粗、该细则细”的灵活性，是 HEVC 同等画质下比 H.264 省下大约一半码率的核心原因之一。这也是为什么 HEVC 虽然编码更耗算力，但只要有 NVENC 这种专用硬件加速，选 HEVC 而不是 H.264 几乎稳赚不赔。

4.2 Main10：即使源内容是 8-bit，也建议选它#

HEVC 的“配置文件（Profile）”决定编码器允许用哪些工具集，Main 只支持 8-bit 色深（每个颜色通道 256 级），Main10 额外支持 10-bit（每个通道 1024 级）。即使画面源头（游戏渲染输出、录屏采集）本身是 8-bit 的，用 Main10 编码依然有实际好处：量化这一步是在 10-bit 精度下舍入，相比直接在 8-bit 精度下舍入，引入的误差被摊薄到更细的刻度上，对大片渐变区域（天空、暗部阴影）出现色带的抑制效果更好。现在主流播放器、剪辑软件（Premiere、DaVinci Resolve 等）对 Main10 支持都很成熟，兼容性基本不是问题，这也是为什么“配置文件”建议直接选 main10，没有明显下行兼容性代价。

5.1 FLAC：无损音频压缩的原理#

有损音频编码（AAC、MP3 等）会用一套**心理声学模型（psychoacoustic model）**去判断人耳大概率听不出来的频率成分，直接丢弃换取体积——这个过程本质上和视频的量化异曲同工，都是利用人体感知的局限性丢弃信息。

FLAC 完全不做这种“猜人耳听不出来”的判断，用的是线性预测编码（linear prediction）——根据前面若干个采样点预测下一个采样点大概是多少，只记录预测值和实际值的差（这个差通常很小，数值上更容易压缩），再配合**熵编码（比如 Rice 编码）**进一步压缩这些差值。整个过程完全可逆，解码出来的波形和原始录音在比特层面完全一致，这就是“无损”的含义。代价是压缩比远不如 AAC/MP3（FLAC 通常只能把体积压到原始 PCM 的 50%~70%左右，而 AAC 能压到 10%以下），换来的是零音质损失。

5.2 音轨、缩放输出、自动分割文件#

这几项和编码原理关系不大，更多是工程实践层面的考量：

• 音轨：OBS 最多支持 6 条独立音轨同时写入同一个录制文件，可以把不同音源（麦克风、桌面音效、游戏声等）分别路由到不同轨道，方便剪辑软件里单独调整音量/降噪，不会牵一发动全身。
• 重新缩放输出：在编码前先把画面缩小或放大到指定分辨率。录制阶段做缩放，损失的细节以后没法补回来，所以除非有非常明确的理由（比如存储空间紧张到必须牺牲分辨率），否则建议保持禁用、按原始分辨率录制，缩放的决定权留给后期剪辑导出阶段。
• 自动分割文件：长时间录制时按时间或大小把输出切成多个文件。除了防止单文件过大，更实际的好处是容错——如果中途死机、断电，已经分割完成的前面几段基本不受影响，只损失最后正在写入的一小段；不开分割的话，整个文件的索引信息通常要等录制正常结束才写完整，中途意外中断很可能导致整个文件损坏无法播放。