WebRTC的带宽估计[转载]

带宽估计（BWE）模块的任务是决定你可以发送多大的视频流且不会造成网络拥塞，以此来保证不会降低视频质量。

在以前的带宽估计算法还是十分基础的，大体上是基于丢包而设计的。通常我们在开始慢慢的增加视频的比特率，直到我们检测到丢包为止。为了检测丢包，你使用标准的RTCP反馈，其中接收端使用RTCP接收端报告（RR）信息来周期性的报告丢包。

现在的带宽估计算法变得更加先进，尝试在拥塞严重到了路由器开始丢弃数据包之前就检测出来。这些算法通过分析数据包之间的延时来预测拥塞情况。想法是当你开始遇到拥塞时，数据会开始流入路由器中的缓冲区，延时也会变得更多样。这些算法中比较出名的几种是Google Congestion Control（就是WebRTC中用的），SCReAM以及SPROUT。

从WebRTC的最初级阶段开始，媒体引擎就是基于远端带宽估计理论而搭建的。正像我之前说的那样，接收端会分析包间延时，并且会对可用带宽产生一个估计值，然后使用RTCP信息报回给发送端，其中RTCP信息使用了一种被设计来完成这项工作的信息类型：REMB。另一个关于WebRTC实现的细节是，发送端不会只使用这个在REMB包中接收的带宽估计值，也会使用反馈的丢包来决定最终发送的目标视频比特率。

这个实现的好处是它可以在检测到使用过度的时候迅速的降低比特率，即使此刻还没有探测到拥塞的时候。

但是在最近版本的Chrome中这点发生了改变，现在带宽估计的所有的逻辑都是发生在发送端。拥塞的基本检测跟以前没有什么大的差别，且发送端需要从接收端传来的延时信息来估计可用的带宽。这是用两个全新的机制/协议来完成的：

#1 传输宽序列号的报头扩展：所有视频RTP数据包都在报头处有额外的4位来包含一个序列号。这是通过下面语句与SDP协商得来：

注意：这种新的序列号的思想是可以对音频和视频只使用一个计数器，但是Chrome还没有将其在音频领域中使用，所以我认为它现在还并不是很有用。

#2 传输反馈：接收端会周期性地将包含有关已接收数据包和包间延时的信息反馈给发送端。为了完成这项工作，接收端使用了新的RTCP包（传输反馈）。这是通过下面这条包括了新RTCP反馈信息的语句在SDP中协商得来：

当你在观察这些传输反馈数据包是什么样子的时候，有意思的是你会意识到其中有Google建议的规范，以及官方标准化方案，但是真正使用的是在源码之中的实际实现。

这个RTCP反馈默认100ms发送一次，但是实际上是动态适应的，只会使用5%的可用带宽（最小值是50ms，最大值是250ms）。

为了将大小控制在最小，这种新的RTCP包的格式十分简洁，包括块内的分组包，以base+diff的形式存储数字，或者将粒度降低到0.25ms为间隔。我做了一个简单的测试，有了这些改进方案，其依旧会使用16Kbps来每50ms发送一次反馈数据包。

你可以在remote_estimator_proxy.h以及transport_feedback.cc中查看相关实现。

发送端带宽估计的好处是什么？Google给出的解释是，这样做的话，所有的决定逻辑都会在一个地方（发送端），而且这会让测试新算法变得更简单，因为你不需要同时取决于两个端点。说实话，由于浏览器的自动更新，我看不出来这点改变可以带来什么大的好处，但是其确实更加的整洁，即便会在带宽使用方面更贵一点。另一项好处是，发送端可以知道自己所发送的数据流是什么类型的，也可以在发送普通视频，而不是做例如屏幕广播这种事情的时候使用不同的算法。

我们会受到实际影响吗？如果你搭建了一个需要进行带宽估计的媒体服务器，在某种程度上你需要更新你的实现。好消息是Chrome还会支持旧机制（REMB）一段时间，至少会持续到Firefox支持它之后。但是REMB可能不会再有新的进展了，而且现在出现bug的可能性会更高，所以我认为推迟更新太久并不是一个好主意。

发送端带宽估计真的就更好吗？我做了一个快速的测试（这是测试页面，你可以尝试一种，或者通过改变布尔值来进行别的测试），其中在Chrome中同时用了两种算法（老的REMB和新的传输反馈），其中新算法的表现要好的多，至少在连接开始阶段的上升部分要好的多。我不认为对于这种结果，除了Google现在全新投入在新算法中，而不管老算法，且所有的赶紧都只会发生在新算法中，这个原因以外还存在着什么技术上的解释。很显然在新算法中，头两秒内肯定是有什么特殊的方法来处理带宽估计，但是我也没有太深入的研究。