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

Måns Rullgård mans
Thu Nov 20 12:54:18 CET 2008


Robert Swain wrote:
> 2008/11/20 M?ns Rullg?rd <mans at mansr.com>:
>>
>> 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.
>
> One would assume there's some sort of IEEE754 compliance test
> somewhere by now. Is there? If all the archs we support, then could we
> rely on regressions for some codecs or whatever that mandate IEEE754
> to tell us about issues on other architectures?

In the interest of performance, IEEE754 deliberately leaves certain
aspects open.  The differences we've encountered are, AFAIK, within
the spec.

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




More information about the ffmpeg-devel mailing list