[ Updated Dec. 1, 2018, with a caution from Apple about ffMPEG and more complete summary comparison between Compressor, AME and ffMPEG. ]

The reason we compress a media file is that we need to make it smaller so that it can be rapidly transferred across a network. If network bandwidth was not limited, we wouldn’t need to compress a file because an uncompressed file will always look and sound better than a compressed file.

So, our goals in compressing any media file are to make it as small as possible, while damaging image and audio quality as little as possible. Given those two goals, I wondered what were the differences, if any, in performance and file size between different popular media compression software.

NOTE: When sending a file to YouTube, or any social media service, it is important to remember that each of these services recompresses the file. This means that you need to create a file with “extra bits” so that when it is recompressed the image quality is not overly degraded. Using the default YouTube, or social media, setting is a fast and good way to maintain image quality throughout.

Over three days this holiday weekend, I compared compression speed and file size between Apple Compressor, Adobe Media Encoder and ffWorks/ffMPEG running on a high-performance 27″ iMac and the new Mac mini.

With only limited exceptions Apple Compressor is the slowest compression software and also generates the largest compressed files.

In a head-to-head contest with Compressor, Adobe Media Encoder generally wins for speed and file size.

An upgraded Mac mini is a powerhouse video compression engine.

The GPU is almost never used in most video compression.

Results vary by computer and codec.

What makes these results even more significant is that Compressor is the underlying compression technology for Apple Final Cut Pro X, just as Adobe Media Encoder is the underlying compression foundation for Adobe Premiere Pro CC. The results of these tests can be directly applied to the performance of these very popular video editing software.

NOTE: While HEVC has a number of variations, the two most important are 8-bit and 10-bit. Compressing 8-bit HEVC is hardware-accelerated on most current Macs. This makes the compression very fast.

However, like H.264 which is also 8-bit, 8-bit HEVC can not be used for HDR media. Compressing 10-bit HEVC can be used for HDR media, but it can only be compressed using software; which, as you will see, takes a lot longer – if it can be compressed at all.

UPDATE: APPLE CAUTIONS ABOUT FFMPEG

Apple has published a caution about using ffMPEG with ProRes:

ProRes is a codec technology developed by Apple for high-quality, high-performance editing in Final Cut Pro X. …Apple also licenses and certifies ProRes for specific third-party products and workflows.

In some instances, unauthorized codec implementations have been used in third-party software and hardware products. Using any unauthorized implementation (such as the FFmpeg and derivative implementations) might lead to decoding errors, performance degradation, incompatibility, and instability.

I use ffMPEG to create H.264 files from ProRes masters. I have found its image quality and file size to be superior to that created by either Apple Compressor or Adobe Media Encoder. I have not had any of my compressed files rejected for technical reasons. This is why I included ffMPEG in my tests.

However, it concerns me that ffMPEG is using unlicensed ProRes code. This is inappropriate and potentially dangerous. While my test results stand for comparison purposes, I will start looking for other compression software to use in the future.

NOTE: The KnowledgeBase article from Apple, above, lists all licensed implementations of ProRes. There are a lot to choose from.

THE GEAR

This is the Mac mini I used for testing. It’s the high-end 6-core Intel i7. It has a 1 TB internal SSD. The i7 is multi-threaded, which yields faster results than an i3 or i5 Mac mini at the same clock speed. This Mac mini is also running the latest version of macOS.

This is the 27″ iMac I used for testing. It is 4-core Intel i5. While it has a faster clock speed than the Mac mini, the i5 is not multithreaded. This will prove to be significant limitation in the speed tests. It, too, is running the latest version of macOS.

THE TESTS

There are so many potential variations of codecs, frame sizes and content that it is impossible to test all the permutations. So, I chose to create 78 different tests using three different source file codecs – XDCAM, ProRes 422 HQ, ProRes 4444 – then compress them into five different codecs – ProRes 422, H.264, HEVC 8-bit, HEVC 10-bit and MXF OP1a.

NOTE: I didn’t see any benefit to testing against older gear. Older computers would only be slower. Computers older than 2015 don’t support hardware acceleration, which makes them far slower for H.264 compression. Also, HEVC is only supported in High Sierra or later.

ffWorks is a front-end to ffMPEG, which is open-source and popular media compression software. ffMPEG, itself, can only be run from the command line of Terminal. ffWorks greatly simplifies using ffMPEG. (Website: ffworks.net)

To keep things as fair as possible:

Each file was compressed with all source files stored on the internal hard disk of each computer.

Each file was compressed individually, there was no batch processing.

With only a couple of exceptions, I used default settings in each software.

Only the compression software was running on each computer.

The same versions of the macOS, compression software and settings were used on both computers.

All software was current as of the date of this test: Nov. 24, 2018.

Adobe Media Encoder was set to use Metal, rather than Open CL.

The same files were used on both computers. File durations ranged from 5 to 45 minutes.

Each software logs how long a compression job takes. I used these log files for timing.

We’ll look first at results by software, then, file sizes, and, finally, by the influence the GPU has on compression.

THE RESULTS

This table compares results for the three software running on the Mac mini. Green bars indicate the fastest software for each task. Yellow indicates where the iMac was faster than the Mac mini. Red indicates where Compressor failed to create a 10-bit HEVC compressed file.

Just to summarize:

Apple Compressor won 4 tests

Adobe Media Encoder won 2 tests

ffMPEG won 7 tests

This table compares results for the three software running on the iMac.

When we measured compression speeds on the iMac, speeds were somewhat slower and:

Apple Compressor won 3 tests

Adobe Media Encoder won 2 tests

ffMPEG won 8 tests (I forgot to highlight XDCAM to MXF)

Based on both these tables, here are my thoughts:

The Mac mini is a serious performer for video compression.

ffWorks/ffMPEG is the performance leader whenever hardware-acceleration is not a factor.

Adobe Media Encoder has improved tremendously in recent versions. In the past, it was too slow to even consider for serious compression work. Now, it takes full advantage of the hardware acceleration built into current Macs. More often than not, it beats Apple Compressor.

NOTE: In fact, Compressor failed to complete compression of two different ProRes 4444 files running on both computers. Failure occurred after 2.5 hours.

Even though Apple Compressor is optimized for Mac hardware, it only consistently wins when compressing 8-bit HEVC. For the much more popular H.264 codec, Media Encoder or ffWorks wins. This really surprised me.

Compressor also performs poorly in converting ProRes files into MXF and in handling ProRes 4444 files.

FILE SIZES

Green bars indicate the smallest file for each task, yellow is second smallest, while red indicates the largest. The default bit rate is illustrated under each file size. The actual bit rate will vary from these defaults depending upon the source file.

I also looked at compressed file sizes for two common compressed files: 8-bit H.264 and 8-bit HEVC.

What stuns me is that ffWorks wins EVERY time. And, from my personal experience, the image quality of its H.264 files is outstanding.

NOTE: Each of these software varies the actual bit rate applied to a file based upon its frame size, frame rate and the amount of pixel movement it senses between frames. The actual bit rate for each file will generally be less than the default setting.

Even more surprising is the VAST variation in size. As with file compression speed, Compressor does not do well in creating small files, which is one of the principle reasons for compressing a file in the first place.

As you can see from this table, the differences in file sizes are measured in HUNDREDS of megabytes. I would never have thought the differences would be that much.

THE GPU IS MOSTLY IRRELEVANT

Apple Compressor CPU / GPU activity, measured using Activity Monitor and running on the iMac. The two windows on the left show GPU (top) and CPU (bottom) loads over time. The left side of each history represents activity compressing XDCAM EX, the right side compressing ProRes 422 HQ, both into H.264. Click to see a larger image.

This screen shot shows how Apple Compressor is using the GPU and CPU. This displays two different compression jobs: XDCAM EX on the left of each history window and ProRes 422 HQ on the right. Compressor is compressing both these files into H.264.

In the table on the right, compressord is the compression software that is actually doing the compression. Since this CPU has four cores, the maximum CPU load is 400%.

NOTE: As you can see in the history panels, there is almost no GPU activity during H.264 compression. In most cases, the GPU does not affect video compression. However, video compression often includes other operations including retiming, scaling, and color conversion — all of which use the GPU. I did not do any tests which involved rescaling the image; and I have never modified color during the compression process.

The left side of the CPU history shows Compressor struggling to compress the XDCAM EX clip. CPU utilization never exceeded 75% (bottom center window).

NOTE: While this screen shot is from the iMac, the results would be similar for the Mac mini, except that it has more cores.

Adobe Media Encoder CPU/GPU activity compressing XDCAM EX and ProRes 422 HQ files into H.264, measured using Activity Monitor. This is the same layout as the window above. Click to see a larger image.

AME handled the XDCAM EX media (on the left of the CPU history) much more efficiently. It struggled with the ProRes 422 material. CPU utilization was about 50% (bottom center window).

NOTE: Again, very limited GPU activity.

ffWorks/ffMPEG CPU/GPU activity compressing XDCAM EX and ProRes 422 HQ files into H.264, measured using Activity Monitor. This is the same layout as the two windows above. Click to see a larger image.

Unlike both Compressor and AME, ffWorks maxed out the CPU, regularly approaching 100% utilization. Also, as with the other two software, ffWorks does not use the GPU.

The CPU history shows both XDCAM EX (on the left) and ProRes 422 HQ (after the gap) on the right.

NOTE: While some transcoding between codecs does use the GPU, most codecs don’t take advantage of it.

EDITORIAL

It is long-past time for Apple give serious attention to Compressor. Yes, the latest version is now a 64-bit application, but I’ve seen no significant improvement in performance with this upgrade.

Worse, there’s no excuse for it to fail to compress a ProRes 4444 files into 10-bit HEVC. HEVC is the new standard for HDR media, this failure means someone at Apple isn’t paying attention. And, when compared to the other two programs, Compressor lags behind in handling ProRes files.

As well, I’ve personally had problems with Compressor creating MP4 files – so much so that I stopped using it for this purpose more than a year ago. The image quality was poor and, in many cases, QuickTime Player refused to play the compressed MP4 files.

Compressor is too slow, creates files that are too fat, and is unreliable.

The only thing I use Compressor for now is creating HTTP Live Streaming files for mobile devices that are streaming from my website. The other two software don’t support that format.

Compressor has the easiest to use interface, but creates the poorest results. It is time this software gets fixed.

SUMMARY

For me, the winner is ffWorks/ffMPEG. I’ve been using it for almost a year now and continue to be impressed with its speed, power, and flexibility. It is not easy to learn, but, as we see in these tests, it’s worth the effort.

Adobe deserves major credit for improving AME. It works quickly, creates reasonably small files and runs on both Mac and Windows. It is a solid workhorse if you already own the Adobe Creative Cloud suite of applications. AME’s performance also explains why Premiere Pro CC has so improved its export and compression speeds.

However, I can’t think of any good reason to depend upon Compressor for video compression in its current state. What makes this statement especially troubling is that the compression engine in Compressor is the same engine that underlies compressing files in Apple Final Cut Pro X. With the possible exception of exporting a master file, FCP X is negatively impacted by Compressor’s lack of performance.

While I have not tested this, I would expect similar results from FCP X, given the same export settings. This means that FCP X is at a significant disadvantage if you are using it to compress media files during export.

NOTE: This is one reason I recommend always exporting a master file, then compressing that file separately, rather than exporting and compressing in one pass.

I would have liked to see a Windows 7 professional or Windows 10 implementation of AME included somehow for those stuck with Windows at work. After using AME on both, it seems they have spent more time with the Windows versions.

These tests were run on a 2018 Mac mini using the standard H.264 settings for ffMPEG. Whether that enabled the video toolbox I don’t know. Especially with ffMPEG, I’m VERY cautious about changing default settings because there are so many controls it extremely easy to screw something up if you don’t know precisely what you are adjusting.

This produces a mute h.264 file via the videotoolbox encoder and therefore will use any available hardware acceleration.
(My understanding of the T2 chip is that it ‘only’ accelerates HEVC encoding I think – not had a definitive answer on this).

Be interesting to know what kind of speeds you get on the MacMini and if there is a way to determine whether it is indeed using the T2, or its reliant on the Intel iGPU only.

Thanks for doing this test, this is great. I’m wondering (and it really couldn’t be tested easily without some help from Apple) how much of a difference RAM makes, and also how much of a difference the 3.0 vs 3.2 Ghz processors make. If I buy a new Mac Mini specifically to render ProRes to H.264, I’d like to figure out if it’s worth the processor upgrade, and how much (if any) difference there is going from 8 to 16 up through 64 GB RAM. Without actually testing, do you have any idea/indication of what difference RAM makes? Considering the price ranges from $1099 to $2699, it’s an important question to ask.

RAM makes a difference in managing multiple files or when you are shuttling back and forth. This is typical for editing, but not compression.

The difference in CPU speed is, essentially, negligible (about 6%). The BIGGER question is whether it is an i3, i5 or i7 chip. The performance differences between these three chip architectures FAR!! outweighs performance benefits from CPU speed.

I just did some ProRes renders yesterday and discovered (unofficially):

* ProRes encodes take advantage of every core
* ProRes encodes push the CPU to about 85% of maximum performance
* 8 GB of RAM was not filled during compression
* I have a 512 GB SSD – I am changing my recommendation to stay with 8 GB of RAM, but boost the SSD to 512 GB – the extra workspace is very useful in video compression.

I wonder though… I doubt the write speed of the SSD is having any effect here. So if you were to render to an external drive, even USB, or even render to a drive across a gigabit network, if you’d see any performance hit at all. Copy the ProRes to the SSD (or in my case, render a ProRes master file from FCPX to the MacMini’s internal 256GB SSD across the network), have Compressor on the Mac Mini render the ProRes to H.264, but writing back across the network to another shared drive. Waddaya think? The render time is far far slower than write time, even over the network. At least, theoretically 😉

It depends. Compressor processing ProRes data at about 80 MB/sec on the Mac Mini PER STREAM. If you are only encoding one movie at a time, you are correct.

However, if you are encoding multiple movies at the same time, and the movies are temporarily copied to the internal SSD, you can boost overall compression speed when using more than one instance of Compressor and a multi-threaded CPU.

My tests purposefully did not test compressing more than one file at a time simply to minimize variables. However, now that I have the Mac mini installed, I’ve optimized it to compress three files at the same time, using three different instances, and, for ProRes, this makes a significant difference. For H.264, though, not so much.

Oh wow… I didn’t even realize there were multiple instances now (I see the feature now). Looking at the Compressor online help, it shows how many additional instances you can add if you have 4 fours cores (zero) or eight cores (one) but it doesn’t mention 6 cores… which is of course what the Mac Mini has! Hmmm

Kind of annoying that the instructions literally tell you to test a series of combinations to get the best performance. You’d think the software could look at what the system has and configure it for the best performance possible. I mean… who wants their renders to be *slower*?

I appreciate this ongoing conversation Larry, thank you for your time.

You said “I’ve optimized it to compress three files at the same time, using three different instances, and, for ProRes, this makes a significant difference. For H.264, though, not so much.” — do you mean that you’re rendering something TO ProRes, or FROM ProRes? My workflow would be to render a ProRes master from Final Cut, then use Compressor (on the Mac mini) to encode those to H.264. Your statement “for H.264, not so much” confused me. Thanks.

Great article ! I will try it out – HOWEVER – just sent a 90GIG prores file to AME and was given 37 hours to completion. Stopped it after 30 minutes and put the same file into Compressor – all complete within 30 minutes. AME 2019 CC seems VERY SLOW in some circumstances. I will try ffWorks. Thanks for the fantastic comparison.

[Update] My mistake – it is an HEVC issue. Had forgotten to select HEVC in Compressor – looks like both AME and Compressor take LONG TIME for HEVC and my audience will never notice the difference.

You make a good point. HEVC is hardware-accelerated only in single-pass, 8-bit mode. This is reasonably fast, but not as fast as compressing media into H.264. 10-bit HEVC, which is required for HDR media, is compressed in software – and, today, as you pointed out, that will take forever.

Also, if you are running a recent computer and operating system and using Adobe Media Encoder, be sure to set Preferences > General > Video Rendering to “Mercury Playback Engine (Metal)” – NOT OpenCL.

Is there not a comparison of the most important factors for me: rapidly changing image detail and color profile fidelity?

I’ve had the impression that Apple Compressor had the best results in terms of detail, color, and contrast fidelity to the intended master (playing well with a REC 709 look), particularly when the resultant file was uploaded to Youtube or viewed through QuickTime.

I’ve been thinking about this, but haven’t figured how to test this. Key questions include: What do I use as test media, how do I measure artifacts, and how do I determine color fidelity?

Based on working with different software, I have opinions based upon what I can see – but developing a reasonably reproducible test that delivers empirical results about quality – THAT is a lot harder.

Not a member? See The Different Membership Tiers.
Become a member of our Video Training Library & Get unlimited access to our highly-acclaimed training, Thousands of movies available 24-hours a day, 7-days a week.