[gst-devel] Upstream caps (re)negotiation

Stefan Kost ensonic at hora-obscura.de
Tue Jun 1 21:17:25 CEST 2010


Am 27.05.2010 12:41, schrieb Martin Bisson:
> Hi,
> 
> I have questions about upstream caps renegotiation.  I've read
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-nego-upstream.html
> but I still have questions on the concrete implementation.
> 
> I'm not sure what to do when caps needs to be renegotated.  As an
> example, let's take a simple plugin that takes a video stream from its
> sink pad, does a simple thing to it by copying it into another buffer,
> then pushes that buffer on its source pad.
> 
> The chain function would try to get the output buffer using
> gst_pad_alloc_buffer.  In the normal case, it would return a buffer of
> the same caps.
> 
> But in case of caps renegotiation coming from upstream, the buffer caps
> might be different.  And I wonder what to do in that case.  I have kind
> of a tree of questions about what to do in every case.  I guess the
> first thing to do would be to try to set the caps on the plugin's source
> pad (gst_pad_set_caps), which would in turn set the caps on the plugin's
> sink pad.

I know its not easy to read, but you might find the answer in
gstreamer/libs/gst/base/gstbasetransform.c::gst_base_transform_prepare_output_buffer()
and gst_base_transform_setcaps() which I am re-reading right now too. The docs
on this subject clearly should be improved. It would be great to get some
corrections from others on my answers, I will then improve the docs.

> 
> 1) If gst_pad_set_caps function fails on the source pad (which would
> have also tried to call it on the sink pad), I guess this means that the
> negotiation failed (no possible format from downstream).  So the chain
> function should stop what it is doing, unref the input buffer and the
> output buffer, and return GST_FLOW_NOT_NEGOTIATED?

I'd say yes.

> 2) If gst_pad_set_caps function succeeds on the sink pad, I guess it
> means the caps were succesfully negotiated upstream.  So what happens to
> the input buffer during all that procedure?  Is it still valid or not?

Yes, the input buffer is unchanged and one would attempt to process it.

> 3) If it's not valid, I guess the chain function just has to stop what
> it's doing, unref the output (and the input?) buffer, but what should it
> returns as a return value?

GST_FLOW_NOT_NEGOTIATED.


> 4) If the input buffer is still valid after caps renegotiation, I see
> two possibilities: it either can be used with the new caps or it
> cannot.  For instance, if the plugin is just flipping an image upside
> down, maybe it's able to flip a yuv buffer into another yuv buffer, a
> rgb buffer into another rgb buffer, but not a yuv buffer into a rgb
> buffer.  So two possibilities depending on wether the plugin can convert
> the buffer in the old caps into a buffer in the new caps.

Correct.

> 5) If it can do it, I guess there is no problem and the chain function
> just does it and returns GST_FLOW_OK

Yep.

> 6) But if it can't do it, what does the function do?  I guess it unrefs
> the input & output buffer, but what would the return value be?

GST_FLOW_NOT_NEGOTIATED.

> 
> Thanks a lot in advance for any explanations,
> 
> Martin
> 

Sorry for late reply, hope it is still useful.

Stefan




More information about the gstreamer-devel mailing list