[XviD-devel] Revolutionary idea for speeding up 1st pass ;->

Michael Militzer michael at xvid.org
Wed Sep 10 01:34:56 CEST 2003


Hi,

just a short note: Do you really believe that this is a revolutionary idea
for improving first-pass speed? I mean sure, what you describe will indeed
work - it's just that I think that the speed-up will be rather small. I
don't think that storing the quant value in a register is that costly (as
long as we have enough registers which we have), but let's assume that you
could achieve a 10% speed-up of DCT+quant by using your method. DCT+quant
together take up about 10% of total encoding time. A 10% speed-up for
these two processing steps does not influence the total encoding time much.

But the changes required to implement your idea would be rather big and I
doubt a bit that the small gain that can be expected from it would really
be worth to invest the time.

bye,
Michael


Quoting Christoph Lampert <chl at math.uni-bonn.de>:

> 
> ...or maybe not.
> 
> Just a quick idea I had yesterday: 
> 
> The quantizers most frequently used for high quality without Bframes are
> (as far as I know) below 10, with emphasis on 3, 4 and 5. First pass is
> usually done with fixed quant 2. 
> 
> Now during quantization, this fixed 2 is passed by value to each and every
> routine. The same for the other values: The same value is passed to every
> of the 6 blocks of the 1000 macroblocks of a frame, unless adaptive
> quantization is active. 
> 
> Couldn't we create separate (de)quant routines (or more) for the most
> frequently used quantizers? This would save 1 register for the quant
> values, and also sholud be easier to optimize (for the programmer or
> compiler) because division/multiplication/rounding and/or table lookup
> is constant and could be simplified or completely removed. 
> 
> Since we have function pointers anyway, these pointers could just be
> updated at the beginning of each frame to point to the right fixed
> quantizer routines. Then it would need 31 different routines, of
> course, which should then rather be generate by a script (partial
> evaluation).
> Otherwise, we would have to check e.g. for Quant<=5 and then call
> QuantizeSpecial[Quant](); or QuantizeGeneral(Quant); 
> 
> For H263-quant, the result would be that simple, that maybe just table
> lookup would work, too (if this is faster at all, which I don't know), at
> least in the most frequently used interval for small coefficients. 
> 
> Instead, maybe const value quantization would become that simple that it
> could be integrated into (i)DCT. Those act on the same memory, which would
> then be SIMD registers, right? 
> 
> gruel
> 
> 
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
> 





More information about the XviD-devel mailing list