fbpx
3 Post Moderation Rule for New Boarders (25 Jan 2021)

New boarders will have their posts moderated - Don't worry if you cannot see your post immediately.

Is "Share" sometimes slower than sending a project to Compressor for encoding?

More
08 Jun 2020 13:58 #107746 by tpf1952
I realize there are so many variable to enumerate, but I've noted that sometimes when I send a project for encoding and uploading via Share, the project get's stuck in the encoding cycle for a very long time. In my impatience, I will abort the encode, send the project to Compressor to create a full-sized ProRes 1080P master, then encode that master to a large H264 that I will in tern upload to Vimeo. This second approach has more steps but encounters no bottlenecks. Anyone else have this experience with Share? Any suggestions for a fix? Share is convenient when it works (which is most of the time.)

Tom

Please Log in to join the conversation.

More
08 Jun 2020 15:41 #107747 by joema

tpf1952 wrote: ... I've noted that sometimes when I send a project for encoding and uploading via Share, the project get's stuck in the encoding cycle for a very long time...


In general FCPX and Compressor use the same underlying source code and there normally should not be a major performance difference. In older versions there was sometimes a difference, I think FCPX got better H264 encode acceleration before Compressor did. But on recent versions they should be the same.

There's an exception with HEVC export which FCPX does not have natively but must be imported as an export option from Compressor.

However there are some possible issues with FCPX tracking and using render files, esp in conjunction with certain combinations of built-in or 3rd party effects. In certain cases this can cause very slow exporting due to a bottleneck on the render phase of compute-intensive effects in the timeline. Sending that to Compressor might appear to work faster but if you simply re-launched FCPX it might also have the same result. FCPX can get stuck in a mode where rendering is very slow.

However there are other modes where re-launching FCPX does not help. Most of these center around unpredictable failure to use existing render files. With compute-intensive Fx in the timeline this can cause sudden and unexplainable slowdown of export. I discuss some of these in this thread: www.fcp.co/forum/4-final-cut-pro-x-fcpx/...se-or-project-switch

In general do these steps:

- Run recent versions of MacOS and FCPX. 10.4.8 has significant performance upgrade, esp. regarding Fx and some export types.
- Disable background rendering
- Delete all old render files with File>Delete Generated Library Files>Delete Render Files>All
- Do one-time or as-needed timeline render with CMD+A to select, then CTRL+R to render

If exporting to H264 use this setting: File>Share>Master FIle>Settings, Format: Computer, Video Codec: H.264 Faster Encode, Resolution: 1080p or 720p.

If exporting to ProRes use ProRes 422 which will match the render format and avoid re-encoding.

Please Log in to join the conversation.

More
08 Jun 2020 16:23 #107749 by tpf1952
Thank you so much for your comprehensive and thoughtful reply. I’ve been encoding to H.264 but you have given me many options to pursue. I make much of my living — more since the pandemic — from post production, so being able to resolve technical issues within the FCPX community is extremely valuable and highly appreciated.

Sincerely,

Tom

Please Log in to join the conversation.

More
08 Jun 2020 16:42 #107750 by JoeEditor
I've always just used H.264 straight from FCPX and upload to social media and get great results. The FCPX built-in uploading to social media function has never been 100% and I find it buggy and slow. I don't ever touch it.

Please Log in to join the conversation.