In that case, it’s possible you re running into a known bug with CS6 and AVCHD whereby things get sticky and slow.
Sequence preset adobe premiere cs6 pro#
Mac Pro 12 core 2.66 Quadro 4000 46G Ram Internal Raid 5.
I notice that when I start the project (About 24 mins long) all is nice and responsive, but as I progress all becomes much slower/slugggish, such that now when I press play it takes 2-4 seconds for the play head to move.
I have a multi sequence with 4 lanes of video (2 x h264 and 2 x all I-frame).
CS6 becomes less responsive over time in Multi Sequence.
Thread: CS6 becomes less responsive over time in Multi Sequence.
In principle, that shouldn’t be happening? I have a state-of -the-art (4-core i7 & GPU) laptop specifically for CS6, no effects applied, just cutting between two cameras, some plain dissolves (between segments of the multicam sequence) – but surely the Mercury Engine should take them in its stride? (or can’t it cope yet with multicam?).
Unexpected Preview-Rendering is happening…!? How come?.
Sony Vegas is far better in these respects, though not in some others, so I’m sticking with Adobe….
Things snatch and interact that shouldn’t (I feel).
Ranged (duration not zero) markers are great but adjusting their right-hand end can be tricky, since this can change the playhead and/or timeline-display.
Doh! must remember to click (activate) back to the multicam monitor once more… As a result, I tend to set the playhead position using the timeline.
Zoom only affects the Timeline, not the multicam monitor.
Not useful and simply clutters the timeline, distracting from real cuts.
Every time I stop multicam-preview, it leaves a cut at the final position of the playhead.
It is a nuisance to have to fight that reflex… Unfortunately my reflex is simply to hit the spacebar.
Every time I stop multicam-preview to tweak the multicam cut timings, then return to multicam editing, I have to remember to activate the multicam monitor, not the timeline (where the tweaks are done).
I lost about 3 hours to this (including web-searching, waiting transcoding and general experimentation).
Where there’s a will, there’s a workaround….
Intend later to nest/sequence usable bits of each multicam edit-sequence in a Master sequence.
Do multicam edits on further segments of the event in that (seqE).
Nest it in a separate multicam sequence (seqE).
However, the sluggish -start remained, though possibly shortened, from about 6 seconds to 4 seconds.
To my delight, the clip-markers (in that clip in seqA) were retained/applied in that replacement footage.
Sequence preset adobe premiere cs6 Pc#
On a 4-Core i7 PC with GPU, it encoded at about real-time, which in my case was about an hour.
My footage is not AVCHD, but the main clip is Sony XDCAM-EX, which has some features (like spanning) in common with AVCHD.
Based on Adobe’s workaround-advice regarding broadly similar problems with long hence spanned AVCHD footage.
AVCHD or Canon’s H264), I tried transcoding the footage to GoPro-Cineform
Following web-advice regarding a broadly-similar issue with multicamera sequences comprising spanned clips (e.g.
Doh! I had hoped that would be a simple workaround.
If I try copying the multicam-edited elements of seqB (the multicam edit-sequence) into new seqD (a new multicam edit-sequence) then the sluggish response to still occurs.
If I try re-creating from scratch, by nesting seqA inside new seqC then seqC plays fine.
Now, when I hit the spacebar to play seqB, there is a delay of several seconds before playing actually begins.
Then I did some multicam “music video” edits, mostly near the end of the sequence.
Then I nested that sequence (seqA) inside another sequence (seqB).
This sequence, as it stood, played fine.
Format: Sony XDCAM-EX: MPEG2 35 Mbps VBR: The other track contained a number of discrete clips, intermittently spaced over that time.
Properties: 1080p, square pixels, 25 fps.
One track contained a single continuous clip of duration just over one hour.
0 kommentar(er)
