Caps negotiation when there are multiple src pads

[David Ing]

Are your src pads each connected to queues of some kind?

Elements with multiple src pads should always be connected directly to
queues because queues create thread boundaries.  Without these thread
boundaries you typically see deadlocking.  I have even seen deadlocking
during caps negotiation.

Demuxers, tees, anything with multiple src pads ... Each src pads should
always connect to some kind of queue.

On Thu, May 21, 2020, 8:34 AM jackBuffington <jbuffington at redzone.com>
wrote:

> I'll answer my own question and ask a new one since I have received no
> reply.
> I have partially figured out what to do and hopefully this will help
> someone
> in the future.
>
> It appears that GstBaseTransform only will facilitate negotiating caps for
> the src and sink pads.  You are on your own for anything else.  In my case,
> I did the following:
>
> In the set_caps function I faked my own negotiation by copying the final
> caps of the src pad.  In my case, this will work because I have them
> connected to the same things.  I did this by:
>
> I called gst_query_caps using the src pad to get the caps on that pad.
> I used gst_set_caps on my other source pad(s) using the caps from the last
> step.
> I call gst_pad_query_accept_caps for my other source pad(s) to see if the
> connecting pad can accept those caps (I know they can but put this in
> because I eventually want to do a full negotiation)
> I then use gst_pad_push_event on my other source pad(s) with
> gst_event_new_caps and the caps which I want the connecting pad to use.
> I'm not certain if this step is necessary but I then called
> gst_pad_set_active for the pad for my other source pads.
>
> At each step I am doing checks to make sure that things go OK.
>
> This allows things to connect up and I can see when I graph out my pipeline
> that the caps are indeed properly 'negotiated'.
>
> OK.   So everything works now right?   Unfortunately not.  I'm stuck
> again.
> If I connect to just one of the pads and code my chain function so that it
> pushes to just that pad, I get video passing through just fine.  If I
> connect to two pads and push to either pad, it will push one buffer and
> then
> forever hang.   If I hit Control+C to kill the pipeline then it will
> continue on to the next line of code which is my check to see what the
> return value of the push was.  It is returning GST_FLOW_FLUSHING, which is
> typically what I see when I kill the pipeline if I am running with only one
> pad connected.
>
> So my new question is now that I am SO close to being done with this (I
> think) how do I just get it to not hang on the push?
>
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200521/49eb6dc9/attachment.htm>