首页 > 其他分享> > WEBRTC浅析（七）GCC之Receiver Estimated Maximum Bitrate的协议简析

WEBRTC浅析（七）GCC之Receiver Estimated Maximum Bitrate的协议简析

2021-07-11 18:34:45 作者：互联网

WEBRTC浅析（七）GCC:: Receiver Estimated Maximum Bitrate的协议简析

接收端的带宽估计（Receiver Estimated Maximum Bitrate）

参考文档：https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03

一：SDP协商

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

二：abs-send-time ::RTP扩展头

	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	   |  ID   | len=2 |              absolute send time               |
	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Wire format: 1-byte extension, 3 bytes of data. total 4 bytes

  abs_send_time_24 = (ntp_timestamp_64>> 14) & 0x00ffffff

在webrtc中的代码实现

absolute send time的RTP打包模块

 // The form of the absolute send time extension block:
 //
 //    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
 //   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //   |  ID   | len=2 |              absolute send time               |
 //   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 constexpr RTPExtensionType AbsoluteSendTime::kId;
 constexpr uint8_t AbsoluteSendTime::kValueSizeBytes;
 constexpr const char* AbsoluteSendTime::kUri;
 
 bool AbsoluteSendTime::Parse(rtc::ArrayView<const uint8_t> data,
                              uint32_t* time_24bits) {
   if (data.size() != 3)
     return false;
   *time_24bits = ByteReader<uint32_t, 3>::ReadBigEndian(data.data());
   return true;
 }
 
 
 bool AbsoluteSendTime::Write(uint8_t* data, uint32_t time_24bits) {
 
   RTC_DCHECK_LE(time_24bits, 0x00FFFFFF);
   ByteWriter<uint32_t, 3>::WriteBigEndian(data, time_24bits);
   return true;
 }

发送端：absolute send time扩展头的设置

  bool RTPSender::SendToNetwork(std::unique_ptr<RtpPacketToSend> packet,
                    StorageType storage,
                    RtpPacketSender::Priority priority) {
    RTC_DCHECK(packet);
    int64_t now_ms = clock_->TimeInMilliseconds();

  	......
  
    packet->SetExtension<AbsoluteSendTime>(AbsoluteSendTime::MsTo24Bits(now_ms));
    
    	......
    
  }

接收端：absolute send time扩展头的解析

  	void Packet::GetHeader(RTPHeader* header) const {
  	
  		  header->markerBit = Marker();
  		  header->payloadType = PayloadType();
  		  header->sequenceNumber = SequenceNumber();
  		  header->timestamp = Timestamp();
  		  header->ssrc = Ssrc();
  			......
  		  header->extension.hasAbsoluteSendTime =
  		      GetExtension<AbsoluteSendTime>(&header->extension.absoluteSendTime);
  		  header->extension.hasTransportSequenceNumber =
  		      GetExtension<TransportSequenceNumber>(
  		          &header->extension.transportSequenceNumber);
  			......
  				
  	}

三：REMB 反馈报文

       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                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ...                                                          |


   The fields V, P, SSRC, and length are defined in the RTP
   specification [2], the respective meaning being summarized below:

   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

webrtc中REMB的打包代码：

  bool Remb::Parse(const CommonHeader& packet) {
  	......
  }
  
  bool Remb::Create(uint8_t* packet,
                    size_t* index,
                    size_t max_length,
                    RtcpPacket::PacketReadyCallback* callback) const {
  	......                  
  }

webrtc中发送端：打包REMB报文

  void PacketRouter::OnReceiveBitrateChanged(const std::vector<uint32_t>& ssrcs,
                                         uint32_t bitrate_bps) {
                                         
    ......
    
    SendRemb(bitrate_bps, ssrcs);
    
  }

Webrtc中接收端：接收解析REMB报文

  bool RTCPReceiver::ParseCompoundPacket(const uint8_t* packet_begin,
                                 const uint8_t* packet_end,
                                 PacketInformation* packet_information) {
  			......
  			
  	    switch (rtcp_block.type()) {
  	      case rtcp::Psfb::kPacketType:
  	        switch (rtcp_block.fmt()) {
  	        
  	        		......
  	        		
  	          case rtcp::Remb::kFeedbackMessageType:
  	            HandlePsfbApp(rtcp_block, packet_information);
  	            break;
  	          default:
  	            ++num_skipped_packets_;
  	            break;
  		}
  }

标签：GCC,SSRC,+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+,packe
来源： https://blog.csdn.net/muwesky/article/details/118657520