视频处理自动化：ffmpeg 命令工程、字幕生成、批量压缩的配方库 —— 横纵综合报告 未开始

题记与说明

• 报告日期：2026-10-29
• 报告性质：最终稿（已按独立审读意见逐条修订；初稿保留于 drafts/ 未改动）
• 综合来源：纵轴章节（发展史，2026-10-29 检索）+ 横轴章节（横向对比，2026-10-29 检索）
• 方法与口径说明：本报告综合上述两章，并消解其间的矛盾与重复。两章均声明基于当日实际检索撰写（纵轴含 7 个 GitHub 仓库 created_at 一手查询、15 次以上定向搜索；横轴含 11 组当日搜索）。FFmpeg 官方 Wiki（trac.ffmpeg.org）因 Anubis 反爬未能在纵轴章节直接读取正文，相关内容已标注"模型既有知识"。综合时新增一次核查：经 WebSearch 确认 FFmpeg 9.0 "Lei" 已于 2026-08-04 发布，据此修正横轴章节"当前主线为 8.0"的表述。全部矛盾消解记录见文末附注"两章口径校准"。
• 修订说明（2026-10-29，按 8 条独立审读意见逐条落实）：① TL;DR 由单段密排改为五要点，"三线合流"主语修正为"FFmpeg 8.0（whisper 滤镜 + Vulkan AV1 编码）"；② "成熟期相差二十余年"改为"起点相差二十余年"口径，并在 1.9 补四要素"到位"判定依据；③ 2.7 云转码"更便宜"改为对照档位表述并按引源原文校正 Mux/Coconut 计费结构，新增"省钱账"最小可复算算例（3.3 同步降格）；④ 2.9 压缩为三句话结论、3.3 为生态位唯一详述处、3.4 只留增量判断，删除跨节重复句；⑤ 新增 3.6 配方条目模板与最小示例（本机 FFmpeg 9.0.2 实跑验证）；⑥ 2.6 表拆为"质量/速度与成本/关键能力"三列，补 faster-whisper 与 WhisperX 关系、queue 参数注释；⑦ 2.5/3.2 的全称否定判断降格为"多轮检索未发现（不排除遗漏）"，"复杂度增长超过 LLM 记忆更新"改为作者判断句式。

TL;DR

• 纵轴结论：课题四要素——命令工程、字幕生成、批量压缩、配方库——起点相差二十余年（字幕 1999、命令工程 2000、压缩 2003、配方库 2014），而"同时到位"的窗口是 2025–2026 年。字幕从 SRT、云端 ASR 走到 Whisper 本地化，压缩从 HandBrake 走到自动寻优；2025 年 FFmpeg 8.0 以内置 whisper 滤镜（合流字幕线）与 Vulkan AV1 编码（合流压缩线），使三线首次在工具本体层汇合。
• 横轴结论：引擎层一超无对手，竞争在知识形态层——cheatsheet 多而散，多轮定向检索未发现带验证机制的权威单品（不排除遗漏），LLM 生成命令有公开幻觉实证。
• 生态位：配方库是"实跑验证、版本锚定、参数有依据"的可版本化知识资产——对 LLM 是幻觉的解药，对编排平台是兵工厂，对云服务是免费档（三重生态位详述见 3.3）。
• 建议：以验证锚定、机器可读、字幕三档决策树、省钱账四个动作差异化；配方以最小条目模板落地（模板与实跑示例见 3.6）。
• 风险：版本漂移（首要运维负担）、云价格行情、消费级下沉。

一、纵轴：发展脉络（1999–2026）

1.1 摘要式时间线

1.2 阶段一：前史——手工时代的字幕与转码（1999–2000）

在"配方库"这个概念出现之前，视频处理的两大痛点——格式转换与字幕——各自处在手工时代。1999 年，法国程序员 "Brain" 开始开发 SubRip，2000 年 3 月 3 日发布 0.5 beta；它用 OCR 从 DVD 上"撕"（rip）出图形字幕并转成纯文本，催生了 .srt 格式。SRT 因极简（序号 + 时间戳 + 文本）而被几乎所有播放器和剪辑工具支持，成为至今仍在使用的事实标准字幕格式（来源：Wikiwand: SubRip）。

驱动因素：DVD 盗录与汉化文化、早期 P2P 视频分享。这一阶段确立了本课题第一条暗线——*字幕是文本工程，视频是比特工程，两者需要一个结合点*。这个结合点直到 2012 年（subtitles 滤镜）和 2025 年（内置 whisper 滤镜）才被彻底打通。

1.3 阶段二：诞生——FFmpeg 与"一条命令"哲学（2000–2003）

2000 年 12 月 20 日，以多产著称的法国程序员 Fabrice Bellard（QEMU、TCC 作者，发布时化名 "Gérard Lantau"）发布了 FFmpeg 首版。名称取 "FF"（fast forward）+ MPEG，项目把解封装（libavformat）、解码/编码（libavcodec）、滤镜（libavfilter）与播放（ffplay）整合为一套库加一条命令行工具，从此 demux → filter → encode 全流程可以塞进一条 shell 命令——这就是后来一切"命令工程"与"配方"的起点（来源：Wikipedia: FFmpeg，纵轴章节全文读取）。

同期两条支线启动：2003 年 Laurent Aimar 在 VideoLAN 项目下创建开源 H.264 编码器 x264（其头文件版权行至今写作 "2003-2018 x264 project"，原始作者 Laurent Aimar，来源：x264.h on GitHub、VideoLAN 开发者页）；同年法国人 Eric Petit 开发 DVD 转码工具 HandBrake，成为此后二十余年图形化批量压缩的代表（来源：Wikiwand: HandBrake）。

驱动因素：Windows 桌面视频格式严重碎片化（AVI/MPG/WMV 各立山头），MPEG-4 编码需求爆发；欧洲开源社区（Bellard、VideoLAN 系）以个人工具起步。

1.4 阶段三：黄金时代——编码器、社区与下载器生态（2003–2011）

2004 年起，Michael Niedermayer 接替 Bellard 成为 FFmpeg 主维护者，此后掌舵约十一年（来源：Wikipedia: FFmpeg）。这一阶段的三件大事塑造了本课题的骨架：

1. x264 统一 H.264 编码：借助反复优化的 psych 视觉模型与 CRF/preset 参数体系，x264 成为全球使用最广的视频编码器，也把"CRF 值 + preset + 两遍编码"这套经验参数变成转码社区的通用配方语言（来源：VideoLAN 开发者页）。
2. 滤镜图立项：2008 年 Bobby Bingham 以 Google Summer of Code 项目启动 libavfilter，-vf/-filter_complex 链式语法在 2010 年前后成熟——FFmpeg 从"转换器"升级为"可编程视频流水线"（来源：Wikipedia: FFmpeg）。
3. 素材获取管线：2006 年 8 月 8 日 Ricardo Garcia Gonzalez 发布 youtube-dl，此后扩展到上千站点；它与 ffmpeg 的后处理（转码、合流、字幕嵌入）组合，构成个人视频自动化的获取端（来源：youtube-dl 官方 about 页、Reddit: History of youtube-dl）。

字幕侧，2009 年 11 月 19–20 日 Google 宣布 YouTube 机器自动字幕（基于与 Google Voice 同源的 ASR），2010 年 3 月 4 日推广至全部视频——云端 ASR 字幕第一次规模化，但准确率长期被人诟病（来源：Gizmodo 2009、Gizmodo 2010）。

驱动因素：在线视频爆发（WebM/VP8 于 2010 年 6 月进入 FFmpeg 0.6）、HTML5 与 Flash 的格式之争、多核 CPU 普及。

1.5 阶段四：成熟与危机——滤镜图、字幕烧录、分叉与复合（2011–2016）

• 字幕烧录进入命令行：2011 年 Baptiste Coudurier、Stefano Sabatini 写出 ass 滤镜，2012 年 Clément Bœsch 将其通用化为 subtitles 滤镜并进入 FFmpeg 1.1 更新日志（2012 年末），-vf subtitles=out.srt 从此一句话把字幕烧进画面（来源：vf_subtitles.c 文件历史、Super User: burn-in subtitles）。阶段一留下的"文本工程×比特工程"结合点，第一次有了官方命令形态。
• 社区分裂与复合：治理冲突于 2010 年底酝酿发酵，2011 年 3 月 13 日部分开发者正式分叉出 Libav；FFmpeg 侧长期执行"下游合并"策略吸收 Libav 改进。2015 年 7 月 Niedermayer 因身心透支与分裂压力辞职，随后 Libav 开发者陆续回归 FFmpeg；Libav 最后一个版本 12.3 停在 2017 年 10 月，Debian 早在 2015 年就回归 FFmpeg，项目于 2020 年被宣告放弃（来源：Wikipedia: FFmpeg、LWN 2011: FFmpeg 与 Libav 决裂、Softpedia: Debian 回归 FFmpeg、Reddit: Niedermayer 辞职、PyAV 放弃支持 libav 的 issue）。
• 硬编码登场：FFmpeg 2.6（2015-09）首次引入 NVIDIA NVENC 封装，3.0 "Einstein"（2016-02-15）以原生 h264_nvenc/hevc_nvenc 取代外部库方案（来源：Wikipedia: FFmpeg、CESBO: Use NVENC in FFmpeg）。
• HEVC 世代：2013 年 7 月 MulticoreWare 开源 x265；FFmpeg 2.2（2014-03-23）集成 libx265（来源：Phoronix: FFmpeg 2.2）。
• 配方库的标志性开源实践：2014 年 7 月 5 日，AMIA（音像档案工作者协会）开源社区创建 ffmprovisr——"面向档案工作者的实用 FFmpeg 命令仓库"，把口口相传的命令写成带解释的可复制配方（来源：GitHub API: amiaopensource/ffmprovisr，created_at=2014-07-05；仓库主页）。配方库出现在档案馆而非工程师社区，说明 ffmpeg 的"配方需求"已外溢出程序员群体。

驱动因素：1080p/4K 高清化使 CPU 软编吃紧，GPU 厂商推动硬件编码；项目治理理念冲突；档案行业数字化。

1.6 阶段五：硬件化与新编解码世代（2016–2022）

• AV1 三步走：AOMedia 联盟 2015 年成立后，Intel 与 Netflix 于 2018 年 10 月公布 SVT-AV1 并于 2019 年 2 月开源（来源：Tom's Hardware）。FFmpeg 4.1（2018-11）支持 AV1 封装、4.2（2019-08）支持解码、4.4（2021-04）支持 libsvtav1 编码与 AV1 VA-API 解码（来源：Wikipedia: FFmpeg）。
• 版本节奏：4.0（2018-04-20，API 清理 + 硬解大跃进）、5.0 "Lorentz"（2022-01-17，重大 API 变更）（来源：Phoronix: FFmpeg 5.0、Wikipedia: FFmpeg）。
• 批量压缩工程化：2020 年 1 月 7 日 Av1an 仓库创建——支持 AV1/VP9/HEVC/H264 的分场景质量编码框架；2022 年 1 月 27 日 ab-av1 仓库创建——用 ffmpeg+SVT-AV1+VMAF 自动搜索最优 CRF。"压缩配方"从社区口传的经验参数走向机器自动寻优（来源：GitHub API: master-of-zen/Av1an，created_at=2020-01-07；GitHub API: alexheretic/ab-av1，created_at=2022-01-27）。
• 素材端剧变：2020 年 10 月 RIAA 对 youtube-dl 发起 DMCA 下架，社区迅速以 yt-dlp（基于 youtube-dlc）分叉续命，ffmpeg+yt-dlp 成为个人下载-压制流水线的事实组合（来源：Data Horde、Wikipedia: Youtube-dl）。
• 配方库文化成型：官方 Wiki 的 Encode/H.264 等页面（CRF 18–28、preset 梯度、两遍编码等经典配方；注：该页因 Anubis 反爬未能直接读取，内容为模型既有知识）、steven2358 的 FFmpeg cheat sheet gist、transitive-bullshit/awesome-ffmpeg 精选清单、以及 ffmpeg.lav.io 交互式命令生成器，共同构成"配方库"的三种形态：官方教程、民间 gist、awesome 清单。

驱动因素：HEVC 专利池收费引发产业焦虑（AV1 免版税）；自建媒体库（Plex/Jellyfin）兴起放大了批量压缩需求；存储与带宽成本。

1.7 阶段六：AI 字幕革命——Whisper 与本地化 ASR（2022–2024）

2022 年 9 月 21 日，OpenAI 开源 Whisper（代码+权重，约 68 万小时弱监督音频训练），多语言识别准确率一举跨过实用门槛（来源：OpenAI: Whisper；确切开源日经多条搜索结果相互印证）。随后 26 个月内，字幕生成完成了从"云 API 拼接"到"本地推理"的换代：

• whisper.cpp：仓库创建于 2022-09-25——距 Whisper 开源仅 4 天（来源：GitHub API: ggerganov/whisper.cpp，created_at=2022-09-25），作者 Georgi Gerganov（ggml、llama.cpp 作者），2022 年 12 月发布首个正式版本，纵轴检索时已达 5.4 万 star，让无 GPU 机器也能本地生成 SRT（来源：whisper.cpp Releases、Discussion #279）。
• faster-whisper：仓库创建于 2023-02-11（来源：GitHub API: SYSTRAN/faster-whisper，created_at=2023-02-11），SYSTRAN 的 Guillaume Klein 基于 CTranslate2 实现约 4 倍提速与 INT8 量化（该数字为仓库 README 自述，未在本地复测）；模型侧 large-v2（2022-12）、large-v3（2023-11）相继发布。
• 流水线整合：早期明星 autosub（2015-06-29 建仓，调 Google Speech API，GitHub API，现已停止维护）被新一代工具取代；2023 年 10 月 2 日创建的 pyvideotrans（纵轴检索时已 1.96 万 star）把 ffmpeg 抽音轨 + Whisper 识别 + 翻译 + subtitles 滤镜硬字幕烧录串成全自动流水线，是中文世界"ffmpeg×Whisper"整合的代表（来源：GitHub API: jianchang512/pyvideotrans，created_at=2023-10-02）。

驱动因素：Transformer 自监督 ASR 成熟；本地化/隐私需求；消费级显存增长与 GGML 量化技术（whisper.cpp 与 llama.cpp 同源共享）。此阶段本课题三条线中的两条——命令工程与字幕生成——首次大规模在应用层合流：ffmpeg 负责抽轨/封装/烧录，Whisper 负责生成 SRT。

1.8 阶段七：融合与当代形态（2024–2026）

• FFmpeg 7.0 "Dijkstra"（2024-04-05）：实验性原生 VVC（H.266）解码、线程架构重构（来源：LWN: FFmpeg 7.0 released、Phoronix）；7.1 "Péter"（2024-09-30）VVC 稳定化并加入 Vulkan 硬编（来源：Linux Today）。
• FFmpeg 8.0 "Huffman"（2025-08-22）：官方称迄今最大更新，因基础设施现代化而延期发布。核心事件：whisper 音频滤镜（af_whisper）合入——commit 13ce36fef9 于 2025 年 8 月 13 日前后合并，基于 whisper.cpp，FFmpeg 本体从此可以一条命令完成"音频→转录→SRT"（来源：daily.dev: FFmpeg 8 can subtitle your videos on the fly with Whisper、daily.dev: whisper 滤镜 commit 报道、ffmpeg-devel 补丁文档、Phoronix: FFmpeg 8.0 Released、Linuxiac、LWN 公告）；同期加入 AV1 Vulkan 编码、APV/ProRes RAW/RealVideo 6.0 解码等，并扩展 Vulkan Video 硬件路径。此前 2018 年 1 月 ffserver 被移除、此后 ffplay/CLI 的现代化清理，标志项目进入基础设施重构期（来源：Wikipedia: FFmpeg）。
• FFmpeg 9.0 "Lei"（2026-08-04 发布，9.0.2 于 2026-09-18）：首次以中国开发者命名大版本——纪念 2016 年英年早逝的流媒体教育者雷霄骅（"雷神"），命名由中国开发者 Liu Qi 于 2026 年 3 月在社区邮件列表提议（发布日为本次综合会话 WebSearch 核实，CSDN 报道一、CSDN 报道二、nixCraft；命名动机来自 SegmentFault、搜狐新闻；9.0.2 日期来自 Wikipedia: FFmpeg）。截至本报告日（2026-10-29），主线版本为 9.0 "Lei"；8.0 仍是 whisper 滤镜这一关键能力的引入版本。
• LLM 时代的命令工程：自然语言→ffmpeg 命令的生成工具批量出现（如 AI-FFmpeg-CLI 聚合页、用编码 LLM 现场推导 ffmpeg 命令的工作流（Medium: You can use coding LLMs to figure out FFMPEG commands）、交互式命令生成器 ffmpeg.lav.io）。配方库形态随之从"人抄命令"进入 "AI 起草 → 人审核 → 库沉淀" 的新循环——这正是本课题（"配方库"作为工程实践）所处的当代坐标。

驱动因素：FFmpeg 获得资金与组织化支持后的基础设施现代化；大模型能力外溢到传统 CLI 领域；8.0/9.0 连续两个大版本把 AI 与 Vulkan 硬件能力内化进工具本体。

1.9 贯通性结论：三条线、一次合流

• 命令工程：2000 年"一条命令"→ 2008 年滤镜图成为可编程流水线 → 2016 年硬件参数体系 → 2025 年 AI 滤镜与 Vulkan 计算。
• 字幕生成：2000 年 SRT 格式确立 → 2009 年云端 ASR → 2015 年 API 包装脚本（autosub）→ 2022–2023 年本地大模型（Whisper/whisper.cpp/faster-whisper）→ 2025 年内化进 FFmpeg 本体（af_whisper）。
• 批量压缩：2003 年图形化工具（HandBrake）→ 2010 年代 CRF/preset 经验配方（x264/x265）→ 2020 年代自动寻优（Av1an、ab-av1）与免版税新编码（AV1/SVT-AV1）。

三条线索各自独立演进逾二十年，在 2025 年 8 月 22 日 FFmpeg 8.0 "Huffman" 上第一次于工具本体层面汇合——字幕线由内置 whisper 滤镜（af_whisper）完成汇合，压缩线由同期加入的 Vulkan AV1 编码器完成（命令线即本体自身）；而"配方库"这一实践形态，则沿着 ffmprovisr（2014，档案馆员）→ 官方 Wiki/awesome 清单/cheat sheet（2010 年代）→ LLM 命令生成与个人配方库（2023–2026）的轨迹，从口传经验演化为可版本化、可被 AI 调用的工程资产。本课题的定位恰好落在这条 26 年演进弧线的交汇点上：ffmpeg 命令工程（本体）+ 字幕生成（AI）+ 批量压缩（硬件与寻优）+ 配方库（知识管理）——四要素齐备的时机，是 2025–2026 年，而非更早。

四要素"到位"的判定依据（本报告口径）：命令工程以 2008 年 libavfilter 滤镜图为成熟标志——命令从此成为可编程流水线；字幕生成以 2022 年 Whisper 开源为成熟标志——本地大模型识别质量越过实用门槛；批量压缩以 2020–2022 年 Av1an/ab-av1 自动寻优为成熟标志——口传经验配方被程序化；配方库以 2014 年 ffmprovisr 为起点，以 2025–2026 年"实跑验证 + 版本锚定"形态（本报告第三章所主张）为成形标志。据此口径，四要素起点相差二十余年（1999–2014），而同时到位的窗口是 2025–2026 年。

二、横轴：横向对比（2026-10-29 截面）

2.1 研究对象的定性：三层能力 + 一种知识组织形态

课题《视频处理自动化：ffmpeg 命令工程、字幕生成、批量压缩的配方库》可拆解为三层能力 + 一种知识组织形态：

1. ffmpeg 命令工程：转码、封装、滤镜链、硬件加速（QSV/NVENC/Vulkan）等命令行的参数设计与组合；
2. 字幕生成：语音识别（ASR）→ SRT/ASS 字幕 → 压制烧录或外挂的完整链路；
3. 批量压缩：目录级/媒体库级的自动化转码——CRF/码率策略、并发与失败处理、硬件编码调度；
4. 配方库形态：这是本课题的定性关键——它的产出物不是一款软件，而是"经过验证、可版本化、带参数依据注释"的知识资产（脚本 + 说明 + 适用条件）。

这个定性决定了横向对比的对象分两类：功能重叠的工具类竞品（它们替用户完成了配方要做的事），以及形态重叠的知识类竞品（cheatsheet 仓库、awesome 列表、LLM 生成的命令）。

2.2 六层生态地图

2.3 核心对比总表

2.4 引擎层：一超无对手，押注正确且无引擎风险

FFmpeg 当前主线版本为 9.0 "Lei"（2026-08-04 发布，9.0.2 维护版 2026-09-18）；上一个里程碑 8.0 "Huffman"（2025-08-22） 是近年最重要的大版本：新增 APV、ProRes RAW、RealVideo 6.0 等原生解码器，扩展 Vulkan Video 硬件路径（含 Vulkan AV1 编码器），并且合入了 OpenAI Whisper 语音识别滤镜（来源：Phoronix: FFmpeg 8.0 Released、Linuxiac、LWN 公告、官网、CSDN: FFmpeg 9.0 发布报道）。这意味着课题的两条主线（命令工程、字幕生成）在引擎层出现了历史性交汇：一条 ffmpeg 命令可以同时完成转码与出字幕。

引擎层的两个"替代品"均不构成威胁：

• libav 是 FFmpeg 2010–2011 年决裂事件的分支（决裂始于 2010 年底，2011-03-13 正式分叉），最后一个版本 12.3 停在 2017 年 10 月，Debian 早在 2015 年就回归 FFmpeg，项目如今实质弃更（LWN 2011、Softpedia、PyAV 放弃支持 issue）。
• GStreamer 是管线框架而非 CLI 工具，社区共识是"GStreamer 适合动态流应用与嵌入式，FFmpeg 适合命令行转码与编码库调用"（r/gstreamer 讨论、StackShare 对比、NETINT 播客）。

结论：配方库的引擎选型不存在争议空间；唯一要管理的是 FFmpeg 命令行为随版本漂移的问题——每条配方应锚定验证时的 FFmpeg 版本。

2.5 命令工程层：真正的竞品是 LLM，而 LLM 恰好暴露了配方库的价值

"怎么写出正确的 ffmpeg 命令"这个问题的答案，2026 年的供给格局是三股：

1. 静态 cheatsheet/awesome 仓库：如 rendi-api/ffmpeg-cheatsheet（54 条带解释的命令）、fastily/cheatsheet 的 ffmpeg 页、krzemienski/awesome-video 的 ffmpeg 板块（约 78 条资源）、awesome.wansal.co 的 FFmpeg 清单。多轮定向检索（横轴当日 11 组搜索）未发现一个公认权威、持续验证、带版本锚定的"awesome-ffmpeg"单品（不排除遗漏）——若该空位属实，它正是课题的卡位点。（最早的 curated 仓库 ffmprovisr 虽创建于 2014 年，但面向档案场景、不以版本锚定的持续验证为机制，故该检索结论仍成立，见附注校准第 4 条。）
2. 代码封装库：Python 侧 ffmpeg-python 是最流行的命令图构建器（适合复杂滤镜链，但仍是薄封装，用户必须懂 ffmpeg）；MoviePy 更偏剪辑但把帧读进 Python 处理，速度显著慢于直跑 ffmpeg（封装库横评、r/moviepy 讨论）；Node 侧 fluent-ffmpeg 在 serverless 环境有二进制打包痛点（对比文）。它们是"程序内嵌视频能力"的答案，不是"人的配方库"的答案。
3. LLM 直接生成命令：这是 2025 年后的默认入口，但可靠性有公开实证缺陷——2025 年 8 月，一个 AI 生成的网页工具 "FFmpegs" 因多处 ffmpeg 命令错误被公开批驳（BigGo News 报道）；Hacker News 上有实测记录：把真实报错喂给模型后，LLM 反而"越来越激进"地编造不存在的 flag（HN #44520855）；连 LLM 转 ffmpeg 的工具 wtffmpeg 都在 README 层面要求用户先审查再运行；从业者给出的工程化缓解方案是"用提示词把模型锁死在真实 flag 集合内"（dbreunig：Building an Easier to Use FFmpeg With LLMs，幻觉机理另见 OpenAI 论文页）。

结论（本报告最重要的一条）：ffmpeg 是 LLM 幻觉的重灾区——flag 空间巨大、版本相关、顺序敏感。一个"每条配方都实跑验证过、注明 FFmpeg 版本与操作系统、解释每个参数为什么这么写"的配方库，恰好是 LLM 缺口的镜像解药。课题的时代红利不在"替代 LLM"，而在"成为 LLM 可引用、可执行、不会幻觉的语料"——建议把配方同时做成对 LLM 友好的机器可读形态（如 skill/规则文件），让 AI 助手调用配方而非自由发挥。

2.6 字幕生成层：内置 Whisper 改写游戏规则，但不是质量上限

2026-10 截面上，"视频出字幕"有五条路线（列义说明：质量为转写准确性与时间轴质量的定性分档；速度与成本只谈推理速度与计费；关键能力为影响选型的差异化能力）：

faster-whisper 与 WhisperX 的关系及分档理由：WhisperX 自 v3 起默认以 faster-whisper 为转写后端（来源：WhisperX README，"Using batched whisper with faster-whisper backend"），因此两者速度与成本同量级，WhisperX 的额外开销在 wav2vec2 对齐与 pyannote 分离两步。质量分档（faster-whisper"中高"、WhisperX"高"）的依据是能力构成而非基准测试：词级时间戳精度直接决定字幕时间轴质量，WhisperX 凭强制对齐 + 说话人分离在字幕场景定高一档——此分档为作者定性判断，非跑分结论。

结论：内置滤镜把"转码时顺带出字幕"变成了配方库里的一条命令，这是只有 FFmpeg 配方库能讲的故事；但按"质量-速度-成本"三档（内置滤镜 → faster-whisper/WhisperX → 云 API）给决策树式配方，是纯工具竞品（HandBrake、剪映）都提供不了的深度。

2.7 批量压缩层：从手写脚本到编排平台是一条光谱，配方库与它们互补而非互斥

• 手写脚本（课题默认形态）：零依赖、可版本化、精确可控，代价是要自己处理并发、失败重试与幂等。
• HandBrake：GUI 转码之王，当前版本 1.11.2（2026 年），1.11.0 约 2026 年 2 月发布，1.10 系新增 Social 10MB 预设并重构了 Intel QSV 路径（官方发布讨论 #7912、handbrake.fr 新闻页）。其 CLI（HandBrakeCLI）可批量，但 presets 封装与 ffmpeg filter 复杂度不可同日而语。
• Tdarr / FileFlows / Unmanic：媒体库级自动化编排三强。2026 年社区舆情可概括为：Tdarr 功能最全（流程图、分布式节点、库分析）但复杂且偶有重复转码/容器内性能问题；FileFlows 用户口碑上升，流程编辑器最友好；Unmanic 最简单、适合"一键全转"（r/selfhosted 对比帖、r/unRAID 对比帖）。它们消费的"流里的节点"本质仍是 ffmpeg/HandBrake 命令——配方库与它们是供给关系而非竞争关系（生态位详述见 3.3）。
• 云转码（参照系）：AWS MediaConvert 按输出分钟计费（每档 rendition 单独计费，编解码器/画质模式乘数叠乘），常规 SD/HD 约 \$0.0075–0.015/分钟，高画质档 4K 可达约 \$0.672/分钟，量大有最高约 19% 的阶梯折扣（Spendark 云视频成本分析、Forasoft 编码 API 对比、G-Cloud 服务定义文档）。社区长期批评其比裸 H.264 编码贵 7–10 倍（r/aws 讨论）。计费更简单的一口价替代是 Coconut 与 Mux：Coconut 按输出分钟以分辨率扁平计价（SD \$0.0075、HD \$0.015、UHD \$0.030，无编解码器乘数），Mux 按输入分钟计费（成本不随 rendition 数放大，Plus 档 720p 约 \$0.025/分钟起）（Transcodely 2026-03 横评）；更激进的省钱路径是 spot 实例自托管 ffmpeg（有讨论称可便宜约 50 倍）（HN 讨论）。注意对照档位：一口价对 MediaConvert 的 SD 低价档（\$0.0075 起）并不便宜，其优势在计费可预期，以及多 rendition ABR 阶梯、高乘数档（HEVC/AV1）场景的总价。

省钱账（最小可复算算例，按本文 2026-10 行情估算；1 美元≈7.2 元；自建侧成本按既有 PC 的电费 + 硬件折旧每年数百至一两千元估算）：

• HD 场景：每周重转码 20 小时（1,200 输出分钟）→ 年 62,400 分钟 × \$0.015 ≈ \$936 ≈ ¥6,700，减自建成本后年省约 ¥5,000–6,000；
• HD 重度场景：每周 30 小时（1,800 输出分钟）→ 年 93,600 分钟 × \$0.015 ≈ \$1,404 ≈ ¥10,100，减自建成本后年省约 ¥8,000–9,500，接近万元级；
• 4K 场景：每周仅 2 小时（120 输出分钟）→ 年 6,240 分钟 × \$0.672 ≈ \$4,193 ≈ ¥30,200，减自建成本后年省约 ¥28,000–29,500。

结论："一年省万元"仅对重度用量（HD 每周约 30 小时以上）或 4K 高画质档成立（用量依赖的估算结论）；轻度用户（每周数小时 SD 档）年省仅数百至数千元。这是配方库最有说服力的商业论据——且账目可直接按用户自己的用量复算（3.5 第 4 条的建议即把该算例参数化成表）。

2.8 消费级警戒线与相邻工具

剪映/CapCut、Descript 类工具把"字幕 + 压缩 + 剪辑"打包成零门槛体验，会持续吞噬轻量需求。但它们封闭、不可脚本化、输出与格式受平台约束，与"可版本化、可集成进任意流水线的命令配方"是两个物种。警戒线在于：当任务足够轻（一条短视频出字幕），用户永远不会需要配方库——课题的目标用户应明确定义为"有批量、可重复、可集成需求的人"。

顺带锚定一个相邻工具：yt-dlp（视频获取，常为流水线第一环）稳定版 2026.08.19，更新活跃（GitHub issue 引用的版本 API、发布页），可作为配方库"获取→处理→压制"全链路的外围成员——其前身 youtube-dl 的 2006 年起点与 2020 年 DMCA 危机见纵轴第 1.4/1.6 节。

2.9 横向结论：课题的生态位

1. 引擎层零风险：FFmpeg 一超（libav 已死、GStreamer 错位），且 8.0 的内置 whisper 滤镜（字幕线）与 Vulkan AV1 编码器（压缩线）使课题主线在引擎层合一——这是 2025-08 之前不存在的结构性机会。
2. 知识形态层竞争分散：多轮定向检索未发现带验证机制的权威单品（不排除遗漏），LLM 入口有公开实证的幻觉缺陷；课题应卡位"验证过 + 版本锚定 + 参数依据"三件套，形成差异化。
3. 与工具竞品全部互补：云 ASR 与云转码是"付费档"，本地配方是"免费档"，编排平台消费配方——三重生态位（对 LLM、对编排平台、对云服务）的完整论证见 3.3，此处不再展开。

三、交叉洞察：两轴结合说明了什么

3.1 洞察一：时间轴解释了横轴格局——越上层的生态越不稳定

把两轴叠起来看，横轴的"六层生态地图"其实不是一张静态设计图，而是一条沉积地层：底层引擎沉积了 26 年（2000 至今），配方文化沉积了 12 年（2014 ffmprovisr 至今），AI 字幕沉积了 4 年（2022 Whisper 至今），LLM 命令入口只有 1–2 年（2024–2025 起）。沉积时间与稳定性正相关：引擎层（FFmpeg/libav/GStreamer 的座次）多年不变，知识形态层（cheatsheet、LLM 工具）则年年洗牌——LLM 工具 2025-08 就出现公开翻车，云价格随行就市，而 SRT 格式从 2000 年用到今天。

对配方库的直接推论：把不确定性封装在上层，把稳定性沉淀在下层——配方锚定的是 FFmpeg 版本与命令行为（稳定地层），而不是某个 LLM 工具或云服务的当期价格（流沙层）。若"未发现权威验证单品"的检索结论属实，这也与其长期无人填补相容：验证机制需要持续投入，而 cheatsheet 形态的维护者天然倾向一次性堆砌。

3.2 洞察二：三条演进规律，各自指向一个配方库设计决策

1. 命令工程线的规律是"复杂度只增不减"：flag 空间从 2000 年的一条命令，膨胀到 2008 年的滤镜图、2016 年的硬件参数体系、2025 年的 AI 滤镜与 Vulkan 计算路径，且正确性越来越依赖版本与构建选项（内置 whisper 滤镜需要 --enable-whisper 构建 + ggml 模型，缺一不可）。→ 设计决策一：每条配方必须"版本锚定 + 实跑验证 + 构建前提说明"。横轴找到的 LLM 公开翻车案例（FFmpegs 工具多处命令错误、HN 上 LLM 越错越编）正是这条规律的对立面教材。可以推断的观察是（作者判断，无量化证据）：ffmpeg 的复杂度持续增长，而 LLM 记忆中的命令知识更新滞后。
2. 字幕线的规律是"从云到本地再到本体"：2009 云端 ASR → 2015 云 API 包装 → 2022 本地大模型 → 2025 内化进 FFmpeg。迁移方向明确，但没有哪条路线在所有维度胜出——内置滤镜零成本但质量中等，WhisperX 质量最高，云 API 免 GPU。→ 设计决策二：字幕章节按"质量-速度-成本"三档给决策树配方（内置滤镜 → faster-whisper/WhisperX → 云 API），不押注单一路线。这条决策树是纯工具竞品给不出的深度，也是纵轴 26 年字幕史的直接结晶。
3. 压缩线的规律是"经验配方终将被自动寻优吸收"：x264 时代的 CRF/preset 口传配方，到 2020 年代被 Av1an/ab-av1 的"VMAF 自动搜 CRF"程序化。→ 设计决策三：配方库要吸收寻优思想（把"跑一遍 VMAF 搜最优 CRF"本身写成配方），同时认清自己的位置：配方库与编排平台是供给关系而非竞争关系（三重生态位见 3.3）。

3.3 洞察三：配方库的三重生态位——镜像解药、兵工厂、免费档

• 对 LLM，它是镜像解药：LLM 能起草但不能保证正确（幻觉重灾区），配方库保证正确但需要检索与维护。两者不是替代关系——配方库的终局形态是"LLM 可引用的语料"：做成机器可读的 skill/规则文件后，AI 助手调用配方而非发明命令，"AI 起草 → 人审核 → 库沉淀"的纵轴终点循环才能闭合。护城河只有一个词：验证。
• 对编排平台，它是兵工厂：Tdarr/FileFlows/Unmanic 消费的"流里的节点"本质仍是 ffmpeg 命令；HandBrake 的预设就是封装好的配方。配方越规范、越带参数依据，越容易被这些平台直接引用。
• 对云服务，它是免费档与议价筹码：MediaConvert 比自建贵 7–10 倍、4K 档可达 \$0.672/输出分钟的账，是配方库最有说服力的商业论据——一份可靠的硬件编码配方（NVENC/Vulkan AV1 路径），对重度用量或 4K 高画质用户，一年省下的云转码费可达万元级（估算；最小算例与成立条件见 2.7"省钱账"）。

3.4 对用户的判断

1. 值得做，且窗口就是现在：纵轴证明四要素（本体命令工程、AI 字幕、硬件寻优、知识形态）直到 2025–2026 才同时齐备；横轴的多轮定向检索未发现权威验证单品（不排除遗漏），而 LLM 幻觉有公开实证。2025-08 之前做这个课题，字幕与命令两条线在本体层还是分离的；现在做，配方库可以直接建立在"一条命令完成转码+字幕"的新地基上。
2. 引擎零风险，版本漂移是首要运维负担：押注 FFmpeg 不存在选型争议，但 8.0/9.0 连续两个大版本意味着命令行为与新滤镜参数仍在演进，配方的"保质期"管理要成为库的一等公民（失效检测、版本重验）。

（竞争格局与三重生态位不再在此重复，见 3.3；唯需强调的增量是：护城河只有一个词——验证。）

3.5 建议的差异化动作（按优先级）

1. 验证锚定：每条配方注明验证环境（FFmpeg 版本/OS/GPU/构建选项）并附实跑输出；库内建立版本重验机制（条目模板与实跑示例见 3.6）。
2. 机器可读形态：为 LLM 消费场景提供 skill/规则文件式输出，让 AI 助手"引用配方"而非"发明命令"。
3. 字幕三档决策树：按"质量-速度-成本"给出内置滤镜 → faster-whisper/WhisperX → 云 API 的选择路径，并注明内置滤镜的 --enable-whisper 构建前提。
4. 省钱账：压缩章节给出与 MediaConvert 计费对照的量化对比，把"配方库省了多少钱"写成可复算的表（2.7 已给出最小算例，按用户实际用量参数化即可）。
5. 节点化封装（综合两轴的补充建议）：把配方粒度对齐编排平台"流里的节点"（单输入→单输出的幂等转码单元），便于被 Tdarr/FileFlows 直接采纳，也天然适配批量场景的失败重试。

3.6 配方条目模板与最小示例（"验证锚定"主张的兑现）

本报告的核心主张是"实跑验证、参数有依据"的配方，因此必须先回答"配方长什么样"。最小条目模板五字段：适用环境（FFmpeg 版本/OS/构建选项）→ 完整命令 → 逐参数依据 → 实跑输出摘要 → 失效重验条件。以下条目于 2026-10-29 在本报告撰写所在机器（Windows 10 x64，FFmpeg 9.0.2 "Lei"，gyan.dev full build，构建配置含 --enable-whisper）实际执行验证，非示意：

配方：一条命令完成"音频→SRT 转录"（内置 whisper 滤镜）

• 适用环境：FFmpeg ≥ 8.0（滤镜 2025-08 合入，本条在 9.0.2 验证）；Windows 10 x64；构建需含 --enable-whisper（gyan.dev full build 默认包含）；另需 whisper.cpp ggml 模型文件（本例 ggml-tiny.bin，约 74 MB，取自 HuggingFace ggerganov/whisper.cpp 仓库，经 hf-mirror.com 下载）。
• 完整命令：

  ffmpeg -hide_banner -y -i input.wav -af "whisper=model=ggml-tiny.bin:language=en:destination=out.srt:format=srt:use_gpu=false" -f null -

• 逐参数依据：model=——whisper.cpp 模型路径，滤镜唯一必填项（缺省直接报错 "No whisper model path specified"）；language=en——显式指定识别语言，避免 auto 检测在短音频上误判；destination=out.srt + format=srt——转写结果落盘为 SRT（滤镜另支持 text/json 输出）；use_gpu=false——无 N 卡或驱动不稳时的稳妥档（默认 true）；-f null -——滤镜会旁路输出音频流，转写结果已由 destination 落盘，故正式输出丢弃；-y——允许覆盖输出；-hide_banner——抑制横幅噪声，便于留存输出摘要。
• 实跑输出摘要（2026-10-29 本机）：8.03 秒 TTS 语音（英文两句），tiny 模型纯 CPU 推理约 1.1 秒（speed≈7.3x），生成 3 段 SRT：第一段逐字正确（"The quick brown fox jumps over the lazy dog."），后两段对原文 "Verified recipes beat hallucinated commands" 的识别出现偏差（"verified recipe speed." / "associated commands."）——tiny 档仅够草稿级，正式字幕应上更大模型档或改走 faster-whisper/WhisperX 路线，恰好印证 2.6 的质量分档。
• 失效重验条件：FFmpeg 大版本升级（滤镜参数或默认行为变更——重跑本命令比对 SRT 输出即完成重验）；whisper.cpp 模型文件格式变更（模型加载报错即失效）；换用非 --enable-whisper 构建时整条命令不可用（报 Unknown filter），退化路径为外挂 faster-whisper（见 3.7 风险清单"构建门槛"条）。

同一模板也适用于压缩线配方：本会话同机另实跑了一条 libx264 压缩命令（testsrc2 3 秒 640×360 测试源，-preset medium -crf 23，实跑输出摘要含 kb/s:794.12），五个字段同理填写。建议把该模板直接作为配方库的入库 schema，与 3.5 第 1 条"验证锚定"一一对应。

3.7 风险清单

• 版本漂移：8.0 的新滤镜参数仍在演进，配方可能随 9.x 更新失效；
• 云价格行情：报告中云 ASR/云转码价格均为 2026-10 检索行情（部分未逐条打开官网定价页核验），引用前以官网为准；
• 消费级下沉：剪映/CapCut 类工具持续吞噬轻量需求，收窄配方库的潜在用户盘面——对策是把目标用户明确锚定在"批量、可重复、可集成"场景；
• 构建门槛：内置 whisper 滤镜需 --enable-whisper 构建与 ggml 模型下载，普通用户可能因此绕开它，配方库应注明预编译获取途径或退化路径（外挂 faster-whisper）。

附注：两章口径校准（矛盾与重复的消解记录）

1. 当前主线版本（横轴称 8.0 vs 纵轴记录 9.0 已发布）：本次综合会话以 WebSearch 核实，FFmpeg 9.0 "Lei" 已于 2026-08-04 发布（CSDN、nixCraft），9.0.2 于 2026-09-18（纵轴引 Wikipedia）。统一口径：截至 2026-10-29 主线为 9.0 "Lei"；8.0（2025-08-22）是 whisper 滤镜的引入版本。横轴"当前主线 8.0"表述据此修正。
2. Libav 分叉时间（横轴"2010–2011 决裂" vs 纵轴"2011-03-13 分叉"）：统一表述为"决裂始于 2010 年底治理冲突，2011-03-13 正式分叉"，两说兼容。
3. Libav 现状（纵轴"2020 年宣告放弃" vs 横轴"最后版本 12.3 停在 2017-10，实质弃更"）：合并为"最后发版 12.3（2017-10），Debian 2015 年回归 FFmpeg，项目 2020 年宣告放弃"。
4. ffmprovisr 与"无权威单品"：纵轴记录 ffmprovisr（2014-07-05 建仓）为配方库实践起点；横轴多轮定向检索未发现"公认权威、持续验证、带版本锚定"的单品（不排除遗漏，非全称否定）。两者不矛盾——ffmprovisr 面向档案场景、不以版本锚定持续验证为机制，该检索结论在其口径下仍成立。
5. faster-whisper "约 4 倍提速"：两章均转述该数字，来源为仓库 README 自述，未在本地复测，报告中保留此限制声明。
6. star 数时效：whisper.cpp 5.4 万、pyvideotrans 1.96 万 star 为纵轴会话当日 GitHub API 查询值，随时间变动。
7. 重复内容合并：FFmpeg 8.0 whisper 滤镜在两章中各叙述一遍，本报告在纵轴记其历史（commit/合入时间），在横轴记其能力边界（构建前提、参数、竞品位）；HandBrake 纵轴记起源（2003）、横轴记现状（1.11.2）；yt-dlp 纵轴记历史（youtube-dl 2006 → DMCA 2020）、横轴记现状（稳定版 2026.08.19）。
8. Mux/Coconut 计费口径（初稿"更便宜的替代 Mux/Coconut 约 \$0.015/分钟"的修正）：据初稿所引 Transcodely 横评原文核对，\$0.015 为 Coconut 的 HD 档单价，Mux 实为按输入分钟计费（Plus 档 720p 约 \$0.025/分钟起）；初稿将两家合并为一个单价并称"更便宜"，与同段 MediaConvert SD 档 \$0.0075 起的价格矛盾（独立审读意见指出）。最终稿改为分列两家计费结构，并以"对照档位"表述替代"更便宜"。
9. 三线合流的表述口径：初稿多处将"三线在 8.0 本体层合流"单独归因于 whisper 滤镜，压缩线的合流点实为同期加入的 Vulkan AV1 编码器。最终稿统一为"FFmpeg 8.0（whisper 滤镜 + Vulkan AV1 编码）使三线首次在工具本体层汇合"。

参考来源

引擎与版本史

• Wikipedia: FFmpeg — https://en.wikipedia.org/wiki/FFmpeg （纵轴会话全文读取；版本史、人物、AV1/NVENC 时间线）
• FFmpeg 官网 — https://www.ffmpeg.org ；下载页 https://ffmpeg.org/download.html
• Phoronix: FFmpeg 2.2 — https://www.phoronix.com/news/MTcxNDM ；FFmpeg 5.0 — https://www.phoronix.com/news/MTI5MTk ；FFmpeg 8.0 — https://www.phoronix.com/news/FFmpeg-8.0-Released ；FFmpeg 7.0 — https://www.phoronix.com/news/FFmpeg-7.0-Released
• LWN: FFmpeg 7.0 released — https://lwn.net/Articles/968565 ；FFmpeg 8.0 公告 — https://lwn.net/Articles/1034813
• Linux Today: FFmpeg 7.1 "Péter" — https://www.linuxtoday.com/blog/ffmpeg-7-1-peter-released-with-full-native-vvc-decoder-mv-hevc-decoder-and-more
• LWN 2011: FFmpeg 与 Libav 决裂 — https://lwn.net/Articles/433503 ；Softpedia: Debian 回归 FFmpeg — https://news.softpedia.com/news/Debian-Moves-to-FFmpeg-and-Drops-Libav-484793.shtml ；PyAV 放弃支持 libav — https://github.com/PyAV-Org/PyAV/issues/110
• SegmentFault: FFmpeg 9.0 "Lei" — https://segmentfault.com/a/1190000048123288 ；搜狐 — https://m.sohu.com/a/1059293672_121124377/
• Reddit: Niedermayer 辞职 — https://www.reddit.com/r/programming/comments/3fdsgw/ffmpeg_team_lead_michael_niedermayer_resigns/
• CESBO: Use NVENC in FFmpeg — https://senta.cesbo.com/en/articles/nvenc

命令工程与配方库生态

• ffmprovisr — https://github.com/amiaopensource/ffmprovisr ；GitHub API — https://api.github.com/repos/amiaopensource/ffmprovisr
• steven2358 FFmpeg cheat sheet — https://gist.github.com/steven2358/ba153c642fe2bb1e47485962df07c730 ；awesome-ffmpeg — https://github.com/transitive-bullshit/awesome-ffmpeg ；ffmpeg.lav.io — https://ffmpeg.lav.io/
• rendi-api/ffmpeg-cheatsheet — https://github.com/rendi-api/ffmpeg-cheatsheet ；fastily/cheatsheet ffmpeg 页 — https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md ；awesome-video ffmpeg 板块 — https://awesome.video/tag/ffmpeg ；awesome.wansal.co — https://awesome.wansal.co/media--ffmpeg
• ffmpeg-python — https://github.com/kkroening/ffmpeg-python ；封装库横评 — https://json2video.com/how-to/ffmpeg-course/ffmpeg-wrappers.html ；r/moviepy — https://www.reddit.com/r/moviepy/comments/t1sm6k/is_using_just_ffmpeg_be_faster_than_moviepy ；fluent-ffmpeg 痛点 — https://www.ffmpeg-micro.com/blog/fluent-ffmpeg-vs-ffmpeg-micro-cloud-api
• BigGo News: AI 生成 FFmpeg 工具含命令错误 — https://finance.biggo.com/news/202508300123_AI-Generated_FFmpeg_Tool_Contains_Command_Errors ；HN #44520855 — https://news.ycombinator.com/item?id=44520855 ；wtffmpeg — https://github.com/scottvr/wtffmpeg ；dbreunig — https://www.dbreunig.com/2025/02/24/building-an-easier-to-use-ffmpeg-with-llm.html ；OpenAI: Why Language Models Hallucinate — https://openai.com/index/why-language-models-hallucinate ；Medium: 用 LLM 推导 ffmpeg 命令 — https://fleker.medium.com/you-can-use-coding-llms-to-figure-out-ffmpeg-commands-9046dba15c87 ；AI-FFmpeg-CLI 聚合页 — https://www.jiasugongju.com/video/250547

字幕生成

• OpenAI: Whisper — https://openai.com/index/whisper/
• whisper.cpp — https://github.com/ggml-org/whisper.cpp/releases ；https://github.com/ggml-org/whisper.cpp/discussions/279 ；GitHub API — https://api.github.com/repos/ggerganov/whisper.cpp
• faster-whisper GitHub API — https://api.github.com/repos/SYSTRAN/faster-whisper ；autosub GitHub API — https://api.github.com/repos/agermanidis/autosub ；pyvideotrans GitHub API — https://api.github.com/repos/jianchang512/pyvideotrans
• WhisperX README（v3 起以 faster-whisper 为后端；"约 70 倍实时"为 README 自述）— https://github.com/m-bain/whisperX
• ffmpeg-devel: whisper 滤镜补丁文档 — https://ffmpeg.org/pipermail/ffmpeg-devel/2025-July/346864.html ；BigGo: FFmpeg Whisper 集成 — https://finance.biggo.com/news/202508131913_FFmpeg_Whisper_Integration ；r/linux 讨论 — https://www.reddit.com/r/linux/comments/1mp7zkx/ffmpeg_80_merges_openai_whisper_filter_for
• daily.dev: FFmpeg 8 whisper 滤镜 — https://daily.dev/posts/ffmpeg-8-can-subtitle-your-videos-on-the-fly-with-whisper-rer7g6xgj ；commit 报道 — https://daily.dev/posts/libavfilter-whisper-audio-filter-13ce36fef9-eyjtnxdqf
• WhisperX/faster-whisper 对比讨论 — https://github.com/m-bain/whisperX/discussions/1354
• 云 ASR 定价：OpenAI 官方 — https://platform.openai.com/docs/guides/speech-to-text （Groq/Deepgram/AssemblyAI 为 2026-10 检索行情，以官网为准）
• YouTube 自动字幕：Gizmodo 2009 — https://gizmodo.com/google-adding-automatic-captions-to-youtube-videos-5409282 ；Gizmodo 2010 — https://gizmodo.com/youtube-gets-automatic-captioning-for-all-videos-5485777
• 字幕烧录：vf_subtitles.c 历史 — https://github.com/FFmpeg/FFmpeg/commits/master/libavfilter/vf_subtitles.c ；Super User — https://superuser.com/questions/831094/how-can-i-burn-in-subtitles-to-a-file-using-ffmpeg
• 剪映教程：百度经验 — https://jingyan.baidu.com/article/76a7e409a97d01bd3a6e1515.html ；PC6 — http://www.pc6.com/video/13125.html ；CapCut 会员化反馈 — https://www.facebook.com/fb-answers/capcut-auto-captions-effects/?locale=zh_CN

批量压缩与云转码

• x264 — https://www.videolan.org/developers/x264.html ；https://github.com/PlatformLab/x264/blob/master/x264.h
• Wikiwand: SubRip — https://www.wikiwand.com/en/SubRip ；Wikiwand: HandBrake — https://www.wikiwand.com/en/HandBrake
• SVT-AV1 — https://www.tomshardware.com/news/intel-svt-av1-open-source-encoder,38551.html
• Av1an GitHub API — https://api.github.com/repos/master-of-zen/Av1an ；ab-av1 GitHub API — https://api.github.com/repos/alexheretic/ab-av1
• HandBrake 发布讨论 #7912 — https://github.com/HandBrake/HandBrake/discussions/7912 ；新闻页 — https://handbrake.fr/news.php
• Tdarr/FileFlows/Unmanic 对比：r/selfhosted — https://www.reddit.com/r/selfhosted/comments/1jqr1g4/fileflows_vs_tdarr_vs_unmanic/ ；r/unRAID — https://www.reddit.com/r/unRAID/comments/1fyvshd/unmanic_vs_tdarr_quality_wise/
• 云转码成本：Spendark — https://spendark.com/blog/video-streaming-cloud-cost ；Forasoft — https://www.forasoft.com/blog/article/video-encoding-api-comparison ；G-Cloud 服务定义 PDF — https://assets.applytosupply.digitalmarketplace.service.gov.uk/g-cloud-15/documents/92331/766812041517888-service-definition-document-2026-01-22-1504.pdf ；r/aws — https://www.reddit.com/r/aws/comments/rzdgzx/can_someone_explain_to_me_why_mediaconvert_is_so ；HN #46473479 — https://news.ycombinator.com/item?id=46473479 ；Transcodely 横评（含 Mux 按输入分钟计费、Coconut 分辨率分档单价明细）— https://www.transcodely.com/blog/video-transcoding-pricing-compared

素材获取与引擎对比

• youtube-dl — https://ytdl-org.github.io/youtube-dl/about.html ；Wikipedia — https://en.wikipedia.org/wiki/Youtube-dl ；Data Horde（DMCA）— https://datahorde.org/the-riaa-issues-youtube-dl-a-dmca-takedown ；Reddit 史料 — https://www.reddit.com/r/youtubedl/wiki/history
• yt-dlp — https://github.com/yt-dlp/yt-dlp/releases/latest ；版本引用 issue — https://github.com/yt-dlp/yt-dlp/issues/17538
• GStreamer vs FFmpeg：r/gstreamer — https://www.reddit.com/r/gstreamer/comments/1g8cuf0/gstreamer_vs_ffmpeg ；StackShare — https://stackshare.io/stackups/ffmpeg-vs-gstreamer ；NETINT 播客 — https://netint.com/research/podcast/the-benefits-and-limitations-of-ffmpeg-gstreamer-gpac

本次综合会话新增核查（2026-10-29 WebSearch）

• CSDN: FFmpeg 9.0 正式发布，代号 "Lei" — https://blog.csdn.net/jianlu365/article/details/163511222
• CSDN: FFmpeg 9.0 "Lei"：十年之后，以你之名 — https://blog.csdn.net/yanceyxin/article/details/163505725
• nixCraft（Mastodon）：FFmpeg 9.0 "Lei" 发布 — https://mastodon.social/@nixCraft/117037109804903859
• 知乎动态 — https://www.zhihu.com/pin/2068106389323617687

本次修订会话新增实跑核查（2026-10-29，本机 Windows 10）

• 本机 FFmpeg 9.0.2 "Lei"（gyan.dev full build，构建含 --enable-whisper）：执行 whisper 滤镜端到端转录一次（TTS 语音 → SRT，tiny 模型 CPU 推理）与 libx264 压缩一次（testsrc2 3 秒，kb/s:794.12），输出摘要见 3.6；
• ffmpeg -h filter=whisper 输出的滤镜参数全表（model/language/queue/vad_model 等，queue 默认 3 秒），用于 2.6 表的参数注释；
• whisper.cpp ggml-tiny 模型（77,691,713 字节）经 https://hf-mirror.com/ggerganov/whisper.cpp 下载。

未能在两章会话中直接验证、如实声明的事项

• FFmpeg 官方 Wiki（trac.ffmpeg.org/wiki/Encode/H.264）因 Anubis 反爬未能读取正文；CRF 18–28、preset 梯度等经典配方内容为模型既有知识，URL 仅供延伸阅读。
• Whisper 确切开源日（2022-09-21）来自多条搜索结果相互印证，未直接抓取 OpenAI 原始公告页。
• 云 ASR 的 Groq/Deepgram/AssemblyAI 单价来自当日搜索聚合行情，未逐条核验官网定价页；OpenAI \$0.006/分钟一档有官方文档链接可查。
• FFmpeg 9.0 "Lei" 命名动机与提议人细节来自中文科技媒体报道（SegmentFault/搜狐），未核对社区邮件列表原始帖子；发布日期（2026-08-04）为本次综合会话 WebSearch 核实。
• Mux"按输入分钟计费、Plus 档 720p 约 \$0.025/分钟起"与 Coconut 分档单价来自 Transcodely 横评（初稿已引此源），未逐条打开 Mux/Coconut 官网定价页核验。
• 2.6 表中 faster-whisper/WhisperX 的"中高/高"质量分档为作者依据能力构成所作的定性判断，非基准测试结论；WhisperX"约 70 倍实时"为其 README 自述，未复测。
• 3.6 配方示例的实跑环境为本机 Windows 10 / FFmpeg 9.0.2 / CPU 推理 / tiny 模型；其他环境（Linux/macOS、GPU 推理、更大模型档位）未复测，配方入库时应按模板重填适用环境与输出摘要。