[FFmpeg-devel] [PATCH] Implement AAC Long Term Prediction (LTP) decoding module

Alex Converse alex.converse
Mon Feb 14 09:37:14 CET 2011


On Mon, Feb 14, 2011 at 12:15 AM, Young Han Lee <cpumaker at gmail.com> wrote:
> On Mon, Feb 14, 2011 at 4:55 PM, Rob <robert.swain at gmail.com> wrote:
>
>> On 14 February 2011 02:27, Young Han Lee <cpumaker at gmail.com> wrote:
>> > On Mon, Feb 14, 2011 at 6:46 AM, Alex Converse <alex.converse at gmail.com
>> >wrote:
>> >
>> >> On Sun, Feb 13, 2011 at 5:56 AM, Young Han Lee <cpumaker at gmail.com>
>> wrote:
>> >> >
>> >> > any comment about this?
>> >>
>> >> It looks good, one last thought
>> >>
>> >> +static void windowing_and_mdct_ltp(AACContext *ac, float *out,
>> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? float *in, IndividualChannelStream
>> >> *ics)
>> >> +{
>> >> + ? ?const float * lwindow ? ? ?= ics->use_kb_window[0] ?
>> >> ff_aac_kbd_long_1024 : ff_sine_1024;
>> >> + ? ?const float * swindow ? ? ?= ics->use_kb_window[0] ?
>> >> ff_aac_kbd_short_128 : ff_sine_128;
>> >> + ? ?const float * lwindow_prev = ics->use_kb_window[1] ?
>> >> ff_aac_kbd_long_1024 : ff_sine_1024;
>> >> + ? ?const float * swindow_prev = ics->use_kb_window[1] ?
>> >> ff_aac_kbd_short_128 : ff_sine_128;
>> >> + ? ?float * buf = ac->buf_mdct;
>> >>
>> >> buf is the same as in should lets just drop buf and call it in.
>> >>
>> >>
>> > Is it just use the "ac->buf_mdct" instead of "*buf"
>> > If yes, I'll change the rest of "*buf".
>>
>> In apply_ltp(), predTime is ac->buf_mdct. predTime is pass to
>> windowing_and_mdct_ltp() as the 'in' argument. Within
>> windowing_and_mdct_ltp() you also made another variable called buf
>> that points to ac->buf_mdct. As buf == 'in', buf is redundant and it
>> would be clearer if 'in' were used for both throughout the function.
>> e.g.
>>
>> + ? ? ? ?ac->dsp.vector_fmul(ac->buf_mdct, in, lwindow_prev, 1024);
>>
>> could be
>>
>> + ? ? ? ?ac->dsp.vector_fmul(in, in, lwindow_prev, 1024);
>>
>> as in == ac->buf_mdct and this change makes it clearer tot he reader
>> that they are the same.
>>
>> Regards,
>> Rob
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>>
>
> I misunderstood it.
> now I fix it.
>

Thank you.

In revision 9 "ret" shrunk from 2048 to 1024? Ret needs to be 2048
samples long for SBR. Was the shrinkage intentional?

Also please submit a patch with git format-patch so I can push this to git :)

If you are unfamiliar with git format patch it works like this

$ git add {changed files}
$ git commit
you will be prompted to write a brief commit message
$ git format-patch origin

then attach the output patch file to this e-mail.

Thanks,
Alex



More information about the ffmpeg-devel mailing list