win2k/ati/virtualdub
There have been various unofficial {ATI} driver releases from time to time, and these are almost uniformly a very bad idea for a dedicated capture machine. The code is generally worse than the official releases, and the install scripts are even less reliable, and the whole collection isn’t aided by {ATI}’s MMC and device driver split. The front end can have an overhaul which may or may not alter the drivers, but of course sometimes the frontend will only work with the newest drivers… In all, give the leaked versions a miss unless you have a few hours to spare getting everything back the way it was.
There was another ugly surprise waiting for me too: WDM. {Microsoft} had decided the change the VFW (Video For Windows) driver architecture with the new WDM system, but {VirtualDub} was a pure VFW program. This meant it would run just fine, but didn’t recognise the ATI card as a capture device. Gaah! yet again, it was VirtualDub to the rescure with this charming snippet of information. Now, despite all the dire warning about the end of the world being nigh if VFW to WDM mapping were performed, it finally recognised the capture card correctly.
Getting a good quality source stream to supply to {TMPGEnc} was the next step, and now that the 2GB limit on AVI’s was removed by {Win2K}, {VirtualDub} and HuffyUV were the obvious pairing. Unfortunately, the HighPoint HPT366 controller wasn’t properly supported under {Win2K}, so I braved a beta version after reflashing the motherboard BIOS (and by association the HPT BIOS). This worked, and the system would now recognise the drive connected to the HPT. Unfortunately, the speed tests (provided with {VirtualDub}) showed that the performance was way down on the Win98 results, with the best data rate I could get peaking at around 11MB/s. Not enough for full frame video capture.
Now I could have gone and bought a new fast controller card such as the Promise ATA device, but I was getting worried that this too wouldn’t perform as well as could be hoped. It was also very annoying to have found that there were potential IBM drive issues with the HPT chipset that were ignored by both IBM and HPT on their glossy front pages, and only surfced when reading the Changelog for the beta versions of the HPT code. I decided that I didn’t want to risk more money on hardware, so something had to change.
Given that I was investigating SVCD, which has a native PAL resolution of 480×576 (2/3 D1), I wondered what would happen if I tried capturing at half the normal horizontal resolution (1/2 D1). This ought to be a fairly quick method of reducing the data rate, and domestic TV’s aren’t good enough to resolve a full D1 image anyway, so I gave it a try. It worked like a charm: I could now capture over 15 minutes of footage without a dropped frame, and the CPU requirements were modest too. I did have to tweak some of the capture buffer sizes to ensure that the IDE interface wasn’t being thrashed with small data packets, but that was all. {VirtualDub} allowed me to postprocess the file back to full D1 with a variety of different transforms, all of which came with a preview so the most suitable could be chosen for each clip.