[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization
Ramiro Ribeiro Polla
ramiro
Mon Jul 16 22:12:21 CEST 2007
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
More information about the ffmpeg-devel
mailing list