[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