posted by Christian F.K. Schaller on Tue 13th Jan 2004 19:28 UTC

"GStreamer Intro, Page 3"
Plans for the future

We are pretty happy with the current feature set of the core of GStreamer. So our focus for the next half year will probably be on polishing what is there and updating old elements and creating new ones.

The only major missing component is a subsystem for doing MIDI with GStreamer. Actually it is probably just a set of elements, but until it is actually implemented we can't be 100% sure that the core doesn't need some changes to accommodate it. We have had several people expressing interest in taking it on, but no one has actually committed some code for it so far, but hopefully someone will get a start on it soon, as it is really something we need in before starting to aim for GStreamer 1.0.

The new development series also includes support for interactivity which is needed for enabling such stuff as DVD menu's and Flash animations to work through GStreamer. The interactivity support was created by David Schleef and is currently being completed and extended by Jan Schmidt. I am not sure we will have a finished DVD playback application or complete Flash support ready for 0.8.0, but the basics are there so we should be able to offer those during the 0.8.x series lifetime. Of course the flash support depends on interactivity being integrated into the flash decoding library Swfdec that David Schleef are developing in parallel with GStreamer. Developers interested in flash should really take a look at swfdec as it is the only flash implementation available out there available under a license as liberal as the LGPL, and it can be used outside of GStreamer.

Another fun new feature is our advanced new support for metadata/tagging designed and implemented by Benjamin Otte. We have devised a system which should be able to preserve your metadata when you use a GStreamer based application to transcode your files. So for instance if you convert some of your FLAC files to Ogg Vorbis with GStreamer, the metadata tags should be converted along with the music. Making an easy to use application with GStreamer for doing media conversions might be an idea for someone who want to learn how to program with GStreamer.

Another interesting development is that we currently got a team of about 7 french students who are going to make a GStreamer-based non-linear video editor as the final year project. This effort will probably improve the framework in certain areas like adding new advanced clocking elements for doing things like double speed playback. In relation to this we just completed a major change in our system which enables, among other things, splitting a video signal into two parallel windows. This means that in the case of a video editor you can view the same video signal in two different windows; the first could be the original video for instance while the second contained your transformations. A great way to experiment with different transformations in real time.

We also hope to integrate a SMIL implementation done by Malcolm Tredinnick in the coming months. This will actually not be part of GStreamer as such, but it is designed to integrate easily with GStreamer. SMIL is a W3C standard using XML that is meant for doing interactive audiovisual presentations. This is very useful for accessibility for instance, where we hope to see GStreamer tools written that will help popularize the addition of accessibility information using SMIL to formats such as Ogg and Matroska. We are especially excited about this as this will be the first implementation of SMIL available under the LGPL.

Other interesting improvements are the work on Quicktime and ASF done by Jeremy Simon, our improved AVI and Matroska encoding by Ronald Bultje, the color ascii art plug-in based on libcaca by Zeeshan Ali, our improved error handling by Thomas Vander Stichele and the software video scaling and gst-player and Totem development done by Julien Moutte. A more long term project that has been discussed (long term unless someone outside the current group of hackers steps up to the plate) is writing a new sound server using GStreamer.

On the competition

Don't want to start a huge flamefest so I keep this one brief in the hope that the level of toe stepping will be acceptable :). We really feel that GStreamer is at a sweet spot at the moment with little real competition. Other projects within our sphere of application are either much more narrowly targeted (like Xine or MPlayer, which are great backends for creating basic playback applications, but in our opinion not well suited as backends for a wider more complex range of applications), or they are much more immature (like MAS and NMM), or licensed in a way that makes them uninteresting to most free software developers (like Helix). Or, even, a combination of all of the above issues.

Another major advantage of GStreamer in addition to our relative maturity is our licensing. GStreamer uses the LGPL license which we feel is the perfect license for a library. It allows plug-in and application developers the freedom to use the license of their choice (our choice for the applications we make ourselves is the GPL), yet reducing the chance of major forking or fixes being withheld, which is what a more liberal license could lead to.

GStreamer is also highly portable; we had reports of people running it on Linux, FreeBSD, Solaris, AIX and Irix. Recently I also got a mail about the core compiling on OSX with some soon to be merged patches attached. The code also compiles with other compilers than GCC, for instance Sun's Forte. Porting to Windows shouldn't be overly difficult if GLib works well. Possibly the only thing that would need coding is a custom scheduler.


Anyway, back to what got me started with GStreamer. As said it has been a long and at times though journey, but I feel that we have now finally gotten to the point both with the library and with available applications using it, that I feel that we are able to deliver what I originally wanted. Just the continuation of the projects and efforts that are already underway is proof enough that we have succeeded in delivering what I was looking for those years ago. That said we are still not done and there are of course still areas needing work, but that is just the way of software; it is not something static but a continuesly evolving entity.

I hope I managed to get you interested in GStreamer and what it can offer developers and through them what it can offer users. If you want to talk you can find us at #gstreamer on or you can get in touch through the mailing list.

Table of contents
  1. "GStreamer Intro, Page 1"
  2. "GStreamer Intro, Page 2"
  3. "GStreamer Intro, Page 3"
e p (0)    53 Comment(s)

Technology White Papers

See More