[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization

[Ramiro Ribeiro Polla]

Hello,

Marc Hoffman wrote:
> On 7/15/07, Benjamin Larsson <banan at ludd.ltu.se> wrote:
>   
>> Marc Hoffman wrote:
>>     
>>> On 7/15/07, Benjamin Larsson <banan at ludd.ltu.se> wrote:
>>>       
>>>> Marc Hoffman wrote:
>>>>         
>>>>> This patch changes the way the data flows by introducing a vec_t data
>>>>> type which is just unsigned char. This way we can abstract the low
>>>>> level data type itself keeping the logic the same.  I'm using a char
>>>>> type so we can walk through the data this is not possible with voids
>>>>> to my knowledge. I have chosen to use vec_t so that we can easily
>>>>> locate the vectors which represent the input and output signals of the
>>>>> system.
>>>>>           
>>>> Ok, I don't know if this is the best way to do it, but I'll assume it
>>>>         
>> is
>>     
>>>> for now.
>>>>
>>>>         
>
>
> Ok now that we have decided on 32bit representation. I guess we need to
> eliminate the f_sample_size and just let the assumption that float is always
> 32 bits.  BTW is this always true?  I think for the class of machines we are
> talking about this is the case but we might want to use this on other
> machines as well.  I will adjust the code to remove q->f_sample_size and use
> sizeof (vec_t), where vec_t will be uint32_t if that makes it simpler.
> Please make a better suggestion if you have a better idea.
>
>
>
>   
>>>> I will then add a set of overloaded primitives to the existing
>>>>         
>>>>> structure that handle the lowlevel stuff like quantization, decouple,
>>>>> satruate, interpolate, and imlt etc that needs to know if your working
>>>>> with float or shorts.  I want to keep all the logic the same so I will
>>>>> also introduce a fixpoint fft which I'm in the process of developing
>>>>> under the ffmpeg license as GPL code.
>>>>>           
>>>> No chance for a LGPL license ? And if you need a reference fp fft to
>>>> look at use this:
>>>>         
>>>
>>> LGPL thats what I meant .
>>>       
>> Ok, nice. And if you have the time implement a split radix version with
>> 2, 3, 4 and 5 radixes. There will be a need for doing fft's with a size
>> of 640 when the siren codec is added to ffmpeg.
>>     
>
>
>
> Great! we would implement something like a 128 point followed by a 5 point
> to get a 640 point system.  If thats what you mean by a fix radix.
>
>   

I know I haven't mentioned this in the ML, and it's been quite a 
while... I got Siren (and therefore also g.722.1) working using 
fft-ref.c's mdct functions. I failed miserably on trying to make 
optimized functions. I even asked for help to a lot of people, but my 
math is not good enough yet to understand what I have to do.

I decided to postpone it to next year, after I (hopefully) finish 
calculus in university and can give it another try to make fast mdct 
functions.

Should I send this in for review with fft-ref's slow functions, so that 
they can be optimized by someone else or at some other time?

Ramiro Polla