¶1.6.0 details
I spent far too much time yesterday playing Treasure of the Rudras (Rudora no Hihou), so I'm trying to do something else today. I think Riza's boss battle music is my new choice for top SNES music, though.
VirtualDub 1.6, like 1.5, is an extensive rewrite of the internals. 1.5 focused on the bottom-level framework for the program, mainly lifting out a few of the subsystems, and most notably OS-level helpers, into static libraries. The changes in 1.6, besides the AMD64 and VS2005 compatibility changes, are focused a layer up, at the application library level. This means that more of the 1.6 changes (besides bugfixes) are visible to the user.
The details:
The AMD64 build is preliminary. Benchmarks from the AMD64 build are worthless, because low-level pixmap conversion routines are not optimized. The only asm-optimized parts are the MPEG-1 video decoder and the resampler. Another problem you'll run into is that 32-bit plugins can't be used, including video filters and Avisynth. Win64 does not allow a 64-bit process to load 32-bit DLLs. COM marshalling might be able to handle Avisynth but I doubt it; it's more likely that I will have to launch the 32-bit VirtualDub as a child process and use IPC to access 32-bit code.
1.6.0 has a completely rewritten bitmap library (Kasumi) that has native support for packed and planar YCbCr (YUV) formats. All conversions interpolate/decimate chroma with bilinear filtering and with MPEG-2-consistent chroma positioning; conversions between YCbCr formats do not round-trip through RGB. This means that 1.6.0 does not require a codec to decode or encode UYVY, YUY2, YV16, YV12, I420, IYUV, YVU9, or Y8, and all conversions are supported. Correspondingly, the Video Depth dialog has been rewritten to allow direct selection of YCbCr formats. VirtualDub will automatically fall back if the codecs involved cannot handle the requested formats -- for example, if YV12 doesn't work it will try YUY2. Fast Recompress is now mostly redundant except that it prohibits features that would force a round-trip through RGB; it will probably be removed in a later version.
The video filter system is still restricted to XRGB32, unfortunately. I wanted to lift this restriction for 1.6.0 but it was apparent that I'd need to rewrite the pixmap library first. An optimization has been added to the video pipeline, however: if Full Processing Mode is selected and the video filter chain is empty, the rendering engine will blit directly from the source format to the destination format. This speeds up the process and drops out a possible RGB round-trip. I did rewrite the resampler, however, in order to add AMD64 support and I expect to add 8-bit channel support later to allow all planar formats to be resampled.
The display subsystem was also improved in 1.6.0, most notably that it now supports planar YCbCr overlays. If you load an Avisynth 2.5 script it is now possible to use hardware overlay to display YV12 output. Note that some video drivers don't ship with correct defaults for overlay contrast/saturation and you may notice a shift in the image; this usually can be corrected in your video driver's control panel. Preliminary OpenGL and Direct3D 9 drivers are now exposed, although disabled by default in Preferences. The OpenGL driver supports point/linear filter mode selection and the Direct3D 9 driver also supports bicubic. Bicubic mode requires an NVIDIA GeForce2 or better, or an ATI RADEON 7xxx or better; quality is better on GPUs that support pixel shader 1.4. One of the reasons I have begun working on 3D drivers is that the Microsoft DirectX team has hinted that DirectDraw's days are numbered. This is unfortunate as Direct3D makes a lousy replacement for DirectDraw, being much more work for lower performance, but at least it is still better than GDI.
VirtualDub 1.6.0 now supports reading type-1 DV files. I bought a copy of SMPTE 314M and implemented a DV video decoder; a DV codec is no longer required. (The 8x4x2 IDCT is still in floating-point, but it isn't used often.) Audio support was actually harder for two reasons: most of the DV audio modes are only covered in the much more expensive ISO/IEC 61834, and the audio stream isn't always locked. I "solved" the latter by loading the audio in ten-frame chunks and resampling them to the correct length. This means that even in Direct Stream Copy mode the audio may be modified slightly. However, the difference is usually not more than a sample or two in duration, 48KHz audio seems to always be locked, and it has the side effect of fixing timing variations. There may be some stuttering during preview if you are playing a DV file off of a slow link, due to the huge block size.
The image sequence code now supports progressive JPEG; it does not use the Independent JPEG Library (IJL), but the quality factors are the same. One issue, though, is that quality level 100 may produce images that show high-frequency artifacts in other applications, such as Internet Explorer and ACDSee 3.0. I tracked this down to a problem with the fast integer IDCT in the IJL library; using IJL with the more precise IDCT fixes the decoding. Another issue that is on my end is that reading a JPEG file that comes from a digital camera may result in a black border, due to insufficient parsing of EXIM headers. I know that PNG support has also been requested; I have working code for decoding PNG (8K!) but haven't plugged it in yet.
And finally, for programmers:
The system library has been relicensed from the GPL to the zlib license for 1.6 -- VirtualDub itself remains under GPL, but system/* and h/vd2/system/* can now be used in programs with other licenses. If anyone needs to make portable, dual-licensed code that can be linked into VirtualDub, this should make it easier. Unfortunately, there are two issues with the library: some of the files still have the old license text, and there are __declspec(thread) variables that will prevent it from being used in a DLL. I'll fix these for 1.6.1.
I fixed compile errors with both the prerelease DDK VC8 compiler and with Visual Studio .NET 2005 Beta 1, including the stupid CRT deprecation warnings that the latter added. However, I have not shipped VS2003 or VS2005 project files because of how much of a pain it is to fix up the converted project files, most notably removing unwanted compiler flags (/GS) and redoing the AMD64 build. For those of you who are still experimenting with the VirtualDub source code on Win95/98/ME, be warned: I have decided that unless it is a disaster like Visual Studio .NET (2002) was, I will be switching to Visual Studio .NET 2005 when it is released. None of the .NET compilers will run on 95/98/ME. Users won't have to worry about this, though, as the generated code will still run, and I haven't even dropped Windows 95 + Pentium support. Yet.