No settings in OnLocation affect the quality of what's recorded. OL records the video stream direct-to-disk, without decoding/re-encoding it, so there's no opportunity for the application to introduce problems. The artifacts could be coming from the camera or they could be a product of an issue writing to disk--for instance, if fragmentation is so bad that the app has to cached too many frames while looking for open sectors, then you could end up with dropped frames. In that particular instance, the message bar below the field monitor would warn you that RAM is dangerously full.
To test whether the problem is on the camera's side, you could record both to the P2 card and to OL. Then when you encounter an artifact in OL's recording, check the same frame in the P2 clip. A triple-check would be to point the camera at OL's field monitor while recording both to the P2 card and direct-to-disk. Then you could see whether an artifact that exists in the clip that OL recorded is also evident in the decoded video that OL displayed live.
What's the nature of the artifacting? Can you post a frame?
Thanks for the reply, Mark.
Unfortunately, I do not have any P2 cards to test with.
Here's a frame with the artifacts:
I've never encountered this problem before with OL. But to my great embarassment, I discovered after the post that I had left on my Internet connection and anti-virus protection. I suppose that could have done it.
I don't recall a warning message below the field monitor, and given this was a 1 minute clip at 720p30, wouldn't it be unusual if that taxed my 12GB system? Also, I defrag continually, so I'd be surprised to find learn that is the problem. The disk is the media drive and is only about 30% full and only a little over a year old without heavy usage.
While I'm at it, may I ask where the best tutorials/articles/videos are on configuring OL for best results with my camera using SureShot, etc.? I've been doing all my settings just with the camera, but the help literature seems to suggest I can do a better job with OL.
One question in particular is whether the green screen should not only be evenly lit, but high on the waveform monitor or should only the subject be high?
Thanks again, Mark, for sharing your vast knowledge and expereince in this forum.
Okay, this is going to be a bit of a scattergun response...
We have seen frames with artifacts much like yours and have a bug on the books about it, dating back to 2008. That bug is closed as a 3rd party issue, with the following note: "These "glitch" frames are not unique to OnLocation. There are many documented cases of such frames coming from the HVX 200. Anecdotal evidence points to a hitch in the data transfer, with the Firewire cable being the main suspect."
Here's a related thread on DVXUser.com: http://www.dvxuser.com/V6/showthread.php?77384-Let-s-solve-this-glitch-once-and-for-all&hi ghlight=the+glitch. The artifacts they're discussing are similar to what your frame shows, but OnLocation was not in the mix.
Anyway, my recommendation is that you try another cable--and keep it under the 4.5 meter limit. Also, it might be worth downloading the trial of Premiere Pro CS5 and seeing if you get the artifacts in that version of OL. I don't recall seeing any "glitch" frame in the CS5 cycle, but I wouldn't testify to that. And even if my memory is right, that doesn't mean that we fixed anything in the app--it could just be that I had scrapped the bad Firewire cable...
Since my memory is shaky on this, I consulted a couple of colleagues. One suggested testing with anti-virus disabled. The other pointed to high RAM usage or a pegged CPU--given how beefy your system is, I'd be a little surprised if either of those proved to be factors, but as far as RAM goes, keep in mind that OL is a 32bit app, so it's not able to access memory addresses beyond the 4GB threshold.
Unrelated to this issue, since you mention only that you're running CS4, I urge you to patch to OL 4.0.3 if you haven't already done so. We fixed a boatload of bugs in the patches.
Thanks so much. You have been very gracious with your time and help.
I tried a new cable and it didn't work. So I tried capturing on my laptop and it captured flawlessly. I think this concludes that the problem is with the desktop editing machine. I've had bad memeory problems in the past--I thought that might be the problem this time, but after an hour of memtest86+, no bad memory yet. I'll certainly let it go longer to see if anything shows up. Maybe run Prime95 as well.
So, at least in my case, it appears that the problem lies somewhere within the architecture of the editing machine.
Thanks again for your devoted attention to this matter. I'm very sorry that the problem is not a result of anything associated with your time consuming research.
In gratitude to all who participated in this thread, here is the final outcome, arrived at through discussion here in the hardware forum.
I changed my BIOS back to the factory default, which meant to only change DRAM from DDR3-1333 to AUTO and UCLK from 2666 to AUTO. No overclocking was ever done, everything else is factory settings except the DRAM timings which are set to OCZ factory recommended 7-7-7-20. No artifacts. I later reset the DRAM Frequency to DDR3-1333 in BIOS and left the UCLK Frequency on AUTO. Still no artifacts and CPU-Z is now faithfully reporting DRAM Frequency at about 667 whereas before it was reporting 533. So it was the BIOS settings the whole time.
My apologies to everyone who tried to help via ideas other than hardware.