2. FFmpeg 基础回顾：核心架构、命令行工具与编解码器

好，咱们正式开始第二讲。在深入丢包恢复策略之前，我建议先把 FFmpeg 的底子夯实。你想想看，如果连滤镜图怎么走、编解码器怎么选都不清楚，后面谈丢包重传、FEC 修复，那基本是空中楼阁。

这一章，我会从三个角度切入：核心架构、常用命令行工具、编解码器基础。每个点我都会结合自己踩过的坑来讲，希望能帮你少走弯路。

FFmpeg 说白了就是一个多媒体处理的瑞士军刀。它的核心架构可以用一张图讲清楚：

这张图我画了很多次。每次给团队新人讲，我都会指着中间的滤镜图说：这是 FFmpeg 的灵魂。输入文件经过解封装、解码后，原始数据流进入滤镜图，你可以在这里做缩放、裁剪、叠加、甚至丢包补偿。处理完再编码、封装输出。

个人习惯：我调试丢包问题时，经常在滤镜图里插入 showinfo 滤镜，实时看每一帧的 PTS、DTS 变化。这比看日志直观多了。

FFmpeg 的命令行工具很多，但日常用得最多的就三个：ffmpeg、ffprobe、ffplay。我管它们叫“三板斧”。

举个例子。有一次线上反馈直播画面频繁卡顿，我第一反应不是看代码，而是用 ffprobe 抓了一段流：

ffprobe -v error -show_entries packet=pts,dts,duration -of csv=p=0 rtmp://live.example.com/stream

结果发现 PTS 跳变严重，明显是丢包导致的时间戳错乱。嗯，这就是典型的“先诊断，再下药”。

我曾经踩过的坑：用 ffmpeg -i 直接转码一个损坏的 TS 文件，结果 FFmpeg 直接崩溃退出。后来我才知道，加个 -err_detect ignore_err 就能跳过错误包继续处理。这个参数在丢包恢复场景里特别有用。

编解码器这块，我不打算讲太深。你只需要记住一个原则：丢包恢复策略和编码器强相关。

举个例子：H.264 的 NAL 单元有类型区分，IDR 帧丢了整个 GOP 都废了。而 VP9 的参考帧管理更灵活，丢包后恢复成本更低。我做过一个对比测试：

编码器	丢包敏感度	恢复难度	我的建议
H.264	高（依赖 IDR）	中	配合 FEC 使用
H.265	更高（参考帧更多）	高	必须加重传机制
VP9	中（灵活参考）	低	适合弱网环境
AV1	低（工具集丰富）	低	未来趋势，但编码慢

你可能会问：那是不是直接用 VP9 就万事大吉了？不一定。VP9 的编码速度比 H.264 慢 3-5 倍，实时场景下扛不住。所以实际项目中，我通常用 H.264 做主编码，然后叠加一层应用层的丢包恢复。

核心观点：编解码器只是工具，丢包恢复策略才是灵魂。选编码器时，要综合考虑编码速度、兼容性、以及你的恢复算法能否匹配它的参考帧结构。

这一章我们回顾了 FFmpeg 的三大块：架构上要理解滤镜图是核心；工具上要熟练使用 ffprobe 做诊断；编解码器上要知道不同编码对丢包的敏感度不同。

我个人觉得，这些基础就像盖楼的地基。后面讲丢包检测、重传策略、FEC 编码时，我会反复引用这里的概念。所以如果你现在对滤镜图或者 NAL 单元还有点模糊，建议先停下来，动手跑几个命令感受一下。