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

[Guenter Bartsch]

hallo christian,

one the one hand i am happy the subject has changed as this discussion
was getting pretty off-topic, on the other hand i dislike two things
about the new topic:

- opensource
  while i dislike the word in itself (i never really understood what
  the opensource movement is about), i think it limits this discussion
  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)

- codecs
  i'd like to broaden the discussion to all kinds of plugins, especially
  demuxers and a common input abstraction layer

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

- a common input abstraction layer
- demuxers
- codecs

and maybe also

- audio/video output

among some media player projects.

> Ronald 'BBB' Bultje, one of the core devs of the Gstreamer team is 
> reading here AFAIK, so he could make contact i guess.
> 
> The Gstreamer people do have a nice API with their 'gst plugin API' 
> AFAIK, but it doesnt help them a lot as its tied to Gstreamer as a 
> framework and so no codec developers will support it natively. So, in 
> the end, they have to make all the plugins themselves now ( i guess BBB 
> is doing that ) and also maintain them.

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.

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 was talking with Erik 'omega' Waltinsen a couple of times on IRC, he's 
> the founder of Gstreamer and does certainly know a lot about this kind 
> of stuff, and he told me he had a neat concept in the very back of his 
> brains already, but just no time to bring it onto paper. Maybe if you 
> guys showed some real interest in cooperating with them here, you could 
> start an avalanche ....

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

so, let's hear what people have to say.

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.

   guenter


-- 
"The other day I put instant coffee in my microwave oven ... I almost
went back in time."
                -- Steven Wright