Building GstElement plugins using CMake

Kyle Mallory kyle at tealdrones.com
Fri Apr 14 22:28:32 UTC 2017


Hey Tim,

Thanks for the reply.  After digging in to it, I was able to get it to 
build.  You were right.  Not much to it.  And we've had some initial 
success in building a working plugin (for machine vision/deep learning).

After gaining a bit more experience with the process, my questions are 
evolving:

I'm trying to find a simple way to allow other developers, who are 
likely not familiar with Gstreamer, to develop a basic video plugin, by 
obscuring the gstreamer entry point.  Imagine something akin to the 
Arduino IDE writing a generic main() that calls the user defined setup() 
and loop().

This seems straight forward.

I'm trying to work through whether there is another, more programmatic 
way to accomplish the registration, that would callback into a wrapper 
to populate the struct GstPluginDesc.  It looks like I can manually 
register/load plugins using the gst_plugin_register_static() function.  
I'm still trying to wrap my head around it all...


Ultimately, I want a user to be able to write a simple plugin, using 
something similar to this :

void initializePlugins() {

     registerElement("tealElement", initializeElement, processElementFrame, shutdownElement);

}

bool initializeElement() {

}

bool processElementFrame( GstVideoFrame *in, GstVideoFrame *out) {

     // do something with the input frame, possibly modifying it

     // create a new output frame if necessary, or just point to the *in frame

     return true; // return false if we should just skip this frame from the output

}

void shutdownElement() {

     // final opportunity to do any local maintenance

}

This code would rely on wrapper code that could be linked with it, to do 
all the low-level gst_* calls...

It seems I might be able to do this, expect that I still need to create 
the entry point in the eventual .so file, so I still have to define the 
GstPluginDesc.  I think.

Can I have multiple plugins with the same GstPluginDesc.name being the same?

How are elements registered and initialized from within the plugin?

I see in the samples, the call to 'gst_element_register' and passing in 
the GST_TYPE_*, but I don't see where the init function for the element 
is called.. either i'm missing something, or its magic. ;-)

Also, I'm still trying to wrap my head around the whole gObject/TYPE 
thing...


Sorry, that was a bit of a rambling email...

Cheers,

--Kyle



On 04/11/2017 04:08 PM, Tim Müller wrote:
> On Tue, 2017-04-11 at 15:41 -0600, Kyle Mallory wrote:
>
> Hi Kyle,
>
>> 1) Has anyone had any success at building GStreamer Element plugins
>> using CMake rather than make?
>>
>> 2) How difficult is it to create plugins that are decoupled from the
>> Gstreamer templates that create the framework for registering the
>> plugins, etc?
> I can't point you to small-enough specific cmake examples right now,
> but this should be fairly easy really. There's nothing special about
> GStreamer plugins. If you can create a shared library/module, that's
> all you need to do from a build system perspective. Then you just need
> to use  GST_PLUGIN_DEFINE in the code to make sure the right entry
> point symbol  is there.
>
> Then you just need to install the result into the right directory to
> make sure GStreamer finds it, or tell GStreamer explicitly where to
> look for the extra plugins (e.g. via GST_PLUGIN_PATH or
> gst_registry_add_path()).
>
> Not that it helps you much, but just for completeness sake I should
> mention that we're looking at Meson as future build system, which is
> even easier to use.
>
> It's well possible I may have misunderstood what you're asking though.
>
> Cheers
>   -Tim
>



More information about the gstreamer-devel mailing list