GStreamer 0.10 – What’s in it for the Users
Christian Schaller shows what the GStreamer team has been working on for the new 0.10 release. With new additions like an automatic plugin registry, support for the RTP protocol and greatly improved playback support, you’ll want to keep on reading!
The newest version of GStreamer, the Gnome multimedia framework, was released just before Christmas. Its release announcement described the new features available to developers but neglected to talk about its improved user experience. This article will introduce the improvements users will notice as they upgrade from 0.8 to 0.10 and offer some background into what makes them possible. Of course, because GStreamer is a library, many applications will need to be updated to benefit from these features.
It became clear to the GStreamer development community that, after two years of development, version 0.8 was suffering from a number of fundamental design flaws For instance, threading was added 0.8 almost as an afterthought so it was predictable that it would suffer from a number of threading issues. Stressing the framework would easily lead to crashes, especially on hyperthreaded or multi-CPU systems. Also, performance was bad when seeking or switching files, leading to a poor user experience. Fixing these flaws would require some rather large changes.
Now that hyperthreaded and multithreaded systems are becoming popular, it was clear that the project should create a strong threading model and then write GStreamer to fit that model. It was quite common for an old GStreamer application to become unresponsive. In fact, if you ever tried moving the seeker bar inTotem back and forth at rapid speed in GStreamer 0.8 you will probably see a segfault. The new GStreamer should not crash and will even show the images blurring by as you scan. Even though 0.10’s internals are very different from 0.8’s, care was taken to ensure that its API remains very compatible. Sound Juicer was ported in one day.
Most of the support requests in the #gstreamer IRC channel came from people whose GStreamer applications were refusing to use their installed plugins. This was usually because the registry of usable plugins, manually updated by the package installation system, was updated wrong. While things improved during the lifetime of 0.8 as distributions took more care to run gst-register, it still caused a lot of grief. GStreamer 0.10 registers plugins automatically so they automatically made available and gst-register no longer exists.
Most distributions, for legal reasons, only ship a small subset of GStreamer 0.8 plugins. Because GStreamer’s plugins are built from the same source module, each packager was forced to split it up to remove components that were illegal or unwise to use in their particular area of operation. The amount of custom code caused a number of problems for users. To solve this, 0.10 has five plugin modules called base, good, ugly, bad and ffmpeg. Base and good contain plugins that any distribution can ship without fear of potential legal issues. Ugly contains well-maintained plugins which may or may have legal issues of some form, generally patent or license issues. Bad is an incubation area where new plugins mature before moving to good or ugly. If a plugin never matures, it may remain in bad for the rest of its life. ffmpeg contains wrappers for all the codecs in the ffmpeg package. This new scheme will allow downstream packagers to have more consistent package naming and installation scripts, making it easier for users to discover and install the plugins that they need.
The base package is not intended to contain all the plugins required by a typical GStreamer setup. Instead, it contains one important example of each type of GStreamer plugin. The code and documentation for base plugins will remain current so developers will always be able to create new plugins from a known working code base.
Better Playback System
While playback in 0.8 did become quite good, it would never meet the high standards of the GStreamer team. 0.10 provides the infrastructure required for a much better playback experience. Switching tracks is very fast now, as close to instant as possible. Seeking should be much more responsive and the return to playback after seek is also very clean. A fun little feature of the new architecture is that if you seek in an audio file (in Totem for instance) and have a visualization active, you can watch the visualization change along with the seeking.
Audio and Video Syncronisation
GStreamer 0.10 has functions that should ensure 100% A/V syncronisation even for very long streams. For instance if you used Thoggen to RIP DVD’s with 0.8, you might have experienced that audio and video slowly drifted apart as the movie played. In 0.10, no matter how long the stream is or how often you seek around in the stream, the audio and video should stay locked together. GStreamer also features a system allowing synchronized recording from multiple sources, like a webcam and your soundcard microphone which will give a better result for applications like Flumotion and video conferencing systems like Farsight.
In 0.8, many plugins that should have worked together would somehow fail. This was especially true for less-used plugins that lacked the developer time required to shake out all the corner cases. For instance, sending audio to to alsa, oss, esound, and artsd should be a straightforward operation, yet each back-end had its own idiosyncrasies that needed to be worked around. An operation that would work perfectly for one person would fail horribly for another, and it would be entirely unclear just where the difference was. To solve this, 0.10 plugins now derive from a base class that handles the common operations. This allows all plugins to share a lot more code. It’s possible for work on the most important plugins to benefit those with a smaller audience too. Ultimately, this code sharing will ensure that plugins will now behave much more consistently.
GStreamer 0.10 also makes it much easier to integrate applications into the various desktop environments. Old applications would link against a tiny helper library to access the GStreamer gconf keys. In 0.10, GConf is supported by a set of plugins. Both a Gtk-only application like bmpx or a Qt/KDE application like Amarok can use the GConf plugins today. This allows Amarok to integrate more tightly with the Gnome desktop and, if the appropriate plugins are written, could allow bmpx and other Gnome applications to integrate more tightly with KDE.
Various plugins have also improved. GStreamer 0.10 comes with a fully functional Real Media demuxer which, when used in conjunction with ffmpeg or the Windows .dll loader plugin, can give support for Real Media formats. An MMS plugin adds support for the mmsh protocol, so Windows Media streaming audio (internet radio) should now work as well.
Support for RTP
A lot of work has been put into Real Time Protocol (RTP) support for GStreamer. This makes it a much more suitable foundation for Voice Over IP (VOIP) and videoconferencing applications. There is even an effort afoot to port Ekiga (formerly GNOME Meeting) to GStreamer this year. The Farsight project is also working in this area, aiming to support all instant messenger, VoIP and videoconferencing systems.
I hope this has been a useful introduction to the user experience improvements of GStreamer 0.10. There will of course be many more as application developer starts taking advantage of the possibilities the new framework. Anyway if you want to talk about GStreamer you can find me and the rest of the GStreamer community on #gstreamer on irc.freenode.com.