<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Oh, the producer pipeline in the example was not quite correct: it should include key frames, a profile specification and config-interval for the h264 parser and payloader: <pre>... nvh264enc gop-size=50 ! video/x-h264, profile=baseline ! h264parse config-interval=-1 ! rtph264pay config-interval=-1 ...</pre> Updated version is attached. But even then, it still breaks. <div class="moz-cite-prefix">On 16-03-2021 20:51, Michiel Konstapel wrote: </div> <blockquote type="cite" cite="mid:e65fc008-20cc-9e1d-8686-b008c3537dcf@aanmelder.nl"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 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 <pre>export GI_TYPELIB_PATH=/usr/local/lib/x86_64-linux-gnu/girepository-1.0</pre> or it fails with: <pre>ValueError: Namespace GstWebRTC not available</pre> Run it once as a producer pipeline: <pre>python3 testcase.py producer </pre> And then run the consumer: <pre>python3 testcase.py consumer</pre> 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: <pre>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 </pre> 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 <div class="moz-cite-prefix">On 14-01-2021 12:04, Michiel Konstapel wrote: </div> <blockquote type="cite" cite="mid:a37f6e4d-fbdb-8744-247a-7e9cb20b2dbc@aanmelder.nl">Apologies, that lost a lot of context since it references an old email to the list. It concerns this message by Dominik: <a class="moz-txt-link-freetext" href="http://gstreamer-devel.966125.n4.nabble.com/WebRTCBin-not-receiving-caps-signal-tt4689946.html" moz-do-not-send="true">http://gstreamer-devel.966125.n4.nabble.com/WebRTCBin-not-receiving-caps-signal-tt4689946.html</a> Quoting: <blockquote type="cite">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: <a class="moz-txt-link-freetext" href="http://roettsch.es/debug_gst_webrtcbin.pdf" moz-do-not-send="true">http://roettsch.es/debug_gst_webrtcbin.pdf</a> 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? </blockquote> On 14-01-2021 12:00, mkonstapel wrote: <blockquote type="cite">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 </blockquote> </blockquote> </blockquote> <div class="moz-signature">-- Michiel Konstapel Lead Software Developer <a href="https://www.aanmelder.nl" moz-do-not-send="true">aanmelder.nl</a> T: +31(0)15 2400 119 E: <a class="moz-txt-link-abbreviated" href="mailto:michiel@aanmelder.nl" moz-do-not-send="true">michiel@aanmelder.nl</a> </div> </body> </html>