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

[D Richard Felker III]

On Sun, Dec 28, 2003 at 08:15:35PM +0100, Enrico Weigelt wrote:
> * Miguel Freitas <miguel at cetuc.puc-rio.br> [2003-12-26 11:47:24 -0500]:
> 
> <snip>
> > I agree with Attila. The problem for finding this common denominator is
> > that all those projects have some different paradigms and its unlikely
> > you would be able to convince another project to follow your idea (maybe
> > changing their codebase heavily). Some only use C, some prefer C++, some
> > have a monolithic architecture, some use plugins and shared libs, some
> > use a protocol instead of an API...
> 
> Well, where exactly do you see the problems ?
> In most cases it should work for them writing a wrapper which provides
> their internal interface and uses our new framework. They could use it
> just as we're using other libraries or even win32 codecs. Nobody said,
> other projects have to be rewritten complely just to be based on our
> mm lib, but they should try to use as many codecs from our mm lib as 
> they can and contribute new codecs for the mm lib instead of their own
> internal api.

This is ALREADY BEING DONE! The lib is called libavcodec. Why don't
you go LEARN about it rather than trolling the list?

> > Last time this discussion emerged i felt skeptical about the success of
> > such external standardization. I mean, suppose xine, mplayer and
> > matroska teams agree on a grand unified api. it would be very arrogant
> > to imagine that any other project would just follow (like if we were the
> > 'leaders' or something). "hey
> > {faad|mad|libmpeg2|liba52|flac|ffmpeg|ogg|vorbis|vlc|etc|etc} developer,
> > please abandon your own api because we just created a new one for you!"
> 
> No, thats wrong. These libs are each one specialized for some individual 
> task (i.e. decoding mpeg2 or ogg) and so of course provide a interface
> specially for this task. It should be an easy job to write some small
> wrappers to plug them into our mm framework. Evryone who really needs
> special stuff which is not covered by the mm api, can still use the lib
> directly, but all those folks, who only want to put in one stream and 
> get out another stream (this is what a codec does) and do not want to
> cope with each lib's specialities, just use our mm framework.
> And also no modifications are necessary in the libs, as we just put
> wrappers around them (just as mplayer+friends now do)

Then you can write this wrapper (aka mm framework) and use it for your
projects. But MPlayer devs have no desire to use it. We hate wrappers.
So don't involve us in this project. Take it somewhere else.

> > of course, if the guy wants to make the plugin more popular he may just
> > write those remaining 10% of code and port it our player.
> 10% ?!
> Well, thats too optimistic!
> 
> I've ported mpg123 to my disco player (http://sourceforge.net/projects/dds),
> that was a really hard job, since there was no device abstraction (direct
> writes to /dev/audio) and MT was impossible, since evrything's stored 
> in global variables.

mp3lib (mpg123) sucks! Properly written codecs are not like this. It
doesn't take any "common api" nonsense, just competent programming.

Rich