[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization
Sun Jul 15 19:59:22 CEST 2007
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
>> Ok, I don't know if this is the best way to do it, but I'll assume it is
>> for now.
>>> 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.
> I guess you might be correct. Initially I was thinking we might be able to
> use 16-bit ints to represent the signal and not 32-bits. I'm still not sure
> if the implementation requires the higher precision to be maintained does
> anyone know if the algorithm requires the 24bits?
Well what I meant was that I don't think 16 bits is enough for the
transform step to keep a good enough precision. So if 32 bits is needed
in the transform step then why not use 32bits in all the calculations
More information about the ffmpeg-devel