Is anyone actually using gstreamermm?

Marcin Kolny marcin.kolny at gmail.com
Thu Mar 12 22:02:47 UTC 2020


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 <ding at panopto.com> 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 <nicolas at ndufresne.ca>
> wrote:
>
>>
>>
>> Le jeu. 12 mars 2020 07 h 15, Carlos Rafael Giani <crg7475 at mailbox.org>
>> 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
>>> gstreamer-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>


-- 
Marcin Kolny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200312/6bf7c781/attachment.htm>


More information about the gstreamer-devel mailing list