RTMP系统推流播放延迟分析

　　一个经过优化的RTMP-CDN网络端到端的延迟大概在2-3秒，延迟大一些要在5秒甚至10秒以上。从推流到播放，会引入延迟的环节有编码延迟、网络丢包和网络抖动、视频的分段传输、多媒体节点的relay、播放器的缓存等等。实际上除了网络丢包和网络抖动不太可控之外，其他的各个环节都有一定的优化方案，比如使用x264的-preset ultrafast和zerolatency，可以降低编码的延迟，分段传输部分可以把GOP减少到1秒之内，在播放器端可以适当减小buffer，并设置一定的追帧策略，防止过大的buffer引起的时延。（积累延迟：原因是RTMP基于TCP不会丢包，所以当网络状态差时，服务器会将包缓存起来，导致累计的延迟）

　　虽然RTMP直播系统从推流端到网络传输到播放器都可以做到深度定制来达到比较低的延迟，但是成本是比较高的。如果做到超低延迟（1000毫秒内）更是难上加难，而且这么低的延迟也会带来一些负面的效果，当网络出现少许抖动的时候就会出现卡顿等等。

　　我们可以在现有的RTMP-CDN系统上做一些优化调整，在边缘节点把RTMP流转化为WebRTC可以播放的流来达到低延迟和CDN系统的复用，同时还可以利用WebRTC抗丢包来优化最后一公里的观看体验。WebRTC在各个平台上都有相应的SDK，尤其是在浏览器内嵌，可以极大的减少整个系统的开发、升级、维护成本，达到打开浏览器就可以观看的效果。

GOP-Cache

GOP是视频流中两个I帧的时间距离。GOP有什么影响？

　　Flash（解码器）只有拿到GOP才能开始解码播放。也就是说，服务器一般先给一个I帧给Flash。可是假设GOP是10秒，也就是每隔10秒才有关键帧，如果用户在第5秒时开始播放，会怎么样？等待下一个I帧，也就是说，再等5秒才开始给客户端数据。这样延迟就很低了，总是实时的流。可是问题是等待的这5秒，会黑屏，现象就是播放器卡在那里，什么也没有。所以服务器需要总是cache一个gop，这样客户端上来就以前一个I帧开始播放，就可以快速启动了。但是这样的问题是延迟就大了。所以编码器调低GOP，比如0.5秒一个GOP，这样延迟也很低，也不用等待。坏处是编码器压缩率会降低，图像质量没那么好。

积累延迟

　　服务器可以配置直播队列的长度，服务器会将数据放在直播队列中，如果超过这个长度就清空到最后一个I帧。当然这个不能配置太小，譬如GOP是1秒，queue_length是1秒，这样会导致有1秒数据就清空，会导致跳跃。延迟基本上就等于客户端的缓冲区长度，因为延迟大多由于网络带宽低，服务器缓存后一起发给客户端，现象就是客户端的缓冲区变大了，譬如NetStream.BufferLength=5秒，那么说明缓冲区中至少有5秒数据。