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

List:       kde-multimedia
Subject:    Vote for a MM system (Was: Re: summary of the aKademy meetings)
From:       Christian Esken <c.esken () cityweb ! de>
Date:       2004-09-09 0:09:31
Message-ID: 200409090209.31373.c.esken () cityweb ! de
[Download RAW message or body]

On Wednesday 08 September 2004 14:13, Marco Lohse wrote:
> Alexander Neundorf wrote:
> [..]
> 
> > A simple KDE API for simple purposes and a recommended framework for advanced 
> > purposes is IMO a really good solution. And I guess most KDE developers 
> > writing advanced MM apps will write some kind of bindings for their preferred 
> > framework. Maybe this will naturally lead to one preferred framework with its 
> > bindings, which can then (maybe in 2..5 years) become the defacto KDE 
> > standard MM framework.
> > 
> > 
> > 
> I think I mostly agree with your opinion. And I am afraid, I did not 
> make my ideas very clear in the beginning:
> 
> The 'simple KDE API' (aka the 'abstract player interface'? aka 
> 'meta-architecture'?) : Simplicity is fine. However, I am sure we can 
> create a simple yet powerful API. For example: let's just say this API 
> should only be used for file playback. So, the simplest API would allow 
> to set a media source, automatically create a flow graph for audio/video 
> rendering, start, stop, pause, ff, rew.

OK, I feel we need to come back to our senses. Lets face reality:

Have you ever seen the DirectX (DirectSound) API?
Actually there are trivial sound players and there is high-end audio-software on \
Windows. And "it works". So we can somehow agree that you can do "anything" with that \
API, right?

So now take a look at the Windows DirectSound API and stop dreaming. How the hell can \
those Win-developers program good MM apps with a crappy API? So it looks like the \
artistic beautiness of the API is definitely NOT our problem. And doing 2 \
artisitcally beautiful API's is totally out-of-scope. We can discuss a perfect API \
for years, but that does not solve any problem.

And actually a KDE API is nice for KDE, but totally irrelevant to UNIX in general.
Yes, we do not even have a generic UNIX MM API - there is no X11 for sound.



OK. enough rambling. 

So, what do I want to communicate:
1) We need an API
2) We need an Linux/*NIX API ... starting with the most trivial stuff like play(), \
pause(), ...  The API is not perfect? So what? API's can and do change. Even after \
years. There is a X11R6, there is DirectX 9 ... so what?  Don't dream about doing the \
perfect API from scratch in 2 months ... that is absurd. 3) We need something NOW \
(waiting another 2 years for somehting that might creep up does not make any sense). \
4) The API must not impose limits on usability on "other" languages. This means, \
bindings for "other" languages should be  possible to do without to much hazzle  \
(e.g. C, C++, JNI, any-other-executed-language, possibly also Script-languages like \
Perl). 5) We need to untangle the current mess of 20 different sound systems:
   The first step here is to allow applications to find out which soundsystem to use \
and to allow an easy migration path.

Thus my vote will go to a MM API, that supports a MM backend system that fulfills all \
of the following properties: a) Can NOW play audio and video
b) Is quite stable (running and API-wise)
c) Is available NOW
d) Is available NOW on multiple Operating Systems (at least Linux, Solaris, *BSD \
[preferably FreeBSD] ). e) Is NOW maintained by a large developer base
f) has an OpenSource license
g) has an open development mentality (stuff like "open" development lists, "open" bug \
system, ...)



Chris
_______________________________________________
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]