一直觉得“音视频开发”这个词被用得太随意了。有人把它当成会调个 MediaPlayer 就算入门，有人觉得写个推流脚本就是精通，但真到了自己上手做播放器、做录制、做音画同步的时候，才发现连“PCM 是什么”都要回头翻资料。我这个系列的第一篇，不想一上来就扔一堆 OpenGL 或者 MediaCodec 的高级概念，反而想先把基本功补扎实：音视频数据到底长什么样、为什么要编码、FFmpeg 在整个链路里扮演什么角色，以及最劝退新手的环节——手动把 FFmpeg 编译出库。这篇文章适合刚接触音视频、准备做播放器或剪辑工具、又对 FFmpeg 一头雾水的开发者，毕竟后面所有项目工程几乎都绕不开它。

1. 先说结论：为什么基础知识和 FFmpeg 编译非要放一起

很多人会问，编译 FFmpeg 和了解音视频基础有什么关系？我直接装一个别人编译好的文件不香吗？说实话，在 Windows 上随便下一个现成库确实能用，但一旦你进入 Android、嵌入式甚至某些定制系统的开发场景，就必须面对两个现实：一是官方发布的库往往包含大量用不到的模块，体积大到难以接受；二是不同平台的编译工具链、依赖库版本差异极大，直接拿别人的编译产物，很容易踩到 ABI 不符、链接失败的坑。所以“自己动手编译 FFmpeg”几乎是每个音视频开发者的成人礼，绕不过去。

而编译 FFmpeg 之前不懂基础知识的代价是什么？你连 configure 脚本里那些开关的含义都看不懂。比如--enable-decoder=h264和--enable-demuxer=mov，如果你不知道“解码器”和“解封装器”是两个完全不同的模块，就永远只能照着网上的命令抄，一旦环境变化就两眼一抹黑。

这就是为什么我把“基础音视频知识”和“FFmpeg 编译”放在同一个入门篇里。只有先搞清楚音视频数据在计算机里是怎么存的、为什么在存储时要分成容器和编码两层结构，再去理解 FFmpeg 的模块划分和编译参数，才能真正建立属于自己的知识框架，而不是死记命令。

2. 数字音频的基本盘：从采样率到 PCM 数据

2.1 模拟声音变成数字信号的过程

声音本身是连续的模拟波形，计算机要存储和处理，就必须把它变成离散的数字序列。这个过程叫采样和量化。采样是每隔一个固定的时间间隔取一个电压值，量化是把取到的电压值用有限位数的整数表示。两个关键参数决定了最终的数据质量：采样率和位深。

采样率就是每秒采多少次，单位是 Hz。人耳能感知的频率范围大约在 20Hz 到 20kHz，根据奈奎斯特定理，采样率必须至少是信号最高频率的两倍才能无失真还原，所以 CD 标准的 44.1kHz 就是这样来的。现在常见的还有 48kHz、96kHz，主要服务于影视制作和高保真音频。

位深则表示每次采样用多少位来存储这个值。常见的是 16 位和 24 位，16 位能表示 65536 个不同的电平，动态范围大约 96dB，已经接近人类听觉的极限；24 位则更多用于专业录音，保留更大的动态余量。还有一个容易忽视的参数是声道数，单声道、双声道、5.1 环绕声，它们直接决定了每秒产生的数据量。

2.2 PCM 数据量与比特率计算

经过采样、量化、按声道排列后的裸数据，就叫 PCM。PCM 是音频世界里最基础、最“干净”的数据格式，所有音频编码算法几乎都是在 PCM 的基础上做压缩变换的。它的体积很好算：

数据量 = 采样率 × 位深 / 8 × 声道数

举一个具体的例子：44.1kHz、16 位、双声道，一秒钟的数据量是 44100 × 2 × 2 = 176400 字节，约 172KB。也就是说一首 4 分钟的歌，PCM 体积大约是 40MB。这个数字放在今天看起来好像还能接受，但如果放到实时通信或者流媒体场景里，这种毫无压缩的传输方式就是灾难。这也就是我们为什么需要后续的 AAC、Opus 等音频编码器。

2.3 理解音频帧的概念

实际开发中经常听到“一帧音频”的说法。和视频帧不同，音频帧并没有一个绝对统一的时长标准，它取决于编码器的规定。对 AAC 来说，一帧通常包含 1024 个采样点，在 44.1kHz 下，一帧时长远低于 1 秒，大约 23ms。在处理音视频同步时，你不能想当然地把音频按 1/30 秒来切分，而应该先根据采样率和编码格式算清“一帧到底有多长”，这一点在后期做音视频同步时非常关键。

3. 视频基础：像素采样、YUV 与编码的必要性

3.1 视频本质是连续图像的序列

视频在底层就是一串连续播放的静态图像，每一张叫“帧”。决定视频画面的主要参数有几个：分辨率，比如 1920×1080 或 1280×720，表示单帧图像的像素规模；帧率，每秒显示多少帧，比如 24fps、30fps、60fps；像素格式，即每个像素用什么方式描述颜色信息；位深，每个颜色分量用多少位表示。

如果完全不做压缩，一秒钟 1080p30 的原始画面有多大？1920×1080 约 200 万像素，每个像素如果用 RGB24 表示，也就是红、绿、蓝各一个字节，那么一帧就是 1920 × 1080 × 3 字节，约 6.2MB。帧率 30，一秒就是 186MB。一部 90 分钟的电影，原始数据能把几百 GB 的硬盘撑爆。这就是必须对视频做压缩的原因，也是 H.264、H.265、VP9 这类编码标准存在的意义。

3.2 YUV 比 RGB 更懂视频压缩

RGB 是显示设备最直接的色彩表示方式，但它有三个分量，信息冗余度高。视频压缩算法几乎都不直接用 RGB，而是用 YUV 家族。Y 表示亮度，U、V 表示色差。人眼对亮度细节敏感，对色彩细节相对迟钝，所以视频编码时可以把色度信息做下采样，减少数据量而又不明显影响主观画质。

常见的 YUV 采样格式有 YUV444、YUV422、YUV420。其中 YUV420 表示每 2×2 的像素块共享一组 U、V 信息，色度数据只有亮度的四分之一。像 H.264 这类编码器默认在 YUV420 输入下工作，这也是硬解码器普遍支持的格式。刚开始做视频开发的同学经常在摄像头回调里拿到的就是 NV21、NV12 这类 YUV420 的变种，不理解这个背景的话，后面做格式转换、渲染都会很痛苦。

3.3 GOP、I 帧、P 帧与 B 帧

视频压缩的核心思路是消除空间冗余和时间冗余。空间冗余靠帧内预测和变换编码，时间冗余则靠帧间预测。一组视频帧中，I 帧是关键帧，包含完整的图像信息，可以独立解码；P 帧参考前面的帧，只保存差异和运动矢量，体积小很多；B 帧则同时参考前后帧，压缩率最高，但解码顺序和显示顺序不同，延迟也更大。一个 I 帧到下一个 I 帧之间就叫一个 GOP。在做视频剪辑、拖动进度条时，GOP 大小直接决定了“关键帧定位”的速度，GOP 越大文件越小，但 seek 的精度越差，这是在实际开发中经常要权衡的点。

4. 编码与封装：这两件事不能混为一谈

4.1 编码器负责压缩，封装器负责装载

很多新手分不清“编码格式”和“文件格式”，比如把“H.264”当成一个视频文件的后缀名。严格来说，H.264、H.265、AAC 这些都是编码格式，它们解决的是“如何把原始音视频数据压缩成更小的码流”的问题；而 MP4、MKV、FLV 是封装格式，它们解决的是“如何把已经压缩好的视频流、音频流、字幕、时间轴、元数据组织在一个文件里”的问题。

封装格式的选择不是任意的，每种格式都有自己支持的编码列表和能力边界。MP4 最通用，支持 H.264/H.265/AAC，适合跨平台播放；MKV 包容性最强，几乎什么编码都能塞；FLV 在直播场景里非常常见，因为它的结构简单，便于流式传输，尤其是在 RTMP 协议下几乎是事实标准。FLV 通常装 H.264 + AAC，这个组合也是目前绝大多数视频网站使用的底层方案。

4.2 为什么解封装和解码在开发中必须独立看待

在实际开发流程里，读取一个视频文件，第一步是解封装，比如从 MP4 容器里分离出视频轨道和音频轨道；第二步才是将分离出来的视频码流交给 H.264 解码器，把音频码流交给 AAC 解码器，得到 YUV 和 PCM。这两步是完全独立的模块。

不少人调试播放器时，发现画面出不来，第一反应是排查解码器，结果查了半天发现问题出在解封装阶段，连编码数据都没拿到。这就是因为脑子里没有把“封装层”和“编码层”拆开。理解了这个分层逻辑，不仅能少走很多弯路，也能很自然地理解 FFmpeg 为什么在架构上要区分libavformat和libavcodec，前者管容器解析，后者管编解码，两者互不干扰。

5. FFmpeg 在音视频开发链路中的定位：干所有重体力活的那个工具

5.1 FFmpeg 不是单单一个可执行程序

FFmpeg 准确来说是一套完整的跨平台音视频处理解决方案，它既包含命令行工具，也包含一系列可供二次开发的库。命令行工具有三个：ffmpeg是核心的多媒体转码工具，ffprobe用来查看媒体文件的详细参数信息，ffplay是一个极简的播放器，用来快速预览结果。日常调试时，ffprobe应该算是使用频率最高的工具之一，它能清楚地告诉你文件的编码、码率、分辨率、时长、封装方式等关键信息。

而在开发侧，真正重要的是 FFmpeg 的库：

• libavformat：封装和解封装，负责读写各种容器格式
• libavcodec：编码和解码，负责编解码各种压缩格式
• libavfilter：音视频滤镜处理，比如缩放、裁剪、添加水印
• libavutil：工具库，提供数据结构、日志、内存管理等底层能力
• libswscale：图像格式与尺寸转换，比如从 YUV 转 RGB
• libswresample：音频格式转换，比如采样率转换、声道重映射

5.2 编译 FFmpeg 到底是在干什么

把 FFmpeg 编译成库，核心工作就是通过configure脚本，按照你的需求启用或禁用模块，然后调用交叉编译工具链，把 C 源码变成目标平台能直接运行的二进制文件。这个过程本质上是在做“私人定制”：只保留你需要的解封装器、解码器、滤镜，砍掉用不到的部分，从而把体积和依赖控制到最小。

这样一听就清楚为什么“直接下载别人编译好的库”不适合所有场景了。别人编译时可能开了大量你不认识的硬件加速和协议模块，可能导致包体冗余；更有甚者，如果平台架构对不上，程序一跑就直接崩溃。自己编译虽然前期麻烦一点，但得到的库和你的工程配合起来最顺手，排查问题也更有底气。

6. 编译准备：把环境、工具链和编译目标先弄清楚

6.1 选择平台与确定目标架构

我建议首次接触编译的人先选择 Linux 环境来做，Ubuntu 或 Debian 都行，因为 FFmpeg 的依赖库和构建工具在 Linux 上最容易安装，网上遇到的坑也最少。如果是 Windows 环境，可以借助 MSYS2 模拟 Linux 环境，也能跑通，但步骤会多一些，调试起来稍显繁琐。假如你的目标是 Android 平台，那么除了编译机上的 Linux 工具链，还需要下载 NDK，用它自带的交叉编译器把 FFmpeg 产物编译成 Android 可用的.so。

编译前先明确目标架构，Android 常见的是 arm64-v8a 和 armeabi-v7a，桌面 Linux 则通常是 x86_64。同一份源码不能用一个架构的产物去顶替另一个架构，在 Android 工程里多个 ABI 需要分别编译出对应目录的.so。

6.2 安装基础依赖

在编译机上，需要确保几个基础工具是齐全的。以 Ubuntu 为例，一般要装这几个包：

sudo apt update sudo apt install -y build-essential nasm yasm pkg-config git

build-essential提供 gcc、make 等基础构建工具，nasm和yasm都是汇编器，FFmpeg 有许多对性能要求极高的模块，比如 x264 和部分编码器，依赖汇编优化，没有这些汇编器会直接报错。pkg-config用来在配置阶段查找系统里已安装的依赖库，很多“找不到 libx264”的问题就是因为 pkg-config 路径没有配置好。

如果你的编译过程需要链接第三方的编解码库，比如 x264 或者 libmp3lame，通常还要先自己编译安装这些库。这里建议新手前期不要一步到位把第三方库全加上，先按纯 FFmpeg 默认配置把流程跑通，再逐步往 configure 里增加--enable-libx264之类的参数，这样更容易定位问题。

7. 编译实战：从 configure 到 make，逐步验证

7.1 第一步：获取 FFmpeg 源码

从 FFmpeg 官网下载最新的发布版源码包并解压，或者用 git 拉取仓库。这里建议使用发布版而不是 master 分支，因为发布版经过更多测试，编译过程相对稳定：

git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg ./configure --help | head -40

第一次执行./configure --help时不要急着配置，先花一点时间浏览输出的参数列表。你会看到一大堆--enable-*和--disable-*，这是理解 FFmpeg 模块结构最好的途径。比如--enable-decoder=和--enable-encoder=控制编解码器，--enable-demuxer=和--enable-muxer=控制封装格式，--enable-protocol=控制网络协议。

7.2 第二步：定制 configure 参数

对于一个最简化的 Android 编译，通常会传入这样的一组参数。这里给出一个我实测过的配置：

./configure \ --prefix=/home/ffmpeg/android/arm64 \ --target-os=android \ --arch=arm64 \ --enable-cross-compile \ --sysroot=$NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot \ --cc=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang \ --strip=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-strip \ --nm=$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-nm \ --enable-shared \ --disable-static \ --disable-doc \ --disable-programs \ --disable-avdevice \ --disable-postproc \ --enable-cross-compile \ --enable-protocol=file \ --enable-decoder=h264,aac \ --enable-demuxer=mov,flv \ --enable-parser=h264,aac \ --disable-x86asm

解释一下几个重要参数的含义。--target-os=android告诉 FFmpeg 编译目标是 Android 系统，它会调整一些平台相关行为；--enable-cross-compile是交叉编译的必需开关；--sysroot指定 NDK 提供的头文件与库文件目录；--cc指定编译器，这里用的是 NDK 里自带的可直接指定最低 API 版本的 clang 工具链；--enable-shared表示编译生成动态库，产物是.so文件；--disable-programs则是不生成 ffmpeg、ffprobe 等命令行程序，因为这些工具在 Android 里没有用，只保留库就够了。

--disable-x86asm是个容易被忽略但在 Android 交叉编译下必要的参数。Android 的 NDK 工具链对 x86 汇编的支持并不像桌面 Linux 那么完备，某些汇编指令在交叉编译时容易报“指令不认识”之类的错误，关闭后 FFmpeg 会退回到 C 实现，性能略差一点，但能保证编译稳定。

7.3 第三步：执行编译

配置完成后，执行编译和安装：

make -j8 make install

-j8表示用 8 个线程并行编译，具体数值可以根据 CPU 核心数调整。编译过程中如果看到一堆.c文件正在处理，说明进行正常。全部完成后，查看安装目录：

ls /home/ffmpeg/android/arm64/lib ls /home/ffmpeg/android/arm64/include

正常情况下lib目录下应该有libavcodec.so、libavformat.so、libavutil.so、libavfilter.so等动态库，include目录下是各模块的头文件。拿到这两样，就可以把它们集成到自己的项目工程里了。

8. 编译过程中常见的问题与排查思路：我的实操心得

8.1 没有安装汇编器导致报错

新手遇到的第一类报错，通常是类似“nasm/yasm not found”或汇编指令无法识别。这类问题的根因很简单，就是缺少必要的汇编器。解决办法是装好 nasm 和 yasm 再重新 configure。如果装好之后依然报汇编相关错误，要留意是不是编译环境里存在多个版本的汇编器，或者 PATH 环境变量指向了错误的安装路径。

8.2 configure 报错“C compiler test failed”

这个报错看着吓人，其实多半是--cc指定的编译器路径不对，或者 sysroot 与编译器版本不匹配。我的排查习惯是先把报错信息往上翻，看 configure 具体在哪一步失败，然后检查 NDK 路径是否真实存在，--cc指向的 clang 能不能独立执行。如果 NDK 是从压缩包解压的，还要确认解压之后的路径没有空格或中文目录，否则编译器调用时容易出诡异问题。

8.3 link 阶段提示 undefined reference

链接阶段的 undefined reference 通常和两个原因有关：一是某个模块启用了，但对应的依赖库没有找到；二是裁剪过度，某个库用到编译依赖时发现尺寸不一致。比较常见的例子是启用了某些滤镜或编码器，却忘了启用对应的解析器或协议。我的建议是每次 configure 改动尽量最小化，遇到错误先对照--disable-everything的理念，从最小的配置集开始逐个开启模块，而不是一次性堆一长串--enable-*参数。

8.4 ABI 不匹配导致运行时崩溃

编译成功只是第一步，集成进工程后可能直接在运行时崩溃。最典型的场景是：平台是 arm64 的机器，但加载的.so是 32 位的，或者反过来。这种问题一般表现为dlopen失败，或者调用 native 方法时直接SIGSEGV。排查方法很简单，先确定目标设备的 CPU 架构，再确认.so文件对应的 ABI。在 Android 里可以把编译产物放进对应jniLibs目录，并确保 Gradle 配置里没有限制 ABI 导致加载不到。

8.5 精简体积时删过头

做裁剪优化时最容易出现的坑是“编译器没报错，运行时报功能不支持”。因为 configure 阶段不会检查逻辑上的完整性，你确实可以只启用一个解码器，但如果你同时禁用了对应的解析器，解码时就会拿不到编码数据。裁剪优化需要遵循一个原则：按数据流的依赖链逐个检查。比如要支持 MP4 文件里的 H.264，你至少需要demuxer=mov，decoder=h264，parser=h264以及基础的protocol=file和bitstream filter，少一个都可能造成运行时异常。

我把这些坑记录下来，是因为当初自己一个一个踩过来的时候，确实挺折腾。尤其是用 NDK 交叉编译的第一周，几乎每晚都在反复 clean 和重新 configure。现在回想起来，这种折腾反而是最有价值的：正是因为这些报错，我才真正理解了解封装、解码、协议各自在 FFmpeg 里是独立模块这件事，而不是把它们当成一个混沌的整体。

9. 结尾小建议：基础不牢，后面全是坑

这个系列既然叫“音视频开发之旅”，第一站就把基础概念和编译问题讲透，是想给后面更难的音画同步、硬解码、OpenGL 渲染、推流这些专题打一个能站得住的底座。个人实际过程中的体会是：不要急着抄网上现成的编译脚本，先把每一个 configure 参数查明白，亲手把裁剪和编译的流程走通一次，收获远比直接复制命令多得多。

最后再分享一个实在的小技巧：把编译过程中产生的 config.log 和 make 输出文件保留几个副本，遇到问题先翻日志而不是直接“重来一次”。这些日志里往往记录了第一个真正出错的位置，而重新编译只会把同样的错误再演一遍。等你亲手编译过几次，再去看 FFmpeg 的模块源码，很多之前看不懂的结构和命名会豁然开朗，这就是打基础带来的复利。