In the past, when I’ve wanted to do a screen capture of an application, I’ve generally fired up FRAPS or Camtasia or similar third party software. Screen capture software tends to be a hassle, though – cost, compatibility glitches, poor performance, etc.

Another approach is to generate your screen capture video from code within your app by calling the Windows Media Encoder SDK. Windows Media Encoder can read from a range of input sources including real video devices, pre-existing video files, and the “screen capture” device we’re interested in. Then it can apply a rudimentary transform pipeline, and send the result to an encoder and on to an output sink like a file or a live Windows Media broadcast.

What you’ll need:

• Install Windows Media Encoder 9 Series:  (32 bit | 64 bit )
• Install Windows Media Encoder SDK
• A .NET app whose output you want to render to video (WinForms or WPF, shouldn’t matter too much – I worked with WPF. In fact, I think even a Console application could be rendered this way – basically, anything you can get an HWND for – see below.)

Suprising fact #1 – 64 bit is different to 32 bit

I installed the 32 bit edition of the Encoder on my 64 bit Windows 7 RC1 install. I probably could have avoided the problem below by installing the 64 bit version.

When I first instantiated the WMEncoder object from my .NET app, I got a failure to instantiate:

Time to check that the Encoder and Encoder SDK installations succeeded. Looking around for the Windows Media Encoder 9 dlls, I noticed they were in my Program Files (x86) folder, so, on a hunch, I told my .NET app to target 32-bit specifically (rather than being agnostic and just running in whatever platform the target machine is natively).

Before:

After:

And that solved the problem.

Surprising fact #2 – COM is fiddly

When you ask the encoder to use the screen as its input stream, you can further tell it whether to grab the whole screen, just a specific part of the screen based on pixel boundaries, or a particular window.

Generally, WMEncoder does a good job of presenting a .NET friendly interface to its underlying COM horror-show. But in this particular case, things get a bit fiddly. The IWMEncVideoSource2 object which represents our screen capture source also implements IPropertyBag, which is not a Windows Media Encoder interface; it’s a generic COM thing, if I’m not mistaken. For this reason, there’s no helpful .NET interop definition for IPropertyBag in the WMEncoder SDK – you’re left to your own devices.

The solution was actually relatively simple – pinvoke.nethas entries for both relevant interfaces (IPropertyBag and IErrorLog) – I was able to just copy the annotated definitions straight from pinvoke.net down into my application and start coding against them.

Surprising fact #3 – flexible and fail-safe interfaces aren’t discoverable

By “flexible” here, I mean interfaces that rely on an untyped property bag of name value pairs. By “fail-safe”, I mean interfaces that, when given configuration values that don’t make sense, rather than raising an error and explaining the problem, they “fail-safe” to a sensible default value.

As I mentioned above, the screen capture video source can capture either the whole screen, a particular window, or a specified rectangle.

Surfing around the SDK documentation and google, it’s possible to find a list of property bag keys that the screen capture source takes notice of. But it wasn’t easy (I never managed) to find documentation of which keys/value pairs must be set to elicit a certain behaviour. For example, the default behaviour is to capture the entire screen. There’s a “Screen” key/value pair which is #defined as “CaptureScreen” in some samples. If I want some other behaviour than whole-screen-capture, do I need to set “Screen” to false? Or zero? Or null? Or “No'”? (Hint: the answer’s no).

There’s a “CaptureWindow” key/value pair. If I want to capture a particular window, I guess I’m going to have to set this. Should it be true/1/”Yes”? (Hint: no). There’s also “WindowTitle”, so I’m guessing I specify the window I want by passing the window’s title in as a string to this key.  (Hint: wrong).

All the above approaches seem (still seem) reasonable to me, and there are googleable examples of others making them and posting their code on the web, but they’re wrong.

Actually, you just set “CaptureWindow” to the Int32 HWND of the window you want to capture.

Moral of the story: if you’re writing an API for mass consumption, you can either:

• write a tight interface that is discoverable and complains clearly and specifically when violated, or
• write a loose interface and great documentation.

Please choose one.

Surprising fact #4 – WPF’s discoverability irritates me again

WPF is generally a vast improvement over WinForms. The main area it falls down in is discoverability. For example, if I have an Ellipse on a Canvas, and I want to set the Ellipse’s position on the canvas, here is the list of approaches I will try, in order:

1. myEllipse.SetPosition(new Point(100, 50));  // Fail
2. myCanvas.SetPosition(myEllipse, new Point(100, 50)); // Fail
3. Rain dance // Fail
4. Prayer // Fail
5. Establish working group // Epic fail
6. Canvas.SetLeft(myEllipse, 100); Canvas.SetTop(myEllipse, 50); // Success, but need to shower

Today’s WPF-discoverability irritatation is a lot lower on the irritation scale than that old chestnut. I needed to obtain the HWND for my app window. In WinForms, HWND is a property on the Window, from memory. In WPF, you need to do the following, which IMHO has the same code reek as the Canvas malarkey above:

(Thanks to http://blogs.vertigo.com/personal/ralph/Blog/archive/2007/04/12/wpf-get-hwnd-of-window-object.aspx for that one).

Surprising fact #5 – after all that, it works!