[XviD-devel] [RFC] A solution to avoid API incompatibilities.

[Edouard Gomez]

Hello,

I don't  know if  this solution is  viable but  it's a nice  idea that
could solve API incompatibilities problems.

The question : what makes XviD API incompatibles ?

The answer : binary structures used in API.

One solution : get rid of binary structures.

Ok so now let's me explain it. For all of you that know what i've done
for transcode's xvid module, that's not so different (i added a config
parser to initialize xvid structures at runtime).

All we  need for  the new API  would be  a "command line  like" parser
(many already available, we have just to choosee the one that best fit
our needs).

The entry point does not change :
int xvid_encore(void *handle, int opt, void *arg1, void *arg2);

But the way we pass options wouldbe change to that :

typedef struct _xvid_option_t
{
	unsigned char *key;
	unsigned char *value;
}xvid_option_t;

xvid_option_t options[]  = {
	{"bitrate", "1000"},
	...
	{"XVID_INTER4V", NULL},
	{"XVID_HALFPEL", NULL},
	{NULL, NULL}
};

and then call :
xvid_encore(handle, XVID_ENC_CREATE, options, NULL);

For a frame encoding, xvid_option_t can be used :

xvid_option_t options[] =
{
	{"frame data", frame_buffer} /* this one passes the pointer to data */
	{"colorspace", "yv12"},
	{"quantizer", "12"},
	{NULL, NULL}
};

/* stats could use the same xvid_option_t structure */
xvid_encore(handle, XVID_ENC_FRAME, options, &stats);


I know this would complexify  xvid options parsing (because it becomes
ascii)  but this  way we  would have  eternal API  compatibility, just
keeping old (deprecated)  option names as aliases for  new ones in the
parsing engine.

It's just an idea, it is not meant to be what xvid api will look like,
but i prefer proposing it now that  XviD API 3 is not yet commited, so
we can still change it.

Of course comments are welcome.

NB : this  idea came to me when remembering the  UCI API proposal. Why
using a so cool approach in UCI and not directly in XviD ? :-)

-- 
Edouard Gomez