Python 解析直播流地址：FFplay 播放与 FFmpeg 录制

做视频采集这行当或者单纯是个爱折腾的爱好者总会撞上同一个坎打开某个电视频道的网页直播画面确实在动可翻遍浏览器开发者工具的网络面板也找不到一个能直接右键另存的 MP4 链接。想用播放器直接看想批量存几期节目偏偏卡在地址在哪这一步。直播流地址难找不是玄学这类页面压根就没打算把流地址明晃晃摆在那里——它藏在接口响应、播放器配置或者加密参数背后浏览器通过脚本自己去取人眼却很难直接抓到。这篇就聊聊我怎么用大概七十行的 Python 代码配合 FFplay把拿到直播流地址、直接播放、顺手录制下载这条链路跑通重点说清楚每一步为什么要这么做、参数怎么定、最容易在哪儿翻车。适合有点 Python 基础、想快速把直播流这事弄明白的读者不需要流媒体底层知识。1. 直播流地址难找的本质播放器拉的从来不是 MP41.1 按下播放键之后浏览器到底在拉什么很多人对视频播放的直觉是一个文件对应一个链接点开就下载点播页面确实可能是这样一个 MP4 文件挂在那儿右键就能看到地址。但直播不是这个逻辑。直播是边产生边推送的连续数据载体通常是 HLS 或 HTTP-FLV 这类流式协议。HLS 给你的地址是一个.m3u8索引文件里面一行行列着若干.ts分片每片几秒钟播放器按顺序去拉取、拼接、解码FLV 则是一个持续写入的.flv流服务端不断往里推数据。你看到的播放中本质是浏览器在后台不停请求一堆碎片而不是在下一部完整的 MP4。这就解释了第一个困惑为什么地址栏里、控制台里都找不到.mp4。因为直播场景下根本不存在这么个文件。你要找的是一个索引或流地址而不是一个成品文件。理解这一点很关键后面所有的解析、播放、录制操作对象都是流而不是文件。流的特点是它有时效、有并发、会断、会续处理思路和下载单个文件完全是两码事。我早期也走过弯路拿着一个 m3u8 地址去用普通下载工具拉结果只下到一个几百字节的文本还以为是解析失败了其实那只是一个索引。1.2 开发者工具抓不到地址的三个原因第一个原因地址先从接口拿页面后渲染。打开页面时前端脚本会先请求一个接口接口返回里带着播放地址的字段前端拿到这个字段再初始化播放器。这意味着你在 Network 面板里翻记录得先找到那个接口请求再从响应 JSON 里读字段。很多人只会盯着媒体类型的请求看方向就偏了。第二个原因防盗链和时效签名。真实地址后面往往挂着一串参数比如过期时间、客户端标识、校验串缺一个就返回 403。也就是说即使你把地址抄下来过几分钟再试可能就失效了。这类地址通常带token、expires、sign之类的关键词看起来又长又乱。第三个原因地址在运行时拼接。有些站点的播放器脚本会先取几个片段再用 JavaScript 拼成一个完整 URL甚至做一次简单的编码转换。你在静态源码里搜.m3u8搜到的可能只是一个片段字符串拼不起来。这三种情况叠加就造成了明明能看到画面就是抓不到地址的尴尬。1.3 第三方解析服务在这条链路里的定位面对上面这些情况手工抓包当然能解决但每换一个站点就要重新分析一遍接口和参数成本很高。所以出现了第三方的解析服务你把播放页地址丢给它它替你完成模拟请求、提取接口、还原地址这一整套流程最后把可用的流地址还给你。它的价值不是破解什么加密而是把取地址的脏活累活包了一层让你专注在播放和录制上。理解它的定位很重要。解析服务输出的是一个临时的、可能带时效的流地址你在拿到之后要尽快用掉别指望它长期有效。另外不同解析服务对同一个页面的支持程度不一样有的能吐 m3u8有的直接给 flv返回值格式也可能变。所以代码里对结果的提取要写得宽容一点同时兼容索引地址和流地址两种形态这样换个页面也不至于直接报错。2. 七十行代码的拆解从页面链接到可播放流2.1 运行环境和依赖清单环境这块其实很轻。Python 3.8 以上就够核心依赖只有requests用来发请求re和json是标准库负责从返回内容里抠地址。FFplay 和 FFmpeg 属于外部工具需要单独装好并保证在 PATH 里能直接调到。如果你用的是包管理安装装 FFmpeg 的时候 FFplay 是一起带上的不用额外折腾。pip install requests # 确认 ffplay / ffmpeg 可用 ffplay -version ffmpeg -version有一点要提醒别在代码里把解析服务的地址写死成某个具体域名。一方面服务会变另一方面不同服务参数不一样。比较稳妥的做法是把请求地址、目标页面地址、请求头集中放在文件顶部的配置区改的时候只动一处。请求头里至少带一个像样的User-Agent和Referer很多接口对这两个字段敏感缺了会直接返回空结果或者报错这一点跟普通网页抓取完全一样。2.2 三段式解析逻辑为什么这样分我把整条链路拆成三段提交、提取、消费。第一段把播放页地址提交给解析服务拿回一个包含结果的内容第二段从这个内容里提取出真正的流地址优先用正则匹配常见的流后缀匹配不到再尝试按 JSON 结构读字段第三段把地址交给 FFplay 或 FFmpeg 去播放、录制。这样拆的好处是每一段都可以单独测试。比如结果提取不对你就把第一段的返回打印出来看看它到底长什么样播放出问题你就把提取到的地址单独贴到命令行里跑一下快速判断是地址的问题还是参数的问题。把一整段逻辑搅在一起写出问题时你根本分不清是哪一环坏了。我踩过这个坑早期图省事写成一个函数结果解析失败和播放失败报的是同一个错排查了半天才发现是正则没匹配上。2.3 完整代码与逐段说明下面这份代码大概七十行把三段逻辑串起来同时留了播放和录制两个入口。import re import json import sys import subprocess import requests # ---- 配置区把下面两个地址换成你实际在用的服务和目标页面 ---- PARSER_ENDPOINT https://example-parser.invalid/api PAGE_URL https://example-tv.invalid/live/channel-1 HEADERS { User-Agent: ( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0 Safari/537.36 ), Referer: https://example-tv.invalid/, } def fetch_result(page_url: str) - str: 第一段把播放页地址交给解析服务拿回结果文本。 resp requests.post( PARSER_ENDPOINT, data{url: page_url, format: json}, headersHEADERS, timeout15, ) resp.raise_for_status() return resp.text def extract_stream_url(content: str) - str: 第二段从结果里提取流地址兼容 m3u8 和 flv。 patterns [ rhttps?://[^\]?\.m3u8[^\]*, rhttps?://[^\]?\.flv[^\]*, ] for pattern in patterns: match re.search(pattern, content) if match: return match.group(0) # 正则没抓到就试着按 JSON 字段读 try: data json.loads(content) except json.JSONDecodeError: data None if isinstance(data, dict): for key in (url, stream, play_url): if data.get(key): return data[key] raise RuntimeError(没有从结果里找到可用的流地址) def play(stream_url: str) - None: 第三段之一用 ffplay 直接播放低延迟参数适合直播。 cmd [ ffplay, -hide_banner, -fflags, nobuffer, -flags, low_delay, -i, stream_url, ] subprocess.run(cmd, checkFalse) def record(stream_url: str, output: str) - None: 第三段之二用 ffmpeg 边看边存-c copy 不重新编码。 cmd [ ffmpeg, -hide_banner, -i, stream_url, -c, copy, -y, output, ] subprocess.run(cmd, checkFalse) if __name__ __main__: page sys.argv[1] if len(sys.argv) 1 else PAGE_URL mode sys.argv[2] if len(sys.argv) 2 else play output sys.argv[3] if len(sys.argv) 3 else output.mp4 content fetch_result(page) stream extract_stream_url(content) print(解析到流地址:, stream) if mode record: record(stream, output) else: play(stream)走一遍流程fetch_result负责第一段extract_stream_url负责第二段并兜底两种格式play和record分别对应两种消费方式。命令行运行时第一个参数是页面地址第二个参数决定播放还是录制比如python run.py 页面地址 record demo.mp4。这样一份代码换个页面只要改配置区非常省事。关于提取逻辑我要强调一点先正则后 JSON的顺序不是随便定的。很多解析服务返回的是带大量 HTML 标签的页面直接json.loads必然失败所以先用正则兜住最常见的 m3u8/flv 形态成功率最高返回纯 JSON 的情况下正则可能恰好也能抓到地址抓不到再走 JSON 兜底两条路互补。别指望一种方式通吃实际用下来两种方式结合才稳。3. FFplay 先接一手验证、播放和调参3.1 最小播放命令和窗口参数拿到地址之后第一件事不是急着写录制脚本,而是先用 FFplay 把画面放出来确认这个地址是活的、能正常解码。最小命令就是ffplay -i 地址一行搞定。如果你平时播放器用得多FFplay 给人的第一印象是窗口不能拖拽、快捷键很陌生,但它是最干净的验证工具——它不做任何额外的界面逻辑能播说明流本身没问题播不了给出的报错信息也比网页上那句加载失败有用得多。窗口相关的参数我常用这几个-window_title改标题方便同时开好几个窗口区分-x和-y控制初始窗口宽高-autoexit让流结束后自动关窗脚本调用时很有用不然进程会一直挂着。如果只是想验证流健康加-nodisp关闭画面显示只处理音频或纯粹读流占用资源更小也方便在无图形界面的环境里跑。这些参数不用死记ffplay -h里都有重点是知道有这么几类。3.2 用 FFplay 做流健康检查我习惯把 FFplay 当成一个流探针。具体来说关注三件事能不能拉起画面、有没有持续的音视频输出、日志里有没有反复的重连或错误。按下播放后如果窗口几秒内出画面且声音正常基本可以判定流是健康的。反过来如果报Connection refused、403 Forbidden这类多半是地址失效或者请求头没带对如果报Invalid data found when processing input说明拿到的根本不是流地址可能是解析结果错位或者抓到了别的东西。更细一点可以在播放时观察控制台输出的时间戳是否持续递增。时间戳停住或者反复跳回去通常意味着流端在断流重连。这一步的价值在于把地址问题和播放参数问题分离开地址用 FFplay 验证一次正常后面录制出问题就基本可以排除地址因素。我见过不少人录制失败第一反应是换命令实际上用 FFplay 一放就发现地址早就过期了。3.3 卡顿、花屏、断流分别调什么参数直播卡顿的来源大概分三类对应的调法也不一样。网络侧抖动导致缓冲不足可以加大-probesize和-analyzeduration让 FFplay 在开头多读一点数据再开始播放代价是起播慢一两秒。低延迟需求下画面偶尔卡一下但整体跟得上用-fflags nobuffer -flags low_delay牺牲一点稳定性换更小的延迟适合盯直播而不是收藏。花屏或者绿块八成是解码跟不上或者分片不完整这种情况调大缓冲作用有限反而应该检查网络是不是在丢包必要时用-framedrop允许丢帧保播放连续性。断流则要区分是源端主动结束还是一时抖动前者只能重新解析拿新地址后者 FFplay 一般会自动重连但你要留意日志里重连的频率太频繁就说明源本身不稳定。这里没有万能参数我的经验是准备两套配置一套偏稳定大缓冲一套偏低延迟按场景切换。4. 录制下载FFmpeg 方案的取舍与分段思路4.1 边看边存的最简命令录制的核心就是 FFmpeg 那条-i 地址 -c copy 输出。-c copy是关键它表示不重新编码直接复制原始音视频数据速度快、几乎不占 CPU、画质零损失。很多人第一次录流会用转码结果机器风扇狂转、录出来还糊就是因为多了一步没必要的编码。ffmpeg -hide_banner -i 解析到的流地址 -c copy -y live.mp4输出容器要结合流格式选。HLS 流录成.mp4一般没问题但如果中途断了MP4 的索引可能写不完整文件打不开这时候.mkv或.ts更宽容断点后依然能播。我一般先用 mp4 图方便碰到断流频繁的场景就改 ts事后再转封装。录制的时机也要注意开始录制不会从头开始它从连接成功那一刻往后存所以想完整录一场得在开始前就挂上命令。4.2 定时分段与文件命名一场直播动辄一两个小时录成一个巨大文件既不好管理也不好传。我习惯用-f segment按时间分段命令里加几个参数就行ffmpeg -hide_banner -i 流地址 -c copy \ -f segment -segment_time 600 \ -reset_timestamps 1 \ part_%03d.mp4-segment_time 600表示每十分钟切一个文件-reset_timestamps 1让每个分段的时间戳从零开始避免拼接时出现时间跳变。命名里的%03d会自动递增part_000.mp4、part_001.mp4依次排下去。这套方案对栏目点播场景同样好用如果解析到的是某期节目的完整流地址分段录制既能控制单文件体积中途出错也只损失一段。文件切出来之后需要合回去再用concat就行了。4.3 下载后的封装和校验录完之后别急着删源地址先做两件事。一是用ffprobe看一眼时长和轨道信息确认音视频都在、时间长度对得上ffprobe -hide_banner -show_format -show_streams part_000.mp4二是抽帧看一眼画面有没有黑屏或者花屏。分段录制的文件尤其要抽检因为断流重连后可能出现某一段开头几秒损坏。如果打算长期保存我会把 ts 分段统一转封装成 mp4去掉中间文件。转封装依然用-c copy速度很快。这套流程跑顺之后从拿到地址到存成可播放文件全程几乎不用人工干预。5. 实操里那些文档不会写的东西5.1 地址失效与自动重试解析出来的地址带时效这是绕不开的现实。短的可能几分钟就过期长的也就一两个小时。所以写脚本的时候一定把重解析做成可调用的一步而不是只在开头解析一次。我的做法是在录制脚本里加个监测FFmpeg 进程异常退出且输出里有连接错误时重新走一遍解析拿到新地址后接着录到新文件。虽然没法做到无缝续接但至少不会大片空白。另一个细节是别在解析结果上做假设。有的服务返回的地址里带了临时 token有的带签名字段URL 看起来很长很吓人但直接用就好别手动去改参数。我有一次自作聪明把地址里的参数精简了一下结果校验失败排查半天才想起来这茬。5.2 网络抖动下的缓冲策略直播对网络稳定性比点播敏感得多。如果你录制的机器同时在跑别的任务很容易出现丢包导致分段损坏。我的经验是录制进程尽量独占网络带宽别和下载、上传任务抢FFmpeg 加-rtsp_transport tcp对 RTSP 源有意义对 HLS/FLV 不用缓冲区相关的-buffer_size可以根据实际码率调大一些给网络抖动留余量。还有一点别在弱网下同时开播放和录制。FFplay 和 FFmpeg 各自都要拉一份流等于同一份数据请求两次弱网下两边都容易卡。所以我一般验证和录制分开先用 FFplay 确认地址可用关掉它再启动录制。5.3 合理使用与边界最后说点实在的。这类脚本的用途应当限定在个人学习、技术验证和合法授权范围内比如测试自己的流媒体服务、研究流协议、做自己的节目备份。录制和传播他人内容涉及版权这点必须心里有数脚本能跑通不代表可以随意使用。另外解析服务本身也是有限制的频率太高会被限流甚至封请求写脚本时加个简单的 sleep 和失败重试间隔对服务对你自己都好。我自己用这套东西的体会是代码短不是目的链路清晰才是。七十行能跑通是因为每一段只做一件事出问题能快速定位。真到了复杂场景短脚本反而更容易改。把解析、提取、播放、录制这几步拆开每步单独验证一次剩下的就是调参数和踩坑的耐心了。频道能播、节目能存这套流程就够用很久。