延时高

1. 延时的测量

一般测量延时最简单的方法，就是推流端和播放端对着同一个时钟，然后用播放端显示的时间减去推流端显示的时间，就得到了粗略的直播延时。

2. 延时高问题分析

首先，我们看看可能产生延时的模块有哪些：

• 图像处理延时，比如画面剪裁、美颜、特效处理
• 视频编码/解码延时
• 网络传输的延时
• 业务代码中的缓冲区

一般图像处理、数据拷贝、编解码带来的延时，都是ms 级别的，真正会产生比较大延时的地方，一个是互联网上的网络传输延时，另一个就是业务代码中的缓冲区了。

2.1 网络传输延时

数据在网络上传输，从一个节点经过多级服务器转发到达另一个节点，是不可避免有物理延时的，下面这个表格给出了理论上数据在光纤中的网络传输的时间（实际场景中的延时往往比这个要大很多，因为涉及到带宽、网络抖动等干扰）播放端离推流端或者边缘服务器节点的物理距离越近，延时会越小。

2.2 业务代码中的缓冲区

业务代码中的缓冲区，主要是推流端的缓冲区和播放端的缓冲区，一个 30 fps 的视频流，缓冲区每滞留 30 帧,延时就会增大 1s，那么，它们是怎么产生缓冲数据的呢 ？

• 推流端的数据是怎么 “积累” 起来的 ？
  采集 -> 编码 -> 数据发送 -> [服务器]
  当网络产生抖动的时候，“数据发送” 会因此减慢，产生一定的阻塞，从而导致这些数据会被 “积累” 在了推流端的发送缓冲区中。
• 播放端的数据怎么 “积累” 起来的 ？
  [服务器]-> 数据接收 -> 解码 -> 渲染
  当网络产生抖动的时候，服务器的数据无法 “及时” 地传输到播放端，而由于 TCP协议的可靠性，所有的数据都会被服务端积累起来，在网络恢复良好的时候，会快速传输到播放端，这些数据会被动地 “积累” 在接收缓冲区中。
• 怎么消除业务缓冲区的累积延时呢 ？
  推流端的发送缓冲区，可以在网络恢复良好的时候，快送发送出去，从而消除掉这个累积延时。
  播放端的接收缓冲区，可以通过丢帧或者加速播放的方式快速消费掉缓冲区中的数据，从而消除累计延时。

2.3 协议延时

通常标准的直播协议有RTMP，HLV，HLS 三种，
一般RTMP/HLV 协议的延时在 1～3s，
HLS协议的直播延时则会更大，注重延时的直播应用，大都会选择 RTMP/HLV 协议，这些协议均是基于 tcp 的协议，tcp协议的多个特性导致其延时明显要高于基于udp的私有协议，主要有如下方面：

• 建立连接的三次握手
• ACK 机制
• 丢包重传

因此，如果想从本质上解决直播延时问题，还是要换成基于 udp 的私有协议来传输数据。

缓冲区.png

显示缓冲区” 其实是解码线程和 渲染线程 之间的桥梁，由于解码和渲染的抖动并不频繁，所以并不需要特别大的缓冲区，最低 3 帧左右即可，一帧在生产，一帧在消费，还有一帧在缓冲区中待命。

而 “帧缓冲区” 是用来抵抗网络抖动的，网络抖动往往是比较频繁的，抖动的时间也有时会比较久一些，所以 “帧缓冲区” 相对要设置得大一点，但以不过于影响内存和播放延时为前提。
对于直播场景，为了防止 “被动丢帧”，往往“帧缓冲区”默认是设置为 “无限大” 的，当检测到缓冲区达到一定阈值后，启动一些诸如主动丢帧或者倍数播放的方式，来快速消耗掉缓冲的内容，从而降低内存和延时。

ijkplayer.png
数据处理.png
直播专题问题排查-播放失败（一）
直播专题问题排查-播放卡顿（二）
直播专题问题排查-首开慢（三)
直播专题问题排查-延时高（四)
直播专题问题排查-音画不同步（五）
直播专题问题排查-黑屏、花屏、闪屏(六)
直播专题问题排查-播放杂音、噪音、回声(七)
直播专题问题排查-拖动不准(八)
直播专题问题排查-功耗高(九)
直播专题问题排查-马赛克(十)