直播录像工程实践：从RTMP拉流到自动归档的完整方案

前几天整理直播内容归档时，我拿到一个看起来非常规范的文件名：李一恩直播录像-2026-08-13-晚上场.mp4。文件名本身没什么技术含量，但它背后其实藏着一整套值得较真的工程问题：这场直播是怎么录下来的？录制过程中断线了怎么办？为什么有时候录完的视频打不开？归档时怎么命名、怎么校验、怎么控制磁盘成本？

很多开发者的第一反应是：直播录像不就是用 OBS 录屏吗？这个判断在“录自己电脑屏幕”的场景下勉强成立，但只要你面对的是持续三四个小时的晚上场直播，或者要按日期批量归档、检索回放，就会发现它远不止一个“开始录制”按钮。直播录像本质是一条流媒体采集链路：从拉流协议、编码容器、断线重连，到文件切片、完整性校验、命名归档，每一环都可能翻车。

这篇文章我从工程视角把这条链路完整拆开。先讲清楚 RTMP、HLS、FLV 这些基础概念，再给出可落地的 FFmpeg、OBS 和 Python 自动化录制方案，最后整理常见故障排查和最佳实践。读完你可以独立搭建一套“主播/栏目-日期-场次”的自动录像归档小系统。

1. 直播录像是个工程问题，不是录屏问题

1.1 三个真实翻车场景

先看几个我见过很多次的场景，你可以对照一下自己有没有踩过类似的坑。

场景一：录到一半，文件损坏。有人用 OBS 直接把录像格式设成 MP4，录制一场晚上场直播，三个半小时后直播结束，点停止录制，软件提示“录像文件已损坏，无法播放”。原因是 OBS 在主进程异常退出或电源突然中断时，MP4 的索引信息没有来得及写入文件尾部，整个文件直接报废。如果直播没有回放，内容就等于永久丢失。

场景二：录屏把不该录的东西都录进去了。用 OBS 采集桌面或浏览器窗口来录别人的直播，系统通知、弹窗、输入法候选框、后台消息提醒全部入了画面；麦克风或者电脑播放声音串进来，音质也很差。更关键的是，屏幕录制的画面质量取决于缩放和编码设置，分辨率一旦没对齐，直播源本身很清晰，录出来却是模糊的。

场景三：录了一堆文件，命名全是“录制_001.mp4”。一场一场录完，文件堆在一个目录里，不打开看根本分不清哪个是哪个。等到要找某一天某一场的录像做剪辑，要花大量时间挨个播放预览。这就是典型的“录制完成、归档失败”。

这三个场景说明同一个问题：直播录像的难点不是“能不能录”，而是“能不能稳定录完、录完能不能用”。

1.2 直播录像的完整链路

如果把直播录像当成一个完整的数据流水线，大概是这个样子：

1. 获取流地址（自己直播的推流地址，或经授权的播放地址）。
2. 拉流（用 FFmpeg、OBS 或相关直播流工具从服务器拉取音视频数据）。
3. 容器封装（FLV、MKV、TS、MP4 等格式选择）。
4. 文件切分与断线重连（按时间分片，断流后自动恢复）。
5. 完整性校验（用 ffprobe 检查时长、流信息，用解码器扫描错误）。
6. 归档命名（主播/栏目-日期-场次，方便检索）。
7. 存储与备份（预留空间、保留策略、热备/冷备）。

这条链路里最容易翻车的是“容器封装 + 断流恢复”这一环，最容易被低估的是“命名和归档”这一环。前者决定内容能不能成功保存，后者决定内容能不能在需要时被找到。

2. 基础概念：推流、拉流与录制路线

2.1 RTMP、HLS、FLV 到底是什么

在写录制命令之前，必须先弄懂几个高频出现的协议词，否则你连 FFmpeg 的报错都看不懂。

推流（publish/ingest）：主播端把音视频数据持续发送到直播服务器。对大多数直播平台来说，推流端使用的依然是 RTMP 协议，推流地址形如rtmp://push.example.com/live/房间号。

拉流（play/pull）：观众端或录制端从服务器拉取音视频数据的过程。拉流可以有多种协议，常见的是 RTMP 和 HLS。

RTMP（Real-Time Messaging Protocol）：最早为 Flash 时代设计，基于 TCP 的实时消息协议。延迟低（1 到 3 秒量级），是直播推流的事实标准。录制端拉 RTMP 流时，数据通常以 FLV 容器承载。

HLS（HTTP Live Streaming）：苹果提出，基于 HTTP 的流媒体协议。它将直播流切成一个个小的 TS 分片文件，并通过 m3u8 索引文件维护播放列表。优点是能穿透常规 HTTP 网络环境、支持自适应码率，缺点是延迟较高（通常在 6 到 30 秒）。很多平台的“网页直播、回放地址”就是 HLS。

FLV / MKV / MP4 / TS：这些都是容器格式，负责把视频流、音频流、字幕、时间戳等打包在一起。容器本身不决定视频清晰度，只决定封装结构和兼容性。

下面用一个表格快速对比四种容器的录制特点：

新手最容易误解的地方是：MP4 是“最好的格式”，所以录制时直接存 MP4。实际上，直播录制过程中一旦断流或崩溃，MP4 文件很容易损坏。更稳妥的做法是先录成 MKV 或 FLV，正常结束后再转封装成 MP4。

2.2 三条录制路线：录屏、拉流、下载回放

选择原则很简单：能直接拉流，就不要先渲染屏幕再录屏。录屏是“我在现场看直播，顺便把它拍下来”；拉流是“我直接从源头上把数据拷一份”。后者清晰度高、资源占用小、更容易自动化。

3. 环境准备与前置条件

3.1 工具清单与安装

本文的实操环境不需要太复杂，核心是三样：

1. FFmpeg：拉流、转封装、校验都靠它。
2. OBS Studio：作为备选方案，适合录制本机画面。
3. Python 3：用来写自动归档脚本，调用 FFmpeg 完成任务。

FFmpeg 的安装方式因系统而异：

Ubuntu / Debian：

sudo apt update sudo apt install ffmpeg

macOS（使用 Homebrew）：

brew install ffmpeg

Windows：建议从 FFmpeg 官网下载静态构建版本，解压后把bin目录加入系统 PATH。

安装完成后验证版本：

ffmpeg -version

看到类似ffmpeg version ...的输出就说明安装成功。需要留意的是，不同发行版、不同构建版本的 FFmpeg 支持的功能略有差异，本文的命令都基于常规开源构建，不依赖付费扩展。

OBS Studio 可以从官网下载，支持 Windows、macOS、Linux，安装后无需额外配置即可开始录制。

3.2 磁盘空间估算

直播录像是典型的“写入密集型”任务，录之前必须先算清楚磁盘够不够。

估算公式非常朴素：

体积(GB) ≈ 码率(Mbps) × 时长(小时) × 0.45

这里 0.45 的来源是：1 Mbps 流一小时产生的数据量约为 450 MB（1,000,000 bit/s × 3600 s ÷ 8 ÷ 1024³，取近似值）。

注意，这个表算的是视频码率，实际还要加上音频码率（通常 128 kbps 到 320 kbps，三小时约多出 100 到 400 MB）。建议按估算值的 1.5 倍预留空间，避免直播延时、加播等意外情况把磁盘写满。

4. 核心流程拆解：从直播流到可回放视频

4.1 先确认授权，再拿流地址

开始写命令之前，必须先说清一个前提：你要录制的直播，必须是你自己拥有版权、或已经取得直播方明确授权的内容。

合法场景包括但不限于：

• 自己作为主播直播，录制自己的直播内容用于存档。
• 公司内部培训、技术分享会的直播，组织方授权录制。
• 公开的技术大会、发布会，主办方明确允许录制回放。
• 基于平台授权或官方回放功能进行合规保存。

未经授权录制他人直播并公开传播，可能涉及著作权侵权、平台规则违约，甚至隐私问题。不要在录制链路里私自添加“爬取未公开播放地址”“绕过平台限制”之类的操作。本文的所有技术方案，默认都建立在“有权限访问流地址”的前提下。

拿到流地址通常有两种方式：

• 如果是自己推流，平台会提供“推流地址 + 推流密钥”，例如rtmp://push.example.com/live/和一串密钥，两者拼接后就是完整推流地址。推流密钥相当于直播间的钥匙，不要泄露。
• 如果是经授权观看的直播，向直播方申请拉流播放地址，例如https://example.com/live/stream.m3u8。

4.2 用 ffprobe 探测流

不管流地址是 RTMP 还是 HLS，录制前先用 ffprobe 探测一下，确认这个地址确实有数据、有音视频流、编码格式是什么。

ffprobe -v error -show_streams -show_format "rtmp://push.example.com/live/room123"

如果探测成功，输出会包含视频流信息（编码格式 h264/hevc、分辨率、码率）和音频流信息（编码格式 aac/mp3、采样率）。如果输出里没有音频流，后面录制时就要注意，不要默认“一定会有声音”。

常见异常情况是画面正常但没有音频流，或者反过来只有音频没有视频流。提前探测可以避免录制完成后才发现录了个寂寞。

4.3 用 FFmpeg 拉流录制

FFmpeg 最简单的拉流录制命令如下：

ffmpeg -i "rtmp://push.example.com/live/room123" -c copy -f flv record.flv

逐项解释：

• -i：指定输入流地址。
• -c copy：流拷贝，不做转码，直接把源流的视频和音频数据“搬运”到文件里。这是录制直播的首选，CPU 占用低，画质零损失。
• -f flv：指定输出容器为 FLV。RTMP 拉下来的流本身是 FLV 结构，直接封装成 FLV 最稳，断流后文件也更容易恢复。

如果源是 HLS 地址，录制命令稍有不同：

ffmpeg -i "https://example.com/live/stream.m3u8" -c copy -bsf:a aac_adtstoasc -f mp4 output.mp4

这里多了一个-bsf:a aac_adtstoasc。原因是 HLS 的 TS 分片里，AAC 音频是以 ADTS 格式存储的，转封装进 MP4 时必须转成 ASC 格式，否则音频播放会出问题。这是 HLS 转 MP4 最常见的坑之一。

4.4 断线自动重连与分段

直播录制的最大敌人不是“清晰度”，而是“断流”。

直播过程中，主播端网络抖动、服务器切换、推流中断，都会导致 FFmpeg 录制进程直接退出。如果人不在电脑前盯守，可能录到一半就停了，剩下全是空白。

解决思路有两个：断线重连和分段录制。

断线重连的循环脚本思路是：不断用 FFmpeg 尝试录制，如果进程退出，等几秒重试。分段录制则是把长时间直播切分成小时级文件，降低单文件损坏的风险。

for i in $(seq 1 50); do ffmpeg -i "rtmp://push.example.com/live/room123" \ -c copy \ -f mkv "record_part_$(date +%Y%m%d_%H%M%S).mkv" echo "录制中断，5 秒后重连..." sleep 5 done

这个脚本足够做演示，但真实生产环境里，我更推荐用 Python 或 Shell 增强控制逻辑，加入日志、流探测、文件命名规范，这些在下一节给出完整示例。

4.5 转封装与校验

录制完成后，把中间格式转封装成 MP4，便于后续剪辑、上传、播放。转封装不是转码，不改变音视频编码，只改容器，速度很快：

ffmpeg -i record.mkv -c copy output_record.mp4

校验是很多人会跳过的一步。建议用 FFmpeg 的解码模式完整扫描一遍文件，确认没有损坏：

ffmpeg -v error -i output_record.mp4 -f null -

如果文件完好，这条命令不会输出任何错误信息；如果有解码错误，会打印具体的错误位置和类型。

5. 完整示例代码实现

5.1 最小 FFmpeg 录制命令

实际项目中，最常用的命令组合如下。先用 FLV 保存直播原始数据：

mkdir -p /data/live_records ffmpeg -hide_banner -loglevel warning \ -rw_timeout 5000000 \ -i "rtmp://push.example.com/live/room123" \ -c copy \ -f flv /data/live_records/raw_record.flv

参数说明：

• -rw_timeout 5000000：网络读写超时设为 5 秒。直播流长时间没有数据时，FFmpeg 不会无限等待，而是更快地退出，方便外层脚本感知断流。
• -loglevel warning：只输出警告和错误，避免日志刷屏。

5.2 OBS 本地录制配置

如果不具备直接拉流条件，只能用 OBS 录屏，建议按下面的方式配置，降低损坏概率：

1. 打开“设置 → 输出 → 输出模式”，选择“高级”。
2. “录像”选项卡里，录像格式选择“MKV”或“FLV”，避免直接选 MP4。
3. 编码器按显卡选择：NVIDIA 显卡用 NVENC H.264，AMD 显卡用 AMF，无独显用软件 x264。
4. 录制完成后，用菜单“文件 → 重新封装录像”，把 MKV 快速转成 MP4。

注意，OBS 录屏只能捕获“本机看到的画面”，适合录制操作演示类内容。如果你的目标是“保存直播内容本身”，优先使用 5.1 和 5.3 的拉流方案。

5.3 自动命名与归档的 Python 脚本

下面这个脚本是本文的核心示例。它把“拉流、断线重连、命名、转封装”整合成一条自动化流水线，输出文件名遵循主播-直播录像-日期-场次.mp4规则，也就是文章开头那个文件名的格式。

#!/usr/bin/env python3 # -*- coding: utf-8 -*- """ 直播录像自动归档脚本 功能：拉流录制直播，断线自动重连，按“主播-直播录像-日期-场次”命名，并转封装为 MP4。 用法：修改下方配置后直接运行。提前确认你有权录制该直播内容。 """ import subprocess import time import os from datetime import datetime STREAM_URL = "rtmp://push.example.com/live/room123" # 替换为有权限访问的流地址 ANCHOR_NAME = "李一恩" # 主播/栏目名称 SESSION = "晚上场" # 场次：早上场