理解实时音视频聊天中的延时问题一篇就够

前言

音视频实时通讯的应用场景已经随处可见，从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑，再到银行视频开户等。对于开发者来讲，除了关注如何能快速实现不同应用场景重点额音视频通讯，另一个更需要关注的可能就是“低延时”。但是，到底实时音视频传输延时应该如何“低”，才能满足你的应用场景呢？

1、延时的产生与优化

在聊低延时之前，我们先要讲清延时是如何产生的。

由于音视频的传输路径一样，我们可以通过一张图来说明延时的产生:

在音视频传输过程中，在不同阶段都会产生延时。总体可以分为三类：

 

4.1设备端上的延时

音视频数据在设备端上产生延时还可以细分。设备端上的延时主要与硬件性能、采用的编解码算法、音视频数据量相关，设备端上的延时可达到 30~200ms，甚至更高。如上表所示，音频与视频分别在采集端或播放端产生延时的过程基本相同，但产生延时的原因不同。

音频在设备端上的延时：
 

• 音频采集延时：采集后的音频首先会经过声卡进行信号转换，声卡本身会产生延时，比如 M-Audio 声卡设备延迟 1ms，艾肯声卡设备延迟约为 37ms；
• 编解码延时：随后音频进入前处理、编码的阶段，如果采用 OPUS 标准编码，最低算法延时大约需要 2.5~60ms；
• 音频播放延时：这部分延时与播放端硬件性能相关；
• 音频处理延时：前后处理，包括 AEC，ANS，AGC 等前后处理算法都会带来算法延时，通常这里的延时就是滤波器阶数。在 10ms 以内；
• 端网络延时：这部分延时主要出现在解码之前的 jitter buffer 内，如果在抗丢包处理中，增加了重传算法和前向纠错算法，这里的延时一般在 20ms 到 200ms 左右。但是受到 jitter buffer 影响，可能会更高。

视频在设备端上的延时：
 

• 采集延时：采集时会遇到成像延迟，主要由 CCD 相关硬件产生，市面上较好的 CCD 一秒可达 50 帧，成像延时约为 20ms，如果是一秒 20~25 帧的 CCD，会产生 40~50ms 的延时；
• 编解码延时：以 H.264 为例，它包含 I、P、B 三种帧（下文会详细分析），如果是每秒 30 帧相连帧，且不包括 B 帧（由于 B 帧的解码依赖前后视频帧会增加延迟），采集的一帧数据可能直接进入编码器，没有 B 帧时，编码的帧延时可以忽略不计，但如果有 B 帧，会带来算法延时；
• 视频渲染延时：一般情况下渲染延时非常小，但是它也会受到系统性能、音画同步的影响而增大；
• 端网络延时：与音频一样，视频也会遇到端网络延时。

另外，在设备端，CPU、缓存通常会同时处理来自多个应用、外接设备的请求，如果某个问题设备的请求占用了 CPU，会导致音视频的处理请求出现延时。以音频为例，当出现该状况时࿰