Welcome, Guest
Username: Password: Remember me

TOPIC: Compressor created Proxies created much quicker than in FCPX

Compressor created Proxies created much quicker than in FCPX 14 Jan 2020 01:55 #103892

  • MZTVPD
  • MZTVPD's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 1
  • Karma: 0
Quick scenario here ... using a MacBook Pro 16" I decided to clock Compressor creating a ProRes Proxy at half-res (960x540) of a 2.5 hour MP4. Amazingly it only took 10 minutes!

Why then, when I use FCPX to do the same thing, it takes over 50 minutes?

The obvious problem being that it doesn't seem to be easy to get custom proxies working (from what I'm reading in here as well). Can anybody shed any light on this? Thanks!

PS. Even more amazingly, using the H264 preset (and the T2 chip), that same 2.5 hour video took the same 10 minutes to create a half-res H264 proxy!
The administrator has disabled public write access.

Compressor created Proxies created much quicker than in FCPX 14 Jan 2020 07:24 #103894

  • arc
  • arc's Avatar
  • NOW ONLINE
  • Gold Boarder
  • Posts: 161
  • Thank you received: 14
  • Karma: 1
I wonder if the 2T chip is better than Intel's Quick Sync. Does anyone know?
The administrator has disabled public write access.

Compressor created Proxies created much quicker than in FCPX 14 Jan 2020 13:16 #103899

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 1322
  • Thank you received: 275
  • Karma: 26
MZTVPD wrote:
...using a MacBook Pro 16" I decided to clock Compressor creating a ProRes Proxy at half-res (960x540) of a 2.5 hour MP4. Amazingly it only took 10 minutes!

Why then, when I use FCPX to do the same thing, it takes over 50 minutes?

Internally, both FCPX and Compressor mostly use the same code for that. Given an equivalent conversion on the same hardware with the same app versions, I'd normally expect about the same performance.

In both cases you area converting from 4k H.264 to ProRes Proxy. FCPX has a single built-in format for this which is 1/2 the linear resolution or 1/4 the pixel resolution. Thus a 3840x2160 H.264 original will become a 1920x1080 ProRes Proxy.

Re T2 or other hardware acceleration, since ProRes does not require this the only benefit would be on the decode side, not the encode side. 1920x1080 is about 4x the pixels of 960x540, and the difference in your times was roughly 4x, so maybe that explains it.

MZTVPD wrote:
...The obvious problem being that it doesn't seem to be easy to get custom proxies working (from what I'm reading in here as well). Can anybody shed any light on this? Thanks!

The build-in FCPX proxy system provides a single scaled resolution at 1/2 the linear or 1/4 the pixel resolution and the only codec is ProRes Proxy. It's not perfect but it's very reliable and never gets out of sync. However traditional FCPX proxies cannot be relinked; this is an issue of they are placed outside the library using the Library Inspector>Storage Locations>Modify Settings.

You can bypass that if you create your own proxies and relink to them as original media, then relink back to the original media after editing. FCPX relink is very fast and can search all files on a large disk volume, relinking them in a single pass. This method does not use View>Proxy, but your self-built proxies as original media. IOW FCPX doesn't know you are using proxies.

FCPX media relink constraints:
- Files must have the same audio config (same number of channels), but sample rate can differ.
- Pixel aspect ratio should be the same, but it may relink even if different. This could result in a squeezed or stretched frame.
- Clip duration must be the same or longer. If longer, then later relinking to the original clip won't work because the new target will then be shorter.
- File suffix must be the same.
- Codec need not be the same, e.g. you can create 720p H264 proxies and relink to those as original media.
- After relinking to a different resolution file, the viewer may show a window-boxed screen. This is typically a cache issue and can be resolved by deleting the FCPX cache for that event, which is either stored in the library or outside as defined by the library inspector. The cache is a file bundle named LibraryName.fcpcache.
- Camera-generated proxies are all different cases and relink to those and back to full res media should be tested for each situation.
- Any use of this method should be thoroughly tested on a few files, then scaled up before using in production.
The administrator has disabled public write access.