Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
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 

§ Exploring hardware overlay support in Windows 7

I finally got around to trying out the new hardware overlay support in Windows 7:
http://msdn.microsoft.com/en-us/library/dd797814(VS.85).aspx

Hardware overlays are a quirk of video hardware that have survived in spite of their lack of evolution. They're essentially a secondary display scan out path in the video chip and are intended for video display, so that a video in a window can use a more optimized display format instead of the rest of the desktop for better playback performance. The biggest advantages of a hardware overlay are hardware accelerated scaling and color conversion from YCbCr to RGB, formerly very expensive operations; in some cases, you also got primitive deinterlacing and some additional TV-out support. Unfortunately, they were often also buggy in drivers. Windows Vista appeared to be the end of the line for overlays, as they were not supported in desktop composition mode, but guess what... they're back in Windows 7. As it turns out, hardware overlays are still valuable for a couple of reasons, one being that you can flip them faster and asynchronously from the composited desktop (good for performance) and because you can't capture their image in a screen grab operation (good for the paranoid). And this time, they have a few improvements, too.

The way you get to overlays is a bit different in Windows 7. In older versions, they were a feature of DirectDraw, and that meant you basically couldn't do anything other than lock-and-load -- DirectDraw couldn't even do color conversion, other than what the hardware overlay itself supported. This time, they're hooked up to Direct3D, which makes them a lot more useful since you can process video through DXVA and shader hardware and push the result into the overlay. The color space is now better defined, as there are flags for whether RGB output is computer RGB (0-255) or studio RGB (16-235), and whether YCbCr output is Rec.601/709 or xvYcc. So far, so good -- time to try it!

Now, it's not easy to get VirtualDub talking to the new overlays yet, for two reasons: the existing overlay code uses DirectDraw, and the Direct3D path only supports D3D9, whereas you need Direct3D9Ex in order to use the overlays. Therefore, I ended up just writing a one-off application to test it. Well, having gotten overlays to work and tested them a bit, I have to say they're a bit underwhelming. The good news:

Now, the bad news:

Disclaimer: I used Windows 7 RC for testing, since I don't have RTM.

So, what do we have at this point? Well, you can create a non-stretched RGB overlay with regular 0-255 range. That means unless you are either in a situation where you are being hampered by a low desktop composition rate or you need to prevent your image from being grabbed, it's unlikely that the overlay will have any advantages over plain blitting to the desktop. And of course, you need to use Direct3D9Ex to access them, which is juuuust different enough from regular Direct3D9 to be annoying. The situation might get better over time, and it may just be my crappy video card... but I'll wait until I actually see improvement.

If anyone wants to experiment with WDDM 1.1 overlays, here's the code I used to test them: d3doverlay.cpp. It's obviously not production code, but I assume if you're trying to build it you have some familiarity with setting up a project and with D3D9.

Comments

Comments posted:


The only place where I found overlay useful nowdays was a weak atom cpu + gma video. The box even had a broadcom hardware decoder for h264 as a mini pc card and still couldn't fluently play back hd material, the d3d9-way presentation via texturing held it back (integrated into a media center like gui). In the old overlay mode cpu usage was 5-10% only...

Gabest - 17 10 09 - 22:55


To me the worst limitation is "The overlay must be used in windowed mode. It cannot be used in fullscreen mode."

007 - 17 10 09 - 23:19


> To me the worst limitation is "The overlay must be used in windowed mode. It cannot be used in fullscreen mode."

Why is that a problem? You can make the overlay the size of the screen, and updating doesn't entail compositing the rest of the desktop.

Phaeron - 18 10 09 - 06:56


Overlays being on a separate path, can this improve fluidity of motion during pans. Since VSync isn't really kept all that well outside exclusive fullscreen mode under Direc3D.

Blight - 18 10 09 - 10:53


Yup, you can flip the overlay, whereas you can't flip a windowed mode image (the runtime emulates DISCARD/FLIP with a blit). I've actually had pretty good luck with doing beam-avoiding blits in Altirra, but it does glitch occasionally, and it requires bumping the timer to 1ms to do high-resolution polling.

One thing I forgot to check was whether flip control has been improved. IIRC, one of the problems of DirectDraw overlays is that there is no way to do a non-blocking flip -- your choices are either no vsync or block on vsync. You need to block on vsync to get that benefit of overlays, but then if the refresh rate is lower than expected your rendering thread backs up several frames and everything gets screwed up timing-wise. I like the new options that have been introduced with the FLIPEX present mode, but sadly these weren't enabled for overlays.

Phaeron - 18 10 09 - 16:15


You should really try RTM. They have changed a lot in the graphic subsystem between RC and RTM. You can read many posts in many forums about it.

GoD - 19 10 09 - 01:32


"And of course, you need to use Direct3D9Ex to access them, which is juuuust different enough from regular Direct3D9 to be annoying"
Yep, another reason to use D3D9Ex, besides bypassing the lost device emulation, allowing rendering to occur while the computer is locked, as described in a previous blog article.

Yuhong Bao - 19 10 09 - 15:44


i got an error when i try to run this. made a brand new c++ console project, with precomplied headers. copy+pasted the code in, and complied it. compiles fine, but it triggers a breakpoint here:

HRESULT hr = d3d9ex->CreateDeviceEx(0, D3DDEVTYPE_HAL, hwnd, D3DCREATE_HARDWARE_VERTEXPROCESSING, &pparms, NULL, &d3ddevex);
if (FAILED(hr))
__debugbreak();

:( - 13 10 11 - 11:27


You'd have to look at the HRESULT or debug runtime output for the specific reason, but if I had to take a guess, you have a GPU that doesn't support hardware vertex processing and thus needs the D3DCREATE_SOFTWARE_VERTEXPROCESSING flag instead.

Phaeron - 14 10 11 - 20:03

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.