解决低延迟问题的核心思想：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播放直播流延时控制小结。