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