[FFmpeg-devel] [PATCH] Implement AAC Long Term Prediction (LTP) decoding module
Young Han Lee
Fri Feb 11 02:46:58 CET 2011
On Thu, Feb 10, 2011 at 6:05 PM, Rob <robert.swain at gmail.com> wrote:
> On 10 February 2011 09:46, Rob <robert.swain at gmail.com> wrote:
> > On 10 February 2011 06:23, Alex Converse <alex.converse at gmail.com>
> >> This version looks good.
> >> Does anyone else have comments?
> > I'll have a look over it shortly.
> My only concerns are that the expansion/addition of data arrays is
> significant. There's a 1024 element float array, a 3072 element
> int16_t array and an additional 1024 elements in another float array.
> I'm not saying that this needs to block merging, but if there is a way
> to improve it, perhaps we can add some comments as to how.
one of 1024 element float array (saved_ltp) is merged.
I'm thinking about how to merge the rest of additional data arrays
but I don't have good idea right now.
And the "ret" data array is reduced to 1024.
I think it could be missed when the imdct_half was implemented.
please check this out.
Is the int16_t array really needed? We output float anyway don't we so
> perhaps there is a way to translate the method to use float all the
> way through. I seem to remember when I switched to using imdct_half
> and vector_fmul I was able to reduce the array sizes somewhat. Is
> there any possibility of this for this ltp code? Things like that.
In the MPEG document, "short" type was recommended but,
it is not a big problem to change the type to float.
However, the array size will be double.
Do I change to float or not?
I'll consider about the possibility of method you used.
but it needs time :).
Generally, the code looks very neat and gets the OK from me as long as
> it has been tested with relevant clips and works. :) Good job!
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 14298 bytes
Desc: not available
More information about the ffmpeg-devel