Caps negotiation when there are multiple src pads

[Mathieu Duponchelle]

It sounds like what you want to do is closer to a demuxer than your
typical BaseTransform subclass. While we do have a base class
for N-to-1 elements (GstAggregator), you are indeed on your own
when it comes to 1-to-N elements for now.

As David pointed out, the hang is at least easily solvable as it is a
standard trap when plugging in a demuxer-like element: your first
push hangs forever, blocked by the prerolling sink, and prerolling
will never occur because you would need to push on your second
src pad for all sinks to be prerolled :)

Depending on your use case, you can either make your sinks
async=false, or add queues (that's the most commonly correct
solution).

Depending on what you're trying to do, you might want to subclass
GstElement directly, and take some inspiration from standard
demuxers. Note that you probably want to use a GstFlowCombiner
by the way.

Good luck,

-- 
Mathieu Duponchelle · https://www.centricular.com


On 5/21/20 5:34 PM, jackBuffington 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