源码编译 FFmpeg，八成时间都花在"喂饱依赖"上——configure 每报一个错，就是缺一个库。本章跟着包青天逐个断案：先看清 20+ 个依赖库怎么分类，再掌握排错主循环，用 x264 / gnutls / opus 三大经典案例练手，最后对照 brew / apt 包管理派的捷径
核心方法论：铁面无私（证据链断案）
「断案讲究证据链，编译排错也一样：configure 的每一行输出都是证词。一个『gnutls not found』背后，可能藏着没装、装错版本、依赖没装全、低版本残留四桩案子——不放过任何一条线索，也不冤枉任何一个库。记住口号：每一个报错都不能放过。学完本章，你看到任何 configure 报错，第一反应不再是『怎么办』，而是『它到底缺什么』。」
上一章我们跑通了 ./configure → make → make install 的主流程。但第 5 章用的是"最小配置"——真正的 FFmpeg 想要支持 H.264、H.265、Opus、MP3、字幕烧录、TLS 推流，背后要站着一大排第三方库。素材里（2019-2020 年，CentOS 7，FFmpeg n4.1.1）作者一口气解决了 20 多个依赖，光是 configure 就重跑了十几轮。这些库可以按职责分成五类：编解码库（负责把音视频压进/解出某种格式）、滤镜/字幕库（负责画面处理和字幕渲染）、网络库（负责 HTTPS/TLS 加密传输）、图像库（负责 JPEG 2000 等图像格式）、杂项（音频重采样、设备采集等边角功能）：
| 分类 | 库 | 干什么的（说人话） | FFmpeg 配置开关 |
|---|---|---|---|
| 编解码 | x264 / x265 / xvid / openh264 | H.264、H.265 视频编码 | --enable-libx264 等 |
| 编解码 | opus / vorbis / theora | 音频 / 视频开源编码（Xiph 家族） | --enable-libopus 等 |
| 编解码 | gsm / opencore-amr / mp3lame | 电话音频、AMR、MP3 编码 | --enable-libmp3lame 等 |
| 滤镜/字幕 | libass / freetype | 字幕渲染（ASS 字幕）、字体绘制 | --enable-libass 等 |
| 网络 | gnutls / openssl | TLS 加密，HTTPS 拉流推流 | --enable-gnutls |
| 图像 | openjpeg / opencv | JPEG 2000 编解码、图像处理 | --enable-libopenjpeg |
| 杂项 | soxr / pulse / speex | 高质量重采样、音频设备、降噪 | --enable-libsoxr 等 |
先别急着背这 20 多个名字。包青天断案的第一步是"看现场"：configure 报错时，错误信息里会直接写出缺的库名——比如 ERROR: libx264 not found，你就去装 x264；装完重跑 configure，它可能又报下一个。这就像过一关解锁下一关。所以第 5 章末尾提到的"基础环境"那一条 yum 命令其实大有深意——它把最常见的一批开发库一次性装好，就是为了少过几关（素材实录，历史命令）：
# 素材实录（CentOS 7，yum）：先把基础编译工具链 + 常用依赖装齐
yum -y install autoconf automake freetype-devel gcc gcc-c++ git \
libtool make nasm pkgconfig zlib-devel bzip2 bzip2-devel# 素材实录：设置 PKG_CONFIG_PATH——让 pkg-config 能找到"自己编译"的库
export PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig:/usr/lib64/pkgconfig:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig这里藏着全章最重要的一课：FFmpeg 自己不实现 H.264 编码，它只是"请" x264 来干活。configure 的 --enable-libx264 不是开关，是"招聘启事"——前提是 x264 已经装好、并且 pkg-config 能找到它。而 PKG_CONFIG_PATH 就是告诉 pkg-config"去这些目录找简历"的路径清单。素材里这句 export 是后来所有源码编译能否被 ffmpeg 识别的前提，第 6.6 节实测时会再验证它的作用。
素材作者的原话值得抄下来："配置好 configure 之后，通过 make 可以一步步试探你缺少的库是什么，然后下载、编译。" 换句话说：源码编译 FFmpeg 的正确姿势不是"先装齐所有依赖再一次成功"，而是"跑 configure → 看报错 → 补依赖 → 重跑"这个循环。每轮循环你都会对"FFmpeg 到底依赖什么"多一分认识，十几轮下来，你就把依赖地图背下来了。这个循环四步走：① 读报错，确定缺什么；② 判断用包管理还是源码编译；③ 安装；④ 重跑 configure，看下一个报错。
报错信息的格式有规律可循。素材里最典型的两种：一种是 ERROR: xxx not found using pkg-config——库没装或者 pkg-config 找不到；另一种是 ERROR: libxxx not found 之后跟着一行提示"如果你要支持 xxx，请安装相应开发包"。注意 ./configure --help 是免费的"题库"：所有 --enable-xxx 开关列得清清楚楚，你可以对照着看自己到底想开哪些功能，而不是被默认行为牵着走。素材里记录的 make 常用命令也一并列出（注意素材原文把 distclean 误写成了 disclean——这种笔误正好说明：素材会骗人，报错不会）：
# 排错主循环的第一现场：configure 的输出（格式如素材截图实录）
./configure --enable-gnutls --enable-libx264 --enable-libx265 --enable-libopus
# 报错样例 1：pkg-config 找不到库
ERROR: gnutls not found using pkg-config
# 报错样例 2：找不到开发头文件
ERROR: libx264 not found
# 每一轮循环的"三连"：改配置 → 编译 → 安装
make -j 10 # 并行 10 核编译（素材原话：可自行调整）
make install # 安装到 /usr/local
make clean # 清除编译产物，重新来
make distclean # 还原 configure 状态（素材原文误写为 disclean）# configure --help：免费的"题库"，所有开关一览（真实选项，节选）
./configure --help
# --enable-gnutls enable GnuTLS, needed for https support
# --enable-libx264 enable H.264 encoding via x264 [no]
# --enable-libx265 enable HEVC encoding via x265 [no]
# --enable-libopus enable Opus decoding and encoding via libopus [no]
# --disable-everything disable all components注意：同一个报错 xxx not found，背后可能是四桩不同的案子，绝不可一刀切：① 没装（最常见，装上即可）；② 装了但 pkg-config 找不到（PKG_CONFIG_PATH 没配，或装到了非标准目录）；③ 装了错误的版本（太老或太新，6.3 节的 gnutls 就是版本坑）；④ 装了但残留低版本干扰（6.5 节的 opus 就是残留坑）。包青天的办案原则：先取证（看完整报错和 pkg-config --modversion 输出），再动手——每一条报错都不能放过，也不要用"重装一遍试试"掩盖真相。
第一个经典案例是 gnutls——FFmpeg 的 --enable-gnutls 用来支持 HTTPS 拉流推流（说人话：让 FFmpeg 能访问 https:// 开头的地址）。素材里 configure 报 ERROR: gnutls not found，作者选择源码编译 gnutls。但 gnutls 不是光杆司令，它依赖 nettle（一个底层密码学库，提供 AES 等加密算法），所以安装顺序必须是 先 nettle、再 gnutls。素材原文这里有个笔误——"安装 gnutls 需要先安装 gnutls"，实际是"先安装 nettle"。这正好是包青天的教学时刻：素材也会出错，但 configure 的报错链不会，跟着报错链走就对了。
更关键的坑在版本：素材明确记录gnutls 3.5.19 是可以的，大于这个版本的有问题。在 2020 年的 CentOS 7 上，新版本 gnutls 与系统自带的 nettle/gmp 版本不匹配，configure 或运行时就会翻车。所以作者没有 yum install 最新的 gnutls，而是精确下载 gnutls-3.5.19.tar.xz 源码编译。这就是"依赖思维"的第一课：不是最新就好，匹配才好。完整过程（素材实录，历史命令）：
# 第 1 步：先装 nettle（gnutls 的密码学底层）
wget https://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz
tar zxf nettle-3.1.1.tar.gz
cd nettle-3.1.1
./configure --enable-shared
make && make install
# 第 2 步：装 gnutls 3.5.19——素材原话：3.5.19 可以，大于此版本有问题
wget https://www.gnupg.org/ftp/gcrypt/gnutls/v3.5/gnutls-3.5.19.tar.xz
xz -d gnutls-3.5.19.tar.xz
tar xf gnutls-3.5.19.tar
cd gnutls-3.5.19
./configure --enable-shared
make && make install但 gnutls 的 configure 不是一次过的——素材里它接连报出 gmp、libtasn1、unistring、p11-kit、unbound 五个依赖错误，作者逐个 yum install 补齐；其中 libtasn1 和 unistring 还有"内置版"开关可以绕过系统库（--with-included-libtasn1 表示"用 gnutls 自带的 libtasn1，别去找系统的"）。这轮连环排错是 6.2 节主循环的最佳范本：每报一个错就补一个，补完重跑，直到 configure 说 "configuration succeeded"：
# gnutls configure 连环报错，逐个击破（素材实录）
ERROR: gmp not found
yum install gmp-devel
ERROR: libtasn1 not found
yum install libffi libffi-devel
./configure --enable-shared --with-included-libtasn1
ERROR: libunistring not found
yum install libunistring-devel
./configure --enable-shared --with-included-unistring
ERROR: p11-kit not found
yum install p11-kit-devel
ERROR: dnssec not found
yum install unbound unbound-devel unbound-libs注意：gnutls 的版本坑在今天依然存在，只是换了个形式——Homebrew 的 gnutls 与 macOS 系统自带的 OpenSSL 互不干扰，但如果你在旧系统上装新 gnutls，或者在一个系统里同时存在系统版和源码版 gnutls，pkg-config 就会"找错人"。通用对策：装库前先 pkg-config --modversion gnutls 查版本，装完后用 pkg-config --cflags --libs gnutls 验证能不能被找到——包青天办案，先验明正身。
依赖链是有方向的：先装被依赖的，再装依赖别人的。nettle → gnutls，libogg → libtheora（素材里 theora 报错就靠 yum install libogg* 解决），libffi → libtasn1 → gnutls。这条链上的任何一环缺失，报错都会出现在"最上层"的库里——所以看到一个库报错，先问一句：它的底层装齐了吗？
第二个经典案例是 x264——FFmpeg 最常用的 H.264 编码器。素材里作者 git clone 源码编译 x264，configure、make、make install 一路顺利，结果 FFmpeg 那边一编译就报错，回头查才发现是 x264 的汇编优化需要 nasm（nasm，说人话：x86 汇编器，负责把 x264 里手写的汇编代码翻译成机器码，让编码速度翻倍）。没有 nasm，x264 编译时只能退化成 C 语言版本，甚至直接报错。于是作者又去源码编译了 nasm-2.13.02。这个故事告诉我们：缺库不只是缺"功能库"，还可能缺"工具库"——编译器、汇编器、构建系统本身也是依赖。
更隐蔽的一类是"构建方式不同"：素材里 openjpeg 没有 configure 脚本，必须用 cmake 构建（cmake，说人话：另一套自动化构建工具，和 autotools 的 configure/make 是竞争关系）。如果你习惯性 ./configure，会直接得到 No such file or directory。x265 也一样走 cmake。所以判断一个源码包怎么装，先看它根目录有没有 configure 或 CMakeLists.txt——这就是包青天的"验尸"环节。素材实录：
# x264：git 拉源码编译（素材实录）
git clone --depth 1 http://git.videolan.org/git/x264
cd x264
./configure --enable-shared
make && make install
# 之后 FFmpeg 编译报错 → 追查发现缺 nasm（汇编优化必需）
# 补装 nasm 2.13.02（素材实录：源码编译）
curl -O -L http://www.nasm.us/pub/nasm/releasebuilds/2.13.02/nasm-2.13.02.tar.bz2
tar -xjvf nasm-2.13.02.tar.bz2
cd nasm-2.13.02
./autogen.sh && ./configure --enable-shared
make && make install# openjpeg：没有 configure，走 cmake（素材实录）
git clone https://github.com/uclouvain/openjpeg.git
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j 10 && make install
# x265：同样走 cmake（素材实录）
git clone --depth 1 https://github.com/videolan/x265.git
cd x265/build
cmake ../source && make && make install
# 连带案例：soxr 的 ./go 脚本内部也要用 cmake——报错就升级 cmake
# （素材：为此源码编译了 cmake-3.13.0-rc1）判断"一个源码包怎么装"，看三个信号：① 根目录有 configure → autotools 老路子，./configure && make && make install；② 有 CMakeLists.txt → cmake 新路子，mkdir build && cd build && cmake ..；③ 有 autogen.sh → 源码树没生成 configure，先跑 ./autogen.sh。素材里 vorbis 就是先 ./autogen.sh 再 configure。记不住也没关系——ls 看一眼目录，比背文档快。
第三个案例最刁钻：opus（说人话：新一代开源音频编码，VoIP 和 WebRTC 的标准音频格式，FFmpeg 的 --enable-libopus 就是请它来编 Opus 音频）。素材里作者源码编译了 opus-1.2.1，路径也配了，PKG_CONFIG_PATH 也设了——但 configure 依然报 opus 找不到。包青天式的追问来了：库在不在？在。路径对不对？对。那问题出在哪？系统里还残留着一个 yum 装的低版本 opus 1.0.2——两个版本打架，pkg-config 优先找到了旧的那个，而旧版本对 FFmpeg 来说"不够格"。
作者的处理方式很彻底：用 yum remove 把低版本连同它的工具链全部卸干净，只留源码编译的 1.2.1，再重跑 configure 就通过了。这个案例补全了 6.2 节 warning 里的第四桩案子：报错不一定代表"没有"，也可能是"有但被更差的顶替了"。这在今天同样常见——Homebrew 装了一版、源码又装了一版、系统还自带一版，三版共存时 pkg-config 只认它先找到的那个。素材实录：
# opus 1.2.1 源码安装（素材实录）
wget http://downloads.xiph.org/releases/opus/opus-1.2.1.tar.gz
tar -zxvf opus-1.2.1.tar.gz
cd opus-1.2.1
./configure && make && make install
# 一切就绪却仍报错 → 查残留：yum 装的低版本 opus 在捣乱（素材实录）
yum remove opus-1.0.2-6.el7.x86_64 opus-tools-0.1.6-1.el7.x86_64 \
opusfile-0.5-1.el7.x86_64 opus-devel-1.0.2-6.el7.x86_64 \
opusfile-devel-0.5-1.el7.x86_64
# 卸干净后重跑 configure，opus 1.2.1 一次通过注意：排查"版本残留"有一个标准取证流程：pkg-config --modversion opus 看 pkg-config 认的是哪个版本；ls /usr/lib64/libopus*（或 brew list --formula | grep opus）看系统里到底躺着几个 opus；再用 ldd 或 otool -L 看最终链接到哪个。包青天办案原则：删库之前先取证，确认哪个版本是"主犯"，避免误删无辜。
# 版本残留标准取证流程（本机可跑，2026-08-08 实测）
pkg-config --modversion opus # ① pkg-config 认的是哪个版本？
brew list --formula | grep opus # ② Homebrew 装了几版？
find /opt/homebrew /usr/local -name 'opus.pc' 2>/dev/null # ③ 所有 .pc 文件的位置
otool -L $(which ffmpeg) | grep opus # ④ 最终链接到哪个（Linux 用 ldd）素材是 2019-2020 年的 CentOS 7 时代，那时 yum 仓库里的 x264、opus 等往往版本老旧甚至没有，逼得作者走"源码派"（手工下载源码、configure、make、make install）。而 2026 年的今天，macOS 的 Homebrew 和 Ubuntu 的 apt 都维护着最新版依赖，一条命令顶得上素材里半天的功夫——这是"包管理派"。但请务必理解：本章教的不是背命令，而是"依赖思维"。包管理派只是把"装库"这一步自动化了，分类、版本匹配、依赖链、残留排查这些判断，一条命令都省不掉。对照如下：
| 依赖 | 源码派（素材，CentOS 7 / yum） | 包管理派 macOS（brew） | 包管理派 Ubuntu（apt） |
|---|---|---|---|
| H.264 编码 | git clone x264 + nasm 源码编译 | brew install x264 | apt install libx264-dev |
| H.265 编码 | x265 源码 cmake 编译 | brew install x265 | apt install libx265-dev |
| Opus 音频 | opus-1.2.1 源码 + 清理残留 | brew install opus | apt install libopus-dev |
| TLS/HTTPS | nettle + gnutls 3.5.19 源码链 | brew install gnutls | apt install libgnutls28-dev |
| 字幕/图像/杂项 | libass / openjpeg / soxr 等逐个击破 | brew install libass openjpeg soxr speex | apt install libass-dev libopenjp2-7-dev |
口说无凭，下面全部是本章写作时在本机（macOS，Homebrew）真实执行的实测。实测①：本机装了哪些依赖——注意 gnutls / nasm / opus / x264 / x265 五个全在，这正是"包管理派已把素材的源码活干完"的直接证据：
# 实测 ①：本机依赖清单（真实输出，2026-08-08）
$ brew list --formula | grep -E 'x264|x265|opus|gnutls|nasm'
gnutls
nasm
opus
x264
x265实测②：ffmpeg -version 的 configuration 行直接交代了这份 ffmpeg 编译时启用了哪些库——对比 6.1 节分类表，你会发现素材里 20 多个依赖几乎全部被 Homebrew 版 FFmpeg 收编了（--enable-libx264、--enable-libx265、--enable-libopus、--enable-gnutls、--enable-libmp3lame、--enable-libopenjpeg、--enable-libass 等）。这就是"断案看证据"：一个 ffmpeg 能干什么，configuration 行说了算：
# 实测 ②：ffmpeg 8.1.1 configuration 行（真实输出，节选）
$ ffmpeg -version
ffmpeg version 8.1.1 Copyright (c) 2000-2026 the FFmpeg developers
configuration: --prefix=/opt/homebrew/Cellar/ffmpeg-full/8.1.1 \
--enable-gnutls --enable-libx264 --enable-libx265 --enable-libopus \
--enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libxvid \
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg \
--enable-libspeex --enable-libsoxr --enable-libass --enable-libfreetype \
--enable-videotoolbox --enable-audiotoolbox实测③和④是本节的"压轴大戏"：先用 ffmpeg -encoders 确认 libx264、libx265、libopus 真的可用（V 开头表示视频编码器，A 开头表示音频编码器），然后真实执行一次 H.265 转码——libx265 编码 20 帧耗时 0.02 秒（约 1027 fps），输出文件正常生成。没有 x265 依赖的 ffmpeg 到这里会直接报 Unknown encoder 'libx265'，就像实测⑤模拟的那样：
# 实测 ③：可用编码器（真实输出，grep 过滤）
$ ffmpeg -encoders | grep -E '264|265|opus'
V....D libx264 libx264 H.264 / AVC / MPEG-4 AVC ... (codec h264)
V....D libx265 libx265 H.265 / HEVC (codec hevc)
A....D libopus libopus Opus (codec opus)
# 实测 ④：libx265 真实转码（真实输出）
$ ffmpeg -i in.mp4 -c:v libx265 -preset ultrafast -c:a copy out_h265.mp4
x265 [info]: frame B: 14, Avg QP:31.61 kb/s: 6.85
encoded 20 frames in 0.02s (1027.64 fps), 39.50 kb/s, Avg QP:30.96
# 实测 ⑤：模拟"缺库"——用不存在的编码器，报错即"缺库"现场（真实输出）
$ ffmpeg -i in.mp4 -c:v libnonexistent out.mp4
[vost#0:0] Unknown encoder 'libnonexistent'
[vost#0:0] Error selecting an encoder
Error opening output file out.mp4.把三节课串成一句话：依赖思维 = 分类（6.1）+ 排错循环（6.2）+ 三桩经典案例（6.3-6.5）。素材用十几个小时踩出来的坑，在包管理派手里就是一条 brew install；但如果你只记住命令而没记住思维，换个平台、换个版本、换个报错，你就又回到原点。下一章我们继续顺着这条线往下走——第 7 章《启用 GPU 硬编解码：configure 与版本匹配》，届时 nv-codec-headers 与 CUDA 的版本匹配，将是比 gnutls 3.5.19 更严格的一桩"铁案"。包青天把证据链先给你备好：硬件型号 → 驱动版本 → SDK 版本 → FFmpeg 开关，一环对不上就一环报错。我们第 7 章见。
把下列库归入五类之一：x264、libass、gnutls、openjpeg、soxr。候选分类：编解码库 / 滤镜·字幕库 / 网络库 / 图像库 / 杂项。
回想 6.1 节的分类表：每个库在 FFmpeg 里负责什么功能？H.264 编码、字幕渲染、HTTPS、JPEG 2000、音频重采样，各自对应谁？
x264 → 编解码库（H.264 编码）；libass → 滤镜/字幕库（ASS 字幕渲染）；gnutls → 网络库（TLS/HTTPS）；openjpeg → 图像库（JPEG 2000）；soxr → 杂项（高质量音频重采样）。判断口诀：先问它服务哪种数据、哪种功能，再对号入座。
把下面五步排成正确的排错顺序，并说明每一步的目的：A. 安装/编译缺失的库；B. 重跑 configure 看下一个报错；C. 运行 ./configure 观察报错；D. 判断该用包管理还是源码编译；E. 从报错信息中确认缺的是哪个库。
6.2 节的四步主循环：读报错 → 判断方案 → 安装 → 重试。五步只是把它拆得更细。
C → E → D → A → B。C 先跑 configure 让错误暴露；E 从报错里锁定缺哪个库（如 ERROR: gnutls not found）；D 判断装法（yum/brew/apt 有现成的就用包管理，没有或版本不匹配才源码编译）；A 执行安装；B 重跑 configure——直到输出 configuration succeeded 才结束循环。
素材记录"gnutls 3.5.19 可以，大于这个版本的有问题"。请回答：① 为什么作者不直接 yum install gnutls 最新版？② 装 gnutls 之前必须先装哪个库？为什么？③ configure 报 libtasn1 not found 时，除了 yum install，还有什么备选方案？
回想 6.3 节：版本匹配 > 版本最新；依赖链有方向；素材里 libtasn1 有两个解法。
① 仓库里的最新版与系统自带的 nettle/gmp 版本不匹配，configure 或运行时翻车——不是最新就好，匹配才好。② 必须先装 nettle（gnutls 的密码学底层，提供 AES 等算法），依赖链方向是"先装被依赖的"。③ 用 gnutls 自带的版本：./configure --enable-shared --with-included-libtasn1，绕开系统库。
在本机真实执行：① brew list --formula | grep -E 'x264|x265|opus|gnutls|nasm'（或 apt 等价命令）确认依赖；② ffmpeg -version 查看 configuration 行，找出至少 5 个 --enable-libxxx；③ 用任意一个没被启用的编码器名（如 libnonexistent）执行 ffmpeg -i 输入 -c:v 该名字 输出，记录报错；④ 解释为什么会出现这个报错。把四步输出完整记录下来。
6.6 节实测 ① ② ⑤ 就是参考答案；注意 -encoders 列出的才是"有货"的编码器，不在列表里的名字一律 Unknown encoder。
① 本机输出 gnutls/nasm/opus/x264/x265（本章实测）；② configuration 行含 --enable-libx264、--enable-libx265、--enable-libopus、--enable-gnutls、--enable-libopenjpeg 等；③ 报错为 Unknown encoder 'libnonexistent' → Error selecting an encoder → Error opening output file；④ 因为该 ffmpeg 编译时没有启用（或没编译进）这个编码器——编码器列表由 configure 时的依赖决定，缺库的后果就是"名单上没有它"。这就是源码编译时缺一个库，最终在命令行表现为一个 Unknown encoder 的完整证据链。