Re: Factoring [Was: Common Opensource codec API]

* Artem Baguinski <[email protected]> [2004-01-05 10:18:18 +0100]:

<snip>
> - dumb input layer (file/http/rtp/video-hardware/...). dumb in the sence
>   that it doesn't know anything about the media its reading
is rtp really "dump" is this meaning ?
(i dont really know how it works ...)

<snip>
> 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].
hmm.. yes and no ...
we need exact timing information to do synchronization, i.e. timestamps,
latency checks, etc.

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

<snip>
> if you want application independent plugin system - you can do the same. 
as already mentioned, we should at least should have a small module 
managemt system, which allows to describe modules on source level 
very compact and easily and is used as source for several build systems,
which then may produces dl's or static libs.

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

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

> 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. 
Also ACK. 
I personally dislike C++ for several reasons. I would never use a
codec API in C++ - many other people too. One point is that plain-C
is better for adapting other languages (java, php, oberon, ...)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [email protected]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/