webrtcbin: Remove a connecting webrtcbin from running pipeline

[Eric Timmons]

On Tuesday, January 25th, 2022 at 11:24 PM, Matthew Waters via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:

> Hi,
>
> Before negotiation completes, webrtcbin will block the input pad to avoid losing data (at the expense of a potential burst of data at the start).
>
> This block of the webrtcbin input pad in turn blocks the upstream queue in the pad stream lock:
>
> [...]
>
> To fix, you need to avoid the queue from blocking, you need to remove the data from the pipeline.  One (tested) solution is to bring the state of webrtcbin down before the queue element which causes the pad to return flushing upstream on any push and the webrtcbin input pad block to be removed.

Thanks, that fixed it in our test case! I haven't had the time to test on the actual code yet, but hopefully it will work there as well!

> Another fix may be to bring the element states down in lock-step from PLAYING->PAUSED->READY->NULL (which is what bin's do internally).

Surprisingly this did not work (at least when transitioning elements in order from the queue down to the webrtcbin). We'll have to keep that in mind if we decide to make a custom bin for that segment of the pipeline.

-Eric

>
> Cheers
> -Matt
>
> On 26/1/22 05:11, Eric Timmons via gstreamer-devel wrote:
>
> > I've got an application where we're streaming video to multiple clients using WebRTC. Our video goes into a tee element and then each WebRTC branch of the tee has a queue, rtph264pay, and webrtcbin element. Dynamically adding new branches to this pipeline works great. Dynamically removing branches as clients go away works, but only if the both the SDP and ICE negotiations have finished.
> >
> > We can't figure out how to remove a branch where an offer has been sent, but no answer received. Currently, we disconnect the branch from the tee, set the states of every element in the branch to NULL, and then remove them from the pipeline. If negotiations have not finished, then setting any element's state to NULL blocks indefinitely.
> >
> > We've additionally tried sending an EOS through the branch after disconnecting from the tee, but the EOS doesn't ever seem to leave the queue.
> >
> > I've attached an example using the Python bindings. This hangs on Line 107 in both 1.18.4 and current main branch.
> >
> > Thanks!
> > -Eric