Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ SSE warning in 1.7.0

Many of you have reported a warning like this showing up in the experimental 1.7.0 release:

[E] Internal error: SSE state was bad before entry to external code at
    (.sourcew32videocodecpack.cpp:670). This indicates an uncaught bug
    either in an external driver or in VirtualDub itself that could cause
    application instability.  Please report this problem to the author!
    (MXCSR = 00009fc0)

In all of the cases I've seen, this warning is harmless and can be ignored. I'll be tweaking the codebase in 1.7.1 to prevent these from appearing in such circumstances.

From what I can tell, the reason for the warnings is that modules compiled with Intel C/C++ with fast math optimizations enabled causes the runtime to flip the Flush to Zero (FTZ) and Denormals are Zero (DAZ) bits on in the CPU's SSE control register. SSE stands for Streaming SIMD Extensions and refers to a streamlined vector math instruction set added starting with the Intel Pentium III and AMD Athlon XP CPUs. In my opinion, the runtime really shouldn't be flipping these settings, because those settings affect math precision in other code running in the thread, and I'm pretty sure it's against the Win32 calling convention to call external code with those bits set. It's definitely against the Windows x64 calling convention, which explicitly defines them as part of nonvolatile state and as normally disabled. Nevertheless, it appears that there are several video codecs and video filters that are compiled in this manner, and thus trip the problem.

The reason I added this check in 1.7.0 is due to an additional vulnerability that I gained when moving to Visual Studio 2005, which is sensitivity to SSE math settings. There has always been a problem with third-party DLLs screwing around with x87 floating point state, like changing precision and unmasking exceptions, which causes all sorts of mayhem such as crashes and calculations going haywire. For this reason, VirtualDub monitors the x87 state in and out of all external calls to video codecs and filters, and fixes the x87 state whenever it detects a violation. However, it didn't check the SSE control register, because it didn't use any SSE math.

1.7.0 is different, however, because starting with Visual Studio .NET (2002), the C runtime library will use SSE2-optimized versions of math functions when possible, such as pow(). These implementations use sequences of primitive operations (add/multiply/etc.) instead of microcoded transcendental math instructions in the FPU. This is often faster, but an unfortunate side effect is that it can be a lot more inaccurate when the rounding mode in the FPU is inappropriately set. Shortly before shipping 1.7.0, I discovered that the resize video filter had a long-standing bug where it would switch the FPU from round-to-nearest-even to truncate, and not restore it properly. This was harmless in 1.6.x because the filter code auto-fixed the x87 state, but in Visual Studio 2005 the _control87() function also changes the SSE state. As a result, the levels filter started showing speckling errors which I tracked down a bizarre result of something like pow(0.997, 0.998) = 1.001, which in turn was caused by the bad rounding mode. Thus, after fixing the resize filter, I added code to check for and fix the analogous SSE violations. Unfortunately, I didn't have a video filters or codecs installed that were compiled with Intel C/C++ aggressive optimization settings, so I missed the warning problem. There was also a bug in the startup code which caused the SSE check to be enabled too late, so any video filters which tripped this problem showed up as an internal error instead of properly tagging the violator.

FTZ (flush-to-zero) and DAZ (denormals-are-zero) are flags which, when set, tell the FPU to allow slight violations of IEEE math rules for faster speed. The numbers in question are denormals, which are really tiny numbers that are so small that they are missing the leading 1 bit normally implicit in IEEE-encoded floating point numbers; for a float, these are smaller in magnitude than about 5.8*10^-39. The FPU normally handles these special cases by grinding the pipeline to a halt and executing special microcode. Most applications won't need the additional accuracy provided by denormals, though, so setting these bits can increase performance slightly by reinterpreting the tiny numbers as zero. It's not that huge of a deal on the x86 architecture because microcoded execution is still hardware support, whereas on some RISC CPUs denormals actually cause a trap to a software emulation handler, which is thousands of times slower than the hardware unit.

The change in accuracy caused by enabling FTZ and DAZ is very minor compared to flipping precision or rounding modes; I was unable to find any computations not involving denormals which were affected by their absence. As a result, 1.7.1 will simply ignore those bits in the external code check.

Comments

Comments posted:


Uner 1.7.0 if I cut avay e.g 5 Minutes of "Werbung" then the Sound (mpg3) is not cutted but the produced result by direct stream copy is ok.

Manel Gasser - 03 12 06 - 11:24


Hahaha, I imediately understood what the problem was.
But maybe you should leave the check on (together with some explanations for lamers, and, perhaps, with some option to supress the warning) to make the developers of such codecs aware of the problem with saving and restoring the FPU/SSE registers.
E.g. I encountered this problem when using the XviD codec from K-Lite Mega Codec Pack v1.61 (1.2.0-dev, or something like that). The latest build from Koepi, 1.1.2 is already O.K.

Muad'Dib - 25 12 06 - 11:57


First off, huge thanks to the devs of VirtualDub! I thought it was dead when VirtualDubMod was being released, but obviously not :D~

Secondly, thx for your tip Muad'Dib! I didn't realize that this error only occurred on my PC when working with XviD format files (seeing as XviD / DivX / etc are all labelled .AVI extensions). I just updated from the K-Lite Mega Codec Pack v1.61 (this did not occur in any versions prior to v1.60) to the K-Lite Mega Codec Pack v1.63 and the error is gone :D!

I am now error free and extremely happy with VirtualDub! This program totally rocks!

Thanks again all, especially you Devs! Keep up the hard work :D!

Jonathan Bruneau (link) - 09 01 07 - 22:18

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.