本文首发地址：开源实践网：RTMP直播累积延时和网络抖动的优化(卷一原理)
问题一 累积延时
对于交互性要求较高的直播业务来说，采集推流端和观看端的延时太高是不可接受的。在 直播协议的选择：RTMP vs. HLS 一文中提到了采用 RTMP 协议做直播业务，一般可以将延时控制在 1-3s 或者更低。但是如果在直播中发生卡顿、播放暂停等情况时，也会不断积累推流端和观看端的延时。这种累积延时要怎么优化呢？
一、优化切换前后台带来的累积延时
在直播场景中，有一种情况是切换前后台造成累积延时。这里举个例子：在前台时，直播视频在播放，然后退到后台，此时暂停播放器，音视频数据继续缓存，当回到前台时，继续从刚才退出时的视频流数据开始播放，而实际的直播现在已经不在这个时间点了。这段前后台切换的时间里，就积累了一段延时。
对于这种延时改怎么处理呢？
- 第一种方案是播放器采用视频同步音频的策略，然后退到后台时保持音频继续播放（在 iOS 平台需要开启 App 的 Background Audio 能力来配合）。这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可。
- 第二种方案是回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时。但是这种方案的问题是重连直播流的过程需要一定的时间，这样回到前台时会有卡顿，或者出现黑屏，尤其是当你的首屏加载优化不够时，这个卡顿或黑屏时间会较长。所以这种方案在你的首屏加载优化的比较好的情况下可以采用。此外，你可以退到后台时截取视频当前帧贴图到直播间上，从而当切回前台时，防止黑屏，优化体验，实践效果还是不错的。
二、优化卡顿带来的累积延时
在理想的情况下：网络状况良好；采集推流端、流媒体服务器、播放端均吞吐正常无阻塞，可以不配置缓冲区。这时候推流端到播放端的延时将会很小，基本上就是网络传输的耗时。
但是在实际情况中，我们多多少少会遇到网络不佳或网络抖动的情况，在这种网络环境下，如果没有缓冲策略，直播将发生卡顿。为了解决卡顿，通常会根据具体情况在采集推流端、流媒体服务器、播放端增加缓冲策略，而一旦发生缓冲，就意味着推流端到播放端的延时。当卡顿情况多次出现，这样的延时就会累积。
此外，从 RTMP 协议层面上来讲，累积延时本身是它的一个特征，因为 RTMP 是基于 TCP，所以不会丢包，在网络情况不佳的情况下超时重传策略、缓冲策略等自然会带来累积延时。
所以，优化卡顿带来的累积延时首先是要优化整个直播链条的网络状况去减少卡顿。从这个角度出发，我们可以采用的策略包括：
- 使用 CDN 分发网络。
- 合理采用 CDN 边缘节点推流。
- 推流端、播放端使用 HTTPDNS 选择网络状况最好的节点接入。
- 推流端实现码率自适应策略，在网络状况不佳的情况下，降低推流码率来降低上行带宽压力。
- 流媒体服务器提供多档位直播流服务，与此同时，播放端实现直播流多档位切换策略，在网络状况不佳的情况下，切换到低档位直播流来降低下行带宽压力。
问题二 网络抖动的优化
除了这些外，我们还可以优化各端的缓冲策略来降低累积延时。直播链条各端的缓冲区通常都是为了防止网络抖动以及端上性能抖动产生卡顿，但是各缓冲区的数据越多，通常也意味着累积延时越大。所以在各端上，我们还可以尝试这些策略：
- 在「卡顿」和「累积延时」这两项体验指标上寻找一个平衡点，在各端设置合适的缓冲区大小。
- 在各端实现一些丢帧策略，当缓冲区超过一定阈值时，开始丢帧。
- 在播放端的缓冲区过大时，尝试断开重连。
- 服务端推流可以分高，中，低三种质量的流，根据拉流端网络质量动态的切换
问题三 如何优化弱网下推流端
推流端是整个数据的起点，如果推流端因为网络原因推到服务端的视频是卡顿的，那么接收端的视频肯定也是卡顿的，所有推流端出现问题，一般都是批量问题。幸运的是，在具体的业务中，推流端一般能够保证设备性能和网络质量。但如果不能保证，在弱网环境下，为了保证推流的流畅性和低延时，我们需要弄一些策略使推流更流畅，一般有如下策略:
(1) 降帧率
网络发送层发现发送速度过慢，反馈给camera采集模块，通过抽帧的方式来降帧率，降低整体发送的码率
(2) 降编码码率
网络发送层发现发送速度过慢，反馈给视频编码模块，通过动态调整编码器码率，来减小视频编码的输出码率。Android上的MediaCodec在4.3+版本上都是支持动态调整码率的； x264以及ios上的VideoToolbox也是支持的
(3) 使用H.265编码推流
使用H.265编码推流可以节省40%带宽，可惜的是并不是所有手机都支持用H.265编码格式播放，所以需要针对手机型号进行推流。
(4) 丢帧
上面两种方法，反射弧比较长一点，它们从pipeline上来看，操作的模块比较前面，生效比如慢一点，取决于各个模块间的缓冲的大小。丢帧策略的话直接作用于pipeline的末端，立即生效。
RTMP发送线程循环从一个缓冲队列里面读取帧，然后发送。为了方便作丢帧处理，encoder采用baseline的profile，这样，缓冲队列里面只存在I帧和P帧
如下 mVideoCount是这个缓冲队列里面视频帧的个数，mVideoCapbility是这个缓冲队列总的大小
if(mVideoCount >= mVideoCapbility/2){
dropFrame(0.3f);
} else if(mVideoCount >= mVideoCapbility/3) {
dropFrame(0.1f);
} else if(mVideoCount >= mVideoCapbility/4) {
dropFrame(0.05f);
} else if(mVideoCount >= mVideoCapbility/5) {
dropFrame(0.02f);
}
dropFrame的参数是丢帧的百分比，意思是相临两个gop之前丢掉的P帧的百分比。为了播放端不花屏，从一个GOP的最后面的P帧开始丢
