[ 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.
12 Responses to Just How Much Faster is an M1 MacBook Pro When Compressing Video? [u]
Hello! Thanks for all the great content!! My m1 max is arriving this week and I am trying to decide if i should start editing off externall ssd drives or continue to ise my slower OWC RAID as before. Seems like people are moving to faster, externall SSD rather than spinning storage for FCPx and even Lightroom.
Like everything in tech, the answer is: “It depends.”
SSDs have the potential to be far faster than spinning media, but they don’t hold as much and cost far more. If your storage needs are small, say less than a couple of terabytes, SSDs are the best option for any kind of computer work. However, the answer gets trickier as the amount of media you are storing increases. I have about 100 TB of storage across multiple RAIDs – all of which use spinning media. To create that much storage from SSDs would break the bank.
For longer-term storage, spinning media is the most cost effective, yet still fast enough, choice.
Another key factor is the media you are editing. SD and HD don’t need the speed of SSDs, though they will benefit from it, your editing won’t be slowed down because of it. 4K – especially effects-heavy rendering will benefit from SSDs, but, again, spinning media will still work. As soon as frame sizes get over 4K, or you are doing multicam editing, SSDs are the clear winner.
Comparing a M1 Macbook pro to an i5 Imac makes little sense in my opinion. At least use a 6 core i7 or i9 for the test.
I totally agree. If I owned one I would have used it.
Hi Larry, glad to hear about your experiences with the M1 MacBook Pro. I have one on order, although it’s still about 8 weeks out. Was the issue with your dock specific to the brand and type of dock or does it seem to be a universal problem? I have two OWC Thunderbolt 3 Docks that I use to move my current MacBook Pro back and forth from work to home. I’ve been very happy with them and would hate to have to replace them. I’ll reach out to OWC to verify compatibility. If you find a good one, please let us know!
I think your docks should be fine. What I need is a good Thunderbolt dock that provides at least three USB 3.0 ports. The dock I have (Insignia, which is the Best Buy store brand) connects via USB and is woefully underpowered. Your docks connect via Thunderbolt so they should have the power and speed necessary.
Thanks for an informative article! I’m using a M1 mini and have been happy with the increase in performance with it. I’m looking forward to an upgraded M1 mini in the hopefully not to distant future.
In you’re reply to Patrick, you state that for longer-term storage spinning media is more cost effective. This reminded me that one thing I’ve never heard of is are there any issues with using SSD media or even thumb drives for long term storage? As the hard disk capacities have increased, their susceptibility to self-erasure over time while sitting on a shelf has also increased. I’ve read about this problem with hard drive multiple times and have experienced it as well. But I don’t recall ever hearing any claims about what happens with an SSD or thumb drive that sits on a shelf unused for an extended period of time.
While even USB 3 thumb drives aren’t all that fast, if they won’t get currupted sitting on a shelf like a hard drive or LTO tape cartridge. it they might be a better to store critical files.
Please keep up the good work!
The long-term storage capability of SSD media is something I’ve chatted with engineers about over the years. The short answer is that we don’t know. SSDs were designed for performance, not storage longevity.
I would be very reluctant to use SSDs or thumb drives for archives. It’s not what they were designed for.
Interesting results indeed, Larry. Thanks for posting.
Let me share some early impressions of my recent migration from an old MacPro to the MacBook Pro M1Max.
I have a small hub which is getting me by until a backordered Sonnet dock arrives. The hub allows me to hook up some peripherals such as my current trackball and keyboard which I prefer to using over a laptop keyboard. Works fine.
For editing media I got an OWC Thunderblade 4TB external SSD. It’s fine but quite honestly not as fast as I had hoped it would be. I’m using that for all my editing media at the moment.
The wonderful thing about this new setup is the silence. No fans anywhere. No spinning drives. That alone is worth the change. The Thunderblade required a few permissions changes to install the SoftRAID software but it went fine after following along with the directions,
RE compression, I find Handbrake takes at least twice as long to compress ProRes to mp4. I’m assigning that task to my older MacBook Pro until things change with the new one. I will experiment with Compressor after reading about your results.
One of the best surprises is that my old (2005) 30-inch Apple Cinema Display is working wonderfully with the new MacBook Pro.. The key was a Club 3D CAC-1510-A USB C to Dual Link DVI-D Adapter. Reasonably cheap ($40) and works.
Awaiting an audio interface, but otherwise up and functional with minimal disruption.
Did I mention I love the silence?
This is a very helpful report – thanks for sharing what you learned. I agree, while I LOVE! all the new ports on the MacBook Pro, I still need more ports. While USB-A docks are inexpensive, I think, for reliability and performance a Thunderbolt or USB-C dock is the best option. The key is to be sure to get powered USB-A ports because lots of our peripherals are expecting power via the USB connection.
Intersting comparison Larry.
A question about ffWorks and FFmpeg:
Did you use the software or hardware version for the H.264 / HEVC / ProRes codecs?
ffWorks is just a front-end to FFmpeg, it does no compression on its own.
With ffMPEG, I used the default settings. Given the level of control it supports at the Terminal level, I suspect you could toggle between software and hardware encoding, but those choices are buried deeply into the interface.