直播常见问题原因汇总

最新推荐文章于 2024-04-25 09:19:21 发布

原创

最新推荐文章于 2024-04-25 09:19:21 发布 · 9.6k 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#音视频

一播放卡顿

卡顿的本质就是播放器渲染的帧率太低，每秒显示不足25帧（人眼视觉特性经验值），可能的原因如下：

1视频流显示时间戳PTS问题
播放器一般是严格根据码流中的音视频PTS来做音画同步的，如果码流中的PTS出现错误，肯定会影响播放画面的渲染时机。例如 pts 1 50 100 160 70。。。PTS 出现了回退现象。而播放器master 主时钟是单调递增的，当后来的视频帧小于了当前的主时钟，说明视频显示慢了，播放器就会做丢帧处理，导致播放的视频帧率远低于码流中的视频帧率，从而产生卡顿现象。

2 网络带宽不足
码流本身没问题的话，接下来就是网络传输这一块了。直播出现卡顿，主播 -> CDN -> 观众三个端都可能是问题的源头：

1）主播端的网络不好，导致推流上行不稳定

2）服务端的线路质量不好，导致分发不稳定

3）观众端的网络不好，导致拉流下行不稳定

网络性能测试工具：ping， iperf，用法请自查。

3 播放设备性能不足
越高清的码率，对解码的要求也越高，很多手机性能不足以支撑 720P 甚至 1080P 的视频解码，特别是很多低端的 Android 手机，因此导致实际解码播放的帧率远小于视频码流的实际帧率，从而产生卡顿。

解决方案有如下几个方面：

1）. 硬解优先，充分利用 GPU 加速

2）. 如果有多种码流，尽可能在低端机上选择低码流

3）. 增大缓冲区，有助于缓解解码不稳定带来的卡顿

二首开慢

首开慢的表现：点击播放后，需要好几秒才能显示播放画面。

1 点击播放后才从服务器取播放地址
播放视频，第一件事就是获取播放地址，大多数直播 App，主播的播放地址是由 App 向服务端发 HTTP GET 请求才能拿到的，获取播放地址有2种方法：

1）App 拉取正在视频列表的时候

2）用户点击某个视频，跳转到播放界面之后--http get请求太慢，体验差

2 DNS 解析慢
不同的播放域名，DNS 解析有快有慢，再加上 DNS 解析服务的缓存策略，在本地没有该域名缓存的情况下，会逐级向更高级的域名服务器查询域名，因此，播放域名解析的耗时，会对首开产生不小的影响。

为了有效降低 DNS 解析对首开的影响，我们可以提前完成播放域名->IP 地址的解析，并缓存起来，播放的时候，直接传入带 IP 地址的播放地址，从而省去了 DNS 解析的耗时。

3 播放策略原因
播放首开时间的定义，就是从点击播放到第一帧画面显示出来的耗时，因此，我们需要尽一切可能加快播放进度。很多侧重点播的播放器，为了减少卡顿，会有一些缓冲策略，当缓冲足够多的数据之后，再送入解码播放。

而为了加快首开效果，需要对播放的缓冲策略做一些调整，如果第一帧还没有渲染出来的情况下，不要做任何缓冲，直接送入解码器解码播放，这样就可以保证没有任何因为「主动」缓冲带来的首开延时。

4 播放参数配置
所有基于 ffmpeg 的播放器，都会遇到 avformat_find_stream_info 这个函数耗时比较久，从而增大了首开时间，该函数主要作用是通过读取一定字节的码流数据，来分析码流的基本信息，如编码信息、时长、码率、帧率等等，它由两个参数来控制其读取的数据量大小和时长，一个是 probesize，一个是 analyzeduration。

减少 probesize 和 analyzeduration 可以有效地减少 avformat_find_stream_info 的函数耗时，从而加快首开，但是需要注意的是，设置地太小可能会导致读取的数据量不足，从而无法解析出码流信息，导致播放失败，或者出现只有音频没有视频，只有视频没有音频的问题。

5 服务端原因
当播放端的优化做到极限后，剩下的首开快慢的决定性因素就是服务端了，服务端主要有哪些方面会影响首开呢？

1）冷热流
当你去附近的边缘服务器节点拉取某个流的时候，如果最近没有任何人从该服务器拉过这个流，那么这台服务器就需要逐级向源头拉流，而且该服务器还需要进行 GOP 缓存，从而产生比较大的首开延时。

2）边缘节点的距离
同等大小的数据，客户端距离服务器越近，那么传输也就越快，首开也会越快。

3）服务器的响应速度
影响服务器响应速度的因素，一个是跟服务器的协议层优化有关，另一个就是服务端的负载和性能了，服务器当前负载越大，响应自然越慢。