实时音视频网络质量统计方法

实时音视频网络质量统计方法

网络质量指标重要性

在实时音视频领域,VoIP通话对于网络质量要求很高,系统必须能实时感知到网络质量变化,供上层应用及时调整码率,降低网络质量进一步恶化的风险。衡量用户的网络质量可以通过丢包、延时、抖动、带宽、吞吐量这些指标。本文重点介绍丢包、延时、和抖动的统计方法。

丢包率的含义与计算方式

音视频数据从发送端A经过网络到达接收端B,数据包在网络中可能由于链路波动、路由器缓存队列积压、Wi-Fi信号不好导致丢包。周期总共丢了多少个包与理论应收包个数的比值就是丢包率。

在实际开发中,发送端通过seq标识每个数据包,接收端根据包头的seq号判断是否有丢包周期性计算丢包率。
丢包率计算公式:
fractionLost = max(0, (expected – received) / expected)

  • expected:统计周期内最大seq与最小seq的差值。
  • received:统计周期实际收到的数据包个数,包括晚到包和重传包。

注意事项

  • received有可能会大于expcted,注意判断。
  • 统计周期需要结合包量进行评估,根据经验值expected 至少要收到25个包以上。
  • 统计周期内expected个数必须大于特定值,避免出现1/2 这种脏数据产生。
  • 如果seq用uint16_t表示,要处理seq号翻转问题,处理方法见链接。

延时的含义与计算方式

在实时音视频领域数据包从发送端A采集到接收端B播放,这段时间就是用户通话感知到的端到端延时。延时主要由三部分组成终端采集编码延时、网络延时、终端抖动缓冲延时,端到端延时超过400ms就会影响用户的体验。
在计算延时时,因设备的时钟不同,不能采用发送时间戳与收包时间戳相减的方式计算。ping这种形式计算出来的是RTT,没有排除应用程序处理带来的延时。WebRTC里面对于延时的计算方法按如下流程。

  • 发送端构造SR包,记录下LSR当前时间戳保存到SR包里面。
  • 接收端收到最新的SR包时,会记录下收包时的时间戳到last_received_sr_ntp。
  • 接收端构造RR包时,设置DLSR字段为 当前时间戳nowtimestamp – last_received_sr_ntp 。
  • 发送端在接收到RR包之后,记录RR包达到时间戳A
  • rtt就等于 TS – LSR – DLSR。
RTT计算流程

SR和RR包不是请求与回应的关系,各自独立发送。RR包里总是记录最近一次SR包里的时间戳。因此,即使发生了丢包只要发送端收到了RR包,发送端就能够计算出当前的RTT。这种方式,充分考虑了程序处理带来的延时,比ping方式更加准确。

抖动的含义与计算方式

实时音视频数据在互联网上传输,就会因为网络质量导致相邻数据包A、B的收包间隔大于发包间隔,这时就发生了抖动。音视频数据在播放时需要保证数据包的时序性,这就要求网络层必须能够计算出当前的抖动情况。

抖动的含义

如果Si代表第i个包的发送时间戳,Ri代表第i个包的接收时间戳。Sj、Rj同理。 抖动D(i, j) =|(Rj - Ri) - (Sj - Si)|。

这种错误容易收到噪声的影响,WebRTC为了统一抖动,并且为了很好的降噪、降低突发抖动的影响,把上面的抖动(i, j)定义为D(i, j)抖动J(i)定义为: J(i) = J(i-1) + (|D(i-1, i)| - J(i - 1)) / 16,这个里面D(i-1,i)的计算需要使用数据包网络层发送的时间戳。

总结

本次重点介绍了实时音视频领域衡量网络质量的基础指标丢包、延时、抖动。对指标的计算方法进行阐述,在学习的过程中发现WebRTC里面对于这些指标的统计方式考虑的很全面、例如抖动的计算增加了去噪处理,RTT的计算充分考虑了SR和RR丢失会带来的问题,后续将进一步分析WebRTC中拥塞控制算法的实现原理。

发表评论

电子邮件地址不会被公开。 必填项已用*标注