Strange pipeline behaviour when assigning capabilities to plugin source pad

Terence Neill t.neill at btinternet.com
Mon Oct 28 23:41:59 CET 2013


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!

Thanks in advance,

Regards,

Terry

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131028/544cfdac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131028/544cfdac/attachment.pgp>


More information about the gstreamer-devel mailing list