Strange pipeline behaviour when assigning capabilities to plugin source pad

[Sebastian Dröge]

On Mo, 2013-10-28 at 22:41 +0000, Terence Neill wrote:
> Hello folks,
> 
> I am using GStreamer version 0.10 on an embedded platform (at the moment, I cannot move to GStreamer 1.0). I am using a custom plugin (called mytestcomponent) and having some difficulties when assigning capabilities to the plugin source pad. I have compiled the plugin for the host environment that I am using (Ubuntu) too and it exhibits exactly the same behaviour on both the host and embedded platform.
> 
> To show this problem, the simplest pipeline that I am using is:
> 
> gst-launch-0.10 -v videotestsrc  ! tee silent=true name=tp ! queue silent=true ! mytestcomponent ! fakesink silent=true tp. ! queue silent=true ! mytestcomponent ! fakesink silent=true tp. ! queue silent=true ! mytestcomponent ! fakesink silent=true tp. ! queue silent=true ! mytestcomponent ! fakesink silent=true
> 
> This pipeline takes the videotestsrc output and splits it into 4 streams, each passing through an instance of “mytestcomponent”.
> 
> The plugin is based on the standard Gstreamer plugin template.  It has two pads, a source pad and a sink pad.  These pads use the standard static template that comes with the example plugin:
> 
> static GstStaticPadTemplate src_pad_template= GST_STATIC_PAD_TEMPLATE ("src",
>                          GST_PAD_SRC,
>                          GST_PAD_ALWAYS,
>                          GST_STATIC_CAPS_ANY
>                          );
> 
> static GstStaticPadTemplate sink_pad_template =
> GST_STATIC_PAD_TEMPLATE ("sink",
>                          GST_PAD_SINK,
>                          GST_PAD_ALWAYS,
>                          GST_STATIC_CAPS_ANY
>                          );
> 
> The plugin also registers a “set_caps” callback function against the sink pad.
> 
> What I am seeing is that, for the pipeline above, if I register any sort of caps against the source pad, the sink pad set caps function gets called continually for all instances of “mytestcomponent”.  The caps that are being set against the sink pad look like random source caps from all other instances of “mytestcomponent”.  The pipeline runs for a while and eventually crashes (usually after about 2 to 3 minutes).
> 
> If I don’t register any sort of caps against the source pad, then the pipeline functions without any problems (the set_caps callback is called once for every instance of mytestcomponent and never again).
> 
> If I reduce the pipeline to the following simplified version (with only one instance of “mytestcomponent”):
> 
> gst-launch-0.10 -v videotestsrc  ! tee silent=true name=tp ! queue silent=true ! mytestcomponent ! fakesink silent=true
> 
> then the pipeline runs without any issues even with caps registered against the source pad.
> 
> The problem does feel like some sort of shared data problem, but, as yet, I have not been able to find any global data that is shared between all instances of the test component other than the source and sink pad templates.
> 
> Has anyone ever come across a similar issue when using GStreamer?  Any hints about what the problem is most likely to be would be appreciated!

Can you show the function where you set the caps on the srcpad? Are you
calling gst_pad_set_caps() there on the srcpad or the sinkpad? Are you
changing the caps of the buffers that are passed through your element to
the new caps?

Without seeing the code there's not much I can tell you.

-- 
Sebastian Dröge <sebastian at centricular.com>
Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131029/812b09e3/attachment.pgp>