Video Compression Speed Test: Apple Compressor vs. Adobe Media Encoder vs. ffWorks/ffMPEG [u]

[ 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.

NOTE: Here’s the link to my 27″ iMac vs. Mac mini speed comparison.

The results were surprising and worth sharing.

EXECUTIVE SUMMARY

• The hands-down performance champion is ffWorks/ffMPEG.
• 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.

Here’s a link to the entire tech note: support.apple.com/en-us/HT200321

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.

NOTE: Here’s an article that explains the differences between an i3, i5 and i7 CPU.

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.
• Apple Compressor is slow; sometimes REALLY slow. It’s implementation of HEVC 10-bit encoding is simply awful.

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.

EXTRA CREDIT

Here’s a PDF of all my findings and notes (64 KB).

Be sure to read this article to learn more about the differences in compression software that I used for this test.

---

Bookmark the permalink.