Video capture

I recently used VirtualDub 1.9.11 to capture video with audio.

I captured video via an ATI TV-Wonder VE card, which is based on the BrookTree/Conexant Bt878 chip. Windows 7 drivers are not available from Microsoft or the Manufacturer, but the version 5.3.8 btwincap open source driver works pretty well. In VirtualDub capture mode, overlay never works and resolutions can't be set via the capture pin, but preview works, and resolutions can be set via "Set custom format". Spending many minutes in (nonfunctional) overlay mode can cause a bluescreen or crash, but that's easy to avoid by switching to preview or "no display" mode. When previewing or capturing, the card is perfectly stable. Video quality is great.

The TV-Wonder VE doesn't capture audio, so I recorded audio via Realtek ALC889a line in with driver version 6.0.1.6235. The audio quality was good, but since audio and video were recorded via separate devices, they weren't in sync. My first capture was a major disappointment, perhaps due to Windows enhancements for line in. After I disabled those, things got better. I discovered that VirtualDub could perfectly sync if "Correct video timing for fewer frame drops/inserts" was not checked in "Capture timing options". If the option was checked, no frames were dropped and fewer frames were inserted, but VirtualDub did not synchronize the audio very well. There was both an offset and a drift. Fortunately, in most cases the drift was insignificant, and so I could simply correct for the offset. I captured most video this way to minimize frame drops and inserts.

I spent some time wondering whether to extend the luma black or white points. It seemed like there was information beyond the luma white point, but extending it didn't help, perhaps because that information was distorted. There was also a bit of information beyond the black point, but extending it increases noise. Extending either made properly exposed scenes seem washed out. I decided to never extend the white point and only extend the black point for a few scenes which would otherwise be excessively dark.

All the frame inserts I got happened before scene changes or severe noise. This makes me think that the card simply didn't record frames where a usable signal wasn't available. When an insert happened before a scene change, what followed was either one frame of the old scene followed by the first frame of the new scene, or one frame of the old scene and one frame of the old scene interlaced with the new scene. In such cases, I removed those frames.

I gave up on deinterlacing to 29.97fps because all algorithms are a compromise between blur and artifacts, and I didn't want to encode that permanently in the video. Deinterlacing to 59.94fps produced good results, but it also increased compressed video size substantially. Because of that, I decided to encode interlaced MBAFF H.264 video with x264. It plays acceptably in Windows Media Player 12 and excellently in MPC-HC with ffdshow Yadif deinterlacing.

Before encoding I considered various forms of denoising, but I never found one that really improves the end result. Denoising could decrease the slight noise, but it would also blur some subtle patterns like distant grass, asphalt, and slightly dirty walls. Also, the file size decrease from denoising is offset by the greater visibility of artifacts in smoothed areas. The most bothersome effect was that areas which show motion due to subtle patterns could stop showing motion. Finally, I noticed that x264 seems to perform some denoising itself, so denoising isn't needed after all.