[FFmpeg-devel] [RFC] AAC Encoder, now more optimal

[Kostya]

On Sun, Sep 07, 2008 at 01:55:43AM +0200, Michael Niedermayer wrote:
> On Sat, Sep 06, 2008 at 10:50:51PM +0200, Gabriel Bouvigne wrote:
> > Kostya a ?crit :
> > > It is slower than realtime since it uses search for optimal quantizers
> > > for given quality.
> > 
> > 
> > > Any comments, suggestions, speedup tricks are extremely welcomed
> > > (especially the latter).
> > 
> > Hum...do you also plan on having an encoder really useable, or only an 
> > optimal but unpractical one?
> 
> i think its a little early to criticise its speed, i think the final encoder 
> will have a few user specifyable parameters to tune speed vs. quality/bitrate.
> considering the speed of our aac decoder compared to faad iam confident
> our fastest mode will beat many other AAC encoders in speed.
> 
> 
> > 
> > Speedups: well, except some heuristics and early terminations here and 
> 
> IMHO its too early for heuristics, we are far from having exploited all easy
> exact optimizations, also the encoder is not optimal at a few points where
> it should be.
 
well, maybe you have said that but I missed that: instead of quantizing I
can just try multiplied vectors for codebooks from aac_tab.c, thus finding
real quantization distortion for coding with codebook and avoiding pow()
calls that cannot be optimized out. The only problem then is to deal with
values > 16.
 
> > there, a major speed hit is likely because of your quantization function.
> 
> yes and this function should actually not be used for quantization because
> it is not optimal.
> 
> 
> > A trivial convertion from float to integer is painfully slow with x86 
> > processors.
> > Within LAME, Takehiro Tominaga implemented a nice trick to perform the 
> > quantization using an union over float and int. You can check it within 
> > takehiro.c, within #ifdef TAKEHIRO_IEEE754_HACK, quantize_lines_xrpow.
> > 
> > It's basically playing with the internal representaion of ieee754 floats 
> > in order to do the float to int conversion in place within an union, 
> > without any direct cast.
> 
> i trust in lrintf() being fast enough. Still we have code for that 
> int32_t trick (int would be even less portable) as well in float_to_int16_one.
> Also we have nicely optimized float_to_int16 code that converts a array
> using whatever asm code is best for the job on the current platform.
> And more code could be added ...
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Old school: Use the lowest level language in which you can solve the problem
>             conveniently.
> New school: Use the highest level language in which the latest supercomputer
>             can solve the problem without the user falling asleep waiting.