从素材到成品：用ffmpeg与Whisper搭建短视频批量二创流水线

好，这次我们不聊代码仓库，也不聊模型权重，而是拆一个看起来一点都不技术的短视频标题：

【盒盒短视频】TREASURE 260809 | D to the E, to the L-I-C-I-O-U-S｜玹硕 道荣 炡禹

第一眼是偶像物料，第二眼是粉丝二创。但把标题拆开看，信息密度非常高：系列标识、团名、日期、歌词梗、成员名单、内容类型全在十几个字里。从技术角度讲，这其实是一个很典型的“短视频二创生产链路”的成品样例。

这类视频的制作并不靠运气，也不靠剪辑软件里的“自动卡点”按钮，而是有清晰可复现的本地流程：素材归档、音频提取、节拍检测、歌词转写、字幕压制、批量导出。本文就把这条链路拆开，用 ffmpeg、Python、Whisper 和几段可复用的脚本，还原一个偶像向二创短视频从素材到成品的制作过程。

如果你是追星女孩想自己动手做物料，或是短视频运营需要批量生产类似内容，又或者是想在本地搭一套半自动剪辑流程，这篇文章可以直接收藏。

1. 核心能力速览

这段话先说清楚：这不是一个“双击就能跑”的整合包，而是一套可拆解、可替换的工作流。每一环都有现成工具，关键是把它们串起来。

2. 适用场景与使用边界

2.1 适合谁

• 粉丝剪辑爱好者：想给喜欢的团做舞台直拍二创、卡点混剪、歌词字幕视频。
• 短视频运营：需要批量产出统一规范的偶像内容切片，字幕、标题、封面风格一致。
• 本地工具党：不想用在线剪辑平台的素材压缩和水印，倾向于在本地用脚本完成。

2.2 能解决什么问题

• 素材多、命名乱：用统一目录和 CSV 元数据管理，省去剪辑软件里反复导入。
• 卡点不准：用 onset 检测把节拍时间自动算出来，不再手动一帧一帧试。
• 字幕对齐慢：用 Whisper 生成带时间戳的逐字稿，再人工微调歌词梗位置。
• 导出效率低：用 ffmpeg 批量压制，一条命令生成多条成品。

2.3 不适合什么场景

• 不适合商业化搬运：偶像舞台画面、音乐版权都属于原公司或版权方，未授权商用有侵权风险。
• 不适合恶意二创：不涉及换脸、声音克隆、恶意剪辑、造谣式拼贴。
• 不适合零基础没有命令行概念的人：虽然每一步都有现成命令，但中途仍需要改路径、调参数。

2.4 版权与合规提醒

涉及偶像真人肖像、音乐、舞台画面时，必须确认素材来源和授权范围。本文只讨论技术实现，不提供任何盗版素材下载渠道。个人学习、粉丝自娱自乐不等于可以商用，发布到公开平台时也要遵守平台内容规范。尤其不要把人声提取、语音识别、视频生成等能力用于伪造内容，合法授权是底线。

3. 环境准备与前置条件

3.1 需要安装的软件

3.2 安装 ffmpeg

Windows 可以通过 winget 安装：

winget install ffmpeg

macOS 使用 Homebrew：

brew install ffmpeg

Linux 使用对应包管理器：

sudo apt update && sudo apt install ffmpeg

安装后验证：

ffmpeg -version

如果提示找不到命令，检查是否把 ffmpeg 可执行目录加入了系统 PATH。

3.3 安装 Python 依赖

建议先创建虚拟环境，避免污染全局 Python：

python -m venv venv

Windows 激活虚拟环境：

venv\Scripts\activate

macOS/Linux 激活：

source venv/bin/activate

安装依赖：

pip install faster-whisper librosa numpy pandas

如果你的显卡支持 CUDA，并且已经装好 PyTorch 的 CUDA 版本，faster-whisper 会自动尝试使用 GPU。更稳妥的做法是先检查 torch 是否可用：

python -c "import torch;print(torch.cuda.is_available())"

输出True才说明 PyTorch 检测到了 CUDA。如果你只想用 CPU 跑，也可以不装 GPU 版本，只是转写速度会慢一些。

3.4 目录规划

建议所有项目文件放在同一个根目录下：

project/ ├── input/ # 原始视频素材 ├── audio/ # 提取出来的音频 ├── timestamps/ # 卡点时间戳 ├── subtitles/ # 字幕文件 ├── output/ # 成品视频 ├── metadata.csv # 素材标题、成员、日期、标签 └── scripts/ # Python 脚本

这样做的目的是让批量任务有明确的输入输出边界，后面写脚本时不需要到处找路径。

4. 素材整理与标题信息拆解

4.1 从成品标题反推素材命名规则

题目里这个标题可以拆成几个字段：

做一个短视频二创，最怕的不是剪不好，而是素材文件名全是VID_20250809_190001.mp4。想要批量生产，先建立元数据。

4.2 使用 CSV 管理素材信息

metadata.csv是批量任务的“大脑”：

filename,group,date,lyric,members,tags input/raw_01.mp4,TREASURE,260809,D to the E to the L-I-C-I-O-U-S,玹硕 道荣 炡禹,舞台直拍 input/raw_02.mp4,TREASURE,260809,D to the E,道荣,竖屏直拍

这样每条素材的标题、简介、标签都可以从 CSV 动态生成，适合批量发布场景。

4.3 批量重命名示例

如果你已经有规范 CSV，可以用 Python 批量重命名：

import csv import os with open("metadata.csv", encoding="utf-8") as f: reader = csv.DictReader(f) for row in reader: old = row["filename"] base = os.path.basename(old) name, ext = os.path.splitext(base) new = f"{row['group']}_{row['date']}_{row['members'].replace(' ', '_')}_{row['lyric'][:12]}{ext}" if os.path.exists(old): os.rename(old, new) print(f"{old} -> {new}")

这段代码只是演示字段拼接，实际使用时需要处理好重名、路径不存在等情况。不要直接对重要原始素材执行，先复制一份到备份目录再测试。

5. 音频提取与卡点检测

二创短视频最容易出效果的是“卡点”。手动卡点效率低，而且往往靠肌肉记忆。技术方案是用 librosa 检测音频中的 onset 强度，再换算成时间戳。

5.1 用 ffmpeg 提取音频

从素材中提取 44.1kHz、单声道、16bit 的 WAV 音频，作为卡点分析输入：

ffmpeg -i "<your_video>.mp4" -vn -ac 1 -ar 44100 -sample_fmt s16 "<your_audio>.wav"

参数说明：

• -vn去掉视频流
• -ac 1转成单声道
• -ar 44100统一采样率
• -sample_fmt s16使用 16bit PCM

如果素材很长（比如整场演唱会），建议先切片到目标区间，再提取音频，减少分析时间。

5.2 用 librosa 检测节拍和卡点

import librosa import numpy as np audio_path = "audio/your_audio.wav" y, sr = librosa.load(audio_path, sr=44100) # 检测 onset strength onset_env = librosa.onset.onset_strength(y=y, sr=sr) # 找到 BPM tempo, beats = librosa.beat.beat_track(onset_envelope=onset_env, sr=sr) # 转成时间戳 beat_times = librosa.frames_to_time(beats, sr=sr) # 保存为文本 np.savetxt("timestamps/beats.txt", beat_times, fmt="%.3f") print("检测完成，BPM 约", tempo)

这个脚本会把每个节拍的时间点输出到timestamps/beats.txt。实际做卡点视频时，不一定每个节拍都要切一次，可以按需保留强拍：

# 只保留每两个节拍中的一个作为切点 selected = beat_times[::2] with open("timestamps/beat_selected.txt", "w", encoding="utf-8") as f: for t in selected: f.write(f"{t:.3f}\n")

卡点是否准确，最终要回到剪辑软件里人工确认。自动检测的意义是帮你节省 80% 的定位时间，而不是完全替代人工审美。

5.3 按时间戳切片

得到时间戳后，可以用 ffmpeg 一键切出多个片段：

ffmpeg -i "<your_video>.mp4" -ss 00:00:01.500 -t 2.000 -c:v libx264 -c:a aac "output/segment_01.mp4"

批量切片用 Python 遍历时间戳文件即可。需要注意：-ss放在-i前面会快速定位，但切点可能不是精确关键帧；追求精确可以放在-i后面，但会先解码再定位，速度更慢。批量产出场景建议用“先 -ss 前 + 后”方式，且结束后用播放器抽查关键位置。

6. 歌词转写与字幕生成

偶像舞台二创经常把歌词变成屏幕上的记忆点。人工打轴很痛苦，尤其是“D to the E, to the L-I-C-I-O-U-S”这种逐字母节奏。用 Whisper 可以快速生成带时间戳的文本，再人工修正歌词梗位置。

6.1 使用 faster-whisper 转写

from faster_whisper import WhisperModel model_size = "small" # tiny, base, small, medium, large-v3 model = WhisperModel(model_size, device="cuda", compute_type="float16") segments, info = model.transcribe("audio/your_audio.wav", language="en") with open("subtitles/lyrics.srt", "w", encoding="utf-8") as f: idx = 1 for seg in segments: start = seg.start end = seg.end text = seg.text.strip() f.write(f"{idx}\n") f.write(f"{ts(start)} --> {ts(end)}\n") f.write(f"{text}\n\n") idx += 1

其中时间戳格式化函数：

def ts(seconds): ms = int((seconds % 1) * 1000) s = int(seconds) m, s = divmod(s, 60) h, m = divmod(m, 60) return f"{h:02d}:{m:02d}:{s:02d},{ms:03d}"

如果你的显卡不是 CUDA，device可以改成"cpu"，compute_type改成"int8"。速度会慢，但可用。

6.2 字幕精修策略

自动转写结果不一定适合发布。至少有这几个问题：

• 歌词大小写、标点需要统一。
• 逐字母拼写的梗，比如 “L-I-C-I-O-U-S”，Whisper 可能识别成 “Delicious” 或乱码。
• 成员名字不一定是英文，转写后可能需要替换成中文标签。

建议在生成 SRT 后，用文本编辑器或字幕软件做一次人工校对。带时间戳的草稿已经省去了大量打轴工作，这一轮人工处理值得。

7. 剪辑合成与硬字幕压制

剪辑软件可以完成精细调色和动态字幕，但批量压制、统一格式、批量打水印这些场景，ffmpeg 效率更高。

7.1 硬字幕方式

下面命令把输入视频转成 1080x1920 竖屏，添加居中字幕：

ffmpeg -i "<your_video>.mp4" -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2,subtitles=subtitles/lyrics.srt:force_style='FontName=Microsoft YaHei,FontSize=18,Alignment=2,MarginV=100'" -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 192k "output/final.mp4"

说明：

• scale和pad把视频适配成 9:16 竖屏，背景黑边。
• subtitles过滤器会烧录字幕，中文环境需要指定中文字体，避免乱码。
• force_style可以控制字体大小、位置、颜色。
• crf 23是 H.264 的常用质量参数，数值越小画质越高，文件越大。

硬字幕的优势是任何播放器都能显示，劣势是字幕不可再编辑。

7.2 软字幕方式

如果想让观看者自己开关字幕，可以把 SRT 封装进 MP4：

ffmpeg -i "<your_video>.mp4" -i "subtitles/lyrics.srt" -c:v copy -c:a copy -c:s mov_text "output/final_soft.mp4"

移动端某些播放器对mov_text支持不完全，发布前要在目标平台测试。

7.3 添加片头和标题文字

类似“盒盒短视频”这样的栏目标识，可以用drawtext放到固定位置：

ffmpeg -i "<your_video>.mp4" -vf "drawtext=text='盒盒短视频':x=20:y=20:fontsize=24:fontcolor=white:box=1:boxcolor=black@0.5:boxborderw=10:fontfile='C\:/Windows/Fonts/msyhbd.ttc'" -c:v libx264 -crf 23 "output/final_title.mp4"

Windows 路径里的冒号需要转义，Linux 路径直接用/usr/share/fonts/...。更推荐把文字画到一张 PNG 上，再用overlay叠加，避免字体路径问题。

8. 批量任务与自动化工作流

单个视频做好以后，批量生产就是流水线问题。思路是：扫描 CSV 中每条素材 -> 提取音频 -> 检测卡点 -> 转写字幕 -> 调用 ffmpeg 合成 -> 输出统一文件名 -> 记录日志。

8.1 Python 批量脚本骨架

import csv import subprocess from pathlib import Path BASE_DIR = Path(".") INPUT_DIR = BASE_DIR / "input" OUTPUT_DIR = BASE_DIR / "output" AUDIO_DIR = BASE_DIR / "audio" with open("metadata.csv", encoding="utf-8") as f: reader = csv.DictReader(f) tasks = list(reader) for i, row in enumerate(tasks, 1): video = INPUT_DIR / row["filename"] audio = AUDIO_DIR / f"audio_{i}.wav" final = OUTPUT_DIR / f"{row['group']}_{row['date']}_{row['members']}.mp4" # 提取音频 subprocess.run([ "ffmpeg", "-y", "-i", str(video), "-vn", "-ac", "1", "-ar", "44100", "-sample_fmt", "s16", str(audio) ], check=True) print(f"[{i}] 音频提取完成: {audio}")

这只是演示第一段。实际生产时，还需要把卡点检测、字幕转写、ffmpeg 合成分别封装成函数，并且在每一步捕获异常、记录日志。

8.2 失败重试与日志

批量任务最容易出现的问题是：某一条素材损坏、某一步 ffmpeg 返回非零退出码、某个字幕文件路径不存在。建议统一约定：

• 每处理一条素材前，先检查输入文件是否存在。
• 每步执行成功后，把状态写入process_log.csv。
• 遇到失败不中断整个队列，而是跳过并记录错误。
• 全部结束后，单独输出失败清单。

for task in tasks: try: process_one(task) except Exception as e: with open("fail.log", "a", encoding="utf-8") as f: f.write(f"{task['filename']}: {e}\n") continue

这样可以保证批量任务不会因为一条坏数据全部卡死。

8.3 用 API 包装

如果你希望把流程暴露成接口，给运营同学调用，可以用 FastAPI 包一层：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Task(BaseModel): filename: str group: str date: str members: str @app.post("/render") def render(task: Task): # 这里调用渲染函数 return {"status": "accepted", "task": task.filename}

启动服务：

uvicorn api_server:app --host 127.0.0.1 --port 8000

这样就能在自己的内网里把二创短视频渲染做成一个小型服务。不建议直接暴露公网，除非有完整的鉴权机制。

9. 资源占用与性能观察

本地剪辑和批量渲染，性能瓶颈通常在两个地方：音频转写的推理速度，以及视频编码速度。

9.1 如何观察资源占用

• 转写阶段用 Whisper：nvidia-smi可以看到显存占用和 GPU 利用率。
• 视频压制阶段用 ffmpeg：任务管理器或top可以看到 CPU/GPU 负载。
• 如果转写模型是large-v3，显存占用会明显高于small；如果批量任务同时开多个进程，内存也会上升。

不要轻信网上固定的“占用 X G 显存”的结论，不同分辨率、不同时长、不同模型版本会导致数字差距很大。最稳妥的做法是自己先跑一个 30 秒片段，把显存和内存峰值记下来，再决定批量并发数。

9.2 CPU 与 GPU 的差异

• CPU 推理：兼容性好，老电脑也能跑，但速度慢。适合素材量少、不急的场景。
• GPU 推理：速度快，但对驱动和 PyTorch 版本有要求。50 系显卡需要对应版本的 CUDA 驱动，老显卡有时候反而因为驱动问题跑不起来。
• 视频编码：NVIDIA 显卡可以用h264_nvenc，Intel 核显可以用h264_qsv，macOS 可以用h264_videotoolbox。

ffmpeg 硬件编码示例：

ffmpeg -i "<your_video>.mp4" -c:v h264_nvenc -preset p4 -cq 23 -c:a aac "output/final_nvenc.mp4"

如果使用的是非 NVIDIA 显卡，这条命令会失败，需要换成对应的编码器名称。

9.3 降低资源占用的方法

• 转写阶段：使用small或base模型，采用 int8 量化。
• 视频合成：先做低分辨率试跑，确认效果后再用原分辨率正式渲染。
• 批量任务：限制同时运行的 ffmpeg 进程数，避免视频编码和转写抢资源。
• 滤镜尽可能少：多个滤镜叠加会显著降低编码速度，尤其是subtitles和drawtext同时使用。

关于 50 系显卡的支持，需要看 ffmpeg 版本、显驱动版本、PyTorch CUDA 版本是否配套。新显卡建议先查对应版本的 release notes，再决定是否启用硬件编码。

10. 常见问题与排查方法

11. 最佳实践与使用建议

11.1 先小后大，先单条后批量

不要第一次就把 100 条素材扔进批量脚本。先用一条 10 秒素材完整走一遍：

• 提取音频是否正常？
• 卡点时间是否满意？
• 字幕是否压在安全区？
• 输出文件名是否符合预期？

确认没问题后，再扩展到全部素材。

11.2 目录和命名是自动化的一半

统一的目录结构、统一的 CSV 字段、统一的输出文件名，是批量任务不出乱子的前提。建议把素材按日期、拍摄场景分目录，并在文件名里保留原始拍摄信息，方便回溯。

11.3 字幕和封面分离

硬字幕一旦烧录就改不了。发布多个平台时，不同平台对字幕位置、安全区要求不同，建议保留一份无硬字幕的干净版，以及一份带字幕的发布专用版。

11.4 合规审查做在渲染之前

确认素材来源合法、音乐版权清晰、肖像授权明确。如果涉及商业账号，必须拿到授权或使用平台版权库内容。个人粉丝二创尽量标注非商用、来源信息，但仍要承担平台审核风险。

11.5 给脚本留好接口

把 ffmpeg 命令封装成函数，把参数放在配置文件中，后续增加分辨率、添加封面、调整水印位置就不用改核心逻辑。

render: width: 1080 height: 1920 crf: 23 encoder: libx264 subtitle_font: "Microsoft YaHei" watermark: text: "Non-commercial" position: "top_right"

配置文件比硬编码更利于团队协作和非技术成员调整。

12. 总结与下一步

这次拆解的短视频案例，核心不是“TREASURE”或“盒盒短视频”本身，而是这套流程：从标题中提取规范字段，用 ffmpeg 完成音频提取和压制，用 librosa 做节拍检测，用 Whisper 生成字幕，再用 Python 脚本把整个过程串成批量任务。

最值得先跑通的是 ffmpeg 的切片和字幕压制命令，因为这两步直接决定成品是否可用。最容易踩的坑也是这一步，滤镜写错、字体路径不对、音视频编码参数不匹配，都会让批量任务在最后一公里失败。

下一步如果你要继续扩展，可以往这几个方向走：

• 用 Whisper 批量生成多语言字幕，做海外平台适配；
• 把渲染流程包装成 FastAPI 服务，给账号运营提供自助上传入口；
• 加入自动生成封面的逻辑，用 Python 把标题、成员名、日期绘制到图片上；
• 对每期成品的播放数据进行回收，反推哪些歌词梗、哪些成员组合更适合做卡点内容。

二创短视频的技术门槛没有想象中高，关键是把每一步都变成可复用的命令和脚本。先把最小链路跑通，再逐步加自动化，你会发现效率提升非常明显。