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

时间:2021-04-09 17:34:34

转自: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反馈报告,整个拥塞控制算法分成了接收端和发送端两个部分。接收端的控制算法是基于时延的算法,其目的是减小时延;发送端的控制算法是基于丢包率的算法,其目的是减少丢包。接收端的算法计算出一个速率Ar,然后将这个码率反馈给发送端,用来限制发送端基于丢包率算法计算出来的发送速率。

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

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

接收端速率控制:

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

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

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

1) The arrival-time filter

该模块的目的是为了计算排队时延m(ti),单向时延(one way delay variation)计算方式如下:dm(ti)= ti–ti-1–(Ti –Ti-1 )                                (3)

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

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

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

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

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(ti)= ηAr(ti−1)

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

REMB Processing

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