[FFmpeg-devel] AAC-Main (round 2)

Michael Niedermayer michaelni
Thu Nov 20 12:09:34 CET 2008


On Thu, Nov 20, 2008 at 10:51:28AM -0000, M?ns Rullg?rd wrote:
> 
> Michael Niedermayer wrote:
> > On Thu, Nov 20, 2008 at 10:25:51AM -0000, M?ns Rullg?rd wrote:
> >>
> >> Michael Niedermayer wrote:
> >> > On Wed, Nov 19, 2008 at 01:42:55PM -0500, Alex Converse wrote:
> >> > [...]
> >> >> diff --git a/libavcodec/aac.c b/libavcodec/aac.c
> >> >> index 1ad0a58..9fb242b 100644
> >> >> --- a/libavcodec/aac.c
> >> >> +++ b/libavcodec/aac.c
> >> >> @@ -91,6 +91,11 @@
> >> >>  #include <math.h>
> >> >>  #include <string.h>
> >> >>
> >> >> +#ifdef ARCH_X86
> >> >> +#define USE_754_PUNS
> >> >> +union float754 { float f; uint32_t i; };
> >> >> +#endif
> >> >
> >> > The correctness of the USE_754_PUNS code could be tested by configure
> >>
> >> Not easily.  The best we could do is set it based on architecture.
> >
> > hmm, is there a problem i miss with just compiling a
> > float a[]= {1.23456789, PI, E, -23.456789}
> > and checking if the IEEE expected byte sequence (for matching integer
> > endianness) is in the object file?
> 
> That's checking 4 out of 4 billion possible float values.  Even if these
> look like IEEE754 numbers, there could be differences elsewhere, e.g.
> in the representation non-finite numbers.  Floating-point is weird enough
> that I wouldn't trust a simple check like that.

A hand written list of archs wont be based on checking 4 billion values
each either. Nor would i completely trust a claim of manufactur X about their
cpus being Y compliant

Besides AFAIK the AAC code is just doing a little rounding of simple
numbers so infs and nans shouldnt matter for it.

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

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- 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/20081120/94e7c596/attachment.pgp>



More information about the ffmpeg-devel mailing list