[XviD-devel] "Generic" plugin mechanism

[Marco Al]

Christoph Lampert wrote:

> 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...


Like say refdivx's adaptive quantization? Or Marc's experiment where he
selectively filtered the original image if there was a large DFD?

>> 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.

Yes, but if you filter the original image (rather than the DFD) you need to know
how well MC has worked to be able to determine the filter strength ... doesnt
pay to filter something for which MC works perfectly. You might as well use
avisynth, the information available to a filter in your scheme is mostly
irrelevant. The only remotely usefull information is the quantizer, but it seems
more usefull than it is IMO again because you dont know how well MC is working
(also a reason why determining DQUANT without taking into account the DFD isnt
all that usefull).

Now that you mention it it might sometimes be usefull to be able to do
operations before the first ME, so I guess IMO all the functions in encoder.c
should be plugins ;)

>> 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.

Oh definately, with XviD a traditional plugin system doesnt make a whole lot of
sense ... better modularization would suit most developers just as well I
imagine.

I would prefer versioned libcores come to think of it, with the right one being
selected by the frontend (VfW or otherwise). This reminds me though of the
problem of configuration ... how do you perform platform independent
configuration? (A problem for the original scheme too.) Part textfiles, part GUI
(in the case of VfW) is a bit ugly ... but too much work to avoid I guess.

Marco