[MPlayer-dev-eng] Re: [matroska-devel] Re: Common Opensource codec API

[Enrico Weigelt]

* D Richard Felker III <dalias at aerifal.cx> [2003-12-28 14:32:28 -0500]:

<snip>
> > What exactly is so different ?
> > Could you please point out some examples ?
> 
> vlc, xine, ogle, etc. are SLOW, do not support advanced filtering, do
> not support performance optimizations (slices, direct rendering), do
> not support tons of obscure colorspaces, crash, etc. etc. Optimizing

Okay, then these projects perhaps only will make use of a subset of the
discussed new mm framework. 

Do you see any other problem ?

<snip>
> for simplicity and performance are NOT the same. MPlayer developers
> are able to do both fairly well, although simplicity comes second.
> Matroska developers are opposed to both.
Please no flaming against matroska people. 
We're not talking about matroska here, but about a common api for several
codecs and devices.

<snip>
> > Perhaps we do not come to a "big unified api" yet, but can do some
> > smaller steps, i.e. first implementing the audio playback, then 
> > audio codecs, then video codecs, etc ...
> > 
> > We should start _NOW_ to do something. 
> 
> No, and we will not. Unless the rest of you want to adopt MPlayer G2
Who is 'we' ?

> as the standard api. We are not going to compromise on crap for the
Could you please give me a pointer to a description of this api ?

<snip>
> People like you are as bad as the "unify the desktop" lamers. 
Oh, thanks for you arrogance.

<snip>
> This is the oldest and most idiotic analogy used by "unification"
> advocates. Please drop it. It was wrong the first time someone said it
> and it's wrong now. The wheel is very simple and universal and there
> is essentially only one design. Software is much more complicated. A
> better analogy would be "reinventing cancer treatment"....maybe since
> we already have some treatments with horrible side effects, it's not
> worthwhile for someone else to research a different approach????
Audio IO is also a quite simple thing. Video IO also.
Audio+Video Codecs being implemented as blackboxes should also be 
relatively simple.

Why such redundant work is necessary ?!

<snip>
> One second you're talking about common _codec_ api, the next second
> about something else, and I have no idea what it is. If you're talking
yeah, I'm talking about multiple multimedia APIs for several jobs
which somehow belong together:

* audio IO
* video IO
* streaming input
* streaming output
* audio codecs
* video codecs

<snip>
> about a common demuxing/decoding/processing/filtering/output layer,
> then the answer is the world's biggest NO. We (Ivan and myself) can't
> even agree on a single api for MPlayer G2. Finding something that all
Why not ? Where's the problem ?

> the groups agree on (including the evil Matroska gang) is all the more
> impossible. There are just too many strikingly different approaches.
Why cares about matroska ?
As long as this thing is not really working and frequently used, we
dont need it. If someday someone wants it, he can code a mux for it ...

> As long as individual project authors write the code well, porting
> from one api to another is _not_ difficult. But using a common api
> _is_ _very_ difficult and is not going to happen.
Perhaps we're not at the point for a common video codec api yet, but many
other things like audio-io can be unified today. Other parts may follow
later. 

<snip>
> > But that's not the point here, instead we first have to talk about library
> > interfaces, since protocols should be constructed for environmental 
> > needs and wrapped into a lib which provides the protocols's functionality
> > on a higher abstraction level (i.e. this is what xlib does for X11)
> 
> And this makes it slower, less efficient, and more bloated. No thanks.
Why ?!
What else does libavcodec do ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/