点播Reaction视频制作全攻略：从OBS录制到FFmpeg合成与HLS点播

最近几年，视频平台上出现了一种非常“上头”的内容类型：点播 Reaction。观众在评论区点一个老节目片段，UP主一边看一边录下自己的第一反应，再把原始片段和反应画面拼在一起，就成了一期视频。

比如那个“Beyond放暑假”的点播系列，很多观众点的是二三十年前的情景短剧片段，UP主自己都没想到当年的偶像在短剧里这么放得开。这种“画中画”形式让屏幕内外的人一起笑，弹幕区也特别热闹。很多人会以为，这无非就是“放一段视频，再开个摄像头录自己”，直到自己上手做一期，才发现根本不是这么回事。视频格式对不上、音画不同步、成片体积大得离谱、上传之后画质糊了……每一步都能把人劝退。

这篇文章我想用技术视角，把“点播 Reaction 视频生产”这件事完整拆开。你会看到从素材拆条、OBS 录制、ffmpeg 合成画中画、HLS 切片点播，到多人同步观看的完整链路。核心判断是：Reaction 类视频的技术门槛不在“看片”本身，而在录制的稳定性、合成时的音画同步，以及转码发布的工程化。把这套流程跑通，你不仅能稳定更新内容，还能顺手搭出一个支持多人同步观看的点播页面。

1. 点播 Reaction 到底是什么，技术视角怎么看

1.1 先给概念定个位

Reaction 视频在国外叫 Reaction Video，最初是网友把自己观看某段视频或预告片的反应录下来，再与原始素材同屏展示。点播 Reaction 是它的延伸：由观众指定想看的片段，创作者按点播内容录制反应。

从内容分类看，常见有三种形态：

从技术视角看，这三种形态的本质是一个数据流链路：

播放原始素材 → 摄像头与麦克风采集 → 本地录制 → 视频合成 → 字幕处理 → 转码封装 → 切片分发 → 终端播放。

很多人会忽略的一点是：你在屏幕上看到的“同屏”效果，并不是拍摄时完成的，而是后期合成出来的。这意味着，录制阶段如果不把原始画面和反应画面分开保存，后续一旦音画不同步，你几乎没有补救空间。这个认知会贯穿整篇文章。

1.2 真正难的是哪个环节

做过一期完整的点播 Reaction，你就会发现“看视频顺便说话”只占整个流程时间的很小一部分。真正花时间的是：

1. 素材拆条。观众点的可能是“第几集里有一段短剧”，你要快速定位并裁出准确片段。
2. 多轨同步。录制出来的素材、摄像头画面、麦克风声音、原片音频，四路信号要按同一时间轴合成。
3. 转码发布。不同平台对分辨率、码率、封装格式的要求不同，原始录屏文件往往几百 MB，直接上传不是不行，而是成本和体验都差。

所以这篇文章不会只讲“怎么录像”，而是把你从拿到素材到上架点播页的每个步骤都走一遍。

2. 核心概念：点播、编码、封装、HLS、音画同步

2.1 点播与直播的差别

点播 VOD（Video on Demand）和直播最大的区别是：点播内容是提前准备好、存在服务端，用户随时按需拉取；直播则是一次性实时推送。

Reaction 视频本身属于点播内容，但如果你以后想做“多人同步观看”的直播式体验，又会用到状态同步技术。理解这个区别有助于你判断技术选型。比如，一个人看点播页面，只需要一个静态 H5 播放器；三个人一起看并实时看到对方的进度，就需要一个中心服务来同步播放状态。

2.2 编码与封装：为什么“看着一样”却打不开

很多初学者会把“视频格式”理解成一个整体，实际上它分两层：

• 编码格式：视频数据用什么算法压缩，常见有 H.264、H.265、AV1。音频编码常见有 AAC、MP3、Opus。
• 封装格式：把压缩后的视频流、音频流、字幕信息装进一个容器，常见有 MP4、MKV、TS。

一个文件能不能被播放器解码，取决于编码格式是否被支持；一个文件能不能被剪辑软件导入，取决于封装格式是否被支持。举例来说，很多手机录出来的视频是 HEVC 编码的 MP4，老一点的剪辑软件导不进去，就是因为解码器不支持 HEVC，或者性能跟不上。

这解释了 Reaction 制作中的一个高频问题：为什么我录制的视频在播放器里很流畅，一进剪辑软件就卡，或者导出后音画不同步。大概率不是软件坏了，而是编码格式选错了。

2.3 HLS：可以边下边播的分片协议

HLS（HTTP Live Streaming）由苹果提出，核心思路是把一个完整视频切成若干小片段，通常是 6 到 10 秒一个 TS 文件，再用一个 m3u8 索引文件记录这些片段。

浏览器原生不支持直接播放 HLS，但可以通过 hls.js 或 Video.js 这类库实现。在点播场景里，HLS 的优势是可以自然适配 CDN 加速，用户拖动进度条时只需要请求对应片段，而不是下载整个文件。

我们在第 7 章的实操里，就会把合成好的成片切成 HLS 分片并放到静态服务器上。

2.4 音画同步的底层逻辑：DTS 与 PTS

“音画不同步”是 Reaction 视频制作中最常见的崩溃点。要理解它，需要知道视频流里有两类时间戳：

• DTS（Decoding Time Stamp）：解码器什么时候解码这一帧。
• PTS（Presentation Time Stamp）：显示设备什么时候显示这一帧。

为了压缩体积，视频帧存在 B 帧和 P 帧，编码顺序和显示顺序不一定一致，所以 DTS 和 PTS 不一定相等。正常情况下播放器会按 PTS 播放，让画面和声音对应。但如果录制或合成时丢帧，或者用了错误的-ss参数做切割，PTS 就可能发生跳变，导致持续一段时间后画面和声音错得越来越远。

在实操章节，我会给出检查和避免音画不同步的具体命令和参数。

3. 整体流程拆解：从确定选题到发布

这里先给出一个通用的流程，后面每一步都有具体操作。

1. 确定点播片段。观众点播后，先人工确认这段内容是否适合做成 Reaction，并确认素材版权和授权边界。
2. 素材预处理。把源视频裁出要用的片段，统一转码成 H.264/AAC 的 MP4，避免后续环节出现解码兼容问题。
3. 录制 Reaction。用 OBS 开启场景，主窗口播放素材，摄像头和麦克风采集反应。
4. 素材归档。录制的原始文件命名保存，保留多音轨和原始质量，不建议在录制阶段直接删素材。
5. 合成画中画。使用 ffmpeg 的 filter_complex 将原始片段和摄像头画面合成为一个视频，同时决定音频轨道怎么处理。
6. 字幕与细节。如果需要对白加字幕，可以用剪映或 Aegisub，也可以在接受纯命令行的前提下用 ffmpeg 烧录字幕。
7. 转码与切片。把成片转成 HLS 分片，放到点播静态服务器或对象存储。
8. 发布页面。编写一个包含播放器、标题、简介的 HTML 页面，让用户可以直接在线观看。
9. 进阶：多人同步观看。搭建 WebSocket 服务，让所有人共享播放进度。

这个流程看起来很线性，但在实际工作中，第 3 步和第 4 步是最容易出问题的环节。录制一旦结束，如果原始素材没有保存好，后期合成很难补救。请务必在录制前先检查磁盘空间和录制参数。

4. 环境准备与工具选型

后面的实操命令都基于以下工具，版本请以实际安装为准，本文重点演示通用思路。

4.1 检查 FFmpeg 是否可用

安装完成后，打开终端执行：

ffmpeg -version

如果系统找不到命令，说明环境变量没有配好。在 Windows 上，把 FFmpeg 的 bin 目录追加进 PATH 即可；在 macOS 上推荐用 Homebrew 安装：

brew install ffmpeg

4.2 检查 FFprobe

FFprobe 是 FFmpeg 套件里的分析工具，用来查看视频流的详细信息。后面排查音画不同步时会用到。

ffprobe -v quiet -print_format json -show_streams test.mp4

这条命令会输出 JSON 格式的流信息，包含视频编码、分辨率、帧率，以及音频的采样率、声道数等。

4.3 OBS 录制前的准备

OBS 是开源免费软件，适合录 Reaction 的关键在于：它可以同时采集显示器窗口、摄像头和麦克风，并且支持多音轨录制。后续如果想把原片声音和麦克风声音分开处理，可以在 OBS 输出设置里开启多个音轨。

建议的录制参数：

• 输出模式：高级
• 录像格式：MKV
• 视频编码器：硬件编码器优先，比如 H.264 或 HEVC
• 音频编码器：AAC
• 音轨：至少两个，一个放桌面音频，一个放麦克风

需要说明的是，如果只是做一个简单 Reaction，用单音轨也能完成合成。但多音轨的好处是后期可以分别调整原片音量和麦克风音量，还能在麦克风声音里做去噪。除非你对音质完全无所谓，否则不要一上来就只录单音轨。

5. 用 FFmpeg 完成视频拆条与素材预处理

5.1 为什么需要拆条

源视频往往很长，可能是一个多小时的节目。观众点播的只是其中三分钟的短剧片段。直接拿一小时的原片去合成，会导致处理时间变长、成片体积变大，也没有必要。

拆条的第一步，是先确定片段的时间区间。可以用播放器看，也可以先用 FFmpeg 抽出一张张关键帧来快速浏览，但最直观的做法还是播放器拖动后记录时间点。

5.2 按时间区间切割

假设源视频文件叫source.mkv，我们需要保留00:02:30到00:05:45的部分，并输出为 H.264/AAC 编码的clip01.mp4，可以使用：

ffmpeg -ss 00:02:30 -i source.mkv -t 00:03:15 -c:v libx264 -c:a aac -avoid_negative_ts make_zero clip01.mp4

这里几个参数值得解释：

• -ss 00:02:30：表示从源视频的第 2 分 30 秒开始处理。把它放在-i前面，FFmpeg 会先快速跳转，速度更快；放在-i后面则会更精确但更慢。
• -t 00:03:15：表示处理 3 分 15 秒。
• -c:v libx264：把视频编码为 H.264。
• -c:a aac：把音频编码为 AAC。
• -avoid_negative_ts make_zero：修正切割后可能出现的时间戳偏移，是减少音画不同步的有效手段。

如果源视频本身就是 H.264 编码，并且不想重编码，可以使用-c copy：

ffmpeg -ss 00:02:30 -i source.mkv -t 00:03:15 -c copy clip01.mp4

-c copy理论上速度快，因为它不重新压缩画面，但在某些时间点切割时，会因为关键帧位置不准确而导致开头黑屏或者首帧画面不对。如果你追求稳定，优先用第一种重编码方案。

5.3 拆条后的检查

切割完成后，用 FFprobe 检查输出文件的流信息，确认时长、编码、分辨率符合预期：

ffprobe -v quiet -print_format json -show_streams -show_format clip01.mp4

其中注意看format.duration是否接近 195 秒，以及streams里视频和音频的codec_name是否分别为h264和aac。

这里想强调一点：做视频处理时，“先检查再用”是好习惯。不要切割完就直接拿去做合成，否则可能到合成阶段才发现前面已经做错了。

5.4 拆条阶段常踩的坑

一个是时间点确认错误。很多站点播放器显示的时间轴和实际时间可能差几秒，建议用播放器精确暂停后记时间，或者先用 FFprobe 获取总时长来评估。

另一个是源视频本身有帧率不稳的问题，导致切割后播放卡顿。出现这种情况时，可以尝试把片段统一转成固定帧率：

ffmpeg -i source.mkv -ss 00:02:30 -t 00:03:15 -vf "fps=30" -c:v libx264 -c:a aac clip01.mp4

加fps=30会把输出视频强制为 30 帧每秒，代价是部分帧会重复或丢弃，但能换来播放稳定。对于 Reaction 这种语言节目为主的内容，30 帧完全够用。

6. 用 OBS 录制 Reaction，再用 FFmpeg 合成画中画

6.1 OBS 的录制流程

打开 OBS 后，建立一个场景，添加两个来源：

1. 显示器采集或窗口采集：用来抓取正在播放素材的视频窗口。
2. 视频采集设备：用来捕捉摄像头画面。

布局方面，把素材窗口铺满画布，摄像头画面缩小后放在角落，常见位置是右下角。

录制前检查红色按钮旁边的“设置”，确保视频分辨率和帧率符合目标。建议录像分辨率设置为 1920x1080，帧率 30。如果电脑性能不够，可以降到 1280x720，30 帧。

点“开始录制”时，先确认画面里素材声音和麦克风声音都能录进去。你可以正常说话几句，然后停止录制，用播放器回放检查。这一步看似浪费时间，却能避免录完一整期才发现没有声音。

6.2 为什么录制阶段要保存原始素材

OBS 录出来的是一段包含了“素材画面 + 摄像头画面 + 合流音频”的单一视频。如果直接把这个文件上传，也不是不行。但更专业的做法是：

• 录一个“包含全部画面”的总文件，用于工作备份。
• 同时保留用于合成的主素材片段，方便后期重新调整画中画大小和位置。

因为画中画的最终位置、大小、透明度，在后期用 FFmpeg 合成时是可以随时改的。如果你让 OBS 直接录出最终画面，之后想调整摄像头位置，就只能重录。

所以，对于正式的 Reaction，推荐流程是：

1. 用 OBS 录制“电脑全屏画面 + 摄像头 + 麦克风”的原始反应视频。
2. 再用 FFmpeg 把原始片段作为主画面、摄像头视频作为画中画，合成最终成片。

6.3 用 FFmpeg 合成画中画

假设我们有两个文件：

• reaction.mp4：OBS 录制的原始反应视频，里面包含电脑画面和摄像头画面。
• clip01.mp4：之前拆条出来的原始素材片段。

我们希望最终画面以clip01.mp4为主画面，把reaction.mp4里的摄像头画面叠加到右下角。但这里有一个问题：reaction.mp4是已经合成过的画面，包含整个 OBS 场景，我们不能直接把整个文件再叠上去，否则会覆盖主画面。

正确的做法是在录制时，用 OBS 单独把摄像头输出成另一段视频，或者录制两轨。如果你的 OBS 配置支持同时录制多个源，那么在 OBS 里的场景可以有两种方案：

方案一：单独录制摄像头画面。 在 OBS 中添加一个单独的“视频采集设备”源并输出为独立文件。不同版本 OBS 的配置方式有差异，有的需要插件实现多轨录制。你可以先确认自己的 OBS 版本是否支持多轨视频输出。

方案二：把摄像头画面从 OBS 录制的完整画面中截取出来。 假设摄像头画面在 OBS 场景中位于画面右下角，大小约为 360x360，录制时摄像头区域相对于画布的位置是 (1500, 660)，那么可以先用 FFmpeg 裁出这个区域：

ffmpeg -i reaction.mp4 -vf "crop=360:360:1500:660" camera_cut.mp4

再通过overlay滤镜把camera_cut.mp4叠加到clip01.mp4上：

ffmpeg -i clip01.mp4 -i camera_cut.mp4 \ -filter_complex "[1:v]scale=360:360[ca];[0:v][ca]overlay=W-w-20:H-h-20:shortest=1[v]" \ -map "[v]" -map 0:a -c:v libx264 -c:a aac -shortest output.mp4

命令拆解：

• [1:v]scale=360:360[ca]：把第二路输入的视频缩放到 360x360，避免摄像头画面过大。
• [0:v][ca]overlay=W-w-20:H-h-20:shortest=1[v]：把缩放后的摄像头画面叠加到主画面右下角，距离边缘 20 像素。shortest=1表示按较短的视频结束。
• -map "[v]"：输出合成后的视频轨。
• -map 0:a：保留第一个输入文件的音频，也就是clip01.mp4的原片声音。
• -shortest：输出长度以最短流为准，防止摄像头画面结束后视频还在空转。

这个命令在录制阶段已经完成了 OBS 整套画面合并的前提下，仍然可以通过裁剪和叠加实现二次合成，灵活度更高。

6.4 音频处理的选择

Reaction 成片里通常有两种声音：原片声音和创作者说话声音。用 FFmpeg 合成时，最简单的方案是直接保留 OBS 录制时的混合音频，然后再-map 0:a取用。

如果你想调整两种声音的比例，需要 OBS 录制时开启多音轨，然后在 FFmpeg 里用 amix 或 sidechaincompress。这类操作复杂一点，但结果会专业很多。推荐先用单音轨跑通，后续再优化音量平衡。

6.5 合成后的验证

用 FFprobe 检查输出文件：

ffprobe -v quiet -print_format json -show_streams output.mp4

确认有两个流：一个是视频，一个是音频。然后播放一遍，重点观察：

• 画面切换是否流畅。
• 说话声音和口型是否对上。
• 右下角摄像头画面有没有被裁掉关键部分。

如果发现音画不同步，说明录制时 OBS 的画面帧率不均匀，或者合成时的时间戳有问题。在还没进入切片阶段前，回炉重录的成本最低。

7. 把成片切片成 HLS，用 H5 播放器做点播页

7.1 为什么不用单个 MP4 直接播放

单个 MP4 文件在浏览器里也能播放，但存在几个问题：

• 文件很大，用户打开页面时即使带宽足够，进度条拖动也可能需要重新加载大段数据。
• 没有多码率自适应，手机上网络波动时会卡。
• 如果视频放在对象存储或 CDN 上，单个大文件更容易产生回源压力。

切片成 HLS 后，播放器会按需加载 6 到 10 秒的分片，拖动进度时只请求对应片段，体验明显更好。

7.2 FFmpeg 生成 HLS 分片

以output.mp4为例，生成 HLS：

ffmpeg -i output.mp4 \ -codec:v libx264 -codec:a aac \ -hls_time 10 \ -hls_list_size 0 \ -hls_segment_filename "stream_%03d.ts" \ playlist.m3u8

参数解释：

• -hls_time 10：每个分片时长约 10 秒。
• -hls_list_size 0：索引文件里保留所有分片，不限制数量。
• -hls_segment_filename "stream_%03d.ts"：分片文件名按照 stream_001.ts、stream_002.ts 这样递增。
• playlist.m3u8：生成的索引文件名，里面记录了分片地址和时长。

执行后，目录里会出现一个playlist.m3u8和多个stream_xxx.ts文件。把它们放到同一个静态目录下即可。

7.3 创建点播播放器页面

写一个最简单的 HTML 页面，使用 Video.js 播放 HLS：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>点播 Reaction 在线观看</title> <link href="https://cdn.jsdelivr.net/npm/video.js@7/dist/video-js.min.css" rel="stylesheet"> <script src="https://cdn.jsdelivr.net/npm/video.js@7/dist/video.min.js"></script> </head> <body> <div style="max-width: 960px; margin: 40px auto;"> <h1>点播 Reaction 示例</h1> <video id="my-player" class="video-js vjs-default-skin vjs-16-9" controls preload="auto" width="960" height="540" >python3 -m http.server 8080

然后访问http://localhost:8080/就能播放。如果使用 nginx 部署，需要确保.m3u8和.ts文件能正常返回，可以在 nginx 配置的 server 块中添加：

location ~ \.(m3u8|ts)$ { add_header Cache-Control "no-cache"; }

no-cache是为了避免更新分片后浏览器继续使用旧缓存。

7.5 点播页面的工程化扩展

上面只是一个最小示例。在实际项目中，你还需要考虑：

• 将播放器封装成一个可复用的组件，传不同的 m3u8 地址和标题即可生成新页面。
• 用对象存储存放分片，通过 CDN 加速。
• 用数据库记录视频列表，后台动态生成播放页面，而不是每次手动改 HTML。

这些扩展会在最佳实践章节再展开。

8. 进阶：多人同步观看 Reaction 的简单实现

8.1 场景与需求

如果你希望让多个观众“同时”看一期 Reaction，并且能看到彼此的播放进度，就需要一个同步服务。常见需求是：

• 一个人点击播放，所有参与者同步开始。
• 一个人暂停或拖动进度条，其他端也跟随变化。
• 新加入的观众能快速跳到当前播放位置。

这个需求的核心不是说把播放器做得更复杂，而是引入一个中心状态同步器。

8.2 服务端实现

用 Node.js 和ws库实现一个简单的 WebSocket 服务：

// server.js const { WebSocketServer } = require('ws'); const wss = new WebSocketServer({ port: 8080 }); let clients = []; const state = { videoUrl: 'playlist.m3u8', currentTime: 0, isPlaying: false }; wss.on('connection', (ws) => { clients.push(ws); // 新连接建立后，立即把当前状态发给它 ws.send(JSON.stringify({ type: 'sync', state })); ws.on('message', (message) => { let data; try { data = JSON.parse(message.toString()); } catch (err) { return; } if (data.type === 'sync') { Object.assign(state, data.state); // 广播给其他客户端 clients.forEach((client) => { if (client.readyState === ws.OPEN && client !== ws) { client.send(JSON.stringify({ type: 'sync', state })); } }); } }); ws.on('close', () => { clients = clients.filter((client) => client !== ws); }); }); console.log('Sync server running at ws://localhost:8080');

启动服务：

npm init -y npm install ws node server.js

8.3 前端接入同步逻辑

在播放器页面中，加入 WebSocket 连接，并根据服务端状态控制播放器：

const ws = new WebSocket('ws://localhost:8080'); const player = videojs('my-player'); ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'sync') { const state = data.state; const diff = Math.abs(player.currentTime() - state.currentTime); // 如果当前进度差异超过 2 秒，则跳转到同步进度，避免频繁打扰 if (diff > 2) { player.currentTime(state.currentTime); } if (state.isPlaying && player.paused()) { player.play(); } else if (!state.isPlaying && !player.paused()) { player.pause(); } } }; function sendState() { ws.send(JSON.stringify({ type: 'sync', state: { videoUrl: 'playlist.m3u8', currentTime: player.currentTime(), isPlaying: !player.paused() } })); } player.on('play', sendState); player.on('pause', sendState); player.on('seeked', sendState);

这个方案的核心思想是：播放器本身不直接控制其他端，而是把状态发给服务端，服务端再广播给所有连接者。

8.4 同步方案的误差与局限

WebSocket 同步本质上是有延迟的，网络抖动、浏览器渲染差异都会造成误差。上面的代码用 diff 大于 2 秒才跳转，就是为了避免频繁校准造成的播放卡顿。

对于纯点播 Reaction 来说，2 秒以内的误差不影响观看。如果要进一步优化，可以在服务端记录更精确的“播放进度 + 服务器时间戳”，客户端用网络延迟估算来修正。但这一步比较复杂，一般场景没有必要。

另外要注意，这种方案适合小规模观众群，几百人同时在线的压力下，单 WebSocket 节点会面临连接数上限问题，需要引入消息队列或分布式状态同步。这里不做展开，但你要知道它是一个横向扩展的边界。

9. 常见问题与排查方法

10. 最佳实践与工程建议

10.1 素材版权与授权边界

做点播 Reaction 时，素材版权往往是最容易被忽略的环节。老综艺片段、影视短剧、其他创作者的作品，都可能受版权保护。即使只是“放一段然后自己评论”，也不代表可以任意传播和商用。

更稳妥的做法是：

• 优先使用平台提供的二次创作授权范围。
• 在视频简介中注明素材出处。
• 不要直接导出原始素材作为单独文件供人下载。
• 遇到版权投诉时积极配合平台流程处理。

这篇文章只讨论制作技术，不代表对版权的建议就是完全答案。遇到具体素材，建议认真阅读平台规范和相关法律法规。

10.2 文件命名与目录规范

随着成片数量增加，文件管理会变成隐形负担。建议按“日期-主题-版本”命名：

20250125_beyond_reaction_clip01.mp4 20250125_beyond_reaction_camera.mkv 20250125_beyond_reaction_output_v1.mp4 20250125_beyond_reaction_output_v2.mp4

目录结构可以按“工程”组织：

project/ source/ 原始素材，不修改 clips/ 拆条后的片段 recordings/ OBS 录制原始文件 work/ 中间文件 output/ 最终成片 publish/ HLS 分片和播放页面

这个目录结构的好处是：任何文件出错时，你能快速定位到它是哪个阶段产生的，也知道该从哪里重新开始。很多制作事故之所以耗时，就是因为文件全堆在一个目录里，根本不知道哪个是原始素材、哪个是处理过的。

10.3 录制参数与编码策略

• 录制阶段优先保稳定，不要追求过高的画质。1080p 30 帧基本够用，如果电脑性能有限，720p 30 帧也行。
• OBS 录像格式建议选 MKV，因为 MKV 在录制中途断电时更容易恢复，而 MP4 可能直接损坏。
• 合成阶段用libx264，-crf 23是一个画质和体积比较平衡的起点。如果发现体积太大，可以把 crf 改为 24 或 25。
• 切片阶段的关键帧间隔要和分片时长匹配。-g 60表示每 60 帧一个关键帧，在 30 帧每秒下就是每 2 秒一个关键帧，适合配合 6 到 10 秒的分片。

10.4 日志与验证习惯

视频处理是计算密集型的操作，一次转码可能运行几分钟。不要在命令行跑完后想当然认为成功，一定要用ffprobe检查输出。可以把验证命令写成一个脚本：

#!/bin/bash ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 "$1"

这个脚本只输出文件时长。如果时长是 0，说明文件损坏；如果时长远小于预期，说明命令执行时提前结束了，需要查看日志。

10.5 发布与缓存

HLS 部署到静态服务器或对象存储后，要注意 CDN 缓存策略。分片文件通常是不可变的，可以设置为长期缓存；playlist.m3u8索引文件会更新，建议设置为较短缓存或不缓存，避免用户看到旧列表。

# 以 AWS S3 + CloudFront 为例 aws s3 sync ./publish/ s3://your-bucket/publish/ \ --exclude "*.m3u8" \ --cache-control "public, max-age=86400" aws s3 cp ./publish/playlist.m3u8 s3://your-bucket/publish/playlist.m3u8 \ --cache-control "no-cache"

这个实践能让你在更新成片后，观众很快看到新内容，而不是因为旧缓存反复清空页面。

11. 总结与后续学习方向

这篇文章从一个“点播 Reaction”的选题出发，实际上拆解的是完整的视频点播生产链路：拆条、录制、合成、转码、切片、前端播放、状态同步和发布部署。这套流程不只是 Reaction 视频能用，任何需要“二创剪辑 + 在线点播”的内容都可以复用。

如果你刚接触这块，建议不要一开始就追求自动化。先手工做完两期，体会一遍所有步骤，尤其是搞清楚 OBS 多音轨录制、FFmpeg 滤镜参数、HLS 分片结构这三个关键点。手工跑通后，你自然知道哪一步最耗时、哪一步最需要脚本化。

后续可以深入的方向有几个：一是把发布流程接到 CI/CD 上，代码提交后自动转码并同步到对象存储；二是学习多码率自适应，使用 HLS 的 master playlist 为不同网络条件提供不同清晰度；三是把同步观看扩展成更完整的房间机制，让用户输入房间号即可加入一次点播活动。

最后提醒一句：无论技术链路搭得多顺，都要预留“人工确认”环节。视频版权、字幕错漏、合成效果，这些是机器检查不完整的。在做大量自动化之前，先确保一手内容的质量稳定。