1. GStreamer 基础回顾：Pipeline 概念、Element 与 Pad、Bin 与 Bus、GstBuffer 与 GstCaps

各位同学，咱们正式开始。这一章我打算带大家快速过一遍 GStreamer 的核心概念。你可能会说：“这些我早看过了。” 但别急，我敢打赌，很多人在实际调流控、调 RTP 时翻车，恰恰是因为这些基础没吃透。

说白了，GStreamer 就是一个多媒体框架。它的设计哲学很朴素：把复杂的处理流程拆成一个个小模块，然后用管道串起来。你想想看，这不就跟搭乐高一样吗？

1.1 Pipeline —— 你的多媒体高速公路

Pipeline，管道，是 GStreamer 里最顶层的容器。它负责管理所有元素的生命周期、数据流动和状态切换。我个人习惯把 Pipeline 想象成一条高速公路：数据就是车，元素就是收费站、服务区、出口。

Pipeline 的状态机有四种：NULL、READY、PAUSED、PLAYING。注意，它不是你想切就能随便切的。比如从 NULL 直接到 PLAYING，内部会依次经过 READY 和 PAUSED。我曾经在调试一个低延迟推流项目时，以为状态切换是瞬间完成的，结果在 PAUSED 状态卡了 200 毫秒，导致首帧延迟飙升。嗯，这里要注意：状态切换是异步的，你得等 BUS 消息确认。

1.2 Element 与 Pad —— 积木与接口

Element 是 GStreamer 的基本处理单元。一个 Element 可以是一个源（source）、一个过滤器（filter）、或者一个接收端（sink）。比如 filesrc 是源，videoconvert 是过滤器，autovideosink 是接收端。

那 Element 之间怎么连接？靠 Pad。Pad 就是 Element 的输入输出端口。每个 Pad 有方向：src pad 输出数据，sink pad 接收数据。连接规则很简单：一个 Element 的 src pad 连到另一个 Element 的 sink pad。

这里有个坑：Pad 的兼容性由 Caps 决定。我见过太多人写 gst_element_link 返回 TRUE 就以为万事大吉，结果运行时数据格式不匹配，Pipeline 直接报错。所以，我建议你每次连接后，用 gst_pad_get_current_caps 检查一下实际协商的格式。

Pad 类型	方向	典型用途
src pad	输出	源元素产生数据，如 filesrc 的 src pad
sink pad	输入	接收端元素接收数据，如 autovideosink 的 sink pad
request pad	动态	按需创建，如 tee 元素的分支输出
always pad	静态	元素创建时就存在，如 videoconvert 的 pad

1.3 Bin 与 Bus —— 容器与信使

Bin 是一个特殊的 Element，它可以包含其他 Element。Pipeline 本身就是一个顶级 Bin。为什么要用 Bin？说白了就是为了复用。你可以把一组 Element 打包成一个 Bin，当成一个“超级元素”来用。比如，一个解码模块可以封装成 Bin，内部包含 demuxer、decoder、converter，对外只暴露一个 sink pad 和一个 src pad。

Bus 呢？它是 Pipeline 内部的消息通道。所有 Element 产生的消息（错误、状态变化、EOS 等）都会发到 Bus 上。你的应用程序需要从 Bus 上取消息并处理。我早期做项目时，经常忽略 Bus 消息，结果 Pipeline 报错了我还一脸懵。后来我养成了一个习惯：在主循环里加一个 Bus 消息的异步监听，任何异常都能第一时间捕获。

1.4 GstBuffer 与 GstCaps —— 数据与契约

GstBuffer 是数据载体。它里面装的是实际的音视频帧数据。每个 Buffer 有时间戳（PTS/DTS）、持续时间、偏移量等元数据。在 RTP 场景下，Buffer 的时间戳精度直接影响到音视频同步。我调试过一个案例，因为 Buffer 的 PTS 单位没对齐（有的用纳秒，有的用微秒），导致播放端音画不同步。所以，统一时间戳单位是基本功。

GstCaps 是能力集，说白了就是“数据格式的契约”。它描述了媒体流的类型、分辨率、帧率、采样率、编码格式等。两个 Pad 连接时，必须通过 Caps 协商达成一致。协商失败，Pipeline 就建不起来。

Caps 有两种：固定 Caps 和 可协商 Caps。固定 Caps 就是“我就这个格式，你爱接不接”；可协商 Caps 则提供一个范围，比如分辨率从 640x480 到 1920x1080。实际项目中，我建议源端尽量用固定 Caps，减少协商开销。接收端如果支持多种格式，再提供可协商 Caps。

1.5 知识体系总览

下面这张图是我自己总结的 GStreamer 核心概念关系图。你看一眼，就能明白这些概念是怎么串起来的。

1.6 一个简单的 Pipeline 示例

光说不练假把式。咱们写一个最简单的 Pipeline，把上面这些概念串起来。

# 一个简单的播放 Pipeline
gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

这个 Pipeline 里：

• filesrc 是源 Element，它的 src pad 输出文件数据。
• qtdemux 是过滤器，解封装，它的 sink pad 接收数据，src pad 输出视频流。
• h264parse 和 avdec_h264 是解码链路。
• videoconvert 做格式转换。
• autovideosink 是接收端，显示画面。

每个 Element 之间的 Pad 连接，都经过了 Caps 协商。比如 h264parse 的 src pad 输出的是 video/x-h264 格式，avdec_h264 的 sink pad 必须能接受这个格式，否则连接失败。