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

[Michael Niedermayer]

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141009/b362385b/attachment.asc>