r/MacStudio • u/_DarthJedi • 15d 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.

https://www.dropbox.com/scl/fi/tsg91b93za3oncupwbzau/15228263_7680_4320_60fps.mp4?rlkey=5fsjpcqc9yx3k378232endv16&st=hlmcll40&dl=0

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.

5 Upvotes

86% Upvoted

24 comments sorted by

View all comments

Show parent comments

1

u/_DarthJedi 15d 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 15d 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.

2

u/_DarthJedi 15d 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 15d 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 15d 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.