Features of Open System DV &
IEEE-1394 Non-Linear Editing Solutions for PCs:
Editing Application (NLE) Integration
All of the IEEE-1394 boards in the Silver List will work with a non-linear editing application (NLE) such as Adobe
Premiere in some manner or another. The degree of integration between the
IEEE-1394 hardware and the NLE varies from one product to the next. There are
three basic scenarios for integration between IEEE-1394 hardware and a given
NLE. Some IEEE-1394 boards come with software that is tuned to work with a specific
NLE such as Adobe
Premiere, Ulead Media Studio Pro or in:sync Speed Razor. Sometimes this integration is done using
an open-system of plug-ins and standard media files, and finally sometimes the
best integration is achieved using proprietary methods which circumvent the
limitations of standard media systems and the open plug-in mechanisms of the
NLEs. In this latter method the specific IEEE-1394 board and NLE are closely
tied together. There are, of course, many variations, but these are the predominant
A simple, compatible, but no NLE integration:
DV video clips are "captured"
from a DV device (typically a DV camcorder or DV VCR) via an IEEE-1394
board into AVI or QuickTime media files using the DV capture utility
provided with the IEEE-1394 board. These media files are subsequently
imported into the non-linear editing application where they are
edited into a new project. The resulting edited project is then
rendered out or exported as one or more new, DV-encoded AVI or
QuickTime media files. These media files are then played back
to the DV device using the DV playback utility provided with the
IEEE-1394 board. All of the IEEE-1394 boards in the Silver List
can be used in this manner.
B open-system NLE integration:
These systems are characterized by the use
of plug-ins to integrate the DV/IEEE-1394 hardware with specific
non-linear editing software. In these systems DV video clips are
"captured" from the DV device to AVI or QuickTime media
files entirely within the non-linear editing application. These
media files are subsequently edited into a new movie. The resulting
edited movie is then played back directly from the NLEs
project timeline to the DV device using a "Print to DV"
plug-in which supports the IEEE-1394 board. Alternately the project
can be rendered or exported to standard media files by the NLE.
Since these systems are based on NLEs with open extensibility
and standard media files you can typically replace either your
IEEE-1394 board or NLE at a later date with any other product
that uses the same media system (QuickTime or AVI).
C closed-system NLE integration:
DV video clips are "captured"
from the DV device to proprietary media files within the non-linear
editing application. These media files are edited into a new project.
The resulting edited project is then played back directly from
the NLEs project timeline to the DV device using a "Print
to DV" feature. Alternately new edited media files can be
rendered or exported by the NLE.
The main difference between scenario C systems
and those that follow the other scenarios is that the DV clips
are not stored in standard format media files (i.e. AVI or QuickTime
files). This limits your ability to easily use these clips in
other digital video applications that only accept standard media.
However NLEs have the ability to export AVI and/or QuickTime files
when needed. And if most of your work is done within the NLE this
may not matter much to you. To their credit, since these systems
bypass standard media systems they are typically not hampered
by some of the limitations of those media systems such as the
9 minute 2 GB maximum clip size. The NLE in such systems is often
tightly coupled with the IEEE-1394 hardware. This coupling may
limit your future choices of IEEE-1394 hardware or NLE software
since you may not be able to easily use your captured media clips
in a different NLE. And, at best, you may only be able to use
a scenario C-type NLE with other IEEE-1394 boards in a manner
consistent with scenario A integration discussed above. In which
case you would lose all the benefits of the scenario C's tighter
IEEE-1394/DV Solution Features:
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 NLEs 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
to DV" from timeline support:
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.
to DV device when scrubbing and editing:
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.
Playback on the Computer Desktop:
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.
Support for all DV Audio Modes,
DV supports several different digital PCM audio formats for recording the
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
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)
|| DAT audio
|| 0 Hz - 24 kHz
| 44.1 kHz
|| 16-bit (linear)
|| CD audio
|| 0 Hz - 22.05 kHz
| 32 kHz
|| 12-bit (non-linear)
|| 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.
of files larger than 2 GB (> 9 min. 26 sec.):
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 shots overall
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.
(anamorphic widescreen mode):
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
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
for Locked Audio:
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
See Adam Wilt's DV site for a thorough discussion of "locked vs. unlocked"
DV audio. http://www.adamwilt.com/DV.html#locked audio
for 4-Channel 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
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
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
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.
proxy clip capture for off-line and reduced resource editing:
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.
Video Monitoring and Pass-though:
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.
updated Oct. 1, 1999
This document is copyright (c) 1999 by Richard Lawler.
Back to the Silver List of
PC DV & IEEE-1394 Solutions