直播低延时踩坑

1、选择一条最优的路径

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

其中：

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

2）大数据分析：采取对历史大数据进行分析，预测哪个网络路径最优。

对历史大数据进行的分析分为两个维度：用户个人连接数据分析和用户群体连接数据分析。

2.1）用户个人连接数据分析

每个主播用户的使用历史数据是有规律可循的。

通过分析这些历史数据，可以发现主播用户从哪里接入，在什么时候接入，接入到哪个服务器，走什么路径的效果最优。

这些历史数据积累得越丰富，历史数据分析得出来的结论就越靠谱。

这个方法能够发现个人主播用户周期性的网络连接情况，能找出大部分时间连接效率最优的网络路径。

缺点：数据采样只是基于单个用户，采样点太少，没有全局考虑到该用户所在地区的整体网络连接情况。

2.2)用户群体连接数据分析

针对某地区用户群体连接数据的分析。

针对某用户所在区域的用户群进行历史数据分析，可以发现这个区域网络连接随着时间变化的规律，找出在不同的时间点，在不同的接入点连接到哪个服务器最好。

总结：

单点网络测速，用户个人连接数据分析，再加上用户群体连接数据分析综合得到结论，就能比较有效地预测哪条路径最优。选路这部分需要不断地优化，才能积累丰富的用户数据，同时适应网络的变化。

2、在这条路径上做到最优

选好最优的路径以后，剩下的就是要在该路径上做到最优。这条路径包括了下面几个环节：采集，编码，推流，转码，分发，拉流，解码和渲染。

2.1）选择协议：推流端的协议有RTMP, WebRTC和基于UDP的私有协议。

RTMP是基于TCP的标准协议，CDN网络普遍支持，也能做到相对比较低的延迟

WebRTC的好处在于用户体验好，不需要安装东西，分享一个链接就可以看。缺点是浏览器支持度低，Google Chrome和Opera支持WebRTC，其他浏览器大部分不支持WebRTC。

基于UDP的私有协议无连接，避免了TCP做网络质量控制所需要的开销，能够做到比较低的延迟。缺点是私有协议的兼容性不好。

2.2）前向纠错（FEC，英文全称Forward Error Correction）和丢包重传

FEC是通过提前采取措施来对抗网络损伤。（前验方法）

 丢包重传主要针对丢包的情况下，有针对性地对丢失的数据包进行高效率的重传。（后验方法）

这部分内容不是为了降低延迟，而是为了对抗网络损伤。能很好地处理网络抖动带来的负面影响，间接也会降低了延迟，同时保证了稳定性和流畅性。

2.3）缓冲自适应

由于有网络抖动的存在，数据包的到达不是匀速的。最直接的降低延迟的方法就是把缓冲队列的长度设置为零，接收到什么数据包就直接渲染什么数据包，然而这样做的后果就是播放不流畅，会出现卡顿。

寻找低延迟和流畅之间的平衡点，寻找平衡点的有效方法就是建立缓冲队列。在拉流端和混流服务器都需要建立缓冲队列。对于一个实时系统来说，缓冲队列的长度必须不是固定的，而是自适应的：当网络很好的时候，缓冲队列的长度就会变得比较短，接近零，甚至为零；当网络不好的情况下，缓冲队列的长度会变得比较长

2.4）码率自适应

由于网络环境的复杂多变，码率要能自动适应网络状况的变化。

在网络比较差的时候，要降低码率，让直播保持低延迟和流畅性；在网络比较好的时候，要提高码率，让直播保持高清画质。

RTMP对码率自适应能做的事情比较有限，因为它基于TCP, 而TCP 下层已经做了网络质量控制，当网络出现拥塞的时候，上层应用不会及时得到通知。基于UDP的私有协议更加适合做码率自适应，因为它基于UDP，而UDP只负责发包和收包，把网络质量控制交给应用层来做，这样应用层会有足够的空间来实现码率自适应。

 3、保持所有路径优质

要实现低延迟，网络基建必须要足够好。网络基建的质量可以通过以下三个方面来提高：

全网充分覆盖：音视频云服务的机房会分布在核心的几个枢纽城市，边远地区的用户的访问质量是得不到保障的。

全方位保障QoE：所有的网络接入点都使用了BGP（边界网关协议）

优质的网络节点资源：为了实现直播技术的低延迟，最好能对接一线的网络运营商，这样部署的网络节点资源无论是数量还是质量上都是有充分的保障。