Yesterday, the author of VHScrCap dropped by my blog and decided to post a statement, arguing that what I’m showing is not a VHScrCap bug. I thought about refuting his claims via another comment, but then I thought, “Why not just blog about it?”
So here it is, a step-by-step walk-through of the video showing the bugs in question, with notations of what’s happening when in the video. Follow along and enjoy the bugs the author insists are not.
00:00 to 00:10 — I launch VHScrCap with a fresh/empty registry, and set it up to capture the full screen. Looks perfect!
00:11 — I choose Track Window, to track the Windows Media Player window of the Japanese parrot fish. Again — looks perfect! The video is “stretched”, but that’s not a bug — it’s expected.
00:12 to 00:44 — I move some windows around, showing the border of the capture region is correct/working properly. Still no bug at this point.
00:45 — I close Windows Media Player.
00:48 — I close the Flash application, which is what’s using VHScrCap. The VHScrCap configuration window also closes.
00:51 — I close the IE window, which is responsible for loading the Flash applet. I do this “just in case”.
00:56 — I launch the IE window.
01:01 — I log in to Ustream.
01:06 — I click “Broadcast Now” in Ustream, which brings up the Flash applet.
01:10 to 01:35 — Here is the first sign of the bug I call the “mosaic bug”. As you can see, the capture window contains what appears to be a heavily mosaic’d version of a portion of the entire screen (my desktop). This makes absolutely no sense what so ever. Now, I assume this bug happens because VHScrCap is still (somehow) trying to refer to the old window capture region of WMP, which is now closed. However, why is it mosaic’d? I also believe this bug to be possibly what leads to the next problem…
01:35 to 01:45 — I launch VHScrCap’s configuration program, and choose the first instance of Internet Explorer.
01:47 — I confirm that Track Screen is selected, confirming my above comment (re: mosaic’d version of my entire desktop).
01:48 to 01:52 — I close the VHScrCap configuration program, and relaunch it.
01:53 to 02:06 — I choose the Internet Explorer window once again, but this time a 2nd instance of it (since there were two instances shown earlier).
02:06 to 02:19 — I close VHScrCap and Internet Explorer, wanting to show that relaunching EVERYTHING (including Flash) to prove that nothing changes.
02:20 to 02:31 — I launch Ustream, log in, and click Broadcast Now, which launches the Ustream Flash applet.
02:32 — Oh look! All I did was relaunch everything, and now VHScrCap isn’t “mosaic’ing” anything — it’s capturing my entire desktop, like it should have done the previous time! This ABSOLUTELY confirms a bug. But wait, there’s more!
02:33 to 02:42 — I launch the VHScrCap configuration program.
02:42 to 02:52 — I move my mouse around the border of the captured region being shown in the Ustream application, and move some windows around. The reason I do this is to indicate my desktop is suddenly cropped incorrectly.
Do you see any sign of my desktop icons on the far left? Nope. Do you see any on the far right? Nope. What about when I drag a window to the left? You can see the left side of that window is no where NEAR the edge of my desktop, yet in the captured region inside of Ustream (VHScrCap!), it’s hitting the border of the captured region. VHScrCap somehow thinks my screen isn’t 1920×1200 any longer. ANOTHER bug, which I often refer to as the “cropping bug”.
02:53 to 02:55 — I select Track Window in the VHScrCap configuration.
02:56 to 03:06 — I go into Explorer (not IE) and launch WMP by double-clicking the video of the Japanese parrot fish. WMP launches.
03:06 to 03:14 — I tell VHScrCap to capture the WMP window, using the Select Window pulldown.
03:15 onwards — Look very closely at the captured region in Ustream. Again, you can see that VHScrCap is incorrectly cropping off the left and right sides of the WMP window — the same thing it was doing before when capturing the entire screen. This proves the “cropping bug” happens with both Track Screen and with Track Window.
The fact of the matter is these are bugs. There is absolutely no other way to see it. The only solution for them is to clear the VHScrCap registry area, which fixes the problem until the next time you launch/utilise VHScrCap. That, to me, confirms there is a bug.
On the other hand, VHScrCap does in fact capture regions faster than SCFH DSF, though the magnitude is not very substantial enough to justify putting up with such bugs. I would rather have a capture filter work correctly, albeit 4-5 fps slower (but this doesn’t matter since Ustream limits you to ~20fps anyways!).