webrtc代码走读五（视频端到端时延分析）

一、延时对主观质量的影响（T-REC-G.114）

图中横轴坐标是毫秒，代表时延。纵轴坐标是用户的体验度。由上图，时延达到150毫秒的时候，用户体验度开始下降，当达到400毫秒的时候，用户的感受是无法容忍。
由此，ITU-T G.114国际标准规定，延时超过150毫秒表示已经开始影响用户体验，用户可以容忍的最高延时是400毫秒。

二、测试组网模型

三、视频处理流水

视频端到端时延，分三大块：发送端产生时延、网络产生时延、接收端产生时延。

四、视频发送端产生延时

1）摄像头产生延时

摄像头视频采集时会遇到成像延迟，主要由如下几方面组成：

1、CMOS/AD转换相关硬件产生延时。

2、视频增强处理，产生延时：比方说白平衡、防闪烁等。

3、视频数据传输产生的延时：例如下面这个云台视频输出格式有YUV、MJPE。

使用YUV传输的优点是不需要编解码，但是数据量大，这里1080P数据只能传输8fps。

使用MJPG传输的优点是数据量小，但是摄像头采集需要经过编码，应用程序使用的时候，需要解码。这里也会产生延时。

成像延时可以根据产品说明书提供的最大帧率计算，市面上较好的摄像头一秒可达50帧，成像延时约为20ms，如果是一秒20~25帧的摄像头，会产生40~50ms的延时；

需要注意当摄像头开启AE功能后，视频采集帧率会随着光强动态调整，实际使用时可能不能达到最大帧率值。

2）视频编码产生延时

与解码器性能、系统配置有关。需要实际仿真测试出具体值。

3）pacer产生延时

视频报文不同于音频报文，一个视频帧有可能分别封装在几个RTP报文，若这个视频帧的RTP报文一起发送到网络上，必然会导致网络瞬间拥塞。以25fps为例，若这帧视频的RTP报文，能够在40ms之内发送给接收端，接收端既可以正常工作，也缓冲了网络拥塞的压力。PACER就是实现把RTP同一时刻生产的若干包，周期性的发送，防止上行流量激增导致拥塞。

pacer延时取决于一帧视频实际的大小和帧率。正常来说，pacer的延时是1000/fps的大小。

五、网络产生延时

根据实际网络情况确定。可以通过webrtc提供的rtt参数计算。

六、视频接收端产生延时

1）JitterBuffer产生延时

JitterBuffer实现原理是，在收到网络上的RTP报文后，不直接进行解码，需要缓存一定个数的RTP报文，按照时间戳或者seq的顺序进行重排，消除报文的乱序和抖动问题。JitterBuffer分动态JitterBuffer和静态JitterBuffer两种模式：

1、静态JitterBuffer缓存报文个数固定。

2、动态JitterBuffer是根据网络环路延时的情况，动态调整缓存报文个数。

JitterBuffer产生的延时与JitterBuffer的深度有关。目前webrtc采用的是动态JB的思想。解码器解码结束后，找frame_buffer要帧，若当前帧完整无缺，直接送给解码器。若当前帧不全，需要等一个kMaxWaitForFrameMs固定时长，超过这个固定时长，直接跳下一帧。

所以JB产生的延时在0到kMaxWaitForFrameMs固定时长之间。

2）视频解码产生延时

与解码器性能、系统配置有关。需要实际仿真测试出具体值。

3）视频渲染产生延时

与显卡性能有关，需要实际仿真测试出具体值。

在windows10操作系统，使用potplay播放器采集摄像头视频，直接opengl渲染回放，测试出（视频采集+视频渲染）=80ms

视频采集大概1000ms/30fps=30+ms。所以视频渲染大概是80ms-30ms=40ms-50ms左右。

七、端到端视频延时小结

视频端到端延时=摄像头采集延时+视频编码延时+pacer延时+网络延时+JB延时+视频解码延时+视频渲染延时+接收发送端系统调用延时。

在intel i7-7700 cpu@3.60GHZ 16G内存 windows10操作系统，以25fps摄像头、openh264 480p分辨率，网络0延时，视频端到端固有延时：

摄像头采集延时40ms
+视频编码延时7ms
+pacer延时40ms
+网络延时0ms
+JB延时0ms
+视频解码延时3ms
+视频渲染延时40ms
+接收端系统调用延时15ms
+发送端系统调用延时15ms
=160ms。