Video Capture, Transcoding, and Authoring/Capturing composite VirtualDub NTSC
Readers are encouraged to comment on the scenarios presented here. Rather than edit the section (unless there is an obvious error), please add the comments in a Notes section following the scenario, for example:
Notes
editThis is an example.
I have a 32-bit Win XP with an Athlon 3200+ and SATA, and this works fine for me. YourNameHere, 20 July 2007
Scenarios
editUsing ATI All-in-Wonder 2006
editFrom Joseph Hall as of 03 May, 2006:
Here is a procedure that works for me.
I have VirtualDub set up the following way:
- Preferences:
- Timing:
- Compression: HuffYUV
My S-video composite output (from a DirecTV box, etc.) is connected to the S-video input of the AIW 2006 dongle. The analog out is also connected to the dongle.
My computer is an Athlon 3400+ X2 running Win XP 64-bit, with 2GB RAM and IDE drives. I run the 32-bit VirtualDub because there is no 64-bit port of HuffYUV (as far as I know). With no other load, or only low-priority background load (such as an "idle" priority TMPGenc batch task), capture generally proceeds fine with no dropped frames and a handful of inserted frames. Some players may not play the resulting AVI-encapsulated HuffYUV stream with perfect A/V sync, but I have learned that the A/V sync is typically fine anyway.
TMPGenc Xpress (4.0) will play the HuffYUV stream with the correct A/V sync in its preview mode (in the clip editor or filter editor). If the A/V sync is correct there, it should be correct after encoding. I can't speak for other encoders at this time, because I am happy with TMPGenc.
A few dropped frames may be okay. If there is a burst of dropped frames, the resulting capture may or may not have good A/V sync. I rarely have dropped frames but every so often I have a source that has a spot that seems to cause dropped frames. Maybe this is because of some peculiarity of those frames that causes HuffYUV to take longer than usual to do the encoding. Several dropped frames in a second or two may not derail A/V sync, but more probably will. Special attention to fragmentation on the recording drive is not necessary in my experience.
Normally I get inserted frames one at a time spaced in intervals of at least a few minutes. A burst of inserted frames may also result in an A/V sync problem, usually due to some other task competing for disk (most likely) or CPU (less likely).
The data rate of the capture depends on the source material. Compression seems to range from about 2.7:1 to nearly 4:1 (on 2.2:1 letterboxed source). 30 GB/hr is a ballpark for capture of a clean but detailed signal from S-video.