What is VirtualDub?

VirtualDub is a video capture/processing utility for 32-bit and 64-bit Windows platforms (98/ME/NT4/2000/XP/Vista/7), 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.

§ ¶VirtualDub 1.9.10 released

New stable release is out -- as usual, no new features, but a handful of bug fixes.

The first important bug fix is that the dwInitialFrames field is now unilaterally cleared when writing AVI files. In some cases, VirtualDub was passing this value through from source files, which caused compatibility problems as some players didn't like non-zero values. Like many header fields, this one is also underdocumented in Microsoft docs, is misinterpreted by various players, and isn't supposed to have any effect on audio sync or sample timing. Some users were encountering issues with this value being left non-zero, though, so the program now always zeroes it.

The second fix is one that was lurking for a while, but didn't appear until some recent feature additions, and was the issue that prompted this release. There was a bug in the thread tracking code that caused a handle leak for all unnamed threads. Most of VirtualDub's threads are named, as you'll discover if you run it under a debugger, but it turns out that the threads used for multithreaded compression weren't. This manifested as an occasional Invalid Handle exception when running a lot of jobs with threaded compression enabled. That's now fixed, so you should now see better stability on such operations.

There has been some confusion about the difference between test/dev/stable releases, and why the dev-test releases have features that don't appear in the stable releases. Some time ago, I switched over to a branched development environment, where the stable releases use a different code line than the dev tree. The reason for this is that it allows me to push only selected fixes into the stable branch and produce clean releases. In the past, I had a couple of accidents where temporary testing hacks ended up getting pushed out with fixes, which then forced me to do an oops-re-release. I hate doing that, so now I use multiple branches to segregate the work. The test versions are quick builds that I do on either line so that users encountering an issue or wanting a feature can take a look at the latest bits; this allows for much faster iteration, but the downside is that those are literally just the latest bits off the code line and about the only guarantee is that it compiles, which is why I don't publish them more formally. These versions are all tagged with -prerelease on startup, so you'll know if you're running one of those.

Changes in this version:

§ ¶Altirra 1.7 released

Things have eased up and I've gotten a little bit more time lately for hobbies, so it's time to start flushing out the release backlog. We'll start with Altirra, since it's the easier one to release and I'm feeling lazy today.

The new release is version 1.7. New features include flash cartridge and IDE emulation, portable mode, fast boot, video recording, hard disk burst I/O, and secondary monitor display acceleration. Bug fixes include debugger stability improvements, CPU undocumented instruction fixes, and improved compatibility for the built-in HLE kernel. Since it's been about four months since the last release, this version has gotten extra testing, and special thanks to Mclane and Breaker for continually testing new releases (and contributing to the epic comment thread on the last post).

It's safe to say that I never thought I'd get this far, and now that I know how much is involved, I'm not likely to try writing another emulator. Well, unless I get another nostalgia kick, and truth be told, the Heathkit H-89 and TRS-80 Model 4 are not nearly as interesting machines. The Apple II doesn't have much in the way of interesting hardware. The C64 never interested me as much, and I hated that butt-slow 1541 disk drive with a passion. (No, I didn't have the Epyx fast load cartridge. Yes, I was bitter.) There's the TI-99/4A, but the only good game I had was Parsec, and TI BASIC made the 1541 look fast. Oh, there's the Amiga....

...

Hmm.

No, I'd better not.

Anyway, if you're an Atari 8-bit fan, please enjoy the new version.