What is VirtualDub?

VirtualDub is a video capture/processing utility for 32-bit Windows platforms (95/98/ME/NT4/2000/XP), licensed under the GNU General Public License (GPL).  It lacks the editing power of a general-purpose editor such as Adobe Premiere, but is streamlined for fast linear operations over video.  It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters.  VirtualDub is mainly geared toward processing AVI files, although it can read (not write) MPEG-1 and also handle sets of BMP images.

I basically started VirtualDub in college to do some quick capture-and-encoding that I wanted done; from there it's basically grown into a more general utility that can trim and clean up video before exporting to tape or processing with another program.  I released it on the web and others found it useful, so I've been tinkering around with its code ever since.  If you have the time, please download and enjoy.

§ ¶When video drivers lie

A couple of days ago, I was running one of my side projects that uses several of VirtualDub's core libraries, including the display code, and discovered to my annoyance that the full-screen mode was not working properly. The program displays video at lock-step 60 fps, so it's sensitive to timing and the glitches are very apparent when it misses frames. This was a particularly bad case, though, because it was missing very badly -- enough that the audio was breaking up -- and this was on a CPU that was about 50% faster than the previous one I had, which ran this program perfectly. The windowed mode wasn't syncing very well either, but that's understandable given the non-exclusive nature of windowed mode, and so clearly the speed of the program core wasn't the problem.

I eventually tracked it down to something odd in the NVIDIA driver for my Quadro NVS 140M. For some strange reason, the driver was lying to me and actually running the full-screen display at 50Hz, but lying to my program and saying it was 60Hz, which of course totally trashed the program timing. I didn't notice because I'm on an LCD, which doesn't show a 50Hz refresh rate by flickering like a CRT would. The desktop was also suffering from the same problem, which was even more bizarre. It turned out that the culprit in the windowed case was a setting in the NVIDIA control panel called "Extend battery charge by using less power for the display"; clearing that restored the desktop at least to 60Hz and gave me clean frame sync again. I still can't figure out how to get the full screen mode back to 60Hz, though. The DirectX APIs are all reporting only 60Hz being available for refresh rate on all available display modes, but every single one of them is actually 50Hz. I tried turning off all the PowerMizer options, but to no avail. How annoying.

Anyway, if you're getting a lot of tearing when you try to play video on your laptop, it may not be the video player. The video driver may be fooling with it a bit.

§ ¶VirtualDub 1.8.3 Released

1.8.3 is out, and fixes a horrendously stupid regression in 1.8.2 where VirtualDub's main window wouldn't display if you didn't already have saved window position data in the Registry. If anyone's still seeing issues in 1.8.3 like this, please let me know.

On the other hand, I already received an email from a software site saying that VirtualDub 1.8.2 has been added to the database and awarded 5 stars....

I have to apologize for the quality of the last couple of releases. To be honest, I haven't found a good solution to the testing problem. Having only one release line didn't work, because I couldn't push experimental changes out without breaking the mainline. Splitting development into two release lines still didn't really fix the problem because most people didn't try the experimental version and so I still ended up with showstopper bugs in the stable line. Lately I've been pushing out test releases at a much faster rate to the forum; that's helped a lot with specific issues since I can get bug fixes to people and have them verify it in much less time, but it's generally still the case that the first stable release end up with a few major bugs that didn't get caught in the pre-testing. In this case, it happened because I and everyone who had been trying those test releases already had the position data in the Registry because we'd been running incremental releases up to the final, and because the few tests that currently exist in the release script are scripted and don't notice issues in the UI. I'd like to beef up the automated testing, but that's going slowly since it's about as major as developing the program itself. Sigh.

If you have some time and tend to track VirtualDub releases, please swing over to the Testing section of the forums, and try the latest test releases there from time to time. I can't implement features very quickly -- particularly right now -- but if you spot new bugs, I can usually fix those on a time scale of days to weeks instead of months as it would be for a full release. I really apprecate this kind of feedback as it helps avoid releasing a dog like I did today.