10、Trendline滤波器：线性回归模型、趋势线斜率计算、窗口大小选择、与卡尔曼滤波的对比
说到WebRTC的拥塞控制，Trendline滤波器是个绕不开的核心模块。我最早接触它的时候，觉得这玩意儿不就是个线性回归嘛，有啥好研究的？后来在项目中踩了坑才发现，里面的门道比想象中多得多。
说白了，Trendline滤波器干的事情很简单：根据延迟变化趋势，判断网络是否开始拥塞。但怎么判断、用什么模型、窗口开多大，这些细节直接决定了算法的鲁棒性。
10.1 线性回归模型：最小二乘法的应用
Trendline的核心是一个一维线性回归模型。我们拿到的输入数据是时间戳和对应的延迟梯度（delay gradient）。延迟梯度怎么算？其实就是相邻两个数据包的接收时间差减去发送时间差。
嗯，这里要注意：我们不是直接用原始延迟，而是用延迟梯度。为什么？因为这样可以消除发送端和接收端时钟不同步带来的偏差。我在项目中遇到过，如果不做这个处理，时钟漂移会直接把趋势线带偏。
线性回归的目标是拟合一条直线：
y = kx + b其中x是时间，y是延迟梯度，k就是我们要的趋势线斜率。WebRTC用的是最小二乘法，公式如下：
k = (n * Σ(xy) - Σx * Σy) / (n * Σ(x²) - (Σx)²)你想想看，这个公式其实就是在找一条线，让所有数据点到这条线的垂直距离平方和最小。道理很简单，但实际工程实现时要注意数值稳定性。
10.2 趋势线斜率计算：从数学到工程
斜率k是Trendline的输出，也是拥塞判断的依据。k > 0 表示延迟在增加，网络可能开始拥塞；k < 0 表示延迟在减小，网络在恢复。
但这里有个坑：斜率的大小怎么解读？WebRTC的做法是设定一个阈值，当斜率超过某个值时就触发拥塞信号。这个阈值不是固定的，它会根据网络状况动态调整。
我记得有一次调试，发现斜率一直在0.01附近抖动，但网络其实没问题。后来查了半天，发现是数据包乱序导致的。乱序包会产生负的延迟梯度，把斜率拉偏了。解决方案是在计算前先做排序和去重。
核心要点：
- 斜率k > 阈值 → 过度使用（Overuse）
- 斜率k < -阈值 → 欠使用（Underuse）
- 斜率k在阈值范围内 → 正常（Normal）
10.3 窗口大小选择：短还是长？
窗口大小是Trendline最关键的参数。WebRTC默认使用20个数据包作为一个窗口。为什么是20？不是10也不是50？
窗口太小，对噪声敏感，容易误判。窗口太大，反应迟钝，拥塞都发生了你还没检测到。20这个数字是Google在大量实验后找到的平衡点。
但实际项目中，我建议你根据场景调整：
| 场景 | 推荐窗口大小 | 原因 |
|---|---|---|
| 实时通话（低延迟） | 10-15 | 需要快速响应，容忍一定误判 |
| 直播推流（高码率） | 25-35 | 需要稳定，误判会导致画质波动 |
| 弱网环境 | 15-20 | 既要响应又要抗抖动 |
10.4 与卡尔曼滤波的对比
很多人问我：Trendline和卡尔曼滤波，到底哪个好？
我的回答是：没有绝对的好坏，只有适不适合。
卡尔曼滤波的优势在于：
- 能处理噪声和不确定性，有状态估计和预测能力
- 可以融合多个传感器数据（比如延迟和丢包率）
- 理论上更优雅，数学基础扎实
但卡尔曼滤波的缺点也很明显：
- 需要调参（过程噪声协方差、测量噪声协方差），调不好就发散
- 计算量比线性回归大一个数量级
- 在非线性场景下需要扩展卡尔曼滤波（EKF），复杂度更高
Trendline的优势：
- 简单、稳定、可解释性强
- 计算量小，适合嵌入式设备
- 参数少，调优成本低
WebRTC最终选择Trendline而不是卡尔曼滤波，我个人认为主要是出于工程稳健性的考虑。Google的工程师在论文里也提到，卡尔曼滤波在某些场景下会出现滤波器发散的问题，而Trendline不会。
我的建议：
- 如果你做的是学术研究或者高端产品（比如专业视频会议系统），可以试试卡尔曼滤波
- 如果你做的是量产产品，尤其是移动端，老老实实用Trendline
- 如果你想把两者结合，可以用Trendline做快速检测，卡尔曼滤波做精细调整
10.5 知识体系总览
下面这张图总结了Trendline滤波器的核心逻辑和与卡尔曼滤波的关系：
从这张图可以看得很清楚：Trendline的流程是输入 → 线性回归 → 窗口选择 → 斜率输出 → 状态判断。而卡尔曼滤波是另一个分支，两者在目标上一致，但实现路径不同。
trendline_estimator.cc。Google的代码注释写得不错，但有些细节需要自己跑实验才能体会。我当年就是一边读源码一边搭仿真环境，花了整整两周才完全吃透。
公众号:蓝海资料掘金营，微信deep3321