GStreamer WebRTC偶发无法在Chrome中播放RTSP流问题排查

我使用GStreamer 1.21.1搭配GStreamer-Sharp开发应用，通过WebRTC将RTSP流转发至Chrome浏览器，所用管线如下：

rtspsrc location=rtsp://10.16.14.204:554 ! 
queue max-size-bytes=0 max-size-time=0 ! 
parsebin ! 
rtph264pay aggregate-mode=zero-latency config-interval=-1 timestamp-offset=0 ! 
queue max-size-bytes=0 max-size-time=0 ! 
webrtcbin bundle-policy=max-bundle name=webrtcbin

该管线多数情况下正常，但偶尔会出现视频无法播放的情况。添加重启按钮测试后，约10次重启即可复现问题，且每次使用的代码和RTSP源完全一致。

我打印了RTCPeerConnection的ontrack事件（RTCTrackEvent）数据，发现可播放与不可播放场景下的差异如下：

我已检查本地和远程SDP，未发现异常。查看服务器端GStreamer日志及自定义日志，存在GstRTSPSrcTimeout，但无论视频是否可播放都会出现，推测GStreamer会自行处理该超时，且未收到EOS信号。

目前已无排查思路，请问RTCTrackEvent中的差异能否提示问题根源？

补充测试 #

• 使用videotestsrc替代rtspsrc时一切正常；
• 使用通过RTSP传输的videotestsrc搭配原管线也正常。

由此推测问题出在摄像头的原RTSP流上，但我无法修复该流，因此需要找到检测异常并重新连接的方案。

我尝试在出现GstRTSPSrcTimeout时执行以下重连逻辑：

1. 将管线状态设置为Null
2. 将管线状态设置为Playing

但此操作导致Internal data stream error，GStreamer会在管线总线上抛出错误，最终只能重启整个管线。

该方案虽能解决问题，但存在两个弊端：

• 若GStreamer自行处理了GstRTSPSrcTimeout，重启会导致视频中断、出现加载动画，影响用户体验；
• 需重启整个管线，我希望保留WebRTC连接，仅让rtspsrc重新连接，用户仅看到视频短暂卡顿。

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