音视频传输 - WebRTC带宽评估

网络拥塞是基于IP协议的数据宝交换网络中常见的一种网络传输问题。网络拥塞是导致网络吞吐降低，网络丢包等的主要原因之一。

WebRTC中传输的采用的是UDP协议，WebRTC的传输层采用的拥塞算法是GCC算法。

Google congestion control

目前新版本的WebRTC的基于丢包的和基于延迟的带宽评估都是放在发送端的。
旧版本的WebRTC的基于延迟的带宽评估可能放在接收端，然后反馈给发送端。

1. 基于丢包的拥塞机制 base_bitrate

基于丢包的拥塞控制比较简单。其基本思想是根据丢包的多少来判断网络的拥塞程度，丢包越多则认为网络越拥塞，那么我们就要降低发送速率来缓解网络拥塞。如果没有丢包，则说明网络状况良好，这时候就可以提高发送码率，向上探测是否有更多的带宽可用。实现该算法主要有两点，一是获得接收端的丢包率，一是确定降低码率和提升码率的阈值。

发送端基于丢包率的控制方法在每一个tkt_ktk时刻，As(tk)A_s(t_k)As(tk)是tkt_ktk时刻的带宽估计值。
WebRTC通过RTCP协议的Receive Report反馈包来获取接收端的丢包率。Receive Report包中有一个fraction lost字段，包含了接收端的丢包率。

As(tk)={As(tk−1)∗(1−0.5∗fl)fl>0.11.05∗(As∗(tk−1))fl<0.02As(tk−1)otherwiseA_s(t_k)=\left\{ \begin{array}{rcl} A_s(t_{k-1}) * (1 - 0.5 * fl) & & {fl > 0.1}\\ 1.05 * (A_s * (t_{k-1}) )& & {fl < 0.02}\\ A_s(t_{k-1}) & & {otherwise} \end{array} \right. As(tk)=⎩⎨⎧As(tk−1)∗(1−0.5∗fl)1.05∗(As∗(tk−1))As(tk−1)fl>0.1fl<0.02otherwise

2. 基于延迟拥塞机制

基于延迟梯度的带宽估计有两种版本，最早一种是在接收端实现，评估的带宽结果通过RTCP REMB消息反馈到发送端，在此种实现中，为了准确计算延迟梯度，WebRTC添加了一种RTP扩展头部abs-send-time,用来表示每个RTP包的精确发送时间，从而避免发送端延迟给网络传播延迟的估计带来误差。这种模式也是RFC和google的paper中描述的模式。
在新近的WebRTC的实现中，所有的带宽估计都放在了发送端，也就是说发送端除了做基于丢包的带宽估计，同时也做基于延迟梯度的带宽估计。为了能够在发送端做基于延迟梯度的带宽估计，WebRTC扩展了RTP/RTCP协议，其一是增加了RTP扩展头部，添加了一个session级别的sequence number,目的是基于一个session做反馈信息的统计，而不仅仅是一条音频流或视频流，其二是增加了一个RTCP反馈信息transport-cc-feedback，该消息负责反馈接收端收到的所有媒体包的到达时间。发送端根据包间的接收延迟和发送间隔可以计算的延迟梯度，从而估计带宽。

2.1 基于延迟的拥塞控制 bwe_bitrate

基于延迟的拥塞控制是通过没组包的到达时间的延迟差的增长趋势来判断网络是否过载，如果过载进行码率下调，如果处于平衡范围维持当前码率，如果网络承载不饱满进行码率上调。

2.1.1 包组

WebRTC在评估延迟差的视乎不是对每个包进行估算，而是采用了包组间进行延迟评估，这符合视频传输（视频帧是需要切分成多个UDP包）的特点，也减少了频繁计算带来的误差。那什么是包组呢？就是距包组中第一个包的发送时刻t0t_0t0小于burst_timeburst\_timeburst_time发送的所有的包成为一组，第一个超过burst_timeburst\_timeburst_time的包作为下一个包组的第一个包。

为什么是burst_timeburst\_timeburst_time一组呢，这是由于WebRTC的发送端实现了一个平滑发送模块，该模块的发送时间间隔是burst_timeburst\_timeburst_time发送一批数据包。
到达时间间隔小于burst_timeburst\_timeburst_time的数据包被归为一组，这是由于在wifi网络下，某些wifi设备的转发模式是，在某个固定时间片内才有机会转发数据包，这个时间片的间隔可能长达100ms，造成的结果是100ms的数据包堆积，并在发送时形成burst，这个burst内的所有数据包就会被视为一组。

burst_timeburst\_timeburst_time可以与平滑发送的时间间隔联系，比它小就可以。
一般认为：

burst_time=5msburst\_time = 5msburst_time=5ms

2.1.2 延迟梯度

设相邻的两个数据分组到达接收方的时间间隔为t(i)−t(i−1)t(i) - t(i-1)t(i)−t(i−1), 而两者被发送的时间间隔则为T(i)−T(i−1)T(i) - T(i-1)T(i)−T(i−1)，那么就有延迟变量d(i)=t(i)−t(i−1)−(T(i)−T(i−1))d(i)=t(i)-t(i-1) - (T(i)-T(i-1))d(i)=t(i)−t(i−1)−(T(i)−T(i−1))。如果d(i)>0d(i) > 0d(i)>0，就说明数据在网络传输时存在延迟的现象。

这里的d(i)d(i)d(i)也称为延迟梯度。

由于延迟梯度did_{i}di的测量精度很小，为了避免网络噪音带来的误差，旧版本WebRTC在接收端利用了卡尔曼滤波来平滑延迟梯度的测量结果，新版本WebRTC则在客户端使用了trendline滤波分析。
WebRTC的实现中，并不是单纯的测量单个数据包彼此之间的延迟梯度，而是前面提到的分组测量。分组的时间间隔为5ms。
为了计算延迟梯度，所有接收端要反馈每个媒体包的接收状态，同时发送端也要记录每个媒体包的发送状态，记录其发送的时间值。在这个情况下abs-send-time扩展不再需要。

2.1.3 过载检测

到达时间滤波器计算出每组数据包的延迟梯度之后，就要据此判断当前的网络拥塞状态，通过和某个阈值的比较，高过某个阈值就认为时网络拥塞，低于某个阈值就认为网路状态良好，因此如何确定阈值就至关重要。这就是过载检测器的主要工作，它主要有两部分，一部分是确定阈值的大小，另一部分就是依据延迟梯度和阈值的判断，估计出当前的网络状态，一共有三种网络状态: overuse underuse normal，我们先看网络状态的判断。

其中m(ti)m(t_i)m(ti)表示的过去一段时间计算出来的延迟梯度的平均值。
这里用γ(ti)\gamma(t_i)γ(ti)表示阈值，阈值根据时间自适应。

当 m(ti)>γ(ti)m(t_i) > \gamma(t_i)m(ti)>γ(ti)， overuse状态。
当m(ti)<−γ(ti)m(t_i) < -\gamma(t_i)m(ti)<−γ(ti)，underuse状态。
当−γ(ti)<m(ti)<γ(ti)-\gamma(t_i) < m(t_i) < \gamma(t_i)−γ(ti)<m(ti)<γ(ti) normal状态。

这样计算的依据是，网络发生拥塞时，数据包会在中间网络设备中排队等待转发，这会造成延迟梯度的增长，当网络流量回落时，网络设备快速消耗（转发）其发送队列中的数据包，而后续的包排队时间更短，这时延迟梯度减小或为负值。

在实际WebRTC的实现中，虽然每个数据包组（前面提到了如何分组）的到达都会触发这个探测过程，但是使用的m(ti)这个值并不是直接使用每组数据到来时的计算值，而是将这个值放大了60倍。这么做的目的可能是m(ti)这个值通常情况下很小，理想网络下基本为0，放大该值可以使该算法不会应为太灵敏而波动太大。
在判断是否overuse时，不会一旦超过阈值就改变当前状态，而是要满足延迟梯度大于阈值至少持续100ms，才会将当前网络状态判断为overuse。

2.1.4 阈值自适应

γ(ti)\gamma(t_i)γ(ti)，它是判断当前网络状况的依据，所以如何确定它的值也就非常重要了。虽然理想状况下，网络的延迟梯度是0，但是实际的网络中，不同转发路径其延迟梯度还是有波动的，波动的大小也是不一样的，这就导致如果设置固定的。 γ(ti)\gamma(t_i)γ(ti)太大可能无法探测到拥塞，太小又太敏感，导致速率了变化很大。同时，另外一个问题是，实验中显示固定的值会导致在和TCP链接的竞争中，自己被饿死的现象（TCP是基于丢包的拥塞控制），因此WebRTC使用了一种自适应的阈值调节算法，具体如下：

γ(ti)=γ(ti−1)+ΔT⋅Kγ(ti)⋅(∣m(ti)∣−γ(ti−1))\gamma(t_i) = \gamma(t_{i-1}) + \Delta{T} \cdot K_{\gamma(t_i)} \cdot (|m(t_i)| - \gamma(t_i -1))γ(ti)=γ(ti−1)+ΔT⋅Kγ(ti)⋅(∣m(ti)∣−γ(ti−1))

ΔT=ti−ti−1\Delta{T} = t_i - t_{i-1} ΔT=ti−ti−1

Kγ(ti)={kd∣m(ti)∣<γ(ti−1)kuotherwiseK_{\gamma(t_i)}=\left\{ \begin{array}{rcl} k_d & & |m(t_i)| < \gamma(t_{i} -1) \\ k_u & & {otherwise} \end{array} \right. Kγ(ti)={kdku∣m(ti)∣<γ(ti−1)otherwise
建议
ku>kdk_{u} > k_{d} ku>kd
推荐值
ku=0.01k_{u} = 0.01 ku=0.01 kd=0.00018k_d = 0.00018 kd=0.00018

从这个式子可以看出，当延迟梯度减小时，阈值会以一个更慢的速率减小；延迟梯度增加时，阈值也会以一个更慢的速度增加。不过相对而言，阈值的减小速度要小于增加速度。这样主要是为了防止饥饿。

2.1.5 速率调整状态机

在过载检测中有提到三种情况，normal, underuse, overuser。
然后estimator通过根据三个情况来更新状态。采用一定的比值，对速率进行调整。
三个状态分别是Increase, Hold, Decrease。

这三种状态的状态机如下，系统在Increase状态下启动。

一般可以认为带宽评估的更新As(tk)A_s(t_k)As(tk)按照以下公式进行。
As(tk)={η∗As(tk−1)Increaseβ∗Rr(ti)DecreaseAs(tk−1)HoldA_s(t_k)=\left\{ \begin{array}{rcl} \eta * A_s(t_{k-1}) & & Increase\\ \beta * R_r (t_{i}) & & Decrease\\ A_s(t_{k-1}) & & {Hold} \end{array} \right. As(tk)=⎩⎨⎧η∗As(tk−1)β∗Rr(ti)As(tk−1)IncreaseDecreaseHold

其中
η=1.05\eta = 1.05 η=1.05

β=0.85\beta = 0.85 β=0.85

Rr(ti)指的是过去500ms窗内的最大ackedbitrateR_r(t_{i}) 指的是过去500ms窗内的最大acked bitrateRr(ti)指的是过去500ms窗内的最大ackedbitrate

值得注意的是，Incease状态时As(tk)A_s(t_k)As(tk)的增加策略应该权衡multiplicatively or additively
界定：
如果当前的Rr(ti)R_r(t_{i})Rr(ti)比较接近我们上一次在Decrease阶段的平均的Rr(ti)R_r(t_{i})Rr(ti)，我们就认为现在大概率在拥塞的边缘，这时候应该选择加性增。

乘法增：
η=1.08⋅min(time_since_last_update_ms/1000,1.0)\eta = 1.08 \cdot min(time\_since\_last\_update\_ms / 1000,1.0)η=1.08⋅min(time_since_last_update_ms/1000,1.0)

As(tk)=η⋅As(tk−1)A_s(t_k) = \eta \cdot A_s(t_{k-1})As(tk)=η⋅As(tk−1)

加性增：

response_time_ms=100+rtt_msresponse\_time\_ms = 100 + rtt\_ms response_time_ms=100+rtt_ms

α=0.5∗min（time_since_last_update_ms/response_time_ms，1.0）\alpha = 0.5 * min（time\_since\_last\_update\_ms / response\_time\_ms，1.0）α=0.5∗min（time_since_last_update_ms/response_time_ms，1.0）

As(tk)=As(tk−1)+max（1000，α∗expected_packet_size_bits）A_s(t_k)= A_s(t_{k-1})+ max（1000，\alpha * expected\_packet\_size\_bits）As(tk)=As(tk−1)+max（1000，α∗expected_packet_size_bits）

最后：

带宽评估不应该过于剧烈
所以最后要有:
As(tk)<1.5⋅Rr(ti)A_s(t_k) < 1.5 \cdot R_r (t_{i}) As(tk)<1.5⋅Rr(ti)
Rr(ti)指的是过去一段时间内最大ackedbitrateR_r(t_{i}) 指的是过去一段时间内最大acked bitrateRr(ti)指的是过去一段时间内最大ackedbitrate
带宽评估触发的时间间隔ti+1−tit_{i+1} - t_{i}ti+1−ti应该尽量均匀

综合

WebRTC会根据上述丢包得到的带宽base_bitrate和基于延迟得到的bwe_bitrate得到的最小值，这个最小值作为estimator最终评估出来的码率。

参考链接

https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02#section-1.1
http://www.sohu.com/a/210713395_629429
http://www.ctiforum.com/news/guandian/535764.html

音视频传输-带宽评估相关推荐

RTC 系统音视频传输弱网对抗技术
Hi~这里是25万+社交,泛娱乐,出海开发者青睐的全球互联网通信云·融云若你对国产化,协同办公解决方案感兴趣,欢迎关注本号的[兄弟号]关注[融云 RongCloud],了解协同办公平台更多干货. 今天 ...
学习笔记：SDVOE，使用SDN的方式进行高清无损的音视频传输，SDN的又一应用，AV/IT融合
时间# 2020-01-25 庚子年正月初一背景# 1.肺炎疫情还在延续,窝在家不用外出拜年,正好抽点时间充下电 2.公司陆续上了几个新产品线,规模起来后,后面业务要分行业分产品了,最近也在纠结后面 ...
AVB音视频传输协议简介
一.音视频传输面临的主要问题二.如何解决这些问题 1. 网络传输问题 2. 媒体时钟同步问题三.AVB体系 1.协议框架 2. 网络拓扑 3. 典型应用场景 a. 车载娱乐系统 b. 大型演唱会现 ...
远距离无线音视频传输方案，物联网技术应用，无线远距离WiFi通信技术
物联网市场的碎片化,不同的场景之下,对于连接技术也有不同的要求,这也使得目前在物联网市场上,有着种类众多的连接技术,比如Wi-Fi.蓝牙.Zigbe等成本低廉的短距离无线连接技术,以及LoRaWAN等 ...
低延迟音视频传输技术在直播领域的应用
本文来自陌陌视频流媒体技术负责人吴涛在WebRTCon 2018上的分享,他详解了陌陌从传统直播过渡到1对1到多人互动模式的演进,架构的优化保证了用户体验与业务需求.另外,文末为WebRTCon 20 ...
音视频传输协议众多， 5G时代不同业务应该如何选择？
摘要:音视频传输协议众多, 不同业务应该如何选择? RTSP.RTMP.RTP/RTC.HLS.MSS.DASH.WEBRTC.RIST.SRT:在此我们就从业务发展的视角来理解各种流媒体协议,帮助大 ...
QOS FEC NACK 实时音视频传输库测试报告（声网、腾讯实时音视频测试）
目录 QOS-FEC-NACK传输库简介实验环境测试DEMO说明测试项说明测试结果竞品分析总结 QOS FE ...
IoT 设备高质量的实时音视频传输解决方案
12月10日,实时互动云服务开创者及引领者声网Agora在北京举办了媒体沟通会,发布了首款定义轻互动直播场景的"极速直播"与可降低50%直播带宽成本的"低码高清" ...
P2P音视频传输接口使用说明
P2P(Point-to-Point)音视频传输技术,是为节省服务器带宽而设计的.我设计和开发的接口使用如下,供参考.最近几天我会整理一下P2P 开发常见问题.该技术目前主要在监控安防,宠物机,扫地机 ...

音视频传输-带宽评估