Canva + ffmpeg 实验短片制作：从素材管理到音画对齐的工程化流程

1. 从一条朋友圈说起Buzz 实验片到底卡在哪先交代背景。Buzz 是我和 Hermes 攒的一个实验短片项目体量不大成片目标三分钟左右但要求看起来不像业余作品。Hermes 负责视觉和分镜我负责工程侧——页面排版、素材管理、切镜、录音对齐、最终合成。听起来分工清晰实际做起来真正耗时间的从来不是拍或者画而是素材在多个工具之间来回搬运时产生的信息损耗。我们最初的方案很朴素Canva 做分镜页和字幕卡导出 PNG 序列然后用 ffmpeg 切镜、拼接、对齐录音。这个链路本身没问题问题出在对齐两个字上。Buzz 的音频不是一次性录完的是分段录的每段之间有呼吸、有停顿、有重录。而画面是按分镜切好的固定时长片段。两者一叠加就会出现画面到了但声音还没到或者声音说完了画面还停着的尴尬。我一开始以为这是剪辑软件能自动解决的问题试了两轮之后发现自动对齐在短片段、多停顿的场景下误判率很高尤其是当录音里有明显的环境底噪时波形检测会把底噪当成语音起点。于是整个项目就变成了一个很具体的工程问题如何用 Canva 管好页面资产用 ffmpeg 做可控的切镜和音频对齐并且让这套流程可复现、可回滚。这篇东西就是把这套流程完整拆开讲。适合谁看如果你也在做小体量的实验短片、课程视频、产品演示手上有 Canva 和 ffmpeg不想被重型剪辑软件绑死那这篇基本可以直接抄作业。如果你只是想了解 ffmpeg 在真实项目里怎么用而不是停留在ffmpeg -i input.mp4 output.mp4这种层面那也有不少能拿走的东西。关键词里出现了 Hermes、Buzz、Canva、ffmpeg、GitHub 这几个词我理解这个项目的核心就是围绕这几样东西展开的。Hermes 在这个项目里既是协作者也是我们内部对智能体辅助流程的一个代称——它帮我们做了一部分分镜文案和素材命名规范的建议。Canva 是页面资产的唯一真源ffmpeg 是后端的处理引擎GitHub 用来做版本管理和流程脚本的托管。下面按实际做下来的顺序讲。2. Canva 当页面真源为什么不用它做剪辑但必须用它管资产2.1 页面资产和视频时间线是两套坐标系很多人做视频的第一反应是能不能在一个工具里全干完。Canva 确实有视频编辑能力但它的强项是页面级设计——排版、字体、配色、图形组合。它的时间线模型是面向演示的不是面向帧精确的。Buzz 里有大量字幕卡和图形页这些页面的设计迭代非常频繁今天改个配色明天调个字距。如果这些页面直接进剪辑时间线每次改设计都要重新导出、重新对齐成本极高。所以我们定了一个原则Canva 只负责页面的最终视觉状态不参与时间线。每个页面在 Canva 里是一个独立设计导出为固定尺寸的 PNG。时间线上的所有时长、转场、音频对齐全部在 ffmpeg 侧完成。这样设计迭代和剪辑迭代解耦改页面不影响时间线结构改时间线也不用回 Canva。这个原则听起来简单但执行时有个坑Canva 导出的 PNG 默认是带透明通道的如果你在 ffmpeg 里直接拼接透明区域会变成黑色或者白色取决于你的像素格式设置。我踩过一次整段字幕卡背景全黑排查了半小时才发现是 alpha 通道的问题。2.2 导出规范尺寸、命名、序列号Canva 导出这一步必须定死规范否则后面 ffmpeg 处理时会非常痛苦。我们最终用的规范是这样的尺寸统一为 1920x1080即使某些页面设计时是竖版也在 Canva 里用画布居中加背景的方式统一成横版。原因是 ffmpeg 拼接不同尺寸的输入需要额外做 scale 和 pad容易引入黑边和比例失真。命名格式为buzz_场景号_镜号_版本号.png例如buzz_s02_c05_v03.png。场景号和镜号用两位数字版本号用两位数字。这个命名直接决定了后面切镜脚本能不能自动化。导出时关闭压缩选项Canva 的压缩会引入可见的色带尤其是渐变背景。文件大一点无所谓后面 ffmpeg 编码时会重新压。每个页面单独导出不要用导出全部。Canva 的批量导出顺序是按图层顺序不是按你想要的叙事顺序而且批量导出的文件名不可控。这里有个经验Canva 的导出队列有时候会卡住尤其是页面多的时候。我的做法是分批导出每批不超过 10 页导完一批检查一批。检查的方法不是肉眼看而是用identify或者ffprobe批量读尺寸和通道数确认没有异常。# 批量检查导出 PNG 的尺寸和通道 for f in buzz_*.png; do ffprobe -v error -select_streams v:0 -show_entries streamwidth,height,pix_fmt -of csvp0 $f done如果输出里出现rgba而不是rgb24说明这个文件带 alpha 通道后面拼接时要特别处理。2.3 版本管理为什么把 PNG 放进 GitHub页面资产是二进制文件放 GitHub 不是最优雅的方案但对我们这种小团队来说是最省事的。原因有三个第一Hermes 和我不在同一个物理位置需要一个共享的真源第二Canva 的历史版本功能有限改错了想回滚很麻烦第三我们需要一个当前使用版本的明确标记避免用错版本的页面。具体做法是在仓库里建一个assets/pages/目录每个页面按命名规范放进去。同时在仓库根目录维护一个manifest.csv记录每个页面当前使用的版本号、对应的场景镜号、以及备注。ffmpeg 脚本读这个 manifest 来决定用哪些文件、按什么顺序拼。scene,shot,file,version,note s02,c05,buzz_s02_c05_v03.png,v03,字幕卡-开场 s02,c06,buzz_s02_c06_v01.png,v01,图形页-过渡 s03,c01,buzz_s03_c01_v02.png,v02,字幕卡-核心观点这个 manifest 是整个流程的枢纽。改页面版本时只改 manifest 里的文件名不动脚本。这样脚本是稳定的资产是可替换的。提示PNG 文件放 GitHub 要注意仓库体积。我们的做法是只保留当前版本和上一个版本更早的版本打 tag 后从主分支移除。如果仓库超过 1GB克隆会变得很慢。3. ffmpeg 切镜从 PNG 序列到带时长的视频片段3.1 为什么不用 concat demuxer 直接拼新手最容易想到的方案是把所有 PNG 写进一个文本文件用 concat demuxer 拼成一个视频。这个方案在每张图时长相同时能用但 Buzz 里每个镜头的时长是不一样的有的字幕卡停 2 秒有的图形页只停 0.8 秒。concat demuxer 对每张图的时长控制很弱需要靠duration指令而且和音频对齐时非常不灵活。我最终用的是逐片段生成 concat filter的方案。每个镜头单独生成一个带精确时长的视频片段然后再把这些片段拼起来。这样做的好处是每个片段的时长、帧率、像素格式都可以独立控制出问题时也容易定位是哪个片段的问题。单个片段的生成命令大概是这样ffmpeg -loop 1 -i buzz_s02_c05_v03.png \ -t 2.0 -r 30 -pix_fmt yuv420p \ -vf scale1920:1080:force_original_aspect_ratiodecrease,pad1920:1080:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -preset medium -crf 18 \ buzz_s02_c05_v03.mp4这里有几个参数值得说清楚-loop 1让静态图变成视频流不加这个参数 ffmpeg 只会生成一帧。-t 2.0是时长单位秒。这个值来自 manifest 里的时长列我建议把时长也写进 manifest而不是硬编码在脚本里。-r 30是帧率。Buzz 用 30fps因为大部分素材是 30fps 录的统一帧率避免后面拼接时做帧率转换。-pix_fmt yuv420p是输出像素格式。这个必须显式指定否则 libx264 可能输出 yuv444p在某些播放器上会显示异常。scale和pad的组合是为了处理非 1920x1080 的输入保证输出尺寸严格一致。force_original_aspect_ratiodecrease保证不拉伸pad补黑边。3.2 时长从哪来录音驱动的反向计算Buzz 的镜头时长不是拍脑袋定的是从录音反推的。流程是这样的先录好每一段的音频用 ffmpeg 的silencedetect找出每段语音的起止点算出每段的有效时长然后给每个镜头分配时长。ffmpeg -i take_s02.wav -af silencedetectnoise-35dB:d0.3 -f null -这个命令会输出类似这样的日志[silencedetect 0x...] silence_start: 0 [silencedetect 0x...] silence_end: 0.42 | silence_duration: 0.42 [silencedetect 0x...] silence_start: 2.31 [silencedetect 0x...] silence_end: 2.68 | silence_duration: 0.37noise-35dB是静音阈值d0.3是最短静音时长。这两个参数需要根据实际录音调整。我们的录音环境底噪大概在 -45dB 左右所以 -35dB 能有效区分语音和底噪。如果底噪更高比如 -30dB那阈值要相应提高到 -25dB 左右否则会把底噪当成语音。从这些起止点算出每段语音的时长后给每个镜头分配时长时留 10% 到 15% 的余量避免语音和画面切换卡得太死。比如一段语音有效时长 1.8 秒对应镜头给 2.0 秒。3.3 拼接concat filter 的正确用法片段生成完之后拼接用 concat filter。这里有个常见错误是直接用 concat demuxer 拼 mp4如果片段的编码参数不完全一致会出现音画不同步或者花屏。concat filter 更稳因为它是在解码后重新编码。ffmpeg -i seg01.mp4 -i seg02.mp4 -i seg03.mp4 \ -filter_complex [0:v][1:v][2:v]concatn3:v1:a0[outv] \ -map [outv] -c:v libx264 -preset medium -crf 18 -pix_fmt yuv420p \ buzz_visual.mp4concatn3:v1:a0里的n是输入片段数v1表示输出视频流a0表示不输出音频流。因为我们这一步只拼画面音频后面单独处理。如果片段数量多命令行会很长。我的做法是写一个 Python 脚本读 manifest动态生成 ffmpeg 命令。这样加镜头、改顺序都只改 manifest。import csv import subprocess segments [] with open(manifest.csv) as f: for row in csv.DictReader(f): segments.append(row[file].replace(.png, .mp4)) inputs [] for seg in segments: inputs.extend([-i, seg]) filter_inputs .join(f[{i}:v] for i in range(len(segments))) filter_complex f{filter_inputs}concatn{len(segments)}:v1:a0[outv] cmd [ffmpeg] inputs [ -filter_complex, filter_complex, -map, [outv], -c:v, libx264, -preset, medium, -crf, 18, -pix_fmt, yuv420p, buzz_visual.mp4 ] subprocess.run(cmd, checkTrue)这个脚本是整个流程里最值得复用的部分。它把哪些片段、什么顺序这件事完全交给 manifest脚本本身不需要改。4. 录音对齐比切镜更磨人的那一半4.1 为什么自动对齐在 Buzz 里不靠谱前面提到过自动对齐在多停顿、有底噪的场景下误判率高。具体表现是波形检测把呼吸声当成语音起点导致画面提前切换或者把两个短句之间的停顿当成段落结束导致画面停留过久。Buzz 的录音里有大量嗯那个之类的填充词这些在波形上和正常语音没有明显区别自动工具很难区分。所以我们的方案是半自动用 silencedetect 找出候选切点人工确认后再生成对齐参数。人工确认这一步不能省但可以做得很快——把候选切点标在波形图上肉眼扫一遍改几个明显不对的就行。4.2 用 ffmpeg 做精确的音频切片和位移确认好切点后用 ffmpeg 把音频切成对应的段每段和对应的视频片段对齐。这里的关键是用样本级精度控制切点而不是用秒级。# 从 2.31 秒处切持续 1.8 秒 ffmpeg -i take_s02.wav -ss 2.31 -t 1.8 -c copy seg_s02_c05.wav-ss放在-i前面是输入定位速度快但精度受关键帧影响放在后面是输出定位精度高但慢。对于 wav 这种无关键帧的格式两种方式精度都够。我习惯放在前面因为快。切完之后如果某段音频比对应视频短需要补静音如果长需要裁掉尾部。补静音用apadffmpeg -i seg_s02_c05.wav -af apadwhole_dur2.0 -t 2.0 seg_s02_c05_padded.wavapadwhole_dur2.0表示把音频补到总长 2.0 秒-t 2.0再裁一次确保不超。这两个参数配合使用能保证输出音频时长严格等于视频时长。4.3 音画合并-shortest 的陷阱音画合并最常用的命令是ffmpeg -i buzz_visual.mp4 -i buzz_audio.wav \ -c:v copy -c:a aac -b:a 192k -shortest buzz_final.mp4-shortest表示以较短的流为准。这个参数在音视频时长完全一致时没问题但如果音频比视频长一点点比如 0.05 秒-shortest会把视频尾部裁掉导致最后一帧被切。Buzz 里就出现过这个问题最后一个镜头的字幕卡被切掉了半秒看起来像卡顿。我的做法是不用-shortest而是先确保音频和视频时长严格一致然后用-t显式指定总时长ffmpeg -i buzz_visual.mp4 -i buzz_audio.wav \ -c:v copy -c:a aac -b:a 192k -t 182.4 buzz_final.mp4182.4是 manifest 里所有镜头时长的总和。这个值由脚本自动算出来不手填。注意-c:v copy表示视频流不重新编码速度快。但如果前面视频片段的编码参数不完全一致copy 可能会出问题。稳妥起见如果拼接后的视频是用同一套参数生成的copy 是安全的如果混用了不同来源的片段建议重新编码。5. 踩过的坑那些文档里不会写的细节5.1 ffmpeg 版本差异导致的参数行为变化ffmpeg 不同版本之间某些参数的行为会变。我遇到过一次-ss在输入定位时的精度问题在 4.x 版本上切出来的音频起点比预期晚了约 0.1 秒换到 6.x 版本就正常了。所以项目开始前一定要固定 ffmpeg 版本并且把版本号写进 README。ffmpeg -version | head -n 1 # 输出示例ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers我们的做法是在仓库里放一个setup.sh里面写清楚需要的 ffmpeg 版本和安装方式。如果是 Linux用包管理器装如果是 Windows从官网下载 essentials 包解压后把bin目录加进 PATH。5.2 PNG 透明通道引发的黑边前面提过 alpha 通道的问题这里展开说。Canva 导出的 PNG 如果带透明背景ffmpeg 在-pix_fmt yuv420p转换时透明区域会被填充为黑色。如果设计时背景是白色输出就会变成黑底白字完全不是想要的效果。解决方案有两个一是在 Canva 导出时确保背景是不透明的二是在 ffmpeg 里用color源做底层把 PNG 叠上去。ffmpeg -f lavfi -i colorcwhite:s1920x1080:d2.0 \ -i buzz_s02_c05_v03.png \ -filter_complex [0:v][1:v]overlay(W-w)/2:(H-h)/2 \ -t 2.0 -r 30 -pix_fmt yuv420p seg.mp4这个方案更灵活因为背景色可以随时改不用回 Canva 重新导出。5.3 音频采样率不一致导致的音画漂移如果录音是 44.1kHz而视频片段的音频轨是 48kHz合并时 ffmpeg 会自动重采样但重采样可能引入微小的时长偏差。片段多的时候这个偏差会累积导致后面几段音画不同步。我的做法是统一所有音频为 48kHz在切片阶段就转好ffmpeg -i take_s02.wav -ar 48000 -ac 2 take_s02_48k.wav-ar 48000指定采样率-ac 2指定双声道。这一步做完之后后面所有处理都基于 48kHz不再有重采样。5.4 GitHub 大文件推送失败的处理PNG 和 wav 文件加起来很容易超过 GitHub 单文件 100MB 的限制。我们的做法是用.gitignore排除原始素材只提交处理后的中间产物和脚本。原始素材放在本地 NAS 上用 manifest 记录路径。如果确实需要提交大文件可以用 Git LFS。但 LFS 有配额限制免费账户每月 1GB 流量。我们的项目没到这个量级所以没用 LFS而是严格控制提交内容。# .gitignore raw/ *.wav *.psd *.canva只提交assets/pages/下的 PNG 和scripts/下的脚本以及manifest.csv。这样仓库体积能控制在 200MB 以内。6. 流程固化从一次性项目到可复用管线6.1 目录结构项目做了一半之后我意识到这套流程不应该只服务 Buzz应该做成可复用的。于是重新整理了目录结构buzz-pipeline/ ├── assets/ │ └── pages/ # Canva 导出的 PNG ├── audio/ │ └── takes/ # 原始录音 ├── scripts/ │ ├── build_segments.py # 生成视频片段 │ ├── build_audio.py # 生成音频片段 │ ├── concat.py # 拼接 │ └── merge.py # 音画合并 ├── manifest.csv # 核心配置 ├── setup.sh # 环境准备 └── README.md每个脚本只做一件事通过 manifest 串联。这样换一个项目只需要换 manifest 和 assets脚本不用动。6.2 manifest 的字段设计manifest 是整个管线的配置中心字段设计要覆盖所有可变部分字段说明示例scene场景号s02shot镜号c05file页面文件名buzz_s02_c05_v03.pngversion版本号v03duration镜头时长秒2.0audio_start音频起点秒2.31audio_dur音频时长秒1.8note备注字幕卡-开场duration和audio_dur不一定相等duration通常比audio_dur大 10% 到 15%留出呼吸空间。6.3 一键构建所有脚本串起来之后整个构建过程就是一条命令python scripts/build_all.py这个脚本依次调用 build_segments、build_audio、concat、merge最后输出buzz_final.mp4。中间产物放在build/目录下方便排查问题。如果某一步失败脚本会打印出具体的 ffmpeg 命令和错误输出而不是只报一个构建失败。这一点很重要因为 ffmpeg 的错误信息通常很具体直接看就能定位问题。7. 关于 Hermes 和智能体辅助的一点实际体会Hermes 在这个项目里承担的是流程建议和文案辅助的角色。具体来说它帮我们做了两件事一是根据分镜文案生成 Canva 页面的命名建议二是检查 manifest 里的字段有没有遗漏或格式错误。这两件事都不复杂但确实省了一些重复劳动。我的体会是智能体辅助在结构化、有明确规则的任务上比较可靠比如命名规范检查、字段完整性校验。但在需要审美判断的任务上比如页面配色、镜头节奏它给的建议只能当参考最终还是要人来定。Buzz 里有几个镜头的时长Hermes 建议缩短但实际看下来缩短后节奏太赶最后还是按原来的时长。另外一点是智能体生成的命令或脚本一定要自己跑一遍再进管线。我遇到过 Hermes 生成的 ffmpeg 命令里-pix_fmt参数位置放错导致输出格式不对。这种错误在静态检查时看不出来只有实际跑才会暴露。8. 如果重做一次我会改什么如果现在重新做 Buzz我会在流程上做三个调整。第一在 Canva 导出阶段就统一像素格式。现在是在 ffmpeg 阶段处理 alpha 通道如果 Canva 导出时就能保证不透明背景后面能省一步。Canva 的导出选项里可以设置背景色只是之前没注意。第二把 silencedetect 的参数做成可配置的。现在阈值是硬编码的 -35dB换一个录音环境就要改脚本。如果做成 manifest 里的一个字段换环境时只改配置。第三更早引入 manifest。Buzz 前半段的镜头顺序是写在脚本里的改顺序要改代码。后半段才改成 manifest 驱动明显顺畅很多。这个教训是只要一个东西会变就把它变成配置不要变成代码。这套流程现在跑下来从 Canva 导出到最终成片三分钟的片子大概需要 40 分钟处理时间其中大部分是 ffmpeg 编码。人工介入的部分主要是确认音频切点和检查输出。相比一开始用剪辑软件手动对齐效率提升大概在三倍左右而且可回滚、可复现改一个镜头不用从头再来。最后分享一个小技巧ffmpeg 的-progress参数可以把编码进度输出到文件配合tail -f可以实时看进度不用干等。ffmpeg -i input.mp4 -c:v libx264 -progress progress.log output.mp4 tail -f progress.log这个在批量处理时特别有用能清楚知道卡在哪一步。