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

[Måns Rullgård]

Michael Niedermayer wrote:
> 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

The list would include only architectures known to implement IEE754.  At
the moment, this is all of the ones we support.

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

True, but anything set by configure could be used somewhere else in future.

-- 
M?ns Rullg?rd
mans at mansr.com