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

[Michael Niedermayer]

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.


> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080907/35d6a70f/attachment.pgp>