GStreamer RTP 插件体系：rtpbin、rtpsession、rtpjitterbuffer、rtpssrcdemux
各位同学，今天我们来啃一块硬骨头——GStreamer 的 RTP 插件体系。说实话，我刚接触 GStreamer 那会儿，看到 rtpbin、rtpsession 这一堆插件，头都大了。它们之间的关系就像俄罗斯套娃，一层套一层。但搞懂了这套体系，你就能像庖丁解牛一样，把 RTP 流控玩得明明白白。
RTP 传输不是简单的“发出去就完事”。网络会抖动、包会乱序、SSRC 会冲突。GStreamer 把这堆脏活累活拆成了四个核心插件，各司其职。我习惯把它们比作一个快递系统：rtpbin 是总调度中心，rtpsession 是分拣站，rtpjitterbuffer 是缓冲区，rtpssrcdemux 是分拣员。
核心要点：这四个插件不是孤立的，它们通过 GstPad 和信号机制紧密协作。你只要把 rtpbin 往 pipeline 里一放，它会自动帮你创建和管理其他三个插件。
1. rtpbin：总调度中心
rtpbin 是 RTP 会话的入口。你想想看，一个 pipeline 里可能有多个 RTP 流，每个流有自己的 SSRC、自己的时序、自己的丢包率。rtpbin 就是负责把这些乱七八糟的流统一管理起来。
我个人习惯把 rtpbin 当作“黑盒”来用。你只需要设置几个关键属性，剩下的它自己搞定。比如：
gst-launch-1.0 udpsrc port=5000 ! application/x-rtp ! rtpbin name=rtpbin \
rtpbin.send_rtp ! udpsink host=192.168.1.100 port=5002这段代码里，rtpbin 自动创建了接收和发送两条路径。你不需要手动去管 rtpsession 怎么创建，rtpbin 会帮你搞定。
我的经验：rtpbin 的 latency 属性很关键。默认是 200ms，但在局域网环境下，我通常调到 50-80ms。调太低会频繁丢包，调太高又影响实时性。我曾经在一个视频会议项目里，因为 latency 设成 500ms，被客户吐槽“画面延迟像在打卫星电话”。
2. rtpsession：分拣站
rtpsession 是 rtpbin 内部的核心组件。它负责维护 RTP 会话状态，包括 SSRC 管理、序列号校验、RTCP 收发。说白了，它就是 RTP 协议的“执行者”。
rtpsession 有几个关键信号，我经常在调试时用到：
| 信号名称 | 触发时机 | 我的调试用法 |
|---|---|---|
on-ssrc-active |
新 SSRC 加入会话 | 打印 SSRC 和源 IP，确认接收端是否正常 |
on-ssrc-collision |
SSRC 冲突 | 触发时立即打印告警，检查是否有两个源用了相同 SSRC |
on-rtcp-sr |
收到发送端报告 | 提取 NTP 时间戳，计算 RTT |
on-rtcp-rr |
收到接收端报告 | 查看丢包率和 jitter 值，判断网络质量 |
嗯，这里要注意：rtpsession 默认是“静默”工作的。如果你不连接这些信号，它不会主动告诉你任何信息。我曾经踩过这个坑——线上环境丢包严重，但日志里啥都没有，后来才发现是没连 on-rtcp-rr 信号。
避坑指南：我曾经在一个项目中，两个发送端用了相同的 SSRC，结果接收端画面疯狂闪烁。rtpsession 的 on-ssrc-collision 信号会触发，但默认行为只是打印一行警告，不会自动处理。你需要自己实现冲突处理逻辑，比如重新协商 SSRC 或丢弃冲突包。
3. rtpjitterbuffer：缓冲区
rtpjitterbuffer 是 RTP 流控的“心脏”。网络抖动会导致包到达时间不均匀，有的早到，有的晚到。rtpjitterbuffer 就是把这些包“捋顺”了再送出去。
它的核心参数有两个：
- latency：缓冲区大小，单位毫秒。值越大，抗抖动能力越强，但延迟也越大。
- mode：缓冲模式。有 0（静态）、1（动态）、2（自适应）三种。
我建议你根据网络环境选择模式：
| 模式 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 0（静态） | 局域网、有线网络 | 延迟最低，CPU 开销小 | 抗抖动能力差 |
| 1（动态） | Wi-Fi、4G/5G | 自动调整缓冲区大小 | 偶尔会有缓冲区波动 |
| 2（自适应） | 互联网、跨运营商 | 根据网络状况实时调整 | CPU 开销较大 |
你想想看，如果网络很稳定，用静态模式就够了。但如果是移动网络，我强烈建议用自适应模式。我记得有一次在高铁上测试视频通话，用静态模式画面卡成 PPT，换成自适应模式后流畅多了。
核心原理：rtpjitterbuffer 内部维护一个包队列，按照 RTP 序列号排序。它不会等所有包到齐才输出，而是根据 latency 值设定一个“等待窗口”。窗口内的包按序输出，窗口外的包要么丢弃，要么标记为丢失。
4. rtpssrcdemux：分拣员
rtpssrcdemux 的作用很简单：根据 SSRC 把混合的 RTP 流拆分成独立的流。比如一个视频会议里，可能有三个人的视频流混在一起，rtpssrcdemux 会按 SSRC 把它们分开，每个流输出到一个独立的 pad 上。
它的用法也很直接：
gst-launch-1.0 udpsrc port=5000 ! application/x-rtp ! rtpbin name=rtpbin \
rtpbin.recv_rtp ! rtpssrcdemux name=demux \
demux.src_0 ! queue ! rtph264depay ! decodebin ! videoconvert ! autovideosink \
demux.src_1 ! queue ! rtph264depay ! decodebin ! videoconvert ! autovideosink这段代码里，rtpssrcdemux 把两个 SSRC 的流分别输出到 src_0 和 src_1。每个流独立解码和显示。
我的习惯：在调试多流场景时，我会在 rtpssrcdemux 后面加一个 fakesink，然后通过 pad-added 信号动态创建分支。这样不用提前知道有多少个 SSRC，代码更灵活。
5. 四个插件的协作关系
这四个插件不是各自为战，而是紧密协作的。我画了一张流程图，帮你理清它们的关系：
流程很简单：网络数据进入 rtpbin，rtpbin 交给 rtpsession 处理 RTCP 和 SSRC 管理，然后数据进入 rtpjitterbuffer 进行排序和抖动消除，最后通过 rtpssrcdemux 按 SSRC 分发给下游解码器。
注意：rtpjitterbuffer 和 rtpssrcdemux 的顺序不能搞反。必须先缓冲排序，再按 SSRC 分发。否则，如果先分发再缓冲，每个子流都要单独维护一个缓冲区，浪费内存不说，还会增加延迟。
好了，这一章的内容就到这里。这四个插件是 GStreamer RTP 流控的基石。你只要理解了它们各自的分工和协作方式，后面调试丢包、抖动、延迟这些问题时，就能快速定位到是哪个环节出了问题。