Jean-Baptiste Kempf 在自己的博客里写:FFmpeg 9.0 代号"Lei"已经发布。他给了一串扎眼的数字——距上一个版本8.1只隔了四个半月,却塞进了2200多次提交、160多位作者、改动1781个文件。七个核心库的主版本号全线跳升,这意味着一次彻底的ABI break。
这些数字都是真的。但翻一下FFmpeg官方仓库,会发现一件对不上的事:9.0目前只建了发布分支,ffmpeg.org上挂着的最新稳定版,仍然是6月17日发布的8.1.2。没有9.0的官方公告,没有安装包,连"Lei"这个代号都没能在官方渠道找到交叉印证。
这次改动确实"大"
抛开发布状态的争议,9.0要做的事情本身没有水分。
其中分量最重的是swscale重写。这个模块负责像素格式转换和缩放,老代码是二十年攒下的手写特例,谁改谁挠头。新架构把每次转换拆成一串"操作"——读取、色彩变换、缩放、打包,交给优化器化简,再编译成具体内核。同一套转换逻辑,现在既能编译成x86 SIMD、AArch64 NEON,也能编译成Vulkan SPIR-V计算着色器,CPU和GPU跑的是同一张图。
另一个十年老坑也被填上了:动画WebP解码。2015年开的4907号issue,过去十年被反复问"为什么FFmpeg只解出第一帧",这次由Ramiro Polla接手完成,RGB和YUV两套路径都比预期复杂。此外DAB+数字广播用到的960采样AAC帧、NVENC的AV1分层B帧、给Playdate掌机写的编码器,都是这次的增量。
时间线对不上的地方
问题出在"发布"这个词上。
分支建立、库版本号跳到libavcodec 63/libswscale 10,这些都能在仓库里核实。但"正式发布"通常意味着官网公告、tarball、变更日志定稿,这几样目前都还没出现。开发者博客说的"发布",更准确的说法是"这轮开发周期的代码已经封版"。
Vulkan的功能归属也被博客的叙事糊在了一起。原文把Vulkan SPIR-V后端、ProRes硬件加速这些描述成9.0周期"变得用户可见"的成果,但其中不少能力——比如swscale的Vulkan后端本体、ProRes Vulkan编码——其实是8.1就带来的。9.0真正新增的Vulkan条目,更准确地说是v360全景滤镜和APV硬件加速解码。同一套"CPU和GPU统一编译"的故事,被延续讲了两个版本。
- 提醒.新swscale架构目前仍挂在
SWS_UNSTABLE开关后面,不提供常规API/ABI稳定性保证,老架构才是默认路径。
这条限定很关键。它说明"架构已经就位"和"可以在生产环境放心用"是两回事。VLC这类下游播放器,不会在没有稳定性承诺的实验开关上赌身家性命。真正验证这次重写成没成,还得看它什么时候脱下UNSTABLE的帽子,成为默认后端。
对普通用户来说,这次升级最直接的感受可能就是动画WebP终于能完整播放——前提是过去十年靠拼接静态帧的临时方案,在alpha混合、循环次数、disposal处理这些细节上不会突然出现行为回归。对开发者和发行版维护者,七个库全线ABI break意味着重新编译是必修课,不是选修课。
代码定稿了,发布还没走完流程,这中间的空档才是这次最值得记的一笔。
开源基础设施的节奏经常这样:核心贡献者先在博客里把活儿讲清楚,官方发布走的是另一条更慢的流程,两者时间差不算新鲜事。但读者如果只看标题,很容易把"技术定稿"当成"可以下载安装"。接下来真正该盯的,不是这篇博客写得多详细,而是ffmpeg.org什么时候真正挂出9.0的tarball,以及swscale新架构什么时候敢摘掉SWS_UNSTABLE这顶帽子。