(源码答复)WebRTC 发送方码率预估实现解析
WebRTC使用的是Google Congestion Control (简称GCC)拥塞控制，目前有两种实现：* 旧的实现是接收方根据收到的音视频RTP报文, 预估码率，并使用REMB RTCP报文反馈回发送方。 * 新的实现是在发送方根据接收方反馈的TransportFeedback RTCP报文，预估码率。
基于延迟的拥塞控制原理
先来看下Google Congestion Control（GCC）的标准草案：https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02 联合草案，可以得知GCC是基于网络延迟梯度的拥塞控制算法，判断的依据如下图：
https://p5.toutiaoimg.com/large/pgc-image/f0d94353207f439189b2452ce66e2d8c
发送方发送两个包组的间隔为 ： Ds = Ts1 - Ts0
接收方接收两个包组的间隔为： Dr = Tr1 - Tr0
假如网络没有任何抖动，那么 [ delta = Dr - Ds ] 应该是一个恒定稳定的值，但是现实中网络有抖动、拥塞、丢包等情况，所以delta也是一个抖动的值。 GCC通过测量delta，来判断当前网络的使用情况，分为 OverUse (过载)，Normal(正常)，UnderUse(轻载) 这三种情况。 有同学可能会问，发送方和接收方时钟不统一，怎么计算差值呢，需要做时间对齐或者NTP同步吗?
不需要，因为我们对比的是delta，只需要单位一致即可，举个例子: seq1的包 发送时间为 16000ms(发送方时钟)，接收时间为 900ms(接收方时钟) seq2的包 发送时间为 16001ms(发送方时钟)，接收时间为 905ms(接收方时钟) 那么延迟梯度delta=(905-900) - (16001-16000) = 4
Pacing和包组
值得留意的是，延迟梯度的判断是以包组为单位的，而且必须在发送方开启pacing发送, 有以下几点原因： 单个包测量误差会过大，基于包组的测量更能反应网络的情况。
burst发送容易冲击网络，影响测量的精度。 那么怎么判断哪几个包属于一个包组呢，非常简单，按发送方的pacing速率分包组。 WebRTC pacing默认是5ms一个包组，如下图所示
https://p26.toutiaoimg.com/large/pgc-image/2c952ad399ce469bb255714fcd38e932
TransportFeedback RTCP报文
再来看看transport-feedback的包结构：https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
https://p26.toutiaoimg.com/large/pgc-image/39fa1e90a50640158d14e52e47b2f810
解析这个报文，我们可以得到下面的信息：
[*]接收到的包seq和包的接收时间
[*]丢失的包seq
[*]可以看到本质上transport-feedback是接收方对数据的ACK，并且捎带了接收的延迟梯度。
发送方码率预估
收到transport-feedback报文后需要怎么处理，联合GCC的算法来看，分为以下几步： 1.计算接收方ack了多少个字节, 统计在采样的时间窗口内接收方的接收速率 看看GCC怎么说：
https://p5.toutiaoimg.com/large/pgc-image/ecdeb8839782455e8afcad2113bda3f0
按照这个算法实现acked_bitrate_estimate，可以计算出接收方在当前时间窗口内的接收速率。
2.将包按包组归类, 计算包组的发送时间 接收时间的差值 在前面的【Pacing和包组】中已经讲过，这里不再赘述
3.按包组的delta, 举行网络状态评估 GCC的标准草案里面使用的是卡尔曼滤波器(接收方评估)，发送方评估默认的实现是Trendline Filter。
基本的原理是最小二乘法, 将多个时间点的网络抖动(delta)拟合成一条直线，如下图所示：
https://p6.toutiaoimg.com/large/pgc-image/086760162a214300908fb86b26bbcbc0
根据直线斜率的变化趋势判断网络的负载情况。 上面已经得到了包组的delta，对delta做平滑计算后，按照(时间点, 平滑后的delta)， 可以在坐标系上绘制出散点图，使用最小二乘法拟合出delta随时间变化的直线，根据直线斜率计算出变化趋势。 来看看GCC里面的说法：
https://p9.toutiaoimg.com/large/pgc-image/a0e3c34944264428b2816ff1cdc56978
[*]m(i)为i时候的包组delta，del_var_th(i)为当前判断是否过载的门槛
[*]m(i) < -del_var_th(i)，判断为under-use(低载)
[*]m(i) > del_var_th(i) 且持续至少overuse_time_th时长，判断为over-use(过载)
https://p9.toutiaoimg.com/large/pgc-image/ba063dc81e81419e8d4ce3297b6c6a45
del_var_th必须动态调整，否则可能会在跟TCP的竞争中被饿死（出于公平性思量）。过大的del_var_th会对延迟变化不敏感，过小的del_var_th则会过于敏感，抖动容易被频繁误判为过载，必须动态调整，才气和基于丢包的连接（好比TCP）竞争。
根据探测的网络情况, 预估码率
总体的头脑是根据当前接收方的接收码率，联合当前的网络负载情况，举行AIMD码率调整：
[*]在接近收敛前，使用乘性增，接近收敛时使，用加性增。
[*]当网络过载时，使用乘性减。
https://p6.toutiaoimg.com/large/pgc-image/303f01d13c3d416cacf812b930c0e4db
在Decrease状态下，会不停地计算匀称最大码率（average max bitrate），当前预估码率和匀称最大码率差值在3个标准差以内时，举行乘性增，否则举行加性增。假如包到达速率超过了匀称最大码率的3个标准差，那么需要重新计算匀称最大码率。
https://p5.toutiaoimg.com/large/pgc-image/0ce0d8572e5a49569fca2a0fb45af044
乘性增期间，每秒最多增长8%的码率
https://p26.toutiaoimg.com/large/pgc-image/28ee24ba0a8d4e4b9b459a0f20c762af
加性增期间，每个rtt增长“半个”包巨细
https://p26.toutiaoimg.com/large/pgc-image/108dda971b64446894b760ed51dfb608
评估出的码率不能超过接收速率的1.5倍
https://p6.toutiaoimg.com/large/pgc-image/14522b437cc34ac091ccd5fe75f60887
当探测到网络过载时，按照0.85的速率低沉码率
发送方码率预估的算法流程
将上面的几步联合起来，可以得到一个大致的算法框架
struct FeedbackResultVector { int64_t send_time_ms; // 包发送时间(发送时记载) int64_t recv_time_ms; // 包接收时间(从TransportFeedback RTCP报文解析得到) int packet_size; // 包巨细};// 解析TransportFeedback RTCP报文FeedbackResultVector feedback_result_vec = TransportFeedbackRtcp.Parse(rtcp_feedback);// 遍历每个包, 举行处理for (feedback_result : feedback_result_vec) { double delta = 0.0; // 计算ack速率(接收方接收速率) AckBitrateEstimate.Update(now_ms, feedback_result.packet_size); // 把接收反馈包按照包组分类,计算包组delta bool compute_delta = PacketGroup.AddPacket(feedback_result, delta); if (comupute_delta) { // 探测网络状态 TrendLineFilter.Detect(delta); // 根据GCC状态机,举行AIMD码率调整 AimdRateControl.Update( TrendLineFilter.NetState(), AckBitrateEstimate.Bitrate() ); }}
页:
[1]