直播自动录制系统实战：流媒体协议、ffmpeg与streamlink详解

从“想留存一场比赛直播”到“自动下载一条直播流并生成规范文件”中间隔着协议选择、参数调优、断流重连、命名规范和磁盘运维等一堆问题。这篇博客就以“电竞录播场景”为背景完整拆解一套直播自动录制方案从流媒体协议基础讲起到 ffmpeg / streamlink 命令、定时任务、异常处理和工程规范全部覆盖适合视频运营、个人创作者和后端开发参考。1. 背景为什么要做自动化录播系统无论是赛事转播、游戏直播还是在线课程都有“直播时没看完、之后想补档”的需求。手动录屏存在三个明显问题画质受显示器分辨率影响、无法长时间稳定运行、录完还要手动改名归档。而对视频创作者来说直播结束后的切片和二创依赖的正是第一时间拿到的高质量原始文件。自动化录播系统要解决的核心问题可以拆成四点准时开始提前到达直播间等待开播而不是靠人盯。稳定录制直播过程中可能断流、卡顿、网络波动脚本需要自动重连。按规则归档文件名要包含日期、场次、对战双方目录结构清晰方便后续检索和剪辑。资源可控长时间录制的文件体积很大需要监控磁盘、定期清理、避免录到一半“爆盘”。这套能力不只适用于 CS2 等电竞比赛任何基于 HLS、RTMP、HTTP-FLV 协议的直播流都可以复用同一套思路。下面先把基础概念理清再直接进入可运行的完整方案。2. 直播流媒体基础概念与协议解析2.1 直播流常见的三种协议现在主流直播平台的下发协议主要有三种协议全称特点常见场景HLSHTTP Live Streaming基于 HTTP将视频切片为多个 ts 文件通过 m3u8 索引播放兼容性好支持动态码率切换网页端、移动端直播/点播RTMPReal-Time Messaging Protocol基于 TCP 的长连接延迟低但依赖 Flash 时代生态目前多用于推流端直播推流、早期直播平台HTTP-FLVHTTP FLV 封装把 FLV 视频流通过 HTTP 传输延迟较低浏览器可通过 flv.js 播放国内直播平台网页端对录制场景来说最常用的是HLS 的 m3u8 地址和HTTP-FLV 地址。原因很简单它们都是基于 HTTP 的协议不依赖特定客户端ffmpeg 和 streamlink 都能直接处理。2.2 m3u8 索引文件长什么样m3u8 本质上是一个文本索引文件里面记录了一个个视频分片ts 文件的地址。下面是一个典型示例#EXTM3U #EXT-X-VERSION:3 #EXT-X-TARGETDURATION:6 #EXT-X-MEDIA-SEQUENCE:1882 #EXTINF:6.000, https://example.com/live/stream_1882.ts #EXTINF:6.000, https://example.com/live/stream_1883.ts #EXTINF:6.000, https://example.com/live/stream_1884.ts#EXTINF表示分片时长单位是秒。#EXT-X-MEDIA-SEQUENCE表示当前分片序列号录制过程中这个值会不断推进。播放器或下载器会不断请求最新 m3u8获取新分片并拼接连播。理解了这一点就能明白为什么录制 HLS 直播本质上是“反复拉取 m3u8 索引下载新增的分片并按顺序合并/转封装为一个连续视频文件”。2.3 录播和点播的区别“录播”这个词在不同语境下含义不同直播录播直播进行时实时录制生成回放文件。点播/回放直播平台已经生成的完整视频下载方式是普通 HTTP 文件下载。本文方案同时覆盖这两种场景直播中通过流地址实时录制直播结束后若平台提供完整回放地址则可以按普通文件下载。两种方式对应的命令不太一样后面会分别给出。3.1 环境与版本说明所有示例在以下环境验证通过项目说明操作系统Ubuntu 22.04 LTS / Windows 10 均可ffmpeg4.4 及以上版本streamlink6.x 及以上版本Python3.8用于循环检测脚本包管理器apt / winget / 官网安装包版本需根据你的实际环境调整本文重点演示配置思路和完整流程不绑定某个具体版本。3.2 Linux 端安装工具# 更新系统包索引 sudo apt update # 安装 ffmpeg sudo apt install -y ffmpeg # 安装 streamlink依赖 Python3 pip3 install --user streamlink # 验证安装 ffmpeg -version | head -n 1 streamlink --version3.3 Windows 端安装工具Windows 下推荐使用winget安装 ffmpegwinget install ffmpegstreamlink 可从 GitHub Releases 页面下载 Windows 安装包安装完成后在 PowerShell 中验证ffmpeg -version streamlink --version3.4 获取直播流地址的通用思路要录制直播流第一步是拿到流地址。不同平台获取方式不同常见思路如下浏览器开发者工具打开直播间页面F12 打开开发者工具切到 Network / 网络 标签刷新页面后过滤m3u8或flv即可看到流地址。平台公开 API部分平台提供room_id查询当前直播流地址的公开接口可以用 curl 或 Python 请求获取。第三方工具解析streamlink 内置了大量平台插件直接支持很多直播平台开箱即用。注意录制和下载直播内容应遵守平台服务条款和版权规定。个人学习、备份非商用内容通常问题不大但若用于二次分发务必确认授权。4. 使用 ffmpeg 实现直播自动录制4.1 最简单的 ffmpeg 拉流录制命令如果已经拿到 HLS 直播地址只需要一条命令就能开始录制ffmpeg -i https://example.com/live/stream.m3u8 -c copy output.mp4命令解释-i指定输入流地址。-c copy表示不重新编码直接把原始音视频数据复制进容器速度快且无损。output.mp4是输出文件名。4.2 指定时长录制直播可能持续数小时而你可能只需要前 30 分钟。可以用-t参数指定录制时长ffmpeg -i https://example.com/live/stream.m3u8 -c copy -t 1800 output.mp4-t 1800表示录制 1800 秒也就是 30 分钟。4.3 断流自动重连直播流可能因为网络波动或平台临时抽风中断。ffmpeg 遇到断流默认会直接退出加上以下参数可以提高容错率ffmpeg -i https://example.com/live/stream.m3u8 -c copy -timeout 30 -rw_timeout 30000000 output.mp4-timeout 30设置 TCP 连接超时单位秒。-rw_timeout 30000000设置读写超时单位是微秒这里表示 30 秒。不过仅靠参数并不能在断流后自动续录。生产级方案需要外层脚本负责轮询检测和重启录制这块在后面会单独说明。4.4 HLS 分片录制的局限性直接对 m3u8 执行-c copy时输出文件可能存在的两个问题音视频不同步部分直播源时间戳PTS异常导致合并后音画不同步。时间戳跳变直播中断重连后时间戳序列可能不连续。如果遇到这两种情况可以改用重编码方式处理ffmpeg -i https://example.com/live/stream.m3u8 -c:v libx264 -c:a aac -b:a 128k output.mp4代价是 CPU 占用明显上升录制速度可能低于直播速度需要评估机器性能。5. 使用 streamlink 简化直播录制5.1 streamlink 是什么streamlink 是一个命令行工具专门用于将各类直播平台的流媒体转发到播放器或保存为文件。它内置了大量平台支持能自动识别画质、自动重连比直接用 ffmpeg 命令更省心。5.2 查看可用画质streamlink --stream-url https://www.twitch.tv/example best如果要查看某个直播间所有可选画质streamlink https://www.twitch.tv/example输出会列出类似720p60、1080p60、best、worst等关键词。5.3 录制直播流streamlink https://www.twitch.tv/example 1080p60 -o output.ts参数中的1080p60表示指定画质。使用best可以自动选择最高画质streamlink https://www.twitch.tv/example best -o output.tsstreamlink 的优势在于它内置了重试机制直播中断后会尝试重新连接对长时间录制的稳定性有很大帮助。5.4 设置重试次数和超时streamlink https://www.twitch.tv/example best -o output.ts --retry-stream 5 --retry-max 60--retry-stream断流后重试次数。--retry-max最大重试间隔秒实际重试间隔会递增。6. 完整实战从检测开播到自动归档这一节组合前面所有能力写出一个“轮询检测开播 → 自动开始录制 → 结束后按日期归档”的完整脚本。脚本用 Python 编写外部依赖只有requests和调试用日志模块。6.1 项目结构live-recorder/ ├── config.json # 配置文件 ├── recorder.py # 主脚本 ├── output/ # 录制输出目录 │ └── 2026-08-13/ # 按日期归档子目录 └── logs/ # 日志目录6.2 配置文件{ channel_name: G2-M80, stream_url: https://example.com/live/stream.m3u8, output_dir: output, check_interval: 60, max_duration: 14400, retry_count: 3 }说明stream_url是直播流 m3u8 地址。check_interval是轮询检测间隔秒建议 60 秒一次避免频繁请求给平台造成压力。max_duration是最长录制时间秒防止异常情况下一直录下去。retry_count是断流重试次数。6.3 主脚本import json import os import subprocess import time from datetime import datetime import logging from pathlib import Path logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(logs/recorder.log, encodingutf-8), logging.StreamHandler() ] ) logger logging.getLogger(__name__) def load_config(pathconfig.json): with open(path, r, encodingutf-8) as f: return json.load(f) def check_stream(url): 通过 ffmpeg 探测流是否可用 cmd [ ffmpeg, -i, url, -t, 5, -c, copy, -f, null, -y, /dev/null ] try: result subprocess.run( cmd, stdoutsubprocess.PIPE, stderrsubprocess.PIPE, timeout20 ) # ffmpeg 即使成功也会向 stderr 输出大量信息这里用返回码判断 return result.returncode 0 except subprocess.TimeoutExpired: logger.warning(探测直播流超时) return False def generate_filename(channel_name): 生成带时间戳的文件名 now datetime.now() date_str now.strftime(%Y-%m-%d) time_str now.strftime(%H-%M-%S) safe_name channel_name.replace( , -) return safe_name, date_str, f{safe_name}_{date_str}_{time_str}.mp4 def record_stream(config, url, output_path, max_duration): 调用 ffmpeg 录制直播流 cmd [ ffmpeg, -y, -i, url, -c, copy, -t, str(max_duration), output_path ] logger.info(f开始录制: {output_path}) try: subprocess.run(cmd, checkTrue) except subprocess.CalledProcessError as e: logger.error(f录制过程中出错: {e}) return False return True def main(): config load_config() output_dir Path(config[output_dir]) output_dir.mkdir(exist_okTrue) logs_dir Path(logs) logs_dir.mkdir(exist_okTrue) stream_url config[stream_url] check_interval config[check_interval] max_duration config[max_duration] retry_count config[retry_count] channel_name config[channel_name] logger.info(录播系统启动等待直播开始...) while True: if check_stream(stream_url): safe_name, date_str, filename generate_filename(channel_name) # 按日期创建归档目录 day_dir output_dir / date_str day_dir.mkdir(exist_okTrue) output_path day_dir / filename # 录制失败则按配置重试 for attempt in range(retry_count): success record_stream(config, stream_url, str(output_path), max_duration) if success: break logger.warning(f录制中断第 {attempt 1} 次重试) time.sleep(10) logger.info(本轮录制结束继续检测下一场直播...) time.sleep(check_interval * 5) else: logger.info(直播未开始继续等待...) time.sleep(check_interval) if __name__ __main__: main()6.4 运行与验证python3 recorder.py启动后脚本会进入循环检测状态日志输出大致如下2026-08-13 14:00:01 - INFO - 录播系统启动等待直播开始... 2026-08-13 14:01:01 - INFO - 直播未开始继续等待... 2026-08-13 14:05:00 - INFO - 检测到直播流可用 2026-08-13 14:05:00 - INFO - 开始录制: output/2026-08-13/G2-M80_2026-08-13_14-05-00.mp4录制结束后进入output/2026-08-13/目录可以看到生成的文件ls -lh output/2026-08-13/预期得到一个.mp4文件大小取决于直播时长和码率。-rw-r--r-- 1 user user 1.2G Aug 13 16:30 G2-M80_2026-08-13_14-05-00.mp46.5 不足与扩展上面的脚本是一个最简可用版本生产使用还需要优化几个点单文件录制时间过长时建议按 1 小时为单位切片避免一个文件几十 GB 导致剪辑困难。录制完成后可以做一次快速校验时长、大小、是否包含音轨确保文件有效。如果平台流地址经常变动需要实现定期重新获取地址的逻辑而不是启动时读取一次。7. 视频文件处理与转封装7.1 为什么需要转封装直播录制输出通常是.ts或裸 HLS 分片合并文件格式本身没有错误但兼容性不够好。移动端、剪辑软件对.mp4的兼容性远高于.ts因此录完后建议统一转封装为 MP4。ffmpeg -i input.ts -c copy output.mp4-c copy不会重新编码速度是实时的数倍以上画质没有任何损失。7.2 提取纯音频有些录播场景只需要保留声音比如做播客或音频切片。可以提取音频为 m4a 或 mp3ffmpeg -i input.mp4 -vn -c:a copy output.m4a如果要转成 mp3ffmpeg -i input.mp4 -vn -c:a libmp3lame -b:a 128k output.mp37.3 截取精彩片段直播录播完通常要切片。比如截取第 30 分钟开始的 90 秒片段ffmpeg -i input.mp4 -ss 00:30:00 -t 90 -c copy highlight_90s.mp4这里-ss放在-i之前是“快速定位”模式定位速度快但切出的视频开头可能在关键帧之前导致画面黑屏要求精确时可以把-ss放到-i之后做精确切割但速度会慢一些。7.4 批量转封装脚本多场比赛、多个文件时手动执行太慢可以写一个简单的批量转封装脚本#!/bin/bash # 批量将 output 目录下的 .ts 文件转为 .mp4 for f in output/*.ts; do if [ -f $f ]; then outfile${f%.ts}.mp4 echo 正在转换: $f - $outfile ffmpeg -i $f -c copy $outfile fi done8. 定时任务与自动化运维8.1 使用 systemd 管理录播进程长期运行的录播脚本不适合直接用python3 recorder.py挂在前台建议使用 systemd 托管实现开机自启和崩溃自动重启。创建服务文件/etc/systemd/system/live-recorder.service[Unit] DescriptionLive Stream Recorder Afternetwork.target [Service] WorkingDirectory/opt/live-recorder ExecStart/usr/bin/python3 /opt/live-recorder/recorder.py Restartalways RestartSec30 [Install] WantedBymulti-user.target启用并启动服务sudo systemctl daemon-reload sudo systemctl enable live-recorder sudo systemctl start live-recorder常用管理命令# 查看服务状态 systemctl status live-recorder # 查看实时日志 journalctl -u live-recorder -f # 重启服务 sudo systemctl restart live-recorder8.2 使用 cron 定时检查磁盘录播是磁盘空间消耗大户。1 小时 1080p 直播大约产生 1.5~3 GB 文件连续录几天如果不清理磁盘很快会满。通过 cron 每天检查一次磁盘使用率并清理超过 N 天的文件是稳妥做法。创建脚本/opt/live-recorder/cleanup.sh#!/bin/bash # 删除 output 目录下 7 天前的录播文件 find /opt/live-recorder/output -type f -name *.mp4 -mtime 7 -delete # 删除空目录 find /opt/live-recorder/output -type d -empty -delete添加定时任务每天凌晨 3 点执行0 3 * * * /bin/bash /opt/live-recorder/cleanup.sh注意清理脚本会真正删除文件。上线前务必先在测试目录验证find命令的匹配范围确认无误后再配置到生产环境。8.3 日志切割Python 脚本里直接写的日志文件不会自动切割长时间运行会越来越大。Linux 下可以用logrotate管理。创建/etc/logrotate.d/live-recorder/opt/live-recorder/logs/*.log { daily rotate 7 compress missingok notifempty copytruncate }这样日志会每天切割一次保留 7 天并压缩旧日志。9. 常见问题与排查思路下面汇总录播系统中出现频率较高的几类问题。问题现象常见原因解决思路ffmpeg 报403 Forbidden流地址带时效签名已过期重新获取带最新签名的流地址或缩短获取间隔录制的视频没有声音流地址只包含视频轨道或音频流单独一路检查 m3u8 中是否有音频分片尝试完整播放验证录制中断后不自动恢复脚本缺少重试逻辑使用循环检测 断流重启或改用 streamlink 的--retry-stream输出文件音画不同步时间戳异常改用重编码方式录制或使用-fflags genpts重新生成时间戳磁盘空间不足导致录制失败长时间直播未清理历史文件配置定时清理对大文件做切片监控磁盘水位检测脚本误判直播已开始平台返回了占位流/预热流但没有真实画面拉流后做帧数检测确认视频轨道有实际数据streamlink 不认识平台平台未适配或需要更新插件升级 streamlink 版本改用 ffmpeg 直接拉流9.1 ffmpeg 录制报 403 的排查流程这个问题最常见。通常流程如下# 1. 先用 curl 测试流地址是否可访问 curl -I https://example.com/live/stream.m3u8 # 2. 查看 HTTP 状态码 # 403 表示服务端拒绝访问 # 200 表示正常 # 3. 检查是否缺少 Referer / User-Agent # 有些平台需要携带特定请求头如果确认需要请求头ffmpeg 可以通过-headers参数传入ffmpeg -headers Referer: https://example.com -i https://example.com/live/stream.m3u8 -c copy output.mp4如果是带签名的流地址那么“拿到地址后尽快开始录制”就是最重要的预防手段不要等太久再执行。9.2 断流检测的判定标准脚本里用ffmpeg -t 5探测流是否可用这个方式在多数场景下有效但也有一些边界情况平台返回的流可以连接但没有真实视频数据。网络波动导致探测超时但实际直播正常。更稳妥的判定方式是连续探测两次都返回成功再开始录制同时记录探测失败的时间避免因为短时网络抖动误判直播结束。9.3 如何确认录制文件完整录制完成后可以用 ffprobe 快速检查文件信息ffprobe -v error -show_format -show_streams output.mp4重点看三个字段duration文件时长是否符合预期。codec_type是否同时包含 video 和 audio。nb_frames/nb_read_packets数据包数量是否异常偏小。如果时长明显短于实际直播时长说明中途录制中断需要排查日志中的重连记录。10. 最佳实践与工程建议10.1 优先选 streamlink 而不是裸写 ffmpeg如果直播平台在 streamlink 的支持列表里优先使用 streamlink。它帮你做好了画质选择、断线重连、重试等待等细节比自己维护一套 ffmpeg 重试逻辑省很多事情。只有平台不被支持时才回退到 ffmpeg 直接拉流。10.2 文件名里包含足够的信息建议的文件命名格式{赛事名}_{日期}_{开始时间}_{场次}_{清晰度}.mp4例如EWC_2026-08-13_14-05_G2-M80_1080p.mp4好处是排序后一眼能看出比赛时间和对阵双方也方便后续剪辑时通过文件名筛选素材。不要用output1.mp4这种没有信息量的命名。10.3 录制前先试播 10 秒正式录制前先尝试拉流 10 秒生成一个小文件验证内容ffmpeg -i https://example.com/live/stream.m3u8 -c copy -t 10 test.mp4 -y然后确认这个 test.mp4 能正常播放、有画面有声音再启动正式录制。这一步能提前拦截绝大多数“地址失效”“没有音频”“只有静态图”的问题。10.4 按小时切片避免超大文件假设直播持续 8 小时从下午 2 点录到晚上 10 点单文件体积可能在 10GB 以上。这种文件打开、剪辑、上传都很吃力。建议录制逻辑里按小时生成独立文件文件命名带上时间段G2-M80_2026-08-13_14-00-15-00.mp4 G2-M80_2026-08-13_15-00-16-00.mp4ffmpeg 的-t 3600可以做到这一点外层脚本负责在每段结束后重新启动下一次录制。10.5 注意版权与授权边界录播系统是强大的工具但必须注意使用场景。个人备份、学习研究、非商业剪辑通常没有问题但如果要公开发布、二次创作、甚至商用请先确认直播平台的服务条款是否允许录制和下载。赛事或内容版权所有方是否授权二次分发。录制内容中是否包含未授权素材音乐、画面、赞助内容。合法合规使用录播工具才能真正长期稳定地为你创造价值。10.6 监控与告警录播系统如果无人值守运行建议增加最简单的告警机制。比如连续 3 次检测失败时向管理后台或群机器人推送告警。录制文件生成后检查文件大小是否低于阈值异常则通知人工介入。磁盘使用率超过 85% 时提前告警避免录制途中空间耗尽。不依赖复杂监控系统脚本里加一个 webhook 请求就能实现基础告警import requests def send_alert(message): webhook_url https://your-webhook-url try: requests.post(webhook_url, json{text: message}, timeout5) except Exception as e: logging.error(f告警发送失败: {e})11. 从录播到内容生产后续能做什么录播只是内容生产链路的第一环拿到原始文件之后通常还会做一些处理自动切片根据比赛关键节点或弹幕高能时刻自动切出精彩片段。封面生成用 ffmpeg 截取指定时间帧生成封面图。字幕生成通过语音识别给录播视频生成字幕方便剪辑检索。转码上传将录播文件转成适合平台上传的码率与格式批量分发到多个平台。这套“协议解析 → 拉流录制 → 文件转码 → 自动归档 → 定时清理”的体系不仅适用 CS2 赛事录播也适用于讲座、会议、网课、发布会等所有直播留存场景。先跑通一个最小闭环再逐步加上你要的工程化能力。如果你按照上面的脚本部署起来建议先把“检测 → 试播 → 定时清理”三条链路分别测试通过再放入正式赛程列表。录播系统的稳定性不是靠某一条命令而是靠整体流程的容错设计。希望这份实操笔记能帮你少走一些弯路。