前几天整理直播内容归档时我拿到一个看起来非常规范的文件名李一恩直播录像-2026-08-13-晚上场.mp4。文件名本身没什么技术含量但它背后其实藏着一整套值得较真的工程问题这场直播是怎么录下来的录制过程中断线了怎么办为什么有时候录完的视频打不开归档时怎么命名、怎么校验、怎么控制磁盘成本很多开发者的第一反应是直播录像不就是用 OBS 录屏吗这个判断在“录自己电脑屏幕”的场景下勉强成立但只要你面对的是持续三四个小时的晚上场直播或者要按日期批量归档、检索回放就会发现它远不止一个“开始录制”按钮。直播录像本质是一条流媒体采集链路从拉流协议、编码容器、断线重连到文件切片、完整性校验、命名归档每一环都可能翻车。这篇文章我从工程视角把这条链路完整拆开。先讲清楚 RTMP、HLS、FLV 这些基础概念再给出可落地的 FFmpeg、OBS 和 Python 自动化录制方案最后整理常见故障排查和最佳实践。读完你可以独立搭建一套“主播/栏目-日期-场次”的自动录像归档小系统。1. 直播录像是个工程问题不是录屏问题1.1 三个真实翻车场景先看几个我见过很多次的场景你可以对照一下自己有没有踩过类似的坑。场景一录到一半文件损坏。有人用 OBS 直接把录像格式设成 MP4录制一场晚上场直播三个半小时后直播结束点停止录制软件提示“录像文件已损坏无法播放”。原因是 OBS 在主进程异常退出或电源突然中断时MP4 的索引信息没有来得及写入文件尾部整个文件直接报废。如果直播没有回放内容就等于永久丢失。场景二录屏把不该录的东西都录进去了。用 OBS 采集桌面或浏览器窗口来录别人的直播系统通知、弹窗、输入法候选框、后台消息提醒全部入了画面麦克风或者电脑播放声音串进来音质也很差。更关键的是屏幕录制的画面质量取决于缩放和编码设置分辨率一旦没对齐直播源本身很清晰录出来却是模糊的。场景三录了一堆文件命名全是“录制_001.mp4”。一场一场录完文件堆在一个目录里不打开看根本分不清哪个是哪个。等到要找某一天某一场的录像做剪辑要花大量时间挨个播放预览。这就是典型的“录制完成、归档失败”。这三个场景说明同一个问题直播录像的难点不是“能不能录”而是“能不能稳定录完、录完能不能用”。1.2 直播录像的完整链路如果把直播录像当成一个完整的数据流水线大概是这个样子获取流地址自己直播的推流地址或经授权的播放地址。拉流用 FFmpeg、OBS 或相关直播流工具从服务器拉取音视频数据。容器封装FLV、MKV、TS、MP4 等格式选择。文件切分与断线重连按时间分片断流后自动恢复。完整性校验用 ffprobe 检查时长、流信息用解码器扫描错误。归档命名主播/栏目-日期-场次方便检索。存储与备份预留空间、保留策略、热备/冷备。这条链路里最容易翻车的是“容器封装 断流恢复”这一环最容易被低估的是“命名和归档”这一环。前者决定内容能不能成功保存后者决定内容能不能在需要时被找到。2. 基础概念推流、拉流与录制路线2.1 RTMP、HLS、FLV 到底是什么在写录制命令之前必须先弄懂几个高频出现的协议词否则你连 FFmpeg 的报错都看不懂。推流publish/ingest主播端把音视频数据持续发送到直播服务器。对大多数直播平台来说推流端使用的依然是 RTMP 协议推流地址形如rtmp://push.example.com/live/房间号。拉流play/pull观众端或录制端从服务器拉取音视频数据的过程。拉流可以有多种协议常见的是 RTMP 和 HLS。RTMPReal-Time Messaging Protocol最早为 Flash 时代设计基于 TCP 的实时消息协议。延迟低1 到 3 秒量级是直播推流的事实标准。录制端拉 RTMP 流时数据通常以 FLV 容器承载。HLSHTTP Live Streaming苹果提出基于 HTTP 的流媒体协议。它将直播流切成一个个小的 TS 分片文件并通过 m3u8 索引文件维护播放列表。优点是能穿透常规 HTTP 网络环境、支持自适应码率缺点是延迟较高通常在 6 到 30 秒。很多平台的“网页直播、回放地址”就是 HLS。FLV / MKV / MP4 / TS这些都是容器格式负责把视频流、音频流、字幕、时间戳等打包在一起。容器本身不决定视频清晰度只决定封装结构和兼容性。下面用一个表格快速对比四种容器的录制特点容器断流容错兼容性录制场景FLV较好一般适合直播场景从 RTMP 直接录制最贴近直播原始形态MKV很好播放器支持广泛转封装容易本地录制首选崩溃后文件仍可读取TS很好一般分段传输友好HLS 分片原始格式适合边录边分段MP4较差最好剪辑软件和网页都认最终交付格式建议录制结束后转封装得到新手最容易误解的地方是MP4 是“最好的格式”所以录制时直接存 MP4。实际上直播录制过程中一旦断流或崩溃MP4 文件很容易损坏。更稳妥的做法是先录成 MKV 或 FLV正常结束后再转封装成 MP4。2.2 三条录制路线录屏、拉流、下载回放路线做法优点缺点适用场景本地录屏OBS 捕获显示器/窗口/浏览器操作直观不依赖协议知识画质受缩放影响容易混入杂音和窗口弹层手动操作多录制自己电脑上的操作演示直接拉流FFmpeg/直播流工具从 RTMP/HLS 拉取并保存画质接近源流可自动化稳定需要拿到流地址有一定命令行门槛录制直播内容本身推荐优先使用平台回放下载从直播平台的官方回放/VOD 入口下载或抓取分片不需要在直播过程中盯守依赖平台是否提供回放未经授权下载可能违规平台已提供回放的合规场景选择原则很简单能直接拉流就不要先渲染屏幕再录屏。录屏是“我在现场看直播顺便把它拍下来”拉流是“我直接从源头上把数据拷一份”。后者清晰度高、资源占用小、更容易自动化。3. 环境准备与前置条件3.1 工具清单与安装本文的实操环境不需要太复杂核心是三样FFmpeg拉流、转封装、校验都靠它。OBS Studio作为备选方案适合录制本机画面。Python 3用来写自动归档脚本调用 FFmpeg 完成任务。FFmpeg 的安装方式因系统而异Ubuntu / Debiansudo apt update sudo apt install ffmpegmacOS使用 Homebrewbrew install ffmpegWindows建议从 FFmpeg 官网下载静态构建版本解压后把bin目录加入系统 PATH。安装完成后验证版本ffmpeg -version看到类似ffmpeg version ...的输出就说明安装成功。需要留意的是不同发行版、不同构建版本的 FFmpeg 支持的功能略有差异本文的命令都基于常规开源构建不依赖付费扩展。OBS Studio 可以从官网下载支持 Windows、macOS、Linux安装后无需额外配置即可开始录制。3.2 磁盘空间估算直播录像是典型的“写入密集型”任务录之前必须先算清楚磁盘够不够。估算公式非常朴素体积(GB) ≈ 码率(Mbps) × 时长(小时) × 0.45这里 0.45 的来源是1 Mbps 流一小时产生的数据量约为 450 MB1,000,000 bit/s × 3600 s ÷ 8 ÷ 1024³取近似值。总码率每小时体积3 小时直播体积2 Mbps约 0.9 GB约 2.7 GB4 Mbps约 1.8 GB约 5.4 GB6 Mbps约 2.7 GB约 8.1 GB注意这个表算的是视频码率实际还要加上音频码率通常 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 录屏建议按下面的方式配置降低损坏概率打开“设置 → 输出 → 输出模式”选择“高级”。“录像”选项卡里录像格式选择“MKV”或“FLV”避免直接选 MP4。编码器按显卡选择NVIDIA 显卡用 NVENC H.264AMD 显卡用 AMF无独显用软件 x264。录制完成后用菜单“文件 → 重新封装录像”把 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 晚上场 # 场次早上场 直播录像工程实践：从RTMP拉流到自动归档的完整方案
前几天整理直播内容归档时我拿到一个看起来非常规范的文件名李一恩直播录像-2026-08-13-晚上场.mp4。文件名本身没什么技术含量但它背后其实藏着一整套值得较真的工程问题这场直播是怎么录下来的录制过程中断线了怎么办为什么有时候录完的视频打不开归档时怎么命名、怎么校验、怎么控制磁盘成本很多开发者的第一反应是直播录像不就是用 OBS 录屏吗这个判断在“录自己电脑屏幕”的场景下勉强成立但只要你面对的是持续三四个小时的晚上场直播或者要按日期批量归档、检索回放就会发现它远不止一个“开始录制”按钮。直播录像本质是一条流媒体采集链路从拉流协议、编码容器、断线重连到文件切片、完整性校验、命名归档每一环都可能翻车。这篇文章我从工程视角把这条链路完整拆开。先讲清楚 RTMP、HLS、FLV 这些基础概念再给出可落地的 FFmpeg、OBS 和 Python 自动化录制方案最后整理常见故障排查和最佳实践。读完你可以独立搭建一套“主播/栏目-日期-场次”的自动录像归档小系统。1. 直播录像是个工程问题不是录屏问题1.1 三个真实翻车场景先看几个我见过很多次的场景你可以对照一下自己有没有踩过类似的坑。场景一录到一半文件损坏。有人用 OBS 直接把录像格式设成 MP4录制一场晚上场直播三个半小时后直播结束点停止录制软件提示“录像文件已损坏无法播放”。原因是 OBS 在主进程异常退出或电源突然中断时MP4 的索引信息没有来得及写入文件尾部整个文件直接报废。如果直播没有回放内容就等于永久丢失。场景二录屏把不该录的东西都录进去了。用 OBS 采集桌面或浏览器窗口来录别人的直播系统通知、弹窗、输入法候选框、后台消息提醒全部入了画面麦克风或者电脑播放声音串进来音质也很差。更关键的是屏幕录制的画面质量取决于缩放和编码设置分辨率一旦没对齐直播源本身很清晰录出来却是模糊的。场景三录了一堆文件命名全是“录制_001.mp4”。一场一场录完文件堆在一个目录里不打开看根本分不清哪个是哪个。等到要找某一天某一场的录像做剪辑要花大量时间挨个播放预览。这就是典型的“录制完成、归档失败”。这三个场景说明同一个问题直播录像的难点不是“能不能录”而是“能不能稳定录完、录完能不能用”。1.2 直播录像的完整链路如果把直播录像当成一个完整的数据流水线大概是这个样子获取流地址自己直播的推流地址或经授权的播放地址。拉流用 FFmpeg、OBS 或相关直播流工具从服务器拉取音视频数据。容器封装FLV、MKV、TS、MP4 等格式选择。文件切分与断线重连按时间分片断流后自动恢复。完整性校验用 ffprobe 检查时长、流信息用解码器扫描错误。归档命名主播/栏目-日期-场次方便检索。存储与备份预留空间、保留策略、热备/冷备。这条链路里最容易翻车的是“容器封装 断流恢复”这一环最容易被低估的是“命名和归档”这一环。前者决定内容能不能成功保存后者决定内容能不能在需要时被找到。2. 基础概念推流、拉流与录制路线2.1 RTMP、HLS、FLV 到底是什么在写录制命令之前必须先弄懂几个高频出现的协议词否则你连 FFmpeg 的报错都看不懂。推流publish/ingest主播端把音视频数据持续发送到直播服务器。对大多数直播平台来说推流端使用的依然是 RTMP 协议推流地址形如rtmp://push.example.com/live/房间号。拉流play/pull观众端或录制端从服务器拉取音视频数据的过程。拉流可以有多种协议常见的是 RTMP 和 HLS。RTMPReal-Time Messaging Protocol最早为 Flash 时代设计基于 TCP 的实时消息协议。延迟低1 到 3 秒量级是直播推流的事实标准。录制端拉 RTMP 流时数据通常以 FLV 容器承载。HLSHTTP Live Streaming苹果提出基于 HTTP 的流媒体协议。它将直播流切成一个个小的 TS 分片文件并通过 m3u8 索引文件维护播放列表。优点是能穿透常规 HTTP 网络环境、支持自适应码率缺点是延迟较高通常在 6 到 30 秒。很多平台的“网页直播、回放地址”就是 HLS。FLV / MKV / MP4 / TS这些都是容器格式负责把视频流、音频流、字幕、时间戳等打包在一起。容器本身不决定视频清晰度只决定封装结构和兼容性。下面用一个表格快速对比四种容器的录制特点容器断流容错兼容性录制场景FLV较好一般适合直播场景从 RTMP 直接录制最贴近直播原始形态MKV很好播放器支持广泛转封装容易本地录制首选崩溃后文件仍可读取TS很好一般分段传输友好HLS 分片原始格式适合边录边分段MP4较差最好剪辑软件和网页都认最终交付格式建议录制结束后转封装得到新手最容易误解的地方是MP4 是“最好的格式”所以录制时直接存 MP4。实际上直播录制过程中一旦断流或崩溃MP4 文件很容易损坏。更稳妥的做法是先录成 MKV 或 FLV正常结束后再转封装成 MP4。2.2 三条录制路线录屏、拉流、下载回放路线做法优点缺点适用场景本地录屏OBS 捕获显示器/窗口/浏览器操作直观不依赖协议知识画质受缩放影响容易混入杂音和窗口弹层手动操作多录制自己电脑上的操作演示直接拉流FFmpeg/直播流工具从 RTMP/HLS 拉取并保存画质接近源流可自动化稳定需要拿到流地址有一定命令行门槛录制直播内容本身推荐优先使用平台回放下载从直播平台的官方回放/VOD 入口下载或抓取分片不需要在直播过程中盯守依赖平台是否提供回放未经授权下载可能违规平台已提供回放的合规场景选择原则很简单能直接拉流就不要先渲染屏幕再录屏。录屏是“我在现场看直播顺便把它拍下来”拉流是“我直接从源头上把数据拷一份”。后者清晰度高、资源占用小、更容易自动化。3. 环境准备与前置条件3.1 工具清单与安装本文的实操环境不需要太复杂核心是三样FFmpeg拉流、转封装、校验都靠它。OBS Studio作为备选方案适合录制本机画面。Python 3用来写自动归档脚本调用 FFmpeg 完成任务。FFmpeg 的安装方式因系统而异Ubuntu / Debiansudo apt update sudo apt install ffmpegmacOS使用 Homebrewbrew install ffmpegWindows建议从 FFmpeg 官网下载静态构建版本解压后把bin目录加入系统 PATH。安装完成后验证版本ffmpeg -version看到类似ffmpeg version ...的输出就说明安装成功。需要留意的是不同发行版、不同构建版本的 FFmpeg 支持的功能略有差异本文的命令都基于常规开源构建不依赖付费扩展。OBS Studio 可以从官网下载支持 Windows、macOS、Linux安装后无需额外配置即可开始录制。3.2 磁盘空间估算直播录像是典型的“写入密集型”任务录之前必须先算清楚磁盘够不够。估算公式非常朴素体积(GB) ≈ 码率(Mbps) × 时长(小时) × 0.45这里 0.45 的来源是1 Mbps 流一小时产生的数据量约为 450 MB1,000,000 bit/s × 3600 s ÷ 8 ÷ 1024³取近似值。总码率每小时体积3 小时直播体积2 Mbps约 0.9 GB约 2.7 GB4 Mbps约 1.8 GB约 5.4 GB6 Mbps约 2.7 GB约 8.1 GB注意这个表算的是视频码率实际还要加上音频码率通常 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 录屏建议按下面的方式配置降低损坏概率打开“设置 → 输出 → 输出模式”选择“高级”。“录像”选项卡里录像格式选择“MKV”或“FLV”避免直接选 MP4。编码器按显卡选择NVIDIA 显卡用 NVENC H.264AMD 显卡用 AMF无独显用软件 x264。录制完成后用菜单“文件 → 重新封装录像”把 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 晚上场 # 场次早上场