[gst-devel] Re: Comparison: MAS, GStreamer, NMM

[Matthias Welwarsky]

Hi,

actually, I'd like to focus on a different view than just ease of use of an 
API. I don't really want to see KDE exchanging Arts Hell with MAS, NMM or 
GStreamer Tartaros. Thus, other points like stability of the ABI, size of the 
development community, focus of development are more important anyway.

Actually, KDE as a Desktop Environment has very little requirements regarding 
its multimedia framework. I'd like to explicitely exclude multimedia 
applications for now, those should be able to use any framework their 
developers think would fit. KDE should stop imposing its own framework on 
them, this will only cause bloat.

KDE currently has some really nice features apart from its multimedia 
applications which need to be kept:

- audible notifications (KNotify)
- pre-listening of audio files, this must work across network through 
kioslaves, too, without having to download the file first.
- static or even animated preview of video files, possibly across a network, 
too.
- you get the tune.

This is sort of a minimum requirement. We should seek to make this possible 
with whatever framework is available. Meaning: In KDE, we need an adaptor 
that implements those few, generic use cases, using either MAS, NMM or 
GStreamer, or <plug you favorite candidate here>. This shouldn't be too 
difficult. I volunteer to work on the KDE::PlayObject stuff to make it more 
generic and not expose details about the underlying framework any more, if 
someone else steps up to write drivers for MAS, NMM and GStreamer.

That way, we'd loosen KDE's dependency on a particular multimedia backend and 
circumvent the need to do one ourselves (like we tried with arts).