ffmpeg视频云转拉耗时优化(续)

背景

https://cloud.tencent.com/developer/article/1149105?s=original-sharing 上次在这里详细分析了ffmpeg转拉过程中的耗时问题,经过一番努力,从1700+毫秒降到了600+毫秒。但是由于视频云整个流程比较长,而且只有冷流才会触发到转拉,所以客户那边对此的处的优化效果并不是特别明显。经过一番讨论,目前确定了一个立竿见影的方案,不过会导致带宽成本的增加。另外对于不提高成本的小优化,我们这边也应该继续研究。 最终经过一番分析与尝试后,再次将600+毫秒的耗时,降低到了400+毫秒左右。目前我们认为,如果想再有大的优化,应该已经不可能了。

过程分析

耗时分析

在上一篇我们已经分析了,主要耗时在avformat_open_input 和 avformat_find_stream_info。其中avformat_open_input的主要耗时在调用avio_open2这里建立连接。

图1,数据收集

第2列就是我们建立链接的耗时,这个文件经过将近一个月的累计,有90000+条数据了。

图2,建连耗时

可以看到,建立连接的耗时平均在250ms 左右。

图3,整体耗时

从进程启动到最后和目的端建立连接之前的耗时大概在643ms 左右。

代码分析

ffmpeg源码分析在上一篇咱们已经探讨过,主要优化点还是在avformat_find_stream_info 这个函数里面。上一篇中我们通过降低了fps_frame_count这个参数的值,达到了一定的优化效果。但是通过打日志分析

图4,avformat_find_stream_info部分源码

在avformat_find_stream_info中,会调用read_frame_internal这个函数。打日志发现,最后这个for(;;)无限循环退出的时候,减小fps_frame_count虽然会少读一些包,但是音视频都读了不少帧。后来我们分析帧率的for循环,其实最核心的代码应该是检查编解码器参数,也就是说对我们来说主要是has_codec_parameters()这个函数调用比较有用。

图5,帧率分析的for循环

有了编解码器参数后,在后续调用avformat_write_head的时候,咱们就可以直接创建输出所需要的一些数据结构。帧率这些参数,对于咱们的转拉这个业务来说,没太大必要。最后直接进行精简,将这个for循环减少到只剩下如下图所示

图6,精简后的for循环

精简后通过图4 中的打的日志,我们发现,只要音视频解码参数都有了,整个for(;;)就退出了。对于大多数情况也就调用read_frame_internal两次,一次读到音频,一次读到视频然后就退出了。由于avformat_find_stream_info的主要耗时就再read_frame_internal中(网络上读数据),所以减少这个函数的调用绝对是最直接的效果。

结果分析

下图是优化后的数据,相比于图1,他多了一列,最后一列是从main到和目的端建立连接的耗时。前面五列和图1完全一样。

图7,优化后的数据

同样是分析第五列,分析的是从ffmpeg的main函数开始,到和目的站建立连接之前的耗时,因为昨天才开始收集数据,所以数据量有点少只有1657条数据,平均耗时414.838毫秒。相比于上次优化,又提升了大概200+ms。

图8,和目的端建链钱的耗时统计

同时,我们也可以看下,和源端建立连接的时间,230毫秒,和上次差别不大。

图9,和源端建链耗时

另外我们也统计了从main到和目的端建立连接后的耗时,这个时间大概在469毫秒的样子,单纯我们主机和目的端建立连接耗时在53毫秒左右。可以看到比和源站建立连接块了很多,这个主要是网络的因素,源站多是第三方的机器,走外网,目的站都是走内网的,所以快很多。

图10,和目的端建链耗时

另外细心的读者可能会看到,发现数据量一直在变化,有的统计的是1657,有的统计的是1668条,有的是1669条数据。其实很正常。因为我是在现网环境下统计的,现网一直都有流拉起,所以数据量会一直增长。

结尾

其实之所以客户反馈首帧时间比较长,这个和咱们的整个视频云架构是有很大关系的,转拉只是整个架构流程中很小的一个环节,就像我开头所说,在其它某个环节改动下,能有立竿见影的效果,比我们这么一点一点的优化,省时省力,不过缺点也很明显,带宽增加,费钱。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java技术栈

Java开发必知道的国外10大网站

1、https://www.google.com/ ? 不解释 2、https://stackoverflow.com ? 里面包含各种开发遇到的问题及答案,质...

4167
来自专栏跟着阿笨一起玩NET

五层拆解 网站架构

本人转载:http://www.cnblogs.com/scottckt/archive/2010/09/15/1826925.html

1501
来自专栏程序员宝库

号称“开发者神器”的github,到底该怎么用?

GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者聚集在一起,与开源软件进行协作和报告问题。简而言之,它是一个基于Git构建的软件开发人员的平台。

984
来自专栏Youngxj

QQ综合工具箱-AD盒子

1834
来自专栏非著名程序员

绝对干货:供个人开发者赚钱免费使用的一些好的API接口

不久前,我写了一篇文章,名为《科普技术贴:个人开发者的那些赚钱方式》,讲了一些个人开发者接私活和自己做软件加广告的一些科普知识。可是做软件,需要服务器,需要后台...

4099
来自专栏老九学堂

号称“开发者神器”的GitHub,到底该怎么用?

相信这么努力的你 已经置顶了我 老九学堂 你身边的IT导师 提醒:大师兄会员课讲解视频在文末哦。 GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者...

33611
来自专栏JAVA高级架构

日处理20亿数据,实时用户行为服务系统架构实践

携程实时用户行为服务作为基础服务,目前普遍应用在多个场景中,比如猜你喜欢(携程的推荐系统)、动态广告、用户画像、浏览历史等等。 以猜你喜欢为例,猜你喜欢为应...

1472
来自专栏13blog.site

Spring+SpringMVC+MyBatis+easyUI整合基础篇(九)版本控制

作者:13 GitHub:https://github.com/ZHENFENG13 版权声明:本文为原创文章,未经允许不得转载。 前言 还好在第一篇文章...

3198
来自专栏顶级程序员

号称“开发者神器”的GitHub,到底该怎么用?

源 / 开源最前线 GitHub是一个拥有数十亿行代码的网站,每天有数百万开发者聚集在一起,与开源软件进行协作和报告问题。简而言之,它是一个基于Git构建的软件...

3817
来自专栏程序员的知识天地

为何Node.js 能成为 Web 应用开发最佳选择?

一项颠覆性的技术进入技术市场总会带来一阵震惊,但随之而来往往是被放弃。然而,Node.js 当然不是这样的情况,它是一个开源的、跨平台的基于 Chrome 的 ...

1423

扫码关注云+社区

领取腾讯云代金券