DV Capture: Please help

bakerbud9 wrote on 1/21/2002, 8:29 PM

I have just installed a new OHCI IEEE 1394 card. It uses the Microsoft drivers from the Windows 2000 CD-ROM. I have installed the DirectX DV Updater patch. My Canon GL1 is detected fine by the capture application, but when I play back, I see pink blocks and "glitches" in the video. I hear static in the audio when these glitches appear. When I play back the AVI file that I recorded, it appears that these "glitches" were recorded into the AVI file. Is this a bad firewire card? What causes this problem?

Sincerely,

Nate

Comments

SonyEPM wrote on 1/22/2002, 8:32 AM
Please confirm:

DMA enabled for all IDE drives

Your disks have been recently defragged

Background apps are not running while capturing

You are not sharing the the 1394 card's IRQ with anything else. Search this forum for "IRQ" for extensive coverage of this issue.
atedee wrote on 1/22/2002, 1:30 PM
Look at any conflict with your devices. I don't think sharing is a bad thing. Besides, with ACPI enabled systems I don't think you can get away with sharing. My 1394 shares IRQ with my SCSI controller and USB but I don't experience such problem. Are you using MB with VIA chipets? Please, post system specs.
bakerbud9 wrote on 1/22/2002, 6:25 PM
I have a dual PIII 850 Mhz system with a SuperMicro motherboard. The chipset is Intel 440BX. I have checked the usual things (defragged 7200 RPM RAID 0 drive, no background apps, etc.) When capturing, my CPU usage is only at about 20%, so I don't think it's a bandwith problem.

The IEEE card is sharing an IRQ with my 3Com ethernet adapter.

--nate
bakerbud9 wrote on 1/22/2002, 10:44 PM

Well, I have confirmed all of the above. On top of that, I have tried two different IEEE 1394 cards (Pyro and Lucent). Both cards exhibit the same behavior.

I have also removed all other cards from the system (including the sound card), and I've used the AMIBIOS to make sure that each IEEE 1394 card had an IRQ that was not shared with the on-board USB or the AGP video.

At this point, I highly suspect a software issue of some sort. But this is a clean, fresh install of Windows 2000 with SP2 and the DV Updater, and I've verified that the IEEE 1394 drivers are the ones supplied by Microsoft (MSDV.SYS).

I am going to take my GL1 over to some friends who have a working IEEE 1394 configuration on thier computer. That should verify that the problem is not the camcorder.

I suppose the actual firewire cable could be at fault, too. I will try getting my hands on another one and seeing if that helps.

Any other ideas?

Sincerely,

Nate Hayes
Sunfish Studio
bakerbud9 wrote on 1/23/2002, 9:59 AM
This appears to be a motherboard problem. I am having this capture problem on a SuperMicro P6DLE, BIOS v3.1. I have installed the OHCI card into two other computers, a Dell Dimension and a custom PC with a Tyan Tiger 100 motherboard, and the video capture works fine on both those systems.

I have been experiencing other conflicts with this motherboard, too. Namely some contention between the on-board USB and the Promise RAID 0 controller.

I think the solution is for me to get another motherboard. Anyone want to buy a brand-new, hardly used SuperMicro P6DBE?

Sincerely,

Nate
deef wrote on 1/23/2002, 10:56 AM
Did you ensure that DMA was enabled for your hard drivers?

Check out this FAQ:

http://www.sonicfoundry.com/support/SupportProduct.asp?FamilyID=30&Family=Vegas&TopicID=89&DetailID=879

Also, do you have UDMA 100 drivers on the mobo CD to install?
bakerbud9 wrote on 1/24/2002, 9:44 AM

My video drive is a hardware RAID 0 of two Western Digital 80 GIG drives connected to a Promise FastTrack100 TX2. I've benchmarked this setup and am getting about 30 MB/sec throughput on reads and writes. This should be more than adequate for a single 5 MB/sec DV video stream.

But the "glitches" appear even when I'm not catpturing video, i.e., even just playing video in the catpure utility causes the "glitches" to occur.

Using the same hardware, OS, and driver versions on two different computers shows no problems. But when I install everything into the SuperMicro, the "glitches" appear. Even switching to a single-processor non-ACPI kernel for Windows 2000 didn't fix this problem.

Bad motherboard.

=(

Sincerley,

Nate
gbohn wrote on 1/24/2002, 12:50 PM
I have exactly the same problem on my Asus P3B-F system (also with Intel 440BX chipset). I have a 1 GHz PIII processor, a Promise Ulta-100 TX2 controller, and have tried a SIIG and ADS Pyro Firewire cards running Win 2000 SP2 (Problem also happens in Win 98 SE).

I get the problem just 'previewing' as well. I noticed both of our systems are 440BX with a Promise controller (although mine isn't RAID).

In my case I discovered that setting my BIOS Front Side bus from 100 MHz to 66 MHz (and thus slowing the system down to 666 MHz) seems to avoid the problem.

Of course, that's not an adequate long term solution...

I've had someone suggest to me that the problem might be with the DirectX 8.1 updates, but I haven't tried reinstalling the OS so I could get back to DirectX 8.

What are the specs of the systems where it did work? Are they 440BX as well? Do they have a Promise card?

Thanks;

-Greg Bohn
bakerbud9 wrote on 1/24/2002, 5:58 PM
Greg,

One of the other systems is a Dell Dimension XPS P3 450 Mhz. The other is a custom PC with a Tyan Tiger 100 440BX motherboard. It seems I can put the 1394 card alongside the Promise just fine in the Dell and Tyan computers, and it works fine.

But here is where it gets interesting: my Tyan has dual PII 266 Mhz processors running at 66 Mhz FSB. There is a problem with the BIOS on that motherboard, so I can't yet upgrade it to support my dual PIII 850 Mhz processors. So I purchased the SuperMicro to use as replacement while I send the Tyan back for repairs. The interesting point is that I've never tried using the 1394 card in the Tyan motherboard while running 100 Mhz FSB.

The Dell, well, I'm not sure what chipset is in there.

Sincerely,

Nate
Rockitglider wrote on 1/25/2002, 4:25 AM
Hello,

This could be a bad memory module as well, Have you tried changing memory?

See ya, Rockit
gbohn wrote on 1/25/2002, 8:42 AM
>This could be a bad memory module as well, Have you tried changing memory?

At least in my case, I'm using ECC memory. I previously tried changing the memory timings from 2-2-2 to 3-3-3 with no effect.

As far as I can tell, I have no other problems which would point to defective memory (Since I would expect bad memory to cause other problems to crop up in other places as well).

-Greg Bohn
deef wrote on 3/21/2002, 9:04 PM
This maybe similar to this issue:

If using a SCSI controller, ensure that it is using a different PCI bus than the OHCI IEEE-1394 card. You can move the IEEE-1394 card to various PCI slots to change the bus assignment. Under Win2k/WinXP, the bus assignment can be seen under the device Properties’ General tab’s Location.

In this case it should be on a different PCI bus than the RAID controller.