¶VirtualDub's video panes
Seems like a lot of people haven't discovered this yet, given that I haven't updated the help files for 1.6.
The right and bottom borders of the video panes in VirtualDub are draggable. You can choose arbitrary zooms as well as aspect ratios, even those that may be different from the underlying file. This means that you can correctly view video clips that may have an aspect ratio greatly different than 1:1, such as a clip whose frames have been split into sequential fields. Right-clicking on the panes opens a context menu that allows selection of several predefined zooms and aspect ratios, along with an option to restore exact 1:1 pixel size.
Under Options > Preferences > Display, there are a number of options for choosing the rendering technology. If you are experiencing rendering issues, particularly with multiple monitors, turning off DirectX support entirely is recommended. This is required under current versions of WINE and under Windows XP Terminal Server (a.k.a. Remote Desktop) to work around DirectDraw blit clipping issues. VirtualDub automatically disables accelerated preview when it loses focus, in order to release system resources and to allow for reselection of a better mode when it is reactivated. It also disables it by default when Terminal Server is active — this is usually faster over a remote link anyway.
Filtering and stretching
The non-DirectX path, which uses GDI, is never filtered and always uses point sampling. In this case each pixel in the source becomes a rectangle on screen, which results in generally poor perceptual quality. It is sometimes preferable when looking for image artifacts, however, as it results in the sharpest image. GDI is very slow when stretching, so when using this mode you will see a serious speedup by using exact 1:1 blits, unless your display driver accelerates StretchBlt(), which nearly none do.
The DirectDraw blit path, which is the default, may or may not bilinearly filter. Unfortunately, whether it does depends on your video driver, and VirtualDub cannot tell or control which is being used. Generally, 3D cards filter and 2D-only cards don't. Stretching is basically free in this mode due to hardware acceleration.
The DirectDraw overlay path is also usually filtered, even on cards that don't support 3D. You can tell when this mode is active by a telltale dark green border when dragging or resizing the pane — this is the colorkey used to mask the video whenever VirtualDub's window is covered. Depending on the video card, and even the video format, the filtering may be better or worse than bilinear. It's not uncommon for chroma to not be filtered in some modes, or even luma unfiltered along a particular axis. This type of display is often subject to separate color controls in the video driver's configuration pages, so be aware of drivers shipping with off-unity settings — NVIDIA drivers, in particular, like to install with saturation set above 100%. VirtualDub will attempt to use an overlay whenever possible, but usually overlays and blits don't conflict: it's usually the case that blits only support RGB and overlays only support YCbCr. There's also usually only one overlay, so if you attempt to do output preview with both input and output formats set to YCbCr, only one will be a true overlay and the other will be a software conversion followed by a blit.
Note that the overlay I talk about here is different than the overlay mode usually seen in capture programs. In this case, the overlay is a second display surface that is pasted on top of the regular desktop in the scanout hardware of the video chip; in the capture case, overlay is usually just the video capture hardware scribbling right onto the desktop window, which then gets displayed as usual.
The 3D minidrivers are the only ones which allow selection of the video filtering algorithm. The OpenGL minidriver supports only point and bilinear; the Direct3D 9 driver also supports bicubic, if you have DX7-class 3D hardware. These drivers are typically slower than the 2D drivers, due to overhead in texture conversion and feeding the hardware command list. I intend to improve the Direct3D 9 driver over time, as that seems to be the way that video display on Windows is headed; I actually prefer OpenGL, but I only have experience with basic OpenGL 1.1, and Direct3D is the evil that I know, so I'm more likely to do work on that front.
Windows Longhorn^H^H^H^HVista
Oddly, VirtualDub seems to mostly work fine under Windows Vista beta 1. I was hoping for a really spectacular fireworks display, like what you'd get on an Amiga with a busted copper list. However, if you have hardware powerful enough to run Aero Glass, you may still encounter some issues with VirtualDub's video displays and the Desktop Composition Engine. When I tried it with the alpha LDDM drivers from NVIDIA, the GDI minidriver stopped working, meaning that whenever you task switched from VirtualDub during preview, the panes would stop updating. It turns out that there is some strange issue with mixing GDI and DirectDraw rendering on the same window — when VirtualDub deletes its DirectDraw objects and drops to GDI rendering, the results of the last DirectDraw blit stick around and cover the GDI output. I don't know whose fault this is, whether it be Microsoft, NVIDIA, or mine, but I've filed a bug on it just to see what Microsoft's reaction is at least.
Although the problem is minor, turning off DirectX acceleration will work around it. StretchBlt() performance seems to be seriously improved in Vista, which is an unexpected bonus.
I also noticed that DirectDraw blits weren't filtered. This might be my fault since I don't bother to set the ARITHSTRETCH bits, given that I couldn't find any hardware on the planet that heeded them. This is another reason I intend to eventually evolve the Direct3D-based display code, as in that case I definitely have control over video filtering. Aero Glass does seem to suck quite a bit of GPU power already, however, as I noticed it taxing the NVIDIA GeForce FX 5600 a bit. I've heard that the DCE renders windows in 16-bit floating-point and does gamma-correction, which seems a bit extreme to me, especially since that hardware doesn't support alpha blending with FP16 render targets. Then again, Vista is only at beta 1, so it's not performance optimized.
If you have Vista beta 1 and try VirtualDub on it, I'd be interested in hearing if you do or don't see the above behavior. Ctrl+Shift+F9 seems to toggle Aero Glass, although oddly I can't find any documentation verifying that.
Incidentally, on an unrelated note, Vista supports symlinks. Unlike the junctions you can create on Windows 2000/XP, these work on files as well as directories, and if you delete a symlink with Explorer it doesn't delete the target. Finally!