FFmpeg 以 CLI 多线程支持落地其“数十年来最复杂的重构”

原文 ↗ Hacker News 讨论 ↗

FFmpeg 的命令行界面刚刚获得了端到端多线程支持，贡献者称这是其数十年来最复杂的重构之一，使媒体流水线的不同阶段（I/O、滤镜、编码）能够并行运行，而不再主要按顺序执行。评论者围绕这项改动在实践中何时、何地真正有用展开讨论，对比了大规模批量/云端编码与一次性或低延迟工作流，并指出许多单独的编解码器本来就已经是多线程的。这一变化也引发了更广泛的争论：并发重构到底有多难，LLM 等工具未来是否能自动化这类工作，以及 FFmpeg 与 VapourSynth 或 Netflix、YouTube 使用的自定义大规模编码栈相比如何。

AI、LLM 与代码重构

  • 线程中的很大一部分在讨论，未来的 LLM 是否能够像 ffmpeg 新的多线程 CLI 大改造这样，完成复杂重构。
  • 支持者认为：
    • 目前的 GPT-4 已经能对较小的重构提供帮助（例如，去重 React 组件、将串行脚本转换为并行形式）。
    • 主要限制在于上下文长度；随着窗口变大以及围绕测试的自动化增强，LLM 就能处理更大的代码库。
    • 重构是明确定义的（保持行为不变的转换），因此很适合自动化工具。
  • 怀疑者则认为：
    • LLM 缺乏真正的“理解”，在非平凡、定制化或高度并发的代码上表现吃力。
    • 它们常常生成看起来合理但实际错误的代码，尤其是在超出训练分布的情况下。
    • 复杂的并发重构和性能优化，需要比基于模式的清理更深层的语义与数学推理。
  • 也有人建议将 LLM 与现有工具结合使用（例如语义补丁系统），而不是完全依赖 LLM。

这次多线程改动到底是什么

  • 许多编解码器（如 H.264 等）本来就已经是多线程的；这次重构是把 ffmpeg 的 pipeline 本身并行化（读取、解码、过滤、编码、写入），从而让各个阶段能够并发运行。
  • 预期最大的收益来自复杂的 filter graph 和多输出场景；对于简单的单输入/单输出转码，收益则没那么大。
  • 线程里也有一些混淆，讨论这是否会影响特定编解码器（例如 MP3/LAME）；多条评论指出，许多老旧编解码器并不适合高效的多线程编码。

实用价值：云端 vs 个人用户

  • 一方观点是：像 Netflix/YouTube 这种大规模服务，已经通过运行大量 ffmpeg 进程来实现多核利用；在这种规模下，CLI 多线程会增加复杂度，但收益有限。
  • 另一方观点是：对于个人用户或运行少量并发任务的小型服务来说，更快的单个 ffmpeg 进程非常有价值（例如更快的一次性编码、CI 流水线、桌面流媒体）。

替代流水线与按块并行

  • 有人提到，使用 VapourSynth、gstreamer，以及 av1an 之类的工具，已经可以多年实现线程化或按场景/按块的并行处理。
  • 讨论还涉及按关键帧片段切分工作与帧内线程化之间的取舍：
    • 按块并行可以提升离线编码，在一些流水线中也在使用，但会增加直播/低延迟流媒体的延迟和复杂度。
    • 质量、延迟和 CPU 利用率之间的权衡被反复强调；对于“最佳”方案并没有明确共识。

项目流程与生态备注

  • 这次重构规模很大（数百个提交），并且是通过邮件列表式 patch 维护的，而不是现代 PR 工作流。
  • 有些人认为这很“老派”，但也接受这正是 ffmpeg 这类长寿项目的一部分。