[FFmpeg-devel] [PATCH] QCELP decoder

[Michael Niedermayer]

On Thu, Nov 20, 2008 at 05:51:22PM -0800, Kenan Gillet wrote:
> Hi,
> On Nov 20, 2008, at 5:08 PM, Michael Niedermayer wrote:
> 
> >>>
> >>>
> >>> [...]
> >>>> +/**
> >>>> + * Computes the Pa or Qa coefficients needed for LSP to LPC  
> >>>> conversion.
> >>>> + * We only need to calculate the 6 first elements of the  
> >>>> polynomial.
> >>>> + *
> >>>> + * @param lspf line spectral pair frequencies
> >>>> + * @param v_poly polynomial input/output as a vector
> >>>> + *
> >>>> + * TIA/EIA/IS-733 2.4.3.3.5-1/2
> >>>> + */
> >>>> +static void lsp2poly(const float *lspf,
> >>>> +                     float *v_poly) {
> >>>> +    float val, *v;
> >>>> +    int   i;
> >>>> +
> >>>> +    // optimization to simplify calculation in loop
> >>>> +    v_poly++;
> >>>> +
> >>>> +    for (i = 0; i < 10; i += 2) {
> >>>> +        val = -2 * cos(M_PI * *lspf);
> >>>> +        lspf += 2;
> >>>> +        v = v_poly + FFMIN(4, i);
> >>>> +
> >>>> +        if (i < 4) {
> >>>> +            v[2] = v[0];
> >>>> +            v[1] = v[0] * val + v[-1];
> >>>> +        }
> >>>> +        for ( ; v > v_poly; v--)
> >>>> +            v[0] = v[0]
> >>>> +                 + v[-1] * val
> >>>> +                 + v[-2];
> >>>> +        v[0] += v[-1] * val;
> >>>> +    }
> >>>> +}
> >>>> +
> >>>> +/**
> >>>> + * Reconstructs LPC coefficients from the line spectral pair  
> >>>> frequencies
> >>>> + * and performs bandwidth expansion.
> >>>> + *
> >>>> + * @param lspf line spectral pair frequencies
> >>>> + * @param lpc linear predictive coding coefficients
> >>>> + *
> >>>> + * @note: bandwith_expansion_coeff could be precalculated into a  
> >>>> table
> >>>> + *        but it seems to be slower on x86
> >>>> + *
> >>>> + * TIA/EIA/IS-733 2.4.3.3.5
> >>>> + */
> >>>> +void qcelp_lspf2lpc(const float *lspf,
> >>>> +                    float *lpc) {
> >>>> +    float pa[6], qa[6];
> >>>> +    int   i;
> >>>> +    float bandwith_expansion_coeff = - 
> >>>> QCELP_BANDWITH_EXPANSION_COEFF;
> >>>> +
> >>>
> >>>> +    pa[0] = 0.5;
> >>>> +    pa[1] = 0.5;
> >>>> +    lsp2poly(lspf, pa);
> >>>> +
> >>>> +    qa[0] = 0.5;
> >>>> +    qa[1] = -0.5;
> >>>> +    lsp2poly(lspf + 1, qa);
> >>>
> >>> it should be faster to deal with 0.5 + 0.5x / 0.5 - 0.5x after  
> >>> building
> >>> the polynomials
> >>
> >> done
> >>
> >>
> >>>
> >>> anyway, see ff_acelp_lsp2lpc
> >>
> >> done, it is globally ~10% faster.
> >>
> >> but it gives some significant difference in the WAV output.
> >> I doule check, and it seems to come from the float rounding :(
> >> here is the list of result of 'tiny_psnr old.wav new.wav'.
> >
> > what happens with double instead of float?
> 
> with keeping the signature of qcelp_lspf2lpc(float *, float *)
> and changing all the calculation into double for
> the code before and after optimization:

hmm
        old vs. new
float    ~3  -5 stddev
double   ~0.5-1 stddev

it seems this code is rather sensitive to rounding

how do the differences look for
        float vs. double 
new
old

?

Iam asking because at this point we dont know if old or new is more
sensitive.

And i suspect the spec has no requirement for rounding to 32bit IEEE floats?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081121/81fcc0f9/attachment.pgp>