一次上传，六种交付
如今，一段原始素材需要变成一个 9:16 的垂直 Reels、一个 1:1 的方形剪辑、一个 16:9 的横向版本、一个用于自动播放的静音带字幕变体、一个带有品牌标志和片头/片尾的品牌剪辑，以及一个在网络连接较弱时能即时加载的压缩版本。相同的内容，六种或更多种形式——每天都在每个营销活动和每个创作者之间倍增。
要大规模解决这个问题，意味着视频必须通过编程方式转换，而不是手动编辑。这就是 FFmpeg 在我们的管道中扮演的角色。
为什么选择 FFmpeg
FFmpeg 是一个免费、开源的命令行工具，用于转换、过滤和编码音频和视频。它没有 UI —— 你只需将所需操作精确描述为一个命令，然后它就会执行。这就是其全部价值主张：一个命令可以通过代码生成，根据用户进行参数化，在管道中排队，并在无需人工干预的服务器上运行。视频编辑变成了一种编程，而不是手动点击操作。
以下三个特性使其非常适合解决这个具体问题，而不仅仅是“一个能用的视频工具”：
可组合滤镜。 FFmpeg 的滤镜图允许您将缩放 → 裁剪 → 叠加 → 淡入淡出操作串联成一个单一过程。这很重要，因为它避免了在每个步骤中写入中间文件——一个在每次操作之间重新编码的简单管道会成倍增加渲染时间和存储损耗。链式操作将多步转换保持在一个编码过程中。
流级别操作，而非仅仅重新编码。 对于剪辑等操作，FFmpeg 可以复制现有流，而不是对其进行解码和重新编码：
ffmpeg -i input.mp4 -ss 00:00:08 -t 15 -c copy highlight.mp4
-c copy 决定了剪辑操作是在几秒内完成，还是耗费与完整重新编码相同的时间。只要操作不涉及像素数据（如剪辑、格式重封装），我们就会使用它；而对于确实需要（如缩放或叠加）的步骤，则保留完整的重新编码。
硬件感知编码。 FFmpeg 可以通过 GPU 编码器（NVENC、QSV、VideoToolbox）进行路由，而不是仅限 CPU 的 libx264。GPU 编码在大批量数据下能提供更高的原始吞吐量；而 libx264 在给定比特率下仍能提供更可预测、可调的质量。选择哪种方案是一个真正的权衡，而非固定默认选项——我们倾向于对最注重质量控制的面向品牌内容使用 CPU 编码，并为大批量、低优先级的批处理保留 GPU 路径。
管道如何实际使用它
重构画面。
最常见的需求是“让它适应所有平台”。一个横向的源视频通过缩放和裁剪变成垂直 Reels。直接裁剪很快，但会丢弃部分画面——对于居中主体来说没问题，但当主体移出中心时则不适用。对于这些情况，我们采用模糊的全画幅背景，并在其前方放置一个正确缩放的前景副本，这样就不会有任何内容被剪裁掉：
ffmpeg -i input.mp4 -filter_complex \
"[0:v]scale=1080:1920,boxblur=20:5[bg]; \
[0:v]scale=1080:-2[fg]; \
[bg][fg]overlay=(W-w)/2:(H-h)/2" \
-c:a copy output_blurred.mp4
这是一个经过深思熟虑的双路径决策，而非单一的默认滤镜——在安全时裁剪，不安全时回退到模糊处理。
品牌化、字幕、音频。 标志、片头和片尾作为参数化叠加和连接应用，因此位置、大小和不透明度会根据品牌而变化，无需修改管道代码。字幕直接烧录到帧中，而不是作为单独的字幕轨道发送——自动播放静音的视频流意味着字幕必须在目标平台应用的任何重新编码中存活下来，而烧录字幕总是能做到；字幕轨道有时则不能。音频经过混音和响度归一化处理，这样在滚动视频流中，任何片段都不会比前一个片段突兀地更响。
交付。 每个输出都使用 +faststart 进行编码，这会将文件元数据移动到文件开头，以便在整个文件下载完成之前即可开始播放——这是一个小小的标志，但对短视频的感知加载时间却有着巨大的影响。
我们仍在研究的权衡
并非所有决策都已确定。GPU 与 CPU 编码是我们最常重新审视的问题：随着数据量的增长，GPU 的吞吐量很有吸引力，但对于品牌关键输出而言，每比特率的质量一致性仍倾向于 CPU 编码。目前，这种划分是按作业类型手动处理的；将其变为一个自动的、质量感知的路由决策是我们正在构建的管道的下一个部分。
为什么这很重要
总而言之，一次上传会触发一个管道，将其重构为垂直、方形和横向版本，进行品牌化，烧录字幕，剪辑成最精彩的片段，混音并归一化音频，并压缩以实现快速交付——所有这些都无需编辑人员打开时间轴。进一步扩展只需并行运行更多的 FFmpeg worker，因为每个作业都是独立且无状态的。
Reels 趋势不仅改变了内容的呈现方式——它还改变了单个内容必须采用的形态数量，而手动编辑的时间线无法匹配这种需求。FFmpeg 之所以能跟上，是因为它将视频视为可编程和可组合的，而不是必须手动点击操作的东西。这才是该管道能够扩展的真正原因：并非 FFmpeg 抽象地强大，而是其中每一个决策——裁剪 vs. 模糊回退，流复制 vs. 重新编码，GPU vs. CPU——都是根据具体情况有意识地做出，而非采用默认设置。
如果您正在构建类似的管道并希望对架构进行审阅，请联系我们。
