[MPlayer-dev-eng] Re: [xine-devel] Common Opensource codec API , was : Re: the road to 1.0 and beyond

[Enrico Weigelt]

* Guenter Bartsch <bartscgr at t-online.de> [2003-06-27 01:47:24 +0200]:

<snip>
>   to just opensource codecs - but binary-only codecs play an important
>   role in today's free software world, like it or not (think quicktime,
>   think real codecs for examples)

Well, for those we can still provide a win32-like API (yeah, of course,
we dont really want it ...)

<snip>
> - codecs
>   i'd like to broaden the discussion to all kinds of plugins, especially
>   demuxers and a common input abstraction layer
ACK. See my other posting.
Support for many other input sources, like streaming protocols or DVB
hardware should be set on an abstraction layer. 

We do not really need to limit to _one_ API. Just like today many codecs
and muxes are 'hardcoded', we could also do this with several APIs.
The goals is that developers are encouraged to use one of the supported
APIs (use this one they think its the best)

This opens doors to a really wide range of multimedia applications beside
just a/v-playback. (i.e. conferencing, remastering, ...)

Once we have such an extensible multimedia framework, many, many applications
can sit on top of it, from audio players to video cutting software.
This is what bloated windoze provides, what the GNU world does not have yet.
Application developers have a interface for quite easily accessing modules
from other parties (so ie. a video cutting software can working w/ quicktime
streams just by having quicktime installed on the system)

<snip>
> is there some documentation available on gstreamer's plugin api? sounds
> very interesting to me, but what i found on their website was pretty
> incomplete and hat lots of broken links in it. gstreamer is definitely
> worth looking into, though.
Could you please do some more research on that and keep us informed ?

<snip>
> i have also added mplayer's developement list to the recipients of this
> mail as i think their mplayer g2 efforts might be a good time to think
> about common standards as well.
I'm not familar w/ g2, so could you please give a short description of it ?

<snip>
> let's see, what he says :) one problem with gstreamer imho is their many
> g'isms, not sure what the current state there is. i think a common api
> should not be dependant on stuff like glib or gobject (though i love
> glib i don't think it's a good idea to force everyone into using it).
ACK.
In times of 1.0.x glib was quite good, but now its really bloated.
(but still not as ugly as gtk2 ...)

<snip>
> this is the time for constructive proposals, all flames and all mplayer
> vs xine vs gstreamer vs whatever ranting will go directly into
> /dev/null.
ACK.

Nobdy can really say, what's the best, since it depends on the personal
premises. Now we should sit together and put all redundant work into 
one project. Perhaps this someday ends up in <1k LOC per player (because
all common stuff has been moved to a common library), but this is okay, 
if each project still has its individuality.

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/