[FFmpeg-devel] [PATCH 07/12] lpc: remove VLA in ff_lpc_compute_autocorr

Justin Ruggles justin.ruggles
Fri Jun 25 04:00:20 CEST 2010


M?ns Rullg?rd wrote:

> Justin Ruggles <justin.ruggles at gmail.com> writes:
> 
>> M?ns Rullg?rd wrote:
>>
>>> Justin Ruggles <justin.ruggles at gmail.com> writes:
>>>
>>>> M?ns Rullg?rd wrote:
>>>>
>>>>> Justin Ruggles <justin.ruggles at gmail.com> writes:
>>>>>
>>>>>> Mans Rullgard wrote:
>>>>>>
>>>>>>> ---
>>>>>>>  libavcodec/lpc.c |    4 +++-
>>>>>>>  1 files changed, 3 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>> looks fine to me.  But I think the sse2 version of this function also
>>>>>> has the same VLA.
>>>>> Yes, it does, as I noticed later.  Requiring dsputil functions to
>>>>> allocate unknown amounts of memory us generally a bad idea.  Can we
>>>>> think of a better solution?  Make the caller pass a scratch buffer?
>>>> Well, I am currently working on revising the autocorrelation function,
>>>> mainly for the ALS encoder.  I'm considering splitting out the
>>>> windowing+int32-to-double part into a separate function or set of
>>>> functions.  So maybe we can change the autocorrelation function to take
>>>> double* input, with constraints that it be aligned and that at least
>>>> [-lag] be accessible (with negative array values either already zero or
>>>> containing actual sample values).  This is important for ALS since
>>>> previous sample values need to be included in certain situations.
>>> That's all very well, but doesn't really address the issue of the
>>> dsputil function needing to allocate unbounded amounts of scratch
>>> memory.
>> If the input is changed to have those constraints, that temporary memory
>> wouldn't need to be allocated at all.
> 
> Even better.

Great.  I'm working on the window function part now.  I'll try to have
something ready to submit by the end of this weekend.

-Justin




More information about the ffmpeg-devel mailing list