转载请联系: 微信号: michaelzhoujay

原文请访问我的博客

众所周知，Android 对涉及底层硬件的 API 控制力都比较弱，从其难用的 Camera/Camera2、MediaCodec 等 API 就可见一斑。

最近项目中有需要对视频进行编辑的需求，总体分析有如下技术上需要实现的点：

首先，按照 Android 官方的文档推荐，当然首推 MediaCodec。

MediaCodec 尺寸裁减

首先用 inputBuffers 读取帧数据到 outputBuffers，如果需要使用 MediaCodec 裁减尺寸，按照上图 MediaCodec 的流程以及官方的文档，需要在处理 output buffer 时将每一帧的数据处理为 bitmap 然后根据左上角的坐标和右下角的坐标对图像进行裁减 Bitmap.createBitmap 实际上这样裁减的过程还是在利用 CPU 来进行裁减

MediaCodec 取帧

使用MediaMetadataRetriever

MediaCodec 截取

截取实际上在第一步的 output 就可以做了，因为 outputbuffer 里每一帧的数据就有时间戳信息，MediaCodec.BufferInfo.presentationTimeUs

怎么样，看起来这套方案还是不错的，但是实际操作下来有几个严重的问题：

如果使用MediaCodec来编码H264视频流，对于H264格式来说，会有一些针对压缩率以及码率相关的视频质量设置，典型的诸如Profile(baseline, main, high)，Profile Level, Bitrate mode(CBR, CQ, VBR)，合理配置这些参数可以让我们在同等的码率下，获得更高的压缩率，从而提升视频的质量，Android也提供了对应的API进行设置，可以设置到MediaFormat中这些设置项:

MediaFormat.KEY_BITRATE_MODE

MediaFormat.KEY_PROFILE

MediaFormat.KEY_LEVEL

但问题是，对于Profile，Level, Bitrate mode这些设置，在大部分手机上都是不支持的，即使是设置了最终也不会生效，例如设置了Profile为high，最后出来的视频依然还会是Baseline....

FFmpeg 由于其丰富的 codec 插件，详细的文档说明，并且与其调试复杂量大的编解码代码(是的，用 MediaCodec 实现起来十分啰嗦和繁琐)还是不如调试一行 ffmpeg 命令来的简单。

利用 FFmpeg 做视频编辑大家一般都会去参考这个 repo ，但是他的 asset 里面的 ffmpeg 大小高达 18MB，即使压缩进 APK 包里也会达到 9MB。对 APK 大小敏感的开发者肯定颇有微词。 ffmpeg-android-java 的原理很简单，交叉编译好可执行的 ffmpeg 二进制文件放到 asset 里，安装后释放二进制文件到 /data/data/ 里，用 Shell command 的形式去执行这个文件，好处是没有任何依赖(依赖全打进二进制了)，稳定可靠(不需要动态加载)。 坏处就很明显了，因为是二进制文件，所以 size 会很大。

于是，果断放弃这种方式，转而编译 ffmpeg 的 so 库，动态加载然后执行命令。听起来不错，对不对？动态库的大小肯定比 ffmpeg-android-java 的 executable 要小多了，而且自己编译 ffmpeg 还能对其进行裁减。

相信很多开发者都会使用 ijkplayer，ijkplayer 底层也用到了 ffmpeg，ijk使用的是 so 库的形式，libffmpeg.so。所以最理想的状态是，重新编译一个公共的 libffmpeg.so，这个 libffmpeg.so 即有 ijk 需要的 decoders 和视频编辑模块需要的 encoders。但是一旦 ijk 或者 ffmpeg 有升级就会很麻烦，因为得重新编译一次 ffmpeg，而且还得 fork ijkplayer，然后每当 ijk 更新的时候将 ijkplayer master 合并到你 fork 分支，视频播放又是很常用的模块，很难做到“无痛”升级。

如果不动 ijk 的 ffmpeg，单独为视频编辑模块编译一个 ffmpeg.so ，与视频播放模块隔离开，这样就可以无痛升级 ijk 依赖 ffmpeg 的视频播放库了。但是，问题来了，如果存在两个 ffmpeg 的话不可避免的会存在冗余。所以编译视频编辑模块的 ffmpeg 时，要裁剪他的 encoders 和 decoders 尽量做到两个 ffmpeg 模块是正交的就 ok了。

交叉编译 FFmpeg 的过程就不赘述，网上有太多教程，这里简单记录一下编译的步骤：

同步 x264 的 repo，这里我选择的是 YIXIA INC 的 mirror.

编写编译脚本：

找到x264 repo 的根目录下的 configure 文件，找到 echo "SONAME=libx264.so.$API" >> config.mak 改为 echo "SONAME=libx264-$API.so" >> config.mak

执行编译脚本进行编译，结果在会在 build/ 文件夹下

接下来编译 FFmpeg, 先同步 ffmpeg 的 repo

编写编译脚本：

执行编译脚本，编译结果会在 /Users/xxx/ffmpegbuilddir/ffmpeg-install-dir/arm/ 目录下

到此，你已经拥有了能在 arm 平台上 load 的 so 文件

在上面的编译脚本中，我们考虑到 so 的输出大小，configure 中有这么一行 --disable-ffmpeg，意为不编译 ffmpeg 的可执行文件，这样我们就没有 ffmpeg 的执行入口，相当于没有 main()函数。所以，我们需要为这些 so 文件编写一个命令执行的入口，这方面也有超多的教程，过程就不深究了，同样这里也只记录一下编译步骤：

在你的 Android Studio 工程里新建一个目录，例如： jni/

将 ffmpeg repo 中的 ffmpeg.c、ffmpeg.h、FFmpegNativeHelper.c、cmdutils.c、ffmpeg_opt.c、ffmpeg_filter.c、show_func_wrapper.c 拷贝到 jni

编写 makefile:

编写 java 代码，声明 Java native method

修改 ffmpeg.c 文件，绑定 jni 方法名与 ffmpeg.c 的方法名

在 jni 目录下执行 ndk-build APP_ABI=armeabi

在 libs/armeabi 目录下得到 libffmpegjni.so

到这里，你已经拥有了可以动态 load 的 so 库，并且可以执行 ffmpeg command 了！

相信很多开发者对这个库都不会陌生FFmpegMediaMetadataRetriever，正如上面所说，原生的 MediaMetadataRetriever 不太好用，这个开源库被我们用来取预览帧：给出时间点，返回 bitmap。

然而，这个库引进来后，聪明的你应该发现了他也编译了一个 ffmpeg 放在了 aar 中，大小约为4MB。

其实，上面步骤走完后，你应该立即想到“可以直接复用已经编译好的 ffmpeg”，安装包立即节约4MB！

同样的这里也只记录步骤：

将 FFmpegMediaMetadataRetriever repo 下 FFmpegMediaMetadataRetriever/gradle/fmmr-library/library/src/main/jni/metadata 的 .c 、.h、.cpp 文件都拷贝到上述的 jni 文件夹中

打开上面章节我们编写的 makefile，添加如下代码：

重新执行 ndk-build APP_ABI=armeabi ，将在 libs/armeabi 下得到 lib ffmpeg_mediametadataretriever_jni.so

将 FFmpegMediaMetadataRetriever repo 中 的 Java 类FFmpegMediaMetadataRetriever.java拷贝到你的项目中，注意要改一下 so load 的过程：

到这里，你已经或得了可以运行的 FFmpegMediaMetadataRetriever，并且复用了用于视频编辑模块的 ffmpeg

如果你需要任何帮助，可以参考我的开源库zhoulujue/ffmpeg-commands-executor-library， fork 的 dxjia/ffmpeg-commands-executor-library 仓库。

自己完全控制 ffmpeg 有一个很大的好处，就是可以根据需求的变化来调整所引入的 ffmpeg codec 插件。 例如，需要增加对 gif 编辑的支持，只需要添加一个 encoder 和 decoder 就 OK 了。