让GStreamer pipeline自动丢弃错误buffer的方案及相关插件咨询

现有插件适配方案（无需完全自研） #

你调研的GDPPay/GDPDepay已经覆盖了核心的buffer序列化、CRC校验能力，仅需做少量改动即可适配你的需求，远比重写全量插件成本低：

• CRC错误处理优化：你可以给GDPDepay新增一个可配置属性（比如ignore-crc-errors），默认关闭保持原有面向可靠链路的行为，开启后遇到CRC校验失败的buffer时直接丢弃数据、重置解析状态机，不返回GST_FLOW_ERROR中断流水线，这个改动仅需几十行代码，提交上游PR的接受度也很高，因为完全兼容原有使用逻辑。
• 重启场景兼容：针对无需带内传输Caps的固定场景，你可以再给GDPDepay新增skip-caps-wait属性，开启后直接跳过等待初始Caps包的逻辑，你只需在GDPDepay下游接capsfilter硬编码匹配两端固定的Caps即可，接收端重启后无需等待已发送过的Caps包，直接就能处理后续传输的buffer数据。

零开发现成方案 #

如果你暂时不想修改GStreamer插件代码，也可以直接用专为不可靠链路设计的RTP相关插件组合实现需求，所有逻辑都是官方原生支持：

• 发送端流水线参考：[你的源链路] -> 对应媒体格式的RTP payloader -> rtpbin -> udpsink，直接给RTP payloader硬编码固定Caps即可，不需要动态协商。
• 接收端流水线参考：udpsrc -> rtpbin -> 对应媒体格式的RTP depayloader -> capsfilter 硬编码固定Caps -> 解码器，RTP栈原生支持校验错误包自动丢弃，不会中断流水线，接收端重启后直接接收后续RTP包即可正常解码，仅丢包时段会出现短暂花屏，完全匹配你的需求。

自研插件建议 #

如果确实要自研定制插件，也建议直接基于GDPPay/GDPDepay的现有代码做二次修改，官方已经实现了完整的buffer元数据（时间戳、时长、flags等）序列化/反序列化逻辑，你只需要调整错误处理和Caps校验逻辑即可，不需要从零实现所有功能。

内容的提问来源于stack exchange，提问作者Garrit Strenge