Stuff

The video filter system is one of the oldest remaining parts of the VirtualDub source code, now that I've rewritten the capture and project modules, and large portions of the render module. While it contributes a rather important part of VirtualDub's feature set, at this point it is also a major limiting factor in the program's development. As such, it has gotten my full attention for the next major experimental release, 1.7.0 (in case you were wondering what I've been doing for the past couple of months).

Designing a next-generation video filter system isn't easy. I've sunk a lot of time into it so far, and there are some parts of it that are nice, and other parts that are simply hairy to implement and design. Below, I'll talk about some of these and some of the implications for both users and filter authors. For brevity, I will refer to the current-generation video filter system as VF1 and the next-generation system as VF2. Some of the features I talk about here might not make it into the next version, though, depending on how well they work out, as honestly the current design is rather ambitious. I don't normally like to talk about designs-in-progress because it seems too much like a promise that I may not be able to keep, but I also don't like to work alone in the dark for too long.

I bought a Seagate 160GB external USB2 hard drive yesterday for the purpose of backing up my laptop's 60GB hard drive. Most of the stuff on my hard drive is junk not work saving — often in very large files called test.avi — but I have a lot of source code that's worth keeping, and up to this point, hasn't been backed up in any reliable form except for a few dozen archives on SourceForge. Recently I thought I should be a little less cavalier about my data and actually try a backup solution.

The drive came with a backup program called BounceBack Express. I ordinarily take a rather dim view of software that comes with hardware; the drivers are usually out of date and the supplemental software is usually a crippled version. This was no different, in that the BounceBack Express software is a reduced-functionality version of the BounceBack backup program. I decided to try it out anyway, though, just to see how good (or bad) it was. The backup drive was more than twice as large as the source disk anyway, so backing up junk wasn't going to be a big deal. So I just decided to just let it back up the whole drive on default settings.

As we see increases in CPU clock speed slowing as it becomes harder to scale chips and CPU manufacturers start shifting toward multicore designs, we're starting to see greater interest in the computer industry in multithreaded applications to continue improving performance. I have a prediction regarding this: we will see lots of buggy programs for a while. We already got a taste of this when SMP and then hyperthreaded CPUs started appearing, when programs — and particularly drivers — started blowing up on systems that could simultaneously run more than one logical thread. The reason I predict this is for a simple reason:

Efficient multithreading is hard.

The reason I bring this up is that as I try to rewrite my video filter system to take advantage of multiple threads, I find that it is a very difficult task and that it is taking much longer than I would like. This is not to say that I even remotely believed it was easy, but I like challenges more than chores. Multithreading requires a new way of thinking and invites a whole new class of bugs that makes it much more challenging than regular single-threaded programming. Here are a few of the tips (or rather scars) that I've picked up over the years.

Sharp users will notice that the changelog for 1.6.10 says August 7th. This date is inserted into the program when the full build kicks off in my release process. I had this release ready on Sunday, but before I could create the SourceForge entry, the power went out in my neighborhood, presumably due to the heat wave. I suppose I could have reconnected the wireless router and the modem to my UPS and uploaded with my laptop, but it was too hot to rearrange wires.

The major bug fixes in this version are in the internal DV decoder. It turns out I got the weighting incorrect on the DCT coefficients, inverting the weights by accident and attenuating the high-frequency terms. A far more serious problem, however, was that the chroma decoding for PAL DV was totally wrong. The reason for this is that I had to code PAL DV blind since the SMPTE 314M standard doesn't describe the commonly used scheme and I wasn't about to shell out more money for ISO 61834 too. I had assumed that the 4:2:0 scheme was similar to MPEG-2, but nope, it's completely different, and I couldn't see the difference because I was using a [i]noninterlaced[/i] video to test. Both NTSC and PAL DV should look better with the internal decoder in 1.6.10.