<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.</p>
    <p>In my environment (1.18.3 built from source) I had to run<br>
    </p>
    <pre>export GI_TYPELIB_PATH=/usr/local/lib/x86_64-linux-gnu/girepository-1.0</pre>
    <p>or it fails with:<br>
    </p>
    <pre>ValueError: Namespace GstWebRTC not available</pre>
    <p>Run it once as a producer pipeline:</p>
    <pre>python3 testcase.py producer
</pre>
    <p>And then run the consumer:</p>
    <pre>python3 testcase.py consumer</pre>
    <p>This will just add a whole bunch of webrtcbins to the running
      pipeline.<br>
    </p>
    <p>Occasionally, this will successfully add 100 webrtcbins to the
      pipeline, but usually, it'll lock up:</p>
    <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>
    <p>And then it just freezes.<br>
    </p>
    <p> 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.<br>
    </p>
    <p>Matthew or other experts, any ideas? Is there an issue tracker I
      should add this to? Is there something wrong with this approach?</p>
    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.<br>
    <p>Kind regards,<br>
      Michiel<br>
    </p>
    <div class="moz-cite-prefix">On 14-01-2021 12:04, Michiel Konstapel
      wrote:<br>
    </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">http://gstreamer-devel.966125.n4.nabble.com/WebRTCBin-not-receiving-caps-signal-tt4689946.html</a><br>
      <br>
      Quoting:
      <br>
      <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.
        <br>
        <br>
        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.
        <br>
        <br>
        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.
        <br>
        <br>
        A PDF of the pipeline is here:
        <a class="moz-txt-link-freetext" href="http://roettsch.es/debug_gst_webrtcbin.pdf">http://roettsch.es/debug_gst_webrtcbin.pdf</a> and an image of the
        relevant portions is attached.
        <br>
        <br>
        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”.
        <br>
        <br>
        I have a few questions to further investigate this:
        <br>
        <br>
        What could be the reason the caps event is not received by the
        GstWebRTCBin?
        <br>
        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?
        <br>
        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?
        <br>
      </blockquote>
      <br>
      <br>
      On 14-01-2021 12:00, mkonstapel wrote:
      <br>
      <blockquote type="cite">Hi Dominik et al,
        <br>
        <br>
        I think I am running into the exact same problem - quickly
        reloading the
        <br>
        "player" page (thus adding webrtcbins) eventually, and
        apparently randomly,
        <br>
        locks up the pipeline. Did you ever find a solution?
        <br>
        <br>
        Kind regards,
        <br>
        Michiel Konstapel <br>
      </blockquote>
    </blockquote>
  </body>
</html>