一. 前言

一些涉及的基本概念：

• 转码：一般指多媒体文件格式的转换，比如分辨率、码率、封装格式等；
• 解复用(demux)：从某种封装中分离出视频track和音频track，然后交给后续模块进行处理；
• 复用(mux)：将视频压缩数据（例如H.264）和音频压缩数据（例如AAC）合并到某种封装格式的文件中去。常提到的MP4即是一种封装；
• 编码(encode)：通过专门的算法(例如H.264或AAC)来对原始音视频数据进行压缩；
• 解码(decode)：对压缩后的数据进行解压缩。

短视频APP中录制完成后，为什么要做转码：

1. 原始视频文件码率较大，上传下载都需要很长时间，不利于传播；
2. 编辑时增加特效、转场效果后，只是在预览中有效，原始文件并未改变，需要进行一次转码来把这些效果合成进最终的文件；
3. 多段视频进行编辑前转码拼接为一个文件，方便后续的编辑；
4. 目标格式和源文件格式不一致，比如需要从mp4转成gif。

为什么不在服务端做转码呢？

1. 短视频需要加入滤镜等效果，在移动端转码可以充分利用手机的GPU等资源，实现实时添加滤镜实时看到效果；
2. 原始视频码率较大，上传下载都需要很长时间。

转码的主要流程如下:

图1. 转码基本流程

其中Audio Filter和Video Filter分别是指音频和视频的预处理。

• 短视频转码的时机:

1. 多段视频的导入；
2. 转场完的合成；
3. 编辑完的合成。

二. Demuxer方案的选择

Demuxer模块的实现，主要有以下三种方案:

1. 方案一，使用播放器
   播放器的主要功能是播放，也就是从原始文件/流中提取出音视频，按照pts完成音视频的渲染。转码并不需要渲染，要求在保持音视频同步的情况下，尽快把解码数据重新按要求编码成新的音视频包，重新复用成文件。我们也曾经为了实现尽快这个要求，把播放器强行改造成快速播放的模式，但后来遇到了很多问题：

   • 音视频同步时机的问题，视频的解码是慢于音频的解码，必然需要实现同步逻辑。player中如果改成快速播放模式，player内部加上音视频同步的逻辑，改动非常大。如果player不管同步，解码数据直接上抛给调用层，则需要在短视频上层做音视频同步，引入了额外的工作量；
   • 使用硬解码时，从SurfaceTexture中获取的timestamp不准。因此最后放弃了这个方案。

2. 方案二，使用MediaExtractor
   MediaExtractor是Android系统封装好的用来分离容器中的视频track和音频track的Java类。优点是使用简单，缺点是支持的格式有限。

3. 方案三，使用FFmpeg
   使用FFmpeg的av_read_frame API来做解复用，即实现简易版的播放器逻辑。

   • 优点：FFmpeg中对视频格式有大量兼容的逻辑，相比MediaExtractor兼容性好，增加新的输入格式的支持会更容易，同时音视频同步逻辑的控制更简单；
   • 缺点: 需要引用FFmpeg，相对来说SDK体积较大。

方案二的兼容性不如方案三。相比方案一，方案三把音视频的解复用和解码都放到了同一个线程，av_read_frame能输出同步交织的音视频packet，上层逻辑调用更清晰。
同时短视频其他功能模块已经引入了FFmpeg，转码模块引入FFmpeg并不增加包大小，所以选择了FFmpeg方案。

三. 转码的数据传递

金山云多媒体SDK实践中，Demuxer实际上是在C层做的，但是接口的封装是在Java层。解码结构也是一样。Demuxer和Decoder之间如何高效地在Java和C层之间传递待解码的音视频包?

3.1 AVPacket的传递

FFmpeg的demuxer模块解复用出来的为音频或视频的AVPacket。最开始的时候我们并没有在Java层对整个AVPacket的地址指针进行封装，而是把数据封装在ByteBuffer和其他的参数中。这样遇到了很多因为AVPacket中的参数没有传递到解码模块导致的问题。

最终我们通过intptr_t在C层保存AVPacket的指针，同时在Java层以long类型来保存和传递这个指针，解决了这个问题。

3.2 AVFormatContext/AVCodecParams的传递

为了实现模块的复用，我们把Demuxer和Decoder分成了两个模块。使用FFmpeg来实现时，Decoder模块可以和Demuxer模块共用AVFormatContext，通过AVFormatContext来创建AVCodecContext。

但是这样会有一个问题，Demuxer的工作速度会快于Decoder，此时AVFormatContext是由Demuxer来创建的，Demuxer停止的时候会释放AVFormatContext。如果交给Decoder模块来释放，不利于模块的复用和解耦。最终我们发现在FFmpeg 3.3的版本中，AVCodecParams结构图中有Decoder所需要的全部信息，可以通过传递AVCodecParams来构造AVCodecContext。

四. 转码提速

转码的速度是客户非常关心的一个点，转码时间太长，用户体验会非常差。我们花了非常多的精力来对短视频的转码时间进行提速。经验主要有以下这些点：

4.1 调整视频软编编码参数

转码的时间大部分都被视频的编码占用了，我们把x264编码做了调整，在保证画质影响较小的前提下，节省了30%以上的编码时间。

4.2 优化GPU数据读取

使用视频软编时，如何从GPU中把数据“下载”到CPU上，我们尝试了很多中方案，具体的我们会在另一篇文章中详细解释。之前的方案是使用ImageReader读取RGBA数据。优化为用OpenGL ES将RGBA转换为YUVA。读取数据后从YUVA再转为I420，下载和格式转化总耗时，提速了大约40%。

4.3 开启硬编

硬编的缺点: 在Android平台上，硬编的兼容性较差，同时视频硬编的压缩比差于软编。
硬编的优点是显而易见的，编码器速度快，占用的资源也相对较少。

4.4 开启硬解

经过大量的测试，硬解的兼容性相较于硬编会好很多，使用硬解码，直接使用MediaCodec渲染到texture上，省去手动上传YUV的步骤，也节省了软解码的时间开销。

4.4.1 硬编解遇到的坑

关于Android的硬编解网上已经有很多例子，官方文档也比较完善。不过在实现过程中还是会遇到一些意想不到的问题。

• 图像质量的问题

在硬编上线后，我们对比画质发现转码图像质量较差。原因是使用MediaCodec API时，选择的是MediaCodecInfo.EncoderCapabilities.BITRATE_MODE_CBR，CBR的好处是码率比较稳定，但是会牺牲画质，移动直播中选用CBR更合理。短视频转码场景硬编时推荐使用MediaCodecInfo.EncoderCapabilities.BITRATE_MODE_VBR，VBR会获得更好的图像质量。对于软编时，我们也尝试过ABR(也就是VBR)，但实际测试下来效果并不能保证。

• 硬解不兼容AVCC/HVCC 码流格式

H.264码流主要分Annex-B和AVCC两种格式，H.265码流主要分为Annex-B和HVCC格式。AnnexB与AVCC/HVCC的区别在于参数集与帧格式，AnnexB的参数集sps、pps以NAL的形式存在码流中（带内传输），以startcode分割NAL。
而AVCC/HVCC 的参数集存储在extradata中（带外传输），使用NALU长度（固定字节，通常为4字节，从extradata中解析）分隔NAL，通常MP4、MKV使用AVCC格式来存储。
Android的硬解只接受Annex-B格式的码流，所以在解码MP4 Demux出的视频流时，需要解析extradata，取出sps、pps，通过CSD(Codec-Specific Data)来初始化解码器；并且将AVCC码流转换为Annex-B，在ffmpeg中使用h264_mp4toannexb_filter或hevc_mp4toannexb做转换。

• 硬解时间戳不准确的问题

硬解码器解码视频到Surface，此时通过SurfaceTexture.getTimestamp()获得时间戳并不准确，某些机型会出现异常。所以还是要使用解码输入的时间戳，可将解码过程由异步转为同步，或者将pts存储到队列中来实现。

• 音频硬编硬解解的速度

MediaCodec的音频编解码具体实现和机型有关，许多机型的MediaCodec音频编解码工作仍然是软件方案。经过测试MediaCodec音频硬编码较软编码有6%左右的提速，但MediaCodec音频硬解反而比软解的的速度慢，具体原因有待进一步调查。不过这只是部分机型的测试结果，更多机型的比较大家可以使用我们demo的转码/合成功能进行测试。

4.5 转码提速对比

下面以三星S8为例，短视频SDK在转码速度上的进步，更多机型的对比数据，请移步github wiki查看。

将1分钟1080p 18Mbps视频，转码成540p 1.2Mbps，不同版本时间开销大致如下：

可以看到，使用了硬编、硬解等提速手段后，合成速度由54秒优化到15秒。

五. 模块化的思考

金山云短视频SDK的基础模块是基于直播SDK，整体来说，是一套push模式的流水线。
流水线中的每个模块都很好地实现了解耦，单独模块完成单一的功能，模块的复用也非常方便。前置模块在产生新的音视频帧后，会立即push给后续模块，后续模块需要尽快把前置模块产生的音视频帧消化掉，最大程度上保证实时性。为了保证音视频同步等逻辑，引入了大量同步锁。在短视频的开发中，遇到了不少的死锁和不方便。对于短视频这种非实时的场景，更多的时候，需要由后续模块(而非前置模块)来控制整个流程的进度。
当前处理过程中需要实现暂停，需要在前置模块加锁来实现。为了能方便以后的开发，我们会在接下来重新梳理这种push流水线的方式, 实现模块化的同时，尽量减少同步锁的使用。

六. 总结

转码对于普通用户来说不可见的，但却是短视频SDK的一个重要过程。怎么样让转码过程耗时更短，转码图像质量更高，特效添加更灵活，减少我们团队自身的开发和维护成本，同时也为开发者提供最方便易用的API，一直是金山云多媒体SDK团队的目标。
团队在很用心的开发短视频SDK，欢迎试用！

转载请注明：
作者金山视频云，首发简书 Jianshu.com

Android短视频SDK：https://github.com/ksvc/KSYMediaEditorKit_Android
有关音视频的更多精彩内容，请参考https://github.com/ksvc

金山云SDK相关的QQ交流群：

• 视频云技术交流群：574179720
• 视频云Android技术交流：620036233