**影响音视频延迟的关键因素（一）：流媒体系统**

低延迟的实时音视频技术应用场景在不断扩大，从秀场直播、连麦PK直播到在线教育、视频会议，音视频技术的落地应用朝着更高清、更低延时发展。下面我们来看看，构成音视频低延迟的因素有哪些，如何实现更低延时的实时音视频？

首先，来看看第一个影响音视频延迟的关键因素：流媒体系统

以下是目前比较流行的媒体传输系统的延迟对比：

第一个是HLS，这是苹果公司提出的一套传输协议，它依托于现有的Http框架，加上苹果强有力的推动，让它有了广泛的设备支持基础。但HLS是以切片为单位传输，默认 6s一个切片，播放器为了保障流畅，会默认缓存3个切片才开始播放。因此，即时不考虑任何其他因素，HLS的系统延迟就达到了18S；

在HLS基础上，基于Http的分块传输编码，LHLS做了优化，它可以做到3-7S的延迟。这套方案还在演进，苹果在去年的WWDC上提出了新的草案，新版草案号称可以做到2S，大家可以期待下。

第二个和第三个是RTMP和HTTP-FLV，这两个都是Adobe提出的，其实这两种协议在优化的较好的情况下是可以做到比较低延迟的，即构也支持RTMP，我们的方案可以做到实验室情况下400ms。但它有个硬伤，它的传输基于TCP，TCP在有丢包的情况下无法做流控，也就是说现实中它的延迟会达到秒级。

第四个就是比较火的WebRTC，在实验室情况它可以做到100ms以内，即构也有做WebRTC的网关，实测的话是300-500ms。

最后一个是即构自研的私有协议，这一套方案在实验室环境的延迟和WebRTC区别不大，因为只要有好网络，很多策略都用不上的，但是在有丢包、网络抖动的情况下，我们的表现会优于RTC，感兴趣的小伙伴可以与我们联系获取实测数据。

我们所说的延迟是端到端的延迟，那么按照数据的流动可以分为这几个步骤：采集、前处理、编码、传输、解码、后处理、渲染。这整套流程的每个环节都会引入时延，接下来我们会分享如何针对每一环节去做优化，敬请期待第二篇~