[XviD-devel] "Generic" plugin mechanism

Christoph Lampert xvid-devel@xvid.org
Fri, 24 Jan 2003 21:35:30 +0100 (CET)


On Fri, 24 Jan 2003, Marco Al wrote:

> Christoph Lampert wrote:
> 
> > 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.
> 
> Adaptive quantization could be a plugin itself.

Yes, but it doesn't have to. I was rather thinking of stuff that's 
already there, but not a part of XVID. "general interest" stuff...

> Personally I think the plugin should be called directly after ME and

Shouldn't ME be done on the  already filtered image? Otherwise we need
another ME step.

> it should handle everything from MC to transformation and
> quantization, that way you dont need pre&post slots. You could make
> some standard full frame MC/quantization/coding routines which would
> prevent replication of the several loops now present in encoder.c
> which handle that whenever possible, but still allow almost all
> pre-processing schemes including the ones interdependent with
> quantization (adaptive and/or R-D optimized) to use the plugin system.

Maybe this would be an idea for restructuring encoder_encode() ?
I still find it a mess... we don't have to convert everything into 
function pointers, but a "simpler" encoder_encode() with calls to 
"modules" could be good. Some of those could be pointered later.


> > 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?
> 
> Dont restrict it to pre-processing, simular modularity is called for
> for post-processing IMO.

Yes, of course... but that's decoder and I was just planning encoder
for the moment. 

gruel