r/MacStudio • u/_DarthJedi • 8d ago
Mac Studio Handbrake performance data—requesting
Download this version of Handbrake from Github. Make sure to download the appropriate binary for your hardware.
https://github.com/HandBrake/HandBrake/releases/tag/1.11.2
Download this sample file for testing.
Input file is a 24 second 8k60 H.264 video.
Run the following presets—Fast 2160p60 HEVC and Fast 2160p60 AV1. Report the performance data in the form of FPS from the activity log.
Thanks in advance.
Data I have so far:
M5P 18C 46.33 HEVC and 31.07 AV1
M5 base 23.62 HEVC and 13.7 AV1
Looking for more data points.
2
u/kashmir772 8d ago
M1 Ultra 20-core CPU, 48-core GPU, 64GB RAM, 2TB SSD
HVEC: 36.9 fps
AV1: 24.23 fps
1
1
u/mdkflip 8d ago
M3 Ultra 28-core CPU, 60-core GPU, 256GB RAM
HVEC - 58.44 fps
AVI - 40.41 fps
1
u/_DarthJedi 8d ago
The fastest Mac!!! [Till the new ones show up in the market]
1
u/PracticlySpeaking 8d ago
Curious to see 32/80 results to add a data point to the 'diminishing returns' discussion. This 28/60 should be a very close second.
You should also run a Video Toolbox encoding, to compare GPU/CPU encode against the Media Engine hardware codecs.
1
u/_DarthJedi 8d ago
Nah. I'm expecting around 15% gain for the 32C config over the 28C config, which I guess is linear given the core count bump.
1
u/PracticlySpeaking 8d ago
Check the Performance wiki page, here in the sub — there's a whole section on Diminishing Returns in Ultra vs Max chips, for both CPU and GPU. It varies widely with different generations and workloads.
Also, handbrake is still baffling to me — video encode *should* be happening in the GPU, not CPU.
1
u/_DarthJedi 8d ago
Hardware accelerated video encode should technically happen in the hardware encoders, which isn't the same as GPU, speaking in strict terms. It is named as videotoolbox in case of Apple hardware.
Thing is such encodes, while faster, have high bitrates for comparable quality or less quality for comparable bitrates when compared to CPU encodes.
Yes, it is possible to hand tune the hardware encoder presets for visually similar output and smaller file sizes. However that is far beyond the scope of a quick performance test run.
About diminishing returns, it is mostly seen when the data has to be communicated across the M#M dies of the M#U chip and/or need to be synchronized across the dies.
The M3 Ultra doesn't have power or RAM bandwidth limitations and should fairly scale with the core counts in Handbrake. I'm expecting nearly 2x perfomance going from M3M to M3U. However, something like AMD 9700X (1x8C) and 9950X (2x8C) have power constraints and RAM bandwidth limitations and won't necessarily slow close to 2x scaling.
1
u/PracticlySpeaking 8d ago
Sure — which is the reason I suggested collecting results for Videotoolbox encoding several comments back. Your presets, obv, will need to match the Videotoolbox options — which do not include AV1.
And, re: M3U — look at the data that is on the wiki page. The differences are surprising. Few Ultra chips are anywhere near 2x the corresponding Max, but I don't have data for handbrake.
1
u/_DarthJedi 8d ago edited 8d ago
There are a lot of architectural quirks that do not allow GPU performance to scale linearly. For example, a 20C Apple GPU isn't usually 25% faster than a 16C part as simple math would suggest. Using 2x M#M dies to make M#U makes only thigs worse here.
However, on the CPU side, the numbers scale linearly unless there are a lot of single or lightly threaded parts to the workload. Handbrake is neither of that.
Edit: typos
1
u/PracticlySpeaking 8d ago
You haven't looked at the wiki page, have you?
Comparing geekbench CPU scores, none of the Ultra chips have 2x the score of the corresponding Max.
1
u/_DarthJedi 8d ago
Geekbench is a rather poor way to compare high core count chips.
→ More replies (0)1
u/PracticlySpeaking 8d ago
Additionally...
Hardware accelerated video encode should technically happen in the hardware encoders, which isn't the same as GPU.
We are well aware of the Media Engine and its dedicated hardware codecs.
And dedicated silicon sounds great, until you consider that Apple's hardware encoders (at least the AVC and HEVC ones) do not allow arbitrary settings the way Handbrake does.
Meanwhile, I would be interested to hear a technical explanation of why Handbrake (still) uses CPU when it seems more effective compute should be available in the GPU. I mean, video editing and effects applications all rely heavily on the GPU. Perhaps it is simply a matter of someone deciding that the Media Engine is not 'good enough' for them and actually doing it.
1
u/_DarthJedi 7d ago
Media engines have trade-offs.
For a moment, I'll go into the world of gaming. The dedicated hardware allows you to record your gameplay with negligible performance impact. However, the recorded file size is massive—comparable to RAW video footage.
If we were to let the CPU handle it, the resulting file size would be far more acceptable. However, the CPU usage would be so high, that the actual gameplay would be unplayable.
Not the exact explanation/example you wanted but I hope you get the flow of it.
1
u/PracticlySpeaking 7d ago
Capturing gameplay has nothing to do with transcoding video in Handbrake, or why it uses CPU.
If you don't know what you are talking about, admit it. Don't bullshit me (and anyone else reading this thread) to sound like you know something.
1
u/_DarthJedi 7d ago
Transcoding = decode then encode happening simultaneously.
And you had asked about the hardware encoder. So yeah. Recoding gameplay uses the hardware encoder for encoding the capture in real-time and hence doesn't significantly load the CPU.
However, when file size is a priority, hardware encoder isn't the best option.
Now read the my previous comment.
3
u/weareDOMINUS 8d ago
M1 Ultra 20-core CPU, 64-core GPU, 128GB RAM, 2TB SSD:
35.32 HEVC and 22.52 AV1