What a morning!

Wow, this is the first time in months I’ve had such an eventful past 24 hours.

Painting pewter miniatures with Thom was pretty cool, as was entertaining his daughter for a few hours until it was her nap time.  Then came a margarita that really kicked my ass, and it was time for bed… followed by really weird dreams, and being awoken every 10-15 minutes.

Morning came, and most of it consisted of arguing with the author of VHScrCap over bugs in his (or someone’s — still not completely sure yet) software, while simultaneously talking to some Russian FreeBSD users, explaining how I knew what an izbushka was and what “prikin” actually means.

But the apex of the adventure was about 30 minutes ago…

I was on my way to get some Chinese food when I heard someone yelling for help.  I found an older heavy-set woman who spoke broken English, stating something about “a broken vein” in her leg.  After seeing how much blood she had lost (on rags and on her doormat), I realised an artery of some kind had probably broken or been cut.  She had a small bandage in her house, which I proceeded to get and apply, but it barely held.  I asked if she had called 9-1-1, and she seemed dazed but said no.  I didn’t know if she really had, so I called it in anyways.

Thankfully I had a very old jacket on, so I used one of the arms as a makeshift bandage, but it didn’t work very well, so I applied heavy pressure with my hands until the local fire department came and was able to help.  They thanked me and provided a couple cleansing towelettes, which didn’t really help since I had blood all up and down my arms.  I remembered thinking “God, I hope she doesn’t have HIV…”

I went and got my Chinese food, inducing quite a few odd looks from customers and the store owners (“Are you okay?”  “Yeah, this isn’t my blood”  “…um, okay…”) before I biked back home.  I again saw the woman being assisted to by the fire dept., as well as a police officer.

Here’s to hoping positive karma for helping someone pays off.

VHScrCap bugs — part 5.

After much chaos (see my previous blog entries about this subject), I’ve recorded a 15 minute video showing the “cropping bug” in VHScrCap 2.1.4.0. It also includes a new bug, where VHScrCap suddenly stops working altogether (until I switch video sources, where it suddenly comes back to life); this bug could actually be with Flash, but I’ve never seen this happen with SCFH DSF or my webcam.

The fact that the “cropping bug” doesn’t happen until you’ve run/used VHScrCap the first time is a bit disconcerting. Near the end of the video, I also show that deleting the VHScrCap registry keys restores proper functionality (no more “cropping bug”).

The entire thing was recorded using VirtualDub (video and audio). Thankfully VirtualDub has screen and audio capture support, making recording this video incredibly easy. The quality is quite high, and very crisp; you should be able to see everything. And yes, my voice is fairly annoying, sorry. :-)

The video codec used is FM Screen Capture Codec (~100KBytes). I would have gone with Vladimir’s own VH Screen Codec, but it’s a DirectShow filter, and VirtualDub doesn’t work with those. The audio is MPEG Layer-3 (MP3), which should work for everyone. One bad thing about the video codec, however: it has no true keyframe support, so fast forwarding and rewinding doesn’t work. :-(

The video is available here (47MBytes):

http://www.malkavian.com/~jdc/vhscrcap/20080614_cropping_bug.rar

I don’t know what else I can say about this problem. The video speaks for itself.

VHScrCap bugs — part 4.

EDIT: This just in.  I just managed to reproduce (in full) the “cropping bug” in 1.5.0.  I really don’t know what just made it start happening, since 30 minutes ago it wasn’t occurring.  This might have to do with the well-known issue where VHScrCap’s configuration utility leaves itself lingering in memory (which is actually fixed in the 2.1.x series), so possibly the registry entries never got updated.

Additionally, Vladimir has stated he can reproduce the “cropping bug”, but with webcams or other hardware.  I’ve never seen that happen, ever — only with VHScrCap.

I’m going to try recording a video switching between the two DirectShow filters (VHScrCap vs. SCFH DSF), showing the problem.  I’ll include audio as well, assuming it doesn’t make the file too big.

This morning I decided to download VHScrCap 2.1.4.0 (according to the website, although the actual VHScrCap driver, once installed, is 2.1.5.0) and attempt to reproduce the bugs. Despite the incredibly annoying VHMultiCam feature (which is new to me) getting in my way, I was only able to reproduce (partially; it’s hard to explain) the “cropping bug”, but not in a way that would affect the video capture region itself. I could only partially reproduce it with the “Keep aspect ratio” option disabled. The “mosaic bug” was completely gone.

I uninstalled VHScrCap 2.1.4.0, deleted the leftover registry entries, and ensured that all the .ax files were unregistered/deleted from my hard disk. Then I installed VHScrCap 1.5.0, which is “old”, but labeled stable. Version 1.5.0 was what I originally was using when I found these bugs. Amazingly, I was not able to reproduce either bug using version 1.5.0 (though I’m under the impression 1.5.0 acts like 2.1.4.0 with “Keep aspect ratio” disabled).

Three major changes have occurred since late 2007 and now:

1) I’m using Windows XP SP3, versus Windows SP XP2,

2) I’m using DirectX 9 end-user runtimes dated June 2008, versus November 2007,

3) I’m using Adobe Flash Player 9.0 revision 124, versus a significantly older version.

This seems to indicate the core of the problem was in XP SP3, DirectX (which includes DirectShow), or Adobe Flash. None of these programs include ChangeLogs, so finding the true source of the fix will prove very difficult. VMware Workstation would come in handy (for installing XP SP2, an older DirectX runtime, and old Adobe Flash), but one thing is for certain:

Presently, I cannot reproduce the problems I originally stated were in VHScrCap.

I’ll be spending the next few days fiddling around with my workstation, seeing if there’s something I’m missing from before. Reproducing these bugs was incredibly easy, and I haven’t forgotten the procedure.

Vladimir, I apologise for stating the bugs are in your software, but I’m still not 100% sure VHScrCap is out of the clear yet. Surely you can see where I’m coming from: if the problems weren’t in VHScrCap, why did switching to another DirectShow filter solve them? That’s the part I can’t figure out.

VHScrCap bugs — part 3

The author of VHScrCap has again responded to my blog, consisting of the following:

1) Claims SCFH DSF doesn’t store settings — false. Each application you bind it to (e.g. explorer.exe, msnmsgr.exe, etc.) causes SCFH DSF to store the settings in <processname>.ini in the directory where the scfh.ax filter was installed from. SCFH, on the other hand, does not store settings, which makes me wonder which program (SCFH DSF vs. SCFH) he’s actually using.

2) Continually ignores the fact, despite long walk-throughs and step-by-step explanations, that VHScrCap works perfectly fine (read: every DirectShow filter has the “cropping bug” and “mosaic bug”). The bugs I have described only happen after VHScrCap is shut down and restarted/re-initialised (and continue subsequently). You can delete VHScrCap registry keys to work around the problem, but you’ll have to remember to delete them every time you exit the application.

3) Suggests that I “re-write all of my blog posts” to inform the world that “these aren’t bugs in VHScrCap”.

4) Implies that by me stating there’s bugs in VHScrCap, that I am executing slander.

I’m not sure what to make of this, and I find it interesting. The definition of slander is defined as comments or actions which would injure a person’s reputation, or defame said person. Calling the author of VHScrCap a thief/murderer/etc. would be slander; mentioning bugs (or “features”) in a piece of software is not slander, regardless of those comments being posted in a blog fashion, in Email, or spoken.

And just to cover my ass, there’s nothing libellous about my comments either. There is absolutely no effort on my part to discredit the author or VHScrCap. There is nothing vindicative here. I am simply reporting problems I have found in VHScrCap, and recommending that if people encounter said problems, there are alternative softwares available (SCFH DSF). Let’s not forget that I did approach Vladimir privately (way before I even had this blog), and reported the problems I found, offering to help in my spare time test debug builds or work towards finding a solution — a slanderous or libellous individual would not do such a thing.

5) As a result of my “slander”, he will possibly contact the WordPress admins and ask them to either close my blog entirely, or posts specific to VHScrCap (I’m not sure which). He apparently hasn’t read the WordPress TOS, applicable sections of which are Section 2 subsection vi (which redirects you to a definition of defamation, which basically repeats what I said above, re: nothing that would destroy his character, as I have no issues with the author personally), Section 5 (Automattic is not responsible for any content posted on a blog, and states “The Website may contain content that … contains technical inaccuracies”), and Section 12 (Automattic is not liable for any content on the site).

6) Indirectly threatens to turn VHScrCap into a solely commercial piece of software if “users do not respect and help developers”. This is sad. I hope such doesn’t happen, because for most peoples’ needs, VHScrCap is fantastic. It is indeed faster than SCFH DSF, and offers the ability to integrate with your own software, which SCFH DSF cannot. But people need to make the decision of what program suits their needs best, on their own. So there are pros and cons to both programs.

On the flip side, he offers the following positive commentary:

1) Recommends that I describe bugs in Adobe Flash in verbose detail, offering to help with the technical descriptions, so that users or programmers in the future may benefit from said descriptions.

2) States that he has put a lot of man-hours into developing VHScrCap, and is happy to make it free, as long as users respect and help developers of free software.

Vladimir seems to be completely unaware that I’m heavily involved in the FreeBSD Project, which is an open-source/community-developed UNIX operating system, and have been involved in open-source projects since 1993. On the other hand, unlike other open-source contributors, I do not play the “you have the source, fix it yourself” or “it’s free, so stop complaining” defence cards. I believe users should have the right to say anything they wish about anything, and that if you release software publicly (which I have), you have a personal responsibility to maintain it.

Vladimir definitely maintains his software, and appears to enjoy maintaining it (why else would he take the time to defend his software here?). I have absolutely no personal qualms with Vladimir, and in fact I appreciate his passion. But his personal character is not what my VHScrCap-related blog posts are about. A person can only go so far with bug reports before saying “I’m out of options. Your program has issues that affect me. You’re claiming they’re not issues. I’m going to switch to another piece of software that doesn’t exhibit those issues”.

That is all I have to say on the matter. Users should read my blog posts, the user comments from Vladimir, download the videos (his and mine), and conclude whatever they wish.

VHScrCap bugs — part 2

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!).