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

[Enrico Weigelt]

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

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. 

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.


<snip>
> 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.

<snip>
> > >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)


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/