[John Davidson]

If you search the HDV forum, there’s an issue where you’re supposed to fully power down both the camera and the Mac before connecting the Firewire cable. Apparently lots of folks have fried their camera firewire ports by not powering down first.

Hopefully that didn’t happen to you.

[John Davidson]

Jesus…sounds like that coolant is made of Happy Fun Ball guts.

I just upgraded the rack order to a 70 incher, so I can put it upright. Whew!

[John Davidson]

Dang. Looks like Marathon Computer went out of biz. I guess I’ll get one from these guys.

https://www.martinandziegler.com/racks.htm

[John Davidson]

Wow. I don’t know if I have the balls to cut up my primary source of income, yet. My G5 is still a few more crashes away from ticking me off that much :-).

I think I’ll just opt for the taller rack, go verticle, and save myself the stress. Thanks though!

[John Davidson]

I don’t think that really answers the question of why RAM preview plays back video slower than audio. As you said, the video is stored in RAM once it’s rendered, and then (theoretically) played back at the frame rate designated by the comp. What I’m saying is that RAM preview doesn’t play back at the correct frame rate when dealing with a complex comp.

This was not an issue in 6.5. Without an accurate way to preview a segment of a comp at full quality, AE loses a good deal of it’s effectiveness. The majority of my graphics are tied to music and sound.

It really feels like a bug, IMHO. I bet 7.1 fixes it.

-neo

[John Davidson]

Funny, I almost made a post saying the same thing a few weeks ago, but I’m not an expert here so I let it slide.

I have noticed a significant lag in video with heavily complex comps. What appears to be happening is that RAM preview does not play at realtime when processing effects. The audio, however, does play at realtime, so the only way I can sync the two is to reduce the quality to around 50%, which seems to alleviate the issue.

I really don’t remember this ever happening on 6.5. RAM preview is built to play back a small section at real time – so once the green bar goes through the comp, even at high quality, why isn’t it playing back at real time?

I am running a dual 2.7, 10.4.5, 8 Gigs of ram, Kona 2 latest drivers, with 10 and 8bit uncompressed footage.

I have an ATI 9650, so my OpenGL is limited (THANKS APPLE!). I bet motion blur and anti-aliasing are sweet with OpenGL!

-neo

[John Davidson]

Great. That’s what I thought.

Thanks!

[John Davidson]

Aha. It’s “user error”. I upgraded to the 1.21 Kona drivers today, then ran conflict checker which said I needed to lose the Blackmagic codecs. I can color correct, resize, and put as many starwipes as my heart desires – I just had to delete the Blackmagic codecs.

I installed them for some reason because I thought they might come in handy a while back. I guess not!

thanks for the assist guys!
=neo

[John Davidson]

Still nothing yet. I’m in the middle of 3 projects at once on this baby, so I’m hesitant to do anything major until they’re delivered next week. I’ll report back when I can do more.

I think I’ll try to reinstall QT again and see if that helps first. Since it appears in FCP as well as the output monitor, I think it’s a software problem now rather than a Kona2 card issue.

Thanks for the support guys!

[John Davidson]

I’ve found that it does this only with 10bit footage, not 8bit. It’s odd because you’d think the 8bit stuff wouldn’t work in the 10bit timeline… 8bit scales and moves fine.

this is all in the Apple 10bit Uncompressed codec. Should I be using the AJA when I digitize?

Thanks again guys…