Strange pipeline behaviour when assigning capabilities to plugin source pad

[Terence Neill]

Thanks for the reply, I have traced the problem.  It was caused by the component "mytestcomponent" modifying the caps data on its input buffers before passing the buffers on.  When running multiple instances of "mytestcomponent" they all ended up modifying the same buffer with predictably nasty results.

-----Original Message-----
From: gstreamer-devel-bounces at lists.freedesktop.org [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Sebastian Dröge
Sent: 29 October 2013 08:27
To: Discussion of the development of and with GStreamer
Subject: Re: Strange pipeline behaviour when assigning capabilities to plugin source pad

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