用Python+FFmpeg搭建速通切片自动生成流水线

在游戏速通（Speedrun）圈子，切片（Clip）已经不只是记录成绩的素材，而是观众获取快乐的主要载体。一条速通切片，通常是从几十甚至几小时的通关录像里，裁出几十秒的小片段，专门保留玩家突然大喊、角色飞出去、读档瞬间、结算画面翻转等画面。看到“末影奶龙”一类带角色梗的速通切片，观众会捧腹大笑，但这类切片未必都靠纯手工去找。手动剪一条当然可以，如果每周要产出几十条，就必须把“找素材、切片段、加字幕、换画风”这几个环节尽量自动化。我会从实际工程角度，用 Python 和 FFmpeg 搭建一条最小可用的速通切片自动生成流水线，覆盖音频兴奋点检测、场景切换检测、时间戳合并、精确切割、字幕与画面滤镜，最后给出常见问题排查和参数调优清单。

1. 先理解速通切片的内容特征和自动化思路

1.1 速通切片为什么让人捧腹大笑

速通玩家追求的是最短通关时间，过程中会大量使用邪道、跳关、Bug 和极限操作。真正让观众笑出声的，往往不是“跑得快”本身，而是高度紧张下出现的反差点：上一秒还在秀操作，下一秒角色被弹飞；存档点前一步被小怪打断；Boss 血量还剩一丝，结果突然黑屏读档。

这类笑点有很强的“事件性”，一定对应某个时间点上的异常信号。可能是玩家音轨里突然出现一声喊叫，可能是画面瞬间切到加载页，也可能是一段 2 秒的静音后爆发出一句粗口。如果这些时刻都要靠人工在完整录像里反复拖动播放条去找，产出效率会非常低。尤其当速通录像长达 3 到 5 小时，事后剪辑的时间成本会远超录像本身。

“末影奶龙”这类题材的速通切片，本质上也是同一套规律：画面梗加玩家反应，再加一点字幕和音效衬托。技术含量不一定高，但剪辑节奏必须准。于是自然产生一个需求：能不能用程序先自动候选出这些“可能搞笑”的时间段，再人工做一次筛选和精修？答案是可以，而且不需要很复杂的机器学习模型。

1.2 自动切片需要抓住哪些关键信号

自动化做不了“理解笑点”，但可以抓笑声、语音、画面变化、停顿这些可计算信号。从工程上看，四类信号最常用：

本文先处理前两类：音量尖峰和场景切换。因为它们实现成本最低，不需要训练模型，也不需要 GPU，普通笔记本就能跑通。即使误检率偏高，也可以作为候选片段供给人工二次选择。

1.3 一条可落地的切片流水线概览

完整的流水线可以拆成六个阶段：

1. 从原始录像中抽取单声道 PCM 音频。
2. 计算音量包络，找出高于阈值的尖峰时间点。
3. 用 FFmpeg 的 scene 滤镜找出画面发生明显变化的场景切换点。
4. 把音量尖峰和场景切换点合并成“候选事件”，并扩展成带前后缓冲的切片时间区间。
5. 用 FFmpeg 按时间区间切割视频，生成基础切片。
6. 给切片加上 ASS 字幕和轻量画面滤镜，输出最终版本。

这套流程可以用一个 Python 脚本串联起来。底层命令全部交给 FFmpeg，Python 只负责算时间戳、生成字幕文件和组织批处理命令。这样既绕开了复杂视频解码逻辑，也方便以后接入 Livesplit 分段文件、ASR 语音情绪识别等扩展。

2. 环境准备：FFmpeg、Python 与素材目录要对齐

2.1 检查 FFmpeg 是否可用

项目依赖 FFmpeg 做三件事：抽音频、分析场景、切割视频。先确认系统里已经安装了 FFmpeg 和 FFprobe：

bash复制ffmpeg -version
ffprobe -version

两个命令都能输出版本信息才算正常。如果提示找不到命令，需要先安装 FFmpeg。常见方式：

• Ubuntu/Debian：sudo apt update && sudo apt install ffmpeg
• macOS：brew install ffmpeg
• Windows：通过 winget、Chocolatey 或 FFmpeg 官方发布的二进制包安装

FFmpeg 版本建议不要太旧。本文用到的 -f f32le、scene 滤镜和 libx264 编码器，在 4.x 以上版本都能使用。安装完成后还需要确认是否包含 libass 字幕过滤器：

bash复制ffmpeg -filters 2>/dev/null | grep ass

如果能搜到 ass 或 subtitles，说明可以直接把 ASS 字幕烧录进视频。如果没有，后续 H2 5 的字幕功能会失效，需要换回 drawtext 或重新安装带 libass 的 FFmpeg 版本。

2.2 安装 Python 依赖

Python 部分只需要一个第三方库：numpy。FFmpeg 的调用全部通过标准库 subprocess 完成，不依赖 ffmpeg-python，因为直接拼命令更直观，排查问题时也更容易看到原始报错。

bash复制pip install numpy

推荐使用 Python 3.9 以上版本。低版本 Python 对 subprocess.run 的 capture_output 参数支持已经存在，但 numpy 在新版本上的二进制包更稳定，减少编译环境带来的麻烦。

2.3 准备素材目录和输入文件

先建立固定目录，避免脚本在运行时找不到输出路径：

text复制speedrun-clipper/
├── input/
│   └── run.mp4
├── output/
├── subs/
└── speedrun_clipper.py

input/run.mp4 可以是 OBS 录制的直播回放、NVIDIA ShadowPlay 片段，也可以是手机拍摄的屏幕录像。只要 FFmpeg 能读取，格式本身不是硬性限制。为了减少问题，建议测试阶段先用一段 10 分钟以内的 MP4 文件。

脚本启动时要读取视频总时长，因为后面扩展切片区间时不能超过视频结尾。先用 FFprobe 获取：

bash复制ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 input/run.mp4

在 Python 里可以把这条命令封装成函数，后面计算切片时间时使用：

python复制import subprocess

def get_duration(path):
    cmd = [
        "ffprobe", "-v", "error",
        "-show_entries", "format=duration",
        "-of", "default=noprint_wrappers=1:nokey=1",
        path
    ]
    result = subprocess.run(cmd, capture_output=True, text=True, check=True)
    return float(result.stdout.strip())

这里使用 -v error 只输出错误信息，避免 FFprobe 把大量流信息刷到标准输出中。如果返回的字符串解析失败，大概率是输入文件不是有效媒体文件。

3. 用音量特征找出“兴奋点”：最小切片引擎

3.1 为什么音量包络能近似反映玩家的兴奋程度

速通录像的音轨通常包含游戏声音和玩家语音。当玩家打出失误、极限操作或遇到搞笑 Bug 时，情绪会直接影响语音音量。即使不看画面，也能通过音量包络发现“这里发生了什么事”。

音频信号中，均方根（RMS）可以反映一个时间段内声音能量的平均值。声音越大，RMS 越高。计算方式也很简单：对一段采样点求平方和，再开方。FFmpeg 负责把视频里的音频解码成原始采样点，Python 负责计算 RMS，两者分工明确。

3.2 从视频中抽离 PCM 音频

在 Python 里调用 FFmpeg，把音频转成单声道、16kHz 采样率、float32 格式的裸 PCM 数据。使用裸 PCM 而不是直接生成 WAV 文件，是因为可以直接用 numpy.frombuffer 转成数组，避免临时文件占满磁盘：

python复制import numpy as np
import subprocess

def extract_pcm(path, rate=16000):
    cmd = [
        "ffmpeg", "-i", path,
        "-vn", "-ac", "1", "-ar", str(rate),
        "-f", "f32le", "-"
    ]
    raw = subprocess.check_output(cmd)
    return np.frombuffer(raw, dtype=np.float32)

命令里每个参数都是有目的的：

• -vn 表示不要视频流，只处理音频。
• -ac 1 把多声道混合成单声道，后续计算不需要声道维度。
• -ar 16000 降低采样率。16kHz 已经能覆盖人声主要频段，处理速度比 44.1kHz 快很多。
• -f f32le 输出 float32 小端序 PCM，numpy 可以直接解析。

注意，如果原视频没有音轨，check_output 会报错。测试素材一定要确认有声音。

3.3 计算音量包络与尖峰

得到 PCM 数组后，按窗口计算 RMS。窗口越短，时间精度越高，但波动也越剧烈。先默认 0.1 秒一个窗口：

python复制def compute_rms(samples, window_sec=0.1, rate=16000):
    window_size = int(window_sec * rate)
    if window_size <= 0:
        return np.array([])

    rms_list = []
    for i in range(0, len(samples) - window_size + 1, window_size):
        frame = samples[i:i + window_size]
        rms = float(np.sqrt(np.mean(frame ** 2) + 1e-10))
        rms_list.append(rms)

    return np.array(rms_list)

1e-10 是防止静音段计算结果为 0，导致后续除法出现除零问题。这里没有做重叠窗口，因为 0.1 秒的时间粒度已经足够生成候选切片，重叠计算只会在长录像上白白增加耗时。

下一步是找尖峰。简单做法是：所有 RMS 值的中位数乘以一个倍数作为阈值，然后扫描超过阈值的点。加上冷却时间，避免同一个兴奋事件被连续标记十几次：

python复制def find_peaks(rms_values, multiplier=3.0, cooldown_sec=2.0, window_sec=0.1):
    if len(rms_values) == 0:
        return []

    threshold = float(np.median(rms_values) * multiplier)
    cooldown_frames = int(cooldown_sec / window_sec)
    peaks = []
    last_peak_frame = -cooldown_frames

    for i, value in enumerate(rms_values):
        if value > threshold and i - last_peak_frame >= cooldown_frames:
            peaks.append(i * window_sec)
            last_peak_frame = i

    return peaks, threshold

中位数比均值更适合做音量阈值：录像里大部分时间可能是安静的，均值会被少数几个巨大音量拽高，导致真正的尖峰被淹没。中位数能代表“安静时的日常音量”。

3.4 把尖峰扩展成切片时间表

单个尖峰时间点不适合直接切割，因为观众需要看到事件发生前因后果。一般会在尖峰前后各保留一段缓冲。例如前 3 秒、后 6 秒：

python复制def expand_to_slices(peaks, total_duration, before=3.0, after=6.0, min_duration=2.0):
    slices = []
    for t in peaks:
        start = max(0.0, t - before)
        end = min(total_duration, t + after)
        if end - start >= min_duration:
            slices.append((start, end))
    return slices

这一步的参数直接影响产出效果：

3.5 用 FFmpeg 精确切割视频

按起止时间切割视频，推荐把 -ss 放在 -i 前面，使用 -t 指定持续时长，并重新编码：

python复制import os

def cut_basic(input_path, output_dir, slices, prefix="clip"):
    os.makedirs(output_dir, exist_ok=True)

    for index, (start, end) in enumerate(slices, 1):
        duration = end - start
        output_path = os.path.join(output_dir, f"{prefix}_{index:03d}.mp4")
        cmd = [
            "ffmpeg", "-ss", str(start),
            "-i", input_path,
            "-t", str(duration),
            "-c:v", "libx264",
            "-c:a", "aac",
            "-avoid_negative_ts", "make_zero",
            "-y", output_path
        ]
        subprocess.run(cmd, capture_output=True, text=True, check=True)

这里没有使用 -c copy，而是重新编码。原因有两个：第一，速通录像里经常包含丢帧、异常时间戳，直接复制流会产生花屏；第二，后续要加字幕和画面滤镜，本来就必须重新编码。-avoid_negative_ts make_zero 是为了处理切割点在非关键帧时产生负时间戳的问题。

注意：如果只做测试，可以临时把 -c:v libx264 换成 -c:v mpeg4 -q:v 5，速度更快，但文件更大、画质更差。正式批量处理不建议用 mpeg4。

4. 场景切换检测与事件合并

4.1 为什么需要场景切换检测

音量尖峰能抓住“玩家吼出来了”，但抓不住“画面猛地黑屏”这种无声笑点。有些速通切片最好笑的地方恰好是角色卡进墙、一秒读档、画面瞬间翻转。这时候音轨可能很安静，音量检测会漏掉。

场景切换检测是对音量检测的补充。它的原理是逐帧计算画面差异，当差异超过阈值时认为出现了一次镜头切换。速通录像里最典型的场景切换就是死亡读档，画面从游戏场景切到加载黑屏，再切回存档点。

4.2 用 FFmpeg 的 scene 滤镜输出时间点

FFmpeg 的 select 滤镜可以配合 scene 表达式输出满足条件的帧，再通过 showinfo 把时间戳打到日志里：

python复制import re

def detect_scenes(path, threshold=0.3):
    cmd = [
        "ffmpeg", "-i", path,
        "-vf", f"select='gt(scene,{threshold})',showinfo",
        "-f", "null", "-"
    ]
    proc = subprocess.run(cmd, capture_output=True, text=True)
    times = []
    for line in proc.stderr.splitlines():
        match = re.search(r"pts_time:([0-9.]+)", line)
        if match:
            times.append(float(match.group(1)))
    return times

scene 的阈值不是固定值，严格程度取决于视频内容：

这个命令会把整段视频完整解码一遍，只是不输出实际视频文件，速度仍然比导出视频快。如果遇到卡顿，可以后面再做抽帧优化。

4.3 合并音量事件与场景事件

音量尖峰和场景切换会产生两组时间点。直接切成两组片段会造成大量重复，还会把同一个搞笑事件切成好几条。更合理的做法是先合并，再做一次简单的时间序列合并：

python复制def merge_events(peaks, scenes, total_duration, merge_gap=2.0, before=3.0, after=6.0):
    events = sorted(set(peaks + scenes))

    merged = []
    for t in events:
        if merged and t - merged[-1][1] <= merge_gap:
            merged[-1] = (merged[-1][0], max(merged[-1][1], t))
        else:
            merged.append((t, t))

    slices = []
    for t0, t1 in merged:
        start = max(0.0, t0 - before)
        end = min(total_duration, t1 + after)
        if end - start >= 2.0:
            slices.append((start, end))

    return slices

merge_gap 表示两个事件相隔小于该值就当成同一段。例如玩家先喊了一声，0.5 秒后画面切到读档，这两个时间点会合并成一个候选片段。

输出结果类似：

text复制音量尖峰: [12.3, 15.8, 44.2, 78.0]
场景切换: [13.0, 60.5, 80.2]
合并切片: [(9.5, 21.9), (41.0, 50.5), (57.2, 66.5), (75.0, 84.2)]

合并后的切片时间表可以直接交给切割函数。这一步是整个流水线中“人工筛选负担”的分水岭：合并规则设置得好，候选片段数量会明显下降，质量也更接近真实剪辑需求。

5. 增加字幕和轻量搞笑效果

5.1 使用 ASS 字幕而不是 drawtext

很多教程会直接用 drawtext 把字幕写进画面，但中文字体路径、转义字符和换行处理非常麻烦。更稳妥的方式是先生成 ASS 字幕文件，再用 FFmpeg 的 ass 滤镜加载。

ASS 文件本身是文本格式，可以动态生成。比如把切片时间表和字幕文本一一对应：

python复制def format_ass_time(seconds):
    hours = int(seconds // 3600)
    minutes = int((seconds % 3600) // 60)
    secs = int(seconds % 60)
    centisecs = int((seconds - int(seconds)) * 100)
    return f"{hours}:{minutes:02d}:{secs:02d}.{centisecs:02d}"

def write_ass(slices, captions, ass_path):
    lines = [
        "[Script Info]",
        "ScriptType: v4.00+",
        "PlayResX: 1280",
        "PlayResY: 720",
        "",
        "[V4+ Styles]",
        "Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding",
        "Style: Default,Microsoft YaHei,28,&H00FFFFFF,&H000000FF,&H00202020,&H80000000,-1,0,0,0,100,100,0,0,1,2,1,2,20,20,20,1",
        "",
        "[Events]",
        "Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text"
    ]

    for (start, end), caption in zip(slices, captions):
        start_str = format_ass_time(start)
        end_str = format_ass_time(end)
        safe_text = caption.replace(",", "\\,").replace("\n", "\\N")
        lines.append(f"Dialogue: 0,{start_str},{end_str},Default,,0,0,0,,{safe_text}")

    with open(ass_path, "w", encoding="utf-8") as f:
        f.write("\n".join(lines))

字幕文本可以来自人工写好的 CSV，也可以在后续版本里接上 ASR 识别结果。示例中字体使用 Microsoft YaHei，在 Linux 上如果没有该字体，需要改成系统已有字体，否则字幕区域会显示方块。

5.2 用 filter 做轻微的画面强化

速通切片要“有节目感”，但不能把画质改得面目全非。推荐做三件事：

• 增加一点对比度和饱和度，让画面更精神。
• 对特别慢的片段做轻微加速，但不要影响语音音调。
• 给字幕叠加 outline，保证在任何背景上都看得清。

FFmpeg 的 filter 可以组合起来：

bash复制-vf "ass=subs.ass,eq=contrast=1.05:saturation=1.15,setpts=0.95*PTS" -af "atempo=1.05"

这里 setpts 控制画面速度，atempo 控制音频速度。atempo 的取值在 0.5 到 2.0 之间，一次加速超过这个范围会报错。如果需要大幅加速，要分两次处理。

5.3 组装最终切片

把基础切割和字幕滤镜合并成最终函数：

python复制def finalize_clip(input_path, start, end, ass_path, output_path,
                  contrast=1.05, saturation=1.15, speed=1.0):
    duration = end - start

    video_speed = 1.0 / speed if speed > 0 else 1.0
    audio_speed = speed

    vf = f"ass={ass_path},eq=contrast={contrast}:saturation={saturation}"
    af = f"atempo={audio_speed}"

    if abs(video_speed - 1.0) > 0.001:
        vf += f",setpts={video_speed:.3f}*PTS"

    cmd = [
        "ffmpeg", "-ss", str(start),
        "-i", input_path,
        "-t", str(duration),
        "-vf", vf,
        "-af", af,
        "-c:v", "libx264",
        "-c:a", "aac",
        "-avoid_negative_ts", "make_zero",
        "-y", output_path
    ]
    subprocess.run(cmd, capture_output=True, text=True, check=True)

实际使用中，字幕文件的时间轴是相对于每个切片内部的，不是相对于原始录像。ass 滤镜会把整段视频当成从 0 开始，所以生成 ASS 时要把时间统一从切片开始时间重新计算，或者直接把 ASS 里的时间都从 0 开始，字幕只覆盖切片内部区间。

6. 运行一次最小闭环并验证输出

6.1 准备一段测试录像和启动参数

用一段带音轨的 MP4 文件作为测试输入，比如速通录像的前 10 分钟。把文件放到 input/run.mp4 后，在脚本中依次调用前面这些函数，就可以得到切片结果。

为了快速验证，可以先用一组温和的参数：

bash复制python speedrun_clipper.py \
  --input input/run.mp4 \
  --output output \
  --peak-mult 3.0 \
  --before 3 \
  --after 6 \
  --scene-thresh 0.3

如果脚本还没有接入命令行参数，可以先用一个简单的主函数固定参数跑一次。重点是看到“输入视频 -> 候选时间表 -> 切片文件”的完整路径是通的。

6.2 预期输出和验证命令

运行结束后，output 目录下应该有多个以 clip_001.mp4 开头的文件。合格的主函数应该打印以下信息：

text复制total duration: 3724.14s
rms peaks: 15
scene cuts: 28
merged slices: 18
wrote output/clip_001.mp4 (12.3s ~ 20.1s)
wrote output/clip_002.mp4 (41.0s ~ 50.5s)

验证切片时长是否符合预期：

bash复制ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 output/clip_001.mp4

再随机播放几条切片，检查是否存在黑屏开头、音频爆音或字幕缺失。不要只看程序没报错，就认为输出一定正确。

6.3 如何判断切片质量

建立一套简单的质量检查清单：

• 切片时长在预期范围内，比如 8 到 12 秒。
• 开头不是长时间黑屏。
• 音频没有明显破音。
• 字幕文字完整，没有被画面背景吞掉。
• 切片里确实包含一个可识别的事件：喊叫、死亡、读档、闪屏中的至少一种。
• 相邻切片之间没有大量内容重叠。

如果某条切片不满足以上任意一条，就应该检查对应的候选时间点，而不是直接输出给观众。

7. 常见问题排查

7.1 FFmpeg 命令报错或找不到 libass

7.2 音量阈值导致漏检或碎片太多

如果一条切片都没有，很可能是 peak_mult 设置得太大，导致中位数乘以倍数后高过所有音量值。可以先打印 RMS 的分布情况：

python复制rms = compute_rms(samples)
print("median:", float(np.median(rms)))
print("p75:", float(np.percentile(rms, 75)))
print("p95:", float(np.percentile(rms, 95)))

如果 p95 与中位数相差不大，说明视频整体音量平稳，需要把 peak_mult 从 3.0 降到 2.0，或者改成 median + k * std 的相对阈值。相反，如果切片过多，说明阈值过低或冷却时间太短，把 cooldown_sec 调到 3 秒以上可以明显减少重复。

7.3 切割后时间轴错乱或黑屏

切割后播放时间不对，通常与 -ss 的位置有关。-ss 放在 -i 之前表示输入定位，速度较快，但有些旧版本对时间戳处理不够干净；-ss 放在 -i 之后表示输出定位，速度慢但精确。如果出现负时间戳或开头黑帧，可以加上 -avoid_negative_ts make_zero，并把切割方式改成重新编码，不要使用 -c copy。检查时用 FFprobe 读取切片起始时间：

bash复制ffprobe -v error -show_entries format=start_time -of default=noprint_wrappers=1:nokey=1 output/clip_001.mp4

7.4 字幕乱码或消失

字幕乱码有两个常见原因：ASS 文件没有以 UTF-8 保存，或者系统缺少指定字体。Python 的 open 使用 encoding="utf-8" 可以解决前者。字体问题可以用 fc-list :lang=zh 查看系统可用中文字体，然后把 ASS 里的 Fontname 改成实际存在的字体名称。

如果文字显示为方块，检查 Fontname；如果文字完全不显示，检查 ass 滤镜是否真的存在。Linux 下还要确认 FFmpeg 编译时包含了 libass，否则不会渲染字幕。

7.5 场景检测耗时过长

detect_scenes 会逐帧解码视频，长录像会非常慢。效率优化方法有三种：

• 先用 -vf fps=5 把帧率降下来，只对每秒 5 帧做场景判断，速度大幅提升，时间精度损失不大。
• 只处理前 30 分钟或指定时间段，通过 -ss 和 -t 限制输入范围。
• 使用支持硬件的 FFmpeg 构建版本，例如通过 GPU 解码，再配合 filter 分析。

场景检测本身应当作为离线批处理任务，不适合放在实时服务里。生产环境建议把它放到录制完成后的后台任务队列中。

8. 自动化切片流水线的最佳实践和扩展方向

8.1 参数调优清单

没有一组参数能适配所有游戏录像。开始批处理前，先挑出三段不同风格的录像跑一遍，记录各自的中位数音量、场景切换频率和候选切片数量。可复用清单如下：

• 确认输入视频包含音轨，且玩家语音没有被 BGM 完全盖过。
• 确认 FFmpeg 与 FFprobe 版本可用。
• 确认 ass 滤镜存在，或准备好 drawtext 替代方案。
• 先用中位数的 3 倍作为音量阈值，观察峰值分布。
• 先用 0.3 作为 scene 阈值，观察场景切换数量。
• 合并事件前，先打印音量尖峰和场景切换时间点，人工核对 2 到 3 个点是否准确。
• 切割完成后随机抽 3 条切片播放，检查开头、结尾、字幕和时长。
• 生产环境批量处理前，确认磁盘空间足够，并保留原始录像和日志便于回溯。

8.2 发布前检查清单

切片生成之后，不一定要直接发布。发布前的检查应该包含内容层面和技术层面：

• 切片中是否包含他人版权音乐或受保护的音频，需要根据平台规则处理。
• 是否包含个人隐私信息，例如聊天框里的账号、地址、真实姓名。
• 切片画面是否过度增强，导致字幕边缘出现色块。
• 音频是否经过 atempo 处理后产生明显金属声。
• 输出视频是否能在主流播放器中正常解码。
• 文件名是否包含足够信息，方便回找原始录像时间点。

生产环境还应该把每次运行参数、输入文件哈希、FFmpeg 版本和候选时间表一起写进日志。否则批量处理一周后，很难定位某条切片是哪次跑出来的。

8.3 可以继续做的扩展

这套流水线只用了音量和场景两个信号，扩展空间很大。

可以对接 Livesplit 的分段时间文件，把“每个分段结束时间”也当作候选事件。速通玩家卡关最多的往往就是某个分段，分段结束前后的十几秒天然适合切片。解析 .lss 文件不需要额外依赖，用标准库的 xml.etree.ElementTree 就能读取。

可以接入 ASR 语音识别，识别玩家语音中出现的“啊”“不行”“跳跳跳”等高频词。将这些词的出现时间当作新事件，能覆盖音量检测抓不到的平静吐槽。这类功能需要额外安装模型，离线部署时要先确认机器内存。

还可以把脚本改造成一个批量后台任务，输入目录里每来一个新录像就自动处理，处理结果写入一个 JSON 清单。前端再做一个简单的时间轴预览界面，人工勾选最终要发布的切片。核心算法仍然是本文这套时间点检测，只是表层交互从“命令行”变成了“编辑器”。

速通切片看起来是纯娱乐内容，背后却是一套完整的媒体处理工程。先把“找素材”自动化，再集中精力做筛选和包装，比从头到尾手动剪辑更可持续。对刚开始接触视频处理的开发者来说，这也是练习 FFmpeg 命令、音频特征计算和批处理脚本设计的不错案例。