音视频低延迟应用的四个技术实践

 

低延时是音视频领域最常遇到的关键诉求，如何设计解决方案以知足低延时的应用场景相当重要，本文将基于低延时的解决方案和实例进行讲解，分享一些应用的实践，帮助开发者更快地将解决方案应用到产品中。内容来自即构科技互联网业务部技术总监邱国钦在LiveVideoStackCon2019北京站上的精彩分享。

 

文 / 邱国钦

整理 / LiveVideoStack

 

你们好，我是即构科技互联网业务开发技术总监邱国钦，众所周知，在音视频技术方面有高清无码和低延迟这两个很是吸引人的应用，今天我演讲的主题就是关于音视频低延迟应用的技术实践。

 

 

首先作一个自我介绍，我到目前为止从事互联网音视频软件开发已经有9年的时间，前后就任于腾讯和即构科技，曾参与及主导QQ、即构音视频SDK等软件开发，目前在即构科技负责方案设计、评估与交付。

 

1. 目录

 

 

本次的演讲分为三个部分，首先会从总体来分析影响音视频通讯延迟的关键构成，基于延迟构成的认识，能够探讨一些音视频低延迟应用的技术实践，最后会对音视频低延迟技术作一些总结以及对将来的展望。

 

2. 影响音视频通讯延迟的关键构成

 

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. 音视频低延迟应用的技术实践

 

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两我的同时开始唱歌，若是启动不一致就会出现时间差的问题。第二个问题是听众独立播放两路流，也可能出现步调不一致的状况，须要对两路音频流进行同步。

 

 

为了让合唱场景的用户能够同时开始唱歌，咱们须要一个可比较的时钟信号。实际上咱们可让双方共同参考伴奏音乐的进度来做为时钟，将伴奏播放进度时间戳发送给对方，让对方判断本身是否超前了。启动时间差能够经过估算启动时间差和加入合适的播放拉伸来进行消除。一方面咱们须要让本身的方案尽可能作到各个角度都低延迟，另外一方面也须要从业务的设计上规避延迟所带来的影响，这两方面都是咱们在将来须要思考的方向。

 

4. 总结与展望

 

 

总结以上内容，低延迟的实现离不开各个环节的努力，包括客户端、服务端和业务端，低延迟须要更优的Codec、更好的网络设施、更好的传输协议（更底层的优化）和更深刻具体应用场景打磨细节，产学研紧密结合，在将来低延迟更加可靠以后，将会对音视频应用带来变革。