goal of kde-multimedia ?

[Scott Wheeler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 23 February 2004 18:58, Alexander Neundorf wrote:

> Probably I *am* too short-sighted, but both work perfectly e.g. for me and 
> my girl friend, and I even hacked a bit on both. Where are the big design 
> problems ?

Well, to be clear -- they do what they are intended to do well; they don't do 
what we need them to do well.  They're made for playing audio and video 
respectively and they do that.  They're not designed to be the core of a 
framework that allows the type of flexibility that we need in KDE.

The MPlayer author specifically acknowledged this when he left the current 
MPlayer tree to start on a new, modular architecture, but this isn't likely 
to be stable in the KDE 4 timeframe.

> I would really like it if we can achieve this, but are you sure we have the 
> man power to do it ?  E.g. mplayer has many contributors which concentrate 
> only on mplayer. This is different from KDE, where most people don't work on 
> only one topic. Are we able to get better results than the mplayer/xine 
> crowds with only a handful of developers working on it casually ?

I'm in fact sure that we *don't* have the man power to do this.  But some of 
the projects that we could cooperate with do.  I think we *do* have the man 
power to put a decent GUI on some of this stuff.
 
> Yes, this is possible.
> But what do we need more than an easy-to-use sound player class and an 
> easy-to-use video widget/kpart ? Maybe this is short-sighted, but I don't 
> see what I am missing. 

Well, for starters most of the applications in KDE's CVS that are currently 
using aRts couldn't be ported to the subset of functionality that you're 
suggesting.  JuK specifically actually probably could be ported to it, but 
that's only because I've not added certain (often requested) features that 
would make it harder for it to be portable across different multimedia 
architectures -- once we decide on something for KDE 4 I'd like to be able to 
implement some of those as well.

MPlayer isn't a library but a CLI program.  I think there are some problems 
with running multiple instances at once.  The CLI interface could be wrapped 
to provide a video widget in a lib interface, but that gets ugly since it was 
never designed to be able to do that.  We've seen a couple of places where 
this was done in KDE and they're pretty ugly -- kspell and the netscape 
plugins X-embed hack come to mind.

> I guess probably we'll go for gstreamer ? Sounds quite good, and with e.g. 
> MAS we also have network transparency. This would probably also fix the "too
> few developers" bug ;-)

Well, from my understanding MAS is meant to be an alternative to GStreamer, 
not a supplement to it.  Specifically I know that the two groups aren't 
particularly fond of oneanother.  Hopefully Leon can shed some light on this 
matter.

- From what I've seen thusfar there are three options that have emerged from 
this discussion that I see as things that we should all be gathering 
information on pending a decision about the KDE 4 multimedia architecture:  
GStreamer, MAS and NMM.  Here are the significant points that I would note 
about them (again, based on only partial understanding of any of them).

=============================================================================

* GStreamer:  Reasonably mature, plugin based multimedia framework that 
handles audio and video.  There are quite a few applications and tools 
already using it in "production" use including two KDE applications.  It will 
be used as GNOME's MM architecture in 2.6 and there's a chance to share 
plugin and bugfixing code.  They're also very interested in supporting KDE.  
It does not provide a sound server and is not bound to a specific output 
method.  The downsides from the KDE perspective are that it's GObject based 
and in C.

* NMM:  Newer, more research geared framework that's not as mature, but is in 
pretty clean C++.  Codec support doesn't seem stellar, but there's a 
reasonable set of input plugins.  There seems to be at least some passive 
interest in working with KDE.  It has network transparency built into the 
design.  On the other hand it's less mature than GStreamer and uses IDL which 
I'm not personally a fan of.  There aren't many things currently using it.

* MAS:  Project organized by X.org that is designed to be a one-stop 
multimedia solution including a multimedia framework and server.  It has a 
mechanism for codec abstraction but doesn't have very many codecs 
implemented.  I can't find any "real" projects actually using it yet.  The 
development mostly happens behind closed doors.  It's written in X-style C.

=============================================================================

I know a good bit about GStreamer and am currently looking into NMM and at 
some point intend to give a better look at MAS.  I would encourage others to 
do the same.

- -Scott

- -- 
It may be true that you can't fool all the people all the time, but you can 
fool enough of them to rule a large country. 
- --Will Durant
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFAOm30Qu0ByfY5QTkRAjHyAJ9T8aHz1dCW5Yn6mvizzNI5ObnGOgCgzvhH
H30/p5FHKkjxwYnjUfm4M7s=
=9rn7
-----END PGP SIGNATURE-----