With Contributions from many other writers

I’d been having a quick online discussion with several people, and quickly realized that it was becoming quite interesting. Thus, I am formalizing it as a webpage for JerryPournelle.com, which you’re reading right now. The mailing list discussion continues, but it will probably be folded into this version over time.

This discussion started out with a mere question by Mr. Mark Minasi about hooking up his spankin’ new DV camera to a PC. Poor Mark didn’t realize what he was getting into, and so I started throwing some answers back. (If, for some reason, you don’t know, Mark is the author of many fine books on Windows NT and fixing your PC. He’s also a Babylon5 fan and a good friend of mine.)

As of this writing, the text consists of several parts, corresponding to several mailings which I sent out. They, in turn, contain multiple comments and commentaries from various sources. They appear in chronological order for the most part, instead of being digested, to give a flavor of the ongoing discussion.

--All best,

Alex

If you want a few places to find out more about these subjects, here’s a quick set:

There’s a freeform discussion of DV in general and equipment for sale in particular at VideoGuys.

Throughout, "DV" is used to mean "MiniDV". There are at least five Digital Video formats, but only MiniDV is being discussed here and now. A note from Peter Glaskowsky about other formats appears as Part III.

Some of the burning questions I have are below. This is by no means complete! Please add your own.

• What are the common means of data interchange between editing and post products? Are numbered Targas the only/best way? What about their huge cumulative size?
• Why don’t companies with hardware codecs release software-only versions for people who want to read their files?
• What is the future of MiniDV? Will it stay around? Is it going to be this little island of semi-pro production?
• Why is this stuff so hard to do? Or is it just me?

Mark Minasi originally wrote, in the note which started it all:

Hey, Alex, do you know of any Firewire/IEEE 1394 boards for the PC? I've just gotten one of these incredibly neat (and tiny) cameras with an IEEE 1394 output and want to hack around with attaching it to the PC. As The Graphics Guy, I imagine you'll have an idea. Thanks.

See, Mark isn’t only a great guy, he recognizes my superior talents... or, at least, he’s great at flattery.

My reply to Mark was:

Let's see, yes, I do know a bit about these things. David Em and I have been researching them for the book.

Many new W98 boxes have 1394 built in, notably the new Compaq Presarios. I have some really nasty words to say about W98 and power management which are in another page.

In any case, if you actually want to edit DV, Digital Video, you'll need scads of disk space of decent speed. 3.6 MBytes/Second, the speed of MiniDV adds up quickly. That’s four minutes per gigabyte.

Apropos of this subject, Mark Minasi wrote:

Perhaps someone can comment on the reality of the Truevision card.

A digital video/audio stream (does FireWire transmit audio as well?) without compression would be a fearsome data rate indeed -- I figure 24-bit 640 x 480 x 24 bit color, 30 frames per second would be 27,648,000 bytes per second, with audio not included. Clearly no standard hard disk could handle that input rate. I'd always assumed that one of the beauties of a DV camcorder would be that I could go camera-PC-camera without loss, unlike the dread Digital-Analog-Digital implied by a Y/C connector. Am I incorrect there?

My reply:

Yes, FireWire/1394 does indeed transmit audio as well. As Peter Flynn notes below, it uses a 32Kbps rate, not the much more standard 44 Kbps. We’ll get into that in a moment.

Mark’s back-of-the-envelope calculation of speeds would be correct if video were sent uncompressed. However, MiniDV uses a lossy compression algorithm which provides a continuous data stream of 3.6 Mbytes/second. It’s a completely digital format; there is no more data loss from Analog -> Digital -> Analog steps.

This data rate can, in fact, be handled by a single hard drive, witness Peter Flynn’s new Presario, which has an UDMA2 IDE drive that will keep up (if just barely) with this rate. Professional video editing systems use multiple hard drives in pairs or threes or more, usually striped RAID 0. The more drives, the more reliable the data transfer. Since video can ill afford dropping even a bit, this becomes important.

There are, in fact, uncompressed video systems, notably SoftImage|Digital Studio and Play’s Trinity, but they will be discussed another time. Nearly all computer-based production of video is done with lossy compression. This lowers the data rate and means you don’t run out of disk space in ten minutes. Of course, there’s an inverse tradeoff between quality and the compression ratio.

There is also a third parameter under NT: file size limitations. Currently, NT only supports files up to 2GB in size. This quickly limits the size of clips which may be grabbed at once. Several homegrown solutions are being cooked up for this. In-Sync, makers of Speed Razor, transparently links files as they’re captured. DPS solves this by using their own drive array, slaved to their own I/O card. Other people have production boxes which handle all the I/O their own bad selves; this is the Trinity approach.

This 2Gbyte limitation isn’t always dealt with intelligently. The Truevision native capture/playback software, for instance, will merrily capture a file far larger than can be saved; so will Avid’s MCXpress.

There’s another problem with MiniDV: the compression method used is not compatible with that used by analog capture systems. MiniDV uses an MPEG-2 format, while most analog capture cards (e.g., Truevision) use a Motion JPEG (MJPEG) format. In order to work with any two together, you must transcode one or the other into a common format.

And you have to transcode to something lower bit-rate with attendant ghastly loss if you want to store more. Oh, and you can't mix DV with analog without transcoding to a compatible standard.... I could go on and on.

Transcoding is also the only way to reduce the data requirements for MiniDV, because it only runs at 3.6 MBps. This inflexible data rate is unsuitable for low-res work, though of course as a source for web-destined video (or other low-res work) it’s just fine. Transcoding can take significant amounts of processing time, on systems without hardware assistance.

There are new chips coming out which will change all this. C-Cube’s new DVx chips (there are two, at differing data rates) will make it possible to both mix MiniDV MPEG and MJPEG, and transcode in realtime. These chips will be less than $175 in quantity for the more consumer-oriented version. Peter Glaskowsky says that there are two others competing in this market space; I think it’s safe to state that competition is heating up quickly.

1394 is, of course, a fully-featured, high speed bus. It can conduct audio, video and control information—anything which can be encoded digitally. So there is no engineering reason why you can’t have complete control over a miniDV camera from a computer.

But the software is another issue. The deck and camcorder manufacturers have been very sticky about actually letting the machine control information out of the bag. Pinnacle claims to have very good rapport with the mfrs, and that they can back up and grab frames that were missed automatically. I have no direct experience on this.

This logjam is in part because the video mfrs are trying to protect their own "prosumer" lines; after all, if you can do all of this with a $4,000 camera, why buy a $10,000 one? Canon, which doesn’t make any camcorders except their new miniDV ones, doesn’t have a prosumer line to protect and thus may break this logjam yet.

One very instructive observation: at WinHEC in 1995, Bill Gates used an early Sony VX1000 camcorder connected to an early FireWire board to capture digital video. At WinHEC 1998, the same demo was done with an analog capture card.

It’s also instructive that Play still has not released their 1394 I/O boards for the Trinity. I guess this stuff is really hard after all.

I’d said to Mark:

Peter Flynn said:

I ordered the cable from computability.com off the web. I don't know if it is the same as i-Link or not. If it is, I could have gone to Fry’s {Local mega-warehouse computer/electronics store} and saved myself a lot of trouble -- the folks on the phone at Fry’s certainly don't have a clue. The cable has a 4-pin connector that goes into the Sony, and a much larger 6pin connector that goes into the Compaq.

i-Link is Sony’s offshoot of 1394/FireWire. I have yet to see any details on how it differs from "regular" 1394. I’d welcome any info anyone might have.

Peter Flynn said:

I did a bit of editing last night with Premiere 4.2. Works pretty well, but I'm in bad need of a mass (many Gig) fast and reliable back-up storage. 10 Gig for 40 minutes of video. Yikes! Currently I'll back dump to the camera.

One advantage to DV! As long as you’re doing cuts-only, you can dump it back to MiniDV with no further loss in quality. It’s only if you do fades, dissolves, effects, etc., that further loss will occur.

I need to get an update for Premiere so that it can properly handle the 32Ksample DV audio.

As it is now it has slight aliasing when converting from 32 to 44. I guess I'll have to buy Premiere 5.0. The results in 4.2 do look good. I did have one sudden system crash. I think the software was making a statement about the quality of the last couple of cuts I had made (they were pretty ugly -- and were lost during the reboot -- but the project was unharmed overall).

I think there are more FireWire cards out there. I've been trying to see if I can buy the Pinnacle DV transfer utility by itself -- and I still don't know if it will work with the Presario FireWire. -- I tested the motoDV product, and it seem NOT to work with the Presario. The Adaptec transfer utility that comes with the Presario {which does SoftDV encode/decode} leaves much to be desired. I guess it's time to e-mail Pinnacle and the moto people with questions.

I replied:

Premiere 5 still has some serious problems with DV so you might want to stick with Ulead's product (which is bundled with the Compaq), or just use Premiere 4.2 till they fix 5.

Peter Flynn commented:

What's the problem with Premiere 5 and DV? So far, for me, 5 has been more stable then 4, but then I haven't had much time to do much work with it.

To which I said:

Premiere 5 has some general problems, like crashing way more often than it should. It wasn't quite done when it came out. Thus spaketh the newsgroups, and David Em has had some problems, and Mary Wehmeier has also heard these rumors. By sheerest coincidence, all of these people are now on the mailing list.

At 05:03 AM 9/24/98 -0400, Mark M. wrote:

My heavens, a whole thread just for li'l old me. I am indebted ... but of course my thirst for knowledge has not been entirely slaked. Permit me to ask further:

Mark has been asking about doing DV production with his new lil' MiniDV camcorder. My answers, in the main, have been aimed at producing a videotape at the end, whether another MiniDV, VHS, or whatever.

There's an undertone to this discussion, of course; all us computer geeks want to keep everything as digital as possible, and are offended by the idea of going through analog conversions, or anything which causes data loss. As discussed here, you can do tapes (if they're cuts-only; read on) without further data loss. If you wish to send your masterpiece to someone to be viewed on their own computer, the situation is more complex, as is addressed in part II of Mark's Q&;A.

Mark's questions were numbered, and the numbering is preserved here:

Nein! It's compressed all the way. The ~3.5 Mbyte/second stream (the actual rate is under debate; see below) is recorded on the tape compressed, it's sent via FireWire compressed, it's sent back to the camera at this rate. Otherwise, yes, it'd have to be compressed upon hitting the camera, and poof!, generational loss (albeit totally digital).

Also, your original calculations of 27 MByte/second were incorrect, simply because there are not 24 bits of color being recorded or even captured. NTSC isn't capable of that much color fidelity, in any case. Also, lesser formats like MiniDV are throwing color info away before they even record it. It's a "4:1:1" format, which is a term I wish I understood fully. Essentially, though, MiniDV throws away both chroma and luma info before it's even compressed.

Remember, no further loss happens just because it's sent down the FireWire to the computer, or back; it's only when doing effects or working in post packages which don't understand the MiniDV format natively when you'll have further loss.

Most FireWire/1394 I/O boards for a PC are just that: an I/O chip on a PCI board. They pull in that (fully digital, now) data stream and pass it to the disk. Some (notably Pinnacle) have an onboard SCSI port to avoid going to the PCI bus and back.

Now, this scenario does present a problem: you cannot play back any images you've captured without a hardware codec. That is, you can capture it, because capturing MiniDV just means copying the ~3.5 MBps data stream to disk. You cannot play it back, because the data stream is compressed. There are five solutions to this problem:

• Hook up your camcorder/deck to the FireWire port, and view the picture on your NTSC monitor (No extra expense, but you must have the camera hooked up)
• Buy a FireWire board that *also* has a DV codec, such as the Fast or Canopus solutions, which then gets hooked to a monitor (About $3,000 at last count)
• Buy an internal MiniDV deck, such as the Sony, which sits in your computer and acts as both a deck and a codec (About $2,000)
• Use a program which transcodes the captured data to a thumbnail which can be viewed realtime on your computer monitor, and then view that. (No extra expense beyond the program, but transcoding can take hours.)
• Use a SoftDV codec, that is, an all-software solution.

Peter Flynn's Compaq seems to manage this trick with no hardware assist, using the Adaptec SoftDV player. I have to wonder whether there isn't some other onboard hardware they're using to assist, like a versatile MPEG codec. But this may just be my suspicions climbing in where they're not warranted. There's certainly no reason that a software-only solution cannot be made to work at least for playback in realtime, with a sufficiently smart programmer and a sufficiently fast computer. But is a P/II-400 Good Enough?

Now, one "however" about losses just due to transmission between camera and computer. There is a case where I believe such losses happen, and that would be using any tape format but MiniDV and any other player than a standard MiniDV player. Anything faster than the ~25 Mbps (uncompressed) data stream of MiniDV--that is, DVCPro, and of course DVCPRO50 and DVCPro100--use Serial Digital In (SDI), not FireWire. SDI is fully digital, but it is my impression that it's a full-speed, uncompressed format.

Now we get to another whole area of contention. You want to do something besides take the video, edit it, and put it back on tape? Now you must transcode it to something that can be read by your target audience. MPEG might be a good choice as MPEG decode hardware becomes ubiquitous, but of course requires hardware. What about a software-only solution?

There's hardly any unanimity on this subject; some people like Real Media because there are players for PCs and Macs, some people like QuickTime because there are good players for UNIX, too.

There are replacements for AVI a-comin' along. Microsoft has two initiatives, AAF and ASF, which we will probably discuss in future messages.

Now, back to production. You must also transcode if you have an existing stock of video captured in some other format, e.g., Hi-8 or etc. Captured on a Truevision card. This is of paramount importance if you want to mix work from multiple sources, as most videographers will want the option to do. Once created, of course, you then face the same problems mentioned above if you wish to then send it out to the Net, or as a CD-ROM, or in any way other than videotape.

Ahh, that it was! But then that's why David and I are writing this whackin' great big book on the whole subject. Your questions have just sparked a discussion I was itching to have anyway.

Mark had asked:

Peter Glaskowsky replied:

I'd also said:

There are replacements for AVI a-comin' along. Microsoft has two initiatives, AAF and ASF, which we will probably discuss in future messages.

Peter replied:

As a followup to the above, I’d like to know if anyone has experience in using QuickTime to distribute audio on CDs for either PCs or Macs. Does Sound Forge do an adequate job of transcoding .WAVs to QT format?

This also presumes that your captured cuts are all under 10 minutes or so, since there is a 2 Gbyte file size limit on both PCs and Macs, currently, unless something happened while I wasn’t looking.

I believe what Jim is saying is that the native MiniDV format isn’t handled directly by After Effects (AE), so the data has to be transcoded to the native format before any other processing happens. Any code/decode cycle is going to lead to compression loss, of course.

I have read elsewhere that M100 does this; however, AE and sundry other products don’t do YUV, so all data must be transcoded before it’s used.

It’s not clear to me whether he’s talking about video that’s transcoded for use in Premiere, edit* and the like, or if he means the native data rate inside the computer, when you’re watching it on your computer’s monitor.

But you can make the animation be rendered at the target resolution so as not to waste extra disk space. How intelligently your average 3D program deals with the target resolution, codecs, interlace vs. non-interlace, etc., is a subject I’d like to know more about.

As for data rates, "knowing" what the program wants or produces can be a poser. It presumes you can find out those characteristics, which are sometimes difficult to ferret out. And most programs keep the information to themselves, for the most part.

Are these truly broadcast quality? The audio isn’t captured at the standard 44KHz rate, and must be upsampled from the native 32 in order to work with it. In addition, the consumer camcorders don’t have XLR inputs. Are commercial producers actually using the XL-1 or Sony’s XL-1000 for production? I’ve also read that the XL-1’s audio has a serious hum problem, but this may have been solved.