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

[Michael Niedermayer]

On Fri, May 14, 2010 at 04:20:44PM +0100, M?ns Rullg?rd wrote:
> 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.

xvid and libvorbis are selected that way too.


> - 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.

3 AVCodecs
mp3
mp3float
mp3fixp

can very easily achive this, mp3 would just pass calls through to whatever
it determined to be faster.
no flag is needed for this, also it can easily be extended to handle external
decoders


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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20100517/5e642b77/attachment.pgp>