[XviD-devel] About dev-api-4

[Edouard Gomez]

I always thought that the (handle, operation, param1, param2) API was
cool because it's simple, however i think we use the wrong way for at
least 1 case.

If we look at xvid_dec_create_t, xvid_enc_create_t and xvid_enc_frame_t,
we can notice that  we have an [out] field in the  structure. I think we
should not mix  in/out fields in a  same structure if we want  to have a
nice API. In the first 2 cases, why not use the param2 parameter ? 

It would become something like:

xvid_enc_create_t xvid_enc_create;
void *enc_handle;

xvid_encore(NULL, XVID_ENC_CREATE, &xvid_enc_create, &enc_handle);

Same thing for the xvid_dec_create. 

Now  concerning the  xvid_enc_frame_t case,  i think  we should  not mix
input  frame and  output stream  in the  same structure  again,  nor the
out_flags that  are already available  through the stats  structure.  In
other words  i think we  are mixing lot of  concepts/parameters together
and  we  should not...   image  should  contain  all image  informations
including width and  height, quant matrices and par/par_width/par_height
should be part of vol structure, type/quant/bquant should be part of the
RC structure (i'm guilty for this one because i'm late at my RC merge)

Perhaps my OO courses at school  are slowly modeling my mind but i think
the actual structures are rather badly organized and inter dependent. 

Perhaps we should do this that way:

typedef struct {

    int version;

    xvid_vol_header_t vol_header;
    xvid_vop_header_t vop_header;
    xvid_motion_t motion_flags;
    xvid_image_t input;

}xvid_enc_frame_t;

typedef struct {
    int csp;
    int width;
    int height;
    void * plane[4];
    int stride[4];
}xvid_image_t;

And where  xvid_vol_header_t and xvid_vop_header_t are more  or less the
anonymous structures  defined in xvid_dec_stats_t  + some more  stuff in
it. 

The resulting code should look far more "logic" as structures will group
all related infos to the "object" they are supposed to represent. 

Just my  first closer look at  this new API,  as we are breaking  lot of
things, i think it's the good time to do it better (a bit more than pete
already did) :-)

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030307/d0b7e310/attachment.bin