What's the difference between DV1 and DV2?
JustMe
I understand that both mini-DV and D8 camcorders capture video in DV
format. When that data is transferred to the computer via an
IEEE-1394 card, it arrives as an AVI file (on a PC).
My understanding is that there are 2 flavors of IEEE cards, DV1 and
DV2. Is that correct? Do the different cards handle the incoming
data differently and create different types of AVI files? Are both
methods "lossless" in moving data from cam to PC? What about this
issue does a consumer need to be aware of in selecting
cam/card/software?
Thanks.
HighPeaksVideo
>My understanding is that there are 2 flavors of IEEE cards, DV1 and
>DV2. Is that correct? Do the different cards handle the incoming
>data differently and create different types of AVI files?
I think it's the software that determines what file type you get on file
transfer from you camera to the computer. Here is a Microsoft page with info.
http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/dvavi.mspx
Craig H.
Dave Haynie
wrote:
>I understand that both mini-DV and D8 camcorders capture video in DV
>format.
That is correct.
>When that data is transferred to the computer via an
>IEEE-1394 card, it arrives as an AVI file (on a PC).
That is, of course, one option, and the usual. The simplest thing to
do is to "encapsulate" the DV data stream in some structure useful for
disc-based manipulation of the video.
>My understanding is that there are 2 flavors of IEEE cards, DV1 and
>DV2. Is that correct?
No, that is entirely incorrect. First, you're not talking about an
"IEEE card", you're talking about an IEEE1394 card. While here folks
probably will know what you're talking about, keep in mind that there
are literally thousands of IEEE specifications. A typical PC might
also have an IEEE1284 parallel port, an IEEE802.3 LAN or IEEE802.11
wireless LAN (which, of course, each use an IEEE802.2 MAC), etc.
It's also proper, these days, to say "Firewire"... the IEEE1394 Trade
Association and Apple finally met on the licensing of this trade name.
Anyway, all Firewire does for you is deliver the high speed serial
bus. Alone, it doesn't know a thing about digital camcorders, DV
encoded video, etc.
When you add a Firewire card to a PC, you'll generally have a driver
bound to it, called an IEEE 1394 Host Controller. This is an
abstraction for the very low-level device. If the controller follows
the OHCI specifications, the driver provided by Windows will support
the card.
Other drivers layer themselves over the Host Controller layer, all
software. If you put a hard disc or other similar storage on your
Firewire bus, you'll see an IEEE 1394 SBP2 "Storage+Repeater" device
supporting it. Other devices are supported by other layered drivers.
The one we're probably interested in the most often, of course, is the
DV driver. Most of the time, under Windows, you'll use the Microsoft
driver, which shows up as "Microsoft DV Camera and VCR".
This driver supports several functions. For one, it controls your
camcorder, via a tiny subset of the huge remote control protocol
developed to allow IEEE 1394 to control fairly dumb devices in a
standard way. It's also, naturally, responsible for make the camcorder
port available to video applications for reading and writing. Most
video applications don't know IEEE 1394 per se; from their
prespective, the DV driver looks like any other Direct Show
capture/control driver.
If you step back a bit and look at other forms of capture, you'll find
there are a number of sorts of drivers for capture, none specifically
related to the AVI file format. DV is really no different in this
respect. In the past, drivers could support audio/video or video only,
in their particular format, and offer compressed or uncompressed video
in a variety of formats. DV isn't particularly different on its own
than, say, an analog capture device that does Motion JPEG encoding (a
DC10+ card, for example). The one big thing you see in practice, of
course, is the fact that it's The New Kind... 32-bit, Direct Show,
etc. None of that old Video for Windows stuff. Thus, the fact that
when DV camcorders first came out, many capture apps didn't see them.
So anyway, assume you have a capture application. It hooks into the DV
capture interface and recognizes that it produces a compressed stream,
with audio/video interleave already done for you. Great! Just what I'd
like on my disc. So the simple thing is to put some kind of ID header
on this stream, then write it directly to disc.
More or less, that's the AVI file called "DV Type 1". A DV Type 1 file
always has the header information for a Direct Show, or AVI 2.0 file.
This uses the OpenDML standard to allow management of a very long file
using only 32-bit information, but it's otherwise a pretty natural
import of the DV information.
The problem here, if there is one, is that, again, this is The New
Thing (eg, only about five years old). Some applications are dragging
their collective feet on Direct Show/AVI 2.0 support, though these
days that's largely limited to freeware; it became a commercial
necessity ages ago.
But, let's say you want to run under the old AVI 1.x system, which is
associated with Video for Windows. Well, you have that same stream
coming into your capture application as before, but you'll have to
have it write things out a bit differently. For one, the natural
interleaving of audio/video in the DV stream isn't compatible with the
requirements of AVI 1.0; it has specific demands about how and where
audio and video interleave. So, at the least, you would have to split
the audio and video streams differently, as you write your AVI 1.0
file (which is called "DV Type 2").
And that's what they did... sort of. To make things efficient, the DV
stream isn't actually split. The stream itself is just included in the
DV Type 2 file as the video stream. Audio chunks are copied out and
interleaved according to the AVI 1.0 specs.
Typically, AVI 1.0 files are limited to 2GB in length. This is a limit
enforced, even today, by Microsoft's built-in AVI code. It's not an
inherent limit, since OpenDML can be used with either AVI format, but
Microsoft only supports it for AVI 2.0 files.
Of course, this isn't the only thing that could be done. Like any
other video input device, you could build a Firewire card that
transcodes your DV into another format; that was actually done long
ago, before DV itself was the popular form for editing. And of course,
a sufficiently fast PC could transcode the DV to another format on the
fly, in the capture utility, just as capture utilities typically allow
other encoders (MJPEG, for example) to run on a raw input. The fact
this isn't typically done or even supported by most software is simple
testiment to the fact that DV is a fine editing format itself, and
re-encoding to a different format for editing would just incur
additional quality loss.
>Do the different cards handle the incoming
>data differently and create different types of AVI files?
Again, nothing to do with the card, these days.
> Are both methods "lossless" in moving data from cam to PC?
Capture applications writing either Type 1 or Type 2 DV bring that
data over exactly as it is stored on tape, media-wise. The only
changes are in the addition of formatting data, necessary to turn a
linear stream into a useful random-access file.
Some people are put off by the idea that this is a "capture" process,
rather than a "file transfer" process, and assume that means there's
some kind of additional loss potential. There isn't. The reason this
process is "of the nature of a capture" rather than "of the nature of
a file transfer" is the simplicity of the DV camcorder interface. The
camera is basically being operated as any other camera; the IEEE1394
command interface isn't doing anything dramatically different with
that camcorder than a LANC interface would have on a analog camcorder.
The camera has a nice digital interface, but it's still very much a
camcorder, not a piece of computer gear. You can't run the tape as a
random-access device, or even start and stop it instantly, like a
computer tape drive. You say "go" and it dumps the data, one-way, no
feedback. So even though it's a lossless digital transfer, it behaves
much like an analog capture.
> What about this issue does a consumer need to be aware of in selecting
>cam/card/software?
Your card should be an OHCI IEEE 1394 card with the features you want
(generally the number of ports, but some companies put the Firewire on
with something else, which is fine). That's pretty much it. Anything
else is based on software.
Dave Haynie | Chief Toady, Frog Pond Media Consulting
dha...@jersey.net| "Get get get get over it!" -Ok Go
"Deathbed Vigil" now on DVD! See http://www.jersey.net/~dhaynie/dbv
Aloke Prasad
--
Aloke
---
to reply by e-mail remove 123 and change invalid to com
"Dave Haynie" <dha...@jersey.net> wrote in message
news:3f01643b....@news.jersey.net...
Markus Zingg
>Typically, AVI 1.0 files are limited to 2GB in length. This is a limit
>enforced, even today, by Microsoft's built-in AVI code. It's not an
>inherent limit, since OpenDML can be used with either AVI format, but
>Microsoft only supports it for AVI 2.0 files.
Your post was fairly acurate and informative, but the above block got
a bit too short ;-) The term "Microsoft's built-in AV" is dangerous
cause these days DirectShow is also built into Windows and DS is able
to read and write OpenDML 1.02 for qute a while now (if memory serves
they introduced it whith DS 7.x)
Then, IMHO AVI 2.0 is just something that is not clearly defined. MS
used this term in conflicting specs over the past. There was even once
a spec out called AVI 2.0 that was virtually a AVI 1.0 with 64 bit
pointers! (i.e. 8 byte for lenght and ofset info and so on) called AVI
2.0. I should have it somewehere on my drive... These days, AVI 2.0
seems to be used by MS for either avi files acording to OpenDML 1.02
or then DV type 1 files which are - as you pointed out - something on
their own header wise but otherwise OpenDML 1.02. Not sure if this
came out clear enough in your text, but DV type 1 and DV type 2 both
can be used (and are used) with OpenDML 1.02 structured avi's. (I.e.
Pinnacle uses strictly DV type 2 within OpenDML 1.02 throughout their
products).
The whole AVI 2.0 term seems to be related to the fact that MS tries
to avoid open standards in their namings due to marketing reasons (avi
2.0 sounds much more like something they invented than OpenDML 1.02
and so on...) Personally I stick to the terms "standard avi's" meaning
avi 1.0 and otherwise OpenDML 1.02.
Markus
Cory
explains it all.
--
Cory Watilo
www.watilo.com
www.soundlightproductions.net
"Aloke Prasad" <apras...@columbus.rr.invalid> wrote in message
news:dpmMa.2862$zE....@fe1.columbus.rr.com...