[Matroska-devel] Xine 2.0 going Gstreamer ??? was : [Fwd: xine 2.0 and gstreamer]
christian at matroska.org
Tue Nov 8 23:02:32 CET 2005
Interesting approach from one of the lead developers of the Xine
project, Michael Roitsch. amaroK, the Linux audio player, was taking
this out front in some way, as they can use Xine or Gstreamer as their
engines. If both projects merge, they had only one, but maybe more
powerful :) ....
For the matroska project such a decision from the Xine devs could have
some undeniable potential impact, as it could be expected that Gstreamer
would progress severly from where it is right now. In this case i guess
it would be high time again to consider gstreamer as the main future
development basis for our container, instead of VLC ? Opinions ?
matroska project admin
-------- Original-Nachricht --------
Betreff: xine 2.0 and gstreamer
Datum: Fri, 4 Nov 2005 13:52:53 +0100
Von: Michael Roitzsch <mroi at users.sourceforge.net>
with the major share of the blame going to myself for too little
contribution, I noticed that xine development is slowing down
compared to maybe a year ago when we still had the 1.0-enthusiasm.
This is why I started thinking about xine 2.0 to start tossing some
fresh ideas around. I apologize in advance if my ideas are becoming a
bit too radical. If so, please just tell me.
I quickly isolated two points which I consider to be the top
* The architecture must become more generic with specific
functionality being encapsulated into components. This basically
means we should put a new layer of infrastructure beneath the
existing concepts: there should be components with various inputs and
outputs being wired together in a dynamic way. Between the
components, only certain well defined communication through packets
of data or commands is allowed. Especially, there should be no direct
function calls between components. This will make things more
flexible and allows us, similarly to the current post plugin system,
to build things like re-encoders with xine.
* Threading must be orthogonal to the components, meaning you can
more or less arbitrarily assign separate threads to the components or
have multiple components being driven by one thread. The extremes are
a single threaded xine and one dedicated thread for every bit of
workload. All the shades of gray in between should be possible to
realize with xine. Especially, it should be possible to extend the
inter-component communication beyond process (or even machine)
boundaries to run some components out of process. This could be
relevant for future DRM scenarios like the high definition disks (Blu-
Ray and HD-DVD), which require TPM-protected compartments to secure
the content. The threading design should make it difficult, if not
impossible, to produce deadlocks.
First thing, I would love to hear your opinions on whether these
design ideas actually make sense or are completely over/under/
Now, this sounds like quite a lot of work. But looking through
existing code out there, I found that all this exists already. It's
called gstreamer. Once I got curious, I browsed through their
documentation (for the first time I admit). What I read there matches
my ideas quite nicely. Although I don't know how much of this is
already working in their code, they have these things called
"elements" (which I called components above) which are connected
through "pads" (think of a post plugin's input and output ports). A
set of readily connected "elements" can be aggregated int a "bin",
which can be used to allow a higher level look on a processing graph
(sounds like xine_stream_t is such a thing).
Data flow between elements works only through generic mechanisms,
timing is provided by pluggable clocks (sounds familiar?). Data flow
through "elements" can work on a push or pull basis and you can map
threads to "elements" by grouping them together and separating the
groups with queues. Each such group has an entry point for a thread
which drives the group.
I would like to hear comments if you think we could benefit from
their work and if some kind of cooperation (though I don't know how
this would look like) between xine and gstreamer would be a good
idea. Since some of the popular media frontends (kaffeine, totem and
amaroK) are using both as a backend, the demand seems to be there.
More information about the Matroska-devel