[FFmpeg-devel] Review request - ra288.{c,h} ra144.{c,h}

[Michael Niedermayer]

On Tue, Aug 05, 2008 at 06:45:03PM -0400, Justin Ruggles wrote:
> Justin Ruggles wrote:
> > Vitor Sessak wrote:
> >> Michael Niedermayer wrote:
> >>> On Tue, Jul 29, 2008 at 08:20:45PM +0200, Vitor Sessak wrote:
> >>>> Hi,
> >>>>
> >>>> Those four files never passed a review. I've just finished cleaning them 
> >>>> up, so if anyone wants to review them (Michael already said he will), 
> >>>> now is time.
> >>> heres 288
> >>>
> >>> [...]
> >>>> static void decode(RA288Context *ractx, float gain, int cb_coef)
> >> [...]
> >>
> >>>> /**
> >>>>  * Converts autocorrelation coefficients to LPC coefficients using the
> >>>>  * Levinson-Durbin algorithm. See blocks 37 and 50 of the G.728 specification.
> >>>>  *
> >>>>  * @return 0 if success, -1 if fail
> >>>>  */
> >>>> static int eval_lpc_coeffs(const float *in, float *tgt, int n)
> >>>> {
> >>>>     int i, j;
> >>>>     double f0, f1, f2;
> >>>>
> >>>>     if (in[n] == 0)
> >>>>         return -1;
> >>>>
> >>>>     if ((f0 = *in) <= 0)
> >>>>         return -1;
> >>>>
> >>>>     in--; // To avoid a -1 subtraction in the inner loop
> >>>>
> >>>>     for (i=1; i <= n; i++) {
> >>>>         f1 = in[i+1];
> >>>>
> >>>>         for (j=0; j < i - 1; j++)
> >>>>             f1 += in[i-j]*tgt[j];
> >>>>
> >>>>         tgt[i-1] = f2 = -f1/f0;
> >>>>         for (j=0; j < i >> 1; j++) {
> >>>>             float temp = tgt[j] + tgt[i-j-2]*f2;
> >>>>             tgt[i-j-2] += tgt[j]*f2;
> >>>>             tgt[j] = temp;
> >>>>         }
> >>>>         if ((f0 += f1*f2) < 0)
> >>>>             return -1;
> >>>>     }
> >>>>
> >>>>     return 0;
> >>>> }
> >>> duplicate of compute_lpc_coefs() ?
> >> Yes, the two functions are practically identical, but 
> >> compute_lpc_coefs() use doubles and ra288 uses floats.
> >>
> >> Justin: does FLAC really need double precision or that was just an 
> >> arbitrary choice?
> > 
> > I know I ran some compression comparison tests at one point, and using
> > floats vs. doubles did negatively affect compression.  How much, I don't
> > remember.  I'll test again and post the results.  If it's not too bad,
> > I'm ok with changing to floats.
> 
> test of 5 concatenated samples.
> total playing time: 26m47s
> 
> system: athlon64 x2 6000+, linux, gcc 4.1.2
> 
> compression level 5:
> double  -- 6.224s -- 171183921
> no sse2 -- 6.600s -- 171183931
> float   -- 6.452s -- 171839999 = 0.4% larger
> 
> compression level 8:
> double  -- 13.385s -- 167634457
> no sse2 -- 13.981s -- 167634492
> float   -- 13.857s -- 168444919 = 0.4% larger
> 
> 
> I'm guessing that Loren's optimized functions could be adapted to use
> floats to give better results.

I think each variable and array should be one at a time be changed to
float and tested, the ones where there is no significant change in filesize
should be made float
and 0.1% being significant

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20080806/deb6c796/attachment.pgp>