Upstream caps (re)negotiation

[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.

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?
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?
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?
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.
5) If it can do it, I guess there is no problem and the chain function just does it and returns GST_FLOW_OK
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?

Thanks a lot in advance for any explanations,

Martin

------------------------------------------------------------------------------


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

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

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel