§ ¶Working with image sequences

Time to actually post something for users and not just developers.

To reading a series of numbered images as a video stream, use File > Open video file... and select the first image. VirtualDub will automatically step the filename and find any sequentially numbered frames after the starting file. You can open BMPs and TARGA files this way. Starting with VirtualDub 1.6.0, you can also sequential JPEGs and single files. In 1.6.2, you can also open non-interlaced PNG. Once the sequence has loaded, use Video > Frame Rate to set the correct frame rate for the sequence.

To exporting a video segment as a sequence of numbered images on disk in VirtualDub, use File > Save Image Sequence. What you may not know is that nearly all of the regular video processing modes are still enabled in this mode. This includes video format, frame rate decimation/conversion, filtering, etc. modes. In particular, if you only want to write out every fifth frame in the video, simply set frame rate decimation to "every 5" and you will only get 1/5th of the frames. Similarly, if you are writing out BMPs, you probably want to use no video compression and a normal video format such as 24-bit RGB. (That VirtualDub allows you to write out something silly like MPEG-4 compressed "BMPs" is actually a misfeature that I need to fix.) For the most part, though, what you see in the preview is what will get written out to disk as images.

§ ¶DirectX 9 December SDK and VirtualDub

Quick note to those of you experimenting with the VirtualDub source code, or otherwise are working with Visual C++ 6.0: the December 2004 update of the Microsoft DirectX SDK is not compatible with VC6. In particular, attempting to link against the DirectX libraries results in missing symbol errors caused by dependencies on symbols only available in the Visual Studio .NET runtime libraries. I think the missing symbols are related to buffer security checks -- these shouldn't be causing problems since VirtualDub only needs the GUID tables and the interface definitions, but it is. This means that if you are compiling VirtualDub with Visual C++ 6.0 (the official compiler) you will need to stick with the November 2004 Update SDK instead, as that one will still work. If you are using Visual Studio .NET 2003, however, you should be able to use the December 2004 SDK without problems.

In general, Microsoft seems to be making a bit of a mess with the current DirectX SDK. The DirectShow documentation and debug runtimes were simply taken out of one of the DX9 SDK refreshes, and then the DirectShow docs popped up in the Extras package, but the debug runtimes were nowhere to be found. Then the DirectShow debug runtimes were added back into the December package, but with no installer or even instructions on how to safely install the debug DLLs. A number of the DLLs are protected by System File Protection, so they can't simply be replaced, and I'm reluctant to simply disable SFC and stomp the existing drivers since some of the files are kernel drivers. If anyone knows how you are supposed to use the debug runtimes, I'd be interested in hearing.

§ ¶Debugging the DirectShow capture driver the hard way

Those of you who have been following my development history for a while know that at one point I predicted I would be releasing a 2.0 version of VirtualDub. Well, that never panned out due to my getting a full-time job, so I scaled my plans back and went down the 1.5, 1.6, etc. incremental plan. One of the modules that I wrote for 2.0 way back in college was a somewhat functioning DirectShow capture module. Unfortunately, I couldn't drop it into 1.4 when I canned 2.0 because the two versions were quite different; it wasn't until I brought over the system libraries in 1.5 and rewrote the capture layer in 1.6 that it was possible. But that wasn't the only problem.

DirectShow is a very different beast compared to Video for Windows, and there were (and still are) a ton of problems in the module. Part of the problem is the increased flexibility of the API, which lends itself to more complexity, and thus more bugs. Another problem, though, was what amounted to a random, full-screen UI lock during development. Frequently all applications on my development machine would cease to respond during testing; I could Ctrl+Alt+Del to the logon desktop, could Alt+Tab and see the window list, could even run console apps in a command prompt -- but all GUI apps were simply locked. Basically, I had to hard restart my system, which on my laptop meant a power-off. This annoyed me to no end and put a major crimp in development, which was one of the reasons I stopped working on it.

I finally figured out what was (is) going on today, when I hit the same stupid hang again... but I had to use a rather drastic trick to do so.

§ ¶Pipelines and performance

VirtualDub, although not really designed for multi-CPU systems, is moderately multithreaded. On an average render it will use about 4-5 threads for UI, reading from disk, processing, and writing to disk. Trying to keep these threads busy is a challenge and to do so VirtualDub's rendering engine is pipelined -- all of the stages attempt to work in parallel with queues between them. The idea is that you add enough buffering between the different threads that they are all working on different places in the output and the stages only block on the single bottleneck within the system, which is usually either disk (I/O) bandwidth or CPU power.

In VirtualDub, pipelining parameters are set under Options > Performance in the editing mode; in capture mode, you can adjust disk buffering parameters in Capture > Disk I/O. But what do the parameters mean, and how should they be set?

§ ¶Beware of the CPU-specific optimizations

Every once in a while, I get a crash report whose diagnosis looks like this:

10116789: 0ff6c1          psadbw mm0, mm1      <-- FAULT

Crash context:
An integer SSE (Pentium III/Athlon) instruction not supported by the CPU was executed in module '****'...
...while decompressing video frame 0 with "********* Codec" [biCompression=********] (VideoSource.cpp:1772).

I blocked out the codec ID information so as to not single out a video codec manufacturer.

A crash like this usually means that the video codec you were attempting to use was compiled with CPU-specific optimizations that your CPU doesn't support. This generally means that your CPU is below minimum requirements for the codec. Unlike normal CPU requirements, missing instructions doesn't mean the codec will run really slowly -- it simply means the codec won't work at all. There's nothing I can do about this in VirtualDub; if you're seeing something like this and are indeed below the minimum spec, you need to either upgrade or beg the codec vendor to support your CPU (if it is actually fast enough to handle the video format).

§ ¶VirtualDub 1.6.2 released

It's been a while since I've done a real update, so I figured I might as well make it a big one.

This version fixes some more regressions and gets closer to stable for the editing mode, but more importantly, this version is what I consider "first viable" for basically what has been a complete rewrite of the capture module since 1.5.10. The 1.6.2 capture module is much more modular and flexible; most of the globals are gone and there are now well-defined interfaces in between layers. The primary benefit is that VirtualDub is now able to interface to both Video for Windows and DirectShow for capture, which means that WDM capture drivers now work much better.

As for the details....

§ ¶Interesting bug in Windows XP 64-bit Edition

For those of us who run the AMD64 (x64) version of Windows XP 64-Bit Edition, the current build, build 1218, is a bit tricky to install. It's required to run Visual Studio .NET 2005, since the previous build 1184 was too old, but it has a tendency to blue-screen on startup until you trawl the newsgroups and find the hint to change the power management setting to Minimal Power Management. After that it mostly works, as long as you don't try to use Windows Media Player.

Anyway, I was doing some checks on the AMD64 build of VirtualDub 1.6.2, only to discover an annoying problem: the capture module wasn't capturing properly. In fact, the timing module was dropping an alarming amount of frames and was seeing the system clock run at half speed. I launched the 32-bit version to cross-check and sure enough, it too was seeing the clock run at half-rate. Doh! What the heck was going on...?