本文转自：直播中累积延时的优化 | www.samirchen.com
对于交互性要求较高的直播业务来说，采集推流端和观看端的延时太高是不可接受的。在 直播协议的选择：RTMP vs. HLS 一文中提到了采用 RTMP 协议做直播业务，一般可以将延时控制在 1-3s 或者更低。但是如果在直播中发生卡顿、播放暂停等情况时，也会不断积累推流端和观看端的延时。这种累积延时要怎么优化呢？
优化切换前后台带来的累积延时
在直播场景中，有一种情况是切换前后台造成累积延时。这里举个例子：在前台时，直播视频在播放，然后退到后台，此时暂停播放器，音视频数据继续缓存，当回到前台时，继续从刚才退出时的视频流数据开始播放，而实际的直播现在已经不在这个时间点了。这段前后台切换的时间里，就积累了一段延时。
对于这种延时改怎么处理呢？
第一种方案是播放器采用视频同步音频的策略，然后退到后台时保持音频继续播放（在 iOS 平台需要开启 App 的 Background Audio 能力来配合）。这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可。
第二种方案是回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时。但是这种方案的问题是重连直播流的过程需要一定的时间，这样回到前台时会有卡顿，或者出现黑屏，尤其是当你的首屏加载优化不够时，这个卡顿或黑屏时间会较长。所以这种方案在你的首屏加载优化的比较好的情况下可以采用。此外，你可以退到后台时截取视频当前帧贴图到直播间上，从而当切回前台时，防止黑屏，优化体验，实践效果还是不错的。
优化卡顿带来的累积延时
在理想的情况下：网络状况良好；采集推流端、流媒体服务器、播放端均吞吐正常无阻塞，可以不配置缓冲区。这时候推流端到播放端的延时将会很小，基本上就是网络传输的耗时。
但是在实际情况中，我们多多少少会遇到网络不佳或网络抖动的情况，在这种网络环境下，如果没有缓冲策略，直播将发生卡顿。为了解决卡顿，通常会根据具体情况在采集推流端、流媒体服务器、播放端增加缓冲策略，而一旦发生缓冲，就意味着推流端到播放端的延时。当卡顿情况多次出现，这样的延时就会累积。
此外，从 RTMP 协议层面上来讲，累积延时本身是它的一个特征，因为 RTMP 是基于 TCP，所以不会丢包，在网络情况不佳的情况下超时重传策略、缓冲策略等自然会带来累积延时。
所以，优化卡顿带来的累积延时首先是要优化整个直播链条的网络状况去减少卡顿。从这个角度出发，我们可以采用的策略包括：
- 使用 CDN 分发网络。
- 合理采用 CDN 边缘节点推流。
- 推流端、播放端使用 HTTPDNS 选择网络状况最好的节点接入。
- 推流端实现码率自适应策略，在网络状况不佳的情况下，降低推流码率来降低上行带宽压力。
- 流媒体服务器提供多档位直播流服务，与此同时，播放端实现直播流多档位切换策略，在网络状况不佳的情况下，切换到低档位直播流来降低下行带宽压力。
除了这些外，我们还可以优化各端的缓冲策略来降低累积延时。直播链条各端的缓冲区通常都是为了防止网络抖动以及端上性能抖动产生卡顿，但是各缓冲区的数据越多，通常也意味着累积延时越大。所以在各端上，我们还可以尝试这些策略：
- 在「卡顿」和「累积延时」这两项体验指标上寻找一个平衡点，在各端设置合适的缓冲区大小。
- 在各端实现一些丢帧策略，当缓冲区超过一定阈值时，开始丢帧。
- 在播放端的缓冲区过大时，尝试断开重连。
