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条数据。其实很正常。因为我是在现网环境下统计的，现网一直都有流拉起，所以数据量会一直增长。

结尾

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