WebRTCBin not receiving caps signal

Tue Mar 16 19:51:45 UTC 2021

After several days of banging my head on the wall, I've gone and split 
off the webrtc part into a separate pipeline, connected to the main one 
through udpsink/udpsrc. However, even then adding webrtcbins will 
randomly lock up. I've narrowed it down to a pretty small testcase in 
the attached python file.

In my environment (1.18.3 built from source) I had to run

export GI_TYPELIB_PATH=/usr/local/lib/x86_64-linux-gnu/girepository-1.0

or it fails with:

ValueError: Namespace GstWebRTC not available

Run it once as a producer pipeline:

python3 testcase.py producer

And then run the consumer:

python3 testcase.py consumer

This will just add a whole bunch of webrtcbins to the running pipeline.

Occasionally, this will successfully add 100 webrtcbins to the pipeline, 
but usually, it'll lock up:

gstwebrtcbin.c:319:gst_webrtc_bin_pad_new:<'':sink_0> new visible pad with direction sink
gstwebrtcbin.c:469:_find_transceiver_for_mline:<webrtcbin97> Found transceiver (NULL) for mlineindex 0
gstwebrtcbin.c:5823:gst_webrtc_bin_request_new_pad:<webrtcbin97> Created new transceiver <webrtctransceiver97> for mline 0
gstwebrtcbin.c:5737:gst_webrtc_bin_change_state: changing state: NULL => READY
gstwebrtcbin.c:1354:_check_if_negotiation_is_needed:<webrtcbin97> checking if negotiation is needed
gstwebrtcbin.c:1360:_check_if_negotiation_is_needed:<webrtcbin97> no negotiation possible until caps have been received on all sink pads
gstwebrtcbin.c:5737:gst_webrtc_bin_change_state: changing state: READY => PAUSED
gstwebrtcbin.c:5737:gst_webrtc_bin_change_state: changing state: PAUSED => PLAYING

And then it just freezes.

Sometimes it's the 98th, sometimes it's the 10th. I've ran it with 
maximum GST_DEBUG, added print statements to gstwebrtcbin.c, and I can't 
find anything that sets apart the successful and failing attempts. 
Adding sleeps seems to help, but it's not foolproof and I have no idea 
why it would help.

Matthew or other experts, any ideas? Is there an issue tracker I should 
add this to? Is there something wrong with this approach?

I did find a workaround: if I pause the whole consumer pipeline, add the 
webrtcbin, and then set the pipeline playing, that appears to prevent 
the race condition. Now that it's in a separate pipeline, that's a 
viable option, but it still doesn't sit right with me that it just 
randomly... stops.

Kind regards,
Michiel

On 14-01-2021 12:04, Michiel Konstapel wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210316/ac6f137c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase.py
Type: text/x-python
Size: 4160 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210316/ac6f137c/attachment.py>