WebRTC 中基于损耗的带宽估算

测量可用带宽和避免拥塞是 WebRTC 视频管道中最关键、最复杂的部分。带宽估算 (BWE) 的概念很简单：监控数据包延迟，如果延迟增加或出现数据包丢失，则减少发送数据。前一部分被称为基于延迟的估计，而后一部分不太为人所知，被称为基于丢失的估计。

在 WebRTC 的最初实现中，基于损耗的估算逻辑非常简单：如果丢包超过 2%，就不要提高发送比特率；如果丢包超过 10%，就降低发送比特率。然而，这种天真的方法存在缺陷。有些网络也会出现数据包丢失的情况，这并不是拥塞造成的，而是网络本身固有的问题（如某些 WiFi 网络）。我们称这种丢包为静态丢包或固有丢包。

为了解决这个问题，经过数年的开发和实验，Google 最新版本的 WebRTC 库引入了一种更先进、更复杂的解决方案。该解决方案被称为基于损耗的带宽估算第二版（loss-based BWE v2），是 WebRTC 历史上该功能的第三次迭代。我们可以用以下时间轴来概括它的演变过程：

基于Loss的基本 BWE（2011 年左右）：基于静态丢包阈值来增加/减少 bwe。源代码
基于 Loss 的 bwe v1（~2019 年）：数据包丢失的动态阈值和平滑测量。源代码
基于Loss 的 bwe v2（2023 年）：基于当前数据包丢失和趋势的最大似然建模。源代码

本篇文章将重点介绍今年在 Chrome 和所有基于相同库的浏览器和客户端中启用的最新解决方案（Loss based BWE v2）。

Loss based BWE v2

从高层次来看，下图显示了基于损耗的 BWE 如何集成到估算逻辑中，以及考虑了哪些输入。基于损耗的估算将基于延迟的估算作为输入，并根据从发送的数据包中接收到的数据包损耗反馈，尝试提供最终估算结果。

基于损耗的新 BWE v2 每次需要提供新的估计时，都会执行以下步骤：

1/ 首先，它生成一个描述网络（也称为信道）特性的潜在候选列表。在本例中，考虑的特性是可用带宽和网络固有的丢包率。

1.a. 候选带宽来自不同领域。基本上，基于延迟的估算、基于损失的最新估算以及发送的比特率都会被考虑在内。然后将这些数据乘以一定的系数（0.95、1、1.02），生成潜在的额外新带宽候选数据。

1.b. 固有数据包丢失候选值来自最新估计值。它根据最近观测的趋势，使用基于一阶和二阶导数的牛顿更新法进行更新。此外，还有基于发送比特率的限制–在比特率较高的情况下，固有丢包率不应过高。

2/ 其次，算法会选择能最准确解释最近观测数据中丢包现象的候选数据。为此，算法会为每个候选者计算一个客观分数，这就是算法的最大似然建模环节。

这两个步骤可以从总结算法概念的实际代码片段中看到：

ChannelParameters best_candidate = current_best_estimate_;
  double objective_max = std::numeric_limits<double>::lowest();
  for (ChannelParameters candidate : GetCandidates(in_alr)) {
    NewtonsMethodUpdate(candidate);
    
    const double candidate_objective = GetObjective(candidate);
    if (candidate_objective > objective_max) {
      objective_max = candidate_objective;
      best_candidate = candidate;
    }
  }

在最后一步中，客观分数最高的候选者的带宽将作为最终估算值，用于决定编码多少视频并发送到网络。

虽然根据上述描述，该算法看似简单，但编码过程远非小事一桩。尽管它的体积相对较小，但却有 30 多个可调参数。如果你持怀疑态度，可以查看问题跟踪历史记录。你会发现，开发、优化并将这一新功能部署到生产中花费了两年多的时间。