接收方带宽估计的RTCP消息 REMB

1) What

Receiver Estimated Max Bitrate (REMB) 提出了提出了一种RTCP消息，供在实验中使用, 它为基于RTP的媒体流部署了拥塞控制算法。

它还描述了一个绝对值时间戳选项，用于带宽估计。该反馈消息用于通知一个在同一RTP会话上有多个媒体流的发送方, 通知它在该RTP会话的接收方路径上的总的估计可用比特率。

在用于反馈消息的公共数据包头中(如[RFC4585]的6.1节所定义)，“数据包发送者的SSRC” 字段指示通知的来源。不使用“媒体源的SSRC”，并且应将其设置为0。在其他RFC中也使用零值。

媒体发送方对符合此规范的REMB消息的接收将导致该消息在RTP会话上发送的总比特率等于或低于此消息中的比特率。新的比特率限制应尽快应用。发送者可以根据自己的限制和估计自由应用其他带宽限制。

2) Why

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

3) How

SDP 中包含如下属性

a=rtcp-fb: goog-remb
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time

RTCP 消息

RTCP 消息格式如下:

首先看它的 Payload Type，206 意谓 PSFB 即荷载特定的反馈 Payload-specific Feedback, 参见 http://www.rfcreader.com/#rfc5104 Codec Control Feedback 编码层反馈
其次看它的 FMT type, 15 意谓应用层反馈 Application layer feedback
然后看它的 Unique Identifier 唯一标识符 “REMB”
最后看相关的 SSRC number, 即RTP流个数，计算估计出带宽为 mantissa * 2 ^ exp

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P| FMT=15  |   PT=206      |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unique identifier 'R' 'E' 'M' 'B'                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Num SSRC     | BR Exp    |  BR Mantissa                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SSRC feedback                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ...                                                          |

字段含义

version (V): (2 bits): This field identifies the RTP version. The current version is 2.
padding (P) (1 bit): If set, the padding bit indicates that the packet contains additional padding octets at the end that are not part of the control information but are included in the length field. Always 0.
Feedback message type (FMT) (5 bits): This field identifies the type of the FB message and is interpreted relative to the type (transport layer, payload- specific, or application layer feedback). Always 15, application layer feedback message. RFC 4585 section 6.4.
Payload type (PT) (8 bits): This is the RTCP packet type that identifies the packet as being an RTCP FB message. Always PSFB (206), Payload-specific FB message. RFC 4585 section 6.4.
Length (16 bits): The length of this packet in 32-bit words minus one, including the header and any padding. This is in line with the definition of the length field used in RTCP sender and receiver reports [3]. RFC 4585 section 6.4.
SSRC of packet sender (32 bits): The synchronization source identifier for the originator of this packet. RFC 4585 section 6.4.
SSRC of media source (32 bits): Always 0; this is the same convention as in [RFC5104] section 4.2.2.2 (TMMBN).
Unique identifier (32 bits): Always 'R' 'E' 'M' 'B' (4 ASCII characters).
Num SSRC (8 bits): Number of SSRCs in this message.
BR Exp (6 bits): The exponential scaling of the mantissa for the maximum total media bit rate value, ignoring all packet overhead. The value is an unsigned integer [0..63], as in RFC 5104 section 4.2.2.1.
BR Mantissa (18 bits): The mantissa of the maximum total media bit rate (ignoring all packet overhead) that the sender of the REMB estimates. The BR is the estimate of the traveled path for the SSRCs reported in this message. The value is an unsigned integer in number of bits per second.
SSRC feedback (32 bits) Consists of one or more SSRC entries which this feedback message applies to.

最终计算出来的带宽估计为

receiver-bit-rate = mantissa * 2^exp

4) Example

REMB 的实现可以参考 webrtc 的源码：https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/modules/rtp_rtcp/source/rtcp_packet/remb.cc

带宽的计算代码为

uint8_t exponenta = payload[13] >> 2;
uint64_t mantissa = (static_cast(payload[13] & 0x03) << 16) |
                      ByteReader::ReadBigEndian(&payload[14]);
bitrate_bps_ = (mantissa << exponenta);

5) Conclusion

网络状况变化多端，时好时坏，在发送音视频不能由着性子随便发，需要根据接收者反馈的 RTCP 消息中包含的最大带宽估计调整自己的发送采样率/分辨率/帧率，也就是调整发送的码率，以满足基本的通信需求。