[FFmpeg-devel] [PATCH 02/14] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/5]
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
>> 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
>> 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
>> >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
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.
More information about the ffmpeg-devel