做音视频的同学应该都知道，基于RTP/RTCP传输流媒体，难点在于怎么把Qos做好。比较常用的基于RTCP反馈机制的Qos策略有NACK、PLI和FIR，再网络比较拥塞的情况下，使用NACK、PLI或FIR机制，可能不会改善网络拥塞情况，反而可能会增加网络拥塞的程度，这时根据网络带宽的具体情况，适当调整发送码流可能会达到更好的效果，这里我们主要说下RTCP的REMB，根据REMB文档的规范https://tools.ietf.org/pdf/draft-alvestrand-rmcat-remb-03.pdf，文档中REMB报文的介绍如下：
该文档建议REMB和abs-send_time一块使用，同时该文档并没有详细规定和介绍REMB的具体算法，一般情况下，发送方和接收方，根据SDP的协商结果，定一个视频编码传输的最大码率，接收端根据实际情况网络的拥塞程度，比如丢包率、抖动、延迟等情况，动态调整发送方的码率，需要接收端根据实际情况向发送端发送RTCP REMB报文，发送端收到接收端反馈的REMB报文，适当调整编码器码率及发送的码率。