Re: Factoring [Was: Common Opensource codec API]

2piksel: the topic of discussion is creation of video/audio input /
decoding API and i thought there's some overlap with piksel there. see
below...

On Mon, Jan 05, 2004 at 11:20:06PM +0100, Enrico Weigelt wrote:
> * 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 ...)

RTP provides functionality suited for carrying real-time content, e.g.,
a timestamp and control mechanisms for synchronizing different streams
with timing properties. so it's smarter then, say, file input. but it
doesn't know about frames/samples => it's still input. such smartness of
some inputs should be considered when designing input API.

'video-hardware' was even worse example ;-) it definitelly knows all you
need about the media and corresponds to the same level as "decoder" or
"container" [depending on wether it feeds encoded or decoded video].

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

ACK :)

i meant that the lower level API shouldn't IMPLEMENT synchronization,
but it should provide enough data to allow implementation of it by
higher level libraries or applications.

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

all you need on lowest level is to say: the library should implement the
following function[s] which return pointer[s] to a structure[s] with the
rest of the API. some minimal meta information like supported media
types / formats and human readable description could also be there.

the "LiViDo" part of piksel project aims to create plugin system for
realtime video effects and colorspace conversions. it would have been
nice if common codec architecture shared at least some data types with
LiViDo [the output of decoder is what video effect could be applied to -
if the format of video frame would be the same it'd be easier for a
developer to use both standards in an application]. see
http://savannah.nongnu.org/projects/piksel/

the LADSPA is similar standard but for audio. if the APIs would be kept
similar [i mean LiViDo / LADSPA] in parts that aren't audio or video
specific then life of developer would be even easier. 

the lower level [or rather closer to start of media pipeline]
input/demuxer/codec API could again use similar plugin architecture
leading to seamless integration of the three standards.

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

Oh, i have absolutelly nothing against C++, it's as valid tool for
building complex software as many others, but lower level APIs won't
profit from any of the C++ high level features. You don't need multiple
[or any] inheritance or templates mechanizms to implement codecs, so why
complicate the matters?

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