I first wrote about this for an Inside Tip. (Click for free registration.)
As I was preparing last week’s webinar on media compression in Apple Compressor (link) I learned the following:
The new M1 chip from Apple (part of the three new Macs launched last week) can accelerate encoding of H.264, 8-bit HEVC, and 10-bit HEVC using hardware. This vastly speeds compression of these codecs.
NOTE: HDR media requires using a 10-bit codec, which is why compressing 10-bit HEVC quickly is important.
To enable hardware acceleration, be sure to select Faster for the Encoding type in the Video Inspector. Setting the Encoder type to Slower performs compression using software, which is much, much, much slower.
As well, recent Intel-based Mac computers can use the T2 chip to hardware accelerate 8-bit HEVC and 10-bit HEVC encoding. Again, the Faster Encoding type option should be selected.
NOTE: On another note, Multi-pass also switches to software-based encoding. In the past, we would do this to improve image quality. Given the speed and quality of today’s hardware-accelerated compression, there are very few reasons to use the Multi-pass option today.
I should note that you can’t add these chips to older Macs, so these are not upgrade options. However, as you plan your next purchase, looking for a system with at least a T2 chip will make media compression MUCH faster.
Because my current production computers do not have either a T2 or M1 chip, I’m holding off doing any more compression speed tests until I can get a newer system.
8 Responses to Apple’s New M1 Chip Improves Video Compression Speeds
So where is this “slower = software, faster = hardware” paradigm documented?
Ben:
I’ve documented these differences many times in my compression speed tests:
https://larryjordan.com/articles/video-compression-speed-test-imac-vs-mac-mini/
As well, Apple has discussed this in their Help files.
However, this is very easy for your to test yourself using Adobe Media Encoder, Apple Compressor, or the media compression software of your choice.
Compress a file using 1-pass compression. Time how long it takes. Do the same thing with 2-pass (multiples in Compressor). Time how long it takes. The difference is striking – 10X – 30X longer.
Larry
I can’t thank you enough for outlining exactly how to get the computer to render these HEVC files so much faster. I was struggling to upload HDR files to YouTube as it seems to require a 10-bit file, but the only way to do that through Final Cut Pro X (as far as I could tell) was through their HEVC process that absolutely crawled. I stumbled across your site after searching for explanations as to why the HEVC conversion process was so slow despite running on a 2019 Macbook Pro 16, which I knew was supposed to have some sort of hardware encoder for HEVC built-in. After setting up a custom profile on Compressor to utilize these settings, I now get this export done about 95% faster than the previous method, it’s amazing. Thanks again for posting these details!
Jeremy:
Happy to help.
Yup, hardware acceleration makes a big, BIG difference!
Larry
Is it me or did Apple this without any logic at all?
Why isn’t it possible to render a slower (or better: higher quality and/or 2-pass) with M1-power?
Nyfal:
You assume that 2-pass is higher quality simply because it is labeled “High Quality.” I’ve compared the two and they are virtually indistinguishable. In fact, using Motion and blend modes you can compare the pixels of both versions and they are, to all intents and purposes, the same.
2-pass existed before hardware-based encoding appeared in Intel chips a few years ago. Now, there’s no reason to use 2-pass software for any work being posted to the web.
Larry
Well, with hardware encoding (like M1) you are losing quality and are getting bigger file sizes.
https://developer.apple.com/forums/thread/678210
https://forum.handbrake.fr/viewtopic.php?p=193596#p193596
https://forums.macrumors.com/threads/mac-mini-m1-h-265-encoding.2269815/?post=29347040#post-29347040
Peter:
Thanks for these links and your comments. I agree, hardware encoding should not look significantly worse than software encoding.
Larry