GStreamer webrtcbin音视频无法同时播放问题求助

问题代码 #

#define STUN_SERVER " stun-server=stun://stun.l.google.com:19302 "
#define AUDIO_CAPS  "audio/x-mulaw,media=audio,channels=1,rate=8000"
#define RTP_CAPS_PCMU "application/x-rtp,media=audio,encoding-name=PCMU,payload=0"
#define VIDEO_CAPS "application/x-rtp,media=video,clock-rate=90000,payload=97,encoding-name=H264"

gst_parse_launch("webrtcbin bundle-policy=max-bundle name=sendrecv "  STUN_SERVER
                    "appsrc name=audio_src is-live=true format=time ! " AUDIO_CAPS " ! rtppcmupay ! queue ! " RTP_CAPS_PCMU " ! sendrecv. "
                    //"audiotestsrc is-live=true wave=red-noise ! audioconvert ! audioresample ! queue ! mulawenc ! rtppcmupay ! " RTP_CAPS_PCMU " ! sendrecv. "                        
                    "appsrc name=video_src is-live=true format=time ! " VIDEO_CAPS " ! rtpjitterbuffer ! queue ! " VIDEO_CAPS  " ! sendrecv. "
                    //"videotestsrc is-live=true pattern=ball ! videoconvert ! queue ! x264enc ! rtph264pay ! queue ! " VIDEO_CAPS  " ! sendrecv. "

现象总结 #

• 单独使用audio_src或video_src时，音视频均可正常播放。
• 同时使用audiotestsrc和videotestsrc时，音视频均可正常播放。
• 同时使用audio_src和videotestsrc时，播放正常。
• 同时使用audio_src和video_src时，Chrome端无音频。
• 同时使用audiotestsrc和video_src时，Chrome端无音频。
• 若先将audio_src链接至webrtcbin，则无视频但音频正常。

排查思路 #

1. 验证RTP流时间戳同步

• 对比audio_src和audiotestsrc的时间戳生成逻辑：audiotestsrc会自动生成符合GStreamer规范的时间戳，而audio_src需确保推送的buffer带有正确的running_time和timestamp，若音频时间戳滞后或无有效时间戳，Chrome的WebRTC栈可能丢弃音频帧。
• 用gst-inspect-1.0 rtppcmupay确认音频RTP包的时间戳注入规则，检查audio_src是否按要求填充时间戳。

2. 检查WebRTC SDP协商过程

• 开启GStreamer调试日志：GST_DEBUG=webrtcbin:5,rtpbin:5，查看SDP协商中音频流的m-line是否被正确包含。使用max-bundle策略时，音视频复用同一传输通道，若视频流的SDP属性覆盖音频，会导致Chrome忽略音频流。
• 查看Chrome的chrome://webrtc-internals/页面，检查接收端音频轨道的状态：是否有流到达、是否被标记为静音或禁用。

3. 确认RTP Caps的一致性

• 验证video_src推送的流是否严格匹配VIDEO_CAPS：payload 97的H264流需包含packetization-mode和profile-level-id属性，缺失这些会导致WebRTC协商异常，进而影响音频流处理。
• 用capsfilter打印Caps信息，对比videotestsrc和video_src的RTP Caps差异：

  gst-launch-1.0 appsrc name=video_src is-live=true format=time ! capsfilter caps="application/x-rtp,media=video,clock-rate=90000,payload=97,encoding-name=H264" ! queue ! fakesink dump-caps=true
  

4. 排查链路缓冲与阻塞问题

• 调整queue元素参数：为音频队列设置更小的max-size-time或max-size-buffers，避免视频大buffer阻塞音频帧推送。
• 移除rtpjitterbuffer测试：video_src已是预生成的RTP流，额外添加抖动缓冲可能引入时序错乱，尝试去掉该元素后重新测试。

5. 检查webrtcbin流添加顺序

• 当前代码先添加音频流再添加视频流，若video_src初始化速度快于audio_src，webrtcbin可能优先完成视频协商，导致音频SDP未被正确更新。尝试调整流的添加顺序，或确保两个流都完成初始化后再启动WebRTC协商。

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