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

[Enrico Weigelt]

* D Richard Felker III <dalias at aerifal.cx> [2003-12-29 12:44:18 -0500]:

<snip>
> Neither is at all simple. For audio, you need to keep track of buffer
> delay and depth so that you can keep the buffers as full as possible
> while also knowing which sample is currently being played. This is
> very different from games, which are realtime and force you to use
> tiny buffers to minimize audio delay.
Yes, but as well as libao2 has some interface for controlling this,
some new library can also have this. Whats the problem ?!

> For video, you need to manage allocating and freeing multiple buffers
> (lots of you want to decode ahead! and at least 3-4 if you want to
> play files with B-frames!), controling and monitoring the time when
> the visible buffer is swapped, knowing which buffers are safe to write
> to and which aren't, ... If you want crappy vo_x11 (which tears) or
> vo_xv (which is slow and tears with some bad drivers), it's easy. We
> want speed and perfect output.
You've manged it to put it all into libvo ?
So why cant exactly this lib be separated out which could also be used 
by others ?

<snip>
> > Audio+Video Codecs being implemented as blackboxes should also be 
> > relatively simple.
> 
> It's not as simple as it sounds, but anyway, it's _ALREADY_ _DONE_.
> For the 2093595494380943854th time, it's called libavcodec!!
Yes. I know this, and I've telled you this. But you dont really listen
to me.

So I'll try it again to explain what I want to say:

I want to move out these libs, so other projects can adopt them. The 
interfaces may remain exactly the same, perhaps some little extensions
like allowing dynamic module loading and make some things easier
in the build system. 

<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
> 
> These classifications are nonsense. Input and output have _nothing_ to
> do with one another. The requirements are totally different...

Okay, then audio input, video input, audio output, video output.

> > * streaming input
> > * streaming output
> 
> What do you mean? Have you even _read_ MPlayer's stream code? It's
> already there, and it will be entirely modular in G2 (maybe it already
> is). Any other project that wants to use it is free to.
Okay, if it is already there, then lets use it.

> > * audio codecs
> > * video codecs
> 
> libavcodec!!!
YES!!

harrgl! 
Did I ever say, we have to invent evrything new ?!
I simply had made a little list of things we need, and then we have to 
look whats already there. And of course >90% of this "ideal" is already 
working. 

<snip>
> Ok, who cares about other players either? We'll just make our nice
> libs (as already planned) for MPlayer G2, and if anyone else wants to,
> they can code stuff for xine, etc. to use them.
hrrr... you really didnt listen to me!

<snip>
> It's already been attempted and failed multiple times. See SDL,
> ClanLib, libaudiofile or libsndfile or whatever, ... They're all made
> with stupid assumptions of trying to accommodate newbie coders, rather
> than doing stuff properly.
They have all quite problemativ interfaces and tried to do too much 
while being focus on too small scopes.

I was working on SDL for some while. These days I wanted to make a clean
and simple multimedia access layer out of this. But people didnt listen
to me and did not understand what I want (the only one who really understood
this was sam, but the SDL project was more and more going off his hands ...).
People liked more adding dozens of features over features which did not 
belong there (i.e. filesystem access, memory management, or networking), 
were only focused on game programming and put evrything what sounds platform
dependent into SDL. Of course it had to fail. The same with Clanlib.

libaudiofile was not made for things like movie players - it is very old
and these days no one really thought about this. But why cant we learn
from the past and improve for the future ?


Of course some day, there will be new requirements and new ideas, so the
old interfaces are not good enough. You see this yourself on G1 vs G2.
But old interfaces can be adapted into new ones (i.e. vo_SDL + ao_SDL
- if it worked - solves quite a lot of problems: it supports all 
devices which are supported by SDL - of course not as performant as
native drivers).


<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 ?
> 
> Mainly it encodes and decodes audio and video. It also contains a
> horribly slow software scaler (not used by MPlayer, which has a much
> better GPL'd one, but there for ffmpeg which needs LGPL code) and an
> optional (GPL) postprocessing implementation.

Well, cant libavcodec be an own (mplayer-related) package - which of 
course if maintained by the same people ?

> Anyway, if you don't even know what libavcodec is, you probably belong
> on mplayer-users, not mplayer-dev-eng...
Of course I _do_ know what libavcodec is (although I do not yet know the
details), but used those rhetoric questions looking forward you're telling
me, what really your problem is, when libavcodec becomes a own package
(still shipped w/ the standard mplayer distro).


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/