视频直播技术（三）：低延时直播经验总结

解决低延迟问题的核心思想：NO BUFFER

低延迟：顾名思义，就是让播放端和推流端的时间差越小越好，那么如何作到低延迟呢，一个词归纳：no buffer

首先说明一下视频流的流向：推流端--->CDN服务器--->拉流端

1. 推流端 nobuffer，也就是保证推流端缓存的buffer最小。这样基本上保证在推流端出现网络抖动或者忽然变差的状况下，可以舍弃已经缓存的buffer，继续推新生成好的视频帧。这样保证了，在网络端开始传输的时候的视频内容是最新的。

2. CDN nobuffer，针对性的调整CDN的配置，让CDN服务器缓存的GOP尽量的少，这样保证拉流端获取到的是最新的内容。

3. 拉流端 nobuffer，既然推流和中转的CDN都设置了nobuffer，那么拉流端设置nobuffer的意义，应该不须要作过多的解释了吧。

记住一点：低延迟问题的解决不是一端的事情，三端的配置都会对延迟的效果产生影响。

拉流端（基于IjkPlayer）低延时直播的经验：

在直播的过程当中，有首开延时和内容延时。首开延时，基本能够控制在100ms左右；基于RTMP播放的内容延迟根据CDN的状况，基本上会在2~5秒左右。而由于RTMP是基于TCP协议的，因此在播放的过程当中会受到网络条件的影响，形成延迟增长的状况。经过了解直播流的推流和拉流相关的知识，能够知道，根据推流端（推流策略）与服务器（缓存策略）不一样的控制的设定，咱们极可能拿到几秒以前的内容（甚至十几秒），能够经过对比拉流端与推流端的内容便可得知。而这些内容，在拉流端会把CDN服务器缓存的数据拉取过来，这时buffer queue变大。那么，buffer queue越大，拉流端与推流端的延时越大。

拉流端影响延时的核心缘由： buffer queue 变大，拉流端播放的内容和推流端相差时延增长。

解决办法：

1. 控制max_buffer_size，合理设置max_buffer_size，使得拉流端不会缓存太长时间的内容（通过测试，发现不是很实用，由于内容延时只有追赶或者丢弃当前播放的内容，快速跳播到最新数据才能达到低延时播放）

2. 使用倍速播放，快速消耗Buffer Queue，在消耗到合理的区间后，进行正常播放（监听并动态控制buffer queue，此方案要求设备的解码性能可以支撑）。

3. 使用丢包（丢帧）策略。策略说明：

• 有音频流和视频流，或者只有音频流状况下，当audioq达到必定的duration，就丢掉前面一部分数据包，由于默认是AV_SYNC_AUDIO_MASTER，视频会追上来。
• 只有视频流状况，当videoq达到必定的duration，就丢掉前面一部分数据包。

下面是我在解决低延迟问题的时候，参考的丢包（丢帧）策略相关文章：ijkplayer丢帧的处理方案 、jkplay播放直播流延时控制小结。