[Ffmpeg-cvslog] CVS: ffmpeg/libavcodec ac3enc.c, 1.31, 1.32 ac3tab.h, 1.7, 1.8

[Michael Niedermayer]

Hi

On Sun, Apr 23, 2006 at 03:26:38PM -0400, Justin Ruggles wrote:
> Michael Niedermayer wrote:
> > Hi
> > 
> > On Sun, Apr 23, 2006 at 02:23:20AM +0100, M?ns Rullg?rd wrote:
> > 
> >>Rich Felker <dalias at aerifal.cx> writes:
> >>
> >>
> >>>On Sat, Apr 22, 2006 at 11:37:28PM +0200, Michael Niedermayer wrote:
> >>>
> >>>>Hi
> >>>>
> >>>>On Sat, Apr 22, 2006 at 11:21:19PM +0200, Benjamin Larsson CVS wrote:
> >>>>
> >>>>>Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
> >>>>>In directory mail:/var2/tmp/cvs-serv11932/libavcodec
> >>>>>
> >>>>>Modified Files:
> >>>>>	ac3enc.c ac3tab.h 
> >>>>>Log Message:
> >>>>>Patch to generate the ac3 window, based on code by Justin Ruggles.
> >>>>
> >>>>btw, by how much does the binary get smaller due to this?
> >>>
> >>>I suspect it gets larger.. ;)
> >>
> >>Yes, ac3enc.o gets 40 bytes larger stripped.  Nothing that worries me,
> >>and this is done to avoid typos in the tables anyway, right?
> > 
> > 
> > its done to break the regression tests due to FPU rounding/optimization
> > differences ... yeah why didnt i realize this before ...
> 
> Is this way really much different than the way the sin & cos tables are
> generated?  Granted, there is a bit more adding and multiplying, but is
> any FPU *that* inaccurate?

it seems you dont understand, ANY error in the integer output is completely
inaceptable, so if any value prior to rounding to int is lets say 
123.49999999999876 or so then it doesnt need much error to flip it to *.5
this doesnt even need different FPUs just a different compiler or compiler
flags

as an example, the x86 fpu registers have 80bits so it makes a difference
if the compier decides to keep some variable in an register or on the stack
iam not sure what the standards say in relation to this but it really doesnt
matter, storing&loading everything after every operation just isnt an option
due to speed 


>  If you want to be that careful about using
> floating-point when you need bitexact-ness, why not hardcode the sin &
> cos tables as well?

yes, or generate them with fixedpoint code


> 
> The binary size is a good reason to revert though, unless, like Benjamin
> said, the code is put somewhere it can be reused by other codecs.

yes ...

anyway this isnt a big issue, we can leave it as it is until something
actually breaks ...

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is