Forum Replies Created

Page 23 of 96
  • Joe Marler

    March 26, 2020 at 12:43 pm in reply to: Cupertino, we’ve got a problem!

    [Oliver Peters] “Premiere Pro performance in my experience is actual quite good on Macs, as long as you are dealing with media that is optimized for macOS, such as ProRes. FCPX and even Resolve are a bit better in overall media handling, but again, nothing that seems to have changes because of Catalina.”

    Likewise I haven’t seen any major perf. problems on Catalina. For certain tasks there was a significant performance improvement with FCPX 10.4.7 (the Metal-optimized version) on both Mojave and Catalina.

    In my experience on an iMac Pro, Premiere performance is highly uneven. It’s OK on optimized media but playback can be incredibly laggy and slow on most 4k H264 codecs and some 4k All-Intra codecs. I tested the viewer (aka program monitor) update rate of FCPX 10.4.7, Resolve Studio 16.1.0.055 and Premiere Pro 13.1.5 on a 10-core Vega 64 iMac Pro running macOS Mojave 10.14.6. Premiere was set to 1/4 resolution. Codec was Panasonic GH5 4k H.264 All-Intra 23.98 fps, 10- bit 4:2:2, 400 mbps:

    Resolve: 28 frames/sec
    FCPX 10.4.7: 20 frames/sec
    Premiere: 2 frames/sec

    That said, both FCPX and Resolve are extremely slow at 10-bit HEVC output. Premiere is much faster for that one task.

    [Oliver Peters] “It would be great if within the OS – without any special app – I could directly operate a remote Mac as if I would running a machine right next to me. And with little or no latency.”

    All Macs have built-in remote control and screen sharing using Messages. It works well and I’ve done limited remote editing, but it’s laggy. You wouldn’t want to do lots of work that way: https://support.apple.com/guide/messages/screen-sharing-icht11883/mac

    I’m not sure how you could run lag-free remote work on a 4k or 5k screen. Using an iPad to control a remote Mac desktop is another issue. Besides the inherent performance problems it also involves remapping mouse/keyboard events to touch events. I’ve used Parallels Desktop for this and it’s OK in a pinch but I wouldn’t want to edit with it.

    Yet a separate issue is remote collaboration which FCPX is just not currently optimized for. This is especially difficult since in the FCPX model much of the work takes place in the Event Browser, not the timeline. The natural workflow is the Assistant Editor preps and organizes the material in the browser, and the lead editor works on the timeline.

    Since each event is a separate database, you can have separate assistants working independently on each event but there is no built-in support for this, not even rudimentary event locking. If something like an advanced version of MergeX was built in, that could be one developmental direction: https://www.merge.software

    Much of the discussion on collaboration centers on the timeline, or on co-located LAN-type collaboration. With FCPX a solution is needed for (1) The Event Browser, and (2) Distributed non-connected collaboration.

    There are check-in/check-out approaches to lock an entire library but ideally some kind of finer-grained concurrency is needed, combined with sync and conflict resolution. Those are not easy, even for companies oriented to group workflow vs single-user workflow.

  • Joe Marler

    March 12, 2020 at 10:32 pm in reply to: Remote editing

    [Terry Barnum] “last night I started playing with screen sharing and TeamViewer to at least be able to get to the FCPX editing systems. I was pleasantly surprised that the performance was pretty decent, though I know it’s not going to be a long-term solution.

    The problem is I can’t get either one to pass the computer audio. Turns out this is a known and long-standing problem with TeamViewer. “

    Recent versions of MacOS Messenger have remote screen sharing and remote control capability built in, however it has a similar limitation of not properly passing system audio. I think both systems must be on Mojave or later : https://support.apple.com/guide/messages/screen-sharing-icht11883/mac

    I have done limited remote editing and it works OK, albeit sluggishly with no skimmer, sort of like Premiere ☺ I think it passes system audio but you don’t have full control over the volume. It is OK for some cases but not for audio editing. It is very good for remote support where you don’t want the person to install new software and you are not doing major editing.

  • Joe Marler

    March 11, 2020 at 2:02 pm in reply to: FCPX freezing when editing/playing

    [Malcolm Karpeta] “Crash. I mean complete crash. Power off, complete shutdown, armageddon. All except my back up external drive which is connected via Thunderbolt monitor, seperate power supply.
    Had to unplug MAC tower for a few moments then restart.
    So, conclusion:
    I deduced my problems were now due to Motion (Perhaps always)”

    In general a user-mode app like FCPX cannot hang the the entire OS unless there’s an underlying system problem or a bug in a user-installed kernel-mode driver. The CPU’s hardware-enforced isolation between processes and user vs kernel mode prevents this.

    You can sometimes see what *appears* to be a plugin or app that hangs the system, but it’s not the fault of that app or plugin. It’s similar to how a truck could drive across a faulty bridge and cause a collapse — the bridge is decayed.

    Due to current limitations in MacOS plugin architecture, a plugin *can* hang or crash the host app – FCPX in this case. This is because currently all plugins run “in process”. With the new FxPlug 4 SDK, it will be possible for developers to migrate their plugins to an “out of process” design which will not crash or hang the host process: https://developer.apple.com/documentation/professional_video_applications/fxplug?language=objc

    Re Neat Video there was a bug which caused problems if combined with FCPX background rendering, but it was not a MacOS hang/crash. I strongly suggest you upgrade to the latest version of Neat Video due to this and also because it’s much faster.

    Be sure to run the built-in Neat Video optimizer which measures your memory, CPU and GPU performance then recommends a specific configuration. It is in the Neat Video menu Tools>Preferences>Performance>Optimize Settings.

  • Joe Marler

    March 3, 2020 at 5:58 pm in reply to: FCPX and C300 files

    [Jeremy Garchow] “I think the plan is to eventually add back support. It’s not here yet, though.

    I thought that was for 64-bit DNxHD support starting with Catalina. Oliver is on Mojave. I don’t have any camera native DNxHD but I exported some OP1A from Premiere in an MXF wrapper then re-wrapped to MOV with EditReady2, but FCPX 10.4.8 on Mojave and Pro Video Formats 2.1.1 would not take it.

    Do you have to load some Avid codec pack like this one? https://avid.force.com/pkb/articles/en_US/Download/Avid-QuickTime-Codecs-LE

    I thought *that* is what went away with Catalina. Not just 32 bit codecs but ability to add 3rd party codecs via Quicktime extension mechanism so system-wide apps can use those. The initial plan of action was each app vendor could then write their own parser and include the deprecated codecs within their app, but this was later changed so certain 64-bit codecs would somehow be approved by Apple and either included with MacOS or field installed. I think 64-bit DNxHD codecs are planned for Catalina, just not here yet, but not sure that’s Oliver’s issue.

  • Joe Marler

    February 22, 2020 at 10:16 pm in reply to: FORK FLOW IN FCPX with video and external mics

    [Kinga Kielczynska] “there is like one hour gap btw them the video and audio device. all the takes are very similar so its very hard to match in edit… i wonder if it could be done in audio sotware? after i did tests in Plural Eyes with both: XTML and media it doesnt work there (works 25 % of the time) i am a bit troubled. i will try this Modify>Adjust Content Created Date/Time”

    Setting cameras to free run timecode (IF available on all cameras AND recorders, and IF you plan ahead) is a nice trick. However to be really effective it requires the ability to simultaneously zero the timecode on all cameras AND recorders. Then in the NLE you sync on timecode. Dave Dugdale found an IR command to zero the free run timecodes on Sony Alpha cameras, and it worked pretty well: https://youtu.be/t3Fuoxbv81E

    If there is a one hour gap between the audio and video, the time of day clocks on those devices were not set properly. You can fix that as mentioned above. However that will NOT fix a difficult sync problem – only make the relevant files sort adjacent to each other. But it’s nonetheless an important step, because to sync them in a multicam clip in FCPX you must first identify what clips are temporally related.

    The file dates are not vital for Plural Eyes. If PE often fails to sync clips, that simply means audio waveform sync is not reliable in this case. Fixing the file dates within FCPX won’t help. It could be levels too low, too noisy, varying reverb, clips too short, etc. There is a reason people use hardware timecode.

    Your original question was whether to sync everything first or edit then sync the 1 hr result. My preference is sync everything first, but if PE is only syncing 25% of the clips, that is difficult. You could edit based on camera audio then for each clip select that in PE as camera 1, then select all the other audio clips as camera 2, then have it look for a match. No matter how you do it, it’s going to be a lot of work.

    This is simply a difficult situation and I am sorry for all the work.

    The last time I shot something like this I brought several Tentacle Sync devices, put them on all the venue cameras and this reduced the sync time to about 60 sec.

    Some contents or functionalities here are not available due to your cookie preferences!

    This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

  • Joe Marler

    February 21, 2020 at 2:29 pm in reply to: forgot to format

    [Brad Hurley] “If you can get into that folder you should be able to retrieve your media files even if the library is corrupted.”

    ^^^ This.

    Some people have reported that opening the library bundle and deleting CurrentVersion.flexolibrary fixed it. Instead of deleting it, I recommend *moving* it outside the library so you can put it back if needed. However before you do anything like that you ideally want the library backed up at a file level.

    If it is a managed library with all internal media unfortunately you can’t easily duplicate it for backup because it’s likely too large. However automatic backup versions of the library should be in /Movies/Final Cut Backups/LibraryName. Those are trimmed-down libraries without external media.

    First make a file-level backup of all those backup libraries – they are small. You could try to open one of the backup libraries. When opened by the new version of FCPX, it will try to upgrade them. That’s why you want a file backup of them. It might be necessary to dig up an old version of FCPX and try to open the old libraries with that, which is impossible after they are upgraded.

    If you have a file-level backup via Time Machine, Carbon Copy Cloner, or anything else, take steps to safeguard those in case they’re needed.

    BTW in all FCPX upgrade situations, save a copy of the old Final Cut Pro.app file bundle. Just rename it. Also save a copy of your library backups from /Movies/Final Cut Backups. That will allow reverting back in case the new version has some issue.

    These situations illustrate the benefit of using only “lean libraries”, ie media and cache kept only outside the library. That way it’s easy to duplicate for backup at a file level.

  • Joe Marler

    February 20, 2020 at 5:50 pm in reply to: FORK FLOW IN FCPX with video and external mics

    [Kinga Kielczynska] “Would Plural Eyes work to synchronise after the edit is locked?”

    I think that would work but (when I used Plural Eyes) I would normally sync everything in Plural Eyes before import. The other approach is export a project XML, sync in PE then re-load the sync’d project XML. I haven’t tested that procedure.

    As Robert mentioned, my preferred approach is sync everything before editing. We used to use Plural Eyes or the built-in FCPX audio sync, but now use hardware-based Tentacle Sync which is much better.

    If you have multiple cameras you often need to sync first to give the editor the choice of angles. Plus syncing by audio on a bunch of short timeline clips is difficult. Typically a waveform analyzer like Plural Eyes or FCPX audio sync is more reliable on longer clips – say 20-30 sec or longer. If you have a bunch of short start/stop clips they fail to sync more often. If the audio sources are from different sides of the venue, echo and reverb will vary which can throw off audio sync.

    Ideally every camera and recorder should be set to the same time of day. Within FCPX that makes the clips sort adjacently in chronological order. This makes it easier to find time-related clips in the FCPX Event Browser.

    If the cameras and recorder clocks were not properly set, first determine by inspection how far off they are. Using FCPX menu Modify>Adjust Content Created Date/Time, you can batch adjust all clips from a single device to the correct date/time.

    Each batch of clips from each device should be labeled in FCPX with a camera name or angle name – before syncing them. Select all clips from a given device, then in Inspector under the Info tab, enter a camera name (same for each audio recorder). That metadata is needed in case you create a multicam via FCPX.

    Even if you have a single video source and multiple audio sources, in general use a multicam clip not a sync clip. There are various reasons for this.

  • Joe Marler

    February 20, 2020 at 12:09 pm in reply to: forgot to format

    [Jonny Cates] “I been working on (2) projects since December. Finished one project recently, but now when I go back to the 1st project to open it back up, it now says it doesn’t recognize the format”

    Is it possible you were using multiple versions of FCPX and you somehow opened those “older” libraries using a newer version than you’re now running? If they were initially a truly older library it would upgrade them but you can’t open a newer library from an older version of FCPX – except between 10.4.7 and 10.4.8 where no library changes were made.

    You can check the library version from Finder by right-click>Show package contents, then use “quick look” (ie the space bar) on the file CurrentVersion.plist. Inside that file will be the library version.

    Once you do that, state the library version and what version of FCPX you are running. Also please state the disk format of that drive, whether ExFAT, HFS+ or whatever.

    If it still doesn’t work state the exact syntax of the error message.

  • Joe Marler

    February 15, 2020 at 1:36 pm in reply to: Used Mac Options for FCPX

    [Jon Lango] “looking for the cheapest Mac that will run FCPX. I will only be shooting simple videos, but want multicam editing,”

    Assuming you are using H.264 or HEVC, you will want a sufficiently new machine with Quick Sync hardware acceleration for this. No older Mac Pro tower or trash can has this.

    You could probably get a 2015 iMac 27 on eBay for maybe $500. That has the retina screen and avoids the sometimes-problematic 2014 models.

    The 2017 iMac 27 has the Kaby Lake CPU which has enhanced Quick Sync so is about 2x faster on decode of H.264 than the 2015. If you are willing to accept a 1TB Fusion Drive (yuck!) you could probably get one on eBay for maybe $700-800. You can always upgrade the RAM yourself.

    The 2013 iMac 27 can be quite capable but doesn’t have the retina screen or Thunderbolt 2. I’m not sure if the nVidia GPU is Metal-supported. In general you want a machine that can run the Metal-optimized version of FCPX which started with 10.4.7.

  • [Pieter Vlamings] “Also has glitches while playing in VLC.”

    Are the glitches in the *source* footage that was imported to FCPX? If so it’s likely not an FCPX problem. Can you describe or post an image of the glitches?

    What camera, frame rate, resolution, bit rate and codec? You can inspect those things using Quicktime Player 10’s menu: Window>Show Movie Inspector.

Page 23 of 96

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy