For the past couple of weeks I have been working on a very cool project, one started and lead by one of our brilliant KDE hackers-that-came-from-GSoC, George Kiagiadakis (gkiagia). I remember that the project got my attention when it was first announced. But I was very busy at that time, and could only follow it from a distance, until now.
As the title of this post reveals, I am talking about QtGStreamer, the Qt-style bindings for the GStreamer multimedia framework.
The project has been progressing during the past year, mostly because it is used in George’s kcall. The structure of the bindings is very flexible, as it follows the powerful pipeline model that is the strength of GStreamer’s design without falling into the trap of trying to map the GStreamer API 1:1. This gives us something that is friendly to the Qt/KDE developer, but at the same time allows things that are very difficult (or impossible) to do with the multimedia APIs we have currently, like displaying a webcam and transcoding the video at the same time with a few lines of code, or streaming audio/video from a remote location transparently.
Even if QtGStreamer is already functional for simple applications it is of course not complete. There is still a lot of work to be done. So as part of my job with Collabora Multimedia I have been assigned to help it reach a feature-complete status. This does not mean the whole GStreamer API will be wrapped: we are aiming for something that is directed specifically to application developers, and I hope it will allow us to help developers code better multimedia experiences for both Qt, MeeGo and KDE users.
My work on the project started recently, and there is still much I have to learn. Luckily George has been around to mentor me, and Collabora Multimedia has a LOT of expertise in GStreamer, of course. I spent the first few weeks doing a full review of the existing GStreamer bindings for all languages, and identifying the missing pieces that we needed to provide. Oh, and making stupid mistakes as well 🙂 You can follow the development of course at the current QGStreamer repository, and don’t be shy if you think you can help, or have a specific request. At this time it is important for us to identify the use cases we have not envisioned for QtGStreamer and do our best to provide an easy API to make them possible, so your input is much appreciated.
I plan to blog regularly about the status of this project. For now, I will already answer the inevitable initial questions:
a) No, it is not meant to replace Phonon. Different use cases, different priorities.
b) No, we could not make this work as part of the Phonon-gstreamer backend. Although the Phonon-gstreamer backend could possibly be ported to QtGStreamer in the future, if there is interest in doing it.
c) No, this does not conflict with the QtMobility/MultimediaKit API. Again, the use case is different, and they might interoperate in the future.
My work on this project is being sponsored by Nokia/MeeGo. As you might know, GStreamer is the official media framework for the MeeGo project, much like Qt is the official developer API. So this project aims to provide the link between those two powerful elements in the MeeGo ecosystem. I will keep you posted about our development, and thanks for reading so far!