Some boards allow you to capture clips within the NLE application whereas others require you to use a separate utility applet to capture clips. For NLEs based on standard media files there usually there isn't much practical difference between these two types of integration. An exception might be that you want to use an NLE’s special feature like stop motion capture. In which case you may need integrated capture support. The other exception is scenario C type systems described above where clips are captured to proprietary media files in order to bypass the limitations of standard AVI or QuickTime media.
Some cards support "Print to DV" from the NLE timeline. This feature allows the NLE to output your edited video project directly to the DV device without first rendering out the project as one or more separate DV media files (AVI or QuickTime files). Cards that support print to DV from the project timeline can simplify laying out to tape of projects longer than 9 min. Otherwise you have to render your movie to one or several media files for output to DV via a separate DV playback utility.
While all DV codecs can display output to the computer monitor (the virtual "desktop") some can also simultaneously or alternatively send DV out the IEEE-1394 port to the DV device. This feature facilitates previewing on a NTSC or PAL video monitor. And since the DV device can easily decode the DV data you can preview full resolution playback from you NLE even if your computer can't decode full-resolution at full frame rate.
There are several factors that limit on-screen DV decoding performance (that is displaying full-size, full-framerate DV on the computer monitor).
DV decoding performance is determined by how fast the computer can read, decode and display frames of DV data. There is also some work that needs to be done to play the DV audio track.
First step of DV playback is probably the easiest since DV data streams at a constant 3.6MB/s. This data rate is no great shakes for most modern hard drives in desktop computer systems. One problem that does arise is that EIDE and some software-based RAID-0 systems require some portion of CPU overhead. So such systems steal CPU horsepower from other parts of the DV playback process most notably decoding. Alternative disk systems such as UltraWide or Ultra2Wide SCSI with bus-mastering controllers and hardware RAID-0 are designed to have minimal impact on CPU performance, but such systems are expensive and probably are overkill for most DV uses. Hard drive I/O performance does not seem to be a major factor in DV playback performance.
Second step of DV playback is the actual decoding of the DV data. The essence of this step is the decoding of frames of raw DV data into 720x480 pixel (or 720x576 for PAL) raster images of RGB data. There seems to be a vast range of differences in the performance of this step by the various codecs and video sub-systems which are available. I've measured four-fold differences in performance on a dual-processor system between the multi-threaded Adaptec Video for Windows codec and Apple's QuickTime DV codec.
The different DV codecs try to achieve better DV playback performance using several methods. Some codecs are just faster because their code has been optimized for higher performance, some use the extended instructions present in some CPUs such as Intel's MMX and SIMD to improve decoding speed. (Apple plans to use Motorola's Altivec instructions which will be present in the next generation of PowerPC chips to gain a performance boost for their hardware this way.) Some codecs such as the Adaptec DV codec have been designed to use multiple CPUs efficiently. Such codecs get a boost on dual-processor NT systems. (A new Fast DV Master codec and a forthcoming codec from Canopus are supposed to make use of multiple CPUs.)
Many DV codecs have options to trade playback performance for accuracy. They can speed-up decoding for on-screen playback by taking shortcuts, like decoding only a 360x240 frame (Microsoft DirectShow, Adaptec) or using a less precise algorithm (Apple QuickTime DV). Such schemes often result in acceptable results.
The third step of DV playback is getting the full-frame RGB raster images to the screen at a fast enough rate. Traditionally this is accomplished by moving the RGB raster images which have been decoded for each frame to the video display frame buffer. This image move is called a bit blit. How fast a system can do that is a large determinant in video playback performance. If a system
can't perform this operation fast enough you will often see "tearing" of the frames. The bit blit operation of a video driver may be yet another task competing with the DV decoding for CPU and bus time. At 25 and 30 fps, there's about 30 MB of raster data being moved around and across a bus to the video board memory every second.
Some video board drivers support a system using specialized video board hardware to overlay RGB data from a separate buffer over the "desktop" windows. This can greatly speed up playback performance since very little CPU overhead is required and the raster image doesn't need to be moved in memory. But in order for hardware overlay to work it must be supported by your video-board's driver, the video sub-system as well as the DV video codec. It's not clear that QuickTime on Windows has any facility to support hardware overlay, for example. By comparison, the Canopus DV products rely on hardware overlay to achieve high performance, on-screen playback.
The other part of DV playback is audio playback. Since miniDV material is often recorded with 48 kHz audio some work may need to be done by the CPU during playback to convert that audio to a format that is compatible with PC audio hardware -- typically 44.1 kHz. I really don't know how significant this issue is for real-time playback.
Tests with the Adaptec codec, Apple's QuickTime 3 DV codec and Microsoft's DirectShow DV codec showed that Microsoft achieves the by far the fastest and smoothest performance with full-size DV framerates of about 18 fps on a dual-Pentium II 400 Windows NT system (with no hardware overlay support). The Adaptec codec can achieve framerates of about 15 fps, but it stutters more (probably due shortcomings of the Video for Windows sub-system without hardware overlay). The Apple QuickTime 3 DV codec in High Quality mode limps along at about 6 fps, which I'm guessing is due to lack of tuning and optimization of QuickTime on Windows and Intel CPUs.
I've not seen any surveys of specific DV codec performance. (It's a difficult and expensive thing to test.) The surveys of DV IEEE-1394 products have tended to ignore performance in favor of more pressing issues like basic setup and operation. Hopefully, we will get to a point where we can rely on all the DV solutions to work out of the box, at which point we can push the their developers to provide better performance.
DV supports several different digital PCM audio formats for recording the soundtrack.
The most common format is stereo 48 kHz sampling. In this mode two channels of 16-bit samples are recorded at a frequency of 48 kHz. These are the same specifications used by DAT audio recorders and provide a theoretical audio frequency range of 0 Hz to 24 kHz -- well beyond the range of normal human hearing (20 Hz to 20 kHz).
DV also has a 44.1 kHz 16-bit stereo recording mode. That mode is the same as that which is employed on audio CDs and has an audio frequency range of 0 Hz to 22 kHz. This mode is often labeled "44 kHz".
Finally the DV format supports a mode with two or four channels of 32 kHz 12-bit audio.
The table below lists the various DV audio modes.
| sampling frequency | sample size | number of channels | equivalent quality | frequency range |
| 48 kHz | 16-bit (linear) | 2 | DAT audio | 0 Hz - 24 kHz |
| 44.1 kHz | 16-bit (linear) | 2 | CD audio | 0 Hz - 22.05 kHz |
| 32 kHz | 12-bit (non-linear) | 4 | MiniDisk | 0 Hz - 16 kHz |
The original multimedia system that supported Microsoft's Video for Windows system only had support for 11 kHz, 22 kHz and 44.1 kHz audio sampling frequencies. These frequencies corresponded to the audio modes supported by typical sound cards in PCs such as a Sound Blaster 16. Subsequently Microsoft introduced the Audio Compression Manager which included a Sound Mapper to resample on the fly from any given audio sampling frequency to one which is supported by the available sound card. Thus all modern Windows PCs can playback stereo audio recorded in any of the DV audio modes even if the computer's audio hardware doesn't directly support the mode. But many Windows applications that use only the original Video for Windows programming interfaces still only support creating AVI clips using the 44.1 kHz DV audio mode.
Ideally you don't want to have to resample your DV audio, but if you should have to, for example, if different DV clips are recorded using different modes or you must use an application that only supports 44 kHz, you want that resampling to be high-quality. High-quality resampling audio from one sampling frequency to another requires good software. Without it harmonic distortion is introduced into to the audio signal which usually manifests itself as objectionable high-frequency ringing. Until recently high-quality resampling software was only available in professional audio applications such as Sonic Foundry's Sound Forge. Now some digital video applications like Adobe Premiere 5 are adding high-quality audio resampling to their features.
Both the AVI and QuickTime media file formats used to store DV clips are limited to a maximum size of 2GB. Because DV has a constant data rate of about 3.6 MB/s this means that a single DV video clip file can be no longer than 9 minutes and 26 seconds. Fortunately, there are various workarounds to this limit. Some systems use extensions to the AVI file format to capture longer clips in larger files. Some systems can capture longer clips into proprietary format media files for use in a specific NLE (such systems are described in scenario C above). Timecode capture is another technology that allows you to circumvent the 2 GB file size limit. Systems that capture timecode within a DV clip allow you to easily reassemble a shot from smaller clips using your NLE regardless of the shot’s overall length.
Batch capture refers to the ability of a DV capture utility to capture a series of clips from a tape using a log of timecodes for the in-points and out-points of the clips. The capture utility will have some facility for generating the clip log and the ability to select which clips in the list to capture or skip. Clip logging can be done either manually, shuttling back and forth with the capture utility's machine controls, or automatically. The latter is called auto-logging. Each method has its pros and cons. Manual clip logging is tedious, but gives the user more control of disk usage and the computer. Automatic clip logging tends to require a lot of computer time (often several times the run-length of the DV tape) and may tie up your computer for the duration, and it may also require larger amounts of available disk storage since not all auto-logging systems know how to use disk space efficiently.
Clip logs (lists of the timecodes for the in-points and out-points for a series of clips on a tape) can also be generated automatically by some DV capture utilities. Such utilities run the entire tape through the DV deck or camcorder and automatically detect cuts and scene changes. The generated clip log can then be used to batch capture the desired clips off the tape.
Timecode capture embeds the original SMPTE timecode from the DV tape into the captured media clip on your PC. You can then use this timecode to do frame-accurate synchronization of clips and even match clips captured during different sessions. Since timecode allows you to seamlessly stitch together multiple clips it can be used to circumvent the 2 GB (9 minute) filesize limits of individual QuickTime and AVI media files.
Many DV camcorders have the ability to record video in an anamorphic widescreen mode. This widescreen mode is made up of frames with a width to height aspect ratio of 16 to 9. The video frames of this widescreen mode are stored using the same size frames as standard 4:3 aspect ratio video. The difference is that the 16:9 widescreen images are horizontally (anamorphically) compressed to a 720x480 pixel video frame. Thus the individual pixels are stretched to display the image properly. Some new TV and video equipment can display 16:9 widescreen video in its proper aspect ratio (either by letterboxing a standard 4:3 display monitor with black bars top and bottom or by stretching the image to fit a wide screen display monitor).
Some DV capture drivers and codecs have the ability to recognize 16:9 encoded DV and preserve the encoding throughout the editing process. Some also have the ability to give an accurate preview of the widescreen image on the computer screen. But many DV software tools can only display square pixels and will thus display a horizontally compressed image on screen but may still preserve the 16:9 encoding.
DV/IEEE-1394 solutions that don't recognize 16:9 widescreen encoding may actually strip the encoding from the digital recording, leaving it indistiquishible from standard format video from an electronic perspective. This makes it difficult to edit and display especially if you mix 16:9 and 4:3 shots on the same tape or video file.
The other impact of the 16:9 format in desktop video is that the pixels that make up a video frame are a different shape from standard 4:3 format DV. (They are 33% wider.) This means that if you composite any 4:3 footage, computer graphics (such as scanned images), or titles onto a 16:9 frame the software must know to stretch the footage or images appropriately.
Finally, there is the separate issue of how to properly do widescreen DV shooting. In question is the suitability of most DV cameras for capturing widescreen video since almost all DV camcorders do so by reducing the resolution of the active image on their CCD image sensors. They reduce the size of the image sensor by 25% then stretch that by 33% resulting in a significantly degraded image. Some very expensive camcorders have widescreen CCD image sensors. Another option is to add an anamorphic lens adapter to a DV camcorder. This issue is completely independent from an IEEE-1394 capture solution's ability to properly recognize, manipulate, display and preserve widescreen encoded DV video.
Batch playback is important in order to easily playback movies longer than 9 minutes to tape. The Video for Windows AVI and QuickTime movie file formats can only store a maximum of 2GB in each individual file. Because of the DV format's fixed playback rate 2GB can only store a little more than 9 minutes of video. Batch playback allows multiple individual movie files to be played back in a seamless sequence. The QuickTime 3 system has the ability to create what are called reference movies to facilitate this. These reference movies contain references to other movie files which contain the actual data to be played back in sequence. Thus QuickTime reference movies are a form of batch playback. Other systems allow a list of files to be queued up for playback from the DV playback utility. This is usually a feature of the IEEE-1394 board's playback utility.
Professional versions of the DV format: DVCAM and DVCPRO use so-called "locked" audio modes. Like anamorphic widescreen this is an attribute of the DV data signal that must be preserved throughout the capture, editing and playback process.
See Adam Wilt's DV site for a thorough discussion of "locked vs. unlocked" DV audio. http://www.adamwilt.com/DV.html#locked audio
None of the standard Windows media subsystems (Video for Windows, DirectShow or QuickTime) has intrinsic support for four-channel audio. So support for four-channel DV audio playback or editing is very rare at this point. (Only the Canopus DVREX card supports four-channel DV audio, and then only within Canopus' RexEdit software.)
Some IEEE-1394 interface cards have with a hardware DV codec (compressor/decompressor) on board. This hardware is actually the same Sony chip that Sony uses inside it's DV camcorders. Originally because these boards had dedicated hardware to do DV compression and decompression it was thought they would perform compression and decompression faster than software-only solutions. In slower PC's this may be true. However, it turns out that the PC's PCI bus is a major bottleneck in such an architecture. In order for the PC to compress video to DV it must transfer 30 full-resolution 24-bit per pixel frames over the PCI bus every second and then transfer the DV encoded data back. As PCs got faster and software codec performance improved software-only codec solutions were able to beat hardware-only solutions under many circumstances. Hardware codec solutions cost several thousand dollars while software-only solutions start at less than $500.
The chief advantage of a hardware codec solution is that it supports analog video capture and playback directly without the need for any DV devices attached to the IEEE-1394 interface. Thus when using a hardware codec card you do not have to have your DV camcorder connected to your PC to be able to preview video on an NTSC monitor. A dedicated DV VCR or a Sony Media Converter attached to your PC will provide similar advantages however. DV VCRs vary in cost from $1000 to $4000. A Sony Media Converter costs under $400.
Some hardware codec solutions such as the Canopus DVREX use a hybrid codec architecture which combines a hardware and software codec and uses each type to it's best advantage.
Most IEEE-1394 cards include a software codec to compress and decompress DV data. This type of codec just uses your computer's CPU to perform DV decoding and encoding and doesn't rely on dedicated hardware to perform the process. The obvious benefit of this scheme is that it is very cost effective to use the general purpose processing power of the CPU to perform DV encoding and decoding.
Some DV codecs are designed to take advantage of Windows NT systems with multiple processors. These systems can use both processors to do DV encoding and decoding.
In my own tests using the Adaptec DVsoft codec and Adobe Premiere 5.1, a dual processor system can speed DV encoding and decoding by as much as 60% compared to a single processor system. Multiprocessing support is only available on Windows NT and is not supported by the Windows 95 and Windows 98 operating systems. A DV codec that is not designed to support multiprocessing will very likely provide no difference in DV performance when used on a multiprocessor system.
This feature allows a low-resolution version of the DV data to be captured from IEEE-1394. This low-resolution version can be used as a proxy for editing. And since it only requires a fraction of the disk storage and processing bandwidth of full-resolution DV it can facilitate long form video projects and off-line DV editing on systems with limited resources. This feature is supported by the Pinnacle DV Studio on Windows and the ProMAX DV software on the Macintosh.
This scheme allows the analog video output of the DV device to be routed into the computer for realtime display in a window on the computer monitor. Essentially this allows you to use the DV device to do full-resolution DV playback to the desktop and it allows you to use your computer display as a video monitor. The analog video signal is then routed out to another analog video device you have such as a video monitor or analog VCR.
In addition to the video frames and audio soundtracks the DV data stream coming from a DV camcorder contains much additional data. This data may include SMPTE timecode, date and time stamps, 16:9 widescreen mode flags, "locked" audio flags, recording data such as lens aperture and speed. Most of this data is not captured by the PC-based DV software. Many, but not all, systems now capture timecode.