Apple FCP and Compressor vs. Adobe CC, Timeline-to-Transcode Workflows, Part 2: Test Results--UPDATED WITH LINK TO TEST FILES

Hard Stop

After updating to Compressor 4.1.1, just as we were setting out to run our tests, we discovered that Final Cut Pro and Compressor are not capable of natively handling the RED camera’s raw .R3D file format. At first it looked like this would bring our testing to a hard stop.

Fortunately, we found that R3D files rely on the RED Apple Workflow plug-in solution, available at RED’s website. Once we had this plugin installed, it allowed us to open R3D files in the Final Cut Pro timeline and use “Send to Compressor” to run tests from FCP to Compressor.

Both Premiere Pro and Adobe Media Encoder can work with .R3D files natively, by the way, which seems odd given the fact that Apple had a lock on the RED workflow just a few years ago. (Click the image below to see it at full size.)

Test 1: Timeline Output, Single Transcode

A single-clip timeline is delivered from the NLE’s timeline direct to the companion transcoding tool.

Test 3: Timeline Output, Long-form Content, Single Transcode, Timecode Overlay

A multiple-clip timeline, with direct cuts between content files in the sequence, and is delivered from the NLE’s timeline direct to the companion transcoding tool. This provides a timeline output of more than twelve minutes. (Click the images below to see them at full size.)

Final Cut Pro - Compressor

Premiere Pro - Adobe Media Encoder

Note the differences not only between the two different transcoding tools--Adobe Media Encoder and Compressor--but also between the OpenCL-powered MacBook Pro and the software-only MacBook Air.

In some cases, the MacBook Pro’s NVIDIA GPU cut encoding times between Compressor and Adobe Media Encoder in half, and it brought the encoding time down to more than half of the MacBook Air’s transcode time. Yet even the software version of AME, run on the MacBook Air, was faster than Compressor. A large part of this is probably due to the fact that Compressor is still a 32-bit architecture.

Readers may question the fact that the file sizes are so different. We set the target bitrate exactly the same between the two transcoding tools, yet Adobe Media Encoder chose to compress even more than Compressor. Logically, this should result in additional processing time, because further compression requires further processing time. Yet AME was able to compress both more efficiently and faster than Compressor. We ran the results multiple times, yet each program consistently returned the same results.