企业官网建设流程全解析

1. 为什么你需要真正搞懂 ffprobe 的输入与输出

很多人第一次接触 ffprobe，都是在一条命令行里顺手敲出来的：想看看某个视频文件到底多长、码率多少、编码格式是什么，于是ffprobe input.mp4一敲，屏幕上哗啦啦刷出一大段信息，然后……就懵了。信息确实出来了，但密密麻麻的键值对、嵌套结构、各种缩写，让人根本不知道哪些是真正有用的，哪些可以忽略。更麻烦的是，当你需要把这些信息接进自动化脚本、批量处理流程或者媒体资产管理系统时，靠肉眼看输出显然不现实，必须搞清楚它的输入怎么给、输出怎么读、格式怎么控。

ffprobe 是 FFmpeg 工具集里专门负责“探测”的组件，它不负责转码，也不负责播放，只做一件事：把媒体文件的内部结构、流信息、元数据、帧级细节尽可能完整地暴露出来。你可以把它理解成媒体世界的“体检仪”——输入是一个文件或者一路流，输出是一份结构化的体检报告。这份报告可以是给人看的纯文本，也可以是给机器读的 JSON、XML、CSV，甚至是 ini 风格的扁平键值对。能不能把这份报告用对、用好，直接决定了你后续的自动化流程是顺畅还是处处踩坑。

这篇文章面向的是已经用过 ffmpeg 基本命令、但对 ffprobe 的输入输出机制还停留在“能跑就行”阶段的开发者和运维人员。我会从输入侧和输出侧两条线分别拆开讲，把参数背后的逻辑、格式选择的取舍、字段含义的坑、以及实际项目里怎么组合使用，全部摊开来说。读完你至少能做到三件事：第一，知道不同输入源该怎么给参数；第二，能根据下游消费方的需求选对输出格式；第三，遇到字段缺失、解析失败、性能瓶颈时知道往哪个方向排查。全文基于我这些年做媒体处理流水线时反复踩坑总结出来的经验，不是官方文档的复述，而是“实际这么干会怎样”的记录。

2. ffprobe 的输入侧：你到底在探测什么

2.1 输入源的类型与对应参数策略

ffprobe 的输入可以是本地文件、网络流、管道数据，甚至是设备采集源。不同类型的输入，参数策略完全不一样，这是很多人第一个容易翻车的地方。

本地文件最简单，直接给路径就行：ffprobe -i /path/to/media.mp4。但这里有个细节，-i其实是可以省略的，ffprobe media.mp4也能跑。不过一旦你开始加其他参数，显式写-i会更清晰，避免参数被误解析成输入文件名。我个人的习惯是永远写-i，因为脚本里参数一多，省略-i很容易出歧义。

网络流的话，输入就是一个 URL。比如ffprobe -i http://example.com/stream.m3u8。这时候要注意，ffprobe 默认会尝试读取整个流来获取完整信息，对于直播流或者无限长的流，这会导致命令永远不返回。解决办法是配合-analyzeduration和-probesize限制探测的数据量。-analyzeduration单位是微秒，控制分析多长时间的数据；-probesize单位是字节，控制读取多少数据来探测流信息。实测下来，对于大多数 HLS 直播流，-analyzeduration 1000000 -probesize 500000就能在几百毫秒内拿到足够的流信息，而不必等整个流结束。

管道输入是另一个高频场景。当你从另一个进程把数据通过 stdin 喂给 ffprobe 时，需要显式指定输入格式，因为 ffprobe 没法从管道里“猜”出容器格式。命令大概长这样：cat media.ts | ffprobe -f mpegts -i pipe:0。这里的-f mpegts就是告诉 ffprobe“接下来这堆字节是 MPEG-TS 容器”。如果不指定，ffprobe 会尝试自动探测，但管道场景下自动探测经常失败或者误判。pipe:0表示从标准输入读，pipe:1则是标准输出，这个在链式处理里很常用。

设备采集源比如摄像头、采集卡，输入通常是-f v4l2 -i /dev/video0这类形式（Linux 下）。这种输入的特点是“活”的，没有固定长度，所以同样需要-analyzeduration和-probesize来限制探测时间，否则命令会一直挂着。

注意：网络流和设备源的探测，永远要加超时和探测限制。我见过太多脚本因为没加这两个参数，在流断开或者设备无响应时直接卡死，把整个流水线堵住。

2.2 探测深度控制：probesize 与 analyzeduration 的取舍

这两个参数是 ffprobe 输入侧最核心的性能调节旋钮，但很多人只知道它们“能限制探测”，却不知道限制多少合适，以及限制之后会丢什么信息。

-probesize控制的是 ffprobe 最多读取多少字节的数据来探测流的数量、编码格式、基本参数。默认值通常是 5000000 字节（5MB），对于大多数文件来说足够。但如果你处理的是超大文件或者需要探测的流在文件很靠后的位置，5MB 可能不够，ffprobe 会报“Could not find codec parameters”之类的错误。这时候把-probesize调大，比如-probesize 50000000，让它多读一点。

-analyzeduration控制的是分析多长时间的数据来获取更精确的信息，比如帧率、时长、码率。默认值通常是 5000000 微秒（5秒）。对于变帧率的视频，或者开头几秒信息不完整的流，这个值可能需要调大。但调大的代价是探测变慢，因为要实际解码分析更多数据。

这两个参数的取舍逻辑是这样的：如果你只需要知道“有几路流、每路流什么编码”，那-probesize给够就行，-analyzeduration可以设很小甚至为 0。如果你需要精确的时长、平均帧率、码率，那-analyzeduration就得给足，让 ffprobe 分析足够多的帧。我在做批量媒体入库时，通常用-probesize 10000000 -analyzeduration 2000000作为平衡点，既能拿到准确的流信息，又不会让每个文件的探测时间超过一秒。

还有一个隐藏坑：-analyzeduration设得太小，ffprobe 可能报告时长为N/A或者一个明显偏小的值。这是因为它在规定时间内没分析到流的结尾。对于本地文件，其实可以设一个很大的值让它分析完，反正本地读取快；对于网络流，就必须限制，否则等不起。

2.3 输入侧的常见陷阱与规避方法

第一个陷阱是文件名以-开头。比如有个文件叫-weird.mp4，你直接ffprobe -weird.mp4，ffprobe 会把它当成参数解析。解决办法是用--分隔，或者用./-weird.mp4这种相对路径写法。这个坑不常见，但一旦遇到会让人抓狂。

第二个陷阱是输入路径包含特殊字符。空格、中文、括号这些，在 shell 里需要正确转义或者加引号。更稳妥的做法是在脚本里用数组传参，而不是拼接字符串。比如在 bash 里用ffprobe "${args[@]}"而不是ffprobe $args，能避免大量转义问题。

第三个陷阱是权限。ffprobe 需要读权限才能探测文件，如果文件权限不对，报错信息有时候很隐晦，不一定是“Permission denied”，可能是“Invalid data found”。遇到莫名其妙的探测失败，先检查文件是否可读。

第四个陷阱是输入格式误判。有些文件扩展名和实际容器格式不一致，比如.mp4文件实际是 MKV 容器。ffprobe 通常能自动探测出真实格式，但如果你显式指定了-f mp4，它就会按 MP4 解析，然后失败。所以除非是管道输入必须指定格式，否则不要随便加-f。

3. 输出格式的选择：给人看还是给机器读

3.1 默认文本输出：快速查看但难以解析

不带任何输出格式参数时，ffprobe 输出的是人类可读的文本，分两大块：Input 信息和 Stream 信息。Input 块包含容器格式、时长、码率、元数据等；Stream 块每个流一段，包含编码、分辨率、帧率、采样率、声道数等。

这种格式适合快速肉眼查看，比如你想确认一个文件是不是 1080p、音频是不是 AAC。但它的缺点也很明显：字段名不固定，不同版本、不同容器类型输出的字段顺序和名称可能不一样；嵌套层级靠缩进表示，解析起来很麻烦；有些字段只在特定条件下出现，脚本里做字符串匹配很容易漏。

我早期写过一个用 grep 和 awk 解析默认输出的脚本，维护了半年就放弃了，因为 ffprobe 版本一升级，输出格式微调，脚本就挂。后来全部改成 JSON 输出，世界才清净。

3.2 JSON 输出：自动化流程的首选

-print_format json（简写-of json）是绝大多数自动化场景的最佳选择。它把探测结果输出成一个 JSON 对象，结构清晰，字段名稳定，任何语言都能轻松解析。

一个典型的 JSON 输出包含这些顶层字段：streams数组，每个元素是一路流的信息；format对象，包含容器级信息；chapters数组，章节信息；programs数组，节目信息（主要用于 TS 流）。每个流对象里有index、codec_name、codec_type、width、height、r_frame_rate、duration、bit_rate等字段。

用 JSON 输出的标准命令是：ffprobe -v quiet -print_format json -show_format -show_streams -i input.mp4。这里-v quiet是为了屏蔽 ffprobe 自身的日志输出，只保留 JSON 结果，否则日志会混进 stdout，导致 JSON 解析失败。这个细节非常关键，我见过太多人忘了加-v quiet，然后抱怨 JSON 解析报错。

-show_format和-show_streams是控制输出内容的开关。默认情况下，ffprobe 只输出它认为“必要”的信息，加上这两个参数才会输出完整的格式和流信息。如果你还需要帧级信息，加-show_frames；需要包级信息，加-show_packets；需要章节，加-show_chapters。这些开关可以组合使用，但要注意，-show_frames和-show_packets会产生大量输出，一个几分钟的视频可能有几十万帧，JSON 文件会非常大，解析也慢。所以只在真正需要帧级细节时才加。

3.3 XML、CSV、INI 等格式的适用场景

除了 JSON，ffprobe 还支持 XML、CSV、INI、Flat 等输出格式。XML 适合那些已经有 XML 处理管道的系统，结构和 JSON 类似，但更冗长。CSV 适合把流信息导出成表格，方便导入 Excel 或者数据库，但 CSV 格式对嵌套结构的表达能力有限，复杂信息会丢失。INI 和 Flat 是扁平键值对，适合简单的配置式消费，但同样不适合复杂嵌套。

我的建议是：除非下游系统强制要求某种格式，否则一律用 JSON。JSON 的通用性、可读性、解析便利性综合最优。CSV 只在“我就是要一张流信息表格”这种简单场景下用，而且要注意 CSV 输出默认用逗号分隔，如果字段值里本身有逗号，需要额外处理。

3.4 输出内容裁剪：只取你需要的部分

ffprobe 支持用-show_entries精确控制输出哪些字段，这在只需要少量信息时非常有用，能大幅减少输出体积和解析开销。

语法是-show_entries section:field1,field2。比如你只想要每路流的编码类型和分辨率，可以写-show_entries stream=codec_type,width,height。想要格式的时长和码率，写-show_entries format=duration,bit_rate。多个 section 用冒号分隔，比如-show_entries format=duration:stream=codec_name。

这个功能在批量处理时特别香。我有个场景是扫描几万个文件，只需要知道每个文件的时长和视频编码，用-show_entries format=duration:stream=codec_name -of csv输出，每个文件就一行，解析速度极快。如果输出完整 JSON，每个文件几十 KB，几万个文件就是几个 GB 的数据，完全没必要。

提示：-show_entries和-show_format、-show_streams不要混用。用了-show_entries就相当于精确指定了要输出的 section 和字段，再加-show_streams反而可能产生意料之外的输出。

4. 核心字段深度解读：别被字面意思骗了

4.1 时长字段：duration、start_time 与 format.duration 的区别

时长是 ffprobe 输出里最容易被误读的字段之一。流级别的duration和格式级别的format.duration经常不一致，这不是 bug，而是因为它们统计的层面不同。

format.duration是整个容器的时长，通常是最准确的“这个文件播放多久”。流级别的duration是这一路流的时长，对于视频流和音频流，可能因为编码延迟、起始时间偏移等原因，和容器时长有几十毫秒到几秒的差异。如果你要做精确的剪辑或者同步，必须用流级别的时长，并且结合start_time一起算。

start_time是流的起始时间戳，单位是秒。很多容器格式（比如 MPEG-TS）的流不是从 0 开始的，可能从某个非零时间戳开始。如果你直接用duration做进度计算，而不减去start_time，结果就会偏。正确的时长计算是duration本身（ffprobe 报告的 duration 通常已经是相对时长），但如果你在处理时间戳，就要注意start_time的偏移。

还有一个坑：某些流（尤其是网络流或者损坏的文件）的duration会显示为N/A。这时候不能直接拿来做数值计算，必须先判断是否为N/A，是的话要么用format.duration兜底，要么通过其他方式估算。

4.2 帧率字段：r_frame_rate 与 avg_frame_rate 的实战差异

r_frame_rate是“基础帧率”，通常是一个分数，比如30000/1001表示 29.97 fps。avg_frame_rate是“平均帧率”，也是分数。很多人以为这两个总是一样，其实不然。

r_frame_rate是容器或者编码器声明的基础帧率，对于恒定帧率（CFR）视频，它和实际帧率一致。对于可变帧率（VFR）视频，r_frame_rate可能是一个“最大帧率”或者“名义帧率”，而avg_frame_rate才是实际的平均帧率。比如手机录制的视频经常是 VFR，r_frame_rate显示 30，但avg_frame_rate可能是 28.5，因为有些帧间隔更长。

做帧数计算时，用哪个取决于你的目的。如果你要估算总帧数，用avg_frame_rate乘以时长更准。如果你要判断视频是否符合某个帧率标准，看r_frame_rate。如果你要做帧精确的抽帧，最好用-show_frames拿到每一帧的实际时间戳，而不是依赖帧率字段。

分数形式的帧率需要做除法才能得到小数。在脚本里，30000/1001这种字符串不能直接当数字用，得先 split 再除。Python 里可以用fractions.Fraction精确处理，避免浮点误差。

4.3 码率字段：bit_rate 为 N/A 时怎么办

bit_rate字段在流级别和格式级别都有，但经常出现N/A。原因通常是容器没有在头部写入码率信息，或者流是 VBR（可变码率）且没有全局码率声明。

当bit_rate为N/A时，有几种兜底方案。第一，用format.duration和文件大小估算整体码率：文件字节数 * 8 / duration / 1000得到 kbps。第二，用-show_packets统计一段时间内的包大小来估算瞬时码率，但这很耗性能。第三，如果只是要一个大概值，用格式级码率除以流数量粗略分配。

格式级的bit_rate通常比流级的更可靠，因为容器一般会记录总码率。但要注意，格式级码率是音视频加在一起的，如果你要单独的视频码率，还是得从流级拿，拿不到就估算。

4.4 编码参数：profile、level 与 pix_fmt 的实际意义

profile和level是 H.264/H.265 编码的重要参数，决定了编码工具集和码率上限。profile常见值有Baseline、Main、High，level是3.0、4.0、4.1这种。这两个字段在做设备兼容性判断时很关键，比如某些老设备只支持 Baseline profile，你拿到一个 High profile 的视频就得转码。

pix_fmt是像素格式，比如yuv420p、yuv422p、rgb24。yuv420p是最通用的，几乎所有播放器都支持。如果探测到yuv444p或者yuvj420p（全范围 YUV），在某些播放器上可能显示异常，需要转成yuv420p。这个字段在做转码决策时必看。

codec_tag_string是编码标签，比如avc1、hvc1、mp4a。它和codec_name的区别在于，codec_name是 FFmpeg 内部的编码器名称（如h264、aac），codec_tag_string是容器里实际写的标签。有些容器用avc1表示 H.264，用hvc1表示 H.265，做容器兼容性判断时看这个更准。

5. 实操：从零搭建一个可复用的探测脚本

5.1 场景定义与需求拆解

假设我们要做一个媒体资产扫描工具，输入是一个目录，输出是每个媒体文件的关键信息表格，包含：文件名、容器格式、总时长、视频编码、分辨率、帧率、视频码率、音频编码、采样率、声道数。要求能处理几千个文件，输出 CSV 方便导入数据库，遇到探测失败的文件要记录错误而不是中断。

这个需求拆解下来，核心要点是：用 JSON 输出保证解析稳定；用-show_entries裁剪字段减少数据量；用-v quiet屏蔽日志；对每个文件做超时保护；错误处理要健壮。

5.2 命令构造与参数组合

单文件探测命令这样构造：

ffprobe -v quiet -print_format json \ -show_entries format=format_name,duration,bit_rate:stream=index,codec_type,codec_name,width,height,r_frame_rate,avg_frame_rate,bit_rate,sample_rate,channels \ -i "$input_file"

这里-show_entries精确指定了要输出的字段，formatsection 要格式名、时长、码率，streamsection 要索引、类型、编码名、宽高、帧率、码率、采样率、声道数。这样输出的 JSON 体积只有完整输出的十分之一左右。

对于网络流或者可能卡住的输入，加上-analyzeduration 2000000 -probesize 10000000，并且用timeout命令包一层：timeout 30 ffprobe ...。这样即使 ffprobe 卡住，30 秒后也会被杀死，不会堵住整个扫描流程。

5.3 JSON 解析与字段提取

拿到 JSON 后，解析逻辑大概是：先读format对象拿容器级信息，再遍历streams数组，找到codec_type为video的流拿视频信息，找到codec_type为audio的流拿音频信息。注意一个文件可能有多路视频或多路音频，要决定取第一路还是全部记录。我的做法是取第一路视频和第一路音频作为主信息，同时记录流的总数。

帧率字段是分数形式，需要转换。Python 里可以这样处理：

from fractions import Fraction def parse_frame_rate(rate_str): if not rate_str or rate_str == 'N/A': return None try: return float(Fraction(rate_str)) except (ValueError, ZeroDivisionError): return None

用Fraction而不是直接eval或者 split 除法，是因为Fraction能精确处理30000/1001这种分数，避免浮点误差，而且对异常输入更安全。

码率字段可能是N/A或者字符串数字，统一转成整数或 None。时长字段同理。所有字段提取后，组装成一行 CSV 记录。

5.4 批量处理与性能优化

批量处理时，最大的性能瓶颈其实是进程启动开销。每调用一次 ffprobe 就要启动一个进程，几千个文件就是几千次进程创建，在机械硬盘或者慢速文件系统上会非常慢。优化方向有几个：一是用多进程并行，比如 Python 的concurrent.futures.ProcessPoolExecutor，开 4 到 8 个 worker 并行探测；二是减少每个文件的探测数据量，用-probesize和-analyzeduration限制；三是如果文件在同一个目录，可以先用os.scandir快速过滤出媒体文件，避免对非媒体文件调用 ffprobe。

并行度不是越高越好。ffprobe 本身是 CPU 密集型（解码分析），并行太高会导致 CPU 争抢，反而变慢。实测在 4 核机器上，4 个并行 worker 比较合适；8 核机器上 6 到 8 个。另外要注意磁盘 IO，如果文件都在同一块机械硬盘上，并行读取会导致磁头频繁寻道，可能比串行还慢。这种情况下要么限制并行度，要么先把文件复制到 SSD 再处理。

5.5 错误处理与日志记录

错误处理要区分几种情况：文件不存在、文件不可读、格式不支持、探测超时、JSON 解析失败。每种情况都要记录到错误日志，并且继续处理下一个文件，而不是中断。

我的做法是给每个文件包一个 try-except，捕获所有异常，把文件名和异常信息写入错误列表。对于 ffprobe 返回非零退出码的情况，也要捕获 stderr 内容，因为 ffprobe 的错误信息通常在 stderr 里。日志用结构化格式，比如每行一个 JSON，方便后续分析。

实操心得：批量扫描时，先跑一个小样本（比如 100 个文件）验证脚本正确性和性能，再全量跑。我吃过亏，全量跑了几小时才发现字段提取逻辑有个 bug，白跑。

6. 常见问题与排查技巧实录

6.1 输出为空或字段缺失的排查路径

遇到 ffprobe 输出为空，第一反应应该是检查-v参数。如果设了-v quiet，ffprobe 的错误信息也被屏蔽了，你看到的就是一片空白。排查时先把-v改成-v error或者-v warning，看看有没有错误输出。

字段缺失的常见原因是-show_entries没包含该字段，或者该字段在这个文件里确实不存在。比如音频流没有width字段，视频流没有sample_rate字段，这是正常的。脚本里提取字段时要做存在性判断，不能假设字段一定存在。

还有一种情况是容器格式不支持某些元数据。比如 MPEG-TS 容器通常不写时长信息，format.duration可能是N/A。这时候要么用-analyzeduration让它分析更久来估算，要么接受这个限制，用其他方式获取时长。

6.2 探测速度慢的性能瓶颈定位

探测慢的原因通常有三个：探测数据量太大、输入源本身慢、CPU 解码压力大。定位方法是先用time命令测单个文件的探测时间，然后逐步调整-probesize和-analyzeduration，看时间变化。

如果调小这两个参数后速度明显提升，说明瓶颈在数据读取和分析。如果调小后速度没变，说明瓶颈在别处，可能是进程启动开销或者磁盘 IO。对于网络流，瓶颈通常在网络延迟，这时候-analyzeduration设小是关键。

还有一个容易被忽略的点：-show_frames和-show_packets会强制 ffprobe 解码或读取所有帧/包，性能开销极大。如果不需要帧级信息，千万别加这两个参数。

6.3 JSON 解析失败的典型原因

JSON 解析失败最常见的原因是 stdout 里混入了非 JSON 内容。ffprobe 的日志默认输出到 stderr，但某些情况下（比如某些版本的 bug）可能混到 stdout。解决办法是始终加-v quiet，并且解析前先检查输出是否以{开头。

另一个原因是输出被截断。如果 ffprobe 进程被 timeout 杀死，或者管道缓冲区满了，JSON 可能不完整。解析时要捕获 JSON 解析异常，并且记录原始输出以便排查。

编码问题也可能导致解析失败。ffprobe 输出的 JSON 默认是 UTF-8，但如果文件名或者元数据包含非 UTF-8 字符，可能产生非法 JSON。Python 的json.loads对非法 UTF-8 会报错，可以用errors='replace'先做清洗。

6.4 常见问题速查表

6.5 几个我踩过的坑和对应技巧

第一个坑：用-show_entries时，如果 section 名写错，ffprobe 不报错，只是不输出该 section。比如写成streams=codec_name（多了个 s），输出里就没有 stream 信息。排查时先用完整输出确认字段存在，再裁剪。

第二个坑：CSV 输出时，如果字段值包含逗号或换行，CSV 结构会被破坏。ffprobe 的 CSV 输出默认不做转义，所以如果元数据里有逗号，解析会错位。解决办法是改用 JSON，或者在解析 CSV 时用专门的 CSV 解析器而不是 split。

第三个坑：某些容器的format_name是复合的，比如mov,mp4,m4a,3gp,3g2,mj2，表示这一组格式共用同一个 demuxer。做格式判断时不能用等号，要用包含判断。

第四个坑：-of和-print_format是等价的，但有些老版本只认其中一个。写脚本时用-print_format兼容性更好。

第五个坑：ffprobe 的退出码不一定可靠。某些情况下探测失败但退出码是 0，或者探测成功但退出码非 0。所以不能只靠退出码判断成功与否，还要检查输出内容是否有效。

7. 进阶：把 ffprobe 输出接入实际生产流程

7.1 与转码决策系统的对接

在实际的转码流水线里，ffprobe 的输出是决策的输入。比如一个视频进来，先探测它的编码、分辨率、码率、帧率，然后根据目标平台的要求决定转码参数。如果源是 H.264 High profile 1080p 8Mbps，目标是移动端 720p 2Mbps，转码参数就明确了。

这里的关键是把 ffprobe 输出映射成决策系统的内部数据结构。我通常定义一个MediaInfo类，包含容器、时长、视频流列表、音频流列表等字段，ffprobe 的 JSON 解析后填充这个类，后续所有逻辑都基于这个类，而不是直接操作原始 JSON。这样解耦之后，即使 ffprobe 输出格式有变化，只需要改解析层，业务逻辑不受影响。

7.2 媒体资产管理系统中的元数据提取

媒体资产管理（MAM）系统需要把 ffprobe 提取的元数据入库，支持检索和筛选。这时候除了基本的技术参数，还要关注容器和流里的自定义元数据，比如format.tags里的title、artist、comment，以及流级别的tags。

这些 tags 字段在不同容器里差异很大，MP4 的 tags 和 MKV 的 tags 完全不是一套。做入库时要做归一化，把常见的 tags 映射到统一字段，不常见的存成扩展属性。另外要注意 tags 的编码，有些老文件的 tags 是 GBK 编码，直接当 UTF-8 解析会乱码，需要做编码检测和转换。

7.3 监控与告警场景下的轻量探测

在流媒体监控场景里，需要定期探测流的健康状态，比如流是否还在、码率是否正常、帧率是否稳定。这种场景下，探测要轻量、快速、高频，不能像批量扫描那样输出完整信息。

我的做法是用-show_entries format=duration,bit_rate:stream=codec_type,codec_name,bit_rate只取关键字段，配合-analyzeduration 500000 -probesize 1000000限制探测数据量，单次探测控制在 200 毫秒以内。然后对比历史数据，如果码率突降或者流消失，就触发告警。

这种轻量探测的坑在于，探测本身会消耗流的数据，对于某些按流量计费的源，高频探测会产生额外成本。所以探测频率要权衡，通常 30 秒到 1 分钟一次比较合理。

7.4 跨平台脚本的兼容性处理

ffprobe 在 Windows、Linux、macOS 上的行为基本一致，但有几个差异点要注意。路径分隔符不同，Windows 用反斜杠，脚本里最好用正斜杠或者系统 API 处理。换行符不同，Windows 的 stdout 是\r\n，解析时要注意。还有编码，Windows 控制台默认编码可能是 GBK，输出非 ASCII 字符时可能乱码，需要设置PYTHONIOENCODING或者用二进制模式读取再解码。

另外，不同平台安装的 ffprobe 版本可能不同，输出字段可能有细微差异。脚本里对字段的访问要做防御性处理，用.get()而不是直接索引，避免 KeyError。

8. 我个人在实际操作中的几点体会

搞了这么多年媒体处理，ffprobe 是我用得最多的工具之一，也是最容易被低估的工具。很多人觉得它就是个“看信息”的命令，随便跑跑就行，但在自动化流程里，它的输入输出细节直接决定了系统的稳定性和性能。

我最大的体会是：永远不要相信“默认行为”。默认输出格式不适合解析，默认探测深度可能不够也可能过多，默认错误处理可能掩盖问题。每用一个参数，都要知道它为什么存在、不设会怎样、设了会怎样。这种“参数意识”是区分“能用”和“用好”的关键。

另一个体会是：JSON 输出加-show_entries裁剪，是 90% 场景的最优解。完整输出只在调试时用，生产环境一律裁剪。这个习惯能让你的脚本快好几倍，数据量小一个数量级。

最后分享一个小技巧：如果你经常需要探测同一批文件，可以把 ffprobe 的输出缓存起来，用文件路径加修改时间做 key。文件没变就不用重新探测，直接读缓存。这个在媒体库扫描场景下能省大量时间，尤其是文件多但变动少的情况。缓存可以用简单的 JSON 文件或者 SQLite，别用太重的方案，够用就行。