virtualdub.org Proof that I had too much free time in college

### Current version

v1.9.11 (stable)
v1.10.1 (exp.)

### Navigation

Main page
Archived news
Downloads
Documentation
Capture
Compiling
Processing
Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
Other projects
Altirra

# VirtualDub history

If you're looking for the list of changes to VirtualDub since the previous version, you're looking in the wrong place -- the list of changes is available in the Help menu of the program itself.

If you want to know how I came to write VirtualDub, then you're in the right place. I've just spent several hours in the ECE lab at UCSB getting a project working, so I feel like doing something else. So in a time long ago, in a dorm far, far away...

## How it all started

By my senior year of high school I'd gotten onto the Internet with the almighty 28.8K baud modem. I was fairly new to talking to millions of people online, and had embarrassed myself on Usenet on a couple of occasions, but I could use a web browser. One of the files I happened to stumble on was a movie file of the Sailor Moon SuperS movie intro. It was 15Mb and extremely high-quality in all its blocky Cinepak splendor, but it was something I'd never seen before, Japanese animation (anime). Later that year, I got myself a video capture card, and one of the first clips I tried to capture -- unsuccessfully -- was the opening from the North American dubbed version of Sailor Moon. It looked very different than regular cartoons, and more importantly, it looked really neat. This is how I got hooked on anime. (Since then, I've seen a lot more than Sailor Moon.)

What does this mean? Anime is what started me on desktop video. Would you believe that I'd write over 700K of code because of anime? I wouldn't have, back then.

## The software that comes with the card always bites

One of the big problems I had at the time was that the capture program that came with my card was a simplistic 16-bit application that refused to capture above 160x120, 15fps without dropping a ton of frames. It wasn't until I started programming in Windows that I riffled through the MSDN collection and discovered that the software that had come with my card was a barely modified version of a Microsoft sample application! The MSDN CD I had also had the source code to a 32-bit version called AVICapture, which I compiled and ran. Sure enough, I went from being able to capture 160x120 to 320x240 at the same frame rate. It turned out that the 16-bit application was disabling the disk cache entirely during the capture session, which caused the hard drive to thrash horribly and basically eat it performance-wise. While making some modifications to this program, I managed to destabilize it, and when I got tired of rebooting repeatedly trying to track the bug down, I started to rewrite it from scratch -- this became the integrated capture mode of VirtualDub.

Before that happened, though, I'd been experimenting with postage-stamp-sized video at 160x120, and RealVideo encoder. RealVideo had just come out, and being able to cram a 15Mb video file down to a streamable <1Mb file was pretty neat. Unfortunately, all my sources were VHS, and... well, VHS quality. However, it seemed that reducing down 320x240 video to 160x120 would give a better picture. Out of this grew a utility called `AVIreduce` which did exactly that. It is this utility that became the nucleus of VirtualDub. You can still see a few remnants of the AVIreduce code in `dub.cpp`, which is the least object-oriented part of the program, with an enormous class using variables such as `lVStreamPos`. Unsurprisingly, the now seldom-used `reduce2` filter was the first filter to be implemented.

To this day, one of my side hobbies is to figure out the best way to produce the smallest good-looking video files from crummy video sources. Some of my experiments are the `hresync` filter (removed in version 1.3) and the `smoother` filter.

## A side trip through the AVI editor

Some time in the middle of my freshman year at UCSB, I'd begun to attend the local anime club and saw a four-episode series called Birdy the Mighty. I'll spare you the plot details, but suffice it to say I liked the series to pick up copies of the episodes on tape. One of the problems with tape is that seeking to a point you want to show somebody is a bitch, and so I realized that I could do so much more quickly if I captured it to a video file. So I started capturing it with AVIcapture and compressing it with a classic Video for Windows program called VidEdit. For those of you who are familiar with ripped episodes of anime, this was a terrible rip; I did episode 1 in 7 segments at 10fps because I had to capture uncompressed and didn't have very much disk space, and the files got stored onto a CD-R in Indeo 4.1 with uncompressed audio -- hardly acceptable nowadays. I still have my homemade "Birdy" CD around here somewhere, and no, I don't distribute. You wouldn't want it anyway.

Halfway through, I got fed up with VidEdit. Since it was a 16-bit program, it locked up USER while compressing a frame, and since I was using the slow Indeo 4.1, I could bring up the Start menu if I held my mouse button down over the icon for several seconds. That caused me to compile another Microsoft sample program, AVIedit. Being a 32-bit program, AVIedit wouldn't lock my system during compression. One of the big problems with AVIedit, though, was that it had a horrible progress indicator. Specifically, none. All it said was "Saving...." I managed to hack one in, but because of the way the `AVISaveV()` function works, all I had to work with was an integer completion percentage; the function didn't even tell you a frame count. At three seconds per frame and about 4,000 frames per clip, this gave quite a large progress granularity. It was my frustration with AVIedit that motivated me to add compression abilities very early on in VirtualDub, and to this date I do all my AVI compression with it.

A few months later, I purchased a miroVideo DRX with hardware motion-JPEG compression. It came with a non-linear editing program called MGI VideoWave 1.0c. I installed it, and found it had MPEG encoding. So I plugged in a clip and tried it. It took about 15 seconds for every 3 frames on my P166 and complained about an invalid MPEG file when I tried to load the output file back in! I deleted the trash off my system and swore never to install it again. If VideoWave had worked correctly, I probably would have used it instead and VirtualDub wouldn't exist.

## Developing the program

Those of you who have known me online for a while know that the first program I released, and my first big project, was a 32-bit DOS paint program called VGAPaint 386. Well, VirtualDub is my first, and only, major Windows project. I started VirtualDub with only a basic knowledge of Win32 programming. After browsing a few pages of the Visual C++ starter's guide with no knowledge of C++ (I only knew ANSI C), I'd chucked the manual early on and decided to program in bare Win32, without MFC. This is why VirtualDub has a fairly simplistic interface, and why the program is only a single, stand-alone 400K statically linked executable.

Most of you probably don't know this, but the build number in VirtualDub increments once for every compile that I do on the program, even for debug builds. I did a few hundred builds before implementing the autonumber system, but in any case I actually have compiled over 13,000 versions of the program. The earliest build I have of VirtualDub is around 650; this build already has many of the characteristic features of the program, including the ability to process the audio stream of a file while copying over its video untouched, and the quick framerate and audio format buttons in capture mode. It wasn't until Public Release 1 (build 1482) that I posted the program to the Internet, and not until around version 1.0 pre-5 (build 6904) that people started to express interest in the program.

A few miscellaneous facts about the program:

- The source code includes 1.9MB of C++ source, 256K of C++ headers, and 457K of assembly.
- VirtualDub takes approximately 10 minutes for a full rebuild on my system.
- C++ files alone contain 73,000 lines of text. When headers and assembly are included, the total rises to 104,000 lines. Guess I'm not ready for the million-source-line club yet.
- WinAmp is almost always playing anime songs when I code... on loop.
- VirtualDub has been developed across five operating system versions -- Windows 95 OSR2, 98, NT4.0 Server, NT4.0 Workstation, and 2000 -- and two versions of Visual C++, 4.0 and 6.0.

## And so on...

Well, VirtualDub has come a long way from its humble beginnings. Since then, the program has gained 21 filters, the ability to decode MPEG-1 files, more than doubled in speed, and nearly quintupled in object size. I hope you enjoy using the program. To all the anime lovers out there, this program's dedicated to you; it wouldn't have happened otherwise.