Archive for the ‘AVCHD’ Category

Adobe Premiere CC: [Undo]: Media non-Unreplace (& Work-around)

Tuesday, October 22nd, 2013

I discovered by accident that, although one can do ProjectPane:[aClip >RtClk> Replace Footage…], a subsequent Undo will not un-replace (restore previous) footage.  I raised this topic at, and subsequent discussions resulted in a confirmation that indeed this is Premiere’s normal behavior but that there is a reasonable work-around.

So what was the work-around?

  • My footage happened to be XDCAM-EX, denying me the possibility of simply doing a further [Replace Footage…]. This is because the browser associated with [Replace Footage…] was only a File-Browser, not a Media Browser.  Consequently it would list individual component files of the XDCAM-EX folder-structure, but not the single overall high-level sense of “Clip” represented by that structure.
    • XDCAM-EX footage needs special treatment because it is file-structure based and spanned, broadly like AVCHD.  To get such footage properly into Premiere, it is necessary to use the Media Browser, and not simply to drag in the [.mp4] “essence” files within that file-structure.  It is ok to drag from Media Browser to Project pane, because that operation recognizes all relevant information in the file-structure, displaying it as a single clip at the highest level, possibly spanning over more than one [.mp4] file.  The Media Browser hides such detail from the user.
  • My next (unsuccessful) workaround-attempt did work but was clunky.  This was to re-import the original footage via Media Browser, so it appeared in the Project pane, then select it, then go down to each relevant clip on the timeline and in each case do a [Replace with clip] using [From bin], i.e. the original footage in the Project pane.  However, while any metadata (e.g. “Log Notes”) on the original item (prior to replacement) got transferred to the replacement footage, that metadata was not “inherited” by the fresh import of the same original footage, so it had to be copied across manually.
    • Ugh!
  • The best work-around was explained (by Jim Simon, in a thread on the Adobe Premiere forum) as follows:
    • In Project pane, do an offline-and-relink, e.g. via [aClip >RightClick> Make Offline] followed by [aClip >RightClick> Link Media…], which does give the option of using Media Browser.
      • NB: When I initially tried that, the Locate Media Browser (a fresh instance of Media Browser, in a pop-up window) opened in File mode.  However, by clicking that browser’s “eye” button, it was possible to select XDCAM-EX mode (among others). This behavior is unlike that of the main Media Browser, which selects the camera-specific mode automatically.

Adobe Premiere CS6: Nested Sequences: Slow Response to Play-Button (Re-buffering? Re-parsing?)

Thursday, February 21st, 2013


  • 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


  • 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?).


    Capture from Sony HDR-SR12 (LenCam)

    Tuesday, November 30th, 2010

    Can simply dig-down, locate and drag the MTS files, but these are really just components of clips, limited in size to around 2GB, hence more numerous than the clips themselves.  To get clips as single files, use e.g. Sony Vegas Device Explorer.  The result is MTS files that are (typically) larger and fewer in number.

    Getting AVCHD into AviSynth

    Wednesday, September 1st, 2010
    • Google: [avchd avisynth]
      • []
        • My very own question, asked 15 Feb 2009, no replies since then.
        • Stated tha:
          • AviSynth via DgIndex etc. (as used by me) could read MXF files as far as their video was concerned, but not the audio.
      • []
        • Avisynth acts as a conduit for the mts files (you import as simple script into premiere).
      • []
        • *You’ll also need an AVCHD directshow codec installed. If you don’t have one, you can use the latest QTalternative
        • * You’ll also need to install Haali Media Splitter.
        • DirectShowSource(“myclip.MTS”) #use the name of the clip
        • DirectShow needs an MTS file reader/splitter to open MTS files. That’s what Haali Media Splitter is for.
        • There’s also the option of DGavcdecNV, which (if you have an Nvidia card) will use the GPU on the video card for decoding the AVCHD file. (See also
        • … links to two DirectShow AVC decoders: CoreAVC Proffdshow.
        • Deeper advice
          • When using DirectShowSource() AviSynth is asking Windows’ DirectShow subsystem to do all the file parsing, stream splitting, and audio/video decompression. If you can open your M2TS (or whatever) file with Windows Media Player then you have everything necessary for DirectShowSource() to work. If WMP will not play the file then you need to find and install the appropriate file reader, file splitter, and/or codecs.
          • (If) you are getting sound but no picture you probably just need a DirectShow decoder for the video. ffdshow includes MPEG 2 and h.264 decoders.
          • If you can’t get DirectShowSource() working you should try DgMpgDec (MPEG 2) or DgAvcDec (h.264). Run DgIndex or DgAvcIndex, and then use Mpeg2Source() or AvcSource() in the Avisynth script.
            • Sadly, at this time of writing (2010-09-01), it seems that DgAvcDec has been abandoned (due to uncomfortable “ride” along the licensed software approval process, with respect to used libraries ).
      • []
    • []
      • As DGAVCDec is withdrawn, this thread is now closed
        • Indeed I was unable to download it.  Also it was still in a state of development and testing, as far as I could see.   Shame.

    Pros & cons of Device Explorer in Sony Vegas

    Saturday, May 1st, 2010


    • as of May 2009:
      • Technically, you “can” edit the .mp4 files right from the card. You’d need to drill down through the directories via the standard Vegas Explorer tool (not the new Device Explorer), find your .mp4 clip, and bring it into your project.
      • “We do not currently support shot markers from EX in the Vegas Pro 9 Device Explorer, but it is on our radar.”
      • Spanning clips does not work properly for everybody (could in principle be due to their circumstances as much as the app).  Recommended to join these together using ClipBrowser thenexport as MXF for NLEs.  … It is really the same concept as (FCP’s) XDCAM Transfer except instead of re-wrapping as [.mov] it re-wraps as [.mxf].
      • (In the case of FCP) … the metadata is part of the MOV after … re-wrapping the file for FCP.  (Possibly) Vegas had a problem with managing the metadata and their solution was just to (import the) native (essence/mp4) files.

    My own experiences:

    • A long shoot gets listed as a sequence of smaller clips, corresponding to the separate [.mp4] files recorded by the camera.  This is known as a spanned clip.  Each of the smaller clips is of size no more than around 3.5 GB.
    • Device Explorer import results:
      • Clips with names like [929_1332_01_20100318_191600] i.e. having datetimes.
      • These clips consist of the following files, with main file name as per the clip:
        • XDCAM-EX:  [.mp4], [.xml]
        • AVCHD: [.mts] (but no clip info files).

    FCP importing AVCHD – How

    Thursday, April 22nd, 2010