goal of kde-multimedia ?
wheeler at kde.org
Mon Feb 23 21:17:37 GMT 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
- 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.
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)
-----END PGP SIGNATURE-----
More information about the kde-multimedia