[FFmpeg-devel] [PATCH] avcodec/aac_tablegen: speed up table initialization
gajjanag at mit.edu
Fri Nov 27 15:16:01 CET 2015
On Fri, Nov 27, 2015 at 8:10 AM, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 27 Nov 2015 13:51:57 +0100
> Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Fri, Nov 27, 2015 at 1:48 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> > On Fri, Nov 27, 2015 at 7:05 AM, wm4 <nfxjfg at googlemail.com> wrote:
>> >> On Fri, 27 Nov 2015 06:42:21 -0500
>> >> Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
>> >>> On Fri, Nov 27, 2015 at 5:35 AM, Rostislav Pehlivanov
>> >>> <atomnuker at gmail.com> wrote:
>> >>> > LGTM, but could you leave (just comment it out) the old code in there
>> >>> > so it's a little easier to follow?
>> >>> >> //ff_aac_pow2sf_tab[i] = pow(2, (i - POW_SF2_ZERO) / 4.0);
>> >>> >> //ff_aac_pow34sf_tab[i] = pow(ff_aac_pow2sf_tab[i], 3.0/4.0);
>> >>> >
>> >>> > The accuracy increase is always nice.
>> >>> Done and pushed. Thanks.
>> >>> BTW, do you or others think that the new performance figures are
>> >>> sufficient to justify getting rid of config_hardcoded_tables and
>> >>> associated ifdefry and C file here?
>> >> I think this would be a very good goal. I never understood why there
>> >> has to be both, and the complication caused by it is terrible.
>> > I definitely agree that the complication is terrible, experiencing it
>> > first hand with some patches currently under review. I was initially
>> > skeptical of the need for both myself, but am now neutral about it,
>> > see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183932.html
>> > for some links about the rationale for this thing and my own thoughts
>> > on it - I am sure a computer systems person can explain it far better.
>> > However, for this to be valid, at least some basic tests need to be
>> > done, e.g what is the library size before and after
>> > --enable-hardcoded-tables?
>> > The trouble is that at the moment packagers and other clients (vlc,
>> > mpv, chromium?) have generally followed the defaults, so if we move to
>> > "hardcoded by default", clients can and perhaps should accuse us of
>> > library bloat. I hence personally prefer doing it all at runtime, but
>> > it will likely lead to bikeshedding. Maybe we can actually use our new
>> > "developer committee" for a poll on this. A simple library size test
>> > should be revealing in this respect.
>> >> I'm not sure if dynamic generation was already the default, but in any
>> >> case the init call should be protected with ff_thread_once.
>> > Dynamic is in the sense that --enable-hardcoded-tables is not done by
>> > default. I got the numbers by running ffplay on some test file.
> Well, I meant switching each case that can be configured to either
> hardcoded or dynamic generation only, depending on its effect on file
Ok, good. Let us proceed with this one step at a time. Here, I guess
it really does not matter since the net size is ~ 3 kB. Nevertheless,
it seems unnecessary now to do it at compile time, so unless AAC
maintainers object, I will submit a patch to always do this at
More information about the ffmpeg-devel