XMMS2 vs GStreamer

Tobias email to the xmms2-devel list

Hello,

I guess it's time to write a longer response to this.

XMMS2 might be new, but it's also old. It started three years ago as a personal project for me and Peter (original XMMS author). By that time gstreamer was *very* immature and not a viable option. This might have changed the last three years, I can't say I am that updated on the progress of gstreamer.

But from what I know about gstreamer and the philosophy of XMMS2 there are some incompatibilities.

First of all: GStreamer is built for audio AND VIDEO support. This of course make an impact of the complexity of the code and size for it. XMMS2 will never implement video support and will make decisions based on that assumption. This makes GST and XMMS2 incompatible in the core.

Secondly: Portability and "bloat". The core of XMMS2 is designed to work on "everything". The clientlib has no dependences and the core / plugin only depend on glib / sqlite3. To get a bigger beast like GST to work on small portable platforms probably will be a lot harder for us. GST still doesn't run on windows either.

Thirdly: The things I have heard from other people about GST like the lack of gapless playback and the slow imports of metadata makes me a bit reluctant to embrace this fully. This is probably a effect of the first statement.

The bottom line is: With transformations in XMMS2, GST and XMMS2 will overlap on several places, people may even say that they are redundant. I can agree on that, but you have to keep in mind that XMMS2 and GST are developed with totally different goals.

XMMS2 will exist as a alternative to GST based players and I don't see the real benefit for us to to switch to GST when we have a pretty good ground right now. Had XMMS2 been redesigned from the ground and up today maybe we should have chosen GST as our decoder framework, but scrapping our code now, switching to GST and fiddle with their code instead of our own seems a bit far fetched.

A GST based transform for XMMS2 would on the other hand be something that I would like to have in our standard distribution.

Some irc discussions

Aug 09 14:38:12 WST

   anyway, I don't like the gstreamer approach   juhovh: why not?22   it looks like an economically good concept    eleusis: the same reason I like the idea of        XMMS2 that music player is not a video player        and it shouldn't be    eleusis: of course gstreamer has its advantages        but maybe I'm old fashioned   juhovh: explain? :D    it's too big to fit in my brain!   you want an audio-only framework?    phew, there *  eleusis looks @ tru   tru: gstreamer vs xmms2 :P    eleusis: I don't want frameworks, I want one        good application that plays music   juhovh: ok, but in that case, why does it matter        to you that gstreamer also supports video?   if the app you're using only allows for audio,        why would it matter whether the backend supports        video as well?    hmm    why would it need to?    I think xinelib is quite good solution for        video+audio playing   juhovh: it doesn't *need* to.. the question        is, why would *you* care? :P   eleusis: the definition of bloat is "supports things that is not being used"   heh   bloat leads to complicated code   which leads to bugs.   instead we can support *exactly* the things we need.   and have no problem with bugs related to huge frameworks.   imho.   so the gist of the 'xmms2 vs gstreamer' argument        is that xmms2 wants to avoid complex frameworks        due to debugging complexity?    that's probably the main reason, I don't want        stuff I will never use    or maybe complexity in general?   eleusis: and of course maintain portablilty, keep depends low   what about the economic argument.. that once a        particular gstreamer plugin is available, all        gstreamer-using apps get to use that plugin without        further modification?    it should also be about maintainability   and overhead.    yeah    but as I said I just need two applications, one        for audio and one for video :P   eleusis: of course. it's the "do not invent the wheel"    reinvent    someone has to do the invention   eleusis: but otoh I don't work on xmms2 to take over the world.   so we invent a smaller wheel to avoid the        bloated gstreamer wheel? :D   I do it because it's fun.   i know    gst-editor-ambisonics.png    I mean, just look at it    maybe we should get some editor like this   tbh, i haven't looked at gstreamer's internals,        so i don't know how bloated it really is, if you        want to use it for audio only.. but my impression        was that it's a very general framework that's        designed to just move data between different plugins..    my impression is that it does everything related        to any audio or video   i.e. my impression is that it's not particularly        optimised, or has specific code to make it suitable        for audio and video only    which would mean all editing, filtering, decoding, encoding     their feature list is saying: "Extremely lightweight        data passing means very high performance/low latency" ;)   ja   so the impression is that it just moves data        around, it doesn't do anything fancy to the data        itself - it lets the plugins do that    their core library should do about that   do what?    move data around   yeah..