[FFmpeg-devel] [PATCH] QCELP decoder
Michael Niedermayer
michaelni
Fri Nov 21 12:26:22 CET 2008
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>
More information about the ffmpeg-devel
mailing list