Sometimes when I capture entire tapes (which I need to do for multicam edits of stage shows) about halfway through the captured file, the picture breaks up completely, with HUGE blocks, some black, some with picture. Like a dropout on acid, but it lasts for the duration of the tape. Recapturing usually solves the problem. The breakup is not visible during capture, which I play back on external monitor during capture -- it's only the converted CFHD-AVI.

This has happened on two different capture devices (Sony HC3 and M15U), two different OSes (XP32 and Vista64), with both Cineform capture within Premiere and with HDLink, with differing amounts on RAM (4 gig and 20 gig) and with three different RAID setups (7x1TB in RAID5, RAID5 with Hot Spare and RAID0), whether quality is set to Medium or High, with both Aspect and Prospect.

Capturing HDV 60i footage shot on FX1s and FX7s. No resizing or other conversions.

System: 2 Xeon E5430 CPU (8 cores total)
20 GB RAM
150GB 10K system disk
7 x 1 TB Work Disk, currently in RAID0 (Yes, I know that's stupid, but I'm just experimenting)
nVidia Quadro FX 1500
Areca 1231ML raid controller with 2gb RAM and BBU

Nothing even on the system other than Premiere and Cineform, Internet turned off, virtually nothing running in BG.

Anyone ever seen this before? It doesn't happen all the time, but enough so that it's annoying to spend an hour capturing one of the twelve tapes that need to go into the machine, only to have to do it over again. Happens I'd say maybe 25% of the time.

If this is happening during conversion, would it make sense to capture the original m2ts and then convert as a separate step?

Edit: Additional thoughts -- could this actually be happening during the import or "conforming" into Premiere? I haven't checked these files with another viewer. And if that's the case, could off-lining them and re-importing solve the problem? Will try this next time this happens.

Edit2: Just happened again. Played clip in WMP and it's there too, so it's part of the .avi, not a Premiere issue.

This is an MPEG artifact, which points to hardware problem. Either the camera is messing up the data (unlikely) or the FireWire port is dropping packets (more common.) Some Firewire Port designs are bad, and will drop packets when the CPU is doing other thing like transcoding. If you capture to M2T and transcode in a second step, and it work fine, replace add or try a different firewire port.

Never thought about the FW port. I'll buy a new one today; I think the existing one is just integrated into the Mobo.

Amazing how a $10 FW card an bring a $7,000 system to its knees. For want of a nail....

Thanks for the help.

Update: I installed a new, separate FW card, but the problem persists, both from Premiere capture and using HDLink.

Any other ideas?

If it only happens while transcoding, then it is a Firewire port or driver issue. You can confirm in HDLink using the M2T only mode. If that messes up and you replaced the FW port, then the camera is suspect. When this only occurs with trancoding, it means the PC is taking too long to response to packet requests from the firewire port, and due to a poor design the port drop important packets. Your PC is plenty fast enough, about 4X the power needed for RT transcoding, so it should be able to service firewire packets.

Appreciate the response. Not really sure what to do now, though... two different FW ports (mobo and card), three different capture devices (two HC3s and one M15), three different OSes (XP32, Vista 64 and Win7). Rarely capture to m2t but I'll try that, I guess, and see if it happens there as well. The few times I've captured as m2t, no problem.

The constant seems to be long tapes I capture in one piece because they are multicam shows, and I need the whole tape. Don't recall it ever happening when I batch capture multiple little clips.

Maybe I'll just start always capturing to m2t in HDLink by default, then transcode later.

At has to something the bus controller on the motherboard it causing delay responses to interrupts. This is a first, as I never seen this occur and replacing the firewire port didn't address it.

I'm just proud to be finding new ways to screw this up.

So if that's the problem, what to do? Take the PC back into the shop (again!)? What do I tell them to look for?

Another thought: usually when capturing within Premiere in a CF project, the "Transcoding to Cineform Intermediate" box is only up for a few seconds after the end of the tape capture, no matter how long the actual capture was. But today the box was up for like 20 minutes, and that was the clip that came out that way. Could they be related or does this provide any clues?

Another possibility: some other hardware device is taking too many cycles, causing the firewire to drop packets. Your RAID controller is a possibility, try capturing to the system drive.

Good idea. Unfortunately, my system drive is pretty full with two OSes and not a lot of space, certainly not enough for an hour of tape transcoded to CF.

Here's another possibility: I have my swap file on the same RAID as I'm capturing to. Could that be the problem?

Unlikely, can't you test shorter captures to the OS drive. Once you know, you can just add a $60 500GB SATA drive for your RT capture and converts.

Sure, I could, but it's never happened with shorter captures.... only the whole tape, and the problem usually doesn't show up until at least halfway through or later.

Latest development: Just finished my first full-tape capture with HDLink capturing only the m2t... and it crashed for no apparent reason. Nothing captured. Will try again. Interesting: the first (unsuccessful) capture didn't count up the file size as it was capturing. But this time it is.

2nd try ok. No artifacts. Moving forward.

Thanks, David, really appreciate the help. And on a weekend yet!

Latest update: it does happen on straight m2t capture via HDLink. Will try capturing to system drive next.

Well, I'm stumped. Happened when capturing to C: as well. It was just a few minutes in the middle of the capture; in the past it's started about halfway through and continued to the end.

System drive is controlled through the mobo only; the other 7 internal drives are on the RAID controller, so I guess the RAID controller isn't the problem.

Not sure where to look next, or what to try.

Hmph.

Well, I'm stumped. Happened when capturing to C: as well. It was just a few minutes in the middle of the capture; in the past it's started about halfway through and continued to the end.

System drive is controlled through the mobo only; the other 7 internal drives are on the RAID controller, so I guess the RAID controller isn't the problem.

Not sure where to look next, or what to try.

Hmph.

Here are some random things to try:
Can you try removing all other cards from your system (including the RAID)?

Can you try putting your FW capture card in another slot? Maybe that slot is sharing interrupts w/ the vid card or another card.

You might want to look into using Window's Perfmon logging during a capture to see if there are any abnormal spikes around the same time the glitch happens. It's in ControlPanel->"Administrative Tools" .. You can log %Interrupt Time, Interrupts/sec, Context switches, CPU time, etc....

Dan

What video card do you have?

Those are all good ideas. I'll try to figure out how to make them work. As I noted earlier, this has happened with both the integrated FW and a separate card I bought and put in my one remaining slot.

Certainly possible it's the RAID card; maybe I could remove and then use mobo RAID control -- wondering if this would mean wiping out RAID data already stored. If so, not an option.

Forgot to mention that this has happened with two video cards as well -- NVidia Quadro FX 1500 before, and now ATI Radeon 4350.

As the glitch isn't visible during capture, only after when you scrub through the file, watching the performance monitor for an hour and writing down any suspicious activity and then checking the captured file will present a challenge -- but it's certainly a good idea.

Thanks for the help.

As it's clear I was barking up the wrong tree by posting in the Cineform forum, I've started a new thread here:

http://www.dvinfo.net/conf/high-definition-video-editing-solutions/145340-mpeg-artifacts-packet-loss-capture.html

Sorry to effectively double/cross-post -- I hate people who do that -- but I wanted to try to get this in front of a larger audience who might not check out th Cineform forum regularly.

Yes, also try another FW cable. :) It can happen.

Yeah, hope springs eternal, so I swapped out the cable last night. No joy.

Adam.


I think you may find that the cameras are not entirely innocent in this. If you play the m2t files back in VLC player, you will likely find the capture is corrupted at the same places and that HDlink is faithfully reproducing those defects without adding any or very few of its own.

I have an FX1 which does what you experienced about 10 to 20 minutes into a long capture like an event or music gig. You may also observe with in-camera playback of the FX1 vision, a sort of resync or reset jump after about 12 minutes of a long take, sometimes later, sometimes not at all. This may be a tape dropout. I have never found the cause.

A Z1P has not done this to me at all.

A JVC GY-HD100 randomly captured a 35 minute single music take then flaked out on every other capture I attempted. Despite my doing all the right things, power down everything before touching firewire plug to socket, the JVC's firewire port had gone next time the Firestore was connected.

I routinely capture first to m2t file in HDLink, then convert in a second step.

Those are all good ideas. I'll try to figure out how to make them work. As I noted earlier, this has happened with both the integrated FW and a separate card I bought and put in my one remaining slot.

Certainly possible it's the RAID card; maybe I could remove and then use mobo RAID control -- wondering if this would mean wiping out RAID data already stored. If so, not an option.

Forgot to mention that this has happened with two video cards as well -- NVidia Quadro FX 1500 before, and now ATI Radeon 4350.

As the glitch isn't visible during capture, only after when you scrub through the file, watching the performance monitor for an hour and writing down any suspicious activity and then checking the captured file will present a challenge -- but it's certainly a good idea.

Thanks for the help.

As it's clear I was barking up the wrong tree by posting in the Cineform forum, I've started a new thread here:

http://www.dvinfo.net/conf/high-definition-video-editing-solutions/145340-mpeg-artifacts-packet-loss-capture.html

Sorry to effectively double/cross-post -- I hate people who do that -- but I wanted to try to get this in front of a larger audience who might not check out th Cineform forum regularly.


You can setup the perfmon tool to log all the diagnostic data to a "history" log file while you're doing the capture and then you can go back (later when you've identified the glitch in the capture file) and analyze the logs using perfmon tool. The method of doing this is different between XP and Vista but they both should acquire all the data you need. Just make sure you write down your start time and whatnot so you have a way to correlate your glitch time offset in the video file with the timestamps in the log data captured by perfmon. I imagine there are plenty of websites that describe how to set this up (XP or Vista). I think it's worth while to learn how to do (at the very least to add to your tool arsenal for future issues).

Thanks for both ideas above. I'll give them a shot.

Bob, you may well be right. All I can tell you is as I noted, this has occurred with three different playback devices, the tape itself is fine as far as I can see, and the problem doesn't go away when I capture the m2ts in HDLink and then convert. And eventually it captures fine if I try enough times. But I have other cams so I can switch some out and see if if makes a difference over time.

As capturing in HDLink, either as m2ts and then converting, or as CFHD-AVI, provides no benefit, I've gone back to capturing from within Premiere. The last two tapes I tried came in fine, even though they were re-captures of previously corrupted files.

I think Bob (and David, in his very first reply, when he implicated the capture device) was on to something, although perhaps not in the way he intended.

Even though this problem has occurred on three different capture devices, I opted to try a fourth, my HD1000, as it doesn't get much use and these are all continuous, single pass captures anyway.

So far, and I emphasize that this is only preliminary, I've captured the last 11 tapes without a problem using this device. All with the same FW cable, port, settings, PC as the original setup when I first posted.

So maybe it had something to do with the M15, although for the life of me I can't imagine what the problem with two different HC3s would have been, especially as internally they are virtually identical to the HD1000.

Using the cam as a deck also solves another minor annoyance I've experienced with the M15, which is that device control isn't great -- it FFs and REWs so fast that it frequently way overshoots the mark when batch capturing and never recovers, leading to small captures that are a minute or more off (and when the clip is only 20 secs, that means you don't get any of what you want).

I wonder if somehow they are related.

Anyway, pretty clearly not a Cineform issue but thought I'd post the progress here as this is where most of the brainstorming occurred.