Re: The GNOME Journal, February Edition

[Scott Bronson <bronson rinspin com>]

I notice that the article that I edited didn't make the cut...  That's OK, except that the one currently on the site has a number of grammar and style issues...  It uses "0.8" five times in two sentences, bad pluralization ("GStreamer being a library wether [sic.] many of the improvements actually makes"), ...

In case it was lost, here's what I sent Sriram on the Jan 21st (with a few minor fixups that I noticed just now).  NOTE: this doesn't have the much better parting statement that Christian Schaller came up with.  Sriram, do you still have that?


GStreamer 0.10 - What's in it for the users

By Christian Schaller

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.

Background

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 in Totem 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.

Fixed Registry

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 (when? at app launch?  continually while the app is running?) so they automatically made available and gst-register no longer exists.

Improved Packaging

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.

Improved Plugins

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 much improved user experience of GStreamer 0.10.  And, of course, application developers will continue to provide additional improvements and changes beyond what exists in the GStreamer core.