长视频优化：如何高效减少转码耗时

本文来自微信客户端技术团队，作者：瑞澈。

1.背景介绍

在视频号项目中，允许用户上传一分钟内的编辑视频，或者选择30min内的长视频。目前来看，整个发表（视频转码+上传）的耗时还略显偏久，虽然当下转码过程都是在手机后台运行，不会阻塞用户交互，但是由于视频未发表成功，视频点赞和转发功能都被限制，对用户和业务而言，这都是很不好的体验，有值得优化的必要。

1.1分析：耗时来源

整个耗时 = 视频转码耗时 + 上传耗时目前上传的时间取决于用户网络，这个不是本文讨论的重点，先暂时不予考虑。那么为什么我们需要对视频进行转码呢？

• 对于用户主动编辑的视频，我们需要重新处理视频才能满足需求。
• 考虑到网络带宽影响和用户观看端体验的优化（网速一定时，文件越大，下载的耗时等比增加），我们需要对视频做一些压缩处理，利于首次快速播放。
• 现在的手机屏幕普遍的分辨率是2k左右，让用户去加载4k的视频，是一种资源浪费。在尽量保证视频效果的同时，同时减小视频的体积，可以降低带宽和手机性能压力（编解码播放）。
• 如果用户的视频自身已经满足一般的播放条件，且又未编辑，此时我们会选择直接上传文件（前置MOOV结构，满足边下边播需求），降低二次转码对视频清晰度带来的损耗。

1.2 当前方案

在实现功能的前提下，在视频号发表侧我们选择了不同于其他场景的处理方式，用户编辑完成点击发表视频后，我们选择将整个视频合成的逻辑放到手机后台执行，不阻塞用户的交互，从而优化用户体验。 但是后台合成的耗时也不可小觑，当发表成功后，用户才可以执行点赞、分享等操作。长时间的等待，会降低用户对当前视频的关注度，降低这里的耗时，可以降低用户的等待时间，为活跃视频号分享有重大的意义。

1.3 当前业界主流方案

在满足一定限制条件（分辨率、码率和帧率）且未编辑的视频，允许直接上传后台；超过限制条件或者存在编辑的情况，则客户端转码后上传后台，后台再将视频转码成多路视频，按照策略向客户端下发。和我们当前的方案基本无异。

关于转码速度优化，目前主流的优化的方案，都是采用硬件编解码为主，优化渲染速度或者优化编解码的调用方式（MediaCodec 异步模式），通过降低每个流程的耗时，来优化时间。在一定程度上来说，这种优化方式是存在**“天花板”**的，每个流程是客观存在耗时的，在无多余等待或者操作耗时的时候，优化就到了尽头。

1.4 拓展方案和技术可行性分析

作为有理想的开发，我们是不会止步于此的。抽象一下问题，我们在深入思考类推一下： 对于普通的耗时任务而言，我们通常选取的优化手段是，判断任务是否有时间强相关性，否则可以通过多线程并行的方式来缩短耗时。这个思想在目前操作系统（多线程）和硬件（多核CPU）都得到了体现。 那我们的任务是什么呢？主要耗时又在哪里？任务相关性几何？ 任务是将长视频进行转码。细分一下模块，主要包括：视频转码和音频转码。相较于音频编码，视频编码存在更高的复杂度和数据量，所以主要耗时在视频转码。 一个普通的mp4文件，一般由多个轨道组成；最为常见的例子，也就是如下图所示的普通视频，包含一个音轨和一个视轨。

任务时间相关性呢？

视轨和音轨是相互独立的，彼此之间无相关性。在当前方案下，音轨和视轨是同时进行转码的，并且主要的耗时集中在视频转码之上，以此可以减少音轨转码带来的耗时。 接着在来详细分析一下视轨，视轨可以认为就是带有一组连续时间戳的静态图像压缩帧，这些帧按类型分为IPB帧；I帧可以独立解码，P帧和B帧需要依赖其他帧才能完成解码；GOP就是两个I帧之间的间隔。

那么我们是不是可以进一步的将视轨转码的任务也拆解一下，视频轨道中仅仅一组GOP内的视频帧存在依赖，GOP之间不存依赖；但是我们却让所有GOP串行执行，不禁想问一句：

1.4.1 技术可行性分析

针对这个问题，那我们是否可以按照GOP或者或者更长的时间区间来划分出多个任务，并行执行从而来减少耗时呢？**值得一试。**磨刀不误砍柴工，开始之前，还是需要先理论分析一波，确保方案的可行性。

正常处理一个视频，涉及到视频解封装、视频解码、渲染、编码和封装几个流程，另外按照并行处理的方式，视频封装的流程也会改变，从单段H264封装，转变为多段H264封装。

那么我们首先需要考虑的问题就是，DSP芯片、GPU和CPU是否支持多路并行呢？

其中多路解封装、视频解码、渲染和编码，这个从过往的经验中可以推论出来是可行的，比如预加载视频或者视频通话场景，或多或少都存在同时多路解码的场景。

那么多段H264封装是可行的吗？简单分析一下。

H.264基本流的结构分为两层，包括视频编码层（VCL）和网络适配层（NAL）。我们接触到的为NAL层，H264编码数据主要有多个NALU组成，其中NAL支持32种类型，那么我们编码出来的有哪些类型呢？

通过FFmpeg分析，我们打印一个普通的单段H264文件，可以发现主要有4种类型NALU，其中SPS和PPS出现在头部，主要是描述视频的一些基本信息，比如分辨率。IDR是I帧的一种特殊类型，IDR帧后面的参考帧，将不会参考之前的帧；SLICE可以认为是参考帧数据。

那么对于多段H264文件拼接，后面的IDR和SLICE正常拼接理论是没有问题，这和普通的单段H264文件结构是一致的；接下来需要考虑的就是头部的SPS和PPS如何处理，参照H264官方文档和一些技术博客，标准并没有限制每种NALU出现的位置，SSP和PPS也可以出现在文件中间，此时有两个作用：

1.解码器需要在码流中间开始解码
2.编码器在编码的过程中改变了码流的参数（如图像分辨率等）
可以简单理解为，H264数据中间的SPS和PPS可有可无，为了方便流程处理，我们直接拼接文件即可。

到此为止，理论方案分析完毕，结论依然是可行。

另外，并行流程中，仅仅是视轨并行转码，音轨保持原有逻辑处理独立处理，因为音轨的处理耗时并不是大头，并且音轨具有更高的敏感性，处理不当，问题会比较明显，相反人对于视频变化的敏感度反而没这么高。这也是为什么一般做音视频同步，往往是视频同步音频的原因。

1.4 可行性测试

Android平台手机类型多，系统版本分布广，性能高中低端分布不均。理论分析完成之后，我们还需要快速验证一下方案的效果如何；为了粗略测试一下并行合成的多机型手机合成效果和支持情况，我们先设计了可以同时运行多个转码任务的demo，期望通过wetest自动化快速测试，得到结论。

同时，我们根据现网视频分布，我们从时长、分辨率、码率、帧率、GOP和编码格式上划分，设计了以下视频用例：

设备用例，多多益善，我们尽量覆盖了全部可以运行的云真机，其中手机芯片覆盖列表（61款机型）

demo自动化测试结果如下，其中用例编号对应上文的视频用例，分段数指将视频转码任务均分成几个work来执行。

备注：正向的柱子表示当前分段下，相对于普通合成的耗时优化率。0表示当前合成任务因为一些原因导致失败。负向柱子表示当前分段下，相对于普通合成的耗时衰退率。

1.5 总结和推论

• A推论：低分辨率时，2-3段任务并行效果基本优秀30%以上；大于等于4段任务并行时，失败率增加（优化率<=0），优化效果降低。