H.264 Hardware Encoding Speeds Way Slower on Mac Studio M1 Ultra vs. M2 Mac Mini
In and old thread over a year ago on this forum, it was said that Screenflow's H.264 Hardware Encoding option on Export was much slower on M1 Pro and M1 Max chip Macs, but H.264 Hardware Encoding (Hardware Accelerated Apple H.264 CODEC) was not slower on M1 chip Macs, and the issue had been determined to be Apple's, and you were waiting on a fix.
Since then, I have just upgraded to a new Mac Mini M2 computer (8GB RAM, 256GB SSD drive) that just came out this week, running Screenflow 10.0.8 and the latest macos Ventura version. I tried the H.264 Hardware Encoding (Hardware Accelerated Apple H.264 option) on a one hour 1080P, 30 fps video, with Hardware Accelerated Apple H.264 option turned on in Screenflow, and it ripped very fast through the encode, faster than I remember the M1 Mac Mini with Hardware Accelerated Apple H.264 turned on.
I then tried and Export with Hardware Accelerated Apple H.264 turned on my Mac Studio M1 Ultra with 128GB RAM and 4TB SSD drive, on the same hour long 1080P video file, with much slower (maybe 10-20X slower) Hardware Encode speeds. Did this issue never get resolved by Apple for M1 Pro, M1 Max, and M1 Ultra chips, and why is the M1 and M2 so much faster with Hardware Accelerated Apple H.264 ?
I do a lot of H.264 1080P encoding with Screenflow, and would very much like to see this encoder speed issue fixed with the higher end Macs with M1 Pro, M1 Max, M1 Ultra, and it may possibly exist on the new M2 Pro and M2 Max chips also.
Thank You.
-
The issue would be tied to macOS and Apple Silicon generally. Of course, chip type and its GPU cores are a factor as well. Apple Toolbox improvements are the biggest issue because we use what Apple offers.
The best reliable check is use the exact same document on each computer with the exact same encoder. Run each test twice. Make sure nothing else is running on the computer and keep in mind the monitors are using GPU resources as well. -
Thanks for the reply Craig!
It appears that Screenflow's Export Hardware Accelerated Apple H.264 option relies on the Apple VideoToolbox to do its H.264 Hardware Encoding, which works very well (and fast) on either Mac Apple Silicon M1 or M2 chips, but not very well (extremely slow) on M1 Pro, M1 Mac, M1 Ultra, M2 Pro, or M2 Max chips.
Until Apple fixes their Apple VideoToolbox H.264 Hardware Encoding software, or Screenflow writes their own encoder routines to be optimized to make full use of all of features and extra hardware encoders found the full line on Apple Silicon chips (including the Pro, Max, and Ultra chips for both M1 and M2), we will not experience very fast H.264 Hardware Encoding video export speeds in Screenflow on anything other than Macs with only regular M1 or M2 chips, and not on Macs with M1 Pro, Max, or Ultra chips, nor on Macs with M2 Pro, Max, or the future M2 Ultra chips.
-
Robert Woeger said:
t appears that Screenflow's Export Hardware Accelerated Apple H.264 option relies on the Apple VideoToolbox to do its H.264 Hardware Encoding,As we must.
Robert Woeger said:
but not very well (extremely slow) on M1 Pro, M1 Mac, M1 Ultra, M2 Pro, or M2 Max chips.Was your Mac Mini M2 on 13.2? Was your Mac Studio M1 Ultra on 13.2? We do report such issues to Apple.
We have found that when we test on the free Handbrake that the same speed issue is shown. This would verify it's Apple Video Toolbox as both ScreenFlow and Handbrake use it to for encoding. That would be a good test to run. It's also possible that an H.264, H.265, Apple ProRes source in Handbrake may behave differently depending on the decoders in the M2 vs M1 vs M1 Ultra. -
I also looked into this back when Macbook Pro M1 Pro/Max were released and now with M2 Max too - had and still have the same issue. I have already lost track, has Apple acknowledged that there's an issue (or a bug) with VideoToolbox software?
The other explanation could be that there's no bug, it's just that they didn't use much of the Max/Pro chips' real estate for the x264 acceleration (if they focused only on the minimum performance required for encoding/decoding h264 for real-time Zoom/FaceTime calls and not for "encode this long video as h264 fast as possible" use cases). So it could be just a hardware limitation too, if they think of H264 as legacy and H265/HVEC/ProRes as the future.
-
Tanel Poder We've certainly communicated with Apple about these issues. If you create an Apple Developers Account you can try to communicate with them. They may not respond though.
https://developer.apple.com
-
-
Tested
2020 M1 13" MBP Monterey 12.6.3
Recorded retina display and exported 1920x1080 Fastest.
Export time 32 seconds.2022 M1 Max Mac Studio Ventura 13.2
Copied over and used the same document from the 13" MBP
Export time 60 seconds.
Clearly still an issue with Video Tool Box.
Just a confirmation with a specific test using the same document and hardware-accelerated export settings.
-
I am not buying next version and I'm switching from Screen Flow after many years because it is unacceptable for them to charge me for every version upgrade and then don't write their own h.264 export routines for M1 pro chips. I export 2h video in 10 minutes in Premiere pro and it takes 1.5h in Screen Flow. It is unusable on M1 pro chips now. I will just record screen in other software and edit it in Premiere Pro. Don't want to switch but have no other choice.
-
Adam macOS includes a free screen recording utility that captures to h.264 and doesn’t require transcoding. Try that.
-
Adam Sorry but we and others have reproduced the issue with Handbrake so this Apple's issue, not ScreenFlow's. Premiere isn't handling the proprietary screen recording codec as source that ScreenFlow is.
-
Brian Wells There are many flat recorders on the market. They don't record the metadata and therefore can't have the feature set ScreenFlow has. Others using similar metadata methodology seem to see the same issues we do as transcoding is required and Apple's Video Toolbox is Apple's supported method for hardware-assisted encoding.
-
CraigS Yeah. That doesn’t sound like anything Apple cares about.
-
Brian Wells And we (and I suspect other developers) have logged this issue with Apple.
-
CraigS Yeah. But, here’s the thing: this “highlight-the-cursor-by-capturing-event” feature was made, what, well over a decade ago? Nowadays, a person can record a flat screen recording and just use a tracker to follow the cursor around and do automated rotoscoping. So, I’m not sure this early 2000s-era approach is even needed anymore. But, I hear ya.
-
-
Brian Wells said:
Nowadays, a person can record a flat screen recording and just use a tracker to follow the cursor around and do automated rotoscoping.Is this something we should implement as an option?
-
CraigS I don't know. I would say this: if Telestream feels strongly that ScreenFlow has something to offer, even to people who already have folders full of flat screen recordings, then, no, probably not. But, one way of looking at this is: what does ScreenFlow offer to someone with a pre-existing folder full of flat screen recordings? Nothing? How about this: if a user could select the cursor, and attach a motion tracker to the cursor in ScreenFlow, and use ScreenFlow's callouts feature as normal from that point onwards, that would be something Telestream could sell to people who already have existing flat screen recordings, right?
-
-
Brian Wells said:
attach a motion trackerThat's been requested for sure
FLOW-7018
With that other features can be implemented to take advantage of that.
It would be a BIG OFFER to those potential customers-
CraigS Uh, yeah. Flat recordings from Windows, Linux, and ChromeOS could even be brought into ScreenFlow for editing.
-
Brian Wells said:
Flat recordings from Windows, Linux, and ChromeOS could even be brought into ScreenFlow for editing.And if you can motion track you could still overlay something tracking the cursor?
Is that what you're considering? -
CraigS I don't really have anything I use screen recordings for. But, you pointed out that these callouts and other things in ScreenFlow are their unique selling proposition and so I figured I'd point out that, if Telestream believes strongly in that, they should probably make it possible to use those features with flat screen recordings from any OS, via a motion tracker on the cursor, not just recordings made with ScreenFlow itself. That's all I was getting at.
-
Brian Wells I agree, motion tracking opens a lot of doors and so many "traditional" NLEs now include that.
-
CraigS Yeah, and if you need any more fuel on the fire for this idea, here's some: iPad Pro screen recordings, with the keyboard and touchpad. If you could track the dot on an iPad with a motion tracker in ScreenFlow, iPad screen recordings could be made more useful with callouts, etc.
-
-
Brian Wells said:
Pad Pro screen recordings, with the keyboard and touchpad.Apple would have to offer that possibility (or at least contribute).
-
CraigS
This screen recording on an iPad shows the dot:
https://www.youtube.com/watch?v=tGVQAQw-D9E
And, that dot could be motion-tracked in an NLE.
Or, ScreenFlow, if ScreenFlow had a motion tracker.
That's all I was getting at.
It's a statement in support of your motion tracker idea.
-
Brian Wells Technically anything moving should be trackable with a proper motion tracker.
Certain information isn't sent by iPads or iPhones though which is why ScreenFlow has "touch" Actions that have to be added to simulate things a finger would do. -
CraigS Right. When not using a trackpad with the iPad, there's no on-screen pointer, so, yes, I could see how that would be useful.
-