When I send a video from Final Cut Pro X to Compressor (Latest versions) It only lets me render it on the local computer?

Hi Brian, re: compressor.app V4.1 (dec 2013) the simple answer is that it's simply NOT SUPPORTED. Formallyit is documented herehttp://support.apple.com/kb/HT6096?viewlocale=en_US&locale=en_US click on the link for the .PDF "transition to Compressor 4.1 white paper by Apple ". I'm sure other posters have refereneced this document in the past. Please excuse the redundancy.

To quote from Page 11 of this Dec 2013 document:

Compressor 4.1 simplifies distributed processing—the act of sharing transcoding work among multiple computers or computer processors.

What was previously referred to as a “cluster” in Compressor 4.0 is now called a “group” of computers. To configure a group of computers and set up distributed processing, you turn on access to your computer and then create a set of shared computers. If you can’t find a computer on your network, you can manually add it to the computer list.

Note: Compressor 4.1 does not support distributed rendering for other applications.

here you have it one place - 😉

The same is TRUE for Motion.app - only renders on a single host (no cluster capability)

Perhaps the term "rendering" is misleading in the sense that Compressor/Qmaster does not offer the RENDERING interface UI anymore since compressor 4.1 (4.0, 3.4 etc) . Thus 3rd party ISV rendermanagers can be used and are more effective.

Compressor.app V4.1 is now a very simply and easy to use to use TRANSCODE BATCH manager.

FCPX "send to compressor": I doubt if the clustering would help you too much even if you could have Compressor/Qmaster "render" or TRANSCODE" you workflow directly form FCPX.. it doesn't seem overly optimise for this due to the limited "automated" access of the mryiad SOURCE shared resources FCPX would need across multiple nodes. There are copious references to this workflow limitation on these forums... a can of worms.. however it's possible.

Heads UP: With the introduction of GrandcentralDispatch on the MAC OSX some years back, the utilisation of work over multiple cores has improved immensely. This a feature of FCPX 10.x is the BACKGROUND rendering with whom we are familiar. On the host where FCPX resides, the "rendering" is performed by multiple subtasks call PROMSRENDERER (Tool) ... this works really well and utilises all the cores it can.

From our perspective and experience, this is more efficient MOST of the time for preparing a MASTER in FCPX.

You might try the workflow of preparing the MASTER then adding this MANUALLY to COMPRESSOR.app V4.1 in order to deploy multipass segmented transcoding over your distributed cluster... a CLUSTER (your multiple compressord instances) for the transcode. Its an extra step and as usual it's an acquired taste.

HTH,

Post your results for others to see.

Warwick

Hong Kong

LOL. Do you represent Apple? Just because it's documented it doesn't mean it's not a bug! At a minimum, it's frustrating to see the network node listed, but greyed out. This should be addressed. Results posted for everyone to see.

🙂.. lol.. this commonly asked question about sending "RENDERING" and "TRANSCODING" FCPX adn MOTION projects to Compressor.app (also in TURN-AROUND/RETURN/TRIP) workflows to utilise a CLUSTER (distributed or otherwise) is unfortunately not a defect/flaw (a bug). It's been implemented as such.

A search of these forums and COW etc etc, will show that this has never really been formally documented. The contradiction to this is statement however is in the old legacy FCS 2/3 (suite) in the case of attempting to send a Final Cut PRO 7/7 to use a COMPRESSOR.app Qmaster cluster.

This WOULD work only if there were individually (or group) licenced FCP7/6 etc on those SERVICE nodes (same subnet or otherwise) and then a Managed Cluster was still unstable for trying to attempt. Qmaster errors would indicate this.

OPINION: In previous posts on the matter, and in my opinion as well, the complexities of making ALL the elements/source objects (plugins / transitions etc etc) available to ALL the services nodes (SHARED) and Managing the concurrent serialisation and further, all this in a transient structure for the original FCP transaction over a SYNCHRONOUS transaction in the FCP / FCPX UI is likely veryv ery complex to omplement and make stable in all situatons. SO.. me thinks that it was mooted by development as "too bloody hard" or the workflow the efficiencies were negligible... who knows?

Lastly, grandecntraldispatch in MACOSX its instance core utilisation for rendering FCPX projects is likely faster than trying to administer and manage the above.

At a minimum, it's frustrating to see the network node listed, but greyed out. This should be addressed. Results posted for everyone to see.

Your point is well made. I agree that the UI portion should be hidden not greyed out as this leads to wasted time in pursuance of a feature that cant be utilised.

FWIW, there are many other customised workflows and work instructions to gain efficiencies. to each their own... add to taste. 🙂

Warwick

Hong Kong