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

Michael Niedermayer michaelni
Sun Sep 7 14:19:28 CEST 2008


On Sun, Sep 07, 2008 at 09:00:45AM +0300, Kostya wrote:
> 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.

are they common enough to matter speedwise ?
if yes then one can do

quant_coeff= lut[lrintf(coeff34[j] * scalefactor34)];
for(i=0; i<2; i++){
    dist= dequant_tab[quant_coeff+i] - coeff[j];
    rd= dist*dist*lambda + bits_tab[quant_coeff+i];
    if(rd < best){
        ...
    }
}

coeff34 would be the coefficient^(3/4) prior to scaling, i think you suggested
someting similar already ...

also lut[] can maybe be droped, and the lrintf() be used though this may
require then more tham 2 tries then. With a lut its possible given a larger
scalefactor34 to ensure that <= 2 are sufficicent.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/f880be8f/attachment.pgp>



More information about the ffmpeg-devel mailing list