[FFmpeg-devel] PATCH: COOK audio decode infastructure to support fixpoint optimization
Sun Jul 15 23:00:04 CEST 2007
On 7/15/07, Marc Hoffman <mmhoffm at gmail.com> wrote:
> On 7/15/07, Michael Niedermayer <michaelni at gmx.at> wrote:
> > Hi
> > On Sun, Jul 15, 2007 at 07:59:22PM +0200, Benjamin Larsson wrote:
> > [...]
> > > > 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
> > > for simplicity.
> > the general rule of thumb is that a n point decorrelation transform
> > needs
> > log2(n)/2 bits more for the values in the frequency domain than in the
> > time domain
> > so 16bit is definitly not enough if you have 16bit audio
> Agreed. so whats your take on 16bit phase factors?
However, you can scale each of the add subs, so that you lose some precision
to eliminate overflow and obtain reasonable results.
Something like this would lose log(n)-bits of precision for n point fft.
tr = (X[k2*2]*wwr - X[k2*2+1]*wwi + 0x4000)>>15;
ti = (X[k2*2]*wwi + X[k2*2+1]*wwr + 0x4000)>>15;
X[k2*2] = (X[k*2] - tr)>>1;
X[k2*2+1] = (X[k*2+1] - ti)>>1;
X[k*2] = (X[k*2] + tr)>>1;
X[k*2+1] = (X[k*2+1] + ti)>>1;
More information about the ffmpeg-devel