[FFmpeg-devel] Float vs. fixed-point audio codecs

Måns Rullgård mans
Fri May 14 17:20:44 CEST 2010

With the addition of Michael's floating-point MPEG audio decoder this
week, we have, for the first time, both float and fixed-point
implementations of a codec.  Having both is a good thing, since which
one is faster depends on the CPU.  This presents us with several new
problems to solve and decisions to make.

Please add your thoughts on this, particularly if there's something
important I've overlooked.  If we can agree on an approach, I'll try
to put some patches together as soon as possible.

Choice of codec
With two implementations available, we must provide a good way of
choosing which one to use.  The code currently in svn simply registers
two instances of each decoder under different names, mp3 and mp3float
for the MP3 decoders.  By default, whichever is registered first will
take priority (currently the fixed-point version).  The user can
override this with an explicit -acodec mp3float on the command line.
If either version is disabled at compile-time, the other is
automatically selected.

This situation is undesirable for several reasons:

- Implementation details should not be reflected in codec names as
  used on the command line.
- No effort is made to automatically choose the best option.
- Build-time configuration can change the command line options
  required to select the MP3 decoder.

A good solution should use a single name on the command line and
choose between float and fixed-point internally.  Naturally, the
fastest alternative should be automatically chosen to the greatest
extent possible, and therein lies the difficulty.  Systems we care
about can be broadly divided into three categories:

1. No hardware FPU
2. Slow FPU
3. Fast FPU

Systems of the first type, those lacking a hardware FPU, are known at
build time; here we can simply disable the float version.

A functional but slow FPU is harder to detect.  In some cases, a --cpu
configure option is enough, and we can disable the float code based on
this.  In other cases, runtime detection may be possible.

Finally, when configuring for a target known to have a fast FPU, the
float version can be enabled by default, possibly even disabling the
fixed-point code entirely.

In all of the above cases it may be desirable to enable both versions,
even if one is faster, letting the user choose.  This brings us to the
question of how to choose implementation in the API as well as on the
command line.  One possibility is to introduce a flag which when set
causes the float version to be chosen, the default depending on
configure options.  Whatever the default, the flag could be set or
cleared from the command line.

Regression tests currently depend on decoder output being bitexact
across all supported targets.  Unfortunately, this is not the case for
the floating point MP3 decoder, so until a scheme is devised allowing
testing of inexact decoders, we will have no choice but to test only
the fixed-point version.  This of course means it will have to be
enabled for testing to be possible.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list