goal of kde-multimedia ?
Leon Shiman
leon at magic.shiman.com
Tue Feb 24 01:36:51 GMT 2004
on Mon, 23 Feb 2004 22:17:37 +0100 Scott Wheeler wrote:
>Subject: Re: goal of kde-multimedia ?
>
>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.
Hi Scott!
Our teams met at Guadec 2 years ago in Spain. We spent many hours
discussing both MAS and GST. It was very cordial, and we enjoyed
some meals together. But no lasting relationships came of it. Some
of us have occasionally met at meetings since then. But there has
been no communication since Guadec2002. There have been occasional
reports that members of the GST team saw MAS as the "sound server"
for Gnome.
MAS was begun almost six years ago. GST didn't exist when MAS was
conceived, and MAS was envisioned, planned, and developed as a
complete window-system-independent network media solution. It was
of course to provide media support for X on all platforms. There
were several other design goals, most notably scalability, and
dynamic loading of all components. Most of the specification is
documented on the MAS web site.
MAS was also planned as an X.Org Standard. Great care was taken to
guarantee a clean code base, so that patents and copyrights were
not at issue. There have been contributions from X.Org and its
members to support some of the work. Delay in completion has been
caused by lack of funding. During the last year we have done a lot
more testing, and patched and extended the code base. The current
MAS code has been extensively tested on RedHat, Suse, Sparc Solaris
and AIX. It is also available - but not free - as a Win32 binary.
Last week the first RPM's were released. It has also available from
Debian. MAS public CVS is current. We are now working on Gnome
integration, which is scheduled for completion this spring.
I believe (of course) that a complete MAS is the best solution for
KDE. But a lot more work is necessary to get there. We would like
to build a community team to do this, if funding permits. As you
may know, we are very deeply involved in the new X projects
supported by the (now open) XOrg Foundation. There is a lot of
discussion about mainstreaming X as a multimedia platform. I see
MAS an an integral part of that effort.
I will try over the next weeks to organize a detailed presentation
on the current state of the MAS code base, and to propose a list of
specific projects which we see as required to move MAS forward. In
its present state, MAS provides a very efficient network media
timed-transport infrastructure. We have tested simultaneous
bi-directional audio across an open network for 100 continuous
hours, with no dropped frames.
Suggestions are welcome.
Please visit www.MediaApplicationServer.net for lists, code, and
documentation.
Leon
>
>- 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-----
>_______________________________________________
>kde-multimedia mailing list
>kde-multimedia at kde.org
>https://mail.kde.org/mailman/listinfo/kde-multimedia
More information about the kde-multimedia
mailing list