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

Robert Swain robert.swain
Mon Nov 24 01:17:40 CET 2008


2008/11/20 M?ns Rullg?rd <mans at mansr.com>:
> "Alex Converse" <alex.converse at gmail.com> writes:
>
>> 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.
>
> Good point.  I can think of a few such architectures.  If the values
> are in memory that's not an issue, of course.  I have yet to see a
> machine with separate memory banks for integers and floats.

So, what is the conclusion here? Is the current patch OK or do some
alterations need to be made to the ifdeffery?

Regards,
Rob



More information about the ffmpeg-devel mailing list