WebRTC之带宽控制部分学习(1) ------基本demo的介绍

转自：http://blog.csdn.net/u013160228/article/details/46392037

WebRTC的代码真是非常之大啊，下载以及编译了我好几天才搞完。。。。。

可以看到WebRTCd代码分成了4个部分，目前为止只看了talk里的一些东西。

1、 talk中的项目文件大多数都是以libjingle开头的，可以看出libjingle是WebRTC中非常核心的一个东西啦。

libjingle中开辟了两个通道，分别为会话通道和数据通道，一个用来会话建立管理等，一个用来传输数据。

libjingle_media是用来渲染获取视频，libjingle_p2p和libjingle_peerconnection是不同的会话方式用到的库吧，现在还没有细看

peerconnection_client和peerconnection_server则是可以直接运行的demo，设为启动项目就可以测试了，先运行server。

2、由于项目研究的是关于带宽估计的东西，所以我们看的文件主要有两个，一个是上行带宽的估计和控制，一个是下行带宽的估计和控制

上行带宽的文件在webrtc/modules/bitrate_controller，下行带宽的文件是remote_bitrate_estimator

下面讲一讲Goolge的WebRTC中自带的码率控制：

发送端发送RTP包，同时接收来自于接收端的RTCP反馈报告，整个拥塞控制算法分成了接收端和发送端两个部分。接收端的控制算法是基于时延的算法，其目的是减小时延；发送端的控制算法是基于丢包率的算法，其目的是减少丢包。接收端的算法计算出一个速率A_r，然后将这个码率反馈给发送端，用来限制发送端基于丢包率算法计算出来的发送速率。

发送端基于丢包率的控制方法在每一个t_k时刻或者t_r时刻启动。t_k表示第k个RTCP反馈报告的到达时间，t_r表示第r个REMB信息到达发送端的时间，其中REMB信息中包含接收端反馈的A_r信息。RTCP包内包含丢包率f_l(t_k)，发送端根据丢包率计算接下来的发送速率，具体计算方式图公式1所示：

接收端速率控制：

接收端算法的目的就是计算出能保证低时延情况下的接收速率A_r，A_r的计算过程如图2所示：

下面介绍接收端也就是remote_bitrate_estimator中的几个模块算法

1) The arrival-time filter

该模块的目的是为了计算排队时延m(ti),单向时延（one way delay variation）计算方式如下：d_m(t_i)= t_i–t_i-1–(T_i –T_i-1 )                                （3）

式中，T_i表示第i帧视频发送的时间戳，ti 表示第i个视频帧接收到的时间戳。单向时延是三个部分的总和，包括传输时间、排队时延m(ti)、网络抖动n(ti)。GCC算法中提出了下面这个公式：

式中，∆L(t_i) = L(t_i) −L(t_i−1)，L(t_i)是第i个视频帧的长度，C(ti)是瓶颈链路容量估计，n(ti)是网络抖动（高斯噪声模型）。为了将dm(ti) − d(ti)的差值缩小到趋于零，用卡尔曼滤波器提取出状态向量，具体工作方式如图3所示：

The over-use detector

每帧视频收到的时刻，即ti时刻，该模块都会产生一个s信号以驱动下一个码率控制模块。当m(ti)大于阀值γ，信号为overuse；当m(ti)小于阀值γ，信号为underuse。

Remote rate controller

该模块的目的是为了估算数接收速率Ar，其算法流程如图2所示，由信号s决定码率的调整，η ∈[1.005,1.3],α ∈[0.8,0.95]分别为增性系数和碱性系数。

上调：Ar(t_i)= ηAr(t_i−1)

下调：Ar(t_i)= αR(t_i)，其中R(t_i)是最近500ms内的平均接收速率。

REMB Processing

该模块的功能是将上一个模块计算出的速率Ar通过REMB信息发给客户端。REMB信息发送间隔为1s，但当Ar下降了3%，即Ar(t_i) < 0.97Ar(t_i−1)时，则立即发送REMB信息以调整码率。