《直播疑难杂症排查》之三:首开慢

举报
且听风吟 发表于 2019/12/17 11:03:18 2019/12/17
【摘要】 七牛直播云在 2016 年 6 月发布之后,帮助广大客户解决过形形色 色的问题,如直播卡顿、马赛克、花屏、黑屏、杂音、音画不同步等等等等,这其中,有一些是网络原因,有一些是开发者的使用姿势问题,有一些是参数配置错误,当然,也有一些是 SDK 本身的问题。总结下来,如果开发者能够对直播领域的一些基础知识有更深入的了解,掌握一些基本的排障手段,很多问题是能够很快自行解决的,甚至也能够更好地防患于...

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

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

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


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

  • 播放卡顿

  • 首开慢

  • 延时高

  • 音画不同步

  • 马赛克严重

  • 播放黑屏、花屏、绿屏

  • 播放杂音、噪音、回声

  • 点播拖动不准

  • 直播发热问题

  • 其他问题(待续)

本文是 《直播疑难杂症排查》系列的第三篇文章,我们来看看直播过程中,最重要的一个性能指标:首开。


首开慢的表现

点击播放后,需要好几秒才能显示播放画面。

常见首开慢问题排查

点击播放后才从服务器取播放地址

播放视频,第一件事就是要拿到播放地址,大多数直播 App,主播的播放地址是由 App 向服务端发 HTTP GET 请求才能拿到的,因此,什么时候去「拿」 这个播放地址,显得至关重要,常见的做法有如下两种:

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

用户点击某个视频,跳转到播放界面之后

显然,后者的用户体验明显会比前者差,因为通过 HTTP GET 请求播放地址的过程,无形增加了首开时间,特别是在弱网下,会更慢。

DNS 解析慢

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

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

如果要支持用 IP 地址播放,是需要修改底层 ffmpeg 源码的,目前我们七牛的 PLDroidPlayer 就支持这样的播放地址: URL 格式「protocol://ip/path?domain=xxxx.com」

播放策略原因

播放首开时间的定义,就是从点击播放到第一帧画面显示出来的耗时,因此,我们需要尽一切可能加快播放进度。

很多侧重点播的播放器,为了减少卡顿,会有一些缓冲策略,当缓冲足够多的数据之后 ,再送入解码播放。

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

播放参数配置

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

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

服务端线路原因

当播放端的优化做到极限后,剩下的首开快慢的决定性因素就是服务端的线路了,服务端的线路主要有哪些方面会影响首开呢? - 冷热流

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

同等大小的数据,客户端距离服务器越近,ttl 越小,那么传输速度也就越快,首开也会越快。 服务器的响应速度

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

下面给出一张图,来直观的感受一下服务端在加速首开这件事上的关键作用:


1240

七牛的实时流网络 (LiveNet),我们会根据网络流量、各节点的连接、负载状况及到用户网络的响应时间等综合信息,实时地将用户的请求调度到最佳服务节点上,同时可计算出最佳服务节点与视频源节点的最佳网络路径,使用户可以更快速的获取到视频内容,提高视频服务的响应速度和用户体验。


1240

小结

关于首开慢的排查大致就介绍到这里了,下篇我们将对延迟高这个话题进行探讨。


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

本文转载自异步社区。

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


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。