用meson加速Windows系统FFmpeg构建

作者：quink
来源：Fun With FFmpeg
原文：https://mp.weixin.qq.com/s/O4W1YQRA_ULWHB6ujvuHPg

对FFmpeg编译构建问题的抱怨由来已久，比如某资深开发者说：

“为什么windows编译ffmpeg会如此麻烦？几十年了都无人解决？还是说大家觉得这不是个问题？这个问题对我相当不友好。我尝试过自己搞msvc版本的编译。后来真的搞不定，只能怪自己菜。问题在于，ffmpeg号称支持那么多的cpu，那么多的操作系统，但是为什么全球第一，使用人数遥遥领先的桌面操作系统，为什么这点都没做好？”

对于科学，也许提出问题比解决问题重要。对于工程，解决问题比提出问题重要。

说ffmpeg构建系统存在问题，可以分为三类：功能、性能和易用性。

从功能上来说，衡量标准是编译输出的target，当前构建系统支持的非常全面。用户编译不出来，并不是功能上不支持。

性能问题，是构建的速度。用户抱怨这一点的其实也不多。多数用户编译一遍放那里，不会天天从源码编译。性能问题，对ffmpeg开发者影响最大。

普通用户真正抱怨的是易用性。但ffmpeg不是个to c的app，对ffmpeg来说，构建系统的功能 > 性能 > 易用性。

当功能复杂到一定程度，易用性问题很难解决：哪怕是提供个visual studio工程，过多的可配置项也会让新手手足无措。易用性问题，可以通过学习、通过第三方项目来弥补。例如，linux发行版的包管理系统在几十年前已经解决了易用性问题。

真正亟待解决的是编译构建的性能问题。为什么编译FFmpeg那么麻烦？因为没有一个让人满意的构建系统，特别是20年前，所以FFmpeg 用shell script加makefile实现。windows下编译难度倒不大，但windows下的shell script速度太慢，configure过程耗时太长。编译windows版FFmpeg 有一堆方法，如在WSL 里用MSVC 编译，但各有各的缺点。

FFmpeg 支持的操作系统大概有十几个，cpu架构十几个，还有大量汇编代码，再加上上百个第三方库依赖，现有的C C++构建系统都吃力。autotools那套可能还不如ffmpeg现有的实现，有希望的两个构建系统是cmake和meson。很多人对cmake直摇头，让社区都接受cmake可能困难。

Google在Webrtc 里用FFmpeg ，是重写了FFmpeg 的构建的，但是完全不具备通用性。他们是用FFmpeg 的configure生成特定平台特定环境的头文件和配置文件，再把源码和配置加到他们自己的gn 构建里。其他的cmake和visual studio直接编译FFmpeg 的方案类似（不是指cmake的ExternalProject），都是半成品，用了现有构建的中间产物，达不到替代FFmpeg 现有configure+makefile的目标。

还有人提到vcpkg。vcpkg编译FFmpeg用的还是FFmpeg自己的构建系统，类似linux发行版，解决的是易用性问题，没有解决构建的性能问题。

现在有一个好消息，gstreamer做了一套ffmpeg的meson构建。

gstreamer原来是用autotools做构建，现在已经全部迁移到meson。除了gstreamer，几个常见的音视频项目也是用meson或支持menson构建：VLC、libvmaf、libplacebo、libdav1d等。我总结了一个趋势：偏向社区开源的倾向于用meson，偏向公司主导的开源项目倾向于用cmake，autotools彻底落伍了。

gstreamer为FFmpeg做meson构建，是为了方便gstreamer把FFmpeg作为第三方库集成进gstreamer：https://github.com/GStreamer/gstreamer/blob/main/subprojects/FFmpeg.wrap

gstreamer fork的FFmpeg仓库在https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg.git

关于meson就不详细介绍了。它的文档组织的很好：https://mesonbuild.com/

gstreamer之外，用meson构建FFmpeg最大的好处是提高了Windows平台的开发效率。其他平台上，特别是Linux下，因为shell script本身的速度非常快，meson的效率体现不出来（可能更慢）。

meson和cmake等类似，编译构建分两步：“configure”配置阶段和“make”编译阶段。编译阶段meson不支持makefile，只支持ninja。

我们来对比下meson和FFmpeg自己的configure/make在Windows上的速度。

1. meson配置ffmpeg的耗时

$ time meson setup \
  -Dprograms=enabled \
  -Dnonfree=enabled \
  meson-build
  
  ...
Found ninja-1.11.1 at D:\bin\msys\ucrt64\bin/ninja.EXE

real    1m2.820s
user    0m0.015s
sys     0m0.000s

耗时1分钟3秒。

2. ffmpeg configure脚本的耗时

$ time ../configure --toolchain=msvc --target-os=win64
real    5m33.280s
user    0m1.272s
sys     0m1.510s

耗时5分33秒。

这是configure成功的情况。如果configure失败，很可能是运行了3分钟4分钟之后失败，你检查检查第三方库、改改configure参数，再跑一次configure，4分钟后再失败——重复几次，半天过去了，这个过程很容易让人崩溃。

3. meson ninja编译ffmpeg的耗时

time ninja -C meson-build/
[2448/2448] Linking target ffmpeg.exe
real    1m48.944s
user    0m0.015s
sys     0m0.000s

1分钟49秒。

4. make编译ffmpeg的耗时

make -j20
real    6m19.520s
user    0m59.605s
sys     1m24.432s

6分钟20秒。

汇总如下：

可见，meson构建的速度是shell script + make的4倍多。

Linux下，shell script的configure只要10秒，还是在有大量第三方库存在的情况下（Windows测试环境几乎没有第三方库）。make编译1分钟。所以，如果是以学习为目的，或者做平台无关的工作，建议还是用Linux吧。

如果因各种原因只能用Windows的，比如做Windows的硬件解码和播放，meson构建ffmpeg不失为一个提升开发效率的选择。