Ordered a new capture card

[Flying dutchman]

Landrover:

I just read a post in a newsgroup about a guy having the same problem with frame drops on a raid-0 system. He also could capture perfectly on a "normal" drive.

He could solve his problem by pulling out all USB devices plus printer before capturing. It appears these devices do some background communication all the time.

Raid-0 may be very fast on the hardware side, but its firmware and software make it consume some more CPU power than a "normal" IDE channel.

[Flying dutchman]

Landrover,

which bitmap format (rbg32, YUY2...) do you use to transfer the data from CinergyTV to the codec?

[landrover]

Môgge Dutch,

I capture in the YUY2 colorspace. And about this USB thing: when capturing uncompressed or Huff encoded video I have CPU load @ about 40%, so it´s probably not the RAID, nor the CPU. But what the hell is it, then?

[Flying dutchman]

Hoi Landrover,

Could it be a scanner or printer that's reporting its presence every few seconds?

Have you tried a throughput speed test on the Raid, to verify that it doesn't have any glitches?

If HuffYuv @ 305x288 works, how about Picvideo @704x576? The data rate is comparable.

[landrover]

No scanners or printers attached at the moment, but I remember reading on this forum long ago that ACPI also has it's disadvantages performance-wise. Can you confirm that?
I'll do some testing with PicVideo tonight, along with a burst rate test, although I don't expect too much from it. A read test revealed around 62MB/s and a write test would destroy data for which I don' t have other space yet. I'll let you know...

[Flying dutchman]

Still bad luck here - computer rebooted spontaneously after capturing 6.5 gigabytes. And yes, I have ACPI enabled - used to work brilliantly with Marvel+Avi_Io. Maybe I oughta give WinXP a try?

I let the task monitor run while capturing; it showed a cpu load varying cyclically between 30 and 60 percent while capturing 480x576 Picvideo.

[Indiana]

Hmm, I did a PicVideo MJPEG 704x576 capture of about 90 mins recently (manually started, have not yet tried the scheduler) and dropped 12 frames.
Colorspace is of course YUY2, OS is Win2k, capturing to a RAID0, this was with the 1.4 drivers and the latest non-Beta Cinergy app.

[Flying dutchman]

I have never had to doubt the stability of my system, I've literally captured terabytes using the Marvel. It could be either an ACPI or driver issue; I've read somewhere that the WDM driver model is better/more stable in Windows XP than in 2000. It could also be that one of my other drivers (LAN? Firewire?) doesn't cope with shared IRQ's too well. On my system IRQ's 5,7 and 11 are available; Windows 2000 packs a zillion devices in IRQ 9.

I'll do a non-acpi test install of Win2000 and XP on a separate hard drive and see how it performs.

[landrover]

Indiana,

with that rig of yours it must be possible to capture full frame DivX!
What bugs me though, is that I don't get full frame rate (25fps), although I don't use CPU intensive codecs and I don't have more than about 40% CPU load when capturing.

I have 2 RAID arrays defined. To have the most benefit from the new ATA133 system drive, I put the drive on the Promise controller in a spanning Array.
The other array is the RAID-0 array containing the 2 80GB drives.
What I'll try is this: take the system drive from the RAID controller and put it on the good old UDMA33 IDE bus. That way the RAID controller has to transport capture data only through the PCI bus. See what that does for capturing....

[Flying dutchman]

I installed XP on a new hard disk (ACPI mode) and installed the Cinergy software from CD. I tried capturing in 480x576 resolution, YUY2, Picvideo. I tried to record from a random TV channel.

Initial capture, performed manually without scheduler, stopped spontaneously after 10 minutes.

Second try made it 30 minutes.

Third try (now using scheduler, set to two hours) ran the full two hours.

Fourth try (now using HuffYuv plus scheduler) stopped spontaneously after 27 minutes. The scheduler marked the recording as "aborted". Aborted by whom, may I ask? Is this some poorly working Macrovision protection?

[Indiana]

I can capture DivX full-res at realtime. Just have to use the "slow" setting instead of "slowest", CPU-load is somewhere between 60% and 90% depending on the video and I drop about 1 frame every 5 to 10 minutes, again depending on the video.

When capturing, the fps is at 24.8 or 24.9. But then I've up to now only tried recording from clear sources (TV-tuner), maybe the results are worse when using bad old video-tapes? Not tried MacroVision encoded material, either.

And I think I have to revert my above statement. The card seems in fact to work even a bit better in WinXP than in Win2k. It was just that my XP partition was old and maybe the old Hauppauge drivers were interfering in some way. After a clean new install I have no problems in XP.

[keithm]

to raid or not to raid-that is the question

I've frequently read that raid is great for normal file storage and uncompressed video (where the data rate is above that of a single hard drive), but for the typical data rate domestic video capture, 1.5-6mb per second it is slower than using a single drive. I suppose it's because instaed of lots of small files the video file is one big one and it don't take kindly to being split over two drives.

[Flying dutchman]

The problem I see with Raid-0 is that it saves the data in 64-kb stripes on both drives. So every read/write operation can involve a "burst" of 128 megabytes. Even if the chipset is good enough to give you the full 133 MHz per second PCI bandwidth, it is still under full load for 0.1 seconds. I prefer to run my drives at a conventional UDMA-33 so there's always bandwidth to spare.

[landrover]

Every read/write burst CAN involve 128MB, you say. But it doesn't have to be that way, does it. If less data is presented, the burst would involve less data. So full load would only apply if the maximum data-rate is presented. Or am I missing something here?
Other question. Are all software MJPEG codecs equally CPU intensive? I don't have PICvideo installed, but I do have Mainconcept MJPEG. So maybe I could do your proposed test- capture with Mainconcept, rather than having two (possibly conflicting) MJPEG codecs installed.....

[Flying dutchman]

Update: I think I got it working now.

I tweaked the WinXP test setup a bit; set it to "standard PC" instead of ACPI. I created a new "capturing" hardware profile and re-booted into this profile. Disabled all device drivers I don't use for capturing. Tweaked the bios setup a little bit so the Cinergy has an IRQ all by itself. No shared IRQ's in use at the moment. Then I let CinergyTV capture 80 minutes using 480x576 HuffYuv and let it run until it smoked. It produced a perfect 35 GB AVI file, meaning a data rate of 7.3 megabytes per second. It dropped 21 frames in total.

I'm going to test the same thing using full-frame (720x576) HuffYuv now, and subsequently with full-frame Picvideo. Also I want to know what exactly happens if the disk gets full.


--------------------------------------------------------------------------------
Update #2:
I let it capture for 80 minutes @720x576 HuffYuv. After 69 minutes the hard drive was full. The program showed a "directshow exception" and stopped capturing. The AVI file was 39 MB in size and perfectly in order. Average byte rate 9.4 megabytes per second. Dropped frames: 45 in total.


I don't intend to start using XP so my next try is to see if I get it working under Win 2000. Maybe it's possible to give the Cinergy a separate IRQ and still use ACPI? It's worth a try anyway.