[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: goal of kde-multimedia ?
From:       Leon Shiman <leon () magic ! shiman ! com>
Date:       2004-02-24 1:36:51
Message-ID: 200402240136.i1O1apo23851 () magic ! shiman ! com
[Download RAW message or body]

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@kde.org
>https://mail.kde.org/mailman/listinfo/kde-multimedia

_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread]