跑团Replay制作实战：从OBS多音轨录制到ffmpeg后期全流程

看跑团 Replay 已经成了不少人的固定娱乐方式，尤其是《寄生者之间》这类 PVP 秘密团，每一集都充满了互相试探、身份反转和“节目效果拉满”的名场面。很多观众看的时候会好奇：这种一群人挂在语音频道里聊天、GM 私下传信息、最后还要剪成完整观看体验的视频，到底是怎么做出来的？其实，跑团 Replay 背后不只是“几个人开个语音就开始玩”，而是一整套从信息分发、录像采集到后期剪辑的技术流程。尤其是 PVP 秘密团，对“身份隔离”和“素材分离”的要求比普通合作团高出很多。这篇文章就围绕线上跑团与 Replay 制作，整理一份完整可落地的实战笔记，覆盖环境准备、OBS 录制、多音轨分离、ffmpeg 转码、字幕时间轴修正和常见排错思路，帮助想自己做跑团内容或者想优化现有流程的朋友少走弯路。

1. 跑团 Replay 是什么？为什么秘密团更吃技术准备

1.1 从“跑团”到“Replay”的转化过程

跑团全称是桌上角色扮演游戏，比如大家熟悉的 DND、COC，或者各种自定规则的轻量系统。玩家各自扮演角色，由 GM（Game Master，主持人）负责推进剧情、扮演 NPC、判定规则。整个过程通常以语音对话为主，配合文字、图片、地图和骰子判定。

Replay 就是把一场跑团游戏的过程录下来，通过剪辑、加字幕、配音效、贴 BGM，让没有参与游戏的人也能看懂发生了什么。早期的跑团 Replay 多为文字记录版，后来随着视频直播工具成熟，越来越多团队采用“线上语音 + OBS 录屏 + 后期剪辑”的方式制作视频。这类视频的核心看点不是画面精致，而是玩家之间的对话博弈、角色成长和突发事件，所以素材保留的重点在“声音清晰”和“画面可读”。

1.2 PVP 秘密团对技术流程的特殊要求

普通合作团的玩家目标一致，信息基本共享，录制时只要保证大家能听清、画面不丢就行。PVP 秘密团完全不同，比如《寄生者之间》这类设定中，玩家们表面上在合作完成任务，实际上每个人都有自己的秘密目标，甚至身份里就藏着“警察”“寄生者”这类阵营对立关系。这意味着：

• GM 必须能单独给某个玩家发信息，其他人不能看。
• 玩家之间的私聊不能被公开频道误发出去。
• 观众在 Replay 中应该看到“谁在撒谎、谁在试探”的悬念，而不是提前看到全部底牌。
• 录制时如果直接把所有玩家视角合在一个画面，很容易把秘密信息提前暴露。

所以在正式录制之前，就要做好信息分层和权限隔离。技术准备的重点不是“录下来”，而是“怎么录才能既不丢信息，又不提前泄底”。

1.3 本文适合谁读

这篇文章适合四类读者：一是想把自己线上跑团做成 Replay 视频的主持人或玩家；二是已经在录制但经常遇到音画不同步、素材混乱问题的进阶玩家；三是 PVP 秘密团的组织者，想解决“私聊传话混乱”“身份信息泄露”的问题；四是对 ffmpeg、Python 脚本感兴趣，想用自动化方式处理视频素材的技术爱好者。全文以通用工具为主，不需要特定付费软件，照着步骤走就能跑通。

2. 环境准备：线上跑团与 Replay 制作的基础设施

2.1 硬件与系统环境

线上跑团看起来只要“能开语音”就行，但要稳定录制并剪出高质量 Replay，硬件配置比想象中重要。建议最低配置如下，实际根据团队情况调整：

• 操作系统：Windows 10/11、macOS 或主流 Linux 发行版均可，本文示例不依赖特定系统。
• 内存：16GB 及以上。跑团时如果同时打开语音软件、浏览器、跑团工具和 OBS，内存不够很容易导致录屏卡顿。
• 存储：建议使用 SSD 存放录制素材，至少预留 50GB 空间。一期 2 小时的跑团素材，加上多音轨和原始视频，体积会很快膨胀。
• 麦克风：每人一个独立麦克风，优先选择动圈麦或带降噪的电容麦。耳机比外放音箱更安全，避免回声串音。
• 摄像头：不是必须，但如果画面中有摄像头视角，可以增加 Replay 的现场感。
• 网络：上行带宽建议 10Mbps 以上。语音和直播同时进行时，网络抖动会直接影响录音质量。

2.2 常用软件清单

以下软件属于“线上跑团 Replay 制作标配”，其中绝大多数是免费或开源软件：

版本说明：本文不针对某个特定软件版本，示例命令在常见版本下均可运行。如果你的 OBS 版本不同，菜单名称可能略有差异，但核心概念一致，关键是理解“场景、来源、音轨”三个词的含义。

2.3 项目目录规划与文件命名

我见过很多跑团视频做到一半发现素材丢失，根本原因不是硬盘坏，而是文件命名混乱。表面上是“小事”，真正剪辑时就会很痛苦。建议在录制前就建好规范目录。

replay-ep05/ ├── raw/ │ ├── video/ │ │ └── episode05-obsvideo.mkv │ ├── audio/ │ │ ├── episode05-track-game.wav │ │ ├── episode05-track-voice.wav │ │ └── episode05-track-mic.wav │ └── chat/ │ └── episode05-text-log.txt ├── subtitles/ │ ├── episode05-align.srt │ └── episode05-origin.srt ├── output/ │ ├── episode05-master.mp4 │ └── episode05-publish.mp4 ├── scripts/ │ ├── shift_subtitles.py │ └── roll_helper.py └── 说明文档.md

文件命名建议遵循“集数-内容-版本”的规则，例如ep05-voice-v2.wav。避免使用“新建文件夹”“最终版”“真正最终版”这类命名方式。版本用 v1、v2 明确递增，素材只在 raw 文件夹中保存原始文件，所有中间产物放在对应子目录中，这样即使后期剪辑出错也能快速回滚。

3. PVP 秘密团的信息分发与隐藏机制设计

3.1 秘密团最容易翻车的几个场景

PVP 秘密团里，“信息泄露”是最大的事故源。结合线上跑团的实际观察，最常见的翻车场景有三类。

第一，GM 私聊发错频道。GM 需要给玩家 A 发送隐藏身份信息，结果误发到全员频道，整个团的悬念瞬间消失。技术上的解决方法是使用带“固定私聊窗口”的语音工具，把每个玩家对应到一个独立私聊会话，并且养成“发消息前先看频道名”的习惯。

第二，共享文档泄露秘密字段。很多团队习惯用在线文档维护角色卡，但如果把“秘密身份”“秘密任务”也放在同一个表格里，玩家误开文档或者截图时就会暴露。这个问题在技术上非常好解决，只要把信息分成公开区和秘密区，秘密区单独建一个文档，仅对 GM 可见。

第三，Replay 画面中意外露底。录制时如果玩家共享屏幕展示自己的角色图，而角色图里包含了“警察”或“寄生者”标记，观众一眼就看到了。录制前必须明确：涉及秘密身份的画面不能出现在公开共享屏幕中，要么单独录制，要么后期打码。

3.2 用“频道权限 + 私聊流程”控制信息边界

秘密团的信息管理可以按照层级拆分，不同信息流向不同的“频道”，所有成员共用一套约定。下面是一个可参考的权限清单：

这里的关键是“所有秘密信息必须走 GM——玩家一对一的私聊通道”。不要使用群内全体可见的投票、不要在小群里接收秘密任务，因为小群截图一旦传播，泄底风险很高。每期开始前，GM 应该花两分钟核对一遍私聊窗口是否对应正确玩家，并把秘密文档访问权限设为“仅指定成员可查看”。

3.3 角色卡与秘密身份的“数据隔离”

从数据结构角度看，PVP 秘密团的关键是把“每个玩家知道什么”和“每个玩家实际是什么”分离。公开角色卡和秘密身份卡应该像两个模块，前者可以全员可见，后者只能 GM 和玩家本人可见。下面是一个最小角色卡模板，你可以根据自己的规则扩展字段。

{ "player_id": "p03", "role_name": "夜莺", "public_role": "医生", "public_skill": [ "急救", "心理安抚" ], "secret_role": "寄生者", "secret_mission": [ "存活到最后", "至少感染两名玩家", "不能让警察玩家存活" ], "secret_items": [ "感染标记 ×2" ] }

在实际使用中，这个 JSON 可以拆成两个文件：role_p03_public.json放到共享文档，role_p03_secret.json单独发给玩家和 GM。更稳妥的做法是只把公开部分放在线协作文档，秘密部分通过私聊单独发送，避免云端权限设置疏忽。

这段设计不只是在跑团中有效，很多需要做“身份隔离”的信息系统也有类似思路：公开数据源和机密数据源分开存储，访问控制精确到“谁、什么时候、能看什么内容”。跑团组局虽然不需要那么强的安全体系，但至少要有意识地做分层。

3.4 隐藏掷骰与 PK 辅助

PVP 秘密团里，骰子结果也经常需要隐藏。合作团可以公开掷骰大家一起欢呼，秘密团里如果玩家偷偷搜证或者发动隐藏技能，GM 需要单独看结果。用普通的实体骰子无法满足隐藏需求，线上跑团时可以使用文字私聊给 GM 掷骰结果，或者写一个简单的小脚本。下面是一个用 Python 实现的极简掷骰工具，适合在本地命令行运行，重点演示思路，你可以根据自己的规则扩展。

import random import re def roll_dice(dice_expr: str) -> tuple: """ 解析类似 "2d6+1"、"1d20"、"3d8" 的表达式，返回每次骰子结果和总和。 示例： roll_dice("2d6+1") -> ([3, 5], 9) """ dice_expr = dice_expr.strip().lower() bonus = 0 if "+" in dice_expr: expr_part, bonus_part = dice_expr.split("+", 1) bonus = int(bonus_part.strip()) else: expr_part = dice_expr match = re.match(r"^(\d*)d(\d+)$", expr_part) if not match: raise ValueError(f"无法识别的骰子表达式: {dice_expr}") count_str, sides_str = match.groups() count = int(count_str) if count_str else 1 sides = int(sides_str) results = [random.randint(1, sides) for _ in range(count)] total = sum(results) + bonus return results, total if __name__ == "__main__": expr = input("输入骰子表达式，例如 2d6+1: ") try: results, total = roll_dice(expr) print(f"骰子结果: {results}, 合计: {total}") except ValueError as e: print(f"输入错误: {e}")

这个脚本只是裸的随机数生成，实际跑团中建议加上“结果记录到本地日志”的功能，方便 GM 在复盘时核对。PVP 团里对“掷骰真实度”要求高的场景，可以使用专门的掷骰机器人，但核心原则是一样的：谁需要看结果，就只把结果发给谁，不要让所有玩家都能看见。

4. 录制端配置：用 OBS 做好“素材分离”

4.1 为什么不能只录一个画面

很多人第一次做跑团录制，习惯直接用“录制桌面 + 采集麦克风”的方式，最后拿到一个视频文件和一条混音音轨。这样制作 Replay 时会发现几个麻烦：某位玩家麦克风音量太小、背景噪音盖过了游戏声、GM 说了一句关键设定但被笑声盖住。如果所有声音混在一条音轨里，后期根本无法修复，只能重新录或者放弃。

正确思路是“素材分离”：画面可以有多场景，声音必须有多个音轨。OBS 天然支持多音轨输出，所以录制时就把游戏声音、语音频道、自己的麦克风、BGM 分别放到不同轨道，后期调音会轻松很多。

4.2 OBS 场景与来源设计

OBS 的核心概念有两个：场景和来源。一个场景相当于一个“画面布局”，来源则是画面里的具体元素。线上跑团建议准备 3 个或以上场景：

• 场景一：开播封面。用来展示本期标题、系列信息，可以放静态图片。
• 场景二：地图/资料展示。包含浏览器窗口、游戏画面、GM 素材共享。
• 场景三：全员摄像头画面。适合需要露脸的团队，用“视频采集设备”把每个玩家的摄像头放进场景里。

在每个场景中，通过“来源——窗口采集”的方式把需要展示的窗口加进去。重点提醒：秘密团的玩家在共享屏幕前，一定要把隐藏信息窗口关闭，否则 OBS 会把你的“警察身份”一五一十直播出去。

4.3 多音轨分离设置

在 OBS 的“设置——输出——录像”中，可以设置录像格式和音轨数量。以常见版本为例，录像格式可以选择 MKV，避免录制过程中程序崩溃导致文件损坏。音频轨道的含义需要理解清楚：每个麦克风、每个应用的声音都可以添加到“音频混合器”中，你可以把不同来源分配到不同音频轨道。

一个推荐的多音轨方案：

具体操作：在“音频混合器”中，点击每个来源右侧的齿轮按钮，选择“高级音频属性”，然后勾选该来源要输出到哪几条轨道。注意麦克风来源和系统声音来源不要同时勾选到同一条轨道，否则就失去了分离意义。录制时，OBS 会把多条轨道写入同一个 MKV 文件，方便后续用 ffmpeg 提取。

4.4 直播与本地录制的编码建议

在线跑团 Replay 制作通常有两种场景：一是在直播平台直播跑团过程，二是只录屏不发直播。如果是后者，录制时可以适当提高码率和画质，把录像分辨率设置为 1920×1080，帧率 30fps，视频编码优先选择硬件编码，例如 NVIDIA NVENC 或 AMD AMF，能显著降低 CPU 占用；如果是纯软件编码，画质可控但电脑负载会明显升高，容易导致语音卡顿。

如果是边直播边录制，直播推流码率通常受平台限制，本地录制则不要降低太多码率。一个稳妥的思路是：推流使用平台推荐的码率，本地录制把“录制质量”设置为“无损”或接近无损，这样直播画面和 Replay 素材的画质互不影响。这里的核心原则是“直播效果是一时的，素材质量是长期的”，录制的原始文件尽可能高质量，后期再压缩发布版本。

5. Replay 后期：ffmpeg 与剪辑工作流

5.1 从 OBS 录像中提取多条音轨

OBS 录制出来的 MKV 文件里默认包含多个音频轨。用 ffmpeg 可以快速把它们拆出来。ffmpeg 是一个功能强大的命令行视频处理工具，没有图形界面，但做批量转换时效率极高。它的安装方式因系统而异，Windows 用户可以下载官方构建版本，macOS 可以用 Homebrew 安装，Linux 用户一般直接用包管理器安装。

提取音轨的命令如下：

# 查看 MKV 文件里的所有轨道信息 ffmpeg -i episode05.mkv # 提取第一条音频轨（通常对应音轨 1） ffmpeg -i episode05.mkv -map 0:a:0 -c:a pcm_s16le episode05-track-game.wav # 提取第二条音频轨（通常对应音轨 2） ffmpeg -i episode05.mkv -map 0:a:1 -c:a pcm_s16le episode05-track-voice.wav # 提取第三条音频轨 ffmpeg -i episode05.mkv -map 0:a:2 -c:a pcm_s16le episode05-track-bgm.wav

这里的-map 0:a:0表示从输入文件的第 0 个文件中选取音频轨道的第 0 条。pcm_s16le是一种无损 PCM 编码，把音轨转成 WAV 后，在 Audacity 或剪辑软件中处理更灵活。如果你希望保留为 AAC 格式以减小体积，可以把-c:a pcm_s16le换成-c:a aac -b:a 192k。

5.2 批量转码与格式统一

不同设备录制的素材格式可能不同，比如 OBS 输出 MKV，手机拍摄输出 MOV，游戏录屏输出 TS。在剪辑前最好统一转换为便于剪辑软件识别的 MP4 格式，顺便把视频编码统一为 H.264。

ffmpeg -i input.mov -c:v libx264 -preset medium -crf 18 -c:a aac -b:a 192k output.mp4

参数说明：-preset medium是编码速度和压缩率的平衡选择；-crf 18表示画面质量较高，数值越小画质越高，一般 18~23 之间合适；音频部分用 AAC 编码，比特率 192kbps 对语音内容足够。如果是素材文件，可以放宽到-crf 16，保证细节不丢失。

多个素材批量转换时，可以写一个简单的 for 循环命令：

for f in raw/video/*.mkv; do ffmpeg -i "$f" -c:v libx264 -preset medium -crf 18 -c:a aac -b:a 192k "output/$(basename "${f%.mkv}").mp4" done

在 Windows 命令行中 for 循环写法略有不同，也可以在 Python 里调用 os.listdir 循环处理，核心逻辑相同。

5.3 字幕时间轴批量修正

跑团 Replay 通常会加字幕。然而字幕制作中非常容易出现“字幕比人声早半秒”或“延迟 1 秒才出现”的问题。如果一期视频有几百条字幕，手动逐条调整不现实。用 Python 脚本批量处理 SRT 字幕文件就可以解决。

SRT 文件的时间格式为小时:分钟:秒,毫秒，例如00:01:23,456 --> 00:01:25,789。下面这个脚本可以把所有字幕整体向前或向后偏移指定秒数，适合统一修正时间轴误差。

import re from pathlib import Path def time_to_ms(t: str) -> int: """把 SRT 时间字符串转为毫秒，例如 00:01:23,456 -> 83456""" h, m, rest = t.split(":") s, ms = rest.split(",") return int(h) * 3600000 + int(m) * 60000 + int(s) * 1000 + int(ms) def ms_to_time(ms: int) -> str: """把毫秒转为 SRT 时间字符串""" ms = max(0, ms) h, ms = divmod(ms, 3600000) m, ms = divmod(ms, 60000) s, ms = divmod(ms, 1000) return f"{h:02d}:{m:02d}:{s:02d},{ms:03d}" def shift_srt_file(input_path: str, output_path: str, offset_ms: int): """整体偏移 SRT 字幕时间轴。offset_ms 为正则向后偏移，为负则向前偏移。""" content = Path(input_path).read_text(encoding="utf-8") pattern = re.compile(r"(\d{2}:\d{2}:\d{2},\d{3}) --> (\d{2}:\d{2}:\d{2},\d{3})") def replace_time(match): start = time_to_ms(match.group(1)) + offset_ms end = time_to_ms(match.group(2)) + offset_ms return f"{ms_to_time(start)} --> {ms_to_time(end)}" new_content = pattern.sub(replace_time, content) Path(output_path).write_text(new_content, encoding="utf-8") print(f"已生成: {output_path}") if __name__ == "__main__": input_file = "subtitles/episode05-origin.srt" output_file = "subtitles/episode05-align.srt" # 例如字幕整体早于声音 0.8 秒，需要向后偏移 +800 毫秒 shift_srt_file(input_file, output_file, 800)

这个脚本虽然简单，但能解决实际后期中最烦人的“整体错位”问题。如果时间轴误差是动态变化的，那就需要逐段对齐，脚本只适用于整体偏移场景。

5.4 在剪辑软件中合成

素材准备好后，进入剪辑环节。跑团 Replay 的剪辑重点不是转场特效，而是“让观众听清、看懂”。建议按以下顺序处理：

第一步，对轨。把提取出的多条音频轨导入剪辑软件，根据波形对齐。一般语音轨是主轴，麦克风轨和游戏轨围绕它微调，确保同一句话不会出现回声和重叠。

第二步，降噪和音量平衡。语音轨先用 Audacity 做降噪处理，去掉底噪和鼠标键盘声。所有人声统一音量，建议使用响度标准化，让观众不需要频繁调整耳机音量。

第三步，画面切换。根据说话人切换对应摄像头画面，或者是图表展示窗口。切换点尽量落在句子停顿处，不要把一句话从中间切断。

第四步，字幕嵌入。把修正好的 SRT 字幕导入剪辑软件，根据需要调整字体大小、描边和位置。跑团 Replay 字幕不需要太花哨，但人名标注非常重要，尤其是多人同时说话时，观众需要知道谁在发言。

6. 常见问题与排查思路

录制跑团素材往往要连续进行两三个小时，任何环节出错都会影响整个后期。下面是线上跑团 Replay 制作中最常见的问题清单。

排错时不要急躁，优先使用“二分法”定位问题：先确认是录制阶段的问题还是后期阶段的问题，再缩小到具体环节。比如无声问题，先把 OBS 录像文件导入播放器检查有没有音轨；如有音轨则可能是剪辑软件导入设置问题；如无音轨则检查 OBS 音频采集。录一段 30 秒的测试素材，是排查绝大多数问题的有效手段。

7. 最佳实践与工程建议

7.1 录制前必须确认的清单

与其出了问题再补救，不如在开录前把风险降到最低。每个参与录制的人都可以对照以下清单快速检查：

• 语音软件连接正常，耳机已佩戴，麦克风没有静音。
• OBS 已识别所有音频源，音轨分配符合约定。
• 共享屏幕时，所有秘密文档、私聊窗口、桌面敏感信息均已关闭。
• 磁盘剩余空间足够，录像格式设为 MKV。
• 录像测试片段可以正常播放，音画同步。
• 每名玩家都知道本期录制的公开范围，避免在语音中说“不宜公开”的信息。
• GM 私聊窗口的对应关系核对无误，秘密文档权限已设置。

7.2 素材管理与备份策略

跑团 Replay 的后期修改频率很高，视频很可能在发布前经历多轮调整。没有备份习惯的话，一次误操作就可能让几小时的剪辑工作白费。建议采用“三份拷贝”原则：原始素材保存在本地硬盘，中间产物保存在另一个目录，成品发布前至少在移动硬盘或网盘中保留一份压缩备份。每周清理一次临时文件，不要把所有临时文件堆在桌面。

7.3 隐私与合规问题

跑团内容涉及真人语音和可能被识别的个人信息。将视频发布到公开平台前，一定要获得所有参与者的明确授权。如果玩家不愿意露脸，就不要放摄像头画面；如果玩家改了昵称，尽量在 Replay 中使用其游戏昵称或化名，不要暴露真实姓名。涉及未成年人的内容要格外谨慎，征得监护人同意后再公开。视频中如果出现了玩家聊天时随手提到的私人地址、电话、工作单位等信息，后期要考虑静音或删除这段素材。

7.4 权限与安全边界

跑团是娱乐活动，但在搭建跑团工具、共享文档、自动化脚本时，也要注意基本的安全边界。在线文档的链接不要随意发到公开群，重要的秘密文档应设置访问权限而不是“任何人可查看”。自己编写的掷骰脚本、字幕脚本只在本机运行，不要随便从网上下载不明来源的插件。涉及账号登录、云存储的内容，不要共享密码，使用邀请制或最小权限原则。

7.5 如何让 Replay 更耐看

从内容创作者的角度说，明确“哪些信息让观众知道、哪些信息让观众猜”非常重要。PVP 秘密团的 Replay 想要好看，不能把所有秘密身份全部展示给观众，也不能让观众完全蒙在鼓里。比较常见的处理方式是：在视频开场做一个“本期玩家角色简介”，只展示公开身份；在每段揭晓秘密时，再通过剪辑切换、音效强调来制造爆点。这样观众既有信息基础，又能体会到现场玩家的博弈心理。

8. 总结与进阶方向

整理完这套流程后，你会发现线上跑团 Replay 的制作并没有想象中困难。按照“信息隔离 → 多音轨录制 → 素材分离 → 自动化解算 → 剪辑发布”的主线，一整套 PVP 秘密团的视频制作链路就能跑通。每期只需要重点盯住两个核心目标：让现场玩家玩得顺畅，让屏幕前的观众看得清楚。

接下来想进阶的话，可以从几个方向继续深入。一是自动化字幕生成，把语音识别模型接进流程，减少人工打字成本；二是用跑团数据管理工具建设剧情树，让 GM 在秘密团中管理多路线剧情；三是学习达芬奇或 Pr 的高级调音调色技巧，进一步压缩后期时间。这些内容都是建立在扎实的基础流程之上的。

不管你是想追平《寄生者之间》这类节目的制作质感，还是想从零开始组建自己的跑团内容小团队，都可以先拿一集素材把流程完整走一遍。真正的经验是剪出来、录出来、踩坑踩出来的。希望这份笔记能帮你少走几个弯路，也欢迎在评论区分享你录制跑团过程中遇到的那些“名场面式”问题。