RTMP直播视频时延分析

RTMP + CDN的视频直播架构很容易搭建，但问题在于时延大，会累积。一般情况下，视频直播时延在2~3s，网络差一些就会有3~7s。长期播放的累积时延可能超过150s。

视频的实时性归纳为三个等级：

伪实时:      视频消费延迟超过3秒，单向观看实时，通用架构是CDN + RTMP+HLS,现在基本上所有的直播都是这类技术。

准实时： 视频消费延迟1 ~ 3秒，能进行双方互动但互动有障碍。有些直播网站通过TCP/UDP + FLV已经实现了这类技术,YY直播属于这类技术。

真实时:   视频消费延迟 < 1秒，平均500毫秒。这类技术是真正的实时技术，人和人交谈没有明显延迟感。QQ、微信、SKYPE和webRTC等都已经实现了这类技术。

从上面的实时标准划分来看，RTMP流就是伪实时技术。菠菜行业普遍采用的在线真人视频，用的就是RTMP直播技术，显然这是客观条件下不得已的选择。随着技术的进步，应该采用UDP技术进行优化，目标可设定为时延<2s，累积时延<3s。毕竟跨国直播要尊重一下GFW的存在。

延迟指视频画面从主播现场到达播放端的时间滞后。 RTMP 协议层面上来讲，累积延时本身是它的一个特征，因为 RTMP 是基于 TCP，所以不会丢包，在弱网络条件下超时重传策略、缓冲策略等自然会带来累积延时。

快速的优化措施是不动RTMP推流 + CDN分发的直播框架。采取改善TCP拥塞算法来进行：

1、视频源站全部通过ip route命令修改rto_min参数，建立改为30ms(default是200ms)。导致一次RTO就是200ms以上。

# ip route add 123.125.104.197/32 via 10.209.83.254 rto_min 30

2. 视频源站内核(centos7)开启Google TCP BBR加速。

TCP BBR 是 Google 提出的一种新型拥塞控制算法，可以使 Linux 服务器显著地提高吞吐量和减少 TCP 连接的延迟。

3、采取最适合低延迟的流参数。GOP=1s, fps=20, H.264 baseline.

根本性的改善则要用RUDP来替换TCP进行传输。可靠UDP(RUDP)是google的技术，webRTC和QUIC项目中使用。

采用RUDP的直播案例包括：学霸君APP和映客直播。

在教育公司学霸君在很多实时场景下确实使用RUDP技术，不同场景我们采用的RUDP方式也不一样。

1）  全局250毫秒延迟的实时1V1答疑，采用的是RUDP +多点relay智能路由方案。

2）  500毫秒1080P视频连麦互动系统，采用的是RUDP + PROXY调度传输方案。

3）  6方实时同步书写系统，采用的是RUDP+redo log的可靠传输技术。

4）  弱网WIFI下Pad的720P同屏传输系统，采用的是RUDP+GCC实时流控技术。

5）  大型直播的P2P分发系统，通过RUDP +多点并联relay技术节省了75%以上的分发带宽。

映客直播

 

使用基于UDP技术的QUIC传输，比TCP传输，在弱网条件下有了明显的改善。

QUIC在映客直播里的应用包括主播端的RTMP or QUIC和播放端的HTTP or QUIC。在这里主要用到它的两个特性，一个是减少了连接时间，优化秒开，一个是改进了丢包算法，优化了弱网卡顿。其中我们所做的工作包括：第一，移植QUIC。QUIC并不是一个协议的形式，它是集成在Chrome中的，因此我们需要把它移植到安卓平台、IOS平台。通过客户端移植QUIC，让内部RTMP支持QUIC，播放器也支持QUIC，我们服务端支持QUIC，可能稍微好一点，由于QUIC Go这样的项目比较容易集成，推流和拉流CDN也支持QUIC。在500Kbps和1%丢包的情况下，主播端使用QUIC和TCP同时进行RTMP推流。观看对比就发现使用QUIC推流，播放基本上是比较流畅的，而使用TCP推流的播放则是非常卡顿的。

我们的测试用例是用1080P 码率为300KB/S视频流，在router用netem上模拟了几种网络状态，其中：

         F.环路延迟300ms, 丢包15%，抖动100ms, 5%乱序，0.1%包损坏。这跟国际光纤跨越GFW的情况类似。

 

从上图可以看出，如果网络控制在环路延迟在200ms丢包在10%以下，可以让视频延迟在500ms毫秒以下，这并不是一个对网络质量要求很苛刻的条件。所以我们在后台的媒体服务部署时，尽量让客户端到媒体服务器之间的网络满足这个条件，如果网路环路延迟在300ms丢包15%时，依然可以做到小于1秒的延迟，基本能满足双向互动交流。这也就是，我们如果采用RUDP技术，跨国直播也能达到1s以内的时延。