[FFmpeg-devel] [PATCH 02/14] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/5]

Nedeljko Babic Nedeljko.Babic at imgtec.com
Fri Oct 10 15:49:12 CEST 2014


>On Thu, Oct 09, 2014 at 12:02:26PM +0000, Nedeljko Babic wrote:
>> >
>> >softfloat uses "if (a.mant + 0x40000000 < 0)" to normalize
>> >0x40000000U + 0x40000000U is < 0 for int32 and thus not part of the
>> >range though -1 would be, is that a problem ?
>> >we could use a.mant + 0x40000000 <= 0 in that case
>> >
>> >the main difference i see to aac is that it shifts up if its too small
>> >while softfloat shift down when its too large
>>
>> The main problem is exactly in difference of handling too large and too small
>> values.
>> If we must use code from softfloat as is, it will demand a lot of changes in
>> aac implementation.
>>
>> And there are other problems with softfloat:
>> - Normalization done for av_add_sf (and av_sub_sf), av_normalize1_sf, is not ok.
>>   It's the same normalization used in multiplication and it will not handle
>>   normalization of mantissa and exponent correctly after addition.
>>   On the other hand, av_normalize_sf can not be used as is since it would have
>>   infinite loop for a.mant == 0.
>> - I guess we would have a problem with av_div_sf since it needs for b to be
>>   normalized and it doesn't handle division by zero (also I am not sure about
>>   precision).
>>
>> We need functions that are implemented just in our emulation (like sincos
>> for example) and not in softfloat and I guess (but am not sure atm) that some
>> of them would also need to be changed if we need to use assumptions from
>> softfloat.
>>
>> >
>> >both dont implement rounding correctly
>>
>> We use this rounding for simplicity. On our test cases we do not have
>> significant problems with it (overall max 3 bit difference with floating
>> point code), although we can change it if it proves to be necessary.
>>
>
>> My question still remains: should we use our float emulation and just
>> integrate it in softfloat adjusting it where necessary, or should we use
>> softfloat and adjust our aac implementation?
>
>its ok to integrate your code in sf / change sf as long as it doesnt
>remove optimizations or make future optimizations hard
>
>thanks

Ok. 

I'll will then recreate this patch and I'm thinking of rebasing all the patches 
since I see there were some changes that affect our implementation.

I will resend entire patch set for review afterwards.

Thanks

-Nedeljko


More information about the ffmpeg-devel mailing list