H.265 export corruption fixed, DaVinci Resolve Studio 19.1.1

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.

I’m just doing some tests to compare my M1 Max with the M4 Pro for my Resolve workflow.

My M1 Max has 32 GPU cores, 32GB RAM and 1TB storage. The M4 Pro is 14 CPU cores, 20 GPU cores, 48GB RAM, 1TB storage.

So I’ve got a simple test to stress out the encoder. It’s 8K/UHD 119.88 for the media, timeline and output, basically NTSC 8K/120.

The basic export settings are: Apple encoder, H.265, two pass, auto bitrate, not optimised for speed, Main10.

I have just tried exporting 3 times and every time I get a crash on the second/encode pass. The system hangs and then after a short while of moving the mouse and trying to exit Resolve the system crashes out to the login screen. The crashes were in similar places but not the exact same point in the timeline/source media.

I don’t have these issues on my M1 Max using the exact same source media and project settings.

I’m on the latest version of Studio with both Macs and macOS is up to date on both

I’m just interested to know if anyone else has had any export issues with any iterations of M4 so far, or any issues in general within Resolve.

What happens when set to single pass?

Don’t know but I just done another test and it crashed on the first pass. I also managed to get one encode out of it and it was totally corrupted, resolve wouldn’t even see it after importing it back in.

BM may have to look into this.

BM may have to look into this.

For which they would need logs...

Maybe someone with an M4 will send one?

Just for context, a single 8K RGBA 32-bit float image will use about 506MB of memory. Or about 59.3 GByte/s at 120fps. Hope it's not trying to cache those.

As I already said, a lesser computer was fine with the same export. In fact, it was the lesser computer that generated the 8K/120 file in the first place.

If you're running into crashes on a Mac, go to the Help Menu and select "Create Diagnostics Log on Desktop." Also, provide a Mac System info file by going into Mac System Prefs -> About, and clicking "System Report." Save this file (as an SPX file).

Now, place both files on a download site like Dropbox, post the link here in a forum message and see BMD Support has to say.

As I already said, a lesser computer was fine with the same export. In fact, it was the lesser computer that generated the 8K/120 file in the first place.

Is that not also evidence that Davinci Resolve isn't the problem ?

I am sure BM will investigate if you produce logs, etc. as Marc & Uli have suggested.

I wonder if this is source-footage related (i.e. captured gaming footage versus more technically stringent high-end camera footage.)

As I already said, a lesser computer was fine with the same export. In fact, it was the lesser computer that generated the 8K/120 file in the first place.

Is that not also evidence that Davinci Resolve isn't the problem ?

I am sure BM will investigate if you produce logs, etc. as Marc & Uli have suggested.

I wonder if this is source-footage related (i.e. captured gaming footage versus more technically stringent high-end camera footage.)

I never said Resolve was the problem.

It’s not source footage related. There’s no difference between a Resolve ProRes export and “high-end” camera ProRes footage. If there were, then I doubt many people would trust Blackmagic.

Sure you did:

I’m just interested to know if anyone else has had any export issues with any iterations of M4 so far, or any issues in general within Resolve.

And, you published a youtube video all about it.

As for the source, you may have rendered it into Prores, but presumably you originally captured it with something like OBS, which makes it distinctly different from camera footage. Logs, etc would help.

Anyway, that's 5 minutes, I am not giving you the full half hour Somebody else can chime in.

It will probably never be looked into without a log.

Sure you did:

I’m just interested to know if anyone else has had any export issues with any iterations of M4 so far, or any issues in general within Resolve.

And, you published a youtube video all about it.

As for the source, you may have rendered it into Prores, but presumably you originally captured it with something like OBS, which makes it distinctly different from camera footage. Logs, etc would help.

Anyway, that's 5 minutes, I am not giving you the full half hour Somebody else can chime in.

Yet another person who doesn’t know enough, assumes far too much and gets it all wrong………

No, the original footage wasn’t recorded in OBS, it was recorded on an Atomos Ninja. However, the original recording wasn’t what was being used as the source for the export anyway.

The 8K ProRes source file was generated by Resolve using the Apple encoder. So if you’re saying that neither the Apple encoder or Blackmagic know how to render a ProRes file properly, then I suggest you think about that for a minute.

And what has camera footage got to do with anything? Nothing! Unless you are suggesting that camera manufacturers know something about creating ProRes files that Apple and Blackmagic don’t. Again, you may want to think about that for a minute

It will probably never be looked into without a log.

This cannot be repeated too many times.
Here’s how to produce the logs and need information.
viewtopic.php?f=21&t=90190

It will probably never be looked into without a log.

This cannot be repeated too many times.
Here’s how to produce the logs and need information.
viewtopic.php?f=21&t=90190

Maybe if Blackmagic at least acknowledged and interacted with those on the forum who help them by taking the time to give them logs and detailed fault reports. Then maybe more people would be inclined to spend time helping Blackmagic.

Maybe if Blackmagic at least acknowledged and interacted with those on the forum who help them by taking the time to give them logs and detailed fault reports. Then maybe more people would be inclined to spend time helping Blackmagic.

That’s plain insulting to the staff which works hard here analysing everyone’s logs and help them out - even those on the free Resolve.
If you have the Studio you can always go through the regular support channel.

Maybe if Blackmagic at least acknowledged and interacted with those on the forum who help them by taking the time to give them logs and detailed fault reports. Then maybe more people would be inclined to spend time helping Blackmagic.

That’s plain insulting to the staff which works hard here analysing everyone’s logs and help them out - even those one the free Resolve.
If you have the Studio you can always go through the regular support channel.

It’s not insulting it’s the truth. There’s loads of stuff on this forum that could be easily answered by Blackmagic staff but they don’t and a lot of this ends up as conjecture and bad information by posters.

I have Studio and have had many BMD hardware products, I’ve used BMD support and can tell you right now that they aren’t always helpful and there’s been instances where they didn’t even respond to support requests.

I’m fairly sure that if anyone from BMD feels insulted by what I’ve said, they can chime in and say so. I’m also sure that they are grown up enough so as to not need their honour defended by a FanGirl.

It will probably never be looked into without a log.

Agreed.

David, what you describe sounds more like an overheating issue given that crash out to the login screen. If you can't provide a log, perhaps another user of the M4 mini will chime in with their results. After all, your OP was asking others using the M4 mini to provide their experience with encoding. It may be early days for many users to have updated to that platform. Give it a week or two.

...M4 Pro is 14 CPU cores, 20 GPU cores, 48GB RAM, 1TB storage.

So I’ve got a simple test to stress out the encoder. It’s 8K/UHD 119.88 for the media, timeline and output, basically NTSC 8K/120.

The basic export settings are: Apple encoder, H.265, two pass, auto bitrate, not optimised for speed, Main10.

I have just tried exporting 3 times and every time I get a crash on the second/encode pass...

David, I'll have the same machine (except 4TB SSD) by tomorrow, Nov. 11. I'll test your scenario then. It seems relatively straightforward. I also have the M1 Max MacBook Pro 16, so I'll compare to that.

Your screen recording showed an apparent MacOS crash to the login screen. That implies it's not a kernel panic but more than an app crash. One possibility is a GPU timeout resulting in the WindowServer process restarting, then you see the login screen. That should never happen, no matter what the app does.

Your scenario is very straightforward and you described it clearly. If it is a Resolve issue on that machine running that workload, I should be able to reproduce it. If I can't reproduce it that could imply a machine-specific problem. I'll post an update ASAP.

It will probably never be looked into without a log.

Agreed.

David, what you describe sounds more like an overheating issue given that crash out to the login screen. If you can't provide a log, perhaps another user of the M4 mini will chime in with their results. After all, your OP was asking others using the M4 mini to provide their experience with encoding. It may be early days for many users to have updated to that platform. Give it a week or two.

Hi, Steve. Yes, overheating can always be a factor. However, I did check the case and air flow and nothing was feeling that warm. Also, I've heard others saying that the new Minis get quite loud as the fan kicks in, presumably to manage thermals. However, mine didn't really make any noise, the only noise I could hear was my Ninja which was recording the HDMI output. Yes, it is early days and I supposed it will take a short while for things to filter through.

The real problem for me is that if this is an Apple issue I cant afford to wait, as I have another 12 days to return the Mini if I'm not happy with it. I had another repeatable problem just over a year ago with the M1 Max MacBook Pro. When in mirroring mode it would hang and crash when playing video media. After unnecessarily swapping out the main board, which resulted in the same issue and was therefore proof of a global issue. Apple admitted the problem existed and said I would have to wait for an update, they were really vague. Anyway, yes that issue did get sorted but it took more than 11 months.

So yes, I don't doubt that certain Apple issues may get fixed but I cant take the risk after buying a new product, that any issues may take a long to get fixed. I'm also quite weary of certain issues maybe being related to other issues and more so when I have an older devices that doesn't exhibit the same issue.

Cheers,
Dave.

...M4 Pro is 14 CPU cores, 20 GPU cores, 48GB RAM, 1TB storage.

So I’ve got a simple test to stress out the encoder. It’s 8K/UHD 119.88 for the media, timeline and output, basically NTSC 8K/120.

The basic export settings are: Apple encoder, H.265, two pass, auto bitrate, not optimised for speed, Main10.

I have just tried exporting 3 times and every time I get a crash on the second/encode pass...

David, I'll have the same machine (except 4TB SSD) by tomorrow, Nov. 11. I'll test your scenario then. It seems relatively straightforward. I also have the M1 Max MacBook Pro 16, so I'll compare to that.

Your screen recording showed an apparent MacOS crash to the login screen. That implies it's not a kernel panic but more than an app crash. One possibility is a GPU timeout resulting in the WindowServer process restarting, then you see the login screen. That should never happen, no matter what the app does.

Your scenario is very straightforward and you described it clearly. If it is a Resolve issue on that machine running that workload, I should be able to reproduce it. If I can't reproduce it that could imply a machine-specific problem. I'll post an update ASAP.

That's great Joe, thanks.

It would be great to have someone with the same setup try this out. I doubt the SSD has anything to do with this issue.

Here's a link to a video showing the issue, if you wouldn't mind testing with the same source and destination codec settings, that would be great. You can just use anything to scale to 8K for the resolution of the source, the issue obviously has nothing to do with the optical resolution. However, I think temporally it may have to be 119.88FPS or maybe 120. As I have a feeling that padding something like 59.94 may not be enough, as I think the extra work involved with the high temporal resolution may be a contributing factor if it's something stress related leading to the hang and crash.

Thanks again and I look forward to your results. It may even be the case that I may need to swap my Mini.

Cheers,
Dave.

You can observe the temperature closely with TG Pro, which will work for a few days without buying it.
Not hearing your fan at all with such demanding clips may point to a defective fan.

You can observe the temperature closely with TG Pro, which will work for a few days without buying it.
Not hearing your fan at all with such demanding clips may point to a defective fan.

The fan is definitely working, the Ninja’s fan was just louder and more noticeable. Plus, it depends on what is being taxed during the encode. As far as I’m aware, it’s the encoders doing most of the donkey work and they’re probably nowhere near the power usage of the CPU and GPU. People complaining of the fan noise are probably battering the CPU and GPU, maybe with all those pointless benchmark test and nothing real-world, like video editing. Resolve would definitely trigger the higher fan speeds but that’s likely to be for effects, colour, 3D and full rasterisation of outputs/renders etc.

The menu app Stats is free and works with infers to monitor all tempt, data etc.

https://github.com/exelban/stats

You can observe the temperature closely with TG Pro, which will work for a few days without buying it.
Not hearing your fan at all with such demanding clips may point to a defective fan.

Hi, Uli.

It's defo not a temp thing. Unfortunately, it looks like Resolve.

I have tried with a UHD/60 source and the two pass on Main10 H.265 is producing corrupted files. Not sure about 4:2:2 or H.264 as I haven't tried them.

Also, the encoder is significantly slower on M4 Pro vs M1 Max, 61FPS vs 99FPS at UHD.

It's very similar to that problem I reported with 10Bit 4:2:2 two pass, that required a Resolve fix.

Anyway, there's a good starting point for anyone at BMD who can be bothered.

...It's defo not a temp thing. Unfortunately, it looks like Resolve.

I have tried with a UHD/60 source and the two pass on Main10 H.265 is producing corrupted files. Not sure about 4:2:2 or H.264 as I haven't tried them...

David, I just got my M4 Pro 14c CPU / 20c GPU 48GB Mac Mini set up and am running your test. I did exactly your procedure: upscaled UHD 8k/119.88 fps ProRes 422 HQ, Resolve Studio 19.03, MacOS Sequoia 15.1. I took frame grabs of your Youtube video to ensure I had the exact same Resolve project, timeline and export settings. I'm exporting to the desktop just like you. Mine has no effects or edits on the file. It's Rec.709 and I'm not using Resolve Color Management.

So far, it is not crashing, but I've only done three 90 sec exports using multi-pass.

I noticed one difference between your Youtube video vs what I'm seeing: your export frame rate to 8k/119.88 H.265 was only about 16 fps. Mine is 23.5 fps.

That is a 47% difference -- but the machines and configs should be identical, except mine has 4TB SSD, which should make no difference. The ProRes 422HQ media file is on a Samsung T7 SSD, but I also tried it on the internal M4 Pro SSD. It made no difference.

Edit/add: the exported 8k/119.88 fps H.265 files play OK with no apparent defects.

Probably like you, I did a fresh Resolve Studio 19.0.3 install on the M4 Pro. There are no plugins, utilities or other third-party software on it -- UPS just delivered the machine three hours ago.

If possible, I suggest you try it without any external SSD. That's all I can think of. If that does not show a difference, maybe your machine is defective?

If you can send me your ProRes 422HQ test file I will try it on my M4 Pro: https://www.dropbox.com/request/K0eBx2qOPr90APw4RvO0

...It's defo not a temp thing. Unfortunately, it looks like Resolve.

I have tried with a UHD/60 source and the two pass on Main10 H.265 is producing corrupted files. Not sure about 4:2:2 or H.264 as I haven't tried them...

David, I just got my M4 Pro 14c CPU / 20c GPU 48GB Mac Mini set up and am running your test. I did exactly your procedure: upscaled UHD 8k/119.88 fps ProRes 422 HQ, Resolve Studio 19.03, MacOS Sequoia 15.1. I took frame grabs of your Youtube video to ensure I had the exact same Resolve project, timeline and export settings. I'm exporting to the desktop just like you.

So far, it is not crashing, but I've only done three 90 sec exports using multi-pass.

I noticed one difference between your Youtube video vs what I'm seeing: your export frame rate to 8k/119.88 H.265 was only about 16 fps. Mine is 23.5 fps.

That is a 47% difference -- but the machines and configs should be identical, except mine has 4TB SSD, which should make no difference. The ProRes 422HQ media file is on a Samsung T7 SSD, but I also tried it on the internal M4 Pro SSD. It made no difference.

Edit/add: the exported 8k/119.88 fps H.265 files play OK with no apparent defects.

Probably like you, I did a fresh Resolve Studio 19.0.3 install on the M4 Pro. There are no plugins, utilities or other third-party software on it -- UPS just delivered the machine three hours ago.

If possible, I suggest you try it without any external SSD. That's all I can think of. If that does not show a difference, maybe your machine is defective?

If you can send me your ProRes 422HQ test file I will try it on my M4 Pro: https://www.dropbox.com/request/K0eBx2qOPr90APw4RvO0

Hi, Joe.

That's awesome, thanks for testing and thanks for all the detail. I really appreciate it.

Your 3 90 second clips would easily have been enough to show the issue if it was there.

That difference in frame rate processing is wild. This would definitely not be the difference between sourcing from an external SSD and the internal. As the speed of the encode is slower than the read bitrate of the SSDs anyway.

Have you got optimised for speed ticked on? This could explain the faster speed. If not, it could suggest that my Mac is broken.

However, I have just found the source for one of the problems I'm having and I think this will also have a bearing on the 8K crash problem I am having.

Have a look at this video if you don't mind, it shows the issue where the export is corrupted. This is actually very similar to another issue I reported on with the exporter a while, which BMD eventually fixed but without acknowledging the issue as a bug.

Would you mind testing this scenario please? This is a much easier test and quicker.

Thanks again, Joe.

Cheers,
Dave.

Thanks to both of you for trying to get to the bottom of this. I'm eyeing just the same machine.

...Have you got optimised for speed ticked on? This could explain the faster speed. If not, it could suggest that my Mac is broken....Have a look at this video if you don't mind, it shows the issue where the export is corrupted....

Yes I had optimized for speed on, Main 10, multi-pass encode, just like you. I'll try the variations mentioned in your new Youtube video, which is export from .mov to UHD 4k/59.94 Main 10 H.265 with/without "optimize for speed." I'll also try with/without multi-pass, and for each combination, I'll check the output file.

I'm very suspicious about your export frame rate being so much slower than mine. Our input files, output files and export parameters were the same, we aren't using any Fx, and we have essentially the same machine and same software config.

...Have you got optimised for speed ticked on? This could explain the faster speed. If not, it could suggest that my Mac is broken....Have a look at this video if you don't mind, it shows the issue where the export is corrupted....

Yes I had optimized for speed on, Main 10, multi-pass encode, just like you. I'll try the variations mentioned in your new Youtube video, which is export from .mov to UHD 4k/59.94 Main 10 H.265 with/without "optimize for speed." I'll also try with/without multi-pass, and for each combination, I'll check the output file.

I'm very suspicious about your export frame rate being so much slower than mine. Our input files, output files and export parameters were the same, we aren't using any Fx, and we have essentially the same machine and same software config.

Hi, Joe.

Optimised for speed should not be switched on. This is likely to be what’s causing the speed difference.

Cheers,
Dave.

Uli and Joe.

Just an update.

I had looked for an update earlier today but my system wasn’t saying one was available. I just checked again about half an hour ago and 19.1 build 12 was available. So I’ve just installed that.

My issue with corrupt media is still happening. I’ve not tested the crash scenario with 8k/120 as I’ve been on a late one editing some client stuff and it’s now nearly 4 in the morning and I need my bed

As soon as I’ve tested the 8K/120 I’ll report back on it.

Also, nothing else changed with regard speed after the update.

Cheers,
Dave.

My issue with corrupt media is still happening...

OK I see the damaged output file. This was using 4k/59.94 ProRes422 HQ source and exporting to 4k/59.94 Main10 H.265, with "Optimize for Speed" off and multi-pass on.

I tested all 4 combinations of the optimize for speed and multi-pass settings, and only that caused it. I never saw a crash, hang or any other problem, but the fact it's damaging the output file is bad.

I tried it with hardware acceleration off, and it still happened. I then repeated the same test with the same file, software versions, Resolve config and export settings on my M1 Ultra Mac Studio. It didn't happen there.

I also have an M2 Pro Mac Mini, and I'll try that tomorrow. However, it's starting to appear like a platform-specific Resolve issue, which is what you said from the beginning. The question is whether it's limited to the M4 Pro or does it also happen on the M4 and M4 Max.

I'll examine the MacOS and Resolve logs tomorrow.

My issue with corrupt media is still happening...

OK I see the damaged output file. This was using 4k/59.94 ProRes422 HQ source and exporting to 4k/59.94 Main10 H.265, with "Optimize for Speed" off and multi-pass on.

I tested all 4 combinations of the optimize for speed and multi-pass settings, and only that caused it. I never saw a crash, hang or any other problem, but the fact it's damaging the output file is bad.

I tried it with hardware acceleration off, and it still happened. I then repeated the same test with the same file, software versions, Resolve config and export settings on my M1 Ultra Mac Studio. It didn't happen there.

I also have an M2 Pro Mac Mini, and I'll try that tomorrow. However, it's starting to appear like a platform-specific Resolve issue, which is what you said from the beginning. The question is whether it's limited to the M4 Pro or does it also happen on the M4 and M4 Max.

I'll examine the MacOS and Resolve logs tomorrow.

That’s awesome, Joe. Thanks.

With your independent testing resulting in the same outcome as far as the corrupt exports are concerned. I’d say that’s all the proof needed to say that this is a platform specific bug. It’s very unlikely that we both have broken Macs.

One of my friends is going to bring his M4 Mini to mine for testing. So I can at least see if the issue extends to M4.

On a side note. I’m actually quite disappointed with the M4 Pro. My M1 Max is doing certain things faster and it’s considerably faster at exporting.

I’m not getting any better GPU performance from the M4 Pro but I already knew that would be the case. All the usual Apple shills are showing useless benchmarks that are saying the 20 GPU cores on the M4 Pro are only slightly behind the 32 on the M1 Max. However, this is why most of these benchmark tests are compete BS and a waste of time. As my experience so far and from what I can see in my system monitoring, is showing the M1 Max to be appreciably better in particular tasks.

I’ve no doubt that the CPU performance will be noticeably better on the M4 Pro. However, I’m not entirely sure which of my daily tasks are CPU bound. I also don’t know what the split is between GPU and CPU in my use of Resolve. So can’t really say that the M4 Pro is gaining me performance in any particular tasks.

One thing is for sure though, the slower export speeds on the M4 Pro are something I definitely can’t live with. If my timeline processing was the bottleneck, then yes, the extra CPU grunt from the M4 Pro, if CPU is the bottleneck. Would result in the difference between the timeline needing processing in the M1 Max and not on the M4 Pro. Which could then result in faster exports, as although the M4 Pro has a slower encoder, if it’s a lot faster than the M1 Max in the timeline, then the timeline render/buffering difference of the M1 Max could result in the M4 Pro having an overall faster export as its feeding the main timeline video buffer into the encoder a lot faster.

The M1 Max higher memory bandwidth will also come into play as well. Although I’m not sure if Resolve takes advantage of the extra video accelerators on the M1 Max. If it does, this could also be helping the timeline in certain instances of mixed codecs and multiple simultaneous instances of video tracks

My instinct would have been to send it back but I’m being sent a Thunderbolt 5 dock and TB5 NVMe enclosure to review. Plus some other peripherals including some stuff for some iPhone 16 Pro Max, BMD camera app and Resolve workflows, using M4. So I’m kind of stuck with it until the M4 Studios come out.


Anyway, thanks for testing and let’s hope these issues are sorted soon.

Cheers,
Dave.

I see the same corrupted video rendering on my M1 Max (see my signature). This is not new, I believe and certainly not just an M4 issue. The crashing / hanging does not happen for me, though. I think the answer previously is 'don't use multi-pass'. Not very satisfying an answer, though.

Add - If I put a checkmark in the 'Optimize for speed' option, my output is just fine. I guess that what you folks saw as well. Either that or don't use multi-pass encoding.

I see the same corrupted video rendering on my M1 Max (see my signature). This is not new, I believe and certainly not just an M4 issue. The crashing / hanging does not happen for me, though. I think the answer previously is 'don't use multi-pass'. Not very satisfying an answer, though...

I just tested the 4k/5994 export to Main10 HEVC with multi-pass on and "optimize for speed off" on my M1 Max MBP 16 using Resolve Studio 19.03 and MacOS Sonoma 14.71 and the damaged output didn't happen. I'll update it to Sequoia 15.1 and try it. It happens 100% of the time with Resolve 19.03 and Seqoia 15.1 on my M4 Pro Mac Mini. I'll update that to Resolve Studio 19.1 and try it.

Dave , you may also want to watch this test from Artis right to see effects of memory and GPU cores.

I'm on Sequoia 15.0.1 and Studio is 19.0.3 Build 5 with my M1 Max MBP and don't have the problem of corrupted outputs or crashing 8K/120.

Don't forget, it looks like the corruption issue is independent of source/project resolution and frame rate.

Dave , you may also want to watch this test from Artis right to see effects of memory and GPU cores.

Alright, Ron.

Good to hear from you and I hope you are well. Are you still using Edius? I've not visited the GV forum for ages so don't even know where Edius is up to. I sold my last Windows workstation earlier this year, so unless Edius ever goes to Mac I doubt I'll ever see it again. Not that you are into gaming but I'm mostly on PS5, iOS and Android for my gaming, so again, no powerful Windows machine for gaming so no chance of slipping back as far as my NLE is concerned.

I did try Resolve on my last Windows machine and while it was way more powerful on the GPU side of things compared to any of my Macs. My workflow really suits Resolve on Apple Silicon and I'm much happier with a computer I can't hear and one that doesn't need Sellafield to power it.

I took a quick look at that video, thanks. Unfortunately for me, it wasn't very specific and I'm not really into looking at multiple graphs, especially benchmarks. I much prefer watching videos that show all the setup details etc. and specific real-world tests. I couldn't really find anything in that video about specific memory and GPU core stuff being directly compared between machines on specific tasks. Maybe it was there, but I didn't find it scanning through his chapters.

As for GPU and memory. For my specific uses between M1 Max and M4 Pro, I'm building up data across a number of real-world edit scenarios that I do every day and to be honest it's not looking good for the M4 Pro. My observations are in stark contrast to a lot of other YouTubers, a lot of whom seem to be fixated on benchmarks and graphs, as opposed to real-world tasks. I simply wont watch anything that's doing Blender or Geekbench tests, these things have no bearing for the vast majority of daily uses for NLE users and their results are far from the whole story.

I should really have gone for the M4 Max MBP for the obvious processing gain. However, I didn't want to buy another laptop just to stick it under the table on a dock connected to a monitor to be used as a desktop. The base M4 Mac Mini is a great buy but the M4 Pro starts suffering due to the lack of bandwidth and video accelerators and GPU cores (even if they are more powerful on a per core basis), compared to the older Max machines. The problem I've got is that I've committed to a bunch of manufacturers for reviews using Thunderbolt 5, so can't send this Mini back to Apple.

I'll just have to get on with what I've got for now and wait for the Studios to come out. As I'm likely to be on a three year cycle, if the Ultra is more monolithic this time around with M4, compared to gluing two Maxes together, or maybe something else that scales more linearly. Then I think fleecing my bank account for the Ultra may be the way to go. If not, I definitely know the M4 Max will be an appreciable step up from my M1 Max.

Anyway, Ron. Once again, it's good to hear from you and I hope you are keeping well.

Take care buddy.

Cheers,
Dave.

Quick update:

M1 Max MBP, Studio 19.1 build 12, macOS 15.0.1. No corruption. Will now update macOS.

Hi Dave . No EDIUS for a long while. Just sometimes use for Bluray encode interlace that I find good compatibility with DVDArchitect I use for authoring.

Interesting part of that video I posted was it was completely done using applications not tests. Clear to me was that even the old M2 Studio Max had a good showing against the M4Pro. GPU cores and memory is what is important rather than single core performance that may be great for games of course !! It is in this area that a PC wins of course. For me my M1 Studio Max is fine for editing but often move project to PC for encode as the 4070Ti is a lot more powerful than the GPU in the M1 and NVIDIA also have hardware encoders. Looking at prices in Canada a kitted out M4 Pro Mini is about the same price as a M2 Studio Max that for some encodes may be faster and stay cooler with less fan noise. The killer unit may well be an M4 Studio Max as long as they do not cost any more than they do now !!!

UPDATE:

M1 Max MBP, Studio 19.1 build 12, macOS 15.1. Basically, everything as up to date as possible as of today, 12/11/24. My files are now corrupting on the export, so the same issue as I'm having on my M4 Pro.

Why oh why did I update when Steve already said that this would happen

One thing, though, my export frame rate has gotten a bit faster, 99/100FPS to 102/103FPS

I will try the 8K/120 project later on my M1 Max and see what's going on with that.

UPDATE:

M1 Max MBP, Studio 19.1 build 12, macOS 15.1. Basically, everything as up to date as possible as of today, 12/11/24. My files are now corrupting on the export, so the same issue as I'm having on my M4 Pro...

David, I just updated my M1 Max MBP16 to those versions and I didn't see it. Just to confirm, that is 4k/59.94 ProRes422 HQ source files and you are exporting from a 4k/59.94 timeline to 4k/59.94 Main10 H.265? You have no Fx, edits or retiming on the timeline? I don't think there should be background rendering in that case, but I turned off background rendering in the project. However I did lots of tests before that and I didn't see any before/after difference.

You are correct about the M4 Pro performance being significantly slower than an M1 Max at H.264/H.265 video exporting. I'm confused because in our test case there should be no real GPU load, and the M4 Pro CPUs are faster. It should be an encode-limited task. I didn't think the dual encoders on the M1/M2 Max/Ultra could be used for single-stream Long GOP, outside of some narrow cases.

However, FCP 10.7 and Compressor in November 2023 were updated with "segmented encoding" whereby Apple Silicon CPUs with multiple H.264/H.265 encoders could use those in parallel in some cases. I suspect there was an underlying improvement to the VideoToolbox framework to enable this, but it wasn't documented.

In recent years Resolve has essentially equaled or exceeded FCP performance in many cases, especially encode tests. It's plausible that Resolve also uses segmented encoding on Macs with multiple encoders. If so that might explain why a pure H.264/H.265 encoding test is significantly faster on M1 Max than M4 Pro.

I examined my Resolve and MacOS logs during one of the corrupted output cases, and I don't see any apparent related errors. I'll go ahead and attach my Resolve logs in case a BMD person wants to examine them. There are tons of "noise" errors and messages, but that is typical on any platform.

I will test the scenario on an M2 Pro and re-test on my M1 Max.

UPDATE:

M1 Max MBP, Studio 19.1 build 12, macOS 15.1. Basically, everything as up to date as possible as of today, 12/11/24. My files are now corrupting on the export, so the same issue as I'm having on my M4 Pro...

David, I just updated my M1 Max MBP16 to those versions and I didn't see it. Just to confirm, that is 4k/59.94 ProRes422 HQ source files and you are exporting from a 4k/59.94 timeline to 4k/59.94 Main10 H.265? You have no Fx, edits or retiming on the timeline? I don't think there should be background rendering in that case, but I turned off background rendering in the project. However I did lots of tests before that and I didn't see any before/after difference.

You are correct about the M4 Pro performance being significantly slower than an M1 Max at H.264/H.265 video exporting. I'm confused because in our test case there should be no real GPU load, and the M4 Pro CPUs are faster. It should be an encode-limited task. I didn't think the dual encoders on the M1/M2 Max/Ultra could be used for single-stream Long GOP, outside of some narrow cases.

However, FCP 10.7 and Compressor in November 2023 were updated with "segmented encoding" whereby Apple Silicon CPUs with multiple H.264/H.265 encoders could use those in parallel in some cases. I suspect there was an underlying improvement to the VideoToolbox framework to enable this, but it wasn't documented.

In recent years Resolve has essentially equaled or exceeded FCP performance in many cases, especially encode tests. It's plausible that Resolve also uses segmented encoding on Macs with multiple encoders. If so that might explain why a pure H.264/H.265 encoding test is significantly faster on M1 Max than M4 Pro.

I examined my Resolve and MacOS logs during one of the corrupted output cases, and I don't see any apparent related errors. I'll go ahead and attach my Resolve logs in case a BMD person wants to examine them. There are tons of "noise" errors and messages, but that is typical on any platform.

I will test the scenario on an M2 Pro and re-test on my M1 Max.

Hi, Joe.

Just to be clear. For the corrupted file output, it does not seem to matter what the files are in the timeline, as far as codecs resolution and frame rates are concerned and it does not seem to matter what the project/sequence resolution and frame rate are. I have tried a number of different project settings and different source media and they will all result in corrupted outputs given a particular mix of macOS and Resolve, that being macOS 15.1 and Resolve Studio 19.1 but I suspect that the free version will also have an issue with macOS 15.1.

An to be clear about the output codec settings that cause the corruption with the dodgy mix of macOS and Resolve, here's the settings:

H.265, two pass, optimised for speed turned off, Main10.

With the corrupted output, bitrate, resolution and frame rate don't make a difference, the file will corrupt regardless of these variables. Now the above settings are for a 10 Bit 4:2:0 output. However, the corruption may also happen with Main/8 Bit, Main 4:2:2 10/10 Bit 4:2:2, I have not tried. The corruption may also happen with other inter-frame codecs that use a two pass, I don't know I have not tried.

As for the M4 Pro. Yes, it's noticeably slower than the M1 Max for pure transcoding/exporting.

Yes, you are correct. In our tests the GPU isn't really being hit, neither is the CPU. We are essentially using Resolve as a transcoder/encoder. So yes, because we aren't processing we are testing the hardware encoders.

Now this is where I am also confused. As far as I was aware, the extra encoders in the M1 Max did not get used together for a single encode. As in, there is no serial or parallel use of two encoders for the one encoding task. Now if this is the case and only one encoder is used, then why is it faster than the encoder on the M4 Pro? I think this is what you are also questioning.

I am unaware of compressor using the encoders in parallel, as I don't use the Apple stuff. However, it would make sense for Apple to do this, seeing as it's their hardware and software. Comparing the speed of the M4 Pro encoding to the M1 Max encoding, it feels like the difference is because of the dual encoders but as we've both said, we're not aware that Resolve does that. If Resolve is indeed utilising the multiple encoders on the M1 Max, then it's done this from the start, as it's always been that speed.

Yes, I doubt your logs will show an error, as there isn't really an "error" scenario occuring. As far as I'm aware, Resolve wont be doing anything wrong as far as it's concerned, so nothing to report. It may still be the case that Resolve isn't doing anything wrong. This could all be because Apple have changed something in an API or something. Who knows?

So, on the point of, who knows? That leads me onto some very obvious criticism of Blackmagic and why I made that comment earlier in this post that I was accused of being insulting about.

Blackmagic you people should be completely ashamed of yourselves. You are observing this post and not even helping. Seriously, you've got at least three dedicated users who have paid for your software, fault finding for you. I say at least three, as there may well be others who are trying things because of this post but don't want to join in the post, which is totally understandable because of all the people who are quick to attack. Sometimes, it's just an easier life if you keep your mouth shut and I don't blame anyone for avoiding the obvious confrontation and wrongful accusations you can get on open forums.

Blackmagic, you people should be at least joining in to stop us from wasting our time testing things that you guys know will not work. Seriously, updating an OS, updating and uninstalling and going backwards with Resolve is time consuming and that's before you start testing. Keeping logs of what you've done and the small incremental changes to the scenarios, in any methodical process of elimination, is very time consuming. But you people know this.

Let's face it. The issue being discussed here is hardly a minor one and it is now being proven to span multiple iterations of Apple Silicon. A slow two pass H.265 output is very common and to be hit with that issue, unexpectedly, after completing an edit, is hardly a good look for Resolve or BMD.

It really does feel like we are just unpaid beta testers, who are paying for the pleasure, both finically for those of us who buy Studio and loads of BMD hardware and we also pay with our precious time.

Anyway, Joe. This is the reason why I stopped sending logs and detailed fault reports a long time ago. I've got no time for helping anyone who cant even reciprocate with some basic curtsy. I'm only here to try and help other users.

BTW, Joe. You say you've now updated your M1 Max MBP and it's the same as what mine now is but yours is not producing the corrupted files and mine is. Maybe this is suggesting other factors that can have a bearing on the final output? Maybe BMD know the answer to that one and would like to help out? And yes, my timeline is clean, no FX, scaling, extra processing etc. Just a straight in and out.

Cheers,
Dave.

Can you explain to me why you are using 2 pass encoding ? To me two pass is useful using software encoding using the CPU, for lowest data rate VBR ( file size ) and where the encoder can, on second pass, manage bit rates to optimize the total encode. Not sure how this is managed for a hardware encoder. I never use two pass for hardware encodes. When I need the best encode, say to fill DVD that is long I encode with TMPGenc MW7 VBR on the PC. Is this issue a hardware encode issue for two pass. Are the files corrupted with CPU encoding only ?

Can you explain to me why you are using 2 pass encoding ? To me two pass is useful using software encoding using the CPU, for lowest data rate VBR ( file size ) and where the encoder can, on second pass, manage bit rates to optimize the total encode. Not sure how this is managed for a hardware encoder. I never use two pass for hardware encodes. When I need the best encode, say to fill DVD that is long I encode with TMPGenc MW7 VBR on the PC. Is this issue a hardware encode issue for two pass. Are the files corrupted with CPU encoding only ?

For the exact same reason why you'd use it for a software encoding. Hardware or software, it doesn't matter, the function is the same. It works really well for picture quality using the auto bit rate for a lot of uses where I don't have the time to test for optimum bit rates and need to keep the file sizes down. I don't use two pass or inter-frame codes for my masters. Anyway, its all academic as I can't use it now anyway

I think someone said the issue happens with the software option as well.

UPDATE:

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

It looks like macOS 15.1 being in the mix is when the fun starts. I can confirm the problem is on my M1 Max MBP and my M4 Pro Mini. I have two more Macs with different configurations but don't have the time to test them.

It seems to be MacOS 15 (Sequoia). No issues on several machines with Sonoma 14.7.1.
Unfortunately, Apple forces 15 on you with the new machines. But wait, sometimes not, depending on development cycles. Might be worth trying to install Sonoma to an external disk and boot from there.

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).

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.

You are right, but it depends.
I have seen models which were initially sold with a brand-new system, but worked with the version before. One can only try.