做了这么多年视频处理和转码工作，我越来越觉得ffprobe才是真正被低估的工具。很多人拿到一个视频文件，习惯性右键看属性，分辨率、大小、时长似乎都有了，可真到干活的时候就发现完全不够用——编码格式是什么？帧率是30还是29.97？总帧数多少？码率多少？是隔行扫描还是逐行？旋转元数据带着什么角度？这些问题文件管理器一概不回答。
尤其当手里攒了上百个来源不同的视频素材，要批量转码、抽帧、生成预览或统一封装格式时，第一步永远是先把每个文件的"底细"摸清楚。ffprobe 就是那个专门干这事的侦察兵。它是 ffmpeg 家族里负责读取和输出媒体信息的工具，不转码、不处理，只负责把视频文件里里外外看个透。这篇文章我把常用参数、关键字段和真实场景里的脚本写法一次说清楚，包括那些文档里没细讲、实际用起来却特别容易踩的坑，希望对刚开始折腾音视频处理的同学有帮助。
1. 为什么要单独拿它出来说：文件属性里的信息根本不够用
先把需求场景摆出来。不论你是做短视频后期、给课程切片、维护素材库，还是写自动化处理脚本，获取分辨率和帧数往往是第一步。Windows 资源管理器和 macOS 的"显示简介"能给你分辨率、时长、文件大小，撑死了再来个总比特率。但下面这些信息它们就完全无能为力了：
- 视频流和音频流各自的编码格式（H.264、H.265、ProRes、AAC、AC-3）
- 视频的色彩空间、色彩深度、像素格式（yuv420p、yuv444p、p010le）
- 真实帧率，而且分名义帧率、平均帧率和实际帧率
- 总帧数到底是多少
- 视频流里是否带旋转元数据
- 关键帧间隔、GOP 结构
- 音频的采样率、声道布局、码率模式
当时我接了个批量整理素材库的活儿，几百个视频文件来源五花八门，手机拍的、相机录的、网上下的、别人发的都有。我需要先自动识别哪些是竖屏、哪些帧率不统一、哪些编码老旧需要转码。这种时候不能指望人工一个个右键看属性，必须得有个命令行工具批量出报告。ffprobe 就是唯一合理的选择。
再说一句：ffprobe 不是独立生态，它随 ffmpeg 一起分发，但使用上完全独立。你不需要懂转码，不需要管编码器、滤镜、muxer 这些概念，它做的事情就一件——读容器、读流、读包，然后把信息吐给你。所以哪怕你只用它做信息采集，也完全不必有心理负担。
2. 环境准备与版本细节：装好只是开始，PATH和版本才是坑
ffprobe 的安装基本没有难度，常见的三种方式：
- macOS：用 Homebrew 安装 ffmpeg 就会带上 ffprobe，命令是
brew install ffmpeg。 - Windows：从官方或可靠的静态编译站下载 ffmpeg 的 release 包，解压后把 bin 目录加入系统 PATH。
- Linux：Debian/Ubuntu 用
apt install ffmpeg，CentOS/RHEL 可以用yum install ffmpeg，不过 EPEL 源里不一定有，通常还是得装静态包或第三方源。
安装完先验证一下：
ffprobe -version输出的第一行类似ffprobe version 6.1.1 ...，能看到版本号就行。但这里有几个实际工作中让我花过时间的地方，单独说一下：
2.1 多版本冲突：装了某个工具附带的 ffmpeg，又把系统自带的覆盖了
我遇到过不止一次：为了用某个配套工具，装了一个自带 ffmpeg 的软件包，它的 ffmpeg 被放进了 PATH 靠前的目录。后来自己又在 /usr/local/bin 里装了新版 ffmpeg，结果 Shell 里敲ffprobe命中的还是老版本。检查办法很简单：
which ffprobe ffprobe -version如果你发现 version 输出和预期不一致，优先看which的路径。这时要么调整 PATH 顺序，要么直接用绝对路径调用。我不太建议把两个版本混在一个目录里，容易出各种奇怪问题。
2.2 静态编译版和完整版的差异
官方发布页一般有静态编译包和源代码包两种选择。静态包不用管依赖，解压就能跑，适合换环境、丢服务器上用的场景。但有些静态包为了控制体积，某些协议和组件的支持不一定齐全，比如 HTTPS 拉流。如果你只是本地读文件，无所谓；如果将来可能要探测网络流（http/https 协议的媒体地址），建议选择支持齐全的版本。
这里给个建议：日常使用尽量固定一个版本。ffprobe 的输出格式经历了一些调整，不同版本对某些字段的命名略有差异。脚本里做字段解析时，版本不一致可能导致 json 里某个键消失了或换了名字，排查起来非常恼火。
3. 基础输出与常用参数：从一行命令看懂媒体信息的结构
装好之后先随便找一个视频试一下最朴素的用法：
ffprobe input.mp4默认会输出一堆类似这样的信息：
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf58.29.100 Duration: 00:03:08.65, start: 0.000000, bitrate: 3681 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 3429 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc Metadata: rotate : 0 Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 255 kb/s默认输出是给人读的纯文本，字段很多，但不太适合程序解析。实战当中绝大多数情况我推荐用 JSON 格式输出，它的结构化程度好、字段稳定、可读性也强，后面接 Python、jq、awk 都很方便：
ffprobe -v quiet -print_format json -show_format -show_streams input.mp4这个命令我几乎天天用。拆开来看几个关键参数：
-v quiet：关掉所有非必要日志，只保留真正的输出内容。如果不加，ffprobe 默认的 verbose 级别还会打印版本 banner 和一堆提示信息，干扰解析。-print_format json：指定输出 JSON 格式。也可以写成-of json，两者是别名关系。-show_format：输出容器级别的信息，包括总时长、总码率、封装格式、文件大小等。-show_streams：输出每个流（视频流、音频流、字幕流、数据流）的详细信息。
一条命令出来的 JSON 会分成 format 和 streams 两大部分。format 里是封装层的汇总数据，比如：
"format": { "filename": "input.mp4", "nb_streams": 2, "nb_programs": 0, "format_name": "mov,mp4,m4a,3gp,3g2,mj2", "format_long_name": "QuickTime / MOV", "start_time": "0.000000", "duration": "188.650000", "size": "86807735", "bit_rate": "3681398", "probe_score": 100 }streams 则是给定媒体文件里所有独立编解码流的数组，每个元素对应一个流。常见的需求，比如要取出视频流里的分辨率、帧率、编码，遍历这个数组按codec_type过滤就行。
3.1 最省心的默认参数组合是什么
如果你只是想快速拿一段视频的基本信息，不想记一长串参数，我常用的最小化命令是：
ffprobe -v quiet -show_entries stream=index,codec_name,codec_type,width,height,r_frame_rate,avg_frame_rate,nb_frames,duration,bit_rate -of json input.mp4-show_entries负责筛选字段，-of json负责输出格式。这个组合的好处是输出干净，不会把 stream 里几十个字段全抛出来。新手能从里面直接读到编码类型、宽高、帧率、总帧数、时长这些最关键的信息。
不过需要提醒一句：-show_entries里写的字段名必须是真实存在的字段名，拼错一个，该字段不出现在输出里，也不会报错。刚开始用容易懵，所以稳妥的做法是先不加-show_entries完整输出一把，看清楚了再筛字段。下面我就把这些关键字段逐个拆开讲。
4. 视频流与音频流的区分逻辑：读懂 codec_type 和流索引
在实际项目中，你面对的文件很少只有一个流。一个典型的 MP4 文件至少包含一个视频流和一个音频流，有的还塞了字幕流、章节流、甚至数据流。要准确拿到"视频"的信息，就必须知道如何在 streams 数组中把视频流挑出来。
4.1 流的标识：index 和 codec_type
每个流都有两个最基础的属性：
index：流在容器里的序号，从 0 开始。codec_type：流的类型，常见的有video、audio、subtitle、data、attachment。
所以区分视频流很简单：遍历 streams，找到codec_type == "video"的那个流。绝大多数普通 MP4/MOV 文件里只有一个视频流，取第一个即可。但有些文件可能有多个视频流，这就得额外小心。
4.2 多个视频流的处理：select_streams 帮你按需取流
某些专业场景里会见到同一文件包含多条视频流的情况。比如相机录制的视频同时存了主码流和代理码流；或者某下载工具把一个视频的不同分辨率版本封装在了同一个文件里。这时如果只写死取streams[0]，很可能拿到的是代理流或低分辨率版本。
ffprobe 提供了-select_streams参数来按条件筛流：
ffprobe -v quiet -print_format json -show_streams -select_streams v:0 input.mp4v:0表示取第一个视频流。同样的逻辑还有a:0（第一个音频流）、s:0（第一个字幕流）。这个参数在写自动化脚本时特别重要，因为它能保证你取的流是明确指定的，而不是靠运气拿默认的第一个。
我自己的习惯是：脚本里一律显式写明-select_streams v:0。哪怕当前文件只有一个视频流，也要写。因为将来碰到双视频流文件时，程序行为才会符合预期，而不是默默出错。
4.3 流级别的字段长什么样
拿一条视频流的 JSON 片段来看：
{ "index": 0, "codec_name": "h264", "codec_long_name": "H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10", "codec_type": "video", "width": 1920, "height": 1080, "pix_fmt": "yuv420p", "r_frame_rate": "25/1", "avg_frame_rate": "25/1", "duration": "188.000000", "nb_frames": "4700", "bit_rate": "3429000" }这些都是最常碰到的字段。音频流的字段则完全不同，比如sample_rate、channels、channel_layout。这就是前面提到为什么要区分流类型的原因——不同 type 的流，字段集合差异很大。写解析代码的时候千万别用一套字段名硬套所有流。
5. 关键字段逐个拆解：帧率、分辨率、帧数、时长的来龙去脉
下面这部分是这篇文章的干货核心。很多参数光看名字好像能理解，真用起来会发现其中有几个理解偏差特别严重。
5.1 width 和 height：注意旋转元数据的影响
width和height代表的是视频帧的编码尺寸，也就是实际存储的像素宽高。这对大部分视频都没问题，但有一类特殊情况——带旋转元数据的视频。
手机拍的视频经常通过rotate元数据标记方向。比如摄像头传感器横向放置录的竖屏视频，实际存储可能是 1920x1080，但元数据里记着rotate: 90，播放器播放时会旋转显示为 1080x1920。
如果你只看 ffprobe 的width和height，会误判成横屏视频，做竖屏判断、裁剪预览、转码尺寸计算时就会出错。正确做法是把旋转元数据也算进来。常见的处理逻辑是：
- 读取
streams里的side_data_list或帧级元数据中的旋转角度； - 如果旋转角度是 90 或 270，显示宽高要对调。
一个简单的判断脚本思路：
ffprobe -v quiet -print_format json -show_streams -select_streams v:0 input.mp4然后解析出 width、height 和 rotation。rotation 一般在 JSON 里以side_data_list形式出现，也可能在tags里以rotate键存在。写程序时这两种情况都要照顾。
5.2 r_frame_rate 和 avg_frame_rate：最容易搞混的帧率字段
这是整个 ffprobe 里最值得讲清楚的两个字段，也是很多人踩坑的重灾区。
r_frame_rate：从容器/帧信息推导出的帧率，表示"帧时间戳序列里可直接观察到的帧率"。它是一个分数形式，例如"25/1"。avg_frame_rate：平均帧率，是拿总帧数 / 总时长算出来的。
正常恒定帧率（CFR）的视频，两个值通常一致。但遇到可变帧率（VFR）视频，或剪辑中间有丢帧、时间戳跳变的视频，这两个值会出现差异。比如有些屏幕录制工具产出的是 VFR 视频，avg_frame_rate可能是"60.23/1"，r_frame_rate可能是"60/1"或类似分数——这种情况下应该相信哪个？
我的经验是：计算总帧数时用 avg_frame_rate 乘以时长；做精确到帧的工具时优先看 nb_frames。因为平均帧率才是基于实际总帧数推导的，更接近真实情况。后面脚本部分会再展开。
还有个细节：这两个字段都是字符串形式的分数，不是浮点数。直接拿来当数值用会出问题，需要先解析成分子/分母再相除。
5.3 nb_frames 为什么可能是 "N/A"
想获取总帧数，最直接的字段是nb_frames，但它并不总是可靠的。对很多封装格式，尤其是 MP4/MKV，ffprobe 能直接从轨道头或索引里读出帧数。但对某些来源的流媒体文件、传输流（TS）、或者某些不完整的录屏文件，nb_frames会显示为"N/A"。
遇到这种情况不用慌，有两种替代方案：
- 用
avg_frame_rate乘以duration估算帧数，四舍五入后基本准确。 - 用暴力方案：加
-count_frames参数让 ffprobe 逐帧计数。
ffprobe -v quiet -print_format json -count_frames -show_streams -select_streams v:0 input.mp4加上-count_frames后，输出的流信息里会多出nb_read_frames字段，表示实际解码读取到的帧数量。代价是速度慢，大视频可能要跑一会儿。不建议对批量任务默认使用，只在你确实需要精确帧数、且常规字段缺失时用。
5.4 duration 和 format.duration：封装时长的两种存在方式
时长信息其实有两处。format.duration是容器级别的总时长，单位秒，通常由封装层记录；streams里的duration是某个流的时长。正常情况下两者接近，但也不是总一致。比如某些视频开头有一段黑帧或静音，流的时长可能比 format 的短；有些拼接产生的文件，流时长和容器时长也会有细微偏差。
做进度条、剪辑范围、转码时长控制时，以format.duration为准做整体时长参考比较稳妥。它代表的是"整个文件播放时长的底线"，虽然实际播放器的显示时长可能受帧结构影响有微小出入。
5.5 其他值得留意的字段
除了上面这些，统计信息时常用到的还有：
format_name：封装格式，如mov,mp4,m4a,3gp,3g2,mj2。codec_name：编码器类型，如h264、hevc、prores、vp9。pix_fmt：像素格式，如yuv420p、yuv422p、p010le。profile：编码档次，如High、Main、Baseline。level：编码级别，数字字符串。bit_rate：流码率，注意也可能缺失。sample_rate、channels、channel_layout：音频流的采样率、声道数、声道布局。tags：容器或流里的元数据，比如rotate、creation_time、encoder等。
做媒体资产管理时，我一般会建类似这样的表格：
| 用途 | 字段 | 所属层级 | 备注 |
|---|---|---|---|
| 分辨率 | width, height | stream | 注意旋转元数据 |
| 帧率 | r_frame_rate, avg_frame_rate | stream | 分数形式，需解析 |
| 总帧数 | nb_frames | stream | 可能为 N/A |
| 编码格式 | codec_name | stream | h264/hevc/prores |
| 像素格式 | pix_fmt | stream | 色度采样 |
| 总时长 | duration | format | 秒为单位 |
| 总码率 | bit_rate | format | 单位 bps |
| 封装格式 | format_name | format | mov/mp4/mkv |
6. 三个贴脸场景的实战脚本：批量给视频"体检"
光知道参数还不够，下面给三个我实际用过很多次的脚本场景，可以直接抄走改改就用。环境默认是 bash + Python3，ffprobe 已加入 PATH。
6.1 批量扫描目录，输出视频信息 CSV
这是最常用的。假设有一个文件夹，里面全是视频素材，需要生成一份包含文件名、分辨率、时长、编码、帧率的清单。用 bash 循环加 jq 就能实现，但如果环境里没有 jq，用 Python 更稳：
#!/bin/bash for f in *.mp4 *.mov *.mkv; do [ -e "$f" ] || continue ffprobe -v quiet -print_format json -show_format -show_streams "$f" > "$f.json" done然后 Python 统一解析：
import json, os, glob rows = [] for json_file in glob.glob('*.json'): with open(json_file, 'r') as fp: data = json.load(fp) video_stream = next( (s for s in data['streams'] if s.get('codec_type') == 'video'), None ) if not video_stream: continue fmt = data.get('format', {}) w = video_stream.get('width', 'N/A') h = video_stream.get('height', 'N/A') fps = video_stream.get('avg_frame_rate', 'N/A') nb = video_stream.get('nb_frames', 'N/A') dur = fmt.get('duration', 'N/A') codec = video_stream.get('codec_name', 'N/A') rows.append([ os.path.splitext(json_file)[0], f'{w}x{h}', fps, nb, codec, dur ]) with open('report.csv', 'w') as fp: fp.write('文件名,分辨率,帧率,总帧数,编码,时长\n') for row in rows: fp.write(','.join(map(str, row)) + '\n')注意两个细节：文件名里的逗号会破坏 CSV 列对齐，实际使用建议用制表符分隔或加引号转义；字符串类型的avg_frame_rate不要直接当数字用。
6.2 判断服务器上的视频是不是竖屏，便于分渠道处理
短视频平台对横竖屏的素材规格通常有不同要求。竖屏判断不能只看 width 和 height，要结合旋转元数据。逻辑如下：
def is_portrait(probe_json): for s in probe_json.get('streams', []): if s.get('codec_type') != 'video': continue w = s.get('width', 0) h = s.get('height', 0) rotation = 0 # 优先从 side_data_list 读取旋转角度 for side_data in s.get('side_data_list', []): if side_data.get('side_data_type') == 'Display Matrix': rotation = abs(side_data.get('rotation', 0)) break if not rotation: rotation = int(s.get('tags', {}).get('rotate', 0) or 0) rotation = rotation % 360 if rotation in (90, 270): w, h = h, w return h > w return False之前用这个脚本跑过一批素材，发现有接近三成的手机视频在 ffprobe 里是宽大于高的，但实际播放是竖屏，光靠 width/height 判断会送错渠道。
6.3 估算视频总帧数，为抽帧任务做规划
抽帧任务通常需要知道源视频有多少帧，来决定抽帧间隔或预计产出数量。前面说过nb_frames可能缺失，所以写一个兜底逻辑：
import json, subprocess def get_frame_count(path): result = subprocess.run([ 'ffprobe', '-v', 'quiet', '-print_format', 'json', '-show_streams', '-select_streams', 'v:0', path ], capture_output=True, text=True, check=True) data = json.loads(result.stdout) stream = data['streams'][0] if stream.get('nb_frames', 'N/A') not in ('N/A', None, ''): return int(stream['nb_frames']) # 兜底：用平均帧率 * 时长估算 avg_fps = stream.get('avg_frame_rate', '0/1') num, den = map(int, avg_fps.split('/')) fps = num / den if den else 0 dur = float(stream.get('duration', 0)) return int(round(fps * dur))这个函数的逻辑是优先相信 nb_frames，缺失时才用平均帧率估算。对于批处理场景，速度比无限加-count_frames快得多，精度也够用。
7. 实战中遇到过的坑：ffprobe 不报错，但结果就是不对
这部分记录一些我实际遇到过的、比较坑的情况。这些坑不一定导致程序崩溃，但会让输出结果不对，而且不仔细看很难发现。
7.1 可变帧率导致帧率显示"奇奇怪怪"
屏幕录制和部分网络视频是 VFR（可变帧率）。在这类文件上，r_frame_rate和avg_frame_rate经常不一致。比如我遇到过r_frame_rate = 60/1、avg_frame_rate = 59.97/1的文件，也有遇到过r_frame_rate = 15360/256这种奇怪分数的。
写代码时，如果直接把"15360/256"当成字符串和其他值比较，结果一定不对。正确做法是统一转浮点：
def rational_to_float(s): num, den = s.split('/') return float(num) / float(den)7.2 中文文件名和带空格路径的引号问题
这一点在脚本场景里极其常见。Windows 上路径带空格、中文，甚至 emoji 都有。命令行里直接写ffprobe 我的视频 1080p.mp4一定会出问题。我的统一经验是：在脚本里用 subprocess 传参时，不要把命令拼成字符串，要传列表。
比如 Python 里正确的是这种：
subprocess.run(['ffprobe', '-v', 'quiet', '-print_format', 'json', '-show_format', '-show_streams', path])而不是：
subprocess.run(f'ffprobe -v quiet -print_format json -show_format -show_streams {path}') # 错误后者一旦路径里有空格就炸。如果是 Shell 脚本，记得给变量加双引号：ffprobe -v quiet -of json -show_streams "$f"。
7.3 有些封装格式的 duration 存在但不准
FLV、TS、某些 WebM 文件，常遇到duration是N/A的情况，或者容器记录时长和实际可播放时长不一致。这跟封装容器的特性有关。如果你要处理的是直播录制或网络抓取的流媒体文件，建议多依赖-count_frames或解码时长来校验，别轻信容器时长。
7.4 多语言音轨/字幕流的干扰
有的文件有几十个字幕流或多余的数据流，用-show_streams时输出 JSON 会非常大，还容易干扰解析。前面建议用-select_streams限定范围，或者解析时直接按codec_type过滤。我见过有人写代码直接取streams[0]，结果文件第一个流是字幕，后面代码拿到一堆 None，查了半天才发现是流索引问题。
7.5 帧率字段是分数而不是整数
这个坑前面提过，再强调一次。"25/1"和"30000/1001"都正常，前者是标准 25fps，后者是 NTSC 29.97fps 的准确表示。如果你拿到"30000/1001"直接转 int，结果会变成 30000，完全不对。必须按分数处理，除以分母后才得到 29.97。
7.6 需要读取网络流信息时，时间可能很长
如果给 ffprobe 传一个 http/https 地址，它默认会做探测，读取一部分数据再返回信息。遇到网络不好或服务器响应慢，命令可能卡住很久。建议加超时控制。命令行本身没有原生超时参数，需要靠外部控制，比如 Python 的timeout参数，或者 Shell 的timeout命令。
timeout 15 ffprobe -v quiet -print_format json -show_format -show_streams "https://example.com/file.mp4"如果探测失败，ffprobe 会返回非零退出码，脚本里要做好对应的错误处理。
8. 更进阶的玩法：ffprobe 远不止获取分辨率和帧数
最后聊几个进阶用法，给已经能熟练拿到基本信息的同学一些拓展思路。
8.1 -show_frames 和 -show_packets：深入帧级信息
-show_frames能列出文件中每一帧的详细信息，包括帧类型（I/P/B）、时间戳、大小、是否为关键帧等。这在分析 GOP 结构、定位 I 帧位置、做抽帧服务时非常有用。
ffprobe -v quiet -print_format json -show_frames -select_streams v:0 input.mp4输出会非常大，几十秒的视频就能产生几十 MB 的 JSON。实际使用时一般配合-read_intervals限制读取范围：
ffprobe -v quiet -print_format json -show_frames -read_intervals "%+5" -select_streams v:0 input.mp4上面这条命令只读取前 5 秒的帧信息，分析 GOP 或检查关键帧间隔足够用了，不会让终端卡死。
-show_packets则是看包级别的信息，适合分析码流的时间戳是否连续、是否有 B 帧、是否有包丢失。排查点播卡顿、时间戳回退问题时我会用它。
8.2 结合 ffmpeg 做"探测后自动处理"的管道
实际工作中我经常把 ffprobe 和 ffmpeg 串起来用。比如一个批处理脚本：先用 ffprobe 判断视频编码，如果是 H.264 且宽度不大于 1920，就跳过转码；如果编码是 MJPEG 或宽高超过阈值，就交给 ffmpeg 执行转码。这比"全部无脑转码"节省大量 CPU 和时间，也是 ffprobe 在自动化工作流中真正的价值所在——作为决策者，在我们的处理管线最前面做分类判断。
我之前做过一个素材预处理服务，核心逻辑就是：
- 用 ffprobe 探测每个文件的编码、分辨率、时长、旋转角度；
- 根据策略决定是否转码、是否需要旋转校正、是否需要抽帧用于预览；
- 把决策结构和源路径写进 CSV，后续任务调度器读取 CSV 执行 ffmpeg 任务。
整个过程零人工干预，靠的就是 ffprobe 给出的那堆字段来做规则判断。所以不要把它只当成"看一眼分辨率的小工具"，它在自动化处理链路里完全有资格当一个独立模块。
8.3 用 ffprobe 分析黑帧、静音段落
除了基本字段，ffprobe 配合-show_frames还能做内容层面的粗分析。比如持续输出每一帧的pkt_size，结合 ffmpeg 的blackdetect滤镜可以定位视频中的黑场段落。当然这种需求更适合直接上 ffmpeg，ffprobe 的定位是"信息采集"，两者配合用互补性很强。
后记
我用 ffprobe 处理过的文件少说也有几万个了，从手机随手拍的小短片到多轨 ProRes 工程都遇到过。最大的体会是：真正难的不是跑通命令，而是理解输出字段背后的含义。写脚本时把分数解析、流索引选择、旋转元数据、VFR 这些边界情况都处理好，你的探测代码才算真正健壮。
最后再分享一个小技巧：如果你想把 ffprobe 的输出当作文本快速看，但又嫌 JSON 太长，可以用-of compact_pretty：
ffprobe -v quiet -of compact_pretty -show_entries stream=index,codec_name,width,height,avg_frame_rate,nb_frames input.mp4这种格式每行一个键值对，既保留了 JSON 的结构信息，又比完整 JSON 短得多，适合在终端里快速扫一眼结果。可以先从这条命令开始玩，等需要更复杂的数据处理时再切回到标准 JSON 输出。
