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

低延时是音视频领域最常遇到的关键诉求，如何设计解决方案以满足低延时的应用场景至关重要，本文将基于低延时的解决方案和实例进行讲解，分享一些应用的实践，帮助开发者更快地将解决方案应用到产品中。 内容来自即构科技互联网业务部技术总监邱国钦在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 延迟的构成

延迟可以理解为声音靠声带振动发声，传到别人耳朵里的过程，在端到端的延迟中可以分为信号采集、前处理、编码和传输这几个步骤，流程中的每一个环节都会引入延迟，如果想做到