[zz] 直播中累积延时的优化

[zz] 直播中累积延时的优化

原文

-对于交互性要求较高的直播业务来说，采集推流端和观看端的延时太高是不可接受的。在 直播协议的选择：RTMP vs. HLS 一文中提到了采用 RTMP 协议做直播业务，一般可以将延时控制在 1-3s 或者更低。

但是如果在直播中发生卡顿、播放暂停等情况时，也会不断积累推流端和观看端的延时。这种累积延时要怎么优化呢？

优化切换前后台带来的累积延时

在直播场景中，有一种情况是切换前后台造成累积延时。这里举个例子：在前台时，直播视频在播放，然后退到后台，此时暂停播放器，音视频数据继续缓存，当回到前台时，继续从刚才退出时的视频流数据开始播放，而实际的直播现在已经不在这个时间点了。这段前后台切换的时间里，就积累了一段延时。

对于这种延时改怎么处理呢？

第一种方案是播放器采用视频同步音频的策略，然后退到后台时保持音频继续播放（在 iOS 平台需要开启 App 的 Background Audio 能力来配合）。这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可。

第二种方案是回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时。但是这种方案的问题是重连直播流的过程需要一定的时间，这样回到前台时会有卡顿，或者出现黑屏，尤其是当你的首