WebRTC的transport wide cc feedback 带宽预估

背景介绍

  • BWE 带宽预估,参考 https://blog.csdn.net/CrystalShaw/article/details/82981183 的文章
    – 丢包预测:丢包率反应带宽情况
    – 延时预测: 组包延时,多个包的到达时间delta的趋势来判断带宽情况
    – 从之前GCC拥塞的接收端计算带宽并发送remb 到接收端反馈Transport cc, 由发送端sender来收集来计算带宽

Transport cc

  • transport wide cc 是属于feedback反馈机制的一种
    在这里插入图片描述
    PT=RTPFB 205
    FMT=15 接收端构造TransportCC报文 rfc transport wide cc
  • 原理:接收端接收到rtp包后,存储sequence number(这里有翻转)和arrive timestamp,然后每隔一段时间计算出每个包的相对延时,通过transport wide cc 传输。接收端收到后通过一些算法计算延时情况,预估带宽。

janus-gateway的transport wide cc 作为接收端的使用

janus作为发送端没看到对transport cc 做处理。

  • 第一步检测offer中的SDP信息中是否包含transport wide cc 信息:
janus_process_incoming_request(){
	//offer
	int transport_wide_cc_ext_id = janus_rtp_header_extension_get_id(jsep_sdp, JANUS_RTP_EXTMAP_TRANSPORT_WIDE_CC);
	handle->stream->do_transport_wide_cc = transport_wide_cc_ext_id > 0 ? TRUE : FALSE;
	handle->stream->transport_wide_cc_ext_id = transport_wide_cc_ext_id;
}

  • Transport wide sequence numbers header extension
    x所有的RTP包额外的增加一个头部扩展项,该扩展项用来表示发送序列号。通过SDP来协商是否打开该扩展项
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
  • Transport Feedback
    接收方向媒体发送方定期发送反馈,提供有关接收到的数据包的信息以及它们之间的延迟。反馈信息通过RTCP-Transport-FB反馈给发送端。通过SDP来协商是否启用
a=rtcp-fb:100 transport-cc

在这里插入图片描述

  • 在janus_ice_cb_nice_recv 接收到rtp包后形成status状态包
  1. 使用transport cc 后,发送端会在rtp包extension 中扩展 cc相关信息
	/*  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   | L=1   |transport-wide sequence number | zero padding  |
	   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	*/
  1. 通过 janus_rtp_header_extension_parse_transport_wide_cc 获取transport_seq_num ,获取当前的时间为rtp包的到达时间。加入到stream->transport_wide_received_seq_nums list中。
    在这里插入图片描述
  2. 通过janus_ice_outgoing_transport_wide_cc_feedback 函数来生成transport ccrtcp包发送。 这个函数由rtcp_source timer 默认一秒调用
  3. 排序transport_wide_received_seq_nums,计算丢失的包,janus_rtcp_transport_wide_cc_feedback生成rtcpbuf 通过janus_ice_relay_rtcp_internal 发送

transport wide cc RTCP协议

  • 详细介绍 rfc
    在这里插入图片描述
    base sequence number: 当前包组第一个packet的nbumber
    packet status count: 包组数量
    reference time: 当前包组第一个packet的time
    feedback packet count: 已发送的transport cc packet 数量 用于检测是rtcp否有丢失

Packet Status Symbols

计算出delta的大小,根据大小区分正常small delta 和large/negative packet

The status of a packet is described using a 2-bit symbol:

  00 Packet not received

  01 Packet received, small delta

  10 Packet received, large or negative delta

  11 [Reserved]
  • janus中体现
    在这里插入图片描述

packet chunk

  • Run Length Chunk 连续相同状态
0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| S |       Run Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T = 0   1bit 表示run length chunk
S			2bit 参考Packet Status Symbols
Run Length   重复包数
  • Status Vector Chunk
0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|S|        Symbols            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T = 1 		1 bit A one identifies this as a status vector
S 	             0表示后面14bit只包含   00 Packet not received/01 Packet received, small delta两种状态最大共14个包
				 1表示后14字节包含正常的Packet Status Symbols,所以最大共7个包

具体代码实现可以参考 janus_rtcp_transport_wide_cc_feedback 函数

发送端的算法处理

可以参考这篇文章

  • Packet Arrival Model
    WebRTC根据数据包到达的时间延迟,通过到达时间滤波器,估算出网络延迟m(t)
	Model the m(i+1) = m(i) + u(i),  u(i) is the Gaussion statistic with the zero mean and variance q(i), q(i) is RECOMMANDED equal to 10^-3.
d(i) = m(i) + v(i),  v(i) is zero mean white noise var_v = E{v(i)^2}.
z(i) = d(i)m_hat(i), where m_hat(i) is the estimation of m(i).
m_hat(i) = m_hat(i-1)  + z(i) * k(i)
k(i) = (e(i-1) + q(i))/(var_v_hat(i) + e(i-1) + q(i))
e(i) = (1-k(i))*(e(i-1)+q(i))
var_v_hat(i) = max(alpha*var_v_hat(i-1) + (1-alpha)*z(i)^2, 1)
alpha = (1-chi)^(30/1000*f_max),   where f_max = max{1/(T(j)T(j-1)} for j in i-K+1,, i,  chi is the filter coefficient, 
typically choose as a number in [0.001, 0.1].
  • Over-use Detector
	The output of  Arrival Time Filter is the delay estimation m(i).
m(i) is compared with the threshold del_var_th(i), An estimate above the threshold is considered as an indication of over-use, 
but over-use will be signaled only if over-use has been detected for at least overuse_time_th milliseconds,
however, if m(i) less than m(i-1), overuse will not be signaled. 
Similarly, the underuse is detected when m(i) less than -del_var_th(i). 
If neigher overuse or underuse is detected,  the detector will be in normal state. 
del_var_th(i) = del_var_th(i) + (t(i)-t(i-1))*K(i)*(|m(i)| - del_var_th(i-1)), 
where del_var_th(is) is RECOMMANDED to clamp to the range [6, 600].
  • Rate Control
Delay Based Estimation
      R_hat_delay(i) = 1/T * sum(L(j)) for j from 1 to N(i)
      A_hat_delay(i) = A_hat_delay(i-1) + max(1000, alpha*expected_packet_size_bits) if under-use
       A_hat_delay(i) = beta*R_hat_delay(i),   beta is RECOMMANDED to 0.85 if over-use
Loss Based Estimation
      Do nothing if loss between 2% ~ 10%
      R_hat_loss(i) = R_hat(i-1)*(10.5*lossRate) if loss is more than 10%
      R_hat_lss(i) = R_hat(i-1)*(1+0.08) if loss is less than 2% 
Combined Rate Control
      R_hat = min(R_hat_loss, A_hat_delay)

REMB : Receiver Estimated Maximum Bitrate,作为接收端

https://www.freehacker.cn/media/tcc-vs-gcc/ WebRTC-GCC两种实现方案对比

ref:

https://www.jianshu.com/u/102fafe8c6b9

  • 8
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值