WebRTC视频数据统计之延时、抖动与丢包

一、前言

这篇文章主要想说明的是WebRTC内部对视频上下行延时、抖动、丢包如何更新，上层又怎么获取到这些统计信息的。对应的WebRTC版本：63。

二、背景

最近在内网情况下测试视频会议，视频下行延时很大，很多时候超过100ms。另外，视频的上下行抖动总是稳定在30~40ms这个区间。这些统计在内网环境下是不正常的，于是决定看看是哪里导致这些问题的。

在解决这些问题的过程中，也对WebRTC内部视频统计数据做了一次梳理。

阅读这篇文章之前，最好对RTP、RTCP、SR、RR有一些了解。这里就不过多展开，可以参考以下文章：

[RTP Data Transfer Protocol][https://tools.ietf.org/html/rfc3550#section-5]
[RTP Control Protocol – RTCP][https://tools.ietf.org/html/rfc3550#section-6]
[RTP/RTSP/RTCP有什么区别][https://www.zhihu.com/question/20278635/answer/14590945]

三、综述

下图是WebRTC内部获取视频统计信息和统计信息如何被更新的流程图：（其中的箭头代表函数调用）

上图中的类A~G属于公司内部代码，不便公开，还请见谅。总体共有两个大的模块，如何取和如何更新：
（ps: 下文关于流程图细节部分都取自于该图，读者可根据相关文字在总图中找到对应的位置 在这里下载上图的电子版： webrtc-statistics.gliffy）

1. 如何取

上面部分“客户端视频数据统计入口”中，左下角的WebRtcVideoChannel::GetStats是WebRTC对外暴露的获取统计信息的入口，视频的上下行统计数据最终分别使用右上角SendStatisticsProxy::stats_、ReceiveStatisticsProxy::stats_和CallStats::avg_rtt_ms_来填充返回。

2. 如何更新

下面部分“延时、抖动、丢包更新流程”部分，从网络接收到RTP/RTCP之后，使用三个不同颜色代表三种统计信息的更新流程，比如红色代表下行抖动/丢包更新流程、蓝色代表RTT的更新流程等。

统计信息大多不是由一条调用流程完成的（这就是下文会说到的“阶段”），会有几次类似缓冲区的“中转”，然后由另外的线程或函数继续做统计信息的整理，最终达到上一步的SendStatisticsProxy::stats_、ReceiveStatisticsProxy::stats_和CallStats::avg_rtt_ms_，等待上层获取。

四、几个统计信息详细介绍

1、延时