嘿，这个场景我刚好在做SFU开发时碰过，给你详细说说！

首先明确结论：webrtcbin完全支持配置多个sink pad，刚好能满足你说的“把新连接的浏览器视频流转发给已有连接”的SFU需求。

核心原理与操作步骤 #

webrtcbin的sink pad是动态请求式的——默认不会自动创建，你需要主动申请新的sink pad来接收不同来源的流。具体操作逻辑如下：

1. 监听新连接的pad-added信号
   当webrtcbin2和浏览器2建立连接并触发pad-added信号时，先过滤出视频流的src pad（通过caps判断，比如匹配video/x-h264、video/vp8这类视频格式）。

2. 给目标webrtcbin请求新的sink pad
   调用GStreamer的API（比如C语言的gst_element_request_pad_simple()，或者Python绑定的request_pad_simple()）给webrtcbin1申请一个新的sink pad，模板名用sink_%u即可（这是webrtcbin官方定义的sink pad模板）。

3. 链接两个pad完成流转发
   用gst_pad_link()（或对应语言的绑定方法）把webrtcbin2的视频src pad和刚申请的webrtcbin1的sink pad链接起来，这样浏览器2的视频流就能通过webrtcbin1转发给浏览器1了。

关键注意事项 #

• Caps协商适配：不同浏览器可能发送不同编码的视频流（比如Chrome默认发VP8，Safari可能发H264），如果两个流的编码不匹配，需要在中间插入转码元素（比如x264enc、vp8enc）或者格式转换元素（videoconvert、videoscale）来做适配，否则pad链接会失败。
• 资源回收：当某个浏览器断开连接时，记得调用gst_element_release_request_pad()释放对应的sink pad，避免内存泄漏。
• 线程安全：所有GStreamer的pad操作必须在GLib主循环线程中执行，别在自定义的业务线程里直接操作pad，否则会出现崩溃或异常。

简单伪代码示例（Python GStreamer绑定） #

import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst

Gst.init(None)

def on_webrtcbin2_pad_added(src, pad):
    # 过滤视频流pad
    caps = pad.get_current_caps()
    if not caps.to_string().startswith("video/"):
        return
    # 给webrtcbin1请求新的sink pad
    sink_pad = webrtcbin1.request_pad_simple("sink_%u")
    if not sink_pad:
        print("申请sink pad失败")
        return
    # 链接pad
    link_result = pad.link(sink_pad)
    if link_result == Gst.PadLinkReturn.OK:
        print("成功将浏览器2的视频流转发给浏览器1")
    else:
        print(f"Pad链接失败，错误码: {link_result}")
        # 链接失败要释放申请的pad
        webrtcbin1.release_request_pad(sink_pad)

# 假设webrtcbin1和webrtcbin2已经初始化完成
webrtcbin2.connect("pad-added", on_webrtcbin2_pad_added)

这种方式就是SFU中“多peer流转发”的标准实现思路，很多基于GStreamer的开源SFU都是这么做的，只要处理好细节，就能稳定运行。

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