David Esp Video Technical Blog

Context:

• I had a Sequence  containing two video tracks, each having a pair of (associated) audio tracks.
  • Sequence Properties: 1080p, square pixels, 25 fps.
  • One track contained a single continuous clip of duration just over one hour[01:02:46:10].
    • Properties: 1080p, square pixels, 25 fps.
    • Format: Sony XDCAM-EX: MPEG2 @ 35 Mbps VBR: MPEG2HD35_1920_1080_MP@HL
  • The other track contained a number of discrete clips, intermittently spaced over that time.
    • Properties: 1080i, fat pixels (PAR=4/3), 25 fps (50 fields/sec), UFF.
    • Format: Sony Z1 HDV: MPEG2 @ 25Mbps CBR
• This sequence, as it stood, played fine.
• Then I nested that sequence (seqA)  inside another sequence (seqB).
  • Still played fine

Problem:

• Then I did some multicam “music video” edits, mostly near the end of the sequence
  • Now, when I hit the spacebar to play seqB, there is a delay of several seconds before playing actually begins.
• If I try re-creating from scratch, by nesting seqA inside new seqC then seqC plays fine.
• 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 [Play] still occurs.
  • Doh!  I had hoped that would be a simple workaround..

Partial Workaround:

• Following web-advice regarding a broadly-similar issue with multicamera sequences comprising spanned clips (e.g. AVCHD or Canon’s H264) , I tried transcoding the footage to GoPro-Cineform
  • Based on Adobe’s workaround-advice regarding broadly similar problems with long hence spanned AVCHD footage.  My footage is not AVCHD, but the main clip is Sony XDCAM-EX, which has some features (like spanning) in common with AVCHD.  Worth a shot!
    • On a 4-Core i7 PC with GPU, it encoded at about real-time, which in my case was about an hour.  CPU was only 25% i.e. equivalent to a single core
  • Replaced the relevant clip in seqA.
    • To my delight, the clip-markers (in that clip in seqA) were retained/applied in that replacement footage.
• However, the sluggish [Play]-start remained, though possibly shortened, from about 6 seconds to 4 seconds.

Further Workaround:

• Duplicate seqA
• Nest it in a separate multicam sequence (seqE)
• Do multicam edits on further segments of the event in that (seqE)
  • Intend later to nest/sequence usable bits of each multicam edit-sequence in a Master sequence.
• Where there’s a will, there’s a workaround…
  • Still, I expect better of Adobe…
  • I lost about 3 hours to this (including web-searching, waiting transcoding and general experimentation).

Further gripes:

•  God it’s clunky!
  • 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).  Unfortunately my reflex is simply to hit the spacebar.  It is a nuisance to have to fight that reflex…
  • Every time I stop multicam-preview, it leaves a cut at the final position of the playhead.  Not useful and simply clutters the timeline, distracting from real cuts.
  • Zoom [+] only affects the Timeline, not the multicam monitor.  As a result, I tend to set the playhead position using the timeline.  Doh! must remember to click (activate) back to the multicam monitor once more…
  • 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.  Things snatch and interact that shouldn’t (I feel).
  • Sony Vegas is far better in these respects, though not in some others, so I’m sticking with Adobe…
• Unexpected Preview-Rendering is happening…!?  How come?
  • 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?).

(more…)