One of the things that was supposed to be discussed at aKademy was what we would be using as a multimedia framework for KDE 4.0
You can find a talk by Scott Wheeler (from kdemultimedia, notably JuK) and Christian Schaller (of gstreamer) on the KDE aKademy presentation archive, which is regarding gstreamer and the role it can play in KDE 4.0
The presentation is a good introduction, and showcases a lot of the current gstreamer integration into KDE. JuK was AFAIK the first KDE music player to output to gstreamer, using Tim Jansen’s nice KDE gstreamer bindings (in the kdenonbeta CVS module). Unfortunately, the bindings only support gstreamer 0.6, while gstreamer 0.8 is already out.
So, now amaroK outshines every other KDE music player out there when it comes to gstreamer support. Not only do they support gstreamer 0.8, but you can even use KIO with amaroK while playing to a gstreamer backend. In fact, amaroK 1.1 Beta 1 doesn’t even support aRts, pending the update of their aRts engine.
The hard work of the amaroK devs has proven that it’s possible to integrate gstreamer output with KDE, which is especially nice since from what I understand, gstreamer is looking to be the front runner to be KDE’s multimedia framework for 4.0.
Everytime the subject of gstreamer and KDE 4.0 comes up, I always hear objections that are IMO unfounded. Let me try to dispel some of those:
-
gstreamer can’t maintain binary compatibility!
This is simply not true. gstreamer could IMO easily maintain binary compatibility. First of all, it is a C library, which means that they don’t have to worry about the ABI changing every other gcc revision. I’ll admit that it makes it very annoying to code gstreamer software at this point, which is why I’m hoping the KDE bindings get updated soon. ;-). Other C-based platforms have maintained binary compatibility for years, most notably the various UNIX-like kernels out there, including Linux. There’s no technical reason why gstreamer wouldn’t be able to, and the developers themselves seem intent on meeting that requirement.
-
gstreamer can’t play over a network so it’s useless!
Well there’s nothing stopping gstreamer from being able to do so. It is, after all, simply another gstreamer plugin. I wasn’t even aware that aRts could do this until I saw this point become mentioned, so it doesn’t strike me as the most famous sound server feature.
-
gstreamer is a part of GNOME, we don’t need GNOME taking over KDE!
Actually, gstreamer only requires glib and libxml. And KDE has used glib for awhile now through, ironically enough, aRts. So that boat’s already left the station. Mind you, using the native gstreamer API IMO is like using shards of glass to wash your face, what with all the macros and underscores and all. But that’s why KDE applications will have a nice wrapper.
I hope that’s a decent overview of the possibilities with KDE + gstreamer, even though it only covers music playing, even though gstreamer is capable of so much more.