Handbrake & FFMpeg Encoding Performance: 2020 M1 MacMini vs 2021 M1 Pro MacBook Pro 14"

[rajs]

The older and slower M1 MacMini is 2 to 2.5x faster currently on the same tasks using the latest and same version of HandBrake or FFmpeg (with M1 patch for VideoToolBox) as compared to the M1 Pro 2021 MacBook 14"

This is the result when using the VideoToolBox encoder for hardware acceleration (both H264 and HEVC)

MacMini - M1 with 8GB RAM / 256GB SSD
MacBook Pro 14" - 16GB RAM / 512GB SSD

Seems like there is some optimization or instruction patches that need to be done for the M1 Pro (and M1 Max) in comparison to the M1. Just found that to be interesting that something is different in that processing pipeline and requires explicit code change it seems vs just working.

(YES I know the VideoToolBox encodes are not of the same quality / size efficiency as the x264 / x265 software non hardware accelerated library - but for my purpose I prefer the time savings when using VideoToolBox).

Anyone else see the same ?

 

[Homy]

Where is the result?

 

[rajs]

Where is the result?

From the very 1st line in original post:

The older and slower M1 MacMini is 2 to 2.5x faster ...

 

[Homy]

From the very 1st line in original post:

I was thinking of actual numbers, like the length of the video and conversion times.

 

[rajs]

Here is some detail - hopefully you've got something similar you can try since you are asking for explicit details beyond the generic from above.

/usr/bin/time ffmpeg -y -loglevel error -stats \​

-ss 0:00:03 -to 0:00:33 \​

-i 2_test.mov \​

-map 0:0 \​

-filter:v eq=saturation=1.1:gamma=1.6,yadif,scale=w=-2:h=720 \​

-c:v h264_videotoolbox -b:v 5000k \​

-color_primaries:v bt709 -color_trc:v bt709 -colorspace:v bt709 \​

-aspect 4:3 \​

-map 0:1 -c:a:0 aac_at -aac_at_mode:a:0 cvbr -ar:a:0 48000 \​

-sn \​

-movflags disable_chpl \​

-movflags +faststart \​

2_test.mp4​

Result from 2021 14" MacBook Pro w/ M1 Pro 16GB RAM / 512GB SSD
frame= 900 fps=150 q=-0.0 Lsize= 18829kB time=00:00:30.03 bitrate=5135.3kbits/s speed=5.01x
6.04 real

Result from 2020 Mac Mini M1 8GB RAM / 256GB SSD
frame= 900 fps=395 q=-0.0 Lsize= 18819kB time=00:00:30.03 bitrate=5132.7kbits/s speed=13.2x
2.33 real

Above holds up to same numbers even without the -ss -to options and letting it encode the full .MOV (DV) file.

Command issued on both against a MOV file with Mediainfo of the following:

Video​

ID : 1​

Format : DV​

Commercial name : DVCPRO​

Codec ID : dvc​

Duration : 7 min 38 s​

Bit rate mode : Constant​

Bit rate : 24.4 Mb/s​

Width : 720 pixels​

Height : 480 pixels​

Display aspect ratio : 4:3​

Frame rate mode : Constant​

Frame rate : 29.970 (30000/1001) FPS​

Original frame rate : 29.970 (29970/1000) FPS​

Standard : NTSC​

Color space : YUV​

Chroma subsampling : 4:1:1​

Bit depth : 8 bits​

Scan type : Interlaced​

Scan order : Bottom Field First​

 

[JimmyjamesEU]

There is talk over at Ars about this also. The consensus is that there is a bug, but it's unclear whether that bug is in ffmpeg/handbrake or Monterey or both! Certainly hardware encoding is much slower than it should be given there are reviews out there with the Max getting ~90fps at 4k h.264/hevc when using Resolve.

 

[cal6n]

I wonder if Handbrake is only using the efficiency cores?

 

[rajs]

There is talk over at Ars about this also. The consensus is that there is a bug, but it's unclear whether that bug is in ffmpeg/handbrake or Monterey or both! Certainly hardware encoding is much slower than it should be given there are reviews out there with the Max getting ~90fps at 4k h.264/hevc when using Resolve.

Thanks for the pointer to Ars, I'll look up the link so I can follow the discussion there.

RE: bug, or something else -- I really wish the "independent" review community on new Apple products would actually take the time to test and report on this sort of stuff. I haven't seen a single review that called out an issue here in terms of Handbrake or ffmpeg when it was being reviewed. Sad really. Also Apple really could do better on their own in terms of ensuring open source programs that are very commonly used actually get tested in-house and that they contribute even more back into the open source community for projects a lot of Apple customers use. (Love Apple, but wanted to say that).

 

[lclev]

Okay I am not at work now where I did this little experiment, but today I took a 1080p 105 minute 5.8Gb MKV video and ran it through Handbrake on my 2021 14" MBP M1 Max, 64GB and also on my Windows 10 PC - with 2970WX Threadripper, 64 GB DDR4, all SSD drives. I started both at the same time. It took 14 minutes on the M1 and 19 minutes on the PC to convert the MKV to an MP4. Keep in mind Handbrake, if I am remembering correctly, installed using Rosetta.

Not totally scientific and as I said I am not at work so I don't have detailed stats but for me anything that shaves 5 minutes off is 5 minutes I am not having to wait.

What was also impressive was the MBP was only slightly warm. Not even in the ball park to how hot my 13" 2020 MBP i7 would get doing the same task and taking a lot longer.

I did have Activity monitor open and iStat monitoring (did I mention I had it hooked up to two 27" 4K monitors too?) The M1 Max showed 93% CPU usage but memory use was low. Not sure which or how many cores? On the PC I had the Performance monitor open so I could see all 24 cores/ 48 threads were in use and way more swapping going on and memory usage. Darn I wish I had more detail... Anyway I was impressed and now I really feel I have a portable system that can get the job done if I work from home.

 

[rajs]

If you are using Handbrake from last few releases it now has an ARM native version.

Handbrake and Ffmpeg issue is most likely related to specific encoder - videotoolbox. Not the x264/x265 software library.

Yes, the M1 / M1Pro / M1 Max are very impressive ….

And yet there is still an issue out there with the videotoolbox encoding pathway. If that issue is solved and one selects that encoder in Handbrake or ffmpeg you’ll see even better speed (quality and output file size are a separate issue - x26x libs are better for quality and final file size)

 

[JimmyjamesEU]

Thanks for the pointer to Ars, I'll look up the link so I can follow the discussion there.

RE: bug, or something else -- I really wish the "independent" review community on new Apple products would actually take the time to test and report on this sort of stuff. I haven't seen a single review that called out an issue here in terms of Handbrake or ffmpeg when it was being reviewed. Sad really. Also Apple really could do better on their own in terms of ensuring open source programs that are very commonly used actually get tested in-house and that they contribute even more back into the open source community for projects a lot of Apple customers use. (Love Apple, but wanted to say that).

Yeah, I agree it'd be nice if these things were reported on or avoided. I think part of the reason is most people using hardware encoders are doing so via an NLE (FCP, Resolve or Premiere). The encoders work fine on these. If you check out the Max Tech reviews on youtube, you can see the Max is getting 4k90fps, which is impressive.

Using ffmpeg/Handbrake is a less common activity, especially with hardware encoders. I'm not sure how active the community is within those projects for hardware encoders. I just discovered the other day that Handbrake doesn't support 10 bit encoding on Nvidia gpus. Incredible. That must be a very common possibility for many people and it just..isn't supported! My impression is using the hardware encoder is looked down upon within these projects. For reasons of quality they recommend x264/x265. We'll see what happens I guess. I know Casey Liss from the ATP podcast is a big ffmpeg user. Someone could reach out to him and ask about it, he may be able to raise some awareness of the issue. Long shot! Or it may just resolve itself with an update either to Monterey or ffmpeg!

 

[rajs]

I wonder if Handbrake is only using the efficiency cores?

For ffmpeg using-c:v h264_videotoolbox parameter -- when using the -loglevel debug I am seeing: " ... detected 8 logical cores ..."

 

[BayouTiger]

Should note that this is relevant to the Pro and Max M1’s. VTB did not work on the M1 when released either, but was fixed quickly.