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
 
Other projects
   Altirra

Archives

Blog Archive

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

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.