添加音频源后WebRTCBin视频延迟升高的原因及疑问

测试环境 #

• 运行GStreamer的单台笔记本服务器

单连接场景（无音频） #

视频流管道 #

webrtcbin -> dec -> depay -> videoscale -> textoverlay -> tee -> compositor -> enc -> pay -> webrtcbin

延迟表现 #

• 端到端（Glass-to-glass）延迟约170ms
• 网络RTT为40ms，表现良好

双媒体连接场景（音视频交叉输入混合器） #

注：音视频流交叉输入对方的audiomixer和compositor

连接1管道 #

• 音频流：webrtcbin -> dec -> depay -> tee -> audiomixer -> enc -> webrtcbin
• 视频流：webrtcbin -> dec -> depay -> videoscale -> textoverlay -> tee -> compositor -> enc -> pay -> webrtcbin

连接2管道 #

• 音频流：webrtcbin -> dec -> depay -> tee -> audiomixer -> enc -> pay -> webrtcbin
• 视频流：webrtcbin -> dec -> depay -> videoscale -> textoverlay -> tee -> compositor -> enc -> pay -> webrtcbin

延迟表现 #

• webrtcbin内原本空的队列迅速填满
• 视频延迟飙升至700ms+

问题分析：为何双媒体连接时WebRTCBin延迟大幅升高？ #

1. 单WebRTCBin的音视频同步队列阻塞
   WebRTCBin内部会维护音视频同步队列，当同时处理两路交叉输入的音视频流时，音视频时序差异会触发缓冲机制。单实例默认分配共享缓冲资源，两路流的帧数据在混合、转发时互相抢占空间，导致视频帧无法及时出队编码发送，队列持续积压后延迟飙升。

2. 混合器的线程调度冲突
   audiomixer和compositor处理两路交叉流时，需要等待两路帧数据到达才能完成混合。若某一路流存在微小延迟，混合器会阻塞等待，后续帧便堆积在WebRTCBin的输入队列中。而单WebRTCBin的线程模型未针对多路混合场景优化，无法并行处理两路流的混合调度，进一步加剧缓冲积压。

3. 编码/支付模块的资源竞争
   两路音视频流共用同一WebRTCBin内的enc（编码器）和pay（支付器）资源，编码器的编码能力有限，同时处理两路视频编码时，编码延迟会显著增加。支付器打包两路流的RTP包时也会出现资源竞争，导致视频帧无法及时封装发送，最终表现为队列填满、延迟飙升。

现有方案的同步问题说明 #

使用两个独立WebRTCBin可避免单实例的资源竞争和队列阻塞，但需额外处理音视频同步：

• 两个WebRTCBin各自维护独立时钟和缓冲，需通过外部时钟同步机制（如NTP时钟校准）对齐两路流时序
• 混合器需接收来自两个WebRTCBin的流，并根据时间戳做帧对齐，否则会出现音视频不同步或卡顿

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