[FFmpeg-devel] [PATCH] AAC decoder

Robert Swain robert.swain
Sat Jun 7 04:09:13 CEST 2008


2008/6/7 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Jun 06, 2008 at 02:11:13PM +0100, Robert Swain wrote:
>> 2008/4/2 Michael Niedermayer <michaelni at gmx.at>:
>> > On Tue, Apr 01, 2008 at 04:56:48PM +0200, Andreas ?man wrote:
>> >> Andreas ?man wrote:
>> >> +static void window_trans(AACContext * ac, sce_struct * sce) {
>> >> +    ics_struct * ics = &sce->ics;
>> >> +    float * in = sce->coeffs;
>> >> +    float * out = sce->ret;
>> >> +    float * saved = sce->saved;
>> >> +    const float * lwindow      = ics->window_shape      ? ac->kbd_long_1024 : ac->sine_long_1024;
>> >> +    const float * swindow      = ics->window_shape      ? ac->kbd_short_128 : ac->sine_short_128;
>> >> +    const float * lwindow_prev = ics->window_shape_prev ? ac->kbd_long_1024 : ac->sine_long_1024;
>> >> +    const float * swindow_prev = ics->window_shape_prev ? ac->kbd_short_128 : ac->sine_short_128;
>> >> +    float * buf = ac->buf_mdct;
>> >> +    int i;
>> >> +
>> >> +    if (ics->window_sequence != EIGHT_SHORT_SEQUENCE) {
>> >> +        ff_imdct_calc(&ac->mdct, buf, in, out); // out can be abused for now as a temp buffer
>> >> +        if (ac->is_saved) {
>> >> +            if (ics->window_sequence != LONG_STOP_SEQUENCE) {
>> >> +                ac->dsp.vector_fmul_add_add(out, buf, lwindow_prev, saved, ac->add_bias, 1024, 1);
>> >> +            } else {
>> >
>> >> +                for (i = 0; i < 448; i++) out[i] = saved[i] + ac->add_bias;
>> >> +                for (i = 448; i < 576; i++) buf[i] *= 0.125; // normalize
>> >> +                ac->dsp.vector_fmul_add_add(out + 448, buf + 448, swindow_prev, saved + 448, ac->add_bias, 128, 1);
>> >> +                for (i = 576; i < 1024; i++)   out[i] = buf[i] + saved[i] + ac->add_bias;
>> >> +            }
>> >> +        }
>> >> +        if (ics->window_sequence != LONG_START_SEQUENCE) {
>> >> +            ac->dsp.vector_fmul_reverse(saved, buf + 1024, lwindow, 1024);
>> >> +        } else {
>> >> +            memcpy(saved, buf + 1024, 448 * sizeof(float));
>> >> +            for (i = 448; i < 576; i++) buf[i + 1024] *= 0.125; // normalize
>> >> +            ac->dsp.vector_fmul_reverse(saved + 448, buf + 1024 + 448, swindow, 128);
>> >> +            memset(saved + 576, 0, 448 * sizeof(float));
>> >
>> > thats alot of copying around, cant that be avoided?
>>
>> I don't think the memset() can be avoided. I think that maybe with a
>> larger buffer and some pointer swapping that memcpy() can be but the
>> one a little further down in the function cannot. I'll work on a patch
>> for the pointer swapping idea unless you have any better suggestion.
>
> I dont remember what i had in mind when i wrote that comment ...

I started on the two buffer and swap pointers idea but I don't really
like it now I've begun. It just seems a bit messy though maybe I'm
mostly averse to it because I'd need two float array[2048] in each
single channel element to do it I think.

> Anyway something unrelated, the output of our imdct() is 50% redundant aka
> identical (iam mentioning that because that is not optimal speedwise and
> iam still searching for a volunteer to clean that up) ... the more often
> i mention it the more likely someone will fix it ;)

Well maybe I will look at this as it would reduce buf to 1024 rather
than 2048 floats which would then make me feel better about the
abovementioned idea. If you have some hints as to what needs doing
that would speed my progress on such, throw them my way.

Apart from one chunk of code which looked exploitable which needs
tending to, I expect to submit the code for another full review when
the channel elements patch has been OKed and committed. I feel the AAC
code is reaching a good level of cleanliness and I shall commence
plugging in the SBR code locally very soon. :) I'd still like to get
AAC into trunk as soon as possible.

>> Also, ping on the fairly large patch refactoring the channel elements
>> that I sent at the beginning of the week. :)
>
> many patches, many flames, too little time ...

Cease the flaming and spend the time on FFmpeg. ;)

Rob



More information about the ffmpeg-devel mailing list