一个只有 Google Meet 才知道的隐秘 WebRTC 优化

在 WebRTC 应用（至少是 Web 应用）中，Google Meet 始终保持着卓越的质量。与典型的开源解决方案相比尤其如此，甚至对于大多数商业解决方案相比也是如此。

原因在于，Google 拥有一支非常了解自己构建的媒体堆栈的团队，并且可以使其以某种方式运行，通过只有他们自己知道的隐藏在 WebRTC 中的旋钮来解决浏览器中的问题。

今天，我试图调试为什么 WebRTC 应用程序的带宽估计值不如 Google Meet 稳定。场景很简单：在一个带宽充足的完美网络中，突然增加 50 毫秒的额外延迟。您会看到，在所有 WebRTC 应用程序中，发送浏览器计算出的带宽估计值都会下降（左图），而使用 Google Meet（右图）时，它保持完全稳定。

在花了几个小时向 Chrome 代码添加日志并调试浏览器在这些条件下的行为后，我最终找到了AimdRateControl 类，它决定何时降低带宽估计值。对于所有应用程序（Google Meet 和其他应用程序），它都会以较低的估计值进入该点。令人惊讶的是，对于 Google Meet，即使估计值较低，它也会保持在之前的估计值。原因是此代码限制了最终估计值。

new_bitrate = std:: min ( 
current_bitrate_，
std:: max (new_bitrate， network_estimate_->link_capacity_lower * beta_) 
) ;

因此，Chrome 浏览器永远不会将比特率降至 “network_estimate_->link_capacity_lower * 0.85 ”以下。但是，什么是 network_estimate_->link_capacity_lower 呢？

经过进一步的调试，我发现这是服务器在类型为 APP 的专有 RTCP 消息中发送的一些信息，名称为“goog”，子类型为 13。

bool RTCPReceiver::HandleApp(const rtcp::CommonHeader& rtcp_block,
PacketInformation* packet_information) {
  rtcp::App app;
  if (!app.Parse(rtcp_block)) {
    return false;
  }
  if (app.name() == rtcp::RemoteEstimate::kName &&
    app.sub_type() == rtcp::RemoteEstimate::kSubType) {
    rtcp::RemoteEstimate estimate(std::move(app));
    if (estimate.ParseData()) {
      packet_information->network_state_estimate = estimate.estimate();
    }
  }
  return true;
}

代码库中用以下文字描述了这一扩展：

// RemoteEstimate packet 从接收端提供网络估计结果。此功能尚处于实验阶段，如有更改
，恕不另行通知。

此 RTCP 消息是在 2019 年添加的。当时它已连接到 SDP，但尽管从那时起我们经常查看 Google Meet，但我们从未见过相应的 SDP，而且今天仍然没有看到它。

因此，服务器每 50 毫秒发送一次 RTCP App 消息，其中包含从服务器端计算的带宽估计值。

该 RTCP RemoteEstimation 消息包含两个编码的值：

• link_capacity_lower
• link_capacity_upper

当发送方带宽估算检测到估算值突然下降但服务器端估算值仍然稳定时，下限值起到上限的作用，使其不至于反应过快。AimdRateControl 中的一个标志禁用了上限值的使用，但 WebRTC 代码库的其他部分可能也使用了上限值。

现在还有一个更难的问题。这些值是如何计算的？它们提供了两个不同的值，看起来像是不同的带宽估计值。

在与 Philipp Hancke 分享了这个问题后，他建议检查一下在禁用 abs-send-time 扩展后是否能正常工作，他是对的，在没有该扩展的情况下是不能工作的，因此它看起来与旧的 REMB 实现类似，但提供两个值（上限和下限）而不是一个仅作为发送方最大值的值。

从本质上讲，对 abs-send-time 的依赖表明服务器上正在运行远程比特率估算器。查看此问题和旧电子邮件，这种情况很可能自 2019 年以来就一直存在，并且隐藏在众目睽睽之下。

为了验证这个假设，我重新编译了 Chrome，以忽略那些专有的 RTCP App 消息，结果就出来了！在相同的测试网络条件下，Google Meet 现在的表现与其他实现一样好（或一样差）。

因此看起来 Google 从接收端带宽估计（REMB；RTCP REMB 可用于传输上限容量但不能传输下限容量）转向发送端带宽估计（传输反馈），然后同时进行这两项工作)

在大多数情况下，RemoteEstimate 扩展对于质量的必要性尚不清楚。据我们所知，除了 Google Meet 之外，没有其他 WebRTC 应用程序使用它，因此这可能并不重要，但它似乎提供了一些价值，因此其他 WebRTC 应用程序可能应该去复制它。我们只需要弄清楚如何计算下限和上限值，并每 50 毫秒将它们发送给发送方。

非常感谢 Philipp Hancke 的评论和反馈。

作者：Gustavo Garcia
原文：https://medium.com/@ggarciabernardo/another-sneaky-webrtc-optimisation-only-known-by-google-meet-remoteestimate-rtcp-packets-1d8f835eff67