WebRTCBin not receiving caps signal

[Michiel Konstapel]

Apologies, that lost a lot of context since it references an old email 
to the list. It concerns this message by Dominik: 
http://gstreamer-devel.966125.n4.nabble.com/WebRTCBin-not-receiving-caps-signal-tt4689946.html

Quoting:
> I am working on a python app that turns an rtsp stream from a 
> networked camera into a stream that you can access through the browser 
> via WebRTC.
>
> For that, I am using a dynamic pipeline, the rtp audio and video 
> streams go to a fakesink through a tee element. For each incoming 
> websocket connection, I build an WebRTC connection: I am adding two 
> queues, one for audio, one for video to the tee elements and connect 
> them to a new WebRTC element. Then I exchange the SDP offer and 
> response via websockets.
>
> Now, in some situations, after quick reloads of the web page that 
> brokers the connection, the newest added WebRTCBin element does not 
> send the “on-negotiation-neeed” signal. I am assuming this is because 
> it did not receive caps on the newly requested pad, thus the 
> gst_webrtcbin_sink_event method did not get triggered and the 
> WebRTCBin is not checking whether a negotiation is needed.
>
> A PDF of the pipeline is here: 
> http://roettsch.es/debug_gst_webrtcbin.pdf and an image of the 
> relevant portions is attached.
>
> The WebRTCBin element sendrecv-2-772371 has blocked pads, as it hasn’t 
> done any negotiation and unblocked its pads, but also the CAPS on the 
> links to the queue elements only show “ANY”.
>
> I have a few questions to further investigate this:
>
> What could be the reason the caps event is not received by the 
> GstWebRTCBin?
> When is the caps event usually sent downstream? Is it sent only once 
> and could it be that the GstWebRTCBin somehow missed it through some 
> race condition?
> When connecting queue and webrtcbin to the tee element, do I need to 
> follow a certain order? Do I need to insert probes in order not to 
> miss the caps event?


On 14-01-2021 12:00, mkonstapel wrote:
> Hi Dominik et al,
>
> I think I am running into the exact same problem - quickly reloading the
> "player" page (thus adding webrtcbins) eventually, and apparently randomly,
> locks up the pipeline. Did you ever find a solution?
>
> Kind regards,
> Michiel Konstapel