WebRTC的丢包计算方法

背景

      目前WebRTC的版本主要还是基于GCC的拥塞控制,发送端需要根据丢包率控制发送码率,而丢包率是在接收端计算并通过RR(Receiver Report RTCP)包通知发送端。

版本

      66

问题

      重传包可能会影响丢包率,如果发送端重传的包都被接收端收到,并且接收端没有区分重传包,那么丢包率会是0,与实际的网络状态不符,发送端也无从控制发送码率。

丢包与NACK、RTX的关系

      在使能RTX的情况下,发送端的重传包会使用新的SSRC通过RTX发送,这些包并不会被计入正常的接收包,这样接收端丢包率的计算是天然正确的。
      在没有使能RTX的情况下,发送端的重传包就在原来的SSRC上简单重传,接收端没有办法通过什么特殊标识区分是否是重传包,而是以接收到包的时间戳以及估算的RTT来判断是否是重传包。

判断当前包是否重传包的算法

      t1=上一个未乱序的包到当前包时间戳的时间间隔
      t2=上一个未乱序的包到当前时间的时间间隔
      如果t2 > t1 + f(rtt)则认为当前包是重传包,f(rtt)是rtt的线性函数,目前f(rtt)=rtt/3+1。
      直观解释就是,当前包的时间戳已经是过去的时间,其加上f(rtt)后仍然是过去的时间,说明可能是接收端通过NACK通知发送端发送的重传包(可能经过了一个rtt),可以认为是重传包。

丢包的计算

   1. 接收端维护两个计数器,每收到一个RTP包都更新:

  • transmitted,接收到的RTP包的总数;
  • retransmitted,接收到重传RTP包的数量;

   2.某时刻收到的有序包的数量Count = transmitted-retransmitte ,当前时刻为Count2,上一时刻为Count1;

   3.接收端以一定的频率发送RTCP包(RR、REMB、NACK等)时,会统计两次发送间隔之间(fraction)的接收包信息:
      //两次发送间隔之间理论上应该收到的包数量=当前接收到的最大包序号-上个时刻最大有序包序号
      uint16_t exp_since_last = (received_seq_max_ - last_report_seq_max_);
     
      //两次发送间隔之间实际接收到有序包的数量=当前时刻收到的有序包的数量-上一个时刻收到的有序包的数量
      uint32_t rec_since_last = Count2 - Count1
     
      //丢包数=理论上应收的包数-实际收到的包数
      int32_t missing = exp_since_last - rec_since_last

      missing即为两次发送间隔之间的丢包数量,会累加并通过RR包通知发送端。

RR中的丢包

      接收端发送的RR包中包含两个丢包,一个是fraction_lost,是两次统计间隔间的丢包率(以256为基数换算成8bit),一个是cumulative_lost,是总的累积丢包。

你可能感兴趣的:(webrtc,直播,SDK)