<div dir="auto">Are your src pads each connected to queues of some kind?<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Demuxers, tees, anything with multiple src pads ... Each src pads should always connect to some kind of queue.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 21, 2020, 8:34 AM jackBuffington <<a href="mailto:jbuffington@redzone.com">jbuffington@redzone.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll answer my own question and ask a new one since I have received no reply. <br>
I have partially figured out what to do and hopefully this will help someone<br>
in the future.<br>
<br>
It appears that GstBaseTransform only will facilitate negotiating caps for<br>
the src and sink pads.  You are on your own for anything else.  In my case,<br>
I did the following:<br>
<br>
In the set_caps function I faked my own negotiation by copying the final<br>
caps of the src pad.  In my case, this will work because I have them<br>
connected to the same things.  I did this by:<br>
<br>
I called gst_query_caps using the src pad to get the caps on that pad.<br>
I used gst_set_caps on my other source pad(s) using the caps from the last<br>
step.<br>
I call gst_pad_query_accept_caps for my other source pad(s) to see if the<br>
connecting pad can accept those caps (I know they can but put this in<br>
because I eventually want to do a full negotiation)<br>
I then use gst_pad_push_event on my other source pad(s) with<br>
gst_event_new_caps and the caps which I want the connecting pad to use.  <br>
I'm not certain if this step is necessary but I then called<br>
gst_pad_set_active for the pad for my other source pads.   <br>
<br>
At each step I am doing checks to make sure that things go OK.  <br>
<br>
This allows things to connect up and I can see when I graph out my pipeline<br>
that the caps are indeed properly 'negotiated'.<br>
<br>
OK.   So everything works now right?   Unfortunately not.  I'm stuck again. <br>
If I connect to just one of the pads and code my chain function so that it<br>
pushes to just that pad, I get video passing through just fine.  If I<br>
connect to two pads and push to either pad, it will push one buffer and then<br>
forever hang.   If I hit Control+C to kill the pipeline then it will<br>
continue on to the next line of code which is my check to see what the<br>
return value of the push was.  It is returning GST_FLOW_FLUSHING, which is<br>
typically what I see when I kill the pipeline if I am running with only one<br>
pad connected.     <br>
<br>
So my new question is now that I am SO close to being done with this (I<br>
think) how do I just get it to not hang on the push?<br>
<br>
<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div>