2002/07.24 @21:12 (articles, blog, digital video)

video capture part two: getting it working

win2k/tmpgenc

The answer to the AVI capture limit was simple: move to Windows 2000 and NTFS, and capture until my hard drive ran out of space. This was good, in that it worked fine, plus the move to MPEG files rather than AVI meant that there wasn’t really a limit anyway. The O/S was far, far better than Win98 in terms of stability, and the Task Manager that could be invoked by a simple CTRL+ALT+DEL was a delight: I could bring the system down to the bare minimum of executing tasks in a moment.

The only slight problem was that the quality of the MPEG-2 captures I was getting wasn’t as good as I’d hoped for. Sure, it blew the MPEG-1 stuff away, especially on motion scenes as the macroblocks were that much smaller, but it still didn’t make me go: Wow !

In order to get the best quality I could, I then started to capture with VirtualDub and the HuffyUV codec with conversion to SVCD via the rather handy TMPGEnc program. Back when I started doing this the software was struggling into Beta 12 (I think I found it a little earlier) and an English translation was a separate patch to the original software. After much searching I ended up with a DVD player too: a Pioneer 525 simply because it would playback CD, CD-R, CD-RW, VCD, SVCD, oh, and DVD too.

Now I was getting somewhere – the interlaced playback, and the generously blurry nature of a TV set rather than a monitor meant that the stuff I could put onto SVCD (via Nero, a superb CD writing program) was getting distinctly watchable.

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.

win2k/vcd/svcd

Not sure what I hadc in mind for this section…

win2k/main concept/pinnacle studio 7

The next big problem that I had been putting off for far too long was what to do with all of the source clips I now had littered around my drive. I could capture material, I could encode and view it, but how could I make it watchable ? Investigating video editors was a long and tedious process – frequently the demo versions were so appaling that I never got beyond a two second title clip before they were deleted. I also found that the pricing is totally stupid: it was going to be cheaper for me to buy another capture card that came with a free version of Media Studio Pro 6 than it was to buy the software alone…

Things came to a head when I was asked to video a friends wedding – I had to find something, and it had to be good. I’d seen iMovie by this point, and was starting to think that perhaps Apple had got it right, and that I’d been wasting my time on a PC. That’s when I noticed Pinnacle’s Studio editor, asnd tried out the demo. It was an eye-opener, with everything that I’d been looking for, and with one large problem: there was no way to prove the export functionality on the demo… I asked if full frame uncompressed AVI was an available option in the full version, only to be told to try the demo. The demo would only allow CIF Indeo conpressed AVI’s, which proved that there was something moving and colourful going on, but was lousy for anything else.

This was solved by Studio 7, which was released just when I needed it most ! After searching around for it in shops, I ordered it from dabs.com and waited for it to come back into stock. The editing is intuitive, the titles look great, and the range of features that are available seem to grow with experience. There was only one problem: it only worked with DV streams. Now I had been expecting this, and ha already asked a friend with QuickTime Pro to convert a sample raw AVI into DV for me to play with. This convinced me that it was the right way to go, so I went for a PC DV codec from MainConcept.

I’d already come across MainConcept whilst looking at various other editors that could cope with MPEG streams, and had since that point seen so many glowing reports of their DV codec that it seemed a good buy. The process then went like this:

  1. Capture 1/2 D1 (384×768) video in VirtualDub
  2. Post process with VirtualDub to expand back to 768×576
  3. Save that full frame video file with the MainConcept DV codec
  4. Load into Studio 7 for editing
  5. Export the final result:
  6. Via the built-in MPEG-1 (or 2) codec for dropping into Nero for a preview VCD/SVCD
  7. Via a HuffyUV compressed AVI stream for importing to TMPGEnc for a quality conversion
  8. Via a HuffyUV compressed AVI stream for importing into a DVD burining application
  9. Via a HuffyUV compressed AVI stream for playing back with the ATI All-in-Wonder in TV output mode for direct VHS taping

Long winded ? Maybe. Workable ? Absolutely. I could capture 15 minutes at a time without a single frame drop, and whilst the re-encoding to the correct frame size and codec only even went at 7 or 8fps, I could do the work I’d been asked to. Why didn’t I capture longer chunks ? Basically it was back to the audio sync issue again. I had told VirtualDub to make sure that the two streams stayed in step, but in doing so it would drop a frame if required to help keep things together. This sounds good, but was annoying in practice as I could tell something was missing if the frame happened to be during a pan, or some other high motion scene. I could have turned it off, but then I’d get drifing sync, so I settled to stopping the capture as soon as the first drop happened, and the rewinding a few seconds before starting it off again.