Webrtcbin sink pad caps negotiation blocked

[Trey Hutcheson]

Ok I tracked it down. I had a loop in the pipeline: the output of one
webrtbin element was directed to an input-selector, which fed video back as
an input into the same webrtcbin element. In normal no-load situations this
particular pipeline setup worked just fine, but under load for some reason
the caps never arrived.

I've since implemented a workaround that prevents the loop/cycle, and feeds
in a fake video source into webrtcbin; this video source is not dependent
on anything else in the pipeline, and caps are negotiated on the sink pad
with zero delay.

On Thu, Sep 17, 2020, 8:50 AM Trey Hutcheson <trey.hutcheson at gmail.com>
wrote:

> This is on gstreamer 1.16.2. And it's difficult to describe, so please be
> patient.
>
> I have an application server with a rest api. The rest api is used to
> build N number of dynamic pipelines. Sometimes these pipelines have
> branches that use webrtcbin, and the rest api is the signaling layer.
>
> When doing sdp negotiation, the remote peer provides an offer. Depending
> on what's in the offer, I connect a vp8 and/or opus sources to webrtcbin
> *before* setting the remote description and generating the answer. I was
> told here that I would need for webrtcbin to create the sink pads, and to
> watch for caps to become available on those sink pads before I could
> negotiate sdp.
>
> So I've added signals/waits to do just that. I add a signal handler for
> pad-added, and if it's a sink pad, add a signal handler for notify::caps
> (actually this is all rust, so using the gstreamer-rs api).
>
> When the sdp offer is posted to the api layer, I link the vp8 and/or opus
> sources. I then wait for a cvar to be signalled. The cvar is signalled in
> the notify::caps signal handler. I've got a reasonable wait timeout of
> 500ms, but it doesn't really matter.
>
> When there is no thread contention, the cvar wait never times out. It
> works as expected. Caps are set on the sink pad, the cvar is signalled, and
> the waiting threads are unblocked. *However*, when there is lots of
> activity (i.e., lots of pipelines, and lots of threads), the caps never
> arrive on the sink pad.
>
> And that doesn't make sense to me. The input sources fed into webrtcbin
> are all connected via an application thread. The application thread then
> waits. I was sure that the sink pad caps negotiation would occur on a
> gstreamer managed thread, and suspending the application thread would have
> zero effect. In my load test logs, I've seen the caps arrive 10, 20, 30
> seconds later, usually when I've tried to free tear down the pipeline.
>
> So what is the best way to block the application thread to wait for caps
> to arrive on the sink pad while at the same time forcing webrtcbin to push
> the caps down?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200921/47514cdd/attachment.htm>