[ Updated Feb. 5, 2022, by adding comparisons with a 2018 Mac Mini with an i7 CPU and the latest version of FFmpeg – Jan. 17, 2022 build – optimized for Apple silicon. ]
In this article, I compare the compression speed of Apple Compressor, Adobe Media Encoder (AME) and ffWorks (FFmpeg) on a new M1 MacBook Pro vs. an older Intel iMac. This is one of those articles that takes forever to create, yet can be understood in less than a minute.
NOTE: Apple Final Cut Pro and Compressor use the same compression engine; I would expect compression speeds to be similar. As well, Adobe Premiere Pro uses the same compression engine for its exports that’s in Adobe Media Encoder. Here, too, I would expect compression speeds to be similar.
EXECUTIVE SUMMARY: Regardless of the software you prefer to use, the M1 MacBook Pro makes encoding into any video format MUCH faster! Also, we will discover that compression speed is not dependent upon how hard the CPUs are working, how fast the hard disk transfers data or, in Intel systems, which CPU you are using.
NOTE: I originally wanted to use Handbrake for this test. However, none of the compressed files it created could be opened. So, I switched to ffWorks.
Why did I choose ffWorks? Because, like Handbrake, its compression engine is FFmpeg, which is widely used in media software. However, Apple has said that FFmpeg has reverse-engineered, rather than licensed, its ProRes implementation. For this reason, they caution against using any software running FFmpeg for creating ProRes files.
However, I have not had any problem when using FFmpeg to read ProRes files and convert them into other formats for YouTube, my website or other social media.
UPDATE: A criticism I received after initially publishing this was that the Intel i5 CPU is significantly slower than an i7 or i9. So, I added test results from a 2018 Mac mini with an i7 CPU. I also re-ran the tests using the latest version of ffWorks (v3) and a version of FFmpeg optimized for Apple silicon CPUs; both of which were released after initial publication. You’ll find all the new results in the Update section below.
Here’s the new system, with an M1 Pro CPU. Notice it’s running the latest version of macOS.
NOTE: Both the M1 Pro and M1 Max have 10-core CPUs, though not the same number of GPU cores. (I don’t, currently, have a way to test the M1 Max.) My suspicion is that the GPU has an impact on compression speed, but I don’t know to what extent; it will probably vary by software. Also, in general, encoding speed is not dependent upon the amount of RAM.
This is the Intel system that I used for reference. (Yeah, I know. It’s kinda old. However, it was what I used every day until Monday last week.) Notice that it has an Intel i5 CPU; this is not as fast as an i7 or i9, but a high-performance graphics card.
UPDATE – Feb. 5, 2022
Here are the specs for the Mac mini I added in the updated version of these tests. Note that it has an i7 CPU, but only 8 GB of RAM and Intel’s GPU, which is not noted for its speed.
THE SOURCE TEST FILE
The test file was a 54:11 QuickTime ProRes 4444 file (1440 x 810 pixels with stereo audio).
NOTE: For some reason, Adobe Media Encoder is not always able to open a ProRes 4444 file exported from Apple Final Cut Pro. I exported the file four times and it was unable to read it each time; though it would open perfectly in QuickTime Player, Compressor and ffWorks. I finally changed source files until I found one AME could open. I’ve run into this problem before and have no idea why Media Encoder fails to read a ProRes 4444 file.
I ran three tests:
I ran each test twice on the M1 MacBook Pro and averaged the compression times. Then I ran each test once on the iMac. I also tracked the CPU load and data transfer rate on the MacBook Pro during compression.
NOTE: Compressor supports hardware acceleration when encoding HEVC 10-bit media. However, Media Encoder and ffWorks only use software acceleration. (All three use hardware acceleration to encode 8-bit HEVC, however, 10-bit is required for HDR material.)
TEST 1: ENCODING INTO H.264
While Compressor showed the greatest improvement in speed, Adobe Media Encoder was the fastest. In fact, AME is generally faster than Compressor on Intel systems, as well. For example, as the chart shows, Compressor was the slowest of the three when running on Intel. Based on past tests, until the M1 Macs, Compressor was never particularly fast.
The number at the top of each green bar indicates how much faster the M1 MacBook Pro was than the Intel iMac.
CONUNDRUM 1: FILE SIZES
When testing, I made a point to set the bit rate to 10000 kpbs for each software. But, the compressed files were not the same size! They should be, but they weren’t.
What I discovered is that the software uses the value we set as a maximum value. It will use less if it can – and it always uses less. As this chart indicates, the actual data rate was both lower and varied significantly. Generally, higher bit rates yield better image quality. What concerns me about this is that, by determining the data rate independently of our setting, we lose the one major control we have over both file size and image quality.
NOTE: I don’t know any way to force any of these three software to use the bit rate that we enter.
TEST 2: ENCODING INTO HEVC
When it comes to HEVC Compressor was the fastest. However, both Compressor and Media Encoder showed significant speed improvements over running on Intel.
TEST 3: TRANSCODING INTO PRORES
New with Apple silicon is hardware acceleration for ProRes files. Both Compressor and AME seem to use this new hardware acceleration. In fact, Compressor improves almost 8X when compressing ProRes files. But, AME became seriously faster, too, especially for MXF files, which Compressor does not support.
Adobe Media encoder provides two versions of ProRes: QuickTime and MXF. As this chart indicates, I tested the speed of both.
CONUNDRUM 2: CPU LOADS COMPRESSING H.264
In the charts below, the two left-most cores in an M1 CPU are the “efficiency” cores. The rest are “performance” cores. What’s interesting to see is how each software uses the available cores differently. This reflects how the software was programmed and optimized.
The top panel for each software indicates how fast it is reading data from storage (Data read/sec). This, more than write speed, Data written/sec, should determine how fast the software can compress media. However, in all cases, this transfer speed is nowhere close to the maximum transfer rate the storage will support.
The bottom panel indicates how hard the 10 cores in the CPU are working; taller bars indicate greater CPU activity.
What I find interesting is that there is not a direct correlation between how hard the CPUs are working – or how many cores are active – to the speed of compressing a file. Compressor is generally the fastest of the three, yet uses the CPUs cores the least. (It may be that Compressor off-loads this work to the GPU. I didn’t measure that.)
Notice also that Media Encoder transferred data almost twice as fast as Compressor, but did not compress the file faster than Compressor.
CONUNDRUM #3: CPU LOADS FOR PRORES TRANSCODING
Here’s the same comparison between the software, except this time they are transcoding one ProRes file into a different flavor of ProRes. It is interesting to see the wide variation in data transfer rates.
NOTE: In all cases, the source file was stored on the internal SSD of the MacBook Pro or the iMac. The SSD in the MacBook Pro supports a blistering 5,500 MB/sec!! The iMac is nowhere near as fast. However, none of this software maxed out the speed of even the slower storage on the iMac. Storage bandwidth does not determine compression speed.
UPDATE – Feb. 5, 2022
To see how these results changed when using an i7 CPU, I re-ran these tests. I also re-ran these tests on the M1 MacBook Pro for the latest version of FFmpeg, which is optimized for Apple silicon.
NOTE: The captions in these charts refer to bold number at the top of the bars. These numbers are the same as the earlier charts and I did not repeat them. You will also find them in the table below each chart.
Compressor really struggled in all of the H.264 tests using an Intel CPU. It was handily beaten by both AME and ffWorks. However, the results change with the M1. Here, while AME was the fastest, Compressor showed the most improvement in speed.
The latest version of ffWorks/FFmpeg is marginally faster, but not as fast as either Compressor or AME.
HEVC compression is where things get way out of whack. AME only supports software encoding of 10-bit HEVC and its slow speed shows the advantage of hardware acceleration.
Again, ffWorks shows the classic speed improvement from i5 to i7 to M1, but version 3 was slower than version 2.
Compressor failed to compress the file at all on the Mac mini, which is a problem Intel systems have had in past tests. However, Compressor turned in the fastest times of the three software on the M1 MacBook Pro.
Note that this is the first time that ffWorks v3 showed a significant performance improvement over version 2.
The extreme slowness of AME when encoding ProRes using Intel chips actually highlights the hardware acceleration of ProRes encoding on both the M1 Pro and M1 Max CPUs. When it comes to ProRes, Compressor is the clear winner on both Intel and Apple CPUs.
One result that surprised me was that the i7 CPU did not consistently beat the i5. Most of the time, it didn’t. This may be due to the speed of the GPU in the Mac mini (it isn’t fast), or the smaller amount of RAM; I don’t have a clear reason why the Mac mini was so consistently slow. This highlights that compression performance relies on more than just the CPU, because the i7 CPU is inherently faster than an i5.
The new Apple silicon Macs compress media much faster than any prior Intel CPU. In fact, all the Intel-based software suffered badly in comparison to the compression speed of the M1-based MacBook Pro. You’ll see speed improvements regardless of which software you prefer to use. I am especially impressed with the speed improvements with Apple Compressor. For years, it has lagged in performance compared to virtually every other compression software I’ve tested it against. It is good to see it getting some engineering love.
If you are working with media, the speed bump in the new systems will save you a significant amount of time. And saving time is always a good thing.
Here are my detailed test results, in case you are interested.
NEW & Updated!
Edit smarter with Larry’s latest training, all available in our store.