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(KantarAudioSink *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

Answer 1

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

Answer 2

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