16、带宽估计器调优：Trendline滤波器参数、丢包率阈值、基于延迟与丢包的混合估计
带宽估计器，说白了就是WebRTC的“油门”。
它决定了一路视频通话能跑多快，画质能有多清晰。我见过太多项目，明明网络不差，但画面糊成一团，或者卡成PPT——十有八九是带宽估计器没调好。
今天咱们就聊聊怎么调优它。重点放在三个地方：Trendline滤波器的参数、丢包率阈值、以及延迟与丢包的混合估计策略。
16.1 Trendline滤波器：延迟信号的“去噪器”
先说说Trendline。它负责从RTP包的到达时间中，提取出“延迟趋势”。
说白了，就是判断网络是不是开始堵了。
但原始数据噪声很大。Wi-Fi抖动、CPU调度、甚至网卡中断，都会让到达时间忽快忽慢。Trendline的作用，就是把这些噪声滤掉，留下真实的排队延迟信号。
16.1.1 核心参数：窗口大小与平滑系数
Trendline有两个关键参数：
- 窗口大小（window size）：默认20个包。我习惯说“观察窗口”。
- 平滑系数（smoothing factor）：默认0.9。用于指数加权移动平均（EWMA）。
窗口越大，对突发抖动的容忍度越高，但反应也越慢。窗口越小，反应快，但容易误判。
我的经验：
在Wi-Fi环境下，我建议把窗口从20调到30-40。Wi-Fi的突发抖动太频繁了，20个包的窗口经常误报“网络拥塞”，导致带宽被低估。调大窗口后，误报率明显下降。
平滑系数0.9意味着当前值只占10%权重，历史值占90%。这会让趋势变化非常平滑。如果你希望更快响应，可以降到0.8。但小心——降太多，噪声也跟着进来了。
16.1.2 代码层面的调优点
在WebRTC源码中，Trendline滤波器位于modules/remote_bitrate_estimator/trendline_estimator.cc。
// 默认参数
constexpr double kDefaultSmoothingCoeff = 0.9;
constexpr size_t kDefaultWindowSize = 20;
// 我常用的Wi-Fi优化参数
constexpr double kSmoothingCoeffWiFi = 0.92;
constexpr size_t kWindowSizeWiFi = 35;嗯，这里要注意：改了参数后，一定要做回归测试。我曾经在某个项目中把窗口调到50，结果延迟信号完全“钝化”了，带宽估计跟不上网络变化，反而更糟。
16.2 丢包率阈值：别让丢包“背锅”
丢包率是带宽估计的另一个重要信号。但丢包率本身很“脏”。
为什么？因为丢包可能是拥塞导致的，也可能是无线链路的随机丢包。如果是后者，你降带宽就亏了——明明网络不堵，却自废武功。
16.2.1 阈值怎么设？
WebRTC默认的丢包率阈值是：
- 上升阈值：2% —— 丢包率超过2%，开始考虑降低带宽。
- 下降阈值：1% —— 丢包率低于1%，可以尝试增加带宽。
这两个阈值，我建议根据网络类型做差异化：
| 网络类型 | 上升阈值 | 下降阈值 | 说明 |
|---|---|---|---|
| 有线/企业网 | 2% | 1% | 丢包极少，阈值可以严格 |
| Wi-Fi | 5% | 2% | 随机丢包多，放宽阈值 |
| 4G/5G | 3% | 1.5% | 介于两者之间 |
我曾经踩过的坑：
有一次在商场部署视频通话，Wi-Fi环境下丢包率经常跳到3%-4%。默认的2%阈值导致带宽被频繁压低，画面一直在360p和720p之间来回跳。用户投诉“画面忽好忽坏”。后来我把上升阈值调到5%，问题解决了。
16.3 混合估计：延迟与丢包，谁说了算？
WebRTC的带宽估计器，其实是个“双引擎”系统：
- 基于延迟的估计（Trendline + 过载检测器）
- 基于丢包的估计（丢包率 + 码率公式）
最终带宽取两者的最小值。这叫“混合估计”。
16.3.1 为什么需要混合？
延迟信号反应快，但容易误判。丢包信号准确，但反应慢（需要等丢包发生）。
两者互补。延迟先降，丢包后补——这是理想情况。
但实际中，两者可能打架。比如：
- 延迟上升了，但丢包率很低 → 可能是网络抖动，不是拥塞。
- 丢包率很高，但延迟没变化 → 可能是无线随机丢包，不是拥塞。
混合估计的核心，就是在这两个信号之间做权衡。
16.3.2 调优策略：权重分配
WebRTC默认的策略是“取最小值”。但你可以调整每个估计器的“可信度”。
我个人习惯的做法是：
- 延迟优先：在低延迟场景（如视频会议），让延迟估计器占主导。延迟一上升，立刻降带宽。
- 丢包兜底：在弱网场景（如移动端），让丢包估计器占主导。延迟抖动太频繁，不如等丢包确认后再降。
具体怎么调？看一个例子：
// 延迟估计器输出：500kbps
// 丢包估计器输出：800kbps
// 默认取最小值 → 500kbps
// 如果我把丢包估计器的权重调低（比如乘以0.8）：
// 丢包估计器输出：800 * 0.8 = 640kbps
// 取最小值 → 500kbps（还是延迟说了算）
// 如果我把延迟估计器的权重调低（比如乘以0.7）：
// 延迟估计器输出：500 * 0.7 = 350kbps
// 取最小值 → 350kbps（丢包反而成了瓶颈）嗯，这里的关键是：权重调整要谨慎。调得太极端，会失去混合估计的优势。
16.4 一张图看懂整体逻辑
下面这张图，展示了带宽估计器的核心流程：
从图中可以看到，延迟和丢包两条路径最终汇合到混合估计器。混合估计器输出最终带宽，再反馈给编码器调整码率。
16.5 实战调优清单
最后，我整理了一份调优清单，方便你在项目中对照检查：
- 确认网络类型：Wi-Fi、4G、有线？不同网络用不同参数。
- 调整Trendline窗口：Wi-Fi环境建议30-40，有线环境20足够。
- 调整平滑系数：0.9是安全值，想更快响应可以降到0.85。
- 设置丢包率阈值：Wi-Fi上升阈值放宽到5%，有线保持2%。
- 测试混合估计权重：低延迟场景让延迟主导，弱网场景让丢包兜底。
- 做回归测试：每次改参数后，跑一遍网络模拟器（如Chrome的NetLog）。
一个小技巧：
调参时不要一次改多个。先改Trendline窗口，跑一天日志；再改丢包阈值，再跑一天。这样你能清楚知道每个参数的影响。我见过有人一口气改了五个参数，结果带宽估计崩了，都不知道是哪个参数的问题。
带宽估计器调优，说白了就是跟网络噪声做斗争。没有万能参数，只有不断试错和观察。希望今天的分享，能帮你少走一些弯路。