Forum Replies Created

Page 29 of 96
  • Joe Marler

    November 10, 2019 at 12:55 pm in reply to: Encoding speed in Compressor vs FCPX

    [Tangier Clarke] “My understanding was that using the “Send to Compressor” feature within FCP X will offload more of the work in Compressor to the GPU giving you improved performance.”

    I have never seen Compressor encode faster than FCPX, although it’s theoretically possible if using multiple machines for distributed encoding.

    A few years ago FCPX was definitely faster at encoding for some H.264 cases, I think because Compressor had not been fully upgraded to use Quick Sync as efficiently. Today they seem to be the same.

    There are two conceptual phases in exporting, render and encode. A lot of GPU-intensive work is in the render phase, not the encode phase. I have never tested how a timeline requiring GPU-heavy rendering (e.g. Neat Video, etc) is handled by Compressor.

    From the standpoint of software development, it would make sense to share as much code as possible between FCPX and Compressor. I don’t know why Compressor would be faster (outside the distributed case), but anything is possible, as demonstrated by it formerly being slower.

    Was there ever a period where Compressor could use multiple GPUs and FCPX could not? Maybe that would explain a possible difference.

  • Joe Marler

    November 7, 2019 at 8:46 pm in reply to: Encoding speed in Compressor vs FCPX

    There were past periods where FCPX was faster at certain encoding tasks, but I think they now use the same code and are similar in performance. However Compressor gives much more flexibility in encoding options.

    The FCPX export bit rate for H.264 master files is about 2x the bit rate Youtube recommends. So it is good quality but you could probably get by with about 1/2 that rate for some things. Compressor lets you do that.

    You can create a Compressor pre-set and use that within FCPX: https://support.apple.com/guide/final-cut-pro/share-using-compressor-ver1ff89071/mac

    If you have multiple machines available, Compressor can do distributed encoding across them. I have not tried this:

    https://youtu.be/onlDODH1l1o

    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

    November 7, 2019 at 7:17 pm in reply to: Missing camera/missing file problem?

    [Daniela Ventura] “my prof gave me a hard drive with a bunch of footage for me to analyze and keyword. We imported it in FCP and it seemed to be okay. When I went to work on it and I opened fcp, ALL the interview clips that I had to keyword where saying ‘missing camera’ or ‘missing file.’ “

    Can you verify the version of FCPX and macOS?

    When you import media it can be with “copy to library” or “leave files in place”. That’s in FCPX preferences. Also if using the import dialog (vs drag/drop from Finder) you can decide each time.

    If the media was copied within the library, it’s very rare to have missing clips. If it was imported with “leave files in place”, those files must always remain available. E.g, if you imported from a portable hard drive he gave you, then later the hard drive was disconnected, they will show as red missing clips.

    If the media is on a portable or external drive, make sure that is connected. Also that should ideally be formatted Mac OS Extended Journaled (aka HFS+), or APFS, not NTFS or ExFAT. Macs can read NTFS and can read/write ExFAT but FCPX tends to work better with HFS+ or APFS formatted drives.

    If external media is on an APFS or HFS+ drive, by using “inode lookup” FCPX can find the material even if the files are moved to another folder and filenames changed.

    Your title says “missing camera”. There is a separate problem whereby media is imported from a camera card and the import interrupted. This produces the error “”referencing media on the camera”.

    Ben Halsall discusses that in this video: https://youtu.be/NRNoReJbVoA

    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

    November 1, 2019 at 4:21 pm in reply to: Double yellow playhead lines

    The left is the playhead, the right is the skimmer. The skimmer can be in two modes, timeline skimmer or clip skimmer. That is toggled with View>Clip Skimming. Clip skimming only skims the single clip touched by the cursor, vs skimming all clip layers at the location.

    The yellow color happens if “snap” is on and the playhead or timeline skimmer is at a “snappable” location. Snapping can be toggled by the icon at upper right of the timeline or with View>Snapping.

  • [Oliver Peters] “I’m on a 2013 8-core and it definitely feels faster to me. Are you talking about media handling or interaction with the interface itself? If media, what format and codec?”

    All good questions. On my Vega 64 iMac Pro BruceX is 2x faster on 10.4.7 than 10.4.6, all on Mojave. Other FCPX built-in effects also seem faster. In general we’d expect the FCPX Metal improvements to help GPU-oriented code – if that code uses Metal. Neat Video is definitely GPU-intensive (if so configured) but it’s no faster on 10.4.7.

    On anything with a T2 chip there is apparently an improvement with H264 encode/decode. I haven’t yet tested machines with Quick Sync.

    I would expect even on a trash can Mac Pro that BruceX and similar GPU-oriented built-in effects might be faster. Doing back-to-back BruceX tests between 10.4.6 and 10.4.7 on a trash can would be interesting. Namely whether the Metal improvements extend back to those older GPUs.

  • [Giampaolo Moretti] “improvement in all rendering and importing sessions and 4K XAVC-LongGop clips can be played directly without dropped frames.

    Not the same on 2013 MacPro Trashcan. Here nothing change. Not even a little faster”

    XAVC-L is a variant of H.264. The Trashcan has no Quick Sync or any other type of hardware acceleration for this. The Xeon-powered iMac Pro uses the accelerator on the T2 chip.

  • Joe Marler

    October 25, 2019 at 11:06 am in reply to: How to tell what colour space a clip was recorded in?

    [Dave Smith] “how do you know when a clip is recorded with the log profile? Or any profile for that matter? Do you “just know” as part of the recording-editing process or talking to the cameraman? In my situation, as the one person doing it all, I certainly would know… but what if I came across footage I didn’t shoot?”

    Video camera metadata is not standardized like EXIF in a still photo where you can more consistently find these things.

    That said, the free command-line utility ExifTool can often extract color profile info from a variety of video formats. The info is not stored in a common place in the video file header, so you have to dump the data in verbose mode then search for words like “log”.

    https://www.sno.phy.queensu.ca/~phil/exiftool/

  • Joe Marler

    October 23, 2019 at 9:43 pm in reply to: Importing from SD and it seems not…Hmmm

    [Ty Ford] “Why do you suppose the system failed to copy the media to disk as my preferences had set?

    The file was 55 minutes. Maybe too long or it got interrupted?”

    That is a possibility. In this video Ben Halsall illustrates how it can happen:

    https://youtu.be/NRNoReJbVoA

    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

    October 21, 2019 at 3:53 pm in reply to: color mask not exporting in Final Cut Pro

    Sorry, I’m not familiar with this area. Does this info about FCPX blend modes help:

    https://www.rippletraining.com/articles/free-final-cut-pro-video-tutorials/2017/06/20/understanding-blend-modes-final-cut-pro/

  • Joe Marler

    October 20, 2019 at 7:32 pm in reply to: Weird Glitchy Area on my Footage

    [Jon Baum] “Same glitchy issues importing from my Canon Vixia HF G10 into Final Cut Pro v10.4.7 under MacOS 10.15 (Catalina). Workaround continues to be copying *.mts files to my MacBook Pro desktop from the camcorder’s SD card and then using EditReady to join the .mts files and then rewrap into a single .MOV file which is then imported into FCP -“

    I have some old HF G10 material and it seems to work OK on FCPX 10.4.7 on Mojave 10.14.6.

    Normally the correct procedure for AVCHD is import from the AVCHD package which automatically re-wraps and copies the files into the library. You should not copy .mts files out of the package and import using leave files in place, which can cause performance problems.

    Alternatively you can use EditReady to re-wrap the files in the AVCHD package and then import those using “leave files in place”. This automatically includes all needed metadata and handles clip spanning.

    If you still have problems when doing that, I can look at some test material if you put it on a share point.

Page 29 of 96

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