h.264 Hardware Acceleration and Multi-Pass Issues on M1 Mac

Hello,

Just wanted to address an issue I've been experiencing with every DaVinci Resolve release after version 17.1. I'm guessing 17.1 is the last version before M1 support because since then, h.264 encoding with multi-pass and hardware acceleration has always been failing.

In version 17.1, videos would do two passes of encoding and then will save onto disk. That's the normal for me. Every version after that, the encoding would freeze at the end of the first pass and then give the "Failed to encode the video frame" error. Then I would have to uninstall the newer versions and reinstall 17.1

It took me a long time of troubleshooting, but I figured out that using hardware acceleration and multi-pass encoding together was the problem.

With both hardware acceleration and mult-pass disabled, videos encode successfully but will result in lower-than-standard image quality.

With hardware acceleration off and multi-pass on, things sometimes go smoothly. But there are instances where the encoder goes through up to 6 passes, and appears to finish successfully, but when you check the file it's only a few kilobytes in size, resulting in a failed export.

With hardware acceleration on, encoded failure or not, the performance is impressively fast! It's unfortunate that it can't be used concurrently the multi-pass option to get a better quality export.

Currently I'm running version 17.3.2 Build 8 and I'm still running into these same issues. I have hardware acceleration turned off and multi-pass turned on and it seems to be more stable than previous versions. My videos have been going through up to 3 passes and successfully saving to disk. I just would like to take advantage of the hardware acceleration since it's an option.

If it helps any, I'm using a Mac Mini M1 16GB RAM with MacOS 11.5.2 at the time of this writing. If there's any other settings I may have overlooked that could be causing conflicts, please let me know. Thanks for your time.

[Peter Chamberlain]

moved to Resolve forum

I have the same machine and I never use DR for encoding to H.264 or H.265. I render to ProRes 422 HQ and then use the free Handbrake encoder for final delivery. It has all the settings and never failed me.

With or without multi-pass the GOP encoding in DR is not really its greatest feature.

I have the same machine and I never use DR for encoding to H.264 or H.265. I render to ProRes 422 HQ and then use the free Handbrake encoder for final delivery. It has all the settings and never failed me.

With or without multi-pass the GOP encoding in DR is not really its greatest feature.

Thanks for the input. I didn't know Handbrake was still around. I'll definitely give that a go.

I'm just putting this out there in hopes that we'll get updates that fix these issues so that we won't have to rely on other apps. I actually like that nearly everything you need is all in one package.

Well, starting with 17 BM seems to rely on third-parties to solve such issues. There is already the MainConcept plug-in.
But it’s not free and Handbrake is still alive and kicking, getting regular updates. With some clever scripting and a watch folder, you should be able to make the process run automatically.

Glad I'm not the only one having this issue and thanks to Uli for the easy Handbrake suggested workaround.
For me, also on 17.4.2 on an M1 Air, I have found that there is a bit-rate barrier that stops Hardware Acceleration and Multi-pass from working.
I tried a 4+ min 720p video and ticking both boxes would consistently fail if bitrates are anything less than 3000kbps. Not even 2999 will work. And even if I use 3000, the resultant output (of a 220kbps original!) winds up being 1700kbps.

I have the same machine and I never use DR for encoding to H.264 or H.265. I render to ProRes 422 HQ and then use the free Handbrake encoder for final delivery. It has all the settings and never failed me.

With or without multi-pass the GOP encoding in DR is not really its greatest feature.

Same here, but DNxHR as I am on PC.

Hopefully one day BM will get their act together with the H.264/5 encoder in resolve. They are obviously trying to steal Adobe's lunch with the Youtuber crowd, and this is a mandatory feature for them.

Quick update. I installed Mac OS Monterey on my M1 Mac and also installed the latest version of DR (17.4.2).

At least the encode error shows up at the beginning of the render instead of the end of the first pass now.

After more experimenting I have to agree that the option to restrict the bitrate is what's causing the errors. The automatic setting is fine, but the file size is unnecessarily large, at least for my needs.

Hopefully this gets fixed soon. For now it's back to reinstalling 17.1

Quick update. I installed Mac OS Monterey on my M1 Mac and also installed the latest version of DR (17.4.2).

At least the encode error shows up at the beginning of the render instead of the end of the first pass now.

After more experimenting I have to agree that the option to restrict the bitrate is what's causing the errors. The automatic setting is fine, but the file size is unnecessarily large, at least for my needs.

Hopefully this gets fixed soon. For now it's back to reinstalling 17.1

FWIW, mine threw the error at the beginning even under Big Sur.