REMB-接收端最大接收码率评估

draft-alvestrand-rmcat-remb-03

接收方带宽估计的RTCP消息 REMB_fanyamin的博客-CSDN博客

webrtc中的码率控制_webrtc设置码率_linux_vae的博客-CSDN博客

参考：

Walter: WebRTC 拥塞控制之 REMB - 接收方带宽估计 - 简书

WebRTC基于TransportCC和Trendline Filter的发送端码率估计(Sendside-BWE)_算法

RTCP message for Receiver Estimated Maximum Bitrate

 

This feedback message is used to notify a sender of multiple media  streams over the same RTP session of the total estimated available  bit rate on the path to the receiving side of this RTP session.

 

接收端最大接收码率估测,接收端会估计本地接收的最大带宽能力，并通过rtcp remb 消息返回给对端，这样对端可以调整自己的发送端码率，达到动态调整带宽得目的.

实现：

1.RTP包增加一个扩展头 abs_send_time

abs_send_time 是一个以秒为单位的时间戳，总共 3 个字节(24 bit) , 格式为 6.18 (小数位固定为18位), 每 64s 会溢出环绕，分辨率为 3.8us

两个包发送的间隔 [T(i) - T(i-1)] 和接收的间隔 t(i) - t(i-1)]在理想情况下是相同的，实际上会有不同. 这样能够通过一些计算模型来计算网络的抖动和delay。

RTP sequence number 计算丢包

再结合接收端的接收的bitrate，来评估出接收的带宽。

2.增加REMB RTCP消息

        The message is an RTCP message with payload type 206. And Feedback message type (FMT)  is 15.

 

PT(8 bits)：206,  表示这是一个RTCP Feedback message， 值为PSFB(206)， 即荷载特定的反馈 Payload-specific Feedback

FMT (5 bits):  Feedback message的类型，值15，意为应用层反馈 Application layer feedback

Length (16 bits): 以32比特为单位的总长度减一，包括头和 padding

Maximum Bitrate估计值 = mantissa * 2^exp

 

GCC算法分两部分：发送端基于丢包率的码率控制和接收端基于延迟的码率控制。基于丢包率的码率控制运行在发送端，依靠RTCP RR报文进行工作。WebRTC在发送端收到来自接收端的RTCP RR报文，根据其Report Block中携带的丢包率信息，动态调整发送端码率As。基于延迟的码率控制运行在接收端，WebRTC根据数据包到达的时间延迟，通过到达时间滤波器，估算出网络延迟m(t)，然后经过过载检测器判断当前网络的拥塞状况，最后在码率控制器根据规则计算出远端估计最大码率Ar。得到Ar之后，通过RTCP REMB报文返回发送端。发送端综合As、Ar和预配置的上下限，计算出最终的目标码率A，该码率会作用到Encoder、RTP和PacedSender等模块，控制发送端的码率。

为什么要有 REMB？

发送者不知道接收方的带宽情况，它需要有一个机制由接收方告诉它有多少带宽可供传输, 这样发送方可以根据这个估计的带宽来调整分辨率(90p, 180p, 360p, 720p等)和帧率(每秒24, 30, 40, 60帧等)