by Larry Jordan
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.
There are only two high-quality software tools – that I know of – that focus on media compression – Adobe Media Encoder and Apple Compressor – the 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.
- 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.
You can read the rest, including RAM results, why multi-threading makes a difference, and whether Larry thinks its’ worth it, over at LarryJordan.com.