活动回顾：音视频低时延应用的技术实践（上）
8月24-25日，由LiveVideoStackCon主办的音视频技术大会在北京召开。在解决方案专场，即构科技互联网业务部技术总监邱国钦（Randy）发表了《音视频低时延应用的技术实践》的主题演讲。他首先从整体上分析了延迟是怎么构成的？有哪些关键点需要特别关注？基于对延迟的整体认识，分享低延迟的应用及技术实践。
现场座无虚席，慕名而来的观众在演讲后与Randy老师进行了多轮互动。以下是活动现场的演讲实录，由于内容比较丰富，我们将分成上下两篇分来进行分享，这是上篇，主要介绍实时音视频中延迟是怎么构成的：
一、主流流媒体系统的延迟
大家好，今天我要分享的主题是：音视频低延时应用的技术实践。首先我们来看下目前比较流行的媒体传输系统的延迟对比：
第一个是HLS，这是苹果公司提出的一套传输协议，它依托于现有的Http框架，加上苹果强有力的推动，让它有了广泛的设备支持基础。但HLS是以切片为单位传输，默认 6s一个切片，播放器为了保障流畅，会默认缓存3个切片才开始播放，理论上来说它的系统延迟就达到了18S；
在HLS基础上，基于Http的分块传输编码，LHLS做了优化，它可以做到3-7S的延迟。这套方案还在演进，苹果在今年的WWDC上提出了新的草案，新版草案号称可以做到2S，大家可以期待下。
第二个和第三个是RTMP和HTTP-FLV，这两个都是Adobe提出的，其实这两种协议在优化的较好的情况下是可以做到比较低延迟的，即构也支持RTMP，我们的方案可以做到实验室情况下400ms，但它有个硬伤，它的传输基于TCP，TCP 对抗丢包的策略不合适于实时流媒体传输，也就是说现实中它的延迟会达到秒级。
第四个就是最近比较火的WebRTC，在实验室情况它可以做到100ms以内，我们自己也有做WebRTC的网关，实测的话是300-500ms。
最后一个是即构自研的私有协议，这一套方案在实验室环境的延迟和WebRTC区别不大，因为只要有好网络，很多策略都用不上的，但是在有丢包、网络抖动的情况下，我们的表现会优于RTC，感兴趣的小伙伴可以与我们联系获取实测数据。
二、影响音视频通信延迟的关键构成
我们所说的延迟是端到端的延迟，按照数据的流动可以分为这几个步骤：
采集：把一个数字信号变成模拟信号；
前处理：包括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的延迟，这和芯片性能相关。
4）传输
传输其实是非常复杂的过程，涉及到运营商、物理距离、接入方式以及节点部署等多方面因素。传输的极限是光速，光在光纤中的传输速度大概是20万每秒，从北京到深圳，大概需要10ms，但在实际传输过程中，使用光纤到户这种方式传输大概需要20ms，用4G的话会达到80ms，我们实测的5G会好很多，5G更接近光纤。
在传输方面做延迟的优化，可以通过以下几个方面来实现：
第一，更好的基础设施。比如FTTH（光纤到户）、5G，如果没有好的网络，做低延迟的优化是不现实的，所以首先是要加强网络建设；
第二，合理部署服务。让我们的服务本身足够靠近用户，做好全链路最优路由；
第三，针对实时流媒体优化传输控制协议。现实的网络中抖动、丢包是不可避免的，我们需要针对这种特性去设计我们流媒体传输的协议，包括重传、估算可用带宽、编码，根据网络情况加入编码冗余；为了对抗抖动要加dejiitter等
5G对低延迟的影响有这两个方面：第一高可靠低时延通信，它的空口时延号称达到1ms，我们自测的话是接近光纤，基于此我们可以实现一些关键操作，比如远程控制，工业的自动化；另一个是增强型移动宽带，它可以达到很大的上行，我们测的话可以达到7/800兆，上传4K、8K的视频没有太大压力。
即构很期待5G的到来和铺开的，首先我们方案是转控分离的，我们的信令面和媒体转发面是分开的，转发面我们就可以从一个localDC到另一个localDC，不需要再往上面去扩，这样更靠近用户走更短的路径，有时延的优化；第二是我们控制面是有状态的，那我们还是往上走，控制面并不影响数据的延迟。
5）渲染
最后一个是渲染，渲染时会调用系统的接口，因此系统接口的类别对时延的影响很大。如安卓我们用OPENSL ES，这个是低时延的关键，还有一些厂商做的私有接口优化，比如耳返。在某些场景耳返是个重要功能，如唱歌过程中歌声需要实时返回耳朵来判断唱的准不准，那这里的时延就非常关键，如果不做耳返优化，在VIVOX9它的时延可能达到了279ms，而当开启优化之后，时延降低到14ms，这是非常明显的优化。
即构的接口SDK已经去适配这些厂商，拿到了他们的文档、接口，我们做了适配，选择即构的方案，就可以即插即用。
以上是分环节来分析，但降低延迟是一个系统性工程，任何单个节点出现异常，都会引发整体异常。下图上下两部分是两个极端，上半部分粒度很粗，采集、前处理、编码一起做完给传输，对端解码、后处理、渲染也一口气做完。这样做，在设备性能好的情况下，延迟是可以比下面的流水线实现低的，但是吞吐是有问题的；
另一个极端是把每个环节拆的很细，采集、前处理、编码、后处理等环节都当成一个个单独的任务，拆的很细就会有另一个overhead，我们把数据从前一个抛给后一个是生产者和消费者的关系，这样是自带Buffer的，Buffer就意味着延迟。因此我们需要权衡考虑设备的能力和怎么去拆分与整合每个环节任务，做更合理的分割。
关于低延迟的应用及技术实践，请看下篇。