-h 有五个层级，从「一眼」到「全本」。 值钱的不是 -h full，是 -h encoder=名字——它给的是「你这台机器的事实」。
3.4~3.9 把选项过了一遍，这一节讲「怎么自己查」。 因为选项有几千个，记不完，会查比会记重要。
一、五个层级，信息量差几个数量级
-h 的输出长度从几十行到几千行，按需要往下走：
写法 输出什么 什么时候用
-h 最常用的那批选项 先看有没有这个功能 -h long 加上少用的选项 常用里没找到 -h full 全部选项，几千行 要查冷门参数 -h encoder=名字 某个编码器的参数 调编码器细节 -h decoder=名字 某个解码器的参数 极少需要 -h filter=名字 某个滤镜的参数 写滤镜链必查
查的顺序是从第一行往下走，别一上来就 -h full。
几千行里 grep 一个词，比在几十行里看一眼慢得多。
后三行才是真正值钱的：它们打的是「这一类里的某一个」。 网上抄的参数说明常常对应旧版本，而这三条打出来的一定是当前这份构建的。
二、-h encoder= 为什么比博客准
因为它是从这份二进制里直接读出来的，不是别人整理过的文档：
来源 准不准 原因
-h encoder=名字 准 读的是当前二进制的 AVOption 表 官方文档 大致准 对应某个版本，未必是你这个 博客教程 看运气 版本不明、机器不同
-h encoder=libx264 打出来的不只是参数名，还有默认值、取值范围、类型。
这三项齐全，才敢写进脚本——只抄参数名不问默认值，是最常见的坑。
还有一个细节：-h encoder= 后面写的是「编码器名字」，不是「编码格式名字」。
h264 和 libx264 是两个不同的编码器，参数集不通用。
三、把帮助存成文件，离线也能查
三份文件基本覆盖日常所有查询：
命令 存下来查什么
ffmpeg -h full > h.txt 全部选项，grep 最快 ffmpeg -filters > f.txt 468 个滤镜的名字与用途 ffmpeg -codecs > c.txt 编解码器与支持的特性字母
这三份东西比搜索引擎有用的地方在于：它们描述的是「你这台机器」。 搜到的答案可能对别人的机器成立，对你这份构建不成立—— 3.11.1 那个「同一段命令别人能跑你不能跑」的现象，根源就在这里。
导出一次，换机器再导一次，diff 一下就能看出两份构建的差别。 排「为什么这台机器编不出某个格式」时，这个 diff 比逐条试快得多。
四、动手 Demo：库这一层能查到的编码器信息
沙箱里没有 ffmpeg.exe，所以 -h encoder=libx264 没法直接跑。
但它的内容来自 libavcodec 的元数据表，库这一层能读到同一批字段。
这一段就是把那几项读出来，看清 -h encoder= 打的是什么东西。
import av
for name in (u"libx264", u"mpeg4"):
c = av.codec.Codec(name, u"w")
print(u"--- %s ---" % name)
print(u"长名 %s" % c.long_name)
print(u"类型 %s" % c.type)
print(u"能编 %s" % c.is_encoder)
print(u"像素格式 %d 种" % len(c.video_formats or []))
# 滤镜这一层的等价物：-h filter= 里的名字从哪来
fs = sorted(av.filter.filters_available)
print(u"滤镜总数 %d" % len(fs))
print(u"示例 %s" % u", ".join(fs[:5]))
实跑输出：
--------------------------------------------------------------------
3.10 ffmpeg -h 详解——五级帮助，从一眼到全本
--------------------------------------------------------------------
**① -h 的五个层级**
写法 输出什么 什么时候用
---------------------------------------------------------------
-h 最常用的那批选项 先看有没有这个功能
-h long 加上少用的选项 常用里没找到
-h full 全部选项，几千行 要查冷门参数
-h encoder=名字 某个编码器的参数 调编码器细节
-h decoder=名字 某个解码器的参数 极少需要
-h filter=名字 某个滤镜的参数 写滤镜链必查
**从第一行到最后一行，信息量涨了几个数量级，但答案的精度也涨了。**
**所以查参数的顺序是从 `-h` 开始，找不到再往下走，不要一上来就 `-h full`。**
**② 后三行才是真正值钱的**
**`-h encoder=libx264` 打出来的东西，比任何博客都准——**
**它是从这份二进制里直接读出来的，不是别人抄的文档。**
**这一点很重要：网上的参数说明常常对应旧版本，**
**而 `-h encoder=libx264` 打出来的一定是「你这台机器上真支持的那些」。**
**③ 本机这份库能查到的等价信息**
项 值
--------------------------------------------------------------------------
完整名 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
类型 video
能编 True
能解的像素格式数 15
支持的特性和标志 7372834
**这几项就是 `-h encoder=libx264` 里最上面那段的内容。**
**再往下的 `-preset`、`-crf` 这些，是编码器私有的 AVOption，**
**库这一层不暴露，只能在真 exe 上用 `-h encoder=` 查。**
**④ 一个实用习惯：把所有帮助存成文件**
命令 存在查什么
--------------------------------------------------------
ffmpeg -h full > h.txt 全部选项，grep 最快
ffmpeg -filters > f.txt 468 个滤镜的名字与用途
ffmpeg -codecs > c.txt 编解码器与支持的特性字母
**离线时这三份文件比搜索引擎有用，因为它们是「你这台机器的事实」。**
**尤其是 `-filters` 那份，写滤镜链时查它比记文档稳。**
这五项就是 -h encoder=libx264 输出里最上面那段的内容。
再往下的 -preset、-crf、-tune 那些，是编码器私有的 AVOption，
库这一层不暴露，只能在真 exe 上用 -h encoder= 查。
所以这一段能证明的是「元数据在库里」，不能证明「私有参数也查得到」。
这两件事的边界要说清楚，不然读者会以为 Python 里也能查 -crf 的范围。
像素格式那一行值得注意：libx264 的 15 种和 mpeg4 的那一份不一样。
-h encoder= 里那张像素格式表就是这个字段——它决定了你能给 -pix_fmt 填什么。
滤镜那两行是 -filters 的等价物：468 个名字都在这份清单里。
写滤镜链之前查一下有没有，比写完再报错省一轮。
30 秒实验
- 看编码器参数：
ffmpeg -h encoder=libx264，重点看-preset与-crf的取值范围。 - 看滤镜参数：
ffmpeg -h filter=scale，对照-vf scale=能写哪些选项。 - 导出三份清单：
ffmpeg -h full > h.txt、-filters > f.txt、-codecs > c.txt，之后 grep。
常见误区
- 一上来就用
-h full。几千行输出里找参数比在-h那几十行里找慢得多，顺序是从短到长。 - 把
-h encoder=h264当成-h encoder=libx264。h264是内置编码器，libx264是外挂的，参数集不通用。 - 以为 Python 库里能查
-crf范围。私有参数是编码器的 AVOption，库这一层不暴露，只能靠真 exe。
自测三问（点开对答案）
1. `-h`、`-h long`、`-h full` 的关系是什么？ —— 逐级变长：`-h` 只列常用选项，`-h long` 加上少用的，`-h full` 是全部，几千行。 2. 为什么 `-h encoder=libx264` 比网上抄的参数表可靠？ —— 因为它读的是当前这份二进制里的 AVOption 表，而网上文档对应的是别的版本、别的构建。 3. `-h encoder=h264` 和 `-h encoder=libx264` 能换着用吗？ —— 不能。`h264` 是内置编码器，`libx264` 是外挂库，两者的参数名与取值范围都不一样。- ☐ （本节完，下一节 3.11.1 -formats）