由于新冠疫情,我们待在家中,在网上工作,开会,看电影的时间越来越多了。网络嘛,大家都知道,时常不稳定,网上开会时声音听不清楚,图像模糊,视频有马赛克(不是人为打的)的情况时有发生,这时候,问题出在哪里呢?
也许是网络的问题,也许不是,即使网络出现问题,只要不是不可忍受的,我们依然需要进行调整,保证基本的功能:
- 语音通话要保持通畅,这是要首先保证的
- 共享的桌面或文件内容要能够识别
- 视频要能看到,哪怕分辨率低点也行
首要的事情是要搞清楚出了什么问题?网络传输问题,设备问题,编解码的问题,还是音视频源的问题?
网络抓包后分析媒体流是常规的媒体质量分析方法,可是用户和服务器都不可能让你随时随地去抓包,何况还有安全和隐私问题的红线。所以剩下的选择就是度量 metrics, 做好度量就能见微知著,透过现象看本质,为上述问题找出答案。
先看一个例子 WebRTC Statistics Example, 源码很简单,参见
就是建立一个本地端到端的连接,将收集到的统计数据打印出来
1) Audio Inbound-rtp 接收的 Audio RTP 数据度量
注:
JitterBufferDelay: 类型为 double , 单位为秒,抖动缓冲区的目的让子弹飞一会儿, 将收到的 RTP 数据包暂存一下, 等一会儿再将缓冲区的 RTP 包重新组合成帧或者重新排序并平滑播放。此处描述的模型假设样本或帧仍处于压缩状态且尚未解码。
它是每个音频样本或视频帧从抖动缓冲区接收到第一个数据包的时间(收取时间戳)到它退出抖动缓冲区的时间(发出时间戳)所用时间的总和。
在音频的情况下,多个样本属于同一个 RTP 数据包,因此它们将具有相同的摄取时间戳,但不同的抖动缓冲区发出时间戳。
在视频的情况下,帧可能是通过多个 RTP 数据包接收的,因此收取时间戳是进入抖动缓冲区的最早数据包,发出时间戳是整个帧退出抖动缓冲区的时间。该指标在样本或帧退出时增加,在缓冲区中完成它们的时间(并增加 jitterBufferEmittedCount)。
平均抖动缓冲延迟可以通过将 jitterBufferDelay 与 jitterBufferEmittedCount 相除来计算。jitterBufferEmittedCount:类型为 unsigned long long
从抖动缓冲区中出来的音频样本或视频帧的总数
2) Audio outbound-rtp 发送的 Audio RTP 数据度量
3) Video Inbound-rtp 接收的 Video RTP 数据度量
注:
- totalDecodeTime: 花费在解码上的总时间(以秒为单位),所解码的帧数可由 framesDecoded 得到
- totalInterFrameDelay 连续解码的帧之间的帧间延迟总和(以秒为单位),在帧解码后立即记录。
可根据公式:(totalSquaredInterFrameDelay - totalInterFrameDelay^2/framesDecoded)/framesDecoded,从totalInterFrameDelay、totalSquaredInterFrameDelay 和framesDecoded 计算帧间延迟方差。
- totalSquaredInterFrameDelay
连续解码的帧之间的平方帧间延迟的总和(以秒为单位)
4) Video outbound-rtp 发送的 Video RTP 数据度量
WebRTC statistics API
详细的 API 和数据结构定义参见 https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/getStats
- candidate-pair: refer to RTCIceCandidatePairStats.
- inbound-rtp: refer to RTCInboundRtpStreamStats
- outbound-rtp: refer to RTCOutboundRtpStreamStats
- remote-inbound-rtp: refer to RTCRemoteInboundRtpStreamStats
- remote-outbound-rtp: refer to RTCRemoteOutboundRtpStreamStats