4、核心概念详解：Pad、Caps、Buffer、Event，它们是如何协同工作的。
说实话，刚接触 GStreamer 的时候，我最头疼的就是这四个概念。Pad、Caps、Buffer、Event，光看名字就够绕的。但你要是搞懂了它们怎么配合，GStreamer 的整个运转逻辑就豁然开朗了。
我习惯把这四个东西比作一个工厂的流水线：Pad 是接口，Caps 是规格书，Buffer 是传送带上的物料，Event 是控制信号。缺一个，流水线就跑不起来。
4.1 Pad —— 元件的“插头”
每个 GStreamer 元件都有 Pad。你可以把它想象成电器上的插头或插座。元件之间靠 Pad 对接，数据才能流通。
- Src Pad：数据从这儿流出去。相当于“输出口”。
- Sink Pad：数据从这儿流进来。相当于“输入口”。
举个例子，一个 filesrc 元件只有一个 Src Pad，它只管往外吐数据。而一个 autovideosink 只有一个 Sink Pad，它只管接收数据并显示。
关键点：两个 Pad 要能连起来，必须满足一个条件——它们的 Caps 能“协商”成功。否则，GStreamer 会直接报错，拒绝连接。
我在项目中遇到过一个问题：两个元件明明功能都对，但就是连不上。查了半天，发现是一个 Pad 输出的是 RGB，另一个 Pad 只接受 BGR。顺序不对，Caps 协商失败，Pipeline 根本建不起来。
4.2 Caps —— 数据的“规格书”
Caps 全称是 Capabilities，说白了就是数据格式的描述。它告诉上下游：“我能处理什么格式的数据？”
一个典型的 Caps 长这样：
video/x-raw, format=I420, width=1920, height=1080, framerate=30/1这串东西的意思是：原始视频，I420 色彩空间，1920x1080 分辨率，30 帧每秒。
Caps 的协商过程很有意思。上游元件说：“我能输出 A、B、C 三种格式。”下游元件看看自己的支持列表，说：“我只能接受 B 和 D。” 那最终选哪个？GStreamer 会挑一个双方都支持的，通常是排在前面的那个。这就是所谓的 Caps 协商。
| 属性 | 含义 | 常见值 |
|---|---|---|
format |
像素格式 | I420, NV12, RGBx, BGRx |
width |
图像宽度（像素） | 640, 1280, 1920, 3840 |
height |
图像高度（像素） | 480, 720, 1080, 2160 |
framerate |
帧率（分数形式） | 30/1, 25/1, 60/1 |
小技巧：调试时可以用 gst-launch-1.0 -v 查看 Caps 协商的详细过程。我曾经靠这个定位过一个花屏问题——原来是 Caps 协商到了一个硬件不支持的格式，导致解码出错。
4.3 Buffer —— 真正的“数据包”
Buffer 就是实际承载音视频数据的对象。它里面装的是裸数据，比如一帧图像、一段音频采样。
Buffer 有几个关键属性：
- 数据指针：指向实际的内存区域。
- 大小：数据占用的字节数。
- 时间戳：PTS（显示时间戳）和 DTS（解码时间戳）。
- 标志位：比如关键帧标记、结束标记等。
你想想看，Buffer 在 Pipeline 里是怎么流动的？上游元件分配一个 Buffer，填好数据，通过 Src Pad 推给下游。下游元件从 Sink Pad 收到 Buffer，处理完，再通过自己的 Src Pad 推给更下游。一环扣一环。
注意：Buffer 是引用计数的。多个元件可以共享同一个 Buffer，直到最后一个使用者释放它。我曾经犯过一个错——在滤镜里直接修改了上游 Buffer 的数据，结果导致上游元件崩溃。正确的做法是：如果需要修改，先调用 gst_buffer_make_writable() 获得一份可写的副本。
4.4 Event —— 流水线上的“控制信号”
Event 不承载音视频数据，它传递的是控制信息。比如：
- EOS（End of Stream）：告诉下游“数据发完了”。
- FLUSH：清空所有缓存的数据。
- SEGMENT：定义播放的时间范围。
- CAPS：通知下游 Caps 发生了变化。
Event 的传递方向和 Buffer 一样，也是从上游到下游。但有一种特殊的 Event 叫 Query，它可以双向传递，用于查询元件的状态。
举个例子，当文件播放完毕时，filesrc 会发送一个 EOS Event。这个 Event 沿着 Pipeline 一路传递，最终到达 autovideosink。Sink 元件收到 EOS 后，就知道播放结束了，可以停止渲染。
4.5 它们是如何协同工作的？
好了，四个概念都讲完了。现在我们把它们串起来，看看一次完整的数据流是怎样的。
- 连接阶段：两个 Pad 通过 Caps 协商确定数据格式。协商成功后，Pipeline 进入运行状态。
- 数据流动：上游元件分配一个 Buffer，填入音视频数据，通过 Src Pad 推给下游。
- 控制信号：在数据流中穿插着 Event。比如 Caps Event 告诉下游“格式变了”，EOS Event 告诉下游“数据结束了”。
- 处理与转发：下游元件从 Sink Pad 收到 Buffer，处理（比如解码、缩放、滤镜），然后通过自己的 Src Pad 继续往下推。
下面这张图可以帮你直观理解这个流程：
嗯，这里要注意一点：Caps 协商并不是只在连接阶段发生一次。如果 Pipeline 运行过程中数据格式变了（比如分辨率切换），上游会发送一个 Caps Event，通知下游重新协商。这就是所谓的“动态重协商”。
个人经验：我在做一个视频拼接项目时，遇到过输入源分辨率不固定的情况。一开始没处理动态 Caps 变化，结果画面直接花掉。后来加了一个 capsfilter 元件，强制固定输出格式，问题就解决了。说白了，capsfilter 就是帮你“锁定” Caps 的利器。
4.6 总结一下
Pad 是接口，Caps 是协议，Buffer 是货物，Event 是指令。四者缺一不可。
- 没有 Pad，元件之间无法连接。
- 没有 Caps，连接了也不知道传什么格式。
- 没有 Buffer，Pipeline 里跑的是空气。
- 没有 Event，Pipeline 就是个失控的机器。
搞懂这四个概念，你就掌握了 GStreamer 的底层逻辑。后面讲滤镜、调优，都是在这个基础上展开的。