1. FFmpeg前世今生：音视频编码发展史、FFmpeg项目起源、核心设计哲学与模块架构

聊FFmpeg之前，得先说说音视频编码这摊子事是怎么来的。

上世纪80年代以前，视频信号还是模拟的。那时候的录像带、电视广播，说白了就是电磁波在磁带上画波形。我刚开始接触这行时，翻过一些老资料，看到模拟视频的指标——什么PAL、NTSC、SECAM，一堆制式混战，画面质量还受信号衰减影响。

转折点出现在1988年。那一年，ISO和IEC联合成立了MPEG专家组。他们的目标很明确：把视频变成一串0和1，然后想办法压缩它。

为什么需要压缩？我给你算笔账：

这还只是标清。放到今天4K、8K的时代，不压缩根本没法存、没法传。

所以编码标准一路演进：

音频这边也是类似的故事。从PCM原始波形，到MP3、AAC、Opus，压缩效率越来越高，音质也越来越好。

核心认知：编码的本质就是在画质/音质和码率之间找平衡。没有完美的编码器，只有最适合场景的编码器。

2000年，一个叫Fabrice Bellard的法国程序员（后来还搞出了QEMU和TinyCC），发起了一个叫FFmpeg的项目。

名字怎么来的？FF代表Fast Forward，mpeg就是MPEG标准的那个mpeg。合起来就是「快速处理MPEG」的意思。

我查过早期的项目日志，最初FFmpeg只支持MPEG-1编码。那时候Linux上能用的视频工具少得可怜，商业软件又贵得要命。Fabrice的想法很简单：写一个开源的、跨平台的、能处理各种音视频格式的命令行工具。

嗯，这一写就是二十多年。

2004年，FFmpeg经历了一次著名的分叉——Libav。原因嘛，开发理念冲突。但FFmpeg社区挺过来了，而且越做越大。我个人觉得，这次分叉反而让FFmpeg的代码质量和社区治理变得更成熟了。

一个小故事：我曾经在调试一个H.264编码问题时，翻到FFmpeg源码里一段注释，写着「This is a hack, but it works.」——这种坦诚在商业软件里可看不到。

FFmpeg的设计哲学，我总结为三条：

为什么能做到这么多格式？因为FFmpeg采用了一种叫「插件式架构」的设计。每个编解码器就是一个.so或.dll文件，运行时动态加载。想加一个新格式？写一个模块，注册进去就行。

你想想看，这就像乐高积木。底层是基础库（libavutil），上面是各种功能模块，最后通过ffmpeg命令行工具把它们串起来。

避坑指南：我曾经在项目里直接修改FFmpeg源码来支持一个私有格式，结果升级版本时改的代码全冲突了。后来学乖了——能用外部模块就别改核心代码，用AVFilter和libavdevice的扩展接口才是正道。

下面这张图，是我自己整理的FFmpeg核心模块架构。搞懂它，你就掌握了FFmpeg的骨架。

这张图怎么看？从上往下：

我见过不少开源项目，火个三五年就凉了。FFmpeg从2000年活到现在，二十多年了，还在持续更新。为什么？

说白了，三个原因：

生态粘性——几乎所有音视频软件都在用FFmpeg。VLC、OBS、HandBrake、Chrome、Android...你叫得上名字的，底层都有FFmpeg的影子
持续进化——新标准出来，FFmpeg很快跟进。AV1刚发布时，FFmpeg三个月内就合入了官方解码器
社区质量——代码审查严格，文档虽然不完美但一直在改进。我提过几次patch，review过程确实专业

我的建议：如果你是刚入行的音视频开发者，别急着自己造轮子。先把FFmpeg用熟，理解它的数据流模型和模块划分。等你真正遇到性能瓶颈或特殊需求时，再考虑深入定制。

嗯，第一章就到这里。FFmpeg的来龙去脉、设计思想、模块架构，你应该有个整体印象了。后面我们会一步步深入每个模块的具体参数和实战技巧。