Video Capture Hard Drive: IDE or FireWire

[JeromeERome]

I just got a new video capture card and realized that my extra 40GB HD I am using for my capture disk is only 5400RPM. I am unable to capture at high DVD resolutions using the Huffyuv codec without dropping frames or losing audio synchronization. I plan on purchasing a new 7200RPM drive. I am trying to decide between a Western Digital Caviar drive which is UltraATA 133 on an IDE bus or a FireWire based HD. The firewire seems like it would be faster since it can run up to 400mb/s bus. Anyhow, what are you guys using in your systems and which would you recommend for video capturing/editing?

[avih]

dropped frames and sync issues are not always due to slow HD.

i'd suggest disabeling your audio capture to see if the dropped frames is a HD only issue. if everything fails, you could try mjpeg, which is a bit lossy, but uses less space than huffyuv. you can also check out that the dma settings are the highest for your drive.

read the capture guides/faq for more information about dropped frames.

[gooki]

Do you have a via chipset motherboard?

If so a 7200rpm hdd may not fix your problem. Also give mjpeg at max quality a go to comfirm if it's your hdd, or something else (ie software/via chipset etc).

And i wouldn't bother getting a firewire hdd, unless external storage is a priorty for you.

[Hiro2k]

Why get ATA/133, only the newest Via chipsets support it and Intel doesn't support it at all since Serial ATA is comming out soon. If you really want fast, wait for the new Serial ATA which is not a long wait. And ATA/133 will cost you more because there are more ATA/100 on the market that stil haven't been sold. 133 is a dead end for companies because they know Serial ATA is much better, delivering transfers up 150MB/s and thats what people are going to want.

[tiki4]

Well, ATA-100 or ATA-133. I guess the latter is just a marketing gag to sell drives. Most - if not all - hard drives cannot even use the max of 100 MB per second. It is just burst transfer that reaches some peak values while continuous transfers are much slower even with the fastest drives. Attaching RAIDed disks may use the maximum transfer rates a little bit better.

SATA is on its way but I really doubt that people want SATA because of its faster transfer speeds. In my opinion SATA gives more important advantages over 'classic' ATA: For example the cables are thinner which helps greatly to keep your head, eh CPU cool. Also they finally give up the parallel concept so you finally no longer have to care for Master and Slave and stuff like this. With this the limitation for two drives on a controller falls so you finally can attach more drives, etc. Nevertheless I doubt we will see SATA so fast in desktop computers. Maybe next year...

Finally, I strictly vote against Firewire hard drive. This is a good choice for externally connected drives but when it comes to speed... AFAIK most Firewire drives contain IDE drives which means some chip in the external box has to translate Firewire commands in ATA commands which seems to be a quite slow process. There are benchmarks around...

Regards,

tiki4

[JeromeERome]

Thanks for all your advice. I tried using a couple other different programs and codecs for capturing video. The one that worked best for me was surprisingly Ulead's Video Studio 6. I captured to AVI using its default codec (which I am unsure what exactly that is). It just said YUYV or something like that. Anyhow I captured at full 720x480 with very little frame drops (20 out of 10000 frames) The audio was synched perfectly. The output file was comparable to using a huffyuv codec. The files averaged 1GB/min. I was impressed that Ulead was capable of this quality. Has anyone else used this application?


-JeromeERome

[avih]

damn, 1G(!!)/min??? that's 17M/sec :) i'd say the problem is NOT your HD ;)

[gooki]

If you are getting 20 frame drops out of ever 10000 then it definetly sounds like the old via chipset issue. Idealy zero frame drops is prefered but you won't be able to acheive that unless you change your motherboard or get a hardware based capture card, so i'd be happy with what you've got now.

[JeromeERome]

Yes I guess it is safe to say that the HD isnt the problem or the bottleneck of my system. It was the MMC software that came with my ATI Radeon card.:devil: Now that I have switched to Ulead's Video Studio I have had no probs. The only reason to get a new HD now is for more space. Currently I have 40GB and would love to have 80-120GB. What is this "via chipset" thing that you mentioned? I know there is no way to fix it without new hardware capture or motherboard I was just curious what it is!

[gooki]

The via issue has to do with your motherboard's pci bus chipset. Aparently via's pci bus isn't the most efficient and can cause random frame drops with capture cards. It is by no means crap, just not 100% efficient.

By moving to a hardware based capture card, you lower the amount fo data going through the PCI bus thus it shouldn't drop frames at all

[Ookami]

From the new capture FAQ (work in progress):

20.) When capturing I always get dropframes

- When TV and sound device are not working at the same clock speed
or the computer is not fast enough, VirtualDub will drop frames
during the capturing session. The captured movie will not contain
such frames. Ideally you will get no such frames. But let's for
a second assume that you do. In PAL we have 25 frames per second.
If 75 frames (corresponds to 3 seconds of video) have been dropped
during a 3h recording session you will not be able to notice the
difference visually but with audio you will notice that the movie
will get asynch. Therefore in VirtualDub you should always activate the adjust
video clock option (in Virtual Dub:
Capture -> timing -> activate Adjust video clock) which
ensures that video and audio stay in synch.
If you like to know more about dropframes:
http://www.voncancrin.de/Capture/dropps.htm
In other programs there are other options to avoid drops or to get audio and video sync afterwards.


21.) What can I do against dropframes?

- First lets clear some misconceptions that many users have. Dropped frames
are not disease that needs to be cured. It is simply a solution to maintain
the A/V sync by dropping or doubling a
frame. The catch is, when you have so many dropped frames that you notice
them (the video "stutters" then the problem is NOT your capture software
(if you use a good one) but in your system (software and/or hardware). It is
normal that Huffyuv clips stutter as this codec was not meant to be used for
playback, first encode it to your desired format, if the picture then
"stutters" you have probably some problems.

You can also (example VirtualDub), disable the "adjust video clock" and try
to synch the audio after the capture (not recommended, but possible). So,
you surely have no dropped frames (at least not from the A/V sync
algorithm).

Anyway, we recommend you to use the excellent VirtualDub modification
VirtualDub_sync by Andreas Dittrich (
http://www-user.rhrk.uni-kl.de/~dittrich/sync/ ).
It uses a different approach to maintain the A/V sync, a real time audio
resample routine and it droppes only frames if the resample routine would
add audible errors.

Most users that got too many dropped frames have simply not optimized their
system. So we suggest you to go through these recommandations, also take a
look at Q4 .

- DMA
- defrag your system and capture disk (you can also quick format your
capture disk if you have nothing to loose on it)
- turn any
- always restart before your capture (memory managment on Windows 98SE
sucks, and W98SE is, currently, the best system for capturing)
- lower your capture resolution or framerate (changing the framerate should
be the last resort, always keep the framerate same as the source, eg 25 for
PAL)
- use a separate HD for your captures (on a different controller than your
system disk), be sure your HD is fast enough (you can use, for instance,
VD's benchmark)
- try Picvideo ... Loeschen! IMO, besser: Try to change your codec setting
and/or try a different capture codec (e.g. MJPEG based instead of Huffyuv)
- screen resolution
- activate cropping (only useful for 16:9 video where you can crop the black
bars)
- make a fixed swap file or disable it
- try a different capture software (you could first try the freeware
programs and then switch to the shareware programs :) )

If all fails (still too many frame drops) try a capture without sound, if
you have NO framedrops for a long time, then your soundcard is giving a
sampling frequency that is way of the desired (instead of, for example,
44100). Possible solutions to this problem (wich for instance Ookami has)
are:

- use VirtualDub Sync (if not yet)
- try to change the frequency
- fiddle with the settings in MULTIMEDIA - AUDIO - Recording adv. properties
(Sample rate conv. and hardware acceleration)
- buy a better souncard :D


22.) I did everything by the book but it simply doesn't work!

Here are some hints. Use them with care!
- Get the latest driver for your capture device or try an alternative
one (like BtWinCap).
- Get the latest drivers for your mainboard.
- Remove every PCI card except your capture device and GFX card.
- If it works with only these two insert your soundcard.
- Use the video input of your GFX card instead of the one of your
capture device
- Try another operating system.
- Deactivate unused HD controller(s).
- Change the screen resolution to 800x600, 256 colors and 85Hz
refresh rate.
- Use the latest DMA drivers for your mainboard.
- Switch PCI/AGP Latency to 32 in your BIOS.
- Use regular 33 pin cables for your UDMA disks.
- Turn off ACPI mode in the BIOS.
- Reinstall your operating system and use the latest drivers.
- Monitor the CPU temperature while you capture. Your CPU may
get too hot.




Cheers,

Mijo.

[natedawg]

Originally posted by tiki4

Finally, I strictly vote against Firewire hard drive. This is a good choice for externally connected drives but when it comes to speed... AFAIK most Firewire drives contain IDE drives which means some chip in the external box has to translate Firewire commands in ATA commands which seems to be a quite slow process. There are benchmarks around...


Yup, any "firewire" HD out there is just an IDE drive with a translator for firewire compatibility. This would not be what you want. :)

[4lex]

RAID-0 is the way to go IMO. Got a couple of 7.2k 60gb IBM disks; I've yet to find any sustained data transfer which can max them out. I'm using an Athlon at 1.5ghz (150) & 1gb ram on an ABit KT7A under Win2k/sp3. I run a seperate ATA/100 7.2k 40gb disk for boot, system, apps and swapfile.

[FWMan]

NateDawg, OOKami.

Yep You are right about the conversion from/to FW to IDE.
But the thing is the charactoristic of the bus, which made all the different.

Why SCSI better than IDE, simply because of its multithread I/O capability. Remember IDE or SCSI transfer rate pretty much the same ( meaning data flows from the plate to reading heads)

FireWire have both charactor of SCSI and IDE, therefore is the best for the money...
Try to capture a video stream with your IDE and FireWire (same HDD different interface) you will see.

Also refer to
showthread.php?s=&postid=172223#post172223 (http://forum.doom9.org/showthread.php?s=&postid=172223#post172223)