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

[Enrico Weigelt]

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

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

<snip>
> Free software development must be about freedom to exercise your
> programming creativity. When somebody creates a plugin for something
> (codec, effects, muxer, video output, whatever) he will just do the way
> he feels right. If he wants to create a plugin for xmms or xine or
> mplayer just because he like those better, good for him. My work, as a
> xine developer, is to later integrate his plugin to my own architecture.
This approach produces much redundant work. 
If I write a codec, since i like some encoding much, I normally want that
as many people as possible can use it w/o much work. And I dont want to 
cope w/ several different APIs which at the end all do the same.

At the other side, if I write a mm application, I dont want to adapt 
each codec one by one, but instead like to use the work of others 
(and that's what opensource is for!)

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


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/