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

[Miguel Freitas]

Hi,

On Thu, 2003-12-25 at 05:58, Attila Kinali wrote:
> On Sat, 28 Jun 2003 16:35:45 +0200
> ChristianHJW <christian at matroska.org> wrote:
> > >>so, basically i think it would be interesting to see if it is possible
> > >>to agree on a common standard for free multimedia plugins, especially
> > >>for
> > >>
> > I 'd have high hopes on this also, but i am not convinced that it is 
> > possible to find a common denominator easily.
> 
> 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.
> 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.


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

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!"



> And i also dont think that a common plugin api would help much,
> as less then 10% of the code of filters and output modules are 
> interface code, so porting code from one interface to another
> (w/o optimizing to the new interface) is quite easy.


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


> 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

Yep. and that is only becoming a common api because it is a de facto
standard. imho libavcodec has exceptionally good programmers and is
heading to support about everything. so they don't push their api into
anybody's throat, they just code.


> ChristianHJW <christian at matroska.org> wrote:
> > >What I'd love to see is the codec API not being an actual lib, but just
> > >a protocol, like X. 

Luckily you are not the one writing codecs! ;-)

I'm not a codec writer either, so i leave this suggestion to the
experts. still, it doesn't sound like a good idea to me.

regards,

Miguel