《直播疑难杂症排查》之四：延时高

七牛直播云在 2016 年 6 月发布之后，帮助广大客户解决过形形色 色的问题，如直播卡顿、马赛克、花屏、黑屏、杂音、音画不同步等等等等，这其中，有一些是网络原因，有一些是开发者的使用姿势问题，有一些是参数配置错误，当然，也有一些是 SDK 本身的问题。

总结下来，如果开发者能够对直播领域的一些基础知识有更深入的了解，掌握一些基本的排障手段，很多问题是能够很快自行解决的，甚至能够更好地防患于未然。

因此，继《直播技术详解》系列文章之后，我们推出了这个新的系列《直播疑难杂症排查》，我们会把协助客户解决直播问题的经验逐步分享出来，同时也会穿插一些音视频开发的基础知识和优化经验，希望能够帮助到直播领域的开发者们。

本系列会涵盖的内容包括但不限于如下一些主题： - 播放失败

• 直播卡顿

• 首开慢

• 延时高

• 音画不同步

• 马赛克严重

• 播放黑屏、花屏、绿屏

• 播放杂音、噪音、回声

• 点播拖动不准

• 直播发热问题

• 其他问题（待续）

本文是 《直播疑难杂症排查》系列的第四篇文章，我们来看看直播的延时问题。

延时的测量

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

延时高问题分析

首先，我们看看可能产生延时的模块有哪些： 1. 图像处理延时，比如画面剪裁、美颜、特效处理 2. 视频编码/解码延时 3. 网络传输的延时 4. 业务代码中的缓冲区

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

网络传输延时

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

由该表可以看出：播放端离推流端或者边缘服务器节点的物理距离越近，延时会越小。

业务代码中的缓冲区

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

>>>>推流端的数据怎么「积累」起来的呢 ？

采集 -> 编码 -> 数据发送 -> [服务器] 当网络产生抖动的时候，「数据发送」会因此减慢，产生一定的阻塞，从而导致这些数据会被 「积累」在了推流端的发送缓冲区中。

>>>>播放端的数据怎么 「积累」起来的呢 ？

[服务器]-> 数据接收 -> 解码 -> 渲染 当网络产生抖动的时候，服务器的数据无法「及时」地传输到播放端，而由于 TCP 协议的可靠性，所有的数据都会被服务端积累起来，在网络恢复良好的时候，会快速传输到播放端，这些数据会被动地 「积累」在接收缓冲区中。

>>>>怎么消除业务缓冲区的累计延时呢 ？

推流端的发送缓冲区，可以在网络恢复良好的时候，快送发送出去，从而消除掉这个累计延时。

播放端的接收缓冲区，可以通过丢帧或者加速播放的方式快速消费掉缓冲区中的数据，从而消除累计延时。

协议延时

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

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

小结

关于播放延时高的问题排查大致就介绍到这里了，下篇我们将对音画不同步这个话题进行探讨。

本文作者：卢俊@七牛云。如果有你感兴趣的问题，但是不在上述列表中，也可以来信 lujun.hust@gmail.com 交流，欢迎关注新浪微博 @卢_俊 或者 微信公众号 @Jhuster 获取最新的文章和资讯。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=NC7E3EF941A400001E8D379602C301D00