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

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:

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:


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:

Based on both these tables, here are my thoughts:

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

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.

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

  1. As always Larry, excellent work as well as eye opening. Can’t thank you enough for your continued diligence and expertise.
    Lou Hemsey
    Lou Hemsey Music and Film

  2. John Teegarden says:

    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.

  3. ffWorks is my favorite as well. I am a FCPX user but don’t even own compressor.

  4. Shakti Vihar says:

    Can you please update the article to reflect hardware encoding on the Mac Mini 2018 using the built-in T2 chip?

    As far as I’m aware, both ffmpeg and Compressor support the T2 when outputting h.264 and 8-bit HEVC, and the speed is quite something.

    • Larry says:

      Shakti:

      These tests were run last week using a brand-new Mac mini (2018), which includes the T2 chip. However, the T2 chip does not handle video compression, the Intel CPU does.

      Larry

  5. Shakti Vihar says:

    Hi Larry,

    This appears to be incorrect. When using the latest version of Compressor, the T2 chip does the HEVC 8-bit and h.264 encoding.

    You can also use the T2 hardware accelerated encoding in ffmpeg/ff.works by changing the x.265 encoder to the videotoolbox accelerated one.

    If you could run those tests it would be very much appreciated!

    • Larry says:

      Shakti:

      Very interesting. I was unaware of this and I’m happy to run the test again. However, I had a loaner Mac mini – mine is on back-order – so it will take a couple weeks until I can run this again.

      larry

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

    • Larry says:

      PhotoJoseph:

      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 spent $1,400 for my system, after discounts at Adorama.

      Larry
      Larry

      • Awesome! So the configuration is…
        • 3.2Ghz 6-core i7
        • 8 GB RAM
        • 512GB SSD

        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 😉

        • Larry says:

          PhotoJoseph:

          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.

          Larry

          • 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*?

          • Larry says:

            Joseph:

            It’s not that simple. If ALL your system is doing is media compression, running multiple instances makes sense.

            But, if you plan to do other work, running multiple instances slows the system down for anything EXCEPT video encoding that the system becomes unworkable.

            That’s why the default is one instance because it provides good compression performance without bogging down the system.

            Larry

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

Leave a Reply

Your email address will not be published. Required fields are marked *

Larry Recommends

Final Cut Pro X 10.4

FCPX Complete

Edit smarter with Larry’s brand-new webinars, all available in our store.

Access over 1,900 on-demand video editing courses. Become a member of our Video Training Library today!

JOIN NOW

Subscribe to Larry's FREE weekly newsletter and save 10%
on your first purchase.