3、关键参数一：码率（Bitrate）—— 码率越高，延迟越低？事实并非如此简单。

很多人刚接触编码优化时，都会有一个直觉：码率越高，数据量越大，延迟肯定越低。毕竟你给的带宽更宽了嘛。

但实际跑过几轮线上压测之后，你会发现事情没那么简单。我当年第一次调优视频编码参数时，也踩过这个坑——把码率从 2 Mbps 直接拉到 8 Mbps，结果延迟不但没降，反而因为网络拥塞丢包，画面卡得没法看。

今天我们就来把「码率 vs 延迟」这层窗户纸捅破。

码率，简单说就是编码器每秒输出的数据量。单位通常是 bps（bit per second）。

它直接决定了两个东西：

但延迟呢？延迟是数据从编码端到解码端的总耗时。码率影响的是其中两个环节：编码耗时和网络传输耗时。

核心观点：码率对延迟的影响是一条 U 型曲线。过低或过高，延迟都会上升。只有在一个合理的区间内，延迟才能达到最优。

码率设得太低时，编码器为了把数据量压到目标值以下，会做两件事：

我曾在一次直播项目中，把码率压到 500 Kbps 去适配弱网用户。结果编码器单帧处理时间从 8 ms 飙升到 35 ms。为什么？因为它在拼命找「更省比特」的编码方式，计算量翻了好几倍。

这还没完。码率过低时，编码器还会频繁触发 码率控制震荡——场景一复杂，瞬间超出预算，编码器又得紧急降质，画面一会糊一会清楚，延迟也跟着忽高忽低。

避坑指南：我曾经在移动端测试中，把视频码率从 1.5 Mbps 降到 600 Kbps，结果端到端延迟从 200 ms 涨到了 480 ms。不是网络变慢了，是编码器自己卡住了。低码率 ≠ 低延迟，这个误区一定要破除。

码率设得太高，问题就出在传输侧。

假设你的上行带宽只有 10 Mbps，你把码率设到 12 Mbps。会发生什么？

这一套下来，延迟直接爆炸。我见过一个案例：某厂商把码率设到带宽上限的 1.3 倍，结果延迟从 150 ms 飙升到 1.2 秒，用户直接骂娘。

而且码率过高还会引发 TCP 拥塞控制 的连锁反应。TCP 检测到丢包后会主动降低发送速率，然后编码器还在拼命往外吐数据，两者形成恶性循环。

我的建议：码率不要超过可用带宽的 80%。留出 20% 的余量给网络抖动和重传。这是我在多个线上项目中验证过的安全阈值。

为了让你看得更清楚，我画了一张关系图。它展示了码率从低到高时，延迟各组成部分的变化趋势。

从图上可以看得很清楚：

码率没有「万能值」。它取决于你的分辨率、帧率、内容类型和网络条件。下面是我在实际项目中积累的参考数据：

一个小技巧：如果你不确定码率设多少合适，可以用 2 倍分辨率经验法则——码率（Mbps）≈ 分辨率（百万像素）× 2。比如 720p 约 0.92 百万像素，码率 ≈ 1.8 Mbps。然后根据内容动态微调。

除了码率数值本身，码率控制模式也会影响延迟。常见的模式有三种：

我个人在实时系统中几乎只用 CBR。虽然它牺牲了一部分编码效率，但延迟的可预测性比什么都重要。你想想看，如果延迟一会 100 ms 一会 500 ms，用户端做缓冲策略会非常痛苦。

注意：如果你用 VBR 做直播，一定要设置最大码率上限。我曾经见过一个案例，VBR 在复杂场景下码率飙到设定值的 3 倍，直接把 CDN 节点打挂了。设个 cap，保平安。

码率对延迟的影响，不是简单的线性关系。它是一道「既要…又要…」的平衡题：