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

[Michael Niedermayer]

On Wed, Oct 08, 2014 at 09:46:56AM +0000, Nedeljko Babic wrote:
> Hi again,
> 
> >> but I do agree that it is more maintainable to have one float emulation and I
> >> am willing to integrate our emulation in softfloat.
> >> 
> >> However, there is a difference in some conventions used (for example is it more
> >> important to represent exactly 0.5 or 1, order of fields in struct that
> >> represents emulated float, etc.) and our aac implementation is tailored to use
> >> our float emulation.
> >
> >i dont understand what you mean by 0.5 vs 1 ?
> >floats are base 2 so both 0.5 and 1 can be represented exactly
> >
> 
> I was a little unclear here, sorry.
> 
> It is true that both 0.5 and 1 can be represented exactly.
> 
> I was referring to a range of normalized mantissas.
>  
> We are using [0.5 - 1) and softfloat uses different range.
> We do not have 1 in our range.
> 
> Please look at difference between av_normalize1_sf that is used in softfloat
> version of mul and normalization used in our float_mul for example.

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

both dont implement rounding correctly


>
> If we need to use range from softfloat, all calculations in aac fixed point 
> implementation that depend on it need to be changed, so I am in favor of using
> our range (of course :)), especially since softfloat is not being used anywhere
> currently and changing the range of mantissas in it would not cause any
> disturbance in ffmpeg.
> 
> - Nedeljko
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- 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/20141008/ce9b4aed/attachment.asc>