Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
XMMS2 vs GStreamer
Tobias email to the xmms2-devel list
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?
* 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?
why would it need to?
I think xinelib is quite good solution for
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"
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.
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
it should also be about maintainability
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"
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 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" ;)
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
move data around