MPEG Artifacts/Packet loss on capture at DVinfo.net

Adam Gold · March 7th, 2009, 08:22 PM

This was originally in the Cineform forum, so apologies if you've already read it there. But it's now starting to look like it's a hardware problem not related to Cineform and I'm going nuts trying to figure it out.

Basically it's about half the time -- more, recently -- when I capture a long tape (as I have to do for multicam) everything starts breaking up about halfway through and I have to recapture -- which doesn't always work. Recently I've had to recapture some tapes four or five times just to get an uncorrupted file.

Here's the original thread, and if anyone could take a look at it and share your thoughts, I'd be deeply appreciative.

http://www.dvinfo.net/conf/cineform-...e-problem.html

Jeez, could it be something as silly as the FW cable?

Boy, it's almost enough to make you want to go tapeless...

Peter Manojlovic · March 7th, 2009, 08:53 PM

Adam....
Does this happen during playback at the exact same spot everytime??

I'm just wondering if it's dropped frames from the tape giving you the headaches??

Adam Gold · March 7th, 2009, 09:45 PM

The tape is perfect -- I watch it on an HDTV monitor while capturing.

The thread I linked to shows all the troubleshooting steps we've gone through so far. (Many thanks to David Newman at Cineform, who helped even though it's clear it's not a Cineform problem.)

Ron Evans · March 8th, 2009, 01:14 PM

Something is clearly interrupting the capture. I know you have probably been through all these but the list would include:- virus scanners/firewalls, auto update of programs, email schedule( shouldn't really have email on the editing PC!!), power management/screen savers ( make sure everything is set to "on" permanently, monitor, disc drives etc), Years ago on a low power system I had the same problem and it turned out to be the screen saver/power management on the monitor, since it had a higher priority than the capture, just for a moment.

Ron Evans

Adam Gold · March 8th, 2009, 02:09 PM

All good suggestions; I actually make sure to confirm all that stuff before I start a project. I will continue to scour for anything I might have missed. I bet it's something stupid.

Tripp Woelfel · March 8th, 2009, 08:21 PM

As you note, there are a number of things that can cause problems such as this. When I was having data corruption issues with external USB drives, I replaced the USB cables and all was good after. Sometimes it is the simplest thing.

I'm starting to get religion on tapeless. No doubt it is the future.

Andrew Crain · March 10th, 2009, 09:58 AM

I've built many systems specifically for A/V capture/encoding, streaming, etc for several years, and have run into these issues many times. Here's a couple of the more common issues that result in the behaviors you've described:

You might be experiencing device contention on the system bus. This might not be relieved by adding a seperate firewire card because the slot used might also be sharing resources with another (or the same) device - disk controllers, network, display, etc. This applies to more than just interrupts. Contention occurs when two devices need access to the system bus at the same time, and if something is using the bus when your firewire card wants it, it has to wait. Since video capture is usually a real time process, the only recourse is to drop a big chunk of data and then just keep going. This reason this doesn't happen for a while might be due to some kind of housekeeping or other periodic processes that occur at some point during the transfer, putting additional load on the bus, and thereby creating the contentious circumstance. The general issue here is that the load on the system bus is periodically too high. Audio/Video transfers are particularly resource-intensive when it comes to the system bus, and wholly and completely intolerant to any contention at all due to their real-time nature.

Unfortunately, diagnosing & determining this for sure is not trivial. You have to look at the technical specifications of the system board to determine if this is the issue - specifically, examine closely the system board block diagram to understand how the PCI bus is laid out. Look at the bus layout for the expansion slots as well as any and all integrated devices, and see who's sharing with who (integrated devices also use the system bus). This document is not always available, especially for consumer-type systems like Dell, HP, etc. However if you built up your own machine and used a Tyan, SuperMicro, or similar main board, the user's manual or specifications document for this should be available from the manufacturer's web site.

The good news is that depending upon the layout of the system bus, you might be able to simply change that firewire card to a different slot and solve the problem. The trick is to find out which slot (if any) is not sharing with another device, or if all slots are sharing, try to find one that is sharing with a device that can be disabled, like a USB port or something.

Another possibility is an inadequate power supply, if you've added stuff to the machine like additional HDDs, RAID controllers, that firewire card, etc., then you might be pulling more wattage than that for which the power supply is rated. This would cause intermittent system hangs among other strange intermittent problems.

Determining this is even less trivial than the system bus layout. The power supply has three rails of power, +12v, +5v, and +3.3v. You have to go through the specs for each and every device in the machine, find its power consumption as applicable to all three rails, and add them all up. This includes EVERYTHING in the system, the mainboard, the CPU(s), all disks, all add-in cards, CD/DVD drives, everything. If the sum of all devices' wattage usage exceeds that for which your power supply is rated, then it's time to go out and buy a bigger power supply. Again, these specs are usually in an appendix of the devices' manuals or technical specifications, so the biggest challenge is going and finding the information. It is not enough to simply find any HDDs wattage rating (for example) - it has to be the specific make/model in use.

None of this is trivial, which is why there is so much more to the design/development of a video-enabled computer system than just sticking a couple of PCI cards and a bunch of HDDs into a Dell or similar off-the-shelf computer and expecting it to just work. There really is more to it.

Hope this helps.

Adam Gold · March 20th, 2009, 05:47 PM

Possible -- and I emphasize that this is only a maybe -- solution posted on the original thread linked to at the top of this one, if anyone's interested.

May have had something to do with original capture devices, although we can't figure out what or why.

Thanks for all the suggestions, and you can bet I'll be back to this topic if/when I fail again.

March 7th, 2009, 08:22 PM	#1
Adam Gold Inner Circle Join Date: Jan 2007 Location: Woodinville, WA USA Posts: 3,467	MPEG Artifacts/Packet loss on capture This was originally in the Cineform forum, so apologies if you've already read it there. But it's now starting to look like it's a hardware problem not related to Cineform and I'm going nuts trying to figure it out. Basically it's about half the time -- more, recently -- when I capture a long tape (as I have to do for multicam) everything starts breaking up about halfway through and I have to recapture -- which doesn't always work. Recently I've had to recapture some tapes four or five times just to get an uncorrupted file. Here's the original thread, and if anyone could take a look at it and share your thoughts, I'd be deeply appreciative. http://www.dvinfo.net/conf/cineform-...e-problem.html Jeez, could it be something as silly as the FW cable? Boy, it's almost enough to make you want to go tapeless...

March 7th, 2009, 08:53 PM	#2
Peter Manojlovic Major Player Join Date: Jun 2007 Location: Hamilton Ontario Posts: 769	Adam.... Does this happen during playback at the exact same spot everytime?? I'm just wondering if it's dropped frames from the tape giving you the headaches??

March 7th, 2009, 09:45 PM	#3
Adam Gold Inner Circle Join Date: Jan 2007 Location: Woodinville, WA USA Posts: 3,467	The tape is perfect -- I watch it on an HDTV monitor while capturing. The thread I linked to shows all the troubleshooting steps we've gone through so far. (Many thanks to David Newman at Cineform, who helped even though it's clear it's not a Cineform problem.)

March 8th, 2009, 01:14 PM	#4
Ron Evans Inner Circle Join Date: Mar 2003 Location: Ottawa, Ontario, Canada Posts: 4,222	Something is clearly interrupting the capture. I know you have probably been through all these but the list would include:- virus scanners/firewalls, auto update of programs, email schedule( shouldn't really have email on the editing PC!!), power management/screen savers ( make sure everything is set to "on" permanently, monitor, disc drives etc), Years ago on a low power system I had the same problem and it turned out to be the screen saver/power management on the monitor, since it had a higher priority than the capture, just for a moment. Ron Evans

March 8th, 2009, 02:09 PM	#5
Adam Gold Inner Circle Join Date: Jan 2007 Location: Woodinville, WA USA Posts: 3,467	All good suggestions; I actually make sure to confirm all that stuff before I start a project. I will continue to scour for anything I might have missed. I bet it's something stupid.

March 8th, 2009, 08:21 PM	#6
Tripp Woelfel Trustee Join Date: Jan 2008 Location: North Conway, NH Posts: 1,745	As you note, there are a number of things that can cause problems such as this. When I was having data corruption issues with external USB drives, I replaced the USB cables and all was good after. Sometimes it is the simplest thing. I'm starting to get religion on tapeless. No doubt it is the future.

March 10th, 2009, 09:58 AM	#7
Andrew Crain Tourist Join Date: Feb 2009 Location: Addison, Texas, USA Posts: 1	I've built many systems specifically for A/V capture/encoding, streaming, etc for several years, and have run into these issues many times. Here's a couple of the more common issues that result in the behaviors you've described: You might be experiencing device contention on the system bus. This might not be relieved by adding a seperate firewire card because the slot used might also be sharing resources with another (or the same) device - disk controllers, network, display, etc. This applies to more than just interrupts. Contention occurs when two devices need access to the system bus at the same time, and if something is using the bus when your firewire card wants it, it has to wait. Since video capture is usually a real time process, the only recourse is to drop a big chunk of data and then just keep going. This reason this doesn't happen for a while might be due to some kind of housekeeping or other periodic processes that occur at some point during the transfer, putting additional load on the bus, and thereby creating the contentious circumstance. The general issue here is that the load on the system bus is periodically too high. Audio/Video transfers are particularly resource-intensive when it comes to the system bus, and wholly and completely intolerant to any contention at all due to their real-time nature. Unfortunately, diagnosing & determining this for sure is not trivial. You have to look at the technical specifications of the system board to determine if this is the issue - specifically, examine closely the system board block diagram to understand how the PCI bus is laid out. Look at the bus layout for the expansion slots as well as any and all integrated devices, and see who's sharing with who (integrated devices also use the system bus). This document is not always available, especially for consumer-type systems like Dell, HP, etc. However if you built up your own machine and used a Tyan, SuperMicro, or similar main board, the user's manual or specifications document for this should be available from the manufacturer's web site. The good news is that depending upon the layout of the system bus, you might be able to simply change that firewire card to a different slot and solve the problem. The trick is to find out which slot (if any) is not sharing with another device, or if all slots are sharing, try to find one that is sharing with a device that can be disabled, like a USB port or something. Another possibility is an inadequate power supply, if you've added stuff to the machine like additional HDDs, RAID controllers, that firewire card, etc., then you might be pulling more wattage than that for which the power supply is rated. This would cause intermittent system hangs among other strange intermittent problems. Determining this is even less trivial than the system bus layout. The power supply has three rails of power, +12v, +5v, and +3.3v. You have to go through the specs for each and every device in the machine, find its power consumption as applicable to all three rails, and add them all up. This includes EVERYTHING in the system, the mainboard, the CPU(s), all disks, all add-in cards, CD/DVD drives, everything. If the sum of all devices' wattage usage exceeds that for which your power supply is rated, then it's time to go out and buy a bigger power supply. Again, these specs are usually in an appendix of the devices' manuals or technical specifications, so the biggest challenge is going and finding the information. It is not enough to simply find any HDDs wattage rating (for example) - it has to be the specific make/model in use. None of this is trivial, which is why there is so much more to the design/development of a video-enabled computer system than just sticking a couple of PCI cards and a bunch of HDDs into a Dell or similar off-the-shelf computer and expecting it to just work. There really is more to it. Hope this helps.

March 20th, 2009, 05:47 PM	#8
Adam Gold Inner Circle Join Date: Jan 2007 Location: Woodinville, WA USA Posts: 3,467	Possible -- and I emphasize that this is only a maybe -- solution posted on the original thread linked to at the top of this one, if anyone's interested. May have had something to do with original capture devices, although we can't figure out what or why. Thanks for all the suggestions, and you can bet I'll be back to this topic if/when I fail again.