Gstreamer多sink管道动态切换输出实现方案咨询

原有demuxer方案失效的核心原因 #

自行实现demuxer回调做切换时，90%以上的异常来自三个逻辑缺失：

• 未正确转发流事件：切换到新sink pad时，没有按顺序发送GST_EVENT_STREAM_START、caps事件、GST_EVENT_SEGMENT，sink无法识别流格式直接报错或触发EOS
• 未做pad状态同步：切换瞬间没有阻塞旧pad、清空缓存队列，残留的旧buffer推到新sink会引发花屏、流协商失败
• 未处理非激活pad的请求：非激活sink的caps查询、分配查询没有转发到上游，上游无法匹配正确的流参数，管道初始化阶段就会协商失败

推荐实现方案（零自定义回调，稳定兼容全版本GStreamer） #

优先使用GStreamer原生的output-selector组件实现，该组件本身就是为1对多输出动态切换场景设计，不需要自行编写demux逻辑，稳定性远高于自定义demux方案。

基础管道结构 #

每个sink前必须加queue组件做线程隔离，避免切换时sink状态同步阻塞管道核心线程，示例管道结构：

[上游媒体源] ! [解码/预处理组件] ! output-selector name=outswitch
outswitch.src_0 ! queue ! [sink1组件，如autovideosink/rtspsink/filesink等]
outswitch.src_1 ! queue ! [sink2组件]
outswitch.src_2 ! queue ! [sink3组件]

切换逻辑实现 #

切换逻辑仅需4步，无需修改插件回调：

• 管道初始化阶段，缓存output-selector的所有src pad，和对应的sink做映射标记
• 收到切换指令时，先在当前激活的旧pad上添加阻塞式pad probe，丢弃队列中残留的待处理buffer
• 调用GObject接口切换激活pad：g_object_set(outswitch_element, "active-pad", target_new_pad, NULL);
• 给新激活的pad发送GST_EVENT_FLUSH_START和GST_EVENT_FLUSH_STOP事件重置sink状态，移除旧pad上的阻塞probe，切换完成

自定义demuxer方案补全逻辑 #

如果业务场景必须使用自定义demuxer实现，需要在原有回调逻辑中补全以下必选逻辑，否则无法正常运行：

• demux的query回调函数中，所有src pad（不管是否激活）的caps查询、内存分配查询都必须转发到上游sink pad，不能仅转发当前激活pad的请求
• 执行pad切换时，先给旧激活pad发送flush事件清空缓存，再暂停旧pad的数据推送；之后给新激活pad按顺序推送流启动事件、caps事件、segment事件，三个事件顺序不能调换
• 非激活pad收到上游buffer时直接返回GST_FLOW_OK丢弃，不要返回错误码，否则会触发管道全局错误中断

常见异常排查 #

• 切换后管道直接报EOS：检查新激活pad是否收到了完整的segment事件，sink未收到segment事件会判定流已结束
• 切换后卡顿2秒以上：检查每个sink前是否添加了独立的queue组件，是否存在sink和上游组件运行在同一线程的情况
• 切换瞬间花屏/绿屏：检查切换前是否清空了旧pad的残留缓存，新pad激活后是否发送了flush事件重置sink缓存

内容的提问来源于stack exchange，提问作者Suryansh Singh