vtables

i forgot to mention about these vtables:

1. different subsystems have different structures with small number of
   methods to implement [e.g. decoder_vtable_t contains only decoder
   spesific calls, encoder_vtable_t - only encoder specific,
   input_vtable_t - only input specific etc.] 

   this makes implementation easier and the module code cleaner.

2. if you realy realy want the messaging system - you can add one on top
   of vtable. then you'll have one implementation of select(vtable,message)
   or better encoder_select(encoder_vtable,message) etc. I would not
   even have messaging in the low level api. many people, me included,
   won't use them.

3. the initialization below was illustrative, actually you dont have to
   mention not implemented calls, they will be NULL by default. so 

> static vtable_t my_vtable {
>   .get_next_frame = get_next_frame; /* implemented call */
>   .seek_ms = seek_ms;               /* another one */
>   .seek_frame = NULL; /* not implemented call */
>   ...
> }

becomes

> static vtable_t my_vtable {
>   .get_next_frame = get_next_frame; /* implemented call */
>   .seek_ms = seek_ms;               /* another one */
> }



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