关于FFmpeg生态的思考

LiveVideoStack和腾讯云音视频联合出品了《2024音视频技术发展报告》，其中一个调查是关于使用的多媒体处理框架：

答案选项有点匪夷所思，就不吐槽了。

虽然调查结果受参与者背景影响，具体数值可能和实际有偏差，FFmpeg占据首位基本没有什么疑问。抛开这个调查问题，我更想知道的是FFmpeg在不同领域的使用情况。

既然没有调研，我就信口开河，讲讲我的观察。我姑妄言之，读者姑妄听之。

1、PC端：FFmpeg开发者大本营

这里说的PC主要是Windows和Linux。和很多早期开源项目一样，FFmpeg开发者多数使用Linux环境，而Windows用户更多，所以Windows和Linux的开发支持力度最大。

macOS虽然也属于PC，但是显然不怎么受开发者待见，支持力度很小，一个功能break很长时间都没人发现。我个人因为办公环境使用macOS，所以顺便给它做一些支持。

PC时代，国内的一众视频播放和转码App都是在FFmpeg基础上做业务，并且保持不开源的传统。PC时代过去了，FFmpeg耻辱柱也成历史了。

2、云时代的音视频服务：都在靠FFmpeg吃饭

PC时代用FFmpeg做音视频相关的可能是首选，但不是必选，其他选项还有不少。而在云时代做音视频业务，基本绕不开FFmpeg。你可以不用它的流媒体传输，不用它的封装解封装，可以自己去封装第三方的编码器，但很难绕开FFmpeg的解码器。

j-b开玩笑说，Demuxed会议上，一半的演讲主题是“我们做了一个项目让FFmpeg更易用”。Ronald补充说，Demuxed另一半的主题是“我们做了一个点播服务”（把FFmpeg称为他们的技术栈）。


12:52 <j-b> jamrial: you are a hacker
12:52 <j-b> If you look at Demuxed
12:52 <j-b> half talks are "here is a project to make FFMpeg easy to use"
12:52 <j-b> :D
12:53 <jamrial> "we're going to explain filtergraphs. have your staff and grimmoire at hand"
12:54 <BBB> the other half is "we made a vod service" and their "stack" is ffmpeg

如果你不是刻意回避FFmpeg，FFmpeg的mux/demux、decoder/encoder、filter都是可以直接拿来做业务的。FFmpeg的IO部分比较弱，虽然实现的协议多，但拿来做服务有些勉强（简单场景还可以）。

另外一个趋势是，大家习惯了把自研的一些功能作为组件塞到FFmpeg里，用FFmpeg实现调用接口的统一。FFmpeg不支持插件化，往里面加东西时，不注意可能把FFmpeg改的面目全非，长期维护是个麻烦。

做音视频服务的，用FFmpeg多，贡献也多。特别是Intel，通过支持FFmpeg来支持它的服务器芯片业务（当然也有PC业务）。

3、移动端：用的多，贡献少

移动时代 + 短视频 + 直播，移动端大体量的App基本离不开FFmpeg，并且很多Android App里，会同时包含多个版本的FFmpeg（点播组件引入一个FFmpeg，视频剪辑组件引入一个FFmpeg）。

一些简单的快速成型的App，直接拿FFmpeg-Kit做功能。头部App性能优化比较好的情况，会更多的使用硬件编解码和GPU处理，拿FFmpeg做异常情况兜底逻辑。

Android和iOS都有自己的多媒体框架，理论上可以不用FFmpeg做音视频业务。实际情况是，总有地方离不开FFmpeg，或者像FFmpeg-Kit这种，通过FFmpeg命令行形式大大降低了音视频的门槛。

移动时代讲究快，快速做业务。我的观察是，FFmpeg在移动应用中用的非常多，但移动应用开发者对FFmpeg投入不多，深入研究的少，给FFmpeg贡献少。

移动应用开发者对FFmpeg贡献少，FFmpeg开发者对移动应用兴趣寥寥，形成一个有些割裂的局面。

一个例子是，FFmpeg里很长时间都没有Android硬件编码的封装。不断的有用户提这个需求，但是FFmpeg开发者谁也没兴趣去实现，而Android开发者又没有参与进来，主动贡献这个功能。当然，MediaCodec糟糕的设计，NDK MediaCodec残废的接口也是影响因素。

另一个现实是，虽然用的很多，FFmpeg在移动应用里已经是配角的角色了，哪怕是必不可少的配角。H.264软件解码可以，H.265软件解码功耗有点高，FFmpeg本身自H.264开始已经没有自带的软件编码了。

FFmpeg作为一个hub的功能，集成一堆第三方库封装的功能，可能慢慢超越它自己实现的功能了。

4、Web端：还能这么玩？

FFmpeg开发者自己也想不到，FFmpeg能运行在Web里（Chrome浏览器里内置的FFmpeg不算）。WebAssembly是个神奇的发明。

与WebAssembly相结合，我比较看好FFmpeg muxer/demuxer能力、音频编解码能力。我不看好拿FFmpeg做视频解码，虽然业内有很多实践，原因如下：

WebAssembly + FFmpeg解码H.265功耗太高
FFmpeg里的汇编优化没法用，重写汇编优化可以提高性能，但是投入成本高
并且，一旦浏览器决定从内部支持H.265，投入的开发成本浪费了。虽然在用户升级浏览器之前，FFmpeg解码方案仍然有价值，我个人是不愿花时间做这类即抛型开发工作
跳过H.265，直接使用AV1是更好的方案

5、嵌入式：严重碎片化

这里主要指嵌入式Linux环境。虽然FFmpeg支持BSD，估计嵌入式BSD系统加FFmpeg的应用场景微乎其微。

都说Android碎片化，至少Android是一个统一的系统（不管谁怎么改），有个统一的framework，而嵌入式天生的百花齐放。

嵌入式领域没有统一的硬件编解码API。虽然PC端也不统一，占主流的就那几个。嵌入式领域，芯片厂商各搞各的。

你可以说有一个标准openmax，各家基本都支持openmax。Android糟糕的mediacodec一部分原因来自openmax，如今Android也抛弃openmax了。openmax今天的地位，可能不如东周天子的地位。

如果要推选一个标准的话，我最看好V4L2作为统一的视频编解码标准接口。

再说FFmpeg和嵌入式音视频领域的关系。嵌入式领域FFmpeg用的也很多，但设备性能限制，FFmpeg视频软件编解码很难用上。各家芯片厂商维护自己私有编解码API，维护一个自己定制的FFmpeg，很少向FFmpeg提交自己的视频编解码支持。FFmpeg里现在有部分树莓派的支持，有瑞芯微解码支持（很久没更新了）。整体局面是，社区不怎么关心嵌入式，嵌入式领域很少参与FFmpeg社区。没动力参与，参与门槛高，社区不友好（经常被说的是，这个社区有毒☠️😂）等都是原因。

嵌入式领域不得不提下gsteamer。同属媒体框架，别的领域被FFmpeg压制，嵌入式领域不好说谁胜谁负。gstreamer的插件化模式，挺适合嵌入式碎片化的生态。各家厂商提供自己的gstreamer插件，可以宽松处理license问题。gstreamer对嵌入式领域的硬件编解码支持明显好于FFmpeg。gstreamer配置pipeline的使用方式，也比FFmpeg API更简单。

FFmpeg社区正在做RISC V的汇编优化，也算是嵌入式领域最大的进展。

6、结语

PC、云服务、移动端都是我工作的范围。工作之外，我更想了解FFmpeg支持不完善的领域，比如Web和嵌入式。

我不懂Web开发，想和Web开发者交流关于Web与音视频技术，看看FFmpeg里能做些什么。

嵌入式领域，FFmpeg支持openmax编码，不支持openmax解码，看openmax现状再补解码支持好像没多少必要了。V4L2值得去完善一下。

FFmpeg还有哪些不足，还有哪些新鲜东西值得做，欢迎来聊。

PS：今天看到一个libavfilter由文字插入二维码的patch，这种就是我说的“新鲜东西”。