interfacing gobject with C++

Question

I’m trying to create a custom audio sink plugin for gstreamer using the Gst::AudioSink as a base class. For me this involves multiple learning curves as I’m new to gstreamer, gstreamermm and gobject. Also I have no background or real interest in gtkmm as I’m not working on GUI code at present.

I am trying to create a class along the lines of:

class MyAudioSink: public Gst::AudioSink
{
public:
    explicit MyAudioSink(MyAudioSink *gobj);
    virtual ~MyAudioSink();

    static void class_init(Gst::ElementClass<MyAudioSink> *klass);

    virtual int write_vfunc(gpointer data, guint length) override;
    virtual void reset_vfunc();
};

I seem to missing some magic in the class_init() function that should link the base class functions to the virtual functions in MyAudioSink. In C we would do something like:

  GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
  GstAudioSinkClass *audio_sink_class = GST_AUDIO_SINK_CLASS (klass);
  audio_sink_class->write = GST_DEBUG_FUNCPTR (myaudiosink_write);

I don’t really grok the C++ binding to gobject. What is the equivalent for linking to the C++ virtual function hierarchy?

I got the impression from Marcin’s video https://gstconf.ubicast.tv/videos/gstreamermm-c-way-of-doing-gstreamer-based-applications/ that the virtual functions should be invoked automatically.

I can create a half usable (doesn’t handle things like EOS) plugin by adding:

   add_pad(sinkpad = Gst::Pad::create(get_pad_template("sink"), "sink"));
   sinkpad->set_chain_function(sigc::mem_fun(*this, &MyAudioSink::chain));

But I don't think a sink should have a chain function.

I've also asked this question on the gtkmm mailing list. If I get an answer there I will post it here.

For MyAudioSink I get a class hierarchy of:

GObject +----GInitiallyUnowned +----GstObject +----GstElement +----myaudiosink

Rather than:

GObject +----GInitiallyUnowned +----GstObject +----GstElement +----GstBaseAudioSink +----GstAudioSink +----myaudiosink

I suspect this is the essence of my problem.

For the audiofilter example Marcin mentions here I get a class hierachy of:

GObject +----GInitiallyUnowned +----GstObject +----GstElement +----GstBaseTransform +----GstAudioFilter +----myaudiofilter

Ungotten

@Mgetz Why? Glib::Object is already the ultimate base in the class hierarchy. What would adding a 2nd copy solve, rather than make worse? – Vintage

class_init has nothing to do with virtual functions. It is described here. You should not call any set_*_function there. – Gatt

That is true for wrappers created using glibmm but not for gobject classes written in C. If you create an element using gst-element-maker the resulting code has boiler plate to set up the gobject virtual function pointers. E.g. gst-element-maker demosink audiosink gives you gstdemosink.c containing: gst_demosink_class_init (GstDemosinkClass * klass) { GstAudioSinkClass *audio_sink_class = GST_AUDIO_SINK_CLASS (klass); audio_sink_class->open = GST_DEBUG_FUNCPTR (gst_demosink_open); – Ungotten

But it is correct to say that it is not true for static methods in mm wrapper classes. In both cases the class_init is for meta data about the class. I'd say meta-class but that may come to mean something else in c++ in the not too distant future. – Ungotten

Yes but we're talking about C++, the C level callbacks are set up by the base class and the actual dispatch is taken care of by the virtual functions mechanism. – Gatt

The problem for me was not the C++ side but the gobject side. How mm wrappers work is not so well documented. As I new user I inferred that the static class_init function matches the <classname>_class_init you produce in C. It does but glibmmproc takes care of the vfunc boilerplate ...unless it doesn't work for some reason that leaves a new user scratching his head. It was far from obvious that adding static method called get_base_type() broke this. – Ungotten

Answer 1

It turns out that much of my troubles were caused by cutting and pasting this into MyAudioSink class:

static GType get_base_type()
    {
       return Element::get_base_type();
    }

This had the effect of telling gobject that my class is based on gstElement which was wrong. I thought it was some innocent cast like incantation. This shows the perils of cut and paste but more than that the perils of coding blindly. I was also guilty of oversimplifying the sample code I pasted here such that no-one my question doesn't show the problem.

That fixes my problem but does not answer my question. I will try to summarise that below.

"What is the equivalent for linking to the C++ virtual function hierarchy?"

To create a wrapper to a gobject class the normal process is to use glibmmproc. The wrapper is defined by files with extension .hg and .ccg from which the C++ interface and a gobject wrapper are generated.

For example to wrap a gobject classs foo you might create Foo.hg and Foo.ccg. glibmmproc would then generate Foo.h and Foo.cc. Foo.cc includes most of your definition of the Foo class but with an additional gobject wrapper Foo_class.

Foo_class is a gobject class which wraps gobject virtual functions (vfunc_callbacks) and forwards them to Foo allowing derived classes of Foo to use C++ inheritance and C++ virtual functions. The boilerplate is hidden and a C++ developer need for the most part only worry about the C++ interface provided by Foo.h

One way to understand the internals is to build gstreamermm from source and study the code generated by glibmmproc. For my case this would be: gstreamermm/audiosink.cc & gstreamermm/audiosink.h generated from src/audiosink.ccg and src/audiosink.hg

So how does the derived C++ class register itself?

• Gst::ElementFactory::register_element() - registers the class with gstreamer
• Gst::register_mm_type - records the inheritance relationship

See your local /usr/include/gstreamermm-1.0/gstreamermm/register.h for the implementation

Glib::ObjectBase(typeid (MyAudioSink)) is not required in my case as I am not using multiple inheritance. However it is critical in other applications which do. See for example Implementing a custom gtkmm treemodel

Ungotten

Answer 2

You can find examples of writing your own plugin in the repository: https://git.gnome.org/browse/gstreamermm/tree/tests/plugins/derivedfrombasetransform.h

In general, your header looks ok, and full implementation should look (more or less) like that:

class MyAudioSink: public Gst::AudioSink
{
public:
    explicit MyAudioSink(KantarAudioSink *gobj)
        : Glib::ObjectBase(typeid (MyAudioSink)),
          Gst::AudioSink(gobj) {}

    static void class_init(Gst::ElementClass<MyAudioSink> *klass)
    {
        // Y
        klass->set_metadata("longname", "classification", "description", "author");

        klass->add_pad_template(Gst::PadTemplate::create("sink", Gst::PAD_SINK, Gst::PAD_ALWAYS, Gst::Caps::create_any()));
    }

    virtual int write_vfunc(gpointer data, guint length) override {}
    virtual void reset_vfunc() {}
};

Very recently we had a bug report when someone posted very nice, tiny example of audiofilter plugin, you can use it as an example for your project as well: https://bug794249.bugzilla-attachments.gnome.org/attachment.cgi?id=369564

If this doesn't work, feel free to file a bug here: https://bugzilla.gnome.org/enter_bug.cgi?product=gstreamermm

Todd

My code is as your example. The myaudiofilter you post has the expected class hierarchy but myaudiosink does not. It seems to inherit directly from GstElement. I think that my be the cause of my problem. I assumed it was a usage error on my part. Is it in fact a bug? – Ungotten

I'm not sure what do you mean by "expected class hierarchy" - your element inherits from Gst::AudioSink, which is correct. – Todd

In C++ yes but in Gobject it didn't because I copied and pasted a static get_base_type() method as per my answer below. – Ungotten