企业官网建设流程全解析

直播回放最容易被低估的地方，是它看起来只需要把直播过程录下来。观众真正需要的，却是一套完整、可检索、可跳转、可长期保存的回放链路。一场从晚上持续到凌晨的多人游戏直播，可能包含了不同玩家视角、不同游戏模式，甚至中间还有临场节目效果；直播结束后，真正决定观众体验的，是回放能不能稳定复现每一个细节，并且想跳到哪里就跳到哪里。接下来不讨论具体某场直播的内容，而是把直播回放背后的录制、转码、切片、索引和播放链路拆开来讲，并给出可复现的最小实现。

1. 直播回放到底在解决什么问题

1.1 观众要的是“完整可回看”，不只是“录下来”

从观众视角看，回放需求非常朴素：直播结束之后，我想把没看到的团战重新看一遍，想从第三局跳到第四局，想在手机上不卡顿地拖动进度条。这些需求放在一句话里是“我要看回放”，但落到工程上却涉及几个完全不同的能力：

• 录制能力：直播画面是否被完整保留，断流后能不能自动接上。
• 转码能力：原始流是否能转成浏览器和移动端都能稳定播放的格式。
• 分片能力：长时间回放能不能被切成多个小文件，方便拖动进度和按需加载。
• 索引能力：观众怎么找到这一场回放，怎么知道这是三排、单排还是随机模式。
• 播放能力：网页端加载回放后的起播速度、拖动流畅度和清晰度。

把“录下来”当成回放的全部，是很多小型项目最常见的误区。直播流是实时连续流，它没有标题、没有封面、没有标签、没有开始结束时间的统一管理；而回放本质上是“点播 + 元数据”的组合体。直播流只是一份连续的媒体数据，只有给它加上转码、切片、落库和检索能力，它才变成观众习惯使用的“回放”。

1.2 从推流到回放的技术链路概览

一条完整的回放链路可以分成六个环节。

一个最小可用的回放系统，至少要把前四个环节跑通，后两个环节决定回放好不好用。很多直播平台只提供“最近一场回放”的简单地址，就是因为元数据环节没有做透，导致观众只能看，不能按标签、按时间、按玩家找到回放。

1.3 为什么不能把直播流直接当回放

直播流和点播文件对媒体格式的要求不同。直播推流为了降低延迟，通常会按一个较小的时间窗口向外分发数据，播放器不会去请求“第 10 分钟的第 3 秒”这种绝对位置，因为直播流的绝对时间本来就不重要。

回放则相反。观众拖动进度条时，播放器必须能快速找到对应的关键帧和分片。如果直接把直播录制文件改名成 mp4 或 m3u8，会遇到几个典型问题：

• 起播慢：播放器不知道关键帧位置，只能从头读到目标时间。
• 拖动不准：快进后画面可能长时间停留在上一个关键帧附近。
• 兼容性差：直播录制格式可能是 FLV，浏览器默认不支持直接播放。
• 无法管理：没有标题、标签、开始时间、结束时间，观众在列表里看到的是无意义文件名。

因此，回放系统的核心工作之一，是把“直播过程中产生的流媒体数据”转成“可点播的媒体资产”。下面从录制端开始，逐步搭建这条链路。

2. 回放管线第一步：直播录制与推流准备

2.1 录制端方案选型

录制直播画面有三类常见方案，适合不同场景。

如果回放素材要用于剪辑、二次分发或长期存档，推荐服务端录制。把录制能力放到服务端之后，主播端只要专注推流，即使主播掉线，服务端也可以把已收到的流保留下来。

2.2 用 SRS 接收推流并开启录制

SRS 是一个常见的开源流媒体服务器，支持 RTMP 接入，也可以直接开启录制功能。下面是一个最小配置示例，用于说明录制参数的含义，落地前需要根据 SRS 版本调整具体字段。

listen 1935; max_connections 1000; daemon off; srs_log_tank console; http_api { enabled on; } http_server { enabled on; listen 1985; } vhost __defaultVhost__ { http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } dvr { enabled on; dvr_plan session; dvr_path /data/record/[app]/[stream]/[2006-01-02]/[15-04-05].flv; dvr_duration 3600; dvr_wait_keyframe on; } }

这里的几个参数需要重点理解：

• dvr_plan session：按会话录制，每次推流连接生成一个录制文件。直播过程中断流重连会生成新文件，便于按时间段区分。
• dvr_path：录制文件的存放路径，[2006-01-02]和[15-04-05]是 Go 语言风格的时间模板，实际渲染出来是日期和时分秒。这样同一个推流名下的录制文件不会互相覆盖。
• dvr_duration 3600：单个文件最长录制 3600 秒，防止长时间直播产生超大文件。
• dvr_wait_keyframe on：等到下一个关键帧再开始写入，避免文件开头没有关键帧，后面转码时起播困难。

2.3 推流命令与 OBS 设置

服务端配置好之后，需要在主播端把画面推向 SRS。最直接的方式是 OBS 推流，推流地址填rtmp://127.0.0.1:1935/live，串流密钥填player1这样的房间标识。

也可以使用 FFmpeg 模拟推流，方便在本地测试整条链路。示例命令如下：

ffmpeg -re -i game_input.mkv \ -c:v libx264 -preset veryfast -tune zerolatency \ -b:v 4500k -maxrate 4500k -bufsize 9000k \ -g 60 -keyint_min 60 \ -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/player1

命令里的参数直接决定了回放质量：

• -g 60：每 60 帧一个关键帧。如果源视频是 30fps，那么关键帧间隔是 2 秒。
• -keyint_min 60：关键帧最小间隔也是 60 帧，防止编码器在画面静止时主动插入过密关键帧，产生无谓码率浪费。
• -tune zerolatency：降低编码延迟，适合直播场景。
• -b:v 4500k -maxrate 4500k -bufsize 9000k：平均码率 4500kbps，画质波动时最高不超过 4500kbps。
• -preset veryfast：牺牲一部分压缩率换取编码速度，避免推流端 CPU 过高。

在 OBS 中也要把“关键帧间隔”设置为 2 秒。这个设置容易被忽略，但它直接影响回放起播速度和拖动准确度。如果推流端关键帧间隔是 10 秒，回放播放器想跳到第 30 秒时，可能需要等接近 10 秒才能找到真正能解码的画面。

2.4 常见坑：断流重连和文件命名

录制环节有两个高频问题。

第一个问题是断流后不自动重连。OBS 可以在网络断开后自动重试，但 FFmpeg 模拟推流时需要手动处理。可以写一个简单的循环脚本：

while true; do ffmpeg -re -i game_input.mkv \ -c:v libx264 -preset veryfast -b:v 4500k \ -g 60 -keyint_min 60 \ -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/player1 echo "push failed, retry in 3s" sleep 3 done

这里要注意，断流期间没有画面，重连后生成的是一个新会话文件，后期需要根据时间戳把多个文件拼起来，或者干脆在上层用元数据表记录“这一场回放包含哪几个文件”。

第二个问题是文件命名。如果录制路径只写到[stream].flv，下一场直播会覆盖上一场文件。按“日期 + 时分秒”命名是最低要求，更稳妥的方式是在文件名中带上房间、模式、玩家标识，例如player1_triple_20240512_200000.flv。这样即使后面要批量迁移、批量转码，也能通过文件名快速判断内容来源。

3. 回放管线第二步：用 FFmpeg 将录制流转码成可回放格式

3.1 为什么需要转码而不是直接改名

录下来的文件通常是 FLV，FLV 是流式封装格式，适合直播分发，但不适合点播回放。直接播放 FLV 时存在三个问题：

• 浏览器原生支持差，需要额外引入 flv.js。
• FLV 文件内部时间戳可能不连续，拖动进度条时定位逻辑复杂。
• 长时间录制的 FLV 可能缺少供点播使用的索引信息，打开文件时需要从头扫描。

转码的核心目的不是改变画面，而是把流式封装转成点播友好的格式，同时按需要调整编码参数、关键帧分布和音频规格。

3.2 HLS 与 MP4 选型

回放格式最常纠结的是 HLS 和 MP4，两者适用场景不同。

如果是一场长达两三个小时的游戏直播回放，优先用 HLS。单文件 MP4 在几小时的场景下体积很大，中途拖动时浏览器需要加载大量元数据，起播和跳转体验都不好。

如果回放还要用于剪辑或让观众下载，再额外导出一份 MP4。

3.3 FFmpeg 转码命令详解

假设 SRS 已经录好了一个 FLV 文件，路径为/data/record/live/player1/2024-05-12/20-00-00.flv。转成 HLS 的命令如下：

ffmpeg -i /data/record/live/player1/2024-05-12/20-00-00.flv \ -c:v libx264 -preset veryfast -crf 23 \ -c:a aac -b:a 128k \ -hls_time 6 \ -hls_list_size 0 \ -hls_segment_filename '/data/hls/player1-%05d.ts' \ -f hls /data/hls/player1.m3u8

参数含义：

• -crf 23：控制画质，数值越小画质越高，文件越大。常见的 19 到 23 都是合理区间。
• -hls_time 6：每个分片时长约 6 秒。
• -hls_list_size 0：将全部分片写入 m3u8 文件。如果不设为 0，默认只保留最近若干分片，适合直播，不适合回放。
• -hls_segment_filename：分片文件的命名模板，%05d表示五位序号。

如果需要导出 MP4，可以转封装而不是重新编码：

ffmpeg -i input.flv \ -c:v copy -c:a copy \ -movflags +faststart \ output.mp4

-c:v copy -c:a copy表示不重新编码，速度快；-movflags +faststart会把 MP4 的索引信息移到文件头部，这样网页播放器不用下载完整文件就能开始播放。这里要注意，如果 FLV 源文件本身编码参数有问题，重新编码能修复一部分问题，而-c:v copy无法修复。

3.4 切片时长和关键帧对齐

HLS 切片时长不能随便设置，它必须和视频关键帧对齐。播放器要播放一个分片，必须从关键帧开始解码。如果切片点落在关键帧中间，播放器就会出现起播黑屏、花屏或卡顿。

推荐的做法是让切片时长是关键帧间隔的整数倍。

上表只是参考，实际要以推流端-g参数为准。如果推流端关键帧间隔是 2 秒，那么-hls_time 6的切片通常能落在关键帧附近，FFmpeg 会自动对齐到关键帧位置。

注意：修改推流端关键帧设置后，需要重新连一次推流，因为编码器关键帧参数在推流连接建立时已经确定。只改服务端切片时长，无法修正推流端不合理的 GOP 设置。

4. 回放管线第三步：回放记录与检索

4.1 为什么回放需要元数据表

转码完成之后，文件已经存在于磁盘上，m3u8 地址也可以访问。但观众不会直接输入一个 m3u8 地址。观众看到的是回放列表，列表里要显示标题、主播、模式、时长、开始时间。

如果只靠文件名管理，回放数据会迅速失控。文件player1-00001.ts无法告诉观众这是哪一场三排，也无法说明这是一场随机模式还是一场娱乐局。因此需要一张元数据表，把“文件世界”和“业务世界”连接起来。

4.2 回放表设计

一张最小可用的回放表如下：

CREATE TABLE replay ( id BIGINT PRIMARY KEY AUTO_INCREMENT, room_id VARCHAR(64) NOT NULL, streamer_name VARCHAR(64) NOT NULL, replay_title VARCHAR(255) NOT NULL, start_time DATETIME NOT NULL, end_time DATETIME NOT NULL, duration_seconds INT NOT NULL, mode_tag VARCHAR(32), category VARCHAR(64), source_file_path VARCHAR(512) NOT NULL, hls_url VARCHAR(512), file_size_bytes BIGINT, status TINYINT NOT NULL DEFAULT 0, created_at DATETIME NOT NULL, KEY idx_room_start (room_id, start_time), KEY idx_mode (mode_tag) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

字段设计要点：

• room_id和streamer_name分开存，房间是稳定的技术标识，主播名称可能变更。
• mode_tag存“三排”“单排”“随机模式”“娱乐局”这类模式标签。
• category存内容分类，例如“游戏”“闲聊”“赛事”。
• status存回放处理状态，例如 0 表示录制完成待转码，1 表示转码完成，2 表示发布失败。
• idx_room_start、idx_mode分别支撑“按房间查最近回放”和“按模式筛选回放”两类高频查询。

4.3 模式标签怎么落到数据模型

模式标签看起来只是一个字段，但设计时要考虑后续扩展。最小场景下，一张表加一个mode_tag字段就够了。如果回放系统要支持多个标签，比如一场回放既是“三排”又属于“搞笑集锦”，就需要引入标签表和关联表。

CREATE TABLE replay_tag ( id BIGINT PRIMARY KEY AUTO_INCREMENT, tag_name VARCHAR(32) NOT NULL UNIQUE ); CREATE TABLE replay_tag_rel ( replay_id BIGINT NOT NULL, tag_id BIGINT NOT NULL, PRIMARY KEY (replay_id, tag_id) );

从最小实现起步时，先用单个mode_tag字段跑通流程。上线后如果运营需要多维标签，再拆分标签表，避免一开始就过度设计。

回放列表接口返回的 JSON 示例：

{ "code": 0, "data": { "list": [ { "replayId": 10086, "title": "三排回放", "streamerName": "player1", "mode": "triple", "startTime": "2024-05-12 20:00:00", "durationSeconds": 7200, "hlsUrl": "https://cdn.example.com/replay/player1.m3u8", "status": 1 } ], "total": 1 } }

4.4 把录制文件迁到对象存储

本地磁盘不适合无限保存回放。长时间直播的分片数量很大，磁盘会持续增长。常规做法是把已经转码完成的 HLS 分片和旧回放迁移到对象存储，本地只保留最近几天的热数据。

MinIO 是常见的自建对象存储方案，迁移命令可以使用 mc：

mc mirror --overwrite /data/hls/ minio/replay/player1/

迁移完成后，要把数据库里的hls_url更新为对象存储的地址，并校验文件对象数量和 m3u8 列表中分片数量一致。

注意：先更新数据库再删本地文件。如果数据库记录已经指向本地路径而本地文件被清理，回放会变成“有记录无内容”，这类数据是最难排查的。

5. 回放播放页与前端接入

5.1 用 hls.js 播放 HLS

桌面浏览器大多不支持原生 HLS 播放，需要借助 hls.js。一个最小播放器页面如下：

<video id="player" controls muted></video> <script src="https://cdn.jsdelivr.net/npm/hls.js@1"></script> <script> const video = document.getElementById('player'); const url = 'https://cdn.example.com/replay/player1.m3u8'; if (Hls.isSupported()) { const hls = new Hls({ maxBufferLength: 30 }); hls.loadSource(url); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () => { video.play(); }); } else if (video.canPlayType('application/vnd.apple.mpegurl')) { video.src = url; } </script>

maxBufferLength: 30表示播放器最多缓冲 30 秒数据。这个值不是越大越好：缓冲区太长会占用带宽，切换清晰度时延迟更大；太小则容易在弱网下卡顿。

MANIFEST_PARSED事件表示 m3u8 已经解析完成，可以调用播放。如果用户刷新页面后希望自动续播，不能在这个事件里无条件调用play()，否则需要先处理浏览器的自动播放策略。

5.2 从元数据跳转到指定时间点

回放列表页经常需要支持“从第 30 分钟开始看”。最简单的实现是在播放页 URL 中带startTime参数，播放器初始化后设置currentTime。

const params = new URLSearchParams(location.search); const start = Number(params.get('startTime')) || 0; if (Hls.isSupported()) { const hls = new Hls({ maxBufferLength: 30 }); hls.loadSource(url); hls.attachMedia(video); hls.on(Hls.Events.MANIFEST_PARSED, () => { if (start > 0) { video.currentTime = start; } video.play(); }); }

这里有一个实际项目容易遇到的问题：currentTime跳转后，播放器可能因为带宽不足而长时间卡顿。生产环境建议在跳转前判断目标分片是否已经加载，或者等待播放器的SEEKED事件后再播放，避免用户点击后画面长时间不动。

5.3 多清晰度切换的思路

如果想提供 720p 和 360p 两档清晰度，可以在转码时分别生成两条 m3u8，再用一个 master m3u8 把它们组合起来：

#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720 720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360 360p.m3u8

hls.js 加载 master m3u8 后，会依据网络带宽自动选择合适清晰度。多清晰度转码比单清晰度多两件事：一是要用不同码率多次执行 FFmpeg 转码，二是要保证不同清晰度之间的切片数量和关键帧位置基本一致，否则切换时可能出现进度跳变。

单机测试阶段可以先不做多清晰度，先用单码率把整条链路跑通，再逐步增加。

6. 常见问题与排查链路

6.1 音画不同步

现象：回放播放到中后段，声音和画面出现偏移，时间越长偏离越明显。

可能原因：

• 推流端采集的音频采样率和视频帧率配置不匹配。
• 转码时没有指定音频时间基准，FFmpeg 按默认值处理。
• HLS 分片时长不一致，播放器在跨分片时积累误差。

检查方式：

ffprobe -v error -show_entries stream=index,codec_type,time_base,start_time \ -of json /data/hls/player1.m3u8

如果视频流的time_base和音频流不一致，或者视频流起始时间不是 0，就可能出现不同步。

处理建议：

• 推流端统一使用 44.1kHz 或 48kHz 音频，并在 FFmpeg 推流命令中显式指定-ar 44100。
• 录制转码时不要对音频使用过于复杂的滤镜，避免重采样带来的时间偏移。
• 长时间回放建议每 4 到 6 小时为一个录制会话，发现不同步时只处理对应时段，避免整段作废。

6.2 播放到一半中断或切片缺失

现象：进度条可以拖动，但拖到某个时间点后一直转圈，无法继续播放。或者只播放了前两分钟就停止。

可能原因：

• m3u8 中引用的分片文件被删除或未生成。
• 转码进程被中断，只生成了部分分片。
• 对象存储迁移时部分分片上传失败，但 m3u8 还是旧路径。

检查顺序：

cat /data/hls/player1.m3u8 ls -l /data/hls/player1-*.ts ffprobe -v error -show_format /data/hls/player1.m3u8

第一步看 m3u8 中引用了几个分片，第二步看实际分片文件是否存在，第三步确认分片文件能否被解码。如果 m3u8 有 100 个分片但磁盘只有 99 个，说明上传或转码过程中有缺失。

处理建议：

• 转码完成后用脚本校验分片数量，数量不一致则触发重新转码。
• 对象存储迁移后检查 m3u8 文件内容，确认地址已经指向新路径。
• 生产环境把“分片数量校验”放进发布流程，不允许校验失败的回放上架。

6.3 MP4 文件损坏或没有 moov

现象：把 FLV 转成 MP4 后，本地播放器打开报错，或者浏览器一直黑屏。

可能原因：

• 录制进程异常退出，源文件本身不完整。
• 转码时使用了-c:v copy，把源文件中的坏数据也复制了过去。
• MP4 的 moov 元数据在文件尾部，文件传输不完整时无法解析。

处理方式：

ffmpeg -i damaged.flv -c:v libx264 -c:a aac -movflags +faststart repaired.mp4

这里需要重新编码，不能使用-c:v copy。如果原始 FLV 损坏严重，先尝试用 FFmpeg 重新封装一遍，确认源文件能否被正常读取：

ffmpeg -i damaged.flv -c copy temp.flv

重新封装能解决一部分时间戳不连续的问题，但无法修复损坏的画面数据。生产环境的核心预防手段是录制阶段用 SRS 的dvr_wait_keyframe on和按会话切分文件，降低单文件损坏的影响面。

6.4 排查清单

7. 学习环境与生产环境的差距

7.1 本地快速验证

本地环境不需要完整的集群，一台机器就可以跑通全部链路：

1. 启动 SRS，开启录制。
2. 用 FFmpeg 推一条测试流：

   ffmpeg -re -f lavfi -i testsrc2=size=1280x720:rate=30 \ -f lavfi -i sine=frequency=440 \ -c:v libx264 -preset veryfast -g 60 -keyint_min 60 \ -c:a aac -b:a 128k \ -f flv rtmp://127.0.0.1:1935/live/test

3. 等待 SRS 生成 FLV 文件。
4. 用 FFmpeg 将 FLV 转成 HLS。
5. 用 hls.js 打开播放页面，观察起播、拖动和切换清晰度。

testsrc2是 FFmpeg 内置测试画面，sine是内置音频源，不需要准备真实游戏视频文件。这个验证方法适合确认参数是否正确，但无法替代真实推流压力和长时间稳定性测试。

7.2 生产环境的录制与回放架构建议

本地跑通后，生产环境还需要额外处理几个问题。

• 录制节点与转码节点分离：录制节点只需要接收流和写磁盘；转码节点负责 FFmpeg 任务，两者混在一起会互相影响。
• 磁盘监控：录制文件增长极快，必须监控磁盘使用率，超过阈值时自动迁移旧文件。
• 任务队列：转码任务建议通过消息队列分发，避免直接依赖 HTTP 回调，任务失败时能自动重试。
• 元数据一致性：数据库记录和实际文件必须一致。转码成功后先写库，再发布地址；发布地址后如果文件被误删，需要能通过异常检测发现。
• 回放地址加 CDN：长时间回放流量消耗大，HLS 分片通过 CDN 分发可以降低源站压力。

7.3 发布前检查清单

在把回放功能发布到线上前，建议逐项确认：

• [ ] 推流端关键帧间隔是否统一为 2 秒。
• [ ] SRS 录制路径是否包含日期和时分秒，避免文件覆盖。
• [ ] 转码命令是否需要区分高画质和低画质。
• [ ] HLS 分片是否已经生成，m3u8 分片数量是否完整。
• [ ] 数据库回放记录的主键、索引和模式标签是否就绪。
• [ ] HLS 地址是否可以通过公网访问。
• [ ] 对象存储迁移后是否校验了分片数量。
• [ ] 磁盘和录制进程是否纳入监控告警。
• [ ] 转码失败是否有重试机制，重试次数是否有上限。
• [ ] 回放页面是否支持从指定时间点开始播放。

8. 最佳实践与扩展方向

8.1 可复用最佳实践

从录制到播放，有五个建议值得在项目中落地。

第一，录制文件命名必须唯一。至少包含房间、日期、时间三个维度，推荐再加入模式前缀，避免后续迁移和转码时靠猜。

第二，HLS 切片时长设置为关键帧间隔的整数倍。这个原则能解决大部分起播黑屏和拖动不准的问题，成本却很低。

第三，回放地址等到元数据落库后再暴露。观众只能访问到发布完成的回放，避免出现“点击回放后频道不存在”的坏体验。

第四，长时间回放不要全部转成 MP4。HLS 负责播放，MP4 只作为导出和剪辑产物，否则浪费大量转码成本。

第五，文件状态和数据库状态要联动。删除文件前先确认数据库记录已经更新，迁移文件后要校验 m3u8 中的路径，不能只靠人工检查。

8.2 扩展方向

回放链路跑通后，可以继续向几个方向扩展。

• 精彩片段自动剪辑：检测音量峰值、转场画面或弹幕峰值，自动截取高光区间，形成集锦。
• 自动标题与标签：通过语音转文字提取关键词，结合游戏内事件自动生成回放标题。
• 多视角回放：在多人游戏场景中，把每个玩家的画面独立录制，回放时由观众选择视角。
• 回放热度分析：统计观众回看时长、拖动热点、重复观看片段，反过来指导直播内容规划。

对刚开始接触回放系统的开发者，最有价值的做法不是一开始就追求多码率、多视角和复杂标签体系，而是先把“推流 - 录制 - FFmpeg 转码 - HLS 切片 - hls.js 播放”这条最小链路完整跑通，再逐步加入数据库、对象存储、任务队列和监控告警。直播回放看起来是“录下来”，实际上是一条从流媒体到点播、从文件到业务的完整工程链路，把每一层拆开验证，才能在直播结束后给观众一个稳定可用的回放。