[MPlayer-dev-eng] [PATCH] liba52 float support

[D Richard Felker III]

On Tue, Feb 22, 2005 at 11:48:32AM -0600, Zoltan Hidvegi wrote:
> D Richard Felker III wrote:
> > Speed is important, but I'm confused as t owhy the code in liba52 is
> > faster. IMO it would be best if we could fix whatever is slow in
> > libaf...
> 
> I do not think you could do that.  When liba52 does the int
> conversion, it decodes the audio with a 384 bias, so the desult will
> fall into the interval [-383.0,+385.0] instead of [-1,+1].  And near
> 384 it just happens to be that when you load the float as an int, the
> least significant two bytes will the the int converted sample.  liba52
> will always add the secified bias, so using 0 bias will not save you
> time, and later, even if af_volume uses the same trick, it will still
> have to load the float, do a float addition, store the float and load
> it as an int.

Thanks for the explanation!

> liba52 also does the conversion in two steps: first it decodes into
> float with 384 bias, and stores the result.  Then it goes through that
> stored float sample and converts them to int using integer only
> operations as described above.  The problem is that the intermediate
> float sample is stored in 256 float blocks, where each block belongs
> to a channel, while lifaf expects the cannels interleaved, so it is
> costly to repackage the samples coming out of liba52 to the formt of
> libaf.  You may be able to streamline things but only if you also
> change liba52, you cannot just fix it in libaf.

It would be better to fix libaf not to expect interleaved samples,
which are generally stupid and painful to work with, just like for
video. "Planar" formats make a lot more sense.

Rich