【C++三方组件】FFmpeg：音视频处理的瑞士军刀

【摘要】：FFmpeg 把音视频的全部层------容器、编解码、滤镜、采集------做成了 libav 家族六个库加一组命令行工具。本机 9.0.2（LGPL 构建）实测 API 闭环：合成 200 帧彩条 → mpeg4 编码 1572 fps 封装 mp4 → 重新打开解码回读 19230 fps，帧数分毫不差。为什么自研编解码是无底洞、send/receive 生命周期与引用计数纪律（av_frame_unref 复用、nullptr 冲刷）怎么守、LGPL 与 GPL 构建差在哪个编码器，本篇收官多媒体、也收官全系列。

【关键词】：FFmpeg、libavformat、libavcodec、编解码、时间基

【版本基准】：FFmpeg 9.0.2（BtbN 自动构建 n9.0.2-22-g46d8f462ee，LGPL-2.1+，win64 共享库）｜示例 C++17｜实测环境：MSVC v145／VS2026，Windows

〔关联〕本篇是全系列第 54 篇收官

1. What：六个库与一把军刀

FFmpeg（2000 年 Fabrice Bellard 发起）是音视频领域的事实标准：Chrome 之外几乎所有播放器、YouTube/B 站的转码集群、OBS 的推流核心，底下都是它。架构上是六个职责单一的库：

库	职责
libavformat	容器封装/解封装（MP4/MKV/FLV/HLS/RTMP......）
libavcodec	编解码器（含硬件加速入口）
libavfilter	滤镜图（水印/缩放/调色/音频混合）
libswscale / swresample	图像缩放与色彩空间 / 音频重采样
libavdevice	采集（摄像头/麦克风/采集卡）

外加一把军刀：ffmpeg 命令行------转码、抽帧、切流一行命令，本身就是独立产品。CLI 与 C API 两条腿走路是它的使用哲学：一次性任务用命令行，管线内嵌（流媒体服务器、帧级分析）才动 API。

2. Why：自研编解码是无底洞

音视频的复杂度不在算法难，在规范深 ：一个 H.264 解码器要正确处理几十种档位、参考帧管理、错误隐藏；一个 MP4 封装器要伺候 box 结构、moov 索引、frag mp4、时间基换算------每一条都是几百页规范的地雷区。再加上硬件加速（NVDEC/QSV/D3D11VA）、新编码器跟进（AV1/H.266）、封装格式长尾，任何团队自研都是填不满的坑。FFmpeg 用二十五年把这三层各吃透一层：容器归 avformat、编解码归 avcodec、处理归 avfilter，你的代码只负责编排（pipeline）。

3. How：接入与「MSVC 没有 CMake 包」的现实

FFmpeg 官方不为 MSVC 提供 CMake 包，接入三选一：vcpkg（vcpkg install ffmpeg，feature 可裁剪------最常规）；Linux/包管理器（apt 的 libavformat-dev 等）；或社区构建 + import lib 手工链 （示例做法：BtbN 的 win64 LGPL 共享构建自带 .lib，CMake 里 include/lib 指过去链 avformat avcodec avutil）。许可证要看构建：LGPL 构建带全部内置编码器（mpeg4 等），libx264/x265 是 GPL 组件------闭源商用要么选 LGPL 构建、要么走商业授权（ffmpeg.org 的合规清单）。

API 的现代形态是 send/receive 双向数据泵（4.x 起取代旧的回调式），编码侧最小闭环四步：

cpp 复制代码

avcodec_send_frame(enc, frame);        // 喂一帧
while (avcodec_receive_packet(enc, pkt) == 0) {
  av_packet_rescale_ts(pkt, enc_tb, stream_tb);  // 时间基!
  av_interleaved_write_frame(fmt, pkt);  // 交织写包
}
avcodec_send_frame(enc, nullptr);      // 冲刷标记
while (avcodec_receive_packet(enc, pkt) == 0) { /* 收尾包 */ }

解码侧对称：av_read_frame 取包 → send_packet/receive_frame。三条纪律：引用计数纪律 （Frame/Packet 是可复用容器，每轮 av_frame_unref/av_packet_unref 再收新数据，最后 *_free 释放容器本身）；错误码纪律 （返回值是负的 AVERROR，av_strerror 转文案，AVERROR(EAGAIN) 表示「这次没有，继续」而不是错误）；时间基纪律 （codec 与 stream 的 time_base 不同，跨层必 av_packet_rescale_ts------新手产出的「卡顿/音画不同步」多半栽在这）。

4. How：实测------编码封装解码全闭环

示例（ffmpeg_demo.cpp）纯 API 走完全环：合成 200 帧 YUV420 彩条（白块逐帧移动）→ mpeg4 编码 → MP4 封装 → 重新打开解封装解码回读。实测输出：

text 复制代码

FFmpeg n9.0.2-22-g46d8f462ee-20261007（libavcodec 63.1.102 / libavformat 63）

== 1. 编码：640x360 mpeg4 → out.mp4 ==
编码 200 帧耗时 127 ms（1572 fps），文件 181 KB

== 2. 解码回读 out.mp4 ==
流：'mpeg4' 640x360，6.63 s，30 fps
首帧 640x360，yuv420p
解码 200 帧耗时 10 ms（19230 fps）
all checks passed

三处可对照正文：其一，流信息一行读到 ------avformat_find_stream_info 后 codec/分辨率/时长/帧率全在 AVStream 里，这是「容器层知道一切」的直接体现；其二，编码选了内置 mpeg4 （MPEG-4 Part 2）------LGPL 构建即可用，演示了许可证裁剪的实操；其三，200 帧往返帧数一致，靠的就是 send/receive 与冲刷标记的正确编排------漏掉 nullptr 冲刷，编码器缓冲里的最后几帧会静默丢失（示例有计数校验）。

5. 边界与选型

FFmpeg 的「不能」与「不必」：它是处理引擎不是产品 ------播放器界面（第 49～52 篇）、传输协议编排（第 30 篇 gRPC 之外的 RTMP/SRT 生态）要自己组合；API 大版本会破坏兼容 （4.x 移除了旧的回调式编码 API，9.x 的 libavcodec 已到 63）------钉住主版本、升级看迁移指南；多线程它自管（编码器内建 slice/帧级并行），外层别再套线程池喂同一个 codec 上下文。选型口径：需要「处理已有的音视频」（转码/抽帧/分析/推流）------没有第二选择；需要「实时通信」（低延迟 RTP/WebRTC）------FFmpeg 能做但要自己啃 SDP/ jitter buffer，可对照 mediasoup/GStreamer 的管线模型。

〔关联〕第 53 篇 OpenCV（视频帧的像素处理，videoio 底下就是本篇）、第 48 篇 oneTBB（「内部自带并行」的限流共存）、第 42～44 篇压缩库（有损/无损的体积直觉在音视频同样成立------本篇 200 帧 181 KB 即运动预测的压缩功劳）。

6. 设计解释与参考

为什么是 send/receive 而不是回调？回调式 API（旧的 avcodec_encode_video2）把控制流交回库，多线程与流水线编排别扭；send/receive 是生产者-消费者的非阻塞泵 ------EAGAIN 就是「泵暂空」，天然适配事件循环（第 31 篇 Asio 的 io_context 可以直接驱动它）与线程池。交织写包（av_interleaved_write_frame）存在的理由：MP4 要求按时间戳排序交错存放音视频包，函数内部维护重排缓冲------所以它可能缓存你的包，关闭前必须 av_write_trailer 冲刷。

FFmpeg 官网与 API 文档：doxygen 按模块组织，每个函数带最小示例；
FFmpeg Wiki：编译选项、硬件加速、许可证矩阵；
完整示例：ffmpeg_demo.cpp（编码封装/解码回读全闭环），构建（import lib 接入）与运行见 README。

参考：本篇实测（mpeg4 编码 1572 fps、解码 19230 fps、200 帧往返一致、流信息读取）均出自配套示例在本机的运行输出（FFmpeg 9.0.2 LGPL 共享构建）；耗时数字随机器而变。