[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