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

[D Richard Felker III]

On Sun, Dec 28, 2003 at 07:57:39PM +0100, Enrico Weigelt wrote:
> * Attila Kinali <attila at kinali.ch> [2003-12-25 11:58:14 +0100]:
> 
> <snip>
> > Leaving all politcal reasons aside, i don't think that this is as
> > easy as you believe. I only know the code of mplayer and parts of vlc,
> > but sofar i've seen too many differences on how things are done,
> > that a common plugin standard could be acchieved w/o turning all
> > players into one using the same code base and ideas.
> 
> 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
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.

> 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
as the standard api. We are not going to compromise on crap for the
sake of being able to share code with shitty projects. I'm perfectly
happy porting and rewriting code for MPlayer to make it perform well
and work with our architecture, and I expect the other projects'
authors to do the same if they want to adapt our code.

People like you are as bad as the "unify the desktop" lamers. We do
not need, and refuse to make, a "common" design. It's pointless, it
hurts performance, and it keeps us from being able to throw out the
old crap and redesign when we need to.

> At least the audio stuff is a point I want to work on, since I also need
> it for some other projects.
> 
> <snip>
> > Beside imho it wouldn't be a good idea. The power of opensource
> > comes from diversity, if you restrict that by using a common plugin
> > format that restricts the whole player to use this api/abi everywhere
> > internaly, then you also restrict the diversity of code.
> But diversity does not forcibly mean, reinventing the wheel evrytime
> and still doing the same.

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????

> > The only place where a common api makes imho sense are the codecs
> > as this code is quite complex and only a few people have enough
> > knowledge to handle that stuff properly. But there, we already have
> > a quite common api for codecs: libavcodec
> I didnt have the time to look deep enough into it. Could you please
> give a short description of it ?
> 
> If I see it right, it only handles audio and video codecs. Well, on my
> suggestion (see my other posting) this is only one of many parts ...
> And if we find out, that libavcodec would also be okay for other projects
> (they can build a wrapper to adopt it to their internal interfaces),
> then why not taking it. But for this we need a goog documentation.
> 
> Please keep in mind, such a common codec api is not only good for 
> video players like mplayer and xine.

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
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
the groups agree on (including the evil Matroska gang) is all the more
impossible. There are just too many strikingly different approaches.

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.

> > > >What I'd love to see is the codec API not being an actual lib, but just
> > > >a protocol, like X. Each application can then write it's own
> > > >implementation code for this, and the codec API can, if wanted, provide
> > > >a header file describing all structs (if any) etc. used in the protocol.
> > > >Tying ourselves to one and the same lib likely won't work, even now
> > > >we're already reproducing so much of the same code... Do people agree
> > > >with this?
> > 
> > That's imho a quite bad idea. If you have ever written anything
> > time critical with using X11 than you know how much time you loose
> ACK. 
> I'm also not happy w/ the X protocol. In the xouvert project we're talking
> about inventing a new protocol, which also can handle things like
> mpeg streams, audio, etc. And there we also would like to use the codec lib :)
> 
> 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.

Rich