M1 handbrake performance very disappointing...

[Damian83]

Hi, my gf just bought a m1 air, and i was more excited than she about this. I'm planning to shrink my whole collection of mkvs, however it takes ages on my imac 2019 (i5 3ghz) and i was pretty sure with an m1 i can almost half the required time. i mean, those tons of benchmarks speaks clear:

MacBook Air (Late 2020) vs iMac (27-inch Retina Early 2019) - Geekbench

Ive tested a mkv fragment and result its very disappointing. m1 its 25% slower than the i5... ive checked hanbrake's log in order to see if there was some different settings and everything its the same apart this:

x265 [info]: frame threads / pool features : 2 / wpp(17 rows) on i5
x265 [info]: frame threads / pool features : 3 / wpp(17 rows) on m1

does anyone have idea what it means? every in-app setting was of course the same (exported/imported settings just to be sure)

 

[zedsdead]

Try the video toolbox settings.

 

[Damian83]

Try the video toolbox settings.

well, no! the quality encoding its made via software (x265)

 

[TTYS0]

Expecting double the encoding speed with software x265 encoding from an M1 (four performance cores / four efficiency cores) compared to a six core (twelve logical) i5 is not a reasonable expectation. That it's only 25% slower is rather remarkable. There are multiple factors at play, not the least of which being that ffmpeg is heavily optimized for x86. On the upside, as the M1 core count increases, so will the performance.

 

[Damian83]

Expecting double the encoding speed with software x265 encoding from an M1 (four performance cores / four efficiency cores) compared to a six core (twelve logical) i5 is not a reasonable expectation. That it's only 25% slower is rather remarkable. There are multiple factors at play, not the least of which being that ffmpeg is heavily optimized for x86. On the upside, as the M1 core count increases, so will the performance.

ok maybe not double speed but certainly i dont excpected it was slower, considering in EVERY benchmark, it outperforms that i5. Now i'm losing fate in everything, considering i finally found a heavy use for a cpu, and realized that all those benchmarks are pointless as i tried just ONE app, that voids all of them...

 

[TTYS0]

Learning that benchmarks are useless is a valuable lesson.

 

[Damian83]

Learning that benchmarks are useless is a valuable lesson.

Ok but let's say i buy a car that outperforms my old car on lap times in every circuit tested, from an oval track to nurburgring. And by a high margin. I buy that car and realize that 0-100, max speed, and braking distance are all worse than my previous one. By a high maring too. It's phisically impossible. So it seems impossible also that i get that HB low performance while all benchmarks says the opposite.... Or maybe those benchamarks works like VW emission tests... Fortunately that MB is for my GF and its main purpose isnt to rip movies faster...

 

[lcubed]

Ok but let's say i buy a car that outperforms my old car on lap times in every circuit tested, from an oval track to nurburgring. And by a high margin. I buy that car and realize that 0-100, max speed, and braking distance are all worse than my previous one. By a high maring too. It's phisically impossible. So it seems impossible also that i get that HB low performance while all benchmarks says the opposite.... Or maybe those benchamarks works like VW emission tests... Fortunately that MB is for my GF and its main purpose isnt to rip movies faster...

let's pretend that car you bought was used in LA traffic

 

[Gnattu]

May I ask your handbrake version and the profiles using? Your experience is contradict to many people in this forum. We even have a user claimed that M1 is as fast as 4750G, and the 4750G is even faster than the i5 in your iMac.

 

[Juicy Box]

Hi, my gf just bought a m1 air, and i was more excited than she about this. I'm planning to shrink my whole collection of mkvs, however it takes ages on my imac 2019 (i5 3ghz) and i was pretty sure with an m1 i can almost half the required time.

In other threads, I posted my disappointment in the M1 (Mac Mini) with SW encoding on Handbrake versus my Late 2012 iMac with the 3rd gen i7.

Using the same source data, I tested Handbrake on multiple computers (Intel and M1), mostly Macs, with different levels of encoding.

The M1 is faster than my i7 iMac, but I was expecting more of a difference that what I got:

For quick encodes (H.264, Encoder Options Preset: Medium), the M1 (267 FPS) was 100% faster than the iMac (133 FPS).

For more difficult, longer encodes (H.265, Encoder Options Preset: Medium), the M1 (78 FPS) dropped to only 85% faster than the iMac (42 FPS).

For the hardest encode I tested (H.264, Encoder Options Preset: Placebo), the M1 (15 FPS) dropped to only 50% faster than the iMac (10 FPS).

I noticed that while the differences in encode times for Intels were pretty linear when changing the encode levels, the M1's performance dramatically decreased with increased encode difficultly.

i mean, those tons of benchmarks speaks clear:

I think the benchmarks are somewhat accurate, but it depends on what is being done in the real world.

If you take my results in testing, the M1 is pretty fast at the beginning of the encode, and holds the speed for a while (30 minutes or so), but after a while (30 minutes+), the average FPS start to drop. The longer you encode, the more it drops. The fan stays quiet the whole time.

Intels on the other hand, start off crazy fast, but quickly drop about 30 seconds to a minute into the encode. Unlike the M1, the FPS stay steady after the initial burst. The fans kick ramp up about 10 seconds into the encode, and stay on.


I suspect that your M1 results would be even worse since you are using the M1 MBA, and there are no fans.

Try encoding something short, something that only takes a few minutes and compare the two machines.

 

[doboy]

I get 270-280 FPS on my M1 Pro encoding 1080p movies using Video Toolbox H256 10-bit setting. However, the file size is larger using VT at comparable quality when compared to my i5 4 core Windows machine using software encoding. Software encoding is 10-13x slower so not worth the smaller file size for me

 

[Juicy Box]

I noticed that while the differences in encode times for Intels were pretty linear when changing the encode levels, the M1's performance dramatically decreased with increased encode difficultly.

but after a while (30 minutes+), the average FPS start to drop.

Using the data from the tests I mentioned in my early post, here are some comparisons between encode time and performance differences with the M1:

Encode Time / M1 Performance Increase Over Late 2012 iMac with 3rd gen i7
8 minutes, 43 seconds / 100% Increase
29 minutes, 58 seconds / 86% Increase
156 minutes, 48 seconds / 50% Increase

As you can see, the longer the encode the performance increase of the M1 gets smaller and smaller. Keep in mind this is with the same source data, I am just changing the encode settings.

Maybe I will do a few more tests with settings that would push the encode times over 24 hours, and see if the 3rd gen i7 could catch up to the M1, given enough time.

 

[Juicy Box]

I get 270-280 FPS on my M1 Pro encoding 1080p movies using Video Toolbox H256 10-bit setting. However, the file size is larger using VT at comparable quality when compared to my i5 4 core Windows machine using software encoding. Software encoding is 10-13x slower so not worth the smaller file size for me

The M1 HW encoding using Handbrake is very fast, but the file size is way too big for my needs.

It is hard to get an objective apples to apples comparison when it comes to quality of Handbrake's SW and HW encoding settings, but when I tried to get a similar quality encode Handbrake SW and HW encoding, the file size of the HW encode was a lot larger than the SW encode.

Software encoding is 10-13x slower so not worth the smaller file size for me

If time is an issue, you can change the Encoder Options Preset to "Ultrafast", you can get a lot faster FPS on Handbrake SW encoding, while still keeping the file size small.

I didn't do extensive tests with the Handbrake HW encoding due to the much larger file size. A few that I did and kept in my test data showed that the H.265 encoder on Ultrafast Preset took about twice as long as the H.265 Video Toolbox encoder at a (subjective) similar quality, but the SW encode was a little more than half the file size of the HW encode.

The HW encoding was still faster, but only .5x slower versus the 10-13 times slower you mention, and the file size was also almost twice the size of the SW encode.

This was with the M1, so your result might be different, but maybe give it a try on your M1 Pro.

 

[Ainze]

I found the benchmarks to be reasonably good for an estimate. Something like Handbrake is about as close to a synthetic benchmark as a real use gets. But I’m really not sure why you ever thought you’d encode in half the time. It says right there on the page you linked that the M1 multicore is only 34% faster, so you’d expect the encode to take at least 75% of the previous time.

As for actually going slower? Must be a software quirk mixing badly with the architecture, maybe in x265. I’m sure it will work out over time.

For reference, my M1 Mac Mini (geekbench 7434) replaced my iMac 2013 i7 4771 (geekbench 3557) and the M1 is indeed about twice as fast for my workload (Using x264 though).

 

[Larsvonhier]

If it´s only about shrinking the file sizes, you might also try the (commercial) tool "Optimage".
It does a remarkable job on pictures, photos, PDFs and even movie files.
There is a demo version for free to experiment with (limits usage per day, otherwise fully featured).
Some mkv´s of mine got >60% compression, others were not handled at all (depends on mkv container codec involved, it seems). Runs natively on M1 and is quite fast (far better than on my 24-core 3.4GHz Xeon MP5,1).

 

[Alex Cai]

Ok but let's say i buy a car that outperforms my old car on lap times in every circuit tested, from an oval track to nurburgring. And by a high margin. I buy that car and realize that 0-100, max speed, and braking distance are all worse than my previous one. By a high maring too. It's phisically impossible. So it seems impossible also that i get that HB low performance while all benchmarks says the opposite.... Or maybe those benchamarks works like VW emission tests... Fortunately that MB is for my GF and its main purpose isnt to rip movies faster...

For example, you have an Jeep and you bought a new racecar.
The racecar must be faster on a regular road, but if you drive in a rough and uneven surface, the Jeep will beat the racecar since the Jeep is suitable for uneven roads.
It is the same on M1
The app your using is not adapted to Apple silicon and have to run on Rosetta2, so what you can is wait a few years until the developer fixes the problem.

 

[eddie_ducking]

As @Jucy Box mentioned, finding settings in amongst the myriad of options Handbrake offers and then trying to decide which one provides the smallest file sizes and best quality viewing experience is hard, to say the least

I eventually settled on H.265 10-bit as my preferred encoder but then the challenge of finding "the best" quality/speed compromise begins. Also potentially not helped by hardware or software changes.

I've attached my two presets (not so much to share them, more it's easier than listing what settings they contain), but with Handbrake 1.4.2 on the M1 Mini (it was current when I started my project), I found software RF20 to be more than acceptable and also VTB CQ45. Both may be more than I could get away with, but the aim of the conversion project was to "save disk space", not "save as much disk space as I possibly could" and I wanted to be sure that the output wasn't going to disappoint me.

Software encoding was yielding 15-25fps, VTB 180-220fps. Software producing files that were 25%-33% of the original H.264, VTB 33% to 50% of the original. Yes, the VTB encodes were larger than the software, but are still less than half the size of the originals and in the few months it took to convert my collection using VTB (and reduced disk space usage by 55%) the software encodes would still be going on and in a few years would have saved a few more TBs but by the time the VTB encoding was completed, would have saved very little space ('cause very few files would have been converted)

Note: don't use VTB for cartoons, my settings generally make the output larger than the H.264 source. Software seems to be the only option for them.

Handbrake 1.5.1 skewed the VTB constantly quality settings and they are aren't comparable to 1.4.2. CQ45 now produces files 10-20% larger than with v1.4.2. The M1 Pro/Max/Ultra H.265 encode engine also looks like it's been enhanced over the M1's and my Studio Ultra produces smaller files for the same CQ setting as my Mini, so the process of finding an acceptable CQ values starts again ... think I might have narrowed it down to CQ37 or CQ38. The Ultra will convert @ over 600fps using VTB (though it needs 2 simultaneous encodes, one on its own is around 310fps). Difficult to ignore the time savings but presently I'm only using software encodes, it's quick enough on the Ultra with that and the collection has been completed (though I may revisit bits and re-do with software, time allowing)

If software is the only way you see going forwards (though I'd strongly recommend evaluating VTB yourself for a mass conversion), try the nightly build of Handbrake. They've started to implement Apple Silicon optimisations on the software encoders and it looks like it's about 10% quicker because of it.

 

[Diskutant]

well, no! the quality encoding its made via software (x265)

there seems to be a misunderstanding.
With video toolbox settings the x265 encoding will be much faster. It's still x265, and still the same quality.

 

[k27]

there seems to be a misunderstanding.
With video toolbox settings the x265 encoding will be much faster. It's still x265, and still the same quality.

x265 is a software encoder for the H.265 codec. VideoToolbox is a hardware encoder for H.265, which is a lot worse (but much faster).

I converted about 8 minutes of 4K video to H.265 with x265 in Handbrake a few days ago (Mac mini M1). The file size is about 1.7 GB. The same video over VT in Handbrake to H.265 has around 8GB (!!!!). Encoding in software via x265 took maybe 2 hours. VideoToolbox encoding was significantly faster.
These are not exact values. But that's how I remember it.

All the tests only look at speed but not quality in relation to file size. And in this regard VideoToolbox is clearly worse than very good software encoding like x264 and x265.

It may be that Handbrake can't get the maximum out of VT. For ffmpeg I think there is a corresponding patch that is not yet in Handbrake (?). But even then the VideoToolbox does not come close to software encoding.

I care more about quality and file size than speed. So I don't use VideoToolbox for the few family movies I encode.

 

[Damian83]

May I ask your handbrake version and the profiles using? Your experience is contradict to many people in this forum. We even have a user claimed that M1 is as fast as 4750G, and the 4750G is even faster than the i5 in your iMac.

I'm using last version (1.5.1)
I'll sent an attachment with my exported settings later but basically its 4k>1080p, no filters, x265 10-bit, qc14, slow, audio passthrough

In other threads, I posted my disappointment in the M1 (Mac Mini) with SW encoding on Handbrake versus my Late 2012 iMac with the 3rd gen i7.

Using the same source data, I tested Handbrake on multiple computers (Intel and M1), mostly Macs, with different levels of encoding.

The M1 is faster than my i7 iMac, but I was expecting more of a difference that what I got:
For quick encodes (H.264, Encoder Options Preset: Medium), the M1 (267 FPS) was 100% faster than the iMac (133 FPS).
For more difficult, longer encodes (H.265, Encoder Options Preset: Medium), the M1 (78 FPS) dropped to only 85% faster than the iMac (42 FPS).

For the hardest encode I tested (H.264, Encoder Options Preset: Placebo), the M1 (15 FPS) dropped to only 50% faster than the iMac (10 FPS).

I noticed that while the differences in encode times for Intels were pretty linear when changing the encode levels, the M1's performance dramatically decreased with increased encode difficultly.



I think the benchmarks are somewhat accurate, but it depends on what is being done in the real world.

If you take my results in testing, the M1 is pretty fast at the beginning of the encode, and holds the speed for a while (30 minutes or so), but after a while (30 minutes+), the average FPS start to drop. The longer you encode, the more it drops. The fan stays quiet the whole time.

Intels on the other hand, start off crazy fast, but quickly drop about 30 seconds to a minute into the encode. Unlike the M1, the FPS stay steady after the initial burst. The fans kick ramp up about 10 seconds into the encode, and stay on.


I suspect that your M1 results would be even worse since you are using the M1 MBA, and there are no fans.

Try encoding something short, something that only takes a few minutes and compare the two machines.

I've tested a 2gb movie fragment, that converted in about 10m. I've clicked "start" on both systems at the same time, and i've noticed i5 was faster IMMEDIATELY before its fans even activated. Of course both systems was "cool" before testing

 

[Damian83]

Here are my settings i use. Basically are:
4k>1080p
no filters
x265 10-bit
qc 14
slow
audio passthrough

With these settings i can shrink a 80gb 4k mkv to around 8-10gb maintaining HDR. I can't tell the difference from the original file on a 75" at 4m viewing distance on a shield tv with AI upscaling. I'll also upload the activity logs of the 2 tests. Comparing them, apart from instruction sets, the only difference its the string "x265 [info]: frame threads / pool features". Maybe someone can clarify this. Thanks

 

[LeadingHeat]

Doesn't VideoToolbox support .265 now? Why wouldn't you use it then?

 

[Damian83]

Doesn't VideoToolbox support .265 now? Why wouldn't you use it then?

read above. basically videotoolbox sucks

 

[doboy]

x265 is a software encoder for the H.265 codec. VideoToolbox is a hardware encoder for H.265, which is a lot worse (but much faster).

I converted about 8 minutes of 4K video to H.265 with x265 in Handbrake a few days ago (Mac mini M1). The file size is about 1.7 GB. The same video over VT in Handbrake to H.265 has around 8GB (!!!!). Encoding in software via x265 took maybe 2 hours. VideoToolbox encoding was significantly faster.
These are not exact values. But that's how I remember it.

All the tests only look at speed but not quality in relation to file size. And in this regard VideoToolbox is clearly worse than very good software encoding like x264 and x265.

It may be that Handbrake can't get the maximum out of VT. For ffmpeg I think there is a corresponding patch that is not yet in Handbrake (?). But even then the VideoToolbox does not come close to software encoding.

I care more about quality and file size than speed. So I don't use VideoToolbox for the few family movies I encode.

You could've got the file size down if you played around with CQ setting for VT so the file size comparison in your test is really not informative. When I did my side by side, I found that CQ 45 10-bit VT was comparable to RF21 and file size was 1.5-2x bigger for VT.

 

[eddie_ducking]

Here are my settings i use. Basically are:
4k>1080p
no filters
x265 10-bit
qc 14
slow
audio passthrough

on a different note, both your preset and your logs show that you're not doing audio passthrough...

[23:38:58] * audio track 1
[23:38:58] + name: Surround 7.1
[23:38:58] + decoder: italiano (TrueHD) (7.1 ch) (track 1, id 0x1)
[23:38:58] + samplerate: 48000 Hz
[23:38:58] + mixdown: Stereo
[23:38:58] + encoder: AAC (Apple AudioToolbox)
[23:38:58] + bitrate: 160 kbps, samplerate: 48000 Hz

That alone will account for 3-4GB of savings in the exported file, more so if there are additional audio tracks in the 80GB file that are being completely stripped out (which there probably are)