Kevin Camp
Forum Replies Created
-
thanks ian, that’s an interesting note… i think it is worth a try, and easier than removing ram to restrict the number of processors being used.
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
technically it should be 20 seconds x 29.97 fps… so 599.4 frames… but that math gets too complicated for me. try rendering out your text crawl at the 600 frames (30fps) that you have, import that footage, but interpret the footage as 29.97, then drop that into your main comp.
also, can you post the crawl somewhere, so we can see the problem?
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
unfortuantely compressed hd is often non-square, both hdv and dvcprohd have a resolution of either 960×720 or 1440×1080. which if you do the math is a 4:3 ratio. so to get it to 16:9 they use a 1.33 pixel aspect ratio.
you can, however, just drop that footage into a hd sqaure pixel preset comp (either 1080 or 720 preset depending on footage) and ae will handle the non-square to square conversion, and it is a common way to work with these codecs.
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
there is a live interaction preview swittch (button) on the timeline, near the motion blur, shy and frame blending switches. its the one that looks like a square with an x on it. try toggling that, it often gets hit accidentally.
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
dv is 720×480; d1 is 720×486, so that may be the problem…
try making the comp that you are rendering to dv with the dv preset (720×480), render to dv, and see how that looks when it comes back in to ae.
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
you are correct, dv uses intraframe, hdv uses interframe… sorry about that, my mistake. but writing to an image sequence will allow each processor to write its own frame, which would eliminate the possible bottleneck of having to write to a single file with ordered frames.
there could also be a possible bottle neck at the drive… if your processors are generating frames fast enough, there is the potential they could exceed the sustained write speed of your drive. seems unlikely if you have a striped raid though…. unless it is severely fragmented (but i think this is a new system, so that’s unlikely)
and, yes you can get a lemon.
i’m kind of curious how it might prform if you take half the ram out…
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
if you tried the expression that moved the text a set number of pixels each frame (d = 8), and your value was much higher than about 4, then your text may just be moving too fast… try a lower value to see if that helps.
if it does, you may need to lengthen the duration of the comp/move or decrease the length of your text line to get the move to complete.
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
dv would use interframe compression (or temporal compression), similar to mpeg and many others. you might try converting the same dv footage used in that comp to lossless or uncompressed or even an image sequence to avoid interframe compression. then see how the comp renders.
you also might try rendering to an image sequence… i remember a comment about nucleo concerning multiprocessing to media files, where one processor also had the responsibility of encoding, but image sequences allowed each processor to write its own frame…
if the image sequence render helps, then possibly increasing the ram cache size to around 2-2.25gb (enough to only allow 6 additional processors for multiprocessing… the multiprocessing prefernce will tell you how many will be used) may help. this might free up one processor for encoding.
have you psted on the adobe ae forum, you might actually get somebody from adobe who knows what’s happening…. i’m really just theorizing. i wish i had enough ram to test it. 🙂
Kevin Camp
Designer – KCPQ, KMYQ & KRCW -
oops, there seems to be a problem with the way i am trying to caluclate the stop position/state…. i think i didn’t see the problem, becasue the little loop i made was 1 second.
i tried this one out a few times, and it seems to work (of course is thouh the last one did too)
loopDuration = key(numKeys).time – key(1).time;
stopTime = thisComp.layer(“Null 1”).effect(“Slider Control”)(“Slider”);
if (time < stopTime) { loopOut() }else{ valueAtTime(((stopTime / loopDuration) - 1) * loopDuration) } however, if the stopTime value is less than the loopDuration it will not work properly... but that could be fixed by another if/else or maybe a clever math way... Kevin Camp Designer – KCPQ, KMYQ & KRCW -
i think your ram preview will still be limited to 3gb… one app can only have 2-3gb of ram, and i think that only one instance of ae is used for preview playback…
the 2 frames to preview issue is often due to the time controls palette having the ‘from current time’ box checked. make sure that is unchecked, or make sure you are not at the last frame of the comp.
i think you could up your ram cache to be a full 2gb, maybe more. the ram cache is how much ram is available for each processor, since you have 9gb you should be able to 8gb to the 4 cores (you did say you had a 4-core macpro???)
Kevin Camp
Designer – KCPQ, KMYQ & KRCW