H.265 export corruption fixed, DaVinci Resolve Studio 19.1.1

Might be worth trying to install Sonoma to an external disk and boot from there.

I have seen cases where brand-new Mac models simply would not run with old Mac OS's. I hope it's not the case here.

I'm very curious to see if this is a Sequoia problem or a hardware problem. If it were me, I'd slow the render speed way down: 8K 60fps is very, very, very demanding footage and would be a problem on a massively-powerful 8GPU 256GB 80-core system, let alone a comparatively dinky Mac Mini (M4 or Pro or not).

Brand new Macs don't have old OSs on them and there is no "easy" way to go backwards either and it's almost impossible after a point.

8K/60 or even 8K/120 is not that difficult to edit. Using an intra-frame codec such as ProRes makes 8K quite easy. Especially as there are dedicated decoder chips for ProRes. Even older M1 variations have no difficulty with 8K/60.

Even traditionally difficult inter-frame codecs are quite easy to deal with in 8K on Apple Silicon, again, due to the decoders.

Now heavy processing is a different story but that's the case for any level of machine. Any machine can be brought to its knees in Resolve with high bandwidth video and a handful of heavy plugins.

I'm not sure why you think the size of a Mac has anything to do with its performance, as in "dinky". The M4 Pro Mini is faster in a number of tasks compared to my last Windows machine, based on a 4070. Likewise, the 4070 would be faster with certain things compared to the M4 Pro. My 4070 machine was only about £100 cheaper to build, so price to performance isn't that different.

Just a note to those who need FCP-X, Compressor or Motion too: The new versions will demand Sequoia.
Time for a sandbox, it seems, since I really like Motion for Motion Graphics.

8K/60 or even 8K/120 is not that difficult to edit. Using an intra-frame codec such as ProRes makes 8K quite easy. Especially as there are dedicated decoder chips for ProRes. Even older M1 variations have no difficulty with 8K/60.

What camera are you using for 8k/120 and Prores? I thought the Raptor was basically it for 120 8k? In which case why shoot Prores?

My next question which Ninja supports 8k 120? I thought the ultra maxed out at 30 FPS? Have they released a new model?

8K/60 or even 8K/120 is not that difficult to edit. Using an intra-frame codec such as ProRes makes 8K quite easy. Especially as there are dedicated decoder chips for ProRes. Even older M1 variations have no difficulty with 8K/60.

What camera are you using for 8k/120 and Prores? I thought the Raptor was basically it for 120 8k? In which case why shoot Prores?

My next question which Ninja supports 8k 120? I thought the ultra maxed out at 30 FPS? Have they released a new model?

My 8K/120 ProRes files are from Resolve exports.

M1 Max MBP, macOS 15.1, I uninstalled Studio 19.1 and went back to 19.03 and I have corrupted outputs...

I confirm it happens on M1 Max MBP 16, 4k/59.94 ProRes422 HQ source, exporting to 4k/59.94 H.265 HEVC and using no Fx or edits. A 60-sec 4k/59.94 timeline will produce corrupted H.265 output. This is seen as a slideshow-like playback of the exported file. It's not limited to the M4 Pro. This is using MacOS Sequoia 15.1 and Resolve Studio 19.1. It also happened on 19.03 on Sonoma 15.1, but I only tested that version on the M4 Pro Mac Mini.

Edit/add: On M4 Pro Mac Mini, it happens with hardware decode acceleration enabled or disabled. I'm currently testing whether disabling hardware *encode* acceleration has an impact.

Update: Above is a non-test because disabling H.265 hardware encode acceleration is "ganged" with disabling multi-pass encode. So the UI does not permit doing H.265 multi-pass encode without hardware encode acceleration. There is no fundamental reason why H.265 multi-pass software encoding cannot be used (except maybe it would be unreasonably slow).

As previously stated, on the Deliver Page, the scenario seems to involve not using "Optimize for speed" (which is H.265-specific), Encoding Profile: Main10, and Multi-pass encode enabled.

If using burn-in timecode, it shows dropping many frames. Quicktime Player (if you click on the timecode number in player controls) will toggle between program timecode, clip timecode, and frame number. That shows the frames (as determined by QTP's interpretation of timecode) are streaming past but just not being displayed. The file is just messed up.

I also tested the same MacOS & Resolve Studio versions on the 2019 i9 MacBook Pro 16, M2 Pro Mac Mini and M1 Ultra Mac Studio, and it didn't happen on those (so far).

The issue isn't how to work around the problem -- that seems easy: just don't use multi-pass, or use "Optimize for speed", or don't use H.265. Rather, data corruption is gravely serious, and it raises the question of whether the current boundaries are nailed down. IOW does it happen with other parameters or machine types we haven't discovered yet?

M1 Max MBP, macOS 15.1, I uninstalled Studio 19.1 and went back to 19.03 and I have corrupted outputs...

I confirm it happens on M1 Max MBP 16, 4k/59.94 ProRes422 HQ source, exporting to 4k/59.94 H.265 HEVC and using no Fx or edits. A 60-sec 4k/59.94 timeline will produce corrupted H.265 output. This is seen as a slideshow-like playback of the exported file. It's not limited to the M4 Pro. This is using MacOS Sequoia 15.1 and Resolve Studio 19.1. It also happened on 19.03 on Sonoma 15.1, but I only tested that version on the M4 Pro Mac Mini.

Edit/add: On M4 Pro Mac Mini, it happens with hardware decode acceleration enabled or disabled. I'm currently testing whether disabling hardware *encode* acceleration has an impact.

Update: Above is a non-test because disabling H.265 hardware encode acceleration is "ganged" with disabling multi-pass encode. So the UI does not permit doing H.265 multi-pass encode without hardware encode acceleration. There is no fundamental reason why H.265 multi-pass software encoding cannot be used (except maybe it would be unreasonably slow).

As previously stated, on the Deliver Page, the scenario seems to involve not using "Optimize for speed" (which is H.265-specific), Encoding Profile: Main10, and Multi-pass encode enabled.

If using burn-in timecode, it shows dropping many frames. Quicktime Player (if you click on the timecode number in player controls) will toggle between program timecode, clip timecode, and frame number. That shows the frames (as determined by QTP's interpretation of timecode) are streaming past but just not being displayed. The file is just messed up.

I also tested the same MacOS & Resolve Studio versions on the 2019 i9 MacBook Pro 16, M2 Pro Mac Mini and M1 Ultra Mac Studio, and it didn't happen on those (so far).

The issue isn't how to work around the problem -- that seems easy: just don't use multi-pass, or use "Optimize for speed", or don't use H.265. Rather, data corruption is gravely serious, and it raises the question of whether the current boundaries are nailed down. IOW does it happen with other parameters or machine types we haven't discovered yet?

Hi, Joe.

That’s all awesome information and some stuff that I’d not tried, thanks for your hard work and time.

As you say, the “workaround” right now is to just not use those parameters for the export. However, is the problem isolated, does it knock on to other problems, is it an indication of an other issues?

Looking at the way the problem has come up, it’s been the macOS 15.1 update that’s triggered it. Maybe Apple have changed something with the update and not informed 3rd party developers. Maybe they did inform 3rd party developers and the developers haven’t implemented or accounted for the changes. Regardless, my guess is that BMD will respond with an update to fix the issue. However, who knows when that will be.

Apple have a lot of form for breaking things with OS updates. I have a lot of UVC devices and Apple break codec compliance with the UVC standard regularly. Even basic fundamental things like colour space selection go missing with their updates and then may re-appear with a later update.

There’s even issues within the OS UI itself since the update and I’m noticing QuickTime problems as well.

Cheers,
Dave.

[Shrinivas Ramani]

Thanks for the reports.

Please try the new 19.1.1.

Thanks for the reports.

Please try the new 19.1.1.

I tested it on an M4 Pro Mac Mini and M1 Max MacBook Pro, both running Sequoia 15.1.1, and it worked OK.

This was the scenario whereby the H.265 output if using hardware acceleration and multipass, but not "optimize for speed", would create a laggy output file.

I first verified the original scenario would reliably reproduce on 19.1 on both machines (it did), then only upgraded to 19.1.1 and ran the same scenario. The laggy output file does not happen on 19.1.1.

I was never able to reproduce the crash when exporting, but the laggy output problem seems definitely fixed.

Thanks for the reports.

Please try the new 19.1.1.

Thanks.

I'm just doing a video about the issue being fixed, I'll post it to the forum later.

Cheers,
Dave.

That’s great news, Dave. Thanks.

That’s great news, Dave. Thanks.

You are very welcome, Steve.

I'll start a new post later with the before and after for the fix. Hopefully it will encourage other Apple Silicon users to update.

Cheers,
Dave.

POST AMENDMENT & UPDATE, PROBLEM FIXED:

Just a post update about the H.265 export corruption problem with DaVinci Resolve Studio that I was having, which has now been fixed with the 19.1.1 update. This was an issue with Apple Silicon.

I also had an issue of a repeatable crash scenario with the M4 Pro Mac Mini. However, I suspect that this may have been unique to either my machine or the particular SoC configuration I was using. Although, the crash scenario was happening under the same scenario as the corrupted output, so I'm guessing that they were one of the same and not necessarily separate issues. I no longer have the M4 Pro Mac Mini so can't test that exact scenario. However, my M4 Max MacBook Pro and M4 Mac Mini are working fine after the update to 19.1.1.

Here's some extra blurb.

The previous version of DaVinci Resolve Studio, 19.1, would generate corrupted exports when using H.265 with the Main10 profile with a multi-pass encode and having optimise for speed turned off. I suspect that this was more of a macOS issue as the problem only happened after the macOS Sequoia 15.1.1 update.

Anyway, after updating to DaVinci Resolve Studio 19.1.1, this problem has now gone.


Thanks to the BMD Resolve team for a speedy fix.

Cheers,
Dave.

Yep, it's fixed!