Re: [Opensg-users] OpenSG1.8 - Possible interference with ffmpeg/libav

[Michael R. <mic...@gm...>]

Hi Carsten, Hi all,

I managed to solve that issue. It was not a problem of OpenSG. 
It proved to be a bad idea to build ffmpeg with msvc10 x64 compiler. Seems to generate some corrupted code which leads to problems in double operations (e.g. sin()). Building with mingw64 works fine!

Thanks,
Michael

-------- Original-Nachricht --------
> Datum: Fri, 07 Dec 2012 09:40:36 -0600
> Von: Carsten Neumann <car...@gm...>
> An: ope...@li...
> Betreff: Re: [Opensg-users] OpenSG1.8 - Possible interference with	ffmpeg/libav

> 	Hello Michael,
> 
> sorry for the delay, i was out of the office for a conference.
> 
> On 12/03/2012 08:46 AM, Michael Raab wrote:
> > our OpenSG-based application uses ffmpeg to encode captured image
> sequences to generate some nice videos. Since switching from an old libav version
> (2011) to the recent build we investigated some emtpy frames when
> capturing some camera movement.
> > After some research on that found that whenever we got invalid/empty
> frames, the calculated/interpolated camera transformation was invalid
> (contained some -1.IND values in rotation section). After digging deeper the
> problem seems to be that in Quaternion.slerp() a call to sin() returns these
> -1.IND values.
> > When animating the camera without capturing and encoding the frames
> afterwards everything seems to run fine. I already asked on the ffmpeg mailing
> list but they also seem to have no clue.
> >
> > Anyone who has an idea why sin() may return -1.IND for a valid input
> value?
> 
> unfortunately no; to be honest I'm not even sure what -1.IND is meant to 
> indicate, AFAIK float has +/-INF and quiet/signalling NaN as special 
> "not-really-a-number" values.
> What is the input that produces such a value? Is it a very large value 
> and you are perhaps running into a precision problem in the sin() 
> implementation? In that case you could try mapping your input value to 
> [0, 2*PI] before passing it to sin().
> Another thought: does ffmpeg modify rounding modes or the trapping state 
> of floating point operations? Not sure how that would cause something 
> relatively straightforward as sin() to stop working, but still...
> 
> 	Cheers,
> 		Carsten
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Opensg-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensg-users