GStreamer C# Binding Update

As many may know, there was once a valiant attempt to bind GStreamer in C# a couple of years ago against 0.8. However, this binding was never complete and had a number of problems, but it was nonetheless promising. That is until it eventually found itself without a maintainer.

For over a year it sat in Mono subversion, and during that time, a number of third-party developers assumed it was a working GStreamer binding for their beloved development platform. Unfortunately this was not the case, and a number of times myself and others had to explain that the binding was not complete and that the best thing to do was to develop the required GStreamer functionality in C, expose it in a simple P/Invokable API, and privately bind that. That’s what I do in Banshee, and it works very, very well.

I eventually moved the gst-sharp module out of the main source trunk to keep it from being “discovered” by new developers to save them the pain and excitement of seeing the apparent binding, and that worked well. After doing that, I found myself no longer having to explain the situation. But still, this was sub-optimal.

Now fast forward to just a couple of months ago. After Peter Johanson and I started talking about it, he managed to find a few hours spread over a few weeks to resurrect the old gst-sharp binding, and began fixing up its GAPI component. We then agreed that it might be a good idea to make it a Google Summer of Code project.

Now enter Khaled Abdul Karim Mohammed (who needs a blog): enthusiastic SoC student destined to deliver working GStreamer CLR bindings. We laid out a few goals for the summer project including extensive unit tests, runtime-bound GObject signal support, GAPI cleanup, sample porting, and some other minor tasks.

#region technical mumbo-jumbo

So now the personally most exciting and compelling reason for writing today: after a few weeks of hard work by Khaled, we now have one of the biggest goals for the binding essentially complete. Khaled took two ideas of mine that I had been toying with a few months ago and turned the best one into a working solution for supporting GObject signal binding at runtime.

This may sound a little weird, but it’s the best phrase I can come up with to describe it. In C, to connect to a signal you do something like g_signal_connect(object, "signal", callback). This isn’t so possible in the CLR without a decent amount of work, and it’s a major requirement for a GStreamer binding because elements aren’t targeted for binding, and thus GAPI doesn’t touch them, and can’t know what signals to bind.

GAPI-bound signals introduce an insane (but necessary) amount of code overhead to transform CLR events into a GObject signal binding. It’s not the kind of overhead you want to pass on to consumers of your binding :-).

Now what I mean by “GObject signal binding at runtime” is this:

Element typefind = ElementFactory.Make("typefind", "typefind");
typefind.Connect("have-type", delegate(object o, DynamicSignalArgs args) {
 Console.WriteLine("MimeType: {0}", args[1] as Gst.Caps);            

In C#, connecting to a signal is very much like how you would do it in C. A number of things had to happen under the hood to make this possible, but it’s much like it’s done in Python (or so Edward says). There’s a default C handler that is connected with G_CONNECT_SWAPPED, and the argument stack is walked to collect the arguments as GValues. There’s one caveat with GstMiniObject however, but we handle this with minimal overhead because GstMiniObject-derived types in the CLR binding are GLib.Opaque-derived. Subsequent Connect/Disconnect calls on the same signal and object then take advantage of multicast-delegate support in the CLR instead of having to manage multiple callbacks for a object-signal in GObject land.

This also means that adding by-hand bindings of common/base elements like decodebin or typefind to get C# event syntax is much easier.

All of this “dynamic signal” stuff is fully generic to glib-sharp, so it is my hope that after we fine-tune it and test drive it in gstreamer-sharp that it will end up in glib-sharp itself. It is an immensely useful feature to have if you need quick signal support on a GObject-based binding and can’t bring GAPI into the equation.


That all being said, and technical jargon aside, we are hard at work (Khaled for the most part right now) on a working, usable, sexy, GStreamer 0.10 binding for Mono/.NET/C#/Boo/VB.NET/IronPython/WhateverLanguageThatTargetsTheCLR. Much of it is already working now, but there is still much to do. Eventually I will port all of the Banshee backends to this lovely new binding.

To avoid the messy situation we lived with for almost a year with the first iteration of the GStreamer CLR binding for 0.8, I am currently not going to directly disclose where the new bindings are located, but for the adventurous at heart, I’m sure they can be found :-). Expect a first release in the coming months.

And, oh boy… I just can’t *wait* to see GStreamer apps written in VB.NET! (ahhh!!!H!!OMG!)

8 Replies to “GStreamer C# Binding Update”

  1. This is great news. I had no idea that you guys weren’t using a gstreamer binding already… (Banshee, Diva Project, etc…)

    Will Diva switch to this binding as well?

  2. Very awesome to see this one taking shape. I didn’t know this was put up as a SoC project – glad to see someone took off with it!

    Yes, Khaled must get a blog, he needs a good pat on the back for a job well done!

  3. For those interested (in comparing how it works in C# vs Python), the signal handling is in fact done in pygobject. Since Python is dynamic, we always attach the same callback handler with some information about what python callback has to be called, and with which python extra data.

    Nice to see the C# bindings coming on ! Keep up the good work.

  4. Will this binding have ports for other platforms such as windows / osx? It would be nice to see more apps targeting mono (Banshee / Diva, etc) that run easily on multiple platforms.

  5. yeah, about 18 months ago peter was trying to get me to be de facto maintainer of gst-sharp but i’m always so busy. i’m glad someone picked it up, we could really use it in muine.

Comments are closed.