Performance and frames

[Matt Mullen]

Is it consistent? Is it just over clips with effects or title? Are you using hardware?

Switch Video Output to “none” does it help at all?

[Floh Peters]

This could either be a real performance issue, with your drives being not fast enough for your footage. You could e.g. use the Aja speed test to test your drive performance.
Or if you have a I/O hardware like an Aja card, it could be related to the placement of the card in your mac. Maybe it is in the wrong PCI slot. There are some recommended configurations on the Aja site.

[Matt Mullen]

Floh is absolutely correct.

This is why I suggest switching the Video Output setting to none. IF the problem clears up you can most likely pin the issue on the card placement.

Let us know how that test goes and the placement of the card.

If it does not remedy the issue I can help you troubleshoot further.

[Paul Crowe]

OK cool thanks fort the help guys. I’ve set the video output to none and the problem persists.

So I’m looking at the AJA system test. I guess thats what you mean for speed testing right guys? Sorry to be a bit of a dumb-arse about this. I’m looking at this AJA system tester and there’s so many options for things to test it’s hard to know exactly how to set it up.

So anyway I did a read/write test to the main drive where the apps etc run from on the mac and one on the FW drive this particular program/media is. Is this the kind of info we need to progress?

Test 1 – Disk Read/write Volume: FW800 storage drive, Video frame size 720×486 8-bit, File size 128MB (disabled file system cache). Result Write: 68.8mbs, Read 72.3mbs.

Test 2 – Disk Read/write Volume: Mac HD , Video frame size 720×486 8-bit, File size 128MB (disabled file system cache). Result Write 60.9Mbs, Read 63.7Mbs

Cheers
Paul

[Floh Peters]

[Paul Crowe] “So anyway I did a read/write test to the main drive where the apps etc run from on the mac and one on the FW drive this particular program/media is. Is this the kind of info we need to progress?
“

Yes.

The fact that the problems also happen when your Kona card is turned off means that chances are pretty high that you run into a drive-speed related issue. From the numbers it looks okay, but since you are having problems I guess the drive simply cannot deliver the required performance consistently. An easy way of testing it would be to re-encode some of your clips e.g. to ProRes (non-HQ) or even ProRes LT in case you have access to it to reduce the data rate. Then do your playback tests again to see if the issues still show up. Most likely not. If not, then you either have to reduce your data rate (e.g. with using ProRes), or you need to get some faster drives.

[Paul Crowe]

Thanks for that Floh,

as per usual your advice is spot on. I re-encoded the footage as ProRess standard (didn’t have LT as and option in my version of M100 – how do I get that?) and everything runs smoothly. It’s even seems to have eliminated the error messages I was getting when importing using the Sony XDCAM transfer tool on my tower mac pro.

But I do have another Q for you if you don’t mind, though…

I’ve gone on to read much stuff on the web about PR and most folk seem to believe that unless your source is 10-bit there’s no point in using PRHQ anyway. Although a few other people reckoned it looked a little better and stood up to more generational rendering and/or transcoding. What are your thoughts about PRHQ v PRLT v PR Standard?

Cheers
Paul

[Floh Peters]

[Paul Crowe] ” What are your thoughts about PRHQ v PRLT v PR Standard? “

Both ProRes and ProRes HQ can be 10 or 8 bit. Usually the non-HQ version is good enough for 99% of all stuff. If you have very complex source material or if you need to do keying with very fine details there may be a benefit in using HQ, but only if you come from sources that use this amount of detail. I would not count XDCam into this category.
We use ProRes most of the time, and use HQ only for very few critical images or projects.