[FFmpeg-devel] AAC decoder round 5

Robert Swain robert.swain
Sat Aug 9 11:37:33 CEST 2008


2008/8/8 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Aug 08, 2008 at 07:59:35PM +0100, Robert Swain wrote:
>> 2008/8/8 Michael Niedermayer <michaelni at gmx.at>:
>> > On Fri, Aug 08, 2008 at 03:38:06PM +0100, Robert Swain wrote:
>> >> 2008/8/8 Robert Swain <robert.swain at gmail.com>:
>> >>
>> >> [...]
>> >>
>> >> > So, it seems the issue is not MAX_CHANNELS so much as the window group
>> >> > and scalefactor band arrays. I'm going to check the cases for maximum
>> >> > number of scalefactor bands per window group as I expect it may be
>> >> > beneficial to flatten these two indices.
>> >>
>> >> const uint8_t ff_aac_num_swb_1024[] = {
>> >>     41, 41, 47, 49, 49, 51, 47, 47, 43, 43, 43, 40
>> >> };
>> >>
>> >> const uint8_t ff_aac_num_swb_128[] = {
>> >>     12, 12, 12, 14, 14, 14, 15, 15, 15, 15, 15, 15
>> >> };
>> >>
>> >> For the long transform, there can only be 1 window group so the worst
>> >> case there is 51 scalefactor bands in total.
>> >>
>> >> For the short transform there can be up to 8 window groups (i.e. each
>> >> group containing only one short window) each with up to 15 scalefactor
>> >> bands, totalling 120 scalefactor bands maximum for this case.
>> >>
>> >> So, instead of [8][64] we could have [120] which is quite a bit better
>> >> but maybe it would obfuscate the code a lot, I'll ponder this now. At
>> >> the very least we can have [8][51]. :)
>> >
>> > [8][51].might lead to slow addressing of the contents due to *51 instead
>> > of <<6
>>
>> See attached.
>>
>> Reduces ChannelElement to 42672 from 80688 bytes, SingleChannelElement
>> to 16896 from 21600 bytes and ChannelCoupling to 8744 from 36968
>> bytes.
>
> great,patch ok

Applied.

Rob




More information about the ffmpeg-devel mailing list