M1 Max and Handbrake = kind of slow?

[aUsern@me]

Just got back from the Apple Store where they kindly let me install Handbrake and encode a file on a Studio M1 Max. Per Handbrake's benchmarking suggestions, I used the "Big Buck Bunny 1080p30" file for a software encode using "Fast 1080p30" and H.265.

While standing there for a few minutes, it seemed kind of slow. I took a screenshot of the results and went back home to test the same file on my four year-old 9700K Hackintosh.

M1 Max, 32 GB Studio, macOS 12.3.1, Handbrake 1.5.1
It took 6:17 to finish with an average speed of 50.76 FPS.
(I did not think to see how many GPU cores, but as the test was a software encode, it shouldn't matter much)

9700K @ 5 GHz, 32 GB, macOS 10.14.6, Handbrake 1.5.1
It took 4:38 to finish with an average speed of 68.66 FPS.

During the test at the Apple Store, I had Activity Monitor open the entire time and it looks like Handbrake was using ≈ 830-50% CPU time during the encode.

This leads me to a couple of questions. Is there a known issue with Handbrake and the M1 Max? I searched and found some supposed issues from when the M1 (not Max or Pro) was first introduced, but I can't find a definitive answer. Could someone with an M1 Max Studio repeat the same test? The Apple Store was really busy and it didn't seem right to hog the machine for another six minutes as I'd already been using it for 15.

At some point relatively soon, I need to go "legit" as I can't stay on Mojave indefinitely. But I was expecting the M1 Max to be way faster. I rarely, if ever, use Handbrake, but it's similar enough to much of my workflow (FFmpeg software video encodes) that the results are relevant. My next step would probably be to buy one and return it within 14 days if it weren't significantly faster that my current set up. However, that 14 day return window is already going to be kind of tight as I'd be testing a lot of new software as I'd be dumping lots of legacy applications. It'd be nice to have the "Is it faster?" question already answered.

If anyone with an M1 Max Studio has a spare six minutes (or hopefully much less) I'd really appreciate it.

 

[StudioMacs]

The consensus seems to be that Handbrake is not fully optimized for the newer chips, but it can be tweaked by using VideoToolbox H265 https://www.reddit.com/r/apple/comments/thgyvk

 

[lcubed]

somethings not quite right in handbrake:

further down in the same reddit:
*** Final Update *** After switching to "VideoToolbox H265" I'm getting 70~75 FPS in 4K source and destination. I'm extremely happy and the Studio is staying!

Thank you again ToAllTheLost for this and that was the solution. I jumped up to 28 FPS on 1080p videos on the M1 (2020) 13" as well.

Time to sell off the Intel Mac mini and M1 Mac mini that was my media server now that I have an all in one solution. I can justify the $5,400 for it now I'm getting the performance. No regrets anymore.

*** UPDATE *** Quality went down with the output on 4K.

TLDR: Setting in Handbrake caused slowness, switch ^ and now extremely happy. 1080p = went from 13 FPS to 28 on the 2020 MBP

 

[aUsern@me]

I wonder what the technical issue is? More importantly, is it something being actively addressed?

VideoToolBox is nifty tech and really fast, but it's nothing I can use as it's not at all configurable. It would seem like an M1 Max should excel for this kind of multi-core processing task and yet, it doesn't.

 

[Mr.Blacky]

I wonder what the technical issue is? More importantly, is it something being actively addressed?

VideoToolBox is nifty tech and really fast, but it's nothing I can use as it's not at all configurable. It would seem like an M1 Max should excel for this kind of multi-core processing task and yet, it doesn't.

In what way is it not configurable?

 

[galad]

The x265 encoder is not as optimized as possible on ARM. And it doesn't even scale as well as x264, so throwing more cores at it doesn't really help (it doesn't help even on Intel and AMD cpu), so if you have 20 cores you could try to encode two files in parallel.

Anyway, there are been some improvements, please try a HandBrake snapshot, and let us know how much it improves the x265 encoding speed: https://github.com/HandBrake/HandBrake-snapshots

VideoToolbox Hardware encoder is certainly faster, but quality will not be as good as x265 as you found out.

 

[aUsern@me]

Is the relative slowness still NEON related?
https://www.reddit.com/r/ffmpeg/comments/s3snv6
How can I find out which version of HandBrake include optimized NEON builds of FFmpeg?

 

[galad]

Not really. Neon is not a compiler flag that needs to be enabled or not. There are hundreds of functions that can be made faster by using Neon, but the code needs to be written by hand. And many others that can be made faster even without using Neon.

That reddit post probably referred to the initial x265 optimizations contributed by Apple to HandBrake, which have been shipped with every HandBrake M1 version.

The HandBrake snapshot includes a bunch of additional Neon optimizations in FFmpeg and x265, and better threads usage in x265.

 

[now i see it]

Isn’t handbrake primarily used for illegally ripping DVD’s?
Doesn’t seem like that was what the Mac Studio was designed to do.
The whole Mac Studio presentation showed “professionals” in studios working on projects. Not guys ripping DVDs with handbrake.

 

[galad]

Not really. I use it to encode the ProRes files exported from Final Cut Pro.

 

[HazardousT]

Isn’t handbrake primarily used for illegally ripping DVD’s?
Doesn’t seem like that was what the Mac Studio was designed to do.
The whole Mac Studio presentation showed “professionals” in studios working on projects. Not guys ripping DVDs with handbrake.

Not everyone with DVD's is illegally ripping them. I still have hundreds of DVD's in my collection and many of them are not available in digital format nor ever will be. It's a very useful tool

 

[Romain_H]

Isn’t handbrake primarily used for illegally ripping DVD’s?

No. Out of the boxx it can‘t even do that due to lack of decss

 

[aUsern@me]

Isn’t handbrake primarily used for illegally ripping DVD’s?
Doesn’t seem like that was what the Mac Studio was designed to do.
The whole Mac Studio presentation showed “professionals” in studios working on projects. Not guys ripping DVDs with handbrake.

In my specific case, it's nothing more than easily accessible benchmark used to compare the underlying libraries' performance. That said, I don't think Handbrake RIPs DVDs.

Speaking of an "easily accessible benchmark," I don't suppose anyone with the a Studio M1 Max has had time to reproduce my test results? Perferably with a Handbrake Snapshot per galad's recommendation.

 

[eddie_ducking]

In my specific case, it's nothing more than easily accessible benchmark used to compare the underlying libraries' performance. That said, I don't think Handbrake RIPs DVDs.

Speaking of an "easily accessible benchmark," I don't suppose anyone with the a Studio M1 Max has had time to reproduce my test results? Perferably with a Handbrake Snapshot per galad's recommendation.

Agreed .. and yes, I did, but being a "muppet", managed to delete what I was aiming to post prior to doing so (though now @galad has mentioned the snapshot, I'll post both). Though I've got an Ultra rather than an Max, say if you're not interested before I do it all.

 

[aUsern@me]

The Ultra is out of my price range, but I think the results would still be informative. If you've got the time, I'd definitely appreciate it. I'm very curious if the snapshot build has any advantage over the current 1.5.1 build.

 

[BobSc]

Isn’t handbrake primarily used for illegally ripping DVD’s?
Doesn’t seem like that was what the Mac Studio was designed to do.

NO. Handbrake cannot rip a DVD. It cannot decrypt. Rather than telling you what it does, why don't you go to it's website and spend a moment of time learning about a program before you accuse it of illegal activities.

As far as what the Mac Studio was designed to do, well, it was designed to be a computer. It can be used for legal and illegal purposes. How do you propose to regulate that?

 

[darthaddie]

Whilst not exactly the benchmark mentioned here I have found handbrake to be incredibly slow with my 4k prores 10 bit to H.265/264 conversions. Even when using videotoolbox.

I am getting a max of 60-70fps whereas with the same settings Adobe media encoder gets over 120 and Apple Compressor does the same. Like a 23 min video would easily convert in 7-8 mins in both. Whereas it took way longer in Handbrake.

I own compressor so that’s what I have been using for conversions.

I noticed that the problem with Handbrake is it doesn’t use the M1 media encorders or the GPU. With videotoolbox maybe some GPU. But that’s it. I have read on their forums that Handbrake runs better on 1080p and lower res footage but does poorly on 4k.

 

[eddie_ducking]

Source: bbb_sunflower_1080p_30fps_normal.mp4
Preset: "Fast 1080p30"
Using Mac Studio Ultra 48GPU/64Gb RAM

Handbrake v1.5.1
Encoder: h.265

Handbrake v1.5.1
Encoder: h.265 10bit

Handbrake v1.5.1
Encoder: VideoToolbox h.265

Handbrake v1.5.1
Encoder: VideoToolbox h.265 10bit

Handbrake v20220421200138-1e2404d0c-master
Encoder: h.265

Handbrake v20220421200138-1e2404d0c-master
Encoder: h.265 10bit

Handbrake v20220421200138-1e2404d0c-master
Encoder: VideoToolbox h.265

Handbrake v20220421200138-1e2404d0c-master
Encoder: VideoToolbox h.265 10bit

CPU usage for the software encodes was around 1200% for v1.5.1. For the snapshot build, around 1400%. To make full use of the CPU with Handbrake, two encodes need to be run in parallel.

 

[aUsern@me]

Much thanks for taking a substantial amount of time to run all those tests.

There does seem to be a noticeable boost in the snapshot build.
79.84 vs 71.44 fps for the 8 bit software H.265
12% faster ain't earth shattering, but it's significant.

Possibly, likely at best, the Max would also receive the 12% bump using the snapshot build, which would put it at 57 fps - which is still not where I'd want it. Too bad I don't have the money for the Ultra. I'm having a hard time justifying $3K for a Max machine that won't be faster for my most demanding tasks.

There'd be other benefits to having a Studio Max vs my hackintosh, but raw speed doesn't appear to be one of them. I guess my next step is to go back to the Apple store and run the same test with the snapshot build. But even your Ultra, running the snapshot, is "only" 16% faster than my 9700K. Even if the Max were capable of that same kind of Ultra speed, I'd be disappointed. In my imagination, I was expecting the Max to just trounce my current set up.

Likely, if my workflow were more GPU dependent, I'd be more impressed. Perhaps I need to start investigating GPU dependent video encoding.

Thank you again.

 

[kfscoll]

This is a timely discussion for me since I’m currently reconverting my entire Blu-ray / HD DVD library (about 1400 discs) to H.265 MKV files that I place on my NAS and stream via Plex. Anyway, while I wait for my Studio Ultra to arrive, I’m using a 2013 12-core Mac Pro and a brand-new HP Pavilion Aero laptop (!!) with an 8-core Ryzen 7 5800U, both running Handbrake 1.5.1, to do the H.265 conversions. I do software x265 encodes using mostly default settings and I pass through all audio when I convert my rips. I’d say my Mac Pro averages in the low-20fps range and the laptop averages in the low-30fps range while encoding. I was hoping my Studio would be around 3x faster in this use-case, and if I really see almost 80fps with my Ultra, I’ll be thrilled.

 

[eddie_ducking]

Much thanks for taking a substantial amount of time to run all those tests.

There does seem to be a noticeable boost in the snapshot build.
79.84 vs 71.44 fps for the 8 bit software H.265
12% faster ain't earth shattering, but it's significant.

Possibly, likely at best, the Max would also receive the 12% bump using the snapshot build, which would put it at 57 fps - which is still not where I'd want it. Too bad I don't have the money for the Ultra. I'm having a hard time justifying $3K for a Max machine that won't be faster for my most demanding tasks.

There'd be other benefits to having a Studio Max vs my hackintosh, but raw speed doesn't appear to be one of them. I guess my next step is to go back to the Apple store and run the same test with the snapshot build. But even your Ultra, running the snapshot, is "only" 16% faster than my 9700K. Even if the Max were capable of that same kind of Ultra speed, I'd be disappointed. In my imagination, I was expecting the Max to just trounce my current set up.

Likely, if my workflow were more GPU dependent, I'd be more impressed. Perhaps I need to start investigating GPU dependent video encoding.

Thank you again.

This is a timely discussion for me since I’m currently reconverting my entire Blu-ray / HD DVD library (about 1400 discs) to H.265 MKV files that I place on my NAS and stream via Plex. Anyway, while I wait for my Studio Ultra to arrive, I’m using a 2013 12-core Mac Pro and a brand-new HP Pavilion Aero laptop (!!) with an 8-core Ryzen 7 5800U, both running Handbrake 1.5.1, to do the H.265 conversions. I do software x265 encodes using mostly default settings and I pass through all audio when I convert my rips. I’d say my Mac Pro averages in the low-20fps range and the laptop averages in the low-30fps range while encoding. I was hoping my Studio would be around 3x faster in this use-case, and if I really see almost 80fps with my Ultra, I’ll be thrilled.

Pleasure @aUsern@me

I've got 3 more for you showing the increased speed for running 2 parallel encodes, again all based on the "Fast 1080p30" with just the encoder being changed.

Handbrake v20220421200138-1e2404d0c-master
Encoder: h.265

Handbrake v20220421200138-1e2404d0c-master
Encoder: h.265 10bit

Handbrake v20220421200138-1e2404d0c-master
Encoder: VideoToolbox h.265 10bit

I've included the H.265 10-bit, simply because I much prefer its output vs the 8-bit, it's slightly slower but IMHO worth the extra time.

I've also included the VTB H.265 10-bit times simply because the enhanced media engine in the Max/Ultra is worth investigating. VTB now provides (on Apple Silicon) a constant quality control capability, on both your bits of kit, your only control is the bitrate (I think). While the VTB CQ setting has no relation to the software RF setting, the two are not transferable, it can be tuned to provide very good output at the cost of a slight increase in file size (though the output size is still generally way less than half the H.264 source). The Apple Silicon version of FFmpeg also supports the VTB CQ setting.

610fps isn't something to be sniffed at at the cost of slightly increased disk usage. Don't take the size part of the BBB test encodes as realistic, it appears the VTB H.265 10-bit encoder doesn't do cartoons very well... it's fine with live action but rarely compresses cartoons at all well (no idea why not, maybe a lower CQ setting could be used, I just simply use software H.265 10-bit for them), but the FPS is the same ilk for both live action and cartoon. VTB on my old Mac Pro was fast but the output was pants and not worth the effort. On the Studio, that's all changed, it's still fast but reliable good quality output can now also be had with a decent CQ setting.

 

[PianoPro]

This is a timely discussion for me since I’m currently reconverting my entire Blu-ray / HD DVD library (about 1400 discs) to H.265 MKV files that I place on my NAS and stream via Plex.

I'm curious. You are taking a quality hit from H.264 and VC-1 just to save disk space?

 

[aUsern@me]

610fps isn't something to be sniffed at at the cost of slightly increased disk usage.

The performance of VTB is incredible. But last time I investigated (a couple years ago), it wasn't just slightly increased disk usage that was the issue - the quality of the file was really bad. At similar files sizes to a software encode, there was very noticeable pixelation, texture loss and blurring. And this wasn't me pixel peeping on still frames. While casually watching the resulting videos it was very obvious which was a software encode and which was VideoToolBox.

Increasing the quality of the VTB encode produced better results, but then the files sizes started to approach H.264 sizes - in which case, what's the point?

Off the top of my head, to produce a "good" 1 hour encode at 8-bit, 1920x1080 at 23.976 fps
H.264 = 1000 MB
Software H.265 = 600 MB (≈2.5 Mbps)
VTB H.265 = 800 MB
Obviously, those sizes are file dependent, but as a general observation they held true.

Like I mentioned, this was all a while back, so perhaps it's time for me to dive into it again. But I remember being very disappointed.

 

[eddie_ducking]

The performance of VTB is incredible. But last time I investigated (a couple years ago), it wasn't just slightly increased disk usage that was the issue - the quality of the file was really bad. At similar files sizes to a software encode, there was very noticeable pixelation, texture loss and blurring. And this wasn't me pixel peeping on still frames. While casually watching the resulting videos it was very obvious which was a software encode and which was VideoToolBox.

Increasing the quality of the VTB encode produced better results, but then the files sizes started to approach H.264 sizes - in which case, what's the point?

Off the top of my head, to produce a "good" 1 hour encode at 8-bit, 1920x1080 at 23.976 fps
H.264 = 1000 MB
Software H.265 = 600 MB (≈2.5 Mbps)
VTB H.265 = 800 MB
Obviously, those sizes are file dependent, but as a general observation they held true.

Like I mentioned, this was all a while back, so perhaps it's time for me to dive into it again. But I remember being very disappointed.

If my rudimentary understanding of VTB is correct, it's nothing more than (for want of a better phrase) a wrapper API for easy(er) access to any underlying hardware encoders detected on the machine. Be it something on the graphics card, (I think) Intel QuickSync in the CPU or in later Macs with the T2 chip the encoder it contains. With Apple Silicon machines, it uses their media encoders. The quality of the output is dictated by the quality of hardware encoder being used.

From my rather limited experience with hardware encoders in the past, I agree, I've never found them much cop, but the ones in the M1 & M1 Max do seem to have moved things on somewhat and now with the constant quality capability (which is only available on Apple Silicon), you can encode using it without having to worry about guessing an average bitrate that should provide reliable output (assuming the CQ value isn't set too low)

I'm not really concerned about the actual size of my encodes, more I'm looking for an acceptable % decrease from the H.264 originals. With VTB H.265 10bit, I'm getting between 33% and 50% of the original, with software H.265 10bit, between 25% and 40%. Generally, the VTB encode is around 25% to 30% larger than my software ones, but with the CQ and RF quality values having no correlation, I've probably gone a bit OTT on the VTB CQ value and part of that size increase is down to the slightly relatively lower quality setting on the software encodes.

With your Hackintosh, I wouldn't bother re-investigating VTB, you've still got the same hardware encoders from the last time you did and I don't think the API itself has changed enough for your existing results to be overturned.

However, if you do get a Studio (or maybe as part of your testing in the Apple Store) give it a go and maybe you'll be pleasantly surprised. Though it can take a bit of time to find a CQ value that's right for your viewing and filesize requirements (especially if you're trying to get the smallest files you can) and unlike the RF value, it might need tweaking between hardware platforms. The M1 Max/Ultra encoder seems to produce around 10% more efficient files than the one in the M1 Mini. My rough percentages above were done on M1 Mini VTB encodes, I'm using software on the Ultra, it's too damn quick to keep the thing fed when using VTB .

 

[PianoPro]

I'm really curious, what is the application for re-encoding H.264 files to H.265 with the subsequent loss of quality? Is it just to reduce disc storage requirements for personal use?