Optimize Apple Compressor for Greater Speed

2019 is the year when the next macOS means that many legacy media files will stop working. (Here are the details.) Because of this, we must convert older media files into something current in order the play them back.

Apple has announced that it will provide the ability to identify and convert legacy codecs in the the first half of next year. They originally announced this would be a feature in Final Cut Pro X. It makes more sense, and I’ve suggested this to Apple, that this ability to find and convert legacy media should be it’s own utility – ideally, part of Compressor. If Apple implements this suggestion, Compressor becomes even more vital for our media workflows.

So, I decided to test different “instance settings” within Compressor to see which would yield the fastest compression speeds. Only to discover, in the middle of my tests, that Apple released a new update to Compressor to version 4.4.2. So, I was also able to see if there were any performance changes between the two versions.

WHY THIS IS IMPORTANT

• Telestream Episode is no longer available.
• Sorensen Squeeze is no longer available.
• ffMPEG has significant legal/licensing issues.

I know of only two high-quality software tools specifically designed for media compression – Adobe Media Encoder and Apple Compressor – that run on a Mac.

Adobe Media Encoder compresses in parallel by default. Compressor allows you to choose how many instances you want to use.

Since media conversion will become a critical issue during 2019, it makes sense this year to start testing to see what we can do to optimize Apple Compressor for speed.

BACKGROUND

Compressor, the application, is a front-end to a background process called “compressord.” This Unix daemon runs in the background, has no user interface and takes the settings and files that are created in Compressor and compresses the media as instructed.

NOTE: Because Compressor is simply a front-end, once you click Start Batch, you can quit Compressor and your files will still compress. During compression, Compressor is serving simply as a monitor for the on-going compression process.

Because compressord is separate from Compressor, it has the ability to run copies of itself, each called an “instance,” to theoretically speed compression. However, the more instances you run, the slower all other apps will become, because more system resources are devoted to running multiple versions of the compressord background process. The default instance setting is 1.

NOTE: Multiple instances won’t help compress a single large file. They should help when compressing multiple files at the same time in the same batch. Whether they actually do was the purpose of this test.

EXECUTIVE SUMMARY

• There are no performance improvements with the latest release of Compressor – v. 4.4.2.
• If you normally compress only one file in each batch, there is no benefit to enabling multiple instances.
• If you are compressing multiple files in the same batch, my testing shows that running Compressor with multiple instances enabled does not improve performance, except when compressing files into MXF XDCAM.
• Total RAM used for any tested compression never exceeded 5 GB, so an 8 GB system will work fine for virtually all video compression systems.
• CPU speed and multi-threading support are the key elements to consider when determining what system to use for video compression.

In these tests, I only used system default settings. I did not test performance results for scaling, frame rate conversion or adding watermarks.

MY SYSTEM AND TESTS

This is the system I used for my tests. It exactly matches the system I outlined in my write-up on how to configure a system for video editing. Read the entire configuration write-up here.

For this test, I used three default settings:

• Video Sharing Services. This creates a QuickTime movie using the H.264 codec. I used the setting that matched the frame size of the video: HD 720p or HD 1080p. (These are the best settings to use for social media files.)
• ProRes 4444. This creates an extremely high-quality file which is optimized for editing.
• MXF XDCAM. This format is widely used in broadcast, cable and other quality-sensitive distribution platforms.

In each case, I made no changes to the settings shipped by Apple.

For source files, I used the same files I used in my earlier tests:

• XDCAM 720p file, 8:59 in duration
• ProRes 422 1080p file. 4:45 in duration
• ProRes 422 HQ 1080p file. 48:05 in duration.

Because the files are of different durations, we can’t compare results between files, but we can compare different results for the same file.

NOTE: I purposefully did not test any ProRes 4444 source media, because the Compressor version prior to 4.4.2 had problems with this format. I have not had time to determine if the latest version of Compressor handles this format any better.

To enable multiple instances, go to Compressor > Preferences > Advanced.

Check the top check box and choose the maximum number of instances that is available from this menu. (Other computers and CPUs will have different numbers in this menu.)

Remember, the more instances you are running, the slower ALL other apps on that computer will run. It’s a trade-off. My system is used exclusively for media compression, so I can afford to set this to a high number.

The only other non-default setting in Compressor was that this option was turned on in Preferences > My Computer.

RAM RESULTS

Because a reader asked, I paid special attention to how much RAM was used during compression. The short answer is that across all tests, RAM used ranged between 3.5 and 5.2 GB. The average was about 4.5 GB. This means that a system with 8 GB of RAM should work fine for media compression.

You can monitor this yourself using Utilities > Activity Monitor. Click the Memory tab and look at the chart at the bottom. The key section is Memory Used.

• Cache files are loaded into memory to save going to the hard disk, however with an SSD that’s as fast as the Mac mini, this is no longer the performance benefit it used to be.
• Swap is when files are written to/from the hard disk. Again, given the speed of the SSD, this is not a big deal anymore either.

MULTI-THREADING MAKES A DIFFERENCE

Multi-threading is the ability to spread a compression task across all cores in a CPU. Only the i7 chip in the Mac mini supports multi-threading, which is why I recommend it.

However, not all codecs take advantage of multi-threading. Here are three examples.

(CPU allocation when compressing source media into H.264)

For example, H.264 is not a multi-threaded codec. As you can see here, the six cores were not fully utilized and the “secondary” cores were not working at all.

(CPU allocation when compressing source media into MXF XDCAM)

Here, the CPUs were much busier compressing source media into MXF XDCAM, but still less than fully utilized.

(CPU allocation when compressing source media into ProRes 4444.)

However, all CPUs and cores were essentially fully utilized when compressing source media into ProRes 4444.

(One instance of compressord using almost 700% of CPU capability, 1200% is max.)

You can measure how fully utilized your CPUs are using Utilities > Activity Monitor. Click the CPU tab at the top, and look at the compressord setting. (You can determine the maximum CPU utilization number by multiplying the number of cores times 100%. In the case of my Mac mini, that would equal 1,200% (Two cores per CPU, times six CPUs, times 100%.))

NOTE: Whether running one instance or three, the maximum performance you can get out of a computer is based upon this CPU performance number: 1,200%, in my case. Once your CPUs are fully maxed out, you can’t go any faster.

(Three instances of compressord, using about 750% of CPU capability, 1200% is max.)

COMPRESSION RESULTS

Here are the results of my testing.

• When compressing for social media, using the H.264 codec, running three instances was 2.2% faster than when running a single instance.
• When compressing media into ProRes 4444, a single instance was 1.3% faster than multiple instances.
• When compressing media into MXF XDCAM, three instances were, on average, 21.3% faster, with maximum performance occurring when compressing XDCAM source media.

What this tells me is that, for most video compression, running Compressor in single instance mode will yield the best results when compressing for the web or into ProRes. However, if you are delivering non-ProRes media for distribution, it is worth testing multiple instances to see if there is a performance benefit for your media.

NOTE: Audio compression, in contrast, is so fast that I haven’t bothered to test it; it’s done before I finish clicking the stopwatch.

SUMMARY

These results were not what I expected. I thought that the speed difference in using multiple instances would be significant, but, except for MXF, they weren’t. At all.

These tests indicate that compression is a multi-faceted tool, if you are compressing a lot of files, it would be worth a day to test your media to see what yields the best results. For me, given these results, when I use Compressor, I’m using it in single instance mode.

EXTRA CREDIT

Here are other recent articles on media compression that might also be of interest to you:

• Video Compression Speed Test: iMac vs. Mac mini
• Video Compression Speed Test: Apple Compressor vs. Adobe Media Encoder vs. ffMPEG
• Apple Compressor: Build a Media Compression Network
• Apple Compressor: Automate Media Compression with Droplets

---

Bookmark the permalink.