上一篇，我们分析了5种流媒体系统与音视频延迟的关系。今天，我们将按照数据的流动步骤，分析每个环节是如何影响音视频时延的，首先分享的是音视频“采集、前处理、编解码”这三个部分是如何引入时延，以及我们的优化方案。
媒体数据流动步骤：
采集：把模拟信号变成数字信号；
前处理：包括3A之类的，把它变成纯净的信号；
编码：将信号送给编码器做编码编成码流，做数据压缩；
传输：把码流通过网络传输到对端；
抗抖动：对端在播放时要考虑流畅，卡顿的时候没法用，因此要做缓冲；
解码：当有一定数据积累后给解码器解码；
后处理：恢复信号后有的产品会需要做后处理（通常不需要）；
渲染：最后交给设备做渲染，实现音频播放视频播放。
上面整套流程的每个环节都会引入时延，我们可以针对每一环节去做优化。
1）采集
音视频采集环节的延迟，与硬件设备、采集的参数配置相关。在即构侧来说，我们是和操作系统的接口打交道。在音频采集时，我们需要考虑音频采样频率，每一次API返回的采样点数。比如：
如果我们以44.1K赫兹去采样，系统 API 每次返回 1024 个点的数据，那么就有 23.2ms 的延迟，再加上一些设备的延迟，最终的延迟会大于23.2ms。如果以48K赫兹去采样，系统 API 每次返回 192 个点的数据，延迟只有 4ms。
但也不是越短越好，这里需要针对应用场景做权衡，很多情况下减少采集帧长的意义不大，一方面编码的帧长有要求，另一方面可能会增加 CPU 开销。并且发送封包需要加包头，帧越短，需要拼帧做编码，payload 占比太小，意义没那么明显，甚至会增加额外开销。
2）前处理
第二个是前处理。比如实时音频的回声消除、噪声抑制、自动增益3A处理；语聊场景的变声；实时视频的美颜、挂件、磨皮、瘦脸等。这些都会产生时延，我们可以从两个角度来看时延的产生：
第一个是算法的固有时延，在下面的图片中，原始数据是蓝色的曲线，我们想通过FIR低通滤波给它做平滑处理，可以看到这个效果是不错的，它确实变平滑了而且它的波形没有太大变化，但是我们也可以看到它整体向右移了，这其实就是算法的固有时延。
第二个就是计算时延，尤其是对视频来说有更大的挑战。通常我们会把这个计算交给GPU，那么GPU就有额外的负担，这是一个异构的计算，我们要把数据给GPU，再把数据从GPU拉下来，这里是需要同步的，我们发现会有10%-20%的延迟。而为了得到这么大的吞吐量一定要依靠GPU，因而这个是避免不了的。
3）编解码
这是比较重要的部分，这里主要指的是信源编码。信源编码的主要目的是压缩，把传输所需要的字节数压缩减少，它需要权衡几个方面的东西：第一个是质量，第二个是码率，第三个是时延，第四个是吞吐。在同等码率下，一个编码方案引入的时延越高，通常来说质量会越高。
我们可以看看常见的编码方案对延迟的影响：
首先是音频的编码方案，以我们常用的HE AAC编码方案和开源的OPUS方案为例，HE AAE系统设计会引入129ms的固有时延，而OPUS可以做到10ms内，通常我们在低延迟的时候会选择OPUS。
在视频编码方面，H.264是目前广泛应用的标准，它有多种编码类别，像baseline profile、main profile等，这两种编码最大的区别是baseline profile只产生I帧和P帧，而main profile除了I帧和P帧外还会产生B帧，B帧是双向参考帧，它会参考未来的数据，当编码帧率是20帧每秒，一个B帧将引入50ms的额外延迟。因而在实时通信场景中，我们通常都是用baseline profile。
另一方面，不同的编码实现对质量与延迟都会产生影响，以视频编码为例。我们要考虑是用软件实现编码还是硬件实现编码，软编通常效果会比硬编好，一方面软编有非常多的策略去做提升优化，另一方面软编的时延通常会比硬编的低。
当然也不是说软编就能完爆硬编，硬编的吞吐量大，当分辨率很大、码流很大的时候，软编是hold不住的，所以还是要依赖硬编。而硬编又依赖于具体的芯片实现，在某些芯片的实现上，硬编可能会达到70ms的延迟，而硬解可能会达到130ms的延迟，这和芯片性能相关。
以上就是采集、前处理、编解码环节，时延是如何形成的。第三篇我们将分享在传输、渲染环节，有哪些影响时延的因素。