[FFmpeg-cvslog] r23095 - in trunk/libavcodec: Makefile allcodecs.c mpegaudio.h mpegaudio_tablegen.h mpegaudiodec.c mpegaudiodec_float.c

Reimar Döffinger Reimar.Doeffinger
Fri May 14 00:24:44 CEST 2010


On Thu, May 13, 2010 at 04:40:27PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Wed, May 12, 2010 at 09:27:43PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> 
> >> > Btw. going back to the original commit, what are your thoughts about an
> >> > "automp3" codec that automatically selects whichever codec should be faster
> >> > (could be compile-time for now)?
> >> 
> >> Compiling both doesn't really make much sense IMO.  I would suggest
> >> making float-only the default and providing configure option for
> >> switching to integer.  This could be done automatically for CPUs known
> >> to lack an FPU (or have a slow one).
> >
> > Well, compiling both makes testing and comparison benchmarks easier
> 
> Easier testing and comparing is not reason enough to bloat the build
> two copies of essentially the same code for everybody.

I think I agree in the long term, however at the moment it _might_
be beneficial if end-user can easily make that comparison, given how
far your and Michael's benchmark results seem to be apart.

> > and allows runtime-switching if we want to support devices where
> > which one is faster might depend on which CPU extensions are
> > available.
> 
> This is a valid point.  However, using different codec names is not a
> good way to achieve this.  We should have one AVCodec selecting the
> best implementation internally.

Fair enough, I guess I like too much having everything fine-tuneable.
However might that cause trouble for regression testing? I doubt the
float and integer versions are bit-exact, and currently the whole
testing infrastructure needs that...



More information about the ffmpeg-cvslog mailing list