低延时是音视频领域最常遇到的关键诉求，如何设计解决方案以满足低延时的应用场景至关重要，本文将基于低延时的解决方案和实例进行讲解，分享一些应用的实践，帮助开发者更快地将解决方案应用到产品中。内容来自即构科技互联网业务部技术总监邱国钦在LiveVideoStackCon2019北京站上的精彩分享。
文 / 邱国钦
整理 / LiveVideoStack
大家好，我是即构科技互联网业务开发技术总监邱国钦，众所周知，在音视频技术方面有高清无码和低延迟这两个非常吸引人的应用，今天我演讲的主题就是关于音视频低延迟应用的技术实践。
首先做一个自我介绍，我到目前为止从事互联网音视频软件开发已经有9年的时间，先后就职于腾讯和即构科技，曾参与及主导QQ、即构音视频SDK等软件开发，目前在即构科技负责方案设计、评估与交付。
- 目录
本次的演讲分为三个部分，首先会从整体来分析影响音视频通信延迟的关键构成，基于延迟构成的认识，可以探讨一些音视频低延迟应用的技术实践，最后会对音视频低延迟技术做一些总结以及对未来的展望。
- 影响音视频通信延迟的关键构成
2.1 现有主流媒体系统的延迟对比
以现有主流流媒体系统为例，HLS (HTTP Live Streaming)是Apple的动态码率自适应技术，主要依托于现有的HTTP框架，加上Apple强有力的推动之后，形成了目前在包括IOS和各大浏览器上的广泛支持。但是HLS的传输单位是切片，默认状态下切片的长度是6s，此外，浏览器为了保证流畅，会在缓存3个切片后才开始播放，理论上系统延迟就达到了18s。
LHLS是一种基于HTTP分块传输编码以降低HLS协议延迟为目标的方案，它可以做到3-7s的延迟，但它还没有被正式写入标准协议中。Apple在今年的全球开发者大会上提出了一个新的草案，号称可以将延迟降低到2s，由于没有demo，真实性有待考证。
RTMP和HTTP-FLV都是由Adobe提出的，这两种协议在优化比较好的情况下可以做到低延迟的效果，即构科技也支持RTMP，并且可以将延迟控制在400ms以内，但是硬伤是在TCP发生丢包的情况下无法做流控，现实中的延迟可能会达到若干秒。由Google提出的WebRTC在实验室条件下可以将延迟控制在100ms以内，实测过程中的延迟可以控制在300-500ms之间。
最后是即构自研的实时音视频通信系统方案，这个方案在实验室条件下可以达到和WebRTC一样的延迟，但在有网络抖动和丢包的情况下，即构的方案要优于WebRTC。
2.2 延迟的构成
延迟可以理解为声音靠声带振动发声，传到别人耳朵里的过程，在端到端的延迟中可以分为信号采集、前处理、编码和传输这几个步骤，流程中的每一个环节都会引入延迟，如果想做到很细致的优化，就要在每一个环节下功夫。
2.2.1 数据采集过程中的延迟
接下来一起关注信号传输过程中每一个环节中需要关注的延时。数据的采集很多情况下与设备和采集的参数配置相关，例如音频通常需要考虑采样频率及采样点数。如果以44.1K Hz采样，1024采样点缓冲区，采集延迟就会大于23.2ms；如果以48K Hz采样，192采样点缓冲区，这时的延迟只有4ms。对于采集延迟而言并不是时间越短效果越好，而是需要在各项指标之间进行权衡，比如采样点越少，CALLBACK的次数越多，交互增加使得CPU相应增加，帧越短可能需要拼帧来完成编码等一系列的操作都会导致成本增加。
2.2.2 音频前处理
关于音频前处理大概可分为音频3A处理、变声、视频滤镜和美颜、挂件，造成音频前处理延迟的两大因素分别是算法延迟和计算延迟。算法延迟是滤波器固有延迟，而计算延迟对音频来说还可以接受，但在对于视频的计算延迟存在很多挑战，首先计算量需要多少CPU周期与CPU相关，其次CPU带来的异构计算和OpenGL都会带来延迟。
2.2.3 编解码
音视频通信延迟的编码部分主要是指信源编码，信源编码需要做到减少传输所需字节数，压缩数据量，压缩也要权衡音/ 画质、码率、延迟和吞吐四个方面，因此选择合适的编码方案就显得尤为重要。在同等码率下编码方案所用的延迟越高，压缩质量也会越高，两者不可兼得。比如HE AAC在配置时不论CPU运行速度有多快，都会引入129ms的固有延时，而OPUS可以把延时控制在10ms内，在同等低码率条件下HE AAC的压缩效果会比OPUS好，但我们会将码率提高到一定程度使得音质不会受损，在低延迟的情况下还是会选择OPUS编码方案。
H.264有多种编码的类别，包括Baseline Profile和Main Profile，这两种编码方案的区别是Baseline Profile只产生I帧和P帧，而Main Profile除了I帧和P帧还产生双向参考帧（B帧），假如编码帧率是20帧每秒，一个B帧将会引入50ms的延迟，因此虽然Main Profile编码方案的压缩率更高，但在直播场景和实时通讯场景都采用BaselineProfile编码方案。关于计算延迟更多涉及到的是视频部分，其中编码分为软件编码和硬件编码两部分，由于软件编码可以做的非常复杂，硬编的吞吐量大，当分辨率很大、码流很大的时候，软编是hold不住的，所以还是要依赖硬编。
2.2.4 流媒体数据传输
传输在音视频通信中是非常复杂的过程，其中涉及到运营商、物理距离、接入方式和节点部署。光纤中光速可达到20万km/s，从北京到深圳靠光纤传递信息大概需要10ms，但实际上数据每经过网络中一个节点都会引入延迟，并可能出现丢包现象。使用traceroute可以探测一个IP包送到目的地所经过的节点，通过发送 icmp 包，并指定 ip 包里的 TTL字段的值。TTL 指的是 Time To Live，IP 协议为了防止一个 IP 在网络中无限游荡，每个 IP 包都有这么一个字段，一个 IP 每经过一个节点，都会把这个值减1，如果这个值变成 0，就会丢掉。将TTL从小设置到大，直到足够送达目标地址。
但仅仅靠这两个简单的工具还不能够掌握网络的复杂性，这是由于有些服务器不响应 ICMP，导致没有响应，或者网络中某些节点，不会去修改 TTL，导致看到的节点数比真实的少，但这也不妨碍traceroute对网络情况和链路问题的判断。网络链路情况是非常复杂的，但是我们可以针对应用场景和兴趣给网络建模，建模主要的参数有 RTT、丢包率和带宽预测。
想要打造一个低延迟的通信网络，需要从以下各个层面入手：
首先需要有更好的网络设施，比如光纤到户（FTTH），5G，这些基础建设是做低延迟优化的基础。其次需要合理的服务器部署，做到就近接入，并做好全链路最优化路由。最后，现实的网络状况丢包不可避免，因此需要针对实时流媒体传输优化的传输控制协议，比如做好重传策略、带宽估计以及根据网络情况加入编码冗余等。
2.3 5G对传输的影响
5G的到来意味着更好的网络设施，而基础建设也是低延迟的基础。同时5G有三个应用场景， 第一个应用场景是增强型移动宽带，可以实时传输4K/8K的视频；第二个应用场景是高可靠低延迟通信，可以实现自动驾驶和远程操作等技术；第三个应用场景是大规模机器通信（IoT），即构会更加关注5G在前两个方面的应用。
5G本身有边缘云计算的需求，所以机房需要尽量靠近基站，把核心网很多功能移到边缘云。另外设备也区域小型化，会有更多的机房空间腾出来，可以用于边缘云建设；同时运营商也面临提速降费的压力，会有动力创造更多类型的营收。即构的网络架构本身就是按转控分离设计，边缘云用于数据转发是非常合适的，所以我们非常期待边缘云铺开可以进一步降低延时。
2.4 渲染对音视频通信延迟的影响
渲染主要是和系统接口打交道，重点是选择合适的接口以及参数配置。
对于 Android来说，使用 OpenSL ES 接口才能达到低延迟的最佳效果。还有一些手机厂商的私有接口，比如华为、OPPO、VIVO……例如耳返功能就有不少厂家提供了私有接口，可以更低延迟的实现耳返。上图列举了厂家私有 API 的耳返优化效果，例如VIVO x9在没有耳返优化的状态下延迟达到279ms，而在开启耳返优化后延迟降到了14ms，目前即构SDK已经可以支持主流手机厂商的耳返优化。
2.5 降低延迟是系统性工程
总之，降低延迟是一个系统性工程，任何单个节点出现异常，都会引发整体的异常。而主要的优化思路（客户端）也分为采用更低延迟的算法和更合理的任务分割两种。其实不管是在前处理还是在编码部分，都需要仔细考虑是否使用了更低延迟的算法，而更细粒度的任务分割可以让流水线更繁忙，压榨设备的性能，减少延迟。
上图所描述的任务分割粒度很粗，采集、前处理、编码都一起做完之后再交给传输，端解码、后处理、渲染也一口气做完。这种做法在设备性能好的情况下，延迟可以比下面流水线的延迟低。而使每一个环节都有自己的队列会引入额外的延迟，同时系统的吞吐量也会增加，可以做更多的事情，这其中需要在设备算力和任务分割之间权衡。
- 音视频低延迟应用的技术实践
3.1 低延迟应用的强互动性
低延迟应用的特点是强互动性，任何需要互动的场景都会对延迟有要求。互动的形式包括双向流媒体、单向流媒体+独立消息通道和单向流媒体。而这些形式的优化思路主要包括从架构设计与工程实现上逼近物理极限和从业务设计上降低用户对真实延迟敏感度两个方面。
比如视频聊天场景，如果单向延迟达到了1秒，除去对方思考的时间，听到对方的回应就是2秒后的事情了，这样的用户体验是非常糟糕的，将单向延迟控制在150ms以内用户是可以接受的。
3.1.1 直播应用场景举例
直播场景最初采用CDN来做分发，但CDN延迟很高，这与直播场景需求非常不匹配，打赏反馈延迟太高将影响营收。但是低延迟同时也意味着高成本，而即构的产品策略是区分人群，对部分VIP观众和少量参与“打赏”的观众采取低延时应用，而普通观众则采用低成本应用，由此达到节省成本的目的。
3.1.2 娃娃机应用场景举例
在线抓娃娃是曾经很火的应用场景，并且我相信，随着虚拟与现实、线上线下互动探索的更加深入，后续还有会类似的应用场景出现。
娃娃机在很多商场都能见到，非常简单也很受欢迎。为了突破场地的限制让大家随时随地抓娃娃，我们推出了线上版本。
这个方案的架构很简单，分为娃娃机、传输网络、玩家三部分。首先是娃娃机端，通过摄像头拍摄娃娃机，推流出去，玩家从实时网络把娃娃机的流拉回来观看到娃娃机的视频。这其中玩家的每一个指令都需要及时响应并及时反馈给玩家。
针对在线抓娃娃的应用场景，我们对延迟做了优化。首先以实时传输方案为基础定制采集设备、去掉视频滤镜以及去掉音频。
首先是数据的采集，娃娃机的采集端是可以控制的，因此可以定制设备让摄像头稳定以60fps采集。其次，额外的前处理是没有必要的，娃娃机不需要视频滤镜，另外的一个关键优化是去掉音频，娃娃机抓手移动的声音并没有什么吸引力，而去掉音频所带来对延迟的优化效果却是非常明显的，因为去掉音频就相当于去除了音频采集、音频前处理、音频编码、音频的传输、音画对齐、音频渲染等等环节所带来的延迟，类似可优化的应用场景还有远程挖掘机、远程医疗和串流游戏等。
3.1.3 AI教学
即构在去年年底推出了一套AI教学的方案，老师可以根据教研设计，参考学生可能出现的反应，录制好各种可能的视频。在上课时根据学生答题的的结果播放对应的视频。这个场景对延迟要求也很高，学生回答后需要及时的响应，否则学生会认为在做点播，缺少趣味性，即构的实时方案已经可以满足以上场景对延迟的要求。从某种意义上看，这就是一个点播系统，只是通过优化把延迟降低，使得点播看起来像是实时视频而已，在此基础上加上AI就变成了AI教学。
在AI教学场景中还存在的问题是，不同的视频片段之间需要做好衔接，传统的处理方法对拍摄的要求很高。为了缓解这个问题，即构提供了视频衔接过渡的优化方案，可以根据机器学习自动生成过渡内容。
3.1.4 KTV合唱双向流媒体互动举例
双向流媒体互动应用的场景之一是线上KTV合唱，如何把线下的 KTV 体验带到线上，让人们突破空间约束一起 KTV，即构提出了以下两个方案。
方案一又可以称之为“串行”方案。首先，歌手A随着伴奏唱歌，并把伴奏和自己的歌声一起发送给歌手B；歌手B听到A的歌声以及伴奏后加入唱歌，同时，歌手B把混入从A收到的声音推流给听众，为了让歌手A能够听到B的声音，B把自己的声音推流给A。
方案一的优点是即使网络延迟较大，听众听到的合唱总是合拍的，但缺点是A听到B的声音延迟是环回延迟，延迟无法控制在100ms内，通常不能被用户接受。
方案二又称之为“并行”方案。让歌手A和B在本地播放伴奏，各自随本地播放伴奏唱歌，单向的通过实时网络推拉流，使得延迟只有原来的一半，听到对方声音的延迟只包括单向延迟。
但要让这个方案完全可行，就必须让A和B两个人同时开始唱歌，如果启动不一致就会出现时间差的问题。第二个问题是听众独立播放两路流，也可能出现步调不一致的情况，需要对两路音频流进行同步。
为了让合唱场景的用户可以同时开始唱歌，我们需要一个可比较的时钟信号。实际上我们可以让双方共同参考伴奏音乐的进度来作为时钟，将伴奏播放进度时间戳发送给对方，让对方判断自己是否超前了。启动时间差可以通过估算启动时间差和加入合适的播放拉伸来进行消除。一方面我们需要让自己的方案尽量做到各个角度都低延迟，另一方面也需要从业务的设计上规避延迟所带来的影响，这两方面都是我们在未来需要思考的方向。
- 总结与展望
总结以上内容，低延迟的实现离不开各个环节的努力，包括客户端、服务端和业务端，低延迟需要更优的Codec、更好的网络设施、更好的传输协议（更底层的优化）和更深入具体应用场景打磨细节，产学研紧密结合，在未来低延迟更加可靠之后，将会对音视频应用带来变革。