Building GstElement plugins using CMake

[Kyle Mallory]

Two questions:

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?


Background:

We are interested in using Gstreamer as the video pipeline for our drone
(www.tealdrones.com), and would like to utilize plugins as an "entry
point" for our drone-side SDK to access that pipeline.  For example, a
developer could use Gst plugins to provide augmented reality capability
by taking the default camera pipeline, receiving telemetry information
from the Teal SDK, and rendering over the video pipeline, before sending
the resulting stream of RTP to the ground station.

One of the challenges we are facing is the ease of entry into developing
plugins. We need to make it as simple as possible for our SDK users to
create a basic plugin, that provides frames on one end, and accepts
frames on the downward side.  We're considering providing a wrapper
layer to encapsulate this basic functionality, but the current tools are
not very friendly.

Further complicating this, our SDK build system is built around CMake,
and we promote the use of CLion as our preferred IDE.

Our goal is to provide a 3 or 4 bullet-proof examples of how to create
new plugins, that just work with Gstreamer.


Thanks in advance, and I'm looking forward to participating regularly
(and hopefully contributing meaningfully) to future discussions.


--Kyle
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

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

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Kyle Mallory]

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
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel