[FFmpeg-devel] [PATCH] QCELP decoder

[Kenan Gillet]

On Nov 21, 2008, at 3:26 AM, Michael Niedermayer wrote:

> 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
>
> ?

101.mov: audio mismatchs from previous build
     stddev:    0.02 PSNR: 78.92 bytes:   250284/   250284

V6_text.mov: audio mismatchs from previous build
     stddev:    0.50 PSNR: 54.00 bytes: 11371244/ 11371244

blue_earth.mov: audio mismatchs from previous build
     stddev:    0.40 PSNR: 55.92 bytes: 19681324/ 19681324

codeblue-interrupt01.mov: audio mismatchs from previous build
     stddev:    0.02 PSNR: 79.21 bytes:   276524/   276524

codeblue-interrupt06.mov: audio mismatchs from previous build
     stddev:    0.31 PSNR: 58.03 bytes:   642924/   642924

codeblue-plot08motor.mov: audio mismatchs from previous build
     stddev:    0.29 PSNR: 58.81 bytes:  1534764/  1534764

h263.mov: audio mismatchs from previous build
     stddev:    0.46 PSNR: 54.85 bytes: 13511404/ 13511404

h263.trashed.mov: audio mismatchs from previous build
     stddev:    0.46 PSNR: 54.85 bytes: 13511404/ 13511404

installfect_export.mov: audio mismatchs from previous build
     stddev:    1.19 PSNR: 46.60 bytes: 10448044/ 10448044

oldepisode.mov: audio mismatchs from previous build
     stddev:    1.09 PSNR: 47.35 bytes:  4588844/  4588844

schlangenmannliten.mov: audio mismatchs from previous build
     stddev:    0.28 PSNR: 59.01 bytes:  8820844/  8820844

surge-1-16-B-Qclp.mov: audio mismatchs from previous build
     stddev:    1.52 PSNR: 44.48 bytes:  1156524/  1156524

8fe3b9dcd6d7e6db3375521c5c1b_Video_041606_002.3g2: audio mismatchs  
from previous build
     stddev:    0.02 PSNR: 78.98 bytes:   721004/   721004

Test3gpp-mp4a.3g2: audio mismatchs from previous build
     stddev:    0.01 PSNR: 90.74 bytes:   219244/   219244

c8wwz2m0.3g2: audio mismatchs from previous build
     stddev:    0.00 PSNR: 91.54 bytes:   241964/   241964

qtaudio-qcelp-problem.3g2: audio mismatchs from previous build
     stddev:    0.02 PSNR: 80.33 bytes:   208044/   208044

test.3g2: audio same as previous build

tube.3g2: audio mismatchs from previous build
     stddev:    0.00 PSNR: 98.65 bytes:   113004/   113004

zg3dx2d6.3g2: audio mismatchs from previous build
     stddev:    0.36 PSNR: 56.84 bytes:   486444/   486444

vidoo_MP4_audio_Qcelp13k.k3g: audio mismatchs from previous build
     stddev:    0.41 PSNR: 55.68 bytes:   743724/   743724


>
> 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?

they have a requirement for qcelp_lspvq1 ... qcelp_lspvq5:
in (2.4.3.2.6.3-1)

x(int) = round (x(float) * pow(2, 14)) / pow(2, 14);

but I am not sure it applies here