[XviD-devel] "Generic" plugin mechanism

suxen_drol xvid-devel@xvid.org
Sun, 26 Jan 2003 17:07:37 +1100


On Fri, 24 Jan 2003 19:17:08 +0100 (CET) Christoph Lampert <chl@math.uni-bonn.de> wrote:

> 
> Hi,
> 
> I noticed that my "idea" of passing a function pointer to XviD core 
> is just the first part of a generic plugin system. Let me just "think
> aloud": 
> 
> There could be slots within encoding, in particular _before_ and _after_ 
> the main encoding step, where generic functions could be called with
> access to internal encoder data. Either just one, doing everything it
> wants, or several, read from a linked list, etc. 

several would be good.

> My idea are things like prefiltering of the input image e.g. with access
> to adaptive quantization information, maybe also with access to motion
> data. 
> A PSNR-filter would also be possible (without the codec providing extra
> infrastructure), by using a pre-slot (buffering the input), and a
> post-slot (calculating PSNR) together. 
> 
> Of course, such filters could become a part of XVID itself, but since
> there are so many possible filters around, it might be easier to just
> write a small wrapper and use a routine which is not a part of the core. 
> XVID could contain a "library" of default filters, but if somebody wants
> to add and test a new one... no problem. 
> 
> I would like slots for "plugins" as a part of the core, not of VfW etc,
> because that way, things are more portable to non-Windows plattforms. 
> 
> What do you think? 

sounds good, although i think getting dev-api-3 back into the trunk
deserves higher priority. the difficult part is defining the api. here's my suggestions

plugin_before(void * private, xvid_enc_plugin_t * p);
plugin_after(void * private, xvid_enc_plugin_t * p, xvid_enc_stats_t *
s);


typedef struct
{
   uint8_t planes[4];		/* y,u,v,alpha */
   int stride[4];
}xvid_image_t;


typedef struct
{
   int version;

   // [...] our "new" stats structure, which indicates frame bitstream
length, etc.
} xvid_enc_stats_t;


typedef struct
{
   int version;
   int width, height;

   xvid_image_t reference;
   xvid_image_t current;

   xvid_image_t original;	/* plugin_after only: points the
original (uncompressed) copy of the current frame */


   int * qtable			/* plugin_before: quantization table for
implementing adaptive quantization */

} xvid_enc_plugin_t;


* plugins declare flags at XVID_ENC_CREATE time which indicate if they
require 'original'. so if none of the plugins require original, we dont
waste cycles making the original image copy.

* iam unsure about macroblocks and motion vectors. how would this fit
in with the motion estimation engine? would m.e then become a plugin?

* and in theory, ratecontrol could become a plugin too. (which would be
really swell). before and after translate to RateControlGet and
RateconrolUpdate.

-- pete; life is like a box of ammo