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

[Alex Converse]

On Thu, Nov 20, 2008 at 6:29 AM, M?ns Rullg?rd <mans at mansr.com> wrote:
>
> 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.
>

Remember we aren't just looking for archs that support IEEE754, we're
looking for ones where this code is faster. It's very possible that
some architecture might have a huge penalty for punning bitstrings
from the FPU to the ALU and vice-versa.

[...]

--Alex Converse