直播系统开发中，各类直播源码对于低延时的需求

3~5秒延时对于多数常见的直播形式一般问题不大, 基本上满足之前遇到的直播形式，但在某些场景下，直播的体验非常差，例如我们最常见的连麦，如果延时超过了1s，基本上整段垮掉。对于这种场景，现在一般的直播平台采取的方案一般是借助第三方的连麦服务，然后再推给CDN厂商来加速视频传输的速度。从对业务的支持层面来看, 仅仅有RTMP、FLV这种3~5秒延时以上的直播形式已经不够了, 需要对更低延迟的直播业务进行支持。

短延时直播VS实时音视频通信

使用WebRTC主要用于解决实时音视频通话的需求，必然对延迟要求非常严格, 一个会议室中参与的多方可以进行视频通话, 每个参与者可以看到其他参与者，也能听到其他参与者说话。每个参与者既有推流，又有播放，数据是双向的。所以参与人数不会太多，一般不能超过20个。

短延时直播仍然是直播业务类型, 只是延时比较低, 短延时直播的业务模型相对简单, 数据单向传输，一个主播推流，参与的播放者人数没有限制，上百万都可以。

直播如何实现低延迟

要选择一条最优的路径，有很多方法。目前使用比较多的是网络测速，用户个人连接数据分析，和用户群体连接数据分析等几种方法来选择最优的网络路径。

网络测速

推流端在推流之前，向各个路径发送简单的数据包，然后根据数据包响应的时间来推测哪条路径最快。这个方法比较简单，有效然而有限：选出来的路径只是在该测试时间点最快的，而网络状况是随着时间变化的；另外，简单数据包测出来速度比较快，并不代表流媒体传输数据速度也比较快。因此，这个方法得到的结果只能作为一个指标来参考。

大数据分析

为了回避单个采样时间点测速导致的偏差，可以采取对历史大数据进行分析，预测哪个网络路径最优。对历史大数据进行的分析分为两个维度：用户个人连接数据分析和用户群体连接数据分析。

低延时是直播系统开发中常见的问题之一，各类直播源码对于延迟的要求又略有不同，普遍都是需要更低的延迟一直播业务的顺利进行，如何实现低延迟也将是直播系统开发成败的因素之一。