FFmpeg 正式发布 9.0 版本，代号“Lei”。新版本继续推进音视频处理能力和硬件加速支持，但这个代号赋予了它更特别的意义：它用于纪念中国开发者雷霄骅（Lei Xiaohua）。对许多中文音视频开发者来说，他留下的技术文章、源码分析和学习资料，曾经是理解 FFmpeg 的重要入口。
“Lei”为什么值得被写进版本历史
FFmpeg 是一套规模庞大的开源多媒体框架。解封装、解码、滤镜、编码、封装等环节彼此衔接，源码中还包含时间基、像素格式、采样格式、线程模型和硬件设备等大量概念。仅靠 API 文档，初学者往往很难建立完整的处理链路。
雷霄骅所做的重要工作，是用中文文章拆解这些复杂模块。他不仅介绍命令如何使用，也通过源码分析解释数据如何在 FFmpeg 内部流动。这类内容降低了中文开发者进入音视频领域的门槛，也让更多人能够从“调用工具”继续走向“阅读实现”。
因此，“Lei”不只是一个容易识别的发布代号。它也记录了一种对开源社区很重要的贡献方式：编写代码能够推动项目，持续、准确地传播技术同样能够扩大项目的影响范围。
升级时应关注整条媒体链路
根据发布信息，FFmpeg 9.0 带来了新一代音视频处理能力，并继续加强硬件加速支持。实际升级时，不宜只确认 ffmpeg -version 是否输出了新版本号。更可靠的做法是检查构建选项、编解码器、滤镜和硬件设备是否符合生产环境要求。
同一个 FFmpeg 版本可能因为编译参数不同而具有完全不同的能力。例如，系统软件源、静态构建包和自行编译的二进制文件，可能启用不同的编码器与硬件后端。升级后二进制能够启动，并不代表原有转码任务一定可以无差别迁移。
可以这样检查当前安装：
ffmpeg -version
ffmpeg -buildconf
ffmpeg -decoders
ffmpeg -encoders
ffmpeg -filters
ffmpeg -hwaccels
其中，-buildconf 用于确认编译选项，-hwaccels 列出当前构建可识别的硬件加速方法。还应进一步检查业务依赖的具体编码器，例如：
ffmpeg -hide_banner -encoders | grep -E 'libx264|libx265|nvenc|qsv|vaapi|videotoolbox'
这条命令只负责发现能力，不表示列出的编码器都能立即使用。驱动、设备权限、运行时库以及实际硬件仍可能限制执行结果。
用一组可重复命令完成升级冒烟测试
在把 FFmpeg 9.0 放入生产任务之前，可以这样实践：生成一个不依赖外部素材的测试视频，再执行探测、转码和结果校验。下面的命令需要系统中存在 ffmpeg 和 ffprobe；若当前构建未包含 libx264，请把编码器替换为 ffmpeg -encoders 中实际可用的软件编码器。
set -euo pipefail
ffmpeg -hide_banner -y \
-f lavfi -i "testsrc2=size=1280x720:rate=30" \
-f lavfi -i "sine=frequency=1000:sample_rate=48000" \
-t 5 \
-c:v libx264 -pix_fmt yuv420p \
-c:a aac -b:a 128k \
input.mp4
ffprobe -v error \
-show_entries stream=index,codec_type,codec_name,width,height,pix_fmt,sample_rate \
-of json input.mp4
ffmpeg -hide_banner -y \
-i input.mp4 \
-vf "scale=854:480,fps=24" \
-c:v libx264 -preset medium -crf 23 \
-c:a aac -b:a 96k \
output.mp4
ffmpeg -v error -i output.mp4 -f null -
ffprobe -v error \
-show_entries format=duration,size:stream=codec_type,codec_name,width,height \
-of json output.mp4
这组测试覆盖了常见的软件处理路径：合成输入、音视频编码、缩放、帧率转换、封装、完整解码检查和元数据探测。ffmpeg -v error -i output.mp4 -f null - 不生成新文件，而是把输出完整解码到空设备，适合发现截断文件和部分解码错误。
硬件加速测试则必须依据机器环境调整。以 NVIDIA 编码器为例，可以先发现能力，再尝试最小任务：
ffmpeg -hide_banner -encoders | grep nvenc
ffmpeg -hide_banner -y \
-f lavfi -i "testsrc2=size=1280x720:rate=30" \
-t 5 \
-c:v h264_nvenc \
nvenc-test.mp4
这里假设 FFmpeg 构建包含 NVENC 支持，并且主机已经安装兼容驱动。其他平台应改用实际存在的编码器，例如 QSV、VAAPI 或 VideoToolbox。不要仅因为 -hwaccels 显示某个后端，就认定编码、解码和滤镜路径全部可用。
生产采用前的检查清单
升级 FFmpeg 的主要风险通常不在命令行参数本身，而在输入素材的复杂性。可变帧率、异常时间戳、字幕、旋转元数据、HDR、多个音轨和损坏的数据包，都可能让测试样例与真实业务产生明显差异。
生产采用前建议完成以下检查：
- 保存旧版与 9.0 的
-version、-buildconf、-encoders和-filters输出，进行能力对比。 - 使用真实素材集回归测试，不只依赖合成视频。
- 比较时长、帧数、音视频同步、像素格式、色彩信息和输出码率。
- 分别测试软件路径与硬件路径，记录驱动和运行时库版本。
- 保留旧二进制或容器镜像，使任务能够快速回滚。
- 对依赖 FFmpeg 库的程序重新编译并运行集成测试，避免把命令行兼容性等同于库 API 或 ABI 兼容性。
FFmpeg 9.0 值得关注的不只是性能与能力变化。“Lei”这个名字也提醒开发者：一个成熟的开源生态既需要实现复杂功能的人，也需要把复杂知识讲清楚、让后来者能够继续前进的人。对团队而言，最合适的纪念方式之一，就是延续这种严谨态度，用可复现的测试和清晰的文档完成每一次升级。