上一篇,我们分析了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的延迟,这和芯片性能相关。

以上就是采集、前处理、编解码环节,时延是如何形成的。第三篇我们将分享在传输、渲染环节,有哪些影响时延的因素。