New job (and company)

I have a new job! After working for 5+ years for Collabora, I decided that it’s time for a change and have quit my contract there early September. These have been great years, working with so many brilliant people on Free Software, but time to move on!

So for the future, it’s actually more than just a new job. Together with fellow GStreamer hackers Tim-Philipp Müller and Jan Schmidt we founded a new company: Centricular Ltd.. We are going to provide consultancy services around Free Software with a focus on GStreamer, Multimedia and Graphics initially (but not exclusively). Technically, not much will change in the kind of work I’m doing compared to the past, but this time we will handle everything ourselves so we can better serve the needs of our customers and are more flexible. Hopefully this also provides an even better work environment within a group of equals and gives us more time to contribute to GStreamer and other Free Software projects.

Check our website for a list of Open Source technologies we cover and services we will offer. Obviously this list is not complete and we will try to broaden it over time, so if you have anything interesting that is not listed there but you would need someone for, just ask.

We will also be at the GStreamer Conference in Edinburgh next week.

Great times ahead! 🙂

Streaming GStreamer pipelines via HTTP

In the past many people joined the GStreamer IRC channel on FreeNode and were asking how to stream a GStreamer pipeline to multiple clients via HTTP. Just explaining how to do it and that it’s actually quite easy might not be that convincing, so here’s a small tool that does exactly that. I called it http-launch and you can get it from GitHub here.

Given a GStreamer pipeline in GstParse syntax (same as e.g. gst-launch), it will start an HTTP server on port 8080, will start the pipeline once the first client connects and then serves from a single pipeline all following clients with the data that it produces.

For example you could call it like this to stream a WebM stream:

Note that this is just a simple example of what you can do with GStreamer and not meant for production use. Something like gst-streaming-server would be better suited for that, especially once it gets support for HLS/DASH or similar protocols.

Now let’s walk through the most important parts of the code.

The HTTP server

First some short words about the HTTP server part. Instead of just using libsoup, I implemented a trivial HTTP server with GIO. Probably not 100% standards compliant or bug-free, but good enough for demonstration purposes :). Also this should be a good example of how the different network classes of GIO go together.

The HTTP server is based on a GSocketService, which listens on a specific port for new connections via a GLib main context, and notifies via a signal whenever there is a new connection. These new connections are provided as a GSocketConnection. These are line 424 and following, and line 240 and following.

In lines 240 and following we start polling the GIOStream of the connection, to be notified whenever new data can be read from the stream. Based on this non-blocking reading from the connection is implemented in line 188 and following. Something like this pattern for non-blocking reading/writing to a socket is also implemented in GStreamer’s GstRTSPConnection.

Here we trivially read data until a complete HTTP message is received (i.e. “\r\n\r\n” is detected in what we read), which is then parsed with the GLib string functions. Only GET and HEAD requests are handled in very simple ways. The GET request will then lead us to the code that connects this HTTP server with GStreamer.

Really, consider using libsoup if you want to implement an HTTP server or client!

The GStreamer pipeline

Now to the GStreamer part of this small application. The actual pipeline is, as explained above, passed via the commandline. This is then parsed and properly set up in line 362 and following. For this GstParse is used, which parses a pipeline string into a real GstBin.

As the pipeline string passed to http-launch must not contain a sink element but end in an element with the name “stream”, we’ll have to get this element now and add our own sink to the bin. We do this by getting the “stream” element via gst_bin_get_by_name(), setting up a GstGhostPad that proxies the source pad of it as a source pad of the bin, and then putting the bin created from the pipeline string and a sink element into a GstPipeline, where both (the bin and the sink) are then connected.

The sink we are using here is multisocketsink, which sends all data received to a set of aplication-provided GSockets. In line 390 and following we set up some properties on the sink that makes sure that newly connected clients start from a keyframe and that the buffering for all clients inside multisocketsink is handled in a sensible way. Instead of letting new clients wait for the next keyframe we could also explicitly request the pipeline to generate a new keyframe each time a client connects.

Now the last part missing is that whenever we successfully received a GET request from a client, we will stop handling any reads/writes from the socket ourselves and pass it to multisocketsink. This is done in line 146. From this point onwards the socket for this client is only handled by multisocketsink. Additionally we start the pipeline here for the first client that has successfully connected.

I hope this showed a bit how one of the lesser known GStreamer elements can be used to stream media to multiple clients, and that GStreamer provides building blocks for almost everything already 😉

GStreamer 1.2.0 released and other updates

This blog post might be a bit late but nonetheless, here are some updates that happened in GStreamer in the last week 🙂

GStreamer 1.2.0 released

On Tuesday we released GStreamer 1.2.0. This was just in time for GNOME 3.10, which depends on it and was released on Wednesday (Congrats btw! Many great improvements).

The changes between GStreamer 1.0 and 1.2 can be seen from the release announcement mail. In summary there are many, many nice new features, API improvements and even more bugfixes that we did not include in the 1.0.x bugfix releases because they required larger changes.

Following the 1.2.0 release we plan to do regular 1.2.x bugfix releases with important bugfixes, while at the same time develop new features and in general more complicated changes in the already opened 1.3 development release series (which is the GIT master branch now). The 1.3 release series will later lead to the next stable 1.4 release series. Needless to say that 1.4 will be completely backwards-compatible with 1.2 and 1.0.

GStreamer 1.2.0 binaries

Two days later on Thursday we then released the binaries for GStreamer 1.2.0 for Android (ARM), Mac OS X and Windows. This will allow to take advantage of all the new changes on these platforms too and provide a better cross-platform multimedia experience.

We also finally moved cerbero, the build system used to generate the binaries for all these platforms, to GStreamer’s freedesktop.org GIT and got rid of all the ancient 0.10 cruft that was still in there. This GIT repository is now the official place from where you can get the latest version of cerbero for building GStreamer, and will also be updated for all future 1.2.x bugfix releases. Hopefully it will also be kept up-to-date for GIT master, i.e. the 1.3 development release series.

iOS binaries and build support

Over the last days I also worked on porting the remaining parts of GStreamer 1.0 to iOS (5.1 and newer versions), and also adapted the cerbero build system to automatically build GStreamer 1.0 for iOS and create an installer package from it. iOS binaries were already available in the past from a third-party website (gstreamer.com) but only for the old and deprecated 0.10 version. My changes are based on this.

It’s now also possible to build GStreamer and all its dependencies via cerbero with the Xcode 5.0 toolchain for OS X and iOS. Thanks to more strict compiler checks and behaviour changes, some changes in the build systems and the code were necessary.

Official binaries for iOS will be provided by the GStreamer project in the next days.

Others

gstreamer-vaapi was already ported to the new 1.2 API for better hardware integration and the next release should contain it. Finally it can do all that without using unstable GStreamer API.

Also gnonlin, gst-editing-services and gst-python finally saw a 1.x based (pre-) release. The final 1.2.0 releases should be there in the next days, and hopefully a new PiTiVi release will follow soonish.

GStreamer conference 2013

In October the GStreamer Conference 2013 will happen in Edinburgh. There will be many interesting talks by the GStreamer developers but also other people and companies, who will give talks about what they achieved with GStreamer.

I’ll give a talk about how to integrate hardware capabilities into GStreamer, and which new APIs were added to make this much easier or possible at all (depending on what kind of integration is needed).

New Blog

Soo… after about 10 years I’m having a blog again. I hope I can keep it updated a bit more often than in the past 🙂

Here I’m planning to write about various topics that seem worthwhile to write about, including Free Software, coding, work related things, food, life in general or whatever else comes to my mind.