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

Nedeljko Babic Nedeljko.Babic at imgtec.com
Thu Oct 9 14:02:26 CEST 2014

```>
>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?

Btw, sorry for me replying on my posts instead on yours.
I have some problem receiving mails from this thread...

-Nedeljko
```