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
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.
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.
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:
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:
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.
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.
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.)
Here are the results of my testing.
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.
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.
Here are other recent articles on media compression that might also be of interest to you:
4 Responses to Optimize Apple Compressor for Greater Speed
That was an incredibly informative piece. Thank you so much for taking the time to test.
Happy to help.
Hi Larry. I feel that you’re missing the point of enabling additional instances of Compressor. With more instances its possible to process a batch of files in parallel.
So for example with a batch of 4 ProRes files to transcode to mp4, with 1 extra instance, 2 files are processed simultaneously!
In my real world job example I’m transcoding 57 minute PAL ProRes files to MP4 for delivery to broadcaster’s spec. (No frame size or rate change)
1 transcode solo took 15 minutes
4 files in batch, 1 extra instance took 49 minutes.
Saving 11 minutes compared to processing individually…
(There’s probably a bottleneck on disk i/o with extra instances.)
Good to know. However, I think it also depends upon how many cores you have in your system. There is a finite amount of CPU resource available. Running multiple instances on a smaller CPU would not yield the same benefits, I don’t think.
I’ll have to play with this some more.