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

2021-07-11 18:34:45 阅读：495 来源： 互联网

标签：GCC SSRC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ packe

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

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9