Re: Re: Factoring [Was: Common Opensource codec API]

* Artem Baguinski <[email protected]> [2004-01-07 10:57:33 +0100]:

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

So RTP should be implemented as a input/demux module ?

<snip>
> 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.
Yes. It should just give the client give an interface for retrieving 
latencies, chunk sizes, bandwidth, ...

<snip>
> 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.
Yes, but I would like to see a little more abstraction. 
First, lets call each autonoumous unit a "module" - and a library is
(as the operating system understands them) a collection of code
(shared objects). Now each library should be able to contain more than
one module. Also modules should static-linkable (i.e. for environments
w/o shared objects ... think of embedded systems w/o real filesystems)

A module exists of a module descriptor (which tells the world what this
module does) and a set of interfaces (retrievable via the module descriptor).
I'm not really happy w/ the way the linux kernel handles modules - they 
register themselves evrywhere. This leads us into big trouble if we need
separated environments in one process space (perhaps not needed on unix,
but maybe interesting for embedded systems)

So in the library build it could look like this:

    struct library_desc 
    {
	void* priv;
	int (*addref)(struct library_desc*);
	int (*unref)(struct library_desc*);

	const char* name;
	const char* description;
	const char* author;
	const char* version;
	
	struct* module_desc (*query_module) ( struct library_desc* pos, int pos );
    };

    struct library_desc* get_library_inf();
    
Our modules look like this:

    struct module_desc
    {
	void* priv;
	int (*addref)(struct module_desc*);
	int (*unref)(struct module_desc*);

	const char* name;
	const char* description;
	const char* author;
	const char* version;
	
	struct service_desc (*query_service) (struct module_desc* mod, int pos);
    };

If the module is build as a single-object, it exports 

    struct module_desc* get_module_inf();
    
On a compile-in build, it exports a similar function:

    struct module_desc* mod_<modulename>_get_module_inf();
    
(this function will be directly called by the client - just as the linux
kernel calls init() functions of compiled-in modules directly on kernel init)

Well, now the services:

    struct service_desc
    {
	void* priv;    
	int (*addref)(struct module_desc*);
	int (*unref)(struct module_desc*);

	const char* name;
	const char* description;
	const char* author;
	const char* version;

	int service_class[4];	/* multi-step classification */
	
	/* ... service type dependent stuff added in other overlaying structs */
    }
    
Services are classified in a multi-step hierachy.
For example class[0] could be SRV_MULTIMEDIA
class[1] could be SRV_MULTIMEDIA_AUDIO_FILTER
class[2] could be SRV_MULTIMEDIA_AUDIO_FILTER SOFTWARE or 
SRV_MULTIMEDIA_AUDIO_FILTER_HARDWARE, ...

We will have to talk a bit about good classification.

For example we perhaps need:

    SRV_MULTIMEDIA_AUDIO_INPUT
    SRV_MULTIMEDIA_AUDIO_OUTPUT
    SRV_MULTiMEDIA_AUDIO_CODEC

    on codecs we could use the next class steps for input and output 
    encoding. So a quite generic audio converter would supply
    a bunch for services for each source:target encoding pair.
	
<snip>
> 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?
ACK. 
You dont need C++ here and it just produces incompatibilities.


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/