[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