RAID & Video Capture?

[SpideyCU]

I was planning on buying a PCI RAID card for my next system, however, I stopped to think about something. One thing I do a lot of is video capture through a Leadtek WinFast TV2000 XP. Now, if I'm capturing video and writing the data to the RAIDed drives, will this cause a peformance hit to the video capture since all of this is going through the PCI bus? (video in through the PCI TV card, over to the PCI RAID card) Or, is my concern baseless, unfounded? Will there be enough bandwidth for all this data anyhow? If anyone can answer, please cleanse me of my ignorance. Thanks.

 

[SpideyCU]

bumpity bump bump bump

 

[Bovinicus]

I doubt it would saturate the PCI bus. If you feel like doing some math, there is a way to find out. First, found out how much information each frame requires. Take the resolution of the images being captured, multiply that number by the number of bytes per colors (Not bits, divide by 8), then multiply that by the number of frames per second are in the capture. This will tell you how many MB/s the video requires. As well, the RAIDed drives will never be writing faster than the video capture card can supply the information. So, the performance gain could theoretically (Not likely) be impacted, but it should not cause a performance loss.

 

[dszd0g]

Video editing on a 3 or 4+ HD, 2+ channel RAID 0 set-up I can see you saturating the PCI bus.

I am not that knowledgeable about video capture.

NTSC TV is only 30fps 640x480 (Well 60 half frames) plus audio, I don't see you saturating the PCI bus with that but I guess it depends on the software you are using. Most software uses about 1152kbps for video and 224kbps for audio (for a total of 172KB/s) to disk if it compresses it on the fly. If you do uncompressed it would be about:
33GB/hour * 1024GB/MB * (1hour/60minutes) * (1minute/60 seconds) = 9.4MB/s

Well actually I've heard figures anywhere from 30-60GB/hour uncompressed. Even at 60 that is around 18MB/s. However, most video capture software won't do uncompressed.

That still isn't anywhere near what is needed to saturate a PCI bus. The PCI bus can do 132MB/s 32-bit/33MHz. Come on there are even PCMCIA video capture cards, we aren't talking about serious bandwidth here.

 

[SpideyCU]

OK, thanks for putting it into perspective, Bov and dsz. I normally *don't* try to select one of the more efficient compression codecs when capturing because the card doesn't do it itself - it's done through software. re: 30-60 GB/hour uncompressed, I can imagine that's true, but the largest files I usually capture, before compressing them, are around 8 GB/hour. I guess my concern about the bandwidth itself was silly, it was just that I've seen driver hacks to permit capture cards to have priority on the PCI bus. I took this to mean that other devices interrupted it enough that it could be a concern - and a RAID card, when capturing video, would take up along a lot more information than a simple NIC.

Anyhow, I'll go ahead and plan to add a RAID card to my nForce2 (if the damned thing ever comes out). Thanks again.

 

[Demon-Xanth]

Even if you don't have a PCI raid card, you can still saturate a data bus or two since the data still has to be written somewhere (or do you capture to /dev/null?)

 

[Pariah]

"I guess my concern about the bandwidth itself was silly, it was just that I've seen driver hacks to permit capture cards to have priority on the PCI bus. I took this to mean that other devices interrupted it enough that it could be a concern"

That's exactly the issue and why the hacks are available. It's not a case of bandwidth limitations but something else interrupting the flow of data through the system to the capture card. Video capture using most codecs does not use very much bandwidth, but the data transfer is constant so even a slight hiccup in the system can cause unwanted dropped frames. Getting a faster hard drive will not get rid of the problem if it exists. Rule #1 for avoiding this problem, is to not have a NIC in the system.

 

[dszd0g]

Yes, I can definitely see video capture card needing priority on the bus. I like Pariah's post.

I don't see a RAID card hurting things, it gets the data transfer over with sooner. That is assuming you aren't trying to multitask and do some unrelated data transfers while the video capture is going on. Correct me if I'm wrong but most motherboards onboard IDE still uses the same PCI bus as is used for the PCI cards. Some of the server motherboards have more than one PCI bus, but I didn't think most desktop motherboards do.

 

[Pauli]

Yes, dszd0g is correct: even onboard IDE connectors are on the PCI bus. Whether your disk controller is on the PCI expansion bus or internal bus should make no difference at all. I don't have any expert knowledge on this subject, but someone please correct me if I'm wrong about this.

 

[SpideyCU]

Originally posted by: dszd0g
Correct me if I'm wrong but most motherboards onboard IDE still uses the same PCI bus as is used for the PCI cards. Some of the server motherboards have more than one PCI bus, but I didn't think most desktop motherboards do.

Oh, no, you two are absolutely correct. I didn't mean this as PCI RAID vs. on-board RAID question, sorry if it came across that way. I just figured that non-harware RAID controllers would be acting more on the bus than regular IDE ones, given that they've got a bit more work to do. But, again, that's just an assumption on my part, could be another one of those "unfounded" things.

I will have a NIC in the system that'll be doing the vid capture, but if that would be a pest as Pariah indicated, I'll disable it when entering long sessions of capture.

Thanks for the confirmations & revelations fellas.

 

[Pauli]

Hey SpideyCU, I wouldn't necessarily assume that IDE RAID controllers are any more "non-hardware" than on-board IDE controllers. In fact, I believe the PCI vs. On-board interface distinction is actually no difference at all. There are indeed many variations of IDE RAID controllers, depending on the manufacturer implementation, but the fact that it is an add-on PCI card does not account for any performance difference. In fact, I think there are many more advanced PCI IDE controllers that have much more hardware based processing than the On-board variety controller, many of which are so-called "Lite" IDE RAID controllers.

Another thing I don't understand is Pariah's Rule #1 about not having a NIC in the system. To be sure, you don't want to have any network traffic or extraneous disk activity occuring during a video capture or editing session, but having a NIC in the system does not mean there will automatically be any network traffic going on at the time of the video processing. I have a 3 node network at home and, on my video editing machine, if I close the browser and turn off my anti-virus and task scheduler, I am pretty certain there will not be any significant network activity going on. I mean, it seems like such a draconian restriction to have on a video editing system.

 

[dszd0g]

Originally posted by: Pauli

Another thing I don't understand is Pariah's Rule #1 about not having a NIC in the system. To be sure, you don't want to have any network traffic or extraneous disk activity occuring during a video capture or editing session, but having a NIC in the system does not mean there will automatically be any network traffic going on at the time of the video processing. I have a 3 node network at home and, on my video editing machine, if I close the browser and turn off my anti-virus and task scheduler, I am pretty certain there will not be any significant network activity going on. I mean, it seems like such a draconian restriction to have on a video editing system.

I have not seen any information to back Pariah's claim, but if I had to guess I would say that I believe him.

Even if your computer isn't itself generating any network traffic any broadcast network traffic generated by other machines on the network (and Microsoft protocols generate a fair amount of broadcast traffic) still has to be processed. If you are on a hub instead of a switch, the NIC has to look at every packet on the network to determine if it is meant for it or not. If you unplug the network cable it should solve those issues.

 

[db]

from tom's:
"...NIC controllers on the motherboard can also cause problems unless they can be disabled during video capture. ATA-66 or ATA-100 on the motherboard is preferable to using separate controllers....The most common problem with installing video capture devices arises from IRQ conflicts."
Tom's Hardware

 

[SpideyCU]

Pauli, by non-hardware, I meant software RAID cards as opposed to hardware RAID cards. I don't think anyone refers to the location of RAID controllers as "hardware" or "non-hardware". Software RAID cards need to send data over to the CPU which actually determines how the data is broken up, then the data is sent back to the RAID controller to be properly striped across the multiple drives. Hardware RAID controllers have an integrated chip to handle this - thus, when they have to write to the drive, there isn't any more bouncing of data to determine what should go where. Similarly, a drive connected to a regular IDE channel shouldn't generate as much extra traffic of data-checking as the software RAID controller. That's what I said/meant.

We'd already gone over the fact that on-board and software PCI RAID controllers behave nearly the same. Regarding the NIC, it's easy enough to simply disable in the Windows control panel, so that's what I plan on doing. If a device is completely unnecessary for vid capture and might toss out unwanted interrupts (it's also one more device to poll, though that really shouldn't affect anything in and of itself), I see no reason to keep it enabled during long blocks of capturing.

Edit: db, good read, later on in that review, they even specifically say "NIC cards can be problematic and you might want to disable them during capture sessions." - on the "Other Peripherals" page.

 

[rbV5]

I don't use a PCI card for capture, but for comparative sake, I've used both a PCI RAID card on my prior board, and now my onboard RAID for my capture arrays. I'm capturing right now while online typing this without dropping any frames (d20L client also running btw).
Tried both:
* MPEG-2 capture DVD High preset (720X480 NTSC 8 MB/sec 48.000 KHz 16bit stereo audio)
* RAW uncompressed AVI (640X480 UYVY NTSC 44.100 KHz 16bit stereo audio)
I really don't notice any difference as far as dropping frames, but my present ALI board has much better ide transfer rate over my old VIA board, both work(ed) very well and much better with long uncompressed captures over a single ide drive. I wouldn't recommend surfing the web or DC projects while capturing...but it does illustrate that you should be alright as long as you have a moderately powerful rig with decent ide performance, even with nics, RAID cards ect.

 

[AluminumStudios]

Forgive me for not reading this entire thread before answering ... I hope I don't repeat anything.

I do a lot of video editing and I capture to an IDE RAID0 with 2 drives. It works GREAT for me.

First of all, adding RAID will open up the bandwidth betwenn the controller and your hard drives. If you can capture to a single drive already, I don't see any way adding badwidth between the drives and their controller will hurt you. The SAME amount of data is already flowing through your PCI bus when capturing to a single drive. Latency from the drive system will be less of a factor for dropping frames now.

Most capture now occurs at 720x480 x 29.97 fps. Worst case scenario this data is internally represented as RGB. So at 24 bits per pixel x 720 x 480 x 29.97 you get ~31 megs/second + approx 172 kb/sec for CD quality audio. This is still FAR from saturating the PCI bus. Even if you doubled that for say video being shipped to the video card for display while you are capturing, it's still only 1/2 of your PCI bandwidth.

I've found the lower latency of RAID to be GREAT for video work. I recommend using a very large strip size (256 kb or larger) for the large streams of video that you'll be writing.