Factoring [Was: Common Opensource codec API]

On Fri, Jan 02, 2004 at 08:55:54PM +0100, Benjamin Otte wrote:
> > Glue layer? Gstreamer is an API for multimedia pipelines consisting of
> > source, format conversions and sink. And certainly format conversions
> > include codecs too.
> >
> What you should all keep in mind is that it's horribly complicated to
> write a plugin for a do-all system like GStreamer. I write them daily, so
> I know that.
> We're heavily moving to subclassing now so writing plugins becomes easier.
> 
> No codec developer wants to write something complicated. WHich is why
> codec developers like Xiph or whoever don't ship plugins for $media
> -{framework,player} but their own API. If I could implement a simple
> decoder plugin in 100 lines of code, that'd be a simple API.
> 
> So instead of inventing some be-all-end-all you could invent something
> that does what it should for 80% of the people and let the other 20%
> invent their own APIs.

hmm, just what i wanted to write but was to lazy :)

nevertheless my 5 cents.

what really lacks standartization are:

- dumb input layer (file/http/rtp/video-hardware/...). dumb in the sence
  that it doesn't know anything about the media its reading
- container layer (AVI/QuickTime/Matroska/...)
- encoding layer (well, you know)

forget about implementing the synchronization between them, or even
passing the data from one to another. Forget about "playback"
altogether. Leave those tasks to API users [== developers of video
software].

separate these three tasks so that codec implementor doesn't have to
worry / know about container or input. Of course eventually the data
from one layer has to reach the next one => it's useful to have common
data types (that are outputs of one layer and inputs of the next one).

if you want application independent plugin system - you can do the same. 

if you want the analog of DirectShow, you can make a separate API on top
of the simple media i/o API. 

by separating these essentually different tasks you'll make sure more
developers are interested in developing inputs/demuxers/codecs with
simple API which will immediatelly be available in your plugin system
and in playback API (DirectShow analog).

Another thing: keeping input / container / encoding layers simple you
won't be needing C++ there, these API may and should be defined as pure
C. On the other hand the plugins and playback layers may be in C++ or
whatever you prefer. 

-- 
gr{oe|ee}t{en|ings}
artm