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

[Zoltan Hidvegi]

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.

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.

Zoli