[uraeus gnome org: GStreamer article for GNOME Journal]



Can someone edit? :-)  

sri

----- Forwarded message from Christian Fredrik Kalager Schaller <uraeus gnome org> -----

Subject: GStreamer article for GNOME Journal
From: Christian Fredrik Kalager Schaller <uraeus gnome org>
To: Sriram Ramkrishna <sri aracnet com>
Content-Type: multipart/mixed; boundary="=-AWTRjiMWLwYxpTldydXV"
Date: Tue, 17 Jan 2006 17:33:20 +0100
Message-Id: <1137515601 31420 11 camel fakesink fluendo lan>
Mime-Version: 1.0
X-Mailer: Evolution 2.5.4 (2.5.4-6) 
X-Scanned: By amavis at egwn.net
X-spasm-sender-IP: 195.10.6.12
X-spasm-sender-host: server02.es6.egwn.net
Content-Length: 10858
Lines: 112

Hi Sri,
After many promises I finally managed to sit down and write something. I
am sending you a draft for review. The article probably needs another
read through and maybe some screenshots to spruce it up a bit, I will
try to do so tomorrow and get back to you with an update.

Christian


----- End forwarded message -----

-- 
Title: GStreamer 0.10 - What's in it for the users

GStreamer 0.10 - What's in it for the users

By Christian Schaller

Just before Christmas the 0.10.0 version of GStreamer was released. The announcement talked a lot about the advantages of this new generation GStreamer for developers, but little about the advantages for end users. This article will attempt to highlight some of the things users will notice have changed in GStreamer applications using 0.10.x instead of 0.8.x. Of course GStreamer being a library wether many of the improvements mentioned here actually makes it accross to the end user is up to all the application developers out there, some improvements comes automatically with a port, while others need specific changes to the applications.

Background

After having worked on 0.8 for over 2 years it was clear to the GStreamer development community that the 0.8 branch had reached the top of its potential and that there where some serious flaws in GStreamer 0.8. The biggest issue was that the whole threading model used in 0.8 was added to the framework as an afterthought and due to that GStreamer 0.8 suffered from a lot of serious threading issues. Stressing the framework could easily lead to crashes, especially on hyperthreaded or multicpu systems. Also performance for some common tasks like seeking and media file switching wasn't very good giving users a bad experience.

As threading just becomes more and more important, with hyperthreaded and multithreaded systems becoming the norm it was decided that we should design a threading model first and then adjust GStreamer around that model. This has lead to GStreamer applications being rock steady on multi-cpu and hyperthreaded systems using the 0.10 backend. The threading changes mean that GStreamer 0.10 is internally quite different from 0.8, yet the API's provided are mostly the same. Sound Juicer for instance was mostly ported in a day. The new threading model also benefits application developers a lot, e.g. in 0.8 it was easy to lock the gtk-gui, in 0.10 that is not an issue anymore. If you ever tried moving the seeker bar in Totem back and forth at rapid speed with GStreamer 0.8 you probably saw Totem segfault. With 0.10 it should be rock stable and you even will see the images blurring by as you do so. There might of course be format specific bugs, but the generic issue is gone.

Registry pains

The most common cause of support requests in the #gstreamer IRC channel was from people who had installed GStreamer and the needed plugins, yet their playback applications did still not work properly. In 95% of the cases this was caused by problems with the GStreamer registry, which had to be manually updated by the package installation system in order to have the new plugin registered. While things got better during the lifetime of 0.8 as distributions took more care to run gst-register it still caused a lot of users grief. So in 0.10 we switch to a automatic registery instead. This makes the registry invisible for the user and also the distribution packager. There is no gst-register command to call anymore.

Improve packaging

Of course part of the reason people where suffering so much grief with the register was because most distributions for legal reasons only shipped a small subset of commonly used GStreamer plugins. GStreamer also used to have all its plugin hosted in the same source module, causing distributions and packagers to package it in many different ways in order to split it up into smaller components and solve the legal issues of their area of operation. In 0.10 we have split the plugins module up into 5 packages called base, good, ugly, bad and ffmpeg. Base and good are meant to only contain plugins which any distribution can ship without having to worry about potential legal issues. Ugly contains well maintained plugins which might have legal issues in some form, be they patent issues or license issues. Bad has two purposes, the first being a incubation area for new plugins, meaning that all new plugins should spend some time in this module before moving on to ugly or good. The second purpose for it is being a storage place for plugins which builds, but for various reasons, including developer interest doesn't meet the quality standards for going into good or ugly. The ffmpeg package is the same as in 0.8, a wrapper plugin containing all the codecs from the ffmpeg package.

Users should be aware that the package base is not meant to include everything they need ie. its not the 'base' in that sense. Instead base was created as a module which contains one important example of each GStreamer plugin type. Making the code and documentation for this module top quality is a high priority goal for the community. Developers writing their own GStreamer plugins thus can safely assume that there is a plugin of the type they are writing in base, and that can be used as documentation for how to do such a plugin.

Besides the result of this new setup is that upstream packages are packaged much more uniformly accross both distributions but also between different package repositories and thus making it easier for users to both get and understand what they need.

Improved playback system

While the playback experience in 0.8 became quite good with later releases, there where a couple of issues left to be addresed with a redesign. The general user experience when playing back files is quite improved with GStreamer 0.10. Switching songs or videoclips should happen much faster now, as close to instant as possible. Seeking should be much more responsive and the return to playback after seek is also much faster then in old GStreamer. A fun little feature here is that if you seek in an audio file, in Totem for instance, and have a visualisation active you will be able to see the visualisation change along with the seeking.

Audio and Video syncronisation

Audio and Video syncronisation is also much better with this version of GStreamer. We now have functions that should ensure 100% syncronisation even for very long streams. So for instance if you used Thoggen to RIP DVD's with 0.8 you might have experienced that audio and video sslowly drifted apart. This could be quite noticeable at the end of long movies. In 0.10, no matter how long the stream is or how often you jump back in forth in the stream through seeking, the audio and video should stay in sync. GStreamer also features a system allowing syncronized 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

One problem in 0.8 was that many plugins which where supposed to be inter-changeable in theory could have problems in practice. This was especially true for plugins which saw little use and due to this little development effort had been invested into making sure they worked 100% like the other plugins of their category. For instance while outputing to alsa, oss, esound, artsd and so on was possible you would come accross different problems with each backend. This of course lead to many cases of something working perfectly for one person not working at all or badly for the next, without it being obvious for the user what the difference was. In 0.10 this problem should be much smaller as we now have baseclasses for each major type of plugins. This means all plugins of the same type share a lot more code and that the work that goes into fixing and maintaining the most important plugins also benefits those with a smaller audience. Also sharing more code also means more coherent behaviour across plugins of course.

One interesting change is that GNOME applications no longer use a little helper library to access the GStreamer gconf keys. Instead the GConf support is now done through a set of plugins. The big advantage of this is that even applications not made to integrate with GNOME will get improved 'GNOME Integration' through these plugins. For instance a GTK+ only application like bmpx or a Qt/KDE application like Amarok can be easily configured to use the GStreamer GConf plugins and through that ensure the same behaviour as the rest of your GNOME desktop in regards to GStreamer usage.

There are also some new and updated plugins. Among other additions 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 the Real Media formats. Another updated plugin is the MMS protocol plugin adding support for mmsh, meaning most Windows Media webradio's should now work through the combination of this plugin with ffmpeg and the asfdemuxer.

Support for the RTP protocol

A lot of work is also being put into GStreamer RTP support, meaning that you can expect to see a lot of GStreamer based applications for Voice of IP and videoconferencing popping up, maybe we even get far enough to get Ekiga (former GNOME Meeting) ported to GStreamer this year. The Farsight project is working in this area and aiming to support all instant messenger, VoIP and videoconferencing systems.

I hope this has been a usefull introduction to the user experience improvements of GStreamer 0.10. Application developers using GStreamer will of course provide additional improvements and changes on top of what I am listing here, but I hope its enough to give you an idea of what GStreamer 0.10 means for you.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]