H.265 export corruption - Resolve Studio & M1 Max

Hi.

I'm wondering if anyone has noticed this problem.

I'm getting random corruption within my H.265 hardware exports. I'm on the latest version of Studio, 18.1.4 build 9, and latest version of MacOS, 13.4.1, on an M1 Max.

I started noticing this issue a couple of versions back on Studio beta and the previous update of MacOS.

Re-exporting the same project will either fix the issue or the corruption may still happen but will appear in different places. The corruption does not appear in the same place.

Although the problem seem more prevalent with various iterations of XAVC sources. I have noticed it with ProRes 422 HQ Ninja sources.

This definitely isn't source media corruption, as there are no issues with the source media, at least as far as Resolve's timeline is concerned or the QT Player.

It's definitely not storage bandwidth issues (under-running etc.)

It doesn't feel heat related as the issue can occur immediately after a cold boot.

The problem occurs regardless of media storage and export destination locations, be that the same drive or separate drives.

There are no other programs running or any other disk or external network activity when Resolve is running, outside of Resolve's own system and disk usage.

Exporting to ProRes does not have this issue.

As this setup needs to stay clean, I don't have the option to test for similar workflows using other NLEs and/or encoding software etc. Hence the question here to see if anyone on a similar system has similar issues.

Having seen similar issues to this over the years with various DSP and hardware accelerated rendering and given that the problem has remained across a few different updates and version of Resolve and different updates to MacOS. My gut is edging toward this being a hardware issue but before dealing with the less than genius "Geniuses" at Apple, I'm trying to rule out software issues as best as possible.

Here's a link to a file showing the issues which also has some missing frames. This is actually just the first 12 seconds from a longer export which would have been far too big to upload. This clip is not a re-render, it's a lossless truncation from the original file.

This particular output contains 25 FPS progressive footage inside a 60 FPS timeline (the bulk of the edit was 60 FPS source material). Although, any variation of 4K and 8K resolutions at any frame rate for the project with any mix, or not, of source resolution and frame rate source footage will randomly suffer this problem. To be clear, even native 1:1 in and out projects randomly corrupt.

https://www.mediafire.com/file/690pw8lq ... E.mov/file

Any help would be greatly appreciated and hopefully someone from BMD can chime in.

Cheers,
Dave.

It seems we are looking at an issue between DR and MacOS Ventura.
Or has anybody around here seen it under Monterey too?

It seems we are looking at an issue between DR and MacOS Ventura.
Or has anybody around here seen it under Monterey too?

Hi, Uli.

That sounds like a possibility, as I'd never seen this issue with Monterey.

Cheers,
Dave.

...I'm getting random corruption within my H.265 hardware exports. I'm on the latest version of Studio, 18.1.4 build 9, and latest version of MacOS, 13.4.1, on an M1 Max...I started noticing this issue a couple of versions back on Studio beta and the previous update of MacOS....Re-exporting the same project will either fix the issue or the corruption may still happen but will appear in different places. The corruption does not appear in the same place....Although the problem seem more prevalent with various iterations of XAVC sources. I have noticed it with ProRes 422 HQ Ninja sources....This definitely isn't source media corruption, as there are no issues with the source media, at least as far as Resolve's timeline is concerned or the QT Player....Exporting to ProRes does not have this issue....This particular output contains 25 FPS progressive footage inside a 60 FPS timeline (the bulk of the edit was 60 FPS source material). Although, any variation of 4K and 8K resolutions at any frame rate for the project with any mix, or not, of source resolution and frame rate source footage will randomly suffer this problem...

Thanks for that well-worded problem description.

This is very interesting. There was a previous similar problem on FCP 10.6.2 and 10.6.3 that was unique to M1 Max and M1 Ultra (that was before M2 Max/Ultra, so I don't know about those). That was fixed in 10.6.4. Those versions required Monterey 12.3 as a minimum. It seemed to remain fixed in FCP 10.6.4 and later on Ventura M1 Max/Ultra machines.

Visually the problem could sometimes appear like your case, although there were several manifestations. However to my knowledge it was not unique to H265/HEVC output but could also happen with H264 or ProRes 422 output. On the input side, it seemed to either require ProRes 422 media, or else it was much less likely if using H264 or HEVC media. I never narrowed that down since the focus was reliably reproducing the problem to expedite a fix.

That case also seemed to require either rate conforming, retiming (or both), and it was more likely if using multi-frame effects such as temporal noise reduction.

I don't think it happened on Resolve Studio on the same M1 Max/Ultra hardware and MacOS versions. I believe I tried to reproduce it using the same scenarios and I never observed it on Resolve. That was around July 2022.

The fact it was unique to M1 Max/Ultra was interesting because those were the only machines which had multiple parallel ProRes encode/decode engines, and multiple H264/HEVC encode engines. Those were supposedly not used in parallel for single-stream operations, but it was always unclear to me how on a framework and hardware level synchronization was handled, and the degree to which the Video Toolbox framework was thread-safe.

With the FCP frame order problem on M1 Max/Ultra, it clearly happened before the final export phase, since it was visible during playback from render cache. However the number and location of those frames could change after the final encode. IOW the encoded output file was different from the render cache. FCP does not always use render cache for final export -- this varies based on the Fx in use, and reproducing the problem (reliably) required using certain Fx.

Resolve gives several options for render cache besides ProRes, so I'd suggest trying those to see if it changes the behavior. That might help narrow down in what pipeline phase it's happening.

You can also disable H264/H265 hardware decode acceleration in Resolve>Preferences>System>Decode Options. Of course on the Deliver page you have the option to disable H265 hardware encode acceleration. Maybe running some variations of the above settings will help define the problem.

On the current FCP on M1 Max/Ultra, H265 export works very well.

Take a look here: viewtopic.php?f=21&t=181606 upgrade to Sonoma Public Beta solved the issue for me

...I'm getting random corruption within my H.265 hardware exports. I'm on the latest version of Studio, 18.1.4 build 9, and latest version of MacOS, 13.4.1, on an M1 Max...I started noticing this issue a couple of versions back on Studio beta and the previous update of MacOS....Re-exporting the same project will either fix the issue or the corruption may still happen but will appear in different places. The corruption does not appear in the same place....Although the problem seem more prevalent with various iterations of XAVC sources. I have noticed it with ProRes 422 HQ Ninja sources....This definitely isn't source media corruption, as there are no issues with the source media, at least as far as Resolve's timeline is concerned or the QT Player....Exporting to ProRes does not have this issue....This particular output contains 25 FPS progressive footage inside a 60 FPS timeline (the bulk of the edit was 60 FPS source material). Although, any variation of 4K and 8K resolutions at any frame rate for the project with any mix, or not, of source resolution and frame rate source footage will randomly suffer this problem...

Thanks for that well-worded problem description.


This is very interesting. There was a previous similar problem on FCP 10.6.2 and 10.6.3 that was unique to M1 Max and M1 Ultra (that was before M2 Max/Ultra, so I don't know about those). That was fixed in 10.6.4. Those versions required Monterey 12.3 as a minimum. It seemed to remain fixed in FCP 10.6.4 and later on Ventura M1 Max/Ultra machines.

Visually the problem could sometimes appear like your case, although there were several manifestations. However to my knowledge it was not unique to H265/HEVC output but could also happen with H264 or ProRes 422 output. On the input side, it seemed to either require ProRes 422 media, or else it was much less likely if using H264 or HEVC media. I never narrowed that down since the focus was reliably reproducing the problem to expedite a fix.

That case also seemed to require either rate conforming, retiming (or both), and it was more likely if using multi-frame effects such as temporal noise reduction.

I don't think it happened on Resolve Studio on the same M1 Max/Ultra hardware and MacOS versions. I believe I tried to reproduce it using the same scenarios and I never observed it on Resolve. That was around July 2022.

The fact it was unique to M1 Max/Ultra was interesting because those were the only machines which had multiple parallel ProRes encode/decode engines, and multiple H264/HEVC encode engines. Those were supposedly not used in parallel for single-stream operations, but it was always unclear to me how on a framework and hardware level synchronization was handled, and the degree to which the Video Toolbox framework was thread-safe.

With the FCP frame order problem on M1 Max/Ultra, it clearly happened before the final export phase, since it was visible during playback from render cache. However the number and location of those frames could change after the final encode. IOW the encoded output file was different from the render cache. FCP does not always use render cache for final export -- this varies based on the Fx in use, and reproducing the problem (reliably) required using certain Fx.

Resolve gives several options for render cache besides ProRes, so I'd suggest trying those to see if it changes the behavior. That might help narrow down in what pipeline phase it's happening.

You can also disable H264/H265 hardware decode acceleration in Resolve>Preferences>System>Decode Options. Of course on the Deliver page you have the option to disable H265 hardware encode acceleration. Maybe running some variations of the above settings will help define the problem.

On the current FCP on M1 Max/Ultra, H265 export works very well.

Hi, Joe.

Thanks for your very detailed response, it’s very much appreciated.

My problem does sound very similar to the FCP mess you describe.

I appreciate your suggestions about switching off certain hardware codecs/accelerators and the information about various parameter and environment changes, plus the acquisition and export codec information. However, at this point I don’t have the time to go fault finding or to work out potential workarounds. Plus, it’s the hardware assistance that was the main reason for switching from Windows to Mac and from Edius to Resolve and I can’t work without it, even if disabling it were a temporarily workaround.

It may also be worth mentioning, as it seems to be another parallel with what you’ve described. I also have an M1 machine and this doesn’t “seem” to suffer the same problem. However, I don’t use that for my daily video work and only tried reproducing this problem on it in a quick attempt to try and narrow down the problem’s environment. However, although I didn’t observe the problem on the M1 with Studio. The problem is very random and I didn’t try enough exports to completely rule out the M1. Although, my first instinct suggested that the problem wasn’t manifesting itself on the M1 with Studio.

I’ve “kind of” accepted some of the quirks with using Mac and Resolve and I don’t mind workarounds that aren’t cumbersome. In the real world of anything to do with computers, nothing ever works 100%. However, and being blunt, I’m really annoyed with this particular problem as it means that I have no confidence in the final output and am always second guessing it.

What’s doubly annoying is that I’ve just got rid of an Intel 13th gen and RTX 4070 Windows system that obviously didn’t have this issue. Although, my preference for my video workflow is Resolve on ARM/Mac due to the power efficiency and lower noise. Even if a cheaper X86(64)/Windows and Nvidia system is more powerful as far as processing is concerned.

The other thing that I’m quite annoyed with, is that neither BMD or Apple are at all forthcoming when these types of issues arise. I can understand the problems with a Windows setup, where there are thousands of potential hardware configurations, that can make finding and reproducing bugs or issues very difficult or next to impossible. However, due to the control in the hardware design of Apple Silcon and its limited variations, I’d have expected a better response to issues on these systems.

I appreciate that the OS will also play a part in identifying potential bugs etc. However, and although I’m neither a software or hardware engineer. I’m going to hazard an educated guess that due to the tight integration between MacOS and Apple Silicon and the fact that Apple have total control of both. That it “should” be easier to find issues at both the hardware and software levels on a Mac/ARM setup compared to a Windows setup with its complete lack of control and manufacturing oversight between the OS and hardware, through to any client software.

Sorry if it sounds like I’m moaning, but I am The bottom line is that I usually make at least one video per day for upload to either YouTube or Amazon and along with that there will be a number of exports/encodes. So this particular problem (or bug) is, by definition, a “show stopper” for my particular work scenario.

Anyway. Thank you again for your input, help and insight. Regardless of my aforementioned reluctance to go fault finding and working out of potential workarounds. I obviously have no immediate option but to get bogged down with those purists. So thanks again for your detailed response as it will be very helpful for a number of starting points to entrances down rabbit holes that I will be inevitably visiting

I should have stuck with Windows

Take care.

Cheers,
Dave.

Take a look here: viewtopic.php?f=21&t=181606 upgrade to Sonoma Public Beta solved the issue for me

Hi, Amedeo.

Thanks for that link, it’s very useful.

Cheers,
Dave.

Today there were updates for the codecs in MacOS and the video applications, maybe those help?

Today there were updates for the codecs in MacOS and the video applications, maybe those help?

Thanks, Uli.

I'll have to check that out.

Cheers,
Dave.