Is anyone actually using gstreamermm?

[Sarah Newman]

I'm planning to use gstreamer for a new project which needs a pipeline and likely also a plugin. gstreamermm seems like a good idea since we're
planning on C++, but there's not a lot of evidence of it being used in the wild.

Is gstreamermm reliable enough for one or both of those tasks right now?  I don't see any examples for writing a plugin using gstreamermm, which
suggests it might not be fit for that purpose. And if it does work, is there a minimum version we should be using?

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

[David Ing]

I don't know anything about the project, but a quick glance at the commit history shows no activity since 1.10.  I am guessing the project is out of date.

I have a C++ project which consumes gstreamer, and I just consume the C-language API.

You might want to invest in a day creating some shared pointers for frequently used objects which already have reference-counting functionality.  You would just write very thin C++ wrappers to tap the existing reference counting functionality.

• GObject
• GstMiniObject
• GstObject

On Wed, Mar 11, 2020 at 10:09 AM Sarah Newman <[hidden email]> wrote:

I'm planning to use gstreamer for a new project which needs a pipeline and likely also a plugin. gstreamermm seems like a good idea since we're
planning on C++, but there's not a lot of evidence of it being used in the wild.

Is gstreamermm reliable enough for one or both of those tasks right now?  I don't see any examples for writing a plugin using gstreamermm, which
suggests it might not be fit for that purpose. And if it does work, is there a minimum version we should be using?

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

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

[Marcin Kolny]

Hi Sarah,

ex-gstreamermm maintainer here. The project is not being maintained for a while (as you can see from the commit list), but you can still use it even with the latest version of gstreamer (however, some of the APIs might not have all the methods wrapped so you'll still need to use C API and .gobj() method).

In terms of plugins; it's actually possible to write them fully in C++. Unfortunately I never managed to write any example, but there's a few tests which you can treat as examples [1]. Also, a few years ago I gave a talk about gstreamermm [2] and briefly talked about all the features of that project (including writing plugins) so you might find it useful.

[1] https://github.com/GNOME/gstreamermm/tree/master/tests/plugins

[2] https://gstconf.ubicast.tv/videos/gstreamermm-c-way-of-doing-gstreamer-based-applications/

śr., 11 mar 2020 o 17:49 David Ing <[hidden email]> napisał(a):

I don't know anything about the project, but a quick glance at the commit history shows no activity since 1.10.  I am guessing the project is out of date.

I have a C++ project which consumes gstreamer, and I just consume the C-language API.

You might want to invest in a day creating some shared pointers for frequently used objects which already have reference-counting functionality.  You would just write very thin C++ wrappers to tap the existing reference counting functionality.

• GObject
• GstMiniObject
• GstObject

On Wed, Mar 11, 2020 at 10:09 AM Sarah Newman <[hidden email]> wrote:

I'm planning to use gstreamer for a new project which needs a pipeline and likely also a plugin. gstreamermm seems like a good idea since we're
planning on C++, but there's not a lot of evidence of it being used in the wild.

Is gstreamermm reliable enough for one or both of those tasks right now?  I don't see any examples for writing a plugin using gstreamermm, which
suggests it might not be fit for that purpose. And if it does work, is there a minimum version we should be using?

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

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

--

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

[Sarah Newman]

Hi Marcin,

Thank you for that information.

Sometimes a project is "done" and doesn't need new commits, so I didn't take the lack of recent commits as a 100% guarantee of it being unmaintained.
But if there are no current maintainers who will fix it if it breaks, then I'd rather use the C API - I don't want to become a gstreamer maintainer
myself right now.

--Sarah

On 3/11/20 1:57 PM, Marcin Kolny wrote:

> Hi Sarah,
> ex-gstreamermm maintainer here. The project is not being maintained for a
> while (as you can see from the commit list), but you can still use it even
> with the latest version of gstreamer (however, some of the APIs might not
> have all the methods wrapped so you'll still need to use C API and .gobj()
> method).
> In terms of plugins; it's actually possible to write them fully in C++.
> Unfortunately I never managed to write any example, but there's a few tests
> which you can treat as examples [1]. Also, a few years ago I gave a talk
> about gstreamermm [2] and briefly talked about all the features of that
> project (including writing plugins) so you might find it useful.
>
> [1] https://github.com/GNOME/gstreamermm/tree/master/tests/plugins
> [2]
> https://gstconf.ubicast.tv/videos/gstreamermm-c-way-of-doing-gstreamer-based-applications/

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

[Tim Müller]

On Wed, 2020-03-11 at 14:04 -0700, Sarah Newman wrote:

Hi Sarah,

> But if there are no current maintainers who will fix it if it breaks,
> then I'd rather use the C API - I don't want to become a gstreamer
> maintainer myself right now.

Just in case you're flexible in terms of what higher-level language to
use here, the Rust bindings are actively maintained and up-to-date.

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

[Carlos Rafael Giani-2]

On 11.03.20 21:57, Marcin Kolny wrote:
> In terms of plugins; it's actually possible to write them fully in
> C++. Unfortunately I never managed to write any example, but there's a
> few tests which you can treat as examples [1].


I've done that in the past. This is largely straightforward, but there
are a few gotchas:


1. Any C++ objects in the element and element class structures must be
initialized with placement-new (don't forget to include the <new> header
for this!) and have their destructors explicitely called. That's because
the structures are allocated with C allocators, which know nothing about
constructors and destructors. Example:

struct MyGstElement
{
   GstElement parent;

   MyCppObject cpp_object;
};

....

void my_gst_element_init(MyGstElement *self)
{
   new (&self->cpp_object) MyCppObject(<constructor arguments>);
}

void my_gst_element_finalize(GObject *object)
{
   ...
   self->cpp_object.~MyCppObject();
   ...
}

Since this can get annoying quickly if you have many C++ objects in your
element, I recommend creating one struct with all C++ objects inside,
and then call that struct's constructor and destructor in _init() and
_finalize().


2. Surround GST_PLUGIN_DEFINE() with extern "C" { }. Otherwise, name
mangling may mess up the symbols that the plugin loader looks for.


3. Sometimes, people like to write internal structs and call the struct
instances something like "private". But "private" is a C++ keyword!


4. I recommend using std::string as often as you can instead of C
strings, since the former are _so_ much nicer and easier to use. But
when combining them with GObject properties, GstStructures etc. you must
always remember to convert from/to C strings. Since the type is erased
at compile time, nothing will warn you or produce an error, you can
easily get a crash instead.


5. C++ is more strict about implicit casts. In particular, in GParam
functions like g_param_spec_uint(), the flags parameter is often set to
a bitwise OR combination of enums, like G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS . In C, this is implicitely cast to GParamFlags.
In C++, you get a compiler error, so you must explicitely cast this,
like so: GParamFlags(G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)

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

[Nicolas Dufresne-5]

Le jeu. 12 mars 2020 07 h 15, Carlos Rafael Giani <[hidden email]> a écrit :

On 11.03.20 21:57, Marcin Kolny wrote:
> In terms of plugins; it's actually possible to write them fully in
> C++. Unfortunately I never managed to write any example, but there's a
> few tests which you can treat as examples [1].


I've done that in the past. This is largely straightforward, but there
are a few gotchas:


1. Any C++ objects in the element and element class structures must be
initialized with placement-new (don't forget to include the <new> header
for this!) and have their destructors explicitely called. That's because
the structures are allocated with C allocators, which know nothing about
constructors and destructors. Example:

struct MyGstElement
{
   GstElement parent;

   MyCppObject cpp_object;
};

....

void my_gst_element_init(MyGstElement *self)
{
   new (&self->cpp_object) MyCppObject(<constructor arguments>);
}

void my_gst_element_finalize(GObject *object)
{
   ...
   self->cpp_object.~MyCppObject();
   ...
}

Since this can get annoying quickly if you have many C++ objects in your
element, I recommend creating one struct with all C++ objects inside,
and then call that struct's constructor and destructor in _init() and
_finalize().


2. Surround GST_PLUGIN_DEFINE() with extern "C" { }. Otherwise, name
mangling may mess up the symbols that the plugin loader looks for.

This is already handled by that macro.

3. Sometimes, people like to write internal structs and call the struct
instances something like "private". But "private" is a C++ keyword!


4. I recommend using std::string as often as you can instead of C
strings, since the former are _so_ much nicer and easier to use. But
when combining them with GObject properties, GstStructures etc. you must
always remember to convert from/to C strings. Since the type is erased
at compile time, nothing will warn you or produce an error, you can
easily get a crash instead.


5. C++ is more strict about implicit casts. In particular, in GParam
functions like g_param_spec_uint(), the flags parameter is often set to
a bitwise OR combination of enums, like G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS . In C, this is implicitely cast to GParamFlags.
In C++, you get a compiler error, so you must explicitely cast this,
like so: GParamFlags(G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)

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

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

[David Ing]

Marcin --

I watched your presentation and it was excellent.

Do you know if anyone is planning to convert the gstreamermm project to meson?  I am specifically interested in a solution where the Windows (MSVC) build is simply supported by the same code generation / build scripts which currently support the Linux build.  (My C++ code runs on both platforms.)

On Thu, Mar 12, 2020 at 5:10 AM Nicolas Dufresne <[hidden email]> wrote:

Le jeu. 12 mars 2020 07 h 15, Carlos Rafael Giani <[hidden email]> a écrit :

On 11.03.20 21:57, Marcin Kolny wrote:
> In terms of plugins; it's actually possible to write them fully in
> C++. Unfortunately I never managed to write any example, but there's a
> few tests which you can treat as examples [1].


I've done that in the past. This is largely straightforward, but there
are a few gotchas:


1. Any C++ objects in the element and element class structures must be
initialized with placement-new (don't forget to include the <new> header
for this!) and have their destructors explicitely called. That's because
the structures are allocated with C allocators, which know nothing about
constructors and destructors. Example:

struct MyGstElement
{
   GstElement parent;

   MyCppObject cpp_object;
};

....

void my_gst_element_init(MyGstElement *self)
{
   new (&self->cpp_object) MyCppObject(<constructor arguments>);
}

void my_gst_element_finalize(GObject *object)
{
   ...
   self->cpp_object.~MyCppObject();
   ...
}

Since this can get annoying quickly if you have many C++ objects in your
element, I recommend creating one struct with all C++ objects inside,
and then call that struct's constructor and destructor in _init() and
_finalize().


2. Surround GST_PLUGIN_DEFINE() with extern "C" { }. Otherwise, name
mangling may mess up the symbols that the plugin loader looks for.

This is already handled by that macro.

3. Sometimes, people like to write internal structs and call the struct
instances something like "private". But "private" is a C++ keyword!


4. I recommend using std::string as often as you can instead of C
strings, since the former are _so_ much nicer and easier to use. But
when combining them with GObject properties, GstStructures etc. you must
always remember to convert from/to C strings. Since the type is erased
at compile time, nothing will warn you or produce an error, you can
easily get a crash instead.


5. C++ is more strict about implicit casts. In particular, in GParam
functions like g_param_spec_uint(), the flags parameter is often set to
a bitwise OR combination of enums, like G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS . In C, this is implicitely cast to GParamFlags.
In C++, you get a compiler error, so you must explicitely cast this,
like so: GParamFlags(G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)

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

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

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

[Marcin Kolny]

Hi David,

I'm not aware of any meson port of gstreamermm, however, I can see that glibmm has already been ported, so porting gstreamermm should be relatively easy. As I said, I don't know of any work that's in progress though.

czw., 12 mar 2020 o 16:08 David Ing <[hidden email]> napisał(a):

Marcin --

I watched your presentation and it was excellent.

Do you know if anyone is planning to convert the gstreamermm project to meson?  I am specifically interested in a solution where the Windows (MSVC) build is simply supported by the same code generation / build scripts which currently support the Linux build.  (My C++ code runs on both platforms.)

On Thu, Mar 12, 2020 at 5:10 AM Nicolas Dufresne <[hidden email]> wrote:

Le jeu. 12 mars 2020 07 h 15, Carlos Rafael Giani <[hidden email]> a écrit :

On 11.03.20 21:57, Marcin Kolny wrote:
> In terms of plugins; it's actually possible to write them fully in
> C++. Unfortunately I never managed to write any example, but there's a
> few tests which you can treat as examples [1].


I've done that in the past. This is largely straightforward, but there
are a few gotchas:


1. Any C++ objects in the element and element class structures must be
initialized with placement-new (don't forget to include the <new> header
for this!) and have their destructors explicitely called. That's because
the structures are allocated with C allocators, which know nothing about
constructors and destructors. Example:

struct MyGstElement
{
   GstElement parent;

   MyCppObject cpp_object;
};

....

void my_gst_element_init(MyGstElement *self)
{
   new (&self->cpp_object) MyCppObject(<constructor arguments>);
}

void my_gst_element_finalize(GObject *object)
{
   ...
   self->cpp_object.~MyCppObject();
   ...
}

Since this can get annoying quickly if you have many C++ objects in your
element, I recommend creating one struct with all C++ objects inside,
and then call that struct's constructor and destructor in _init() and
_finalize().


2. Surround GST_PLUGIN_DEFINE() with extern "C" { }. Otherwise, name
mangling may mess up the symbols that the plugin loader looks for.

This is already handled by that macro.

3. Sometimes, people like to write internal structs and call the struct
instances something like "private". But "private" is a C++ keyword!


4. I recommend using std::string as often as you can instead of C
strings, since the former are _so_ much nicer and easier to use. But
when combining them with GObject properties, GstStructures etc. you must
always remember to convert from/to C strings. Since the type is erased
at compile time, nothing will warn you or produce an error, you can
easily get a crash instead.


5. C++ is more strict about implicit casts. In particular, in GParam
functions like g_param_spec_uint(), the flags parameter is often set to
a bitwise OR combination of enums, like G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS . In C, this is implicitely cast to GParamFlags.
In C++, you get a compiler error, so you must explicitely cast this,
like so: GParamFlags(G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS)

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

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

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

--

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