Frame error and video Artifacts After updating Mac OS 13.4

Hi there,

Am on m1 max with DRS 18.1.4, after updating to Mac Os 13.4 i can't properly export h265 422 main 10 files (after exporting it video freeze in certains points while it is playin both in QT and VLC, there are Artifacts also like digital glitches). The issue disappear if i export in h264 or ProRess. Before updating OS i did not have problem at all.

Checking on my DRS log i saw:

Code: Select all

0x2a04b3000    | SyManager            | ERROR | 2023-05-18 22:13:00,604 | There is no current clip, SetCurrentFrame failed.

Any ideas?

Ty in advance!

Is this h265 in a QuickTime container (MOV file)?

Is this h265 in a QuickTime container (MOV file)?

Yes

I'm hoping someone else will confirm this. I haven't updated to Ventura 13.4 yet - I'd like to leave it for a bit to see what happens but at some point I'll try it.

The issue seems to be related to h265 codec doesn't really matter the container (.mov or .mp4)

I backed-up my system and went ahead with the Ventura 13.4 update. Back in Resolve I took a short UHDp29.97 timeline and exported h265 422 10-bit QuickTime - no problems with playback. Seems to be fine. This is under Resolve Studio 18.5 b2.

I backed-up my system and went ahead with the Ventura 13.4 update. Back in Resolve I took a short UHDp29.97 timeline and exported h265 422 10-bit QuickTime - no problems with playback. Seems to be fine. This is under Resolve Studio 18.5 b2.

Good to know, but indeed am bit scared about using Beta Release software on production machine, but may i’ll backup my DB and give a try to DRS 18.5.X

Even after give a chance to DRS 18.5 B2 the problem is still there, it's a bit better than previously but still there are freezing frame on the exported file. The issue disappear if you are exporting with h264 codec

Can you post an image of your export settings?

I used the default H265 Master preset that ships with Resolve and didn't have any issues. Also tried changing from main10 to the main 422 10 encoding profile - still no issues. This was only on a 10 second timeline. Maybe it needs to be much longer?

Add - took the same 10 second sequence and duplicated it to produce a 10-minute sequence and then exported as above and still looks fine. Maybe all include your timeline settings and source information?

Hopefully someone else will be able to reproduce what you are seeing.

Can you post an image of your export settings?

I used the default H265 Master preset that ships with Resolve and didn't have any issues. Also tried changing from main10 to the main 422 10 encoding profile - still no issues. This was only on a 10 second timeline. Maybe it needs to be much longer?

My export setting are just h 265 Main 422 10 bit, limited to 19000 kb/s, may you can try export one minute or more of video and see what happens. Anyway if i export h264, or ProRes, everything works as expected.

Are you saying that the only changes you made to the default exhort setting 'H265 Master' is to change it to Main 422 10 and then quality from 'automatic' to 19000 kbps? You didn't change anything else such as 'Optimized for speed' or the keyframe interval?

What is your timeline resolution (export resolution) and frame rate?

Add - I tried your settings on an UHDp29.97 10 minute timeline - no problem playing in QuickTime.

Are you saying that the only changes you made to the default exhort setting 'H265 Master' is to change it to Main 422 10 and then quality from 'automatic' to 19000 kbps? You didn't change anything else such as 'Optimized for speed' or the keyframe interval?

Exactly, my timeline resolution is 1920x1080, 25p

OK - I'll give that a try at some point with exactly a 1080p25 timeline. My guess is that there is something else going on with your system that causing this issue but you never know - 25p may be the difference.

OK - I'll give that a try at some point with exactly a 1080p25 timeline. My guess is that there is something else going on with your system that causing this issue but you never know - 25p may be the difference.

I don't know what it could be, I have two M1 Max (Studio and MBP 14) and on both i have same issue. If I export in h264 or ProRess I have no problem at all

I can't reproduce that issue, but then, I always have "Frame reordering" switched off. Did you try that?
Or could it be an issue with the M1 Max? I got the M1 Pro here.

I can't reproduce that issue, but then, I always have "Frame reordering" switched off. Did you try that?
Or could it be an issue with the M1 Max? I got the M1 Pro here.

Thanks I didn't solve the problem but I discovered a few things:

Source video Codec:

1 - Video Codec
H.264 High 4:2:2 L5.1
Frame Rate
25.000
Audio Codec
Linear PCM
Sample Rate
48000
Resolution
3840 × 2160

2- Video Codec
H.264 High L4.0
Frame Rate
25.000
Sample Rate
Resolution
1920 × 1080

First Test - Frame Reordering Off - Quality Limit to 19000 Passed
Second Test - Frame Reordering Off - Quality Limit to 19000 Passed
Third Test - Frame Reordering Off - Quality Limit to 50000 Failed
Fourth Test - Frame Reordering Off - Quality Limit to 19000 Failed
Fifth Test - Frame Reordering Off - Quality Limit to 19000 - optimize for speed On - Passed
Sixth Test - Frame Reordering Off - Quality Limit to 50000 - optimize for speed On - Failed
Seventh Test - Frame Reordering Off - Quality Limit to 19000 - optimize for speed On - Failed
Eighth Test - Frame Reordering Off - Quality Limit to 19000 - optimize for speed On - Passed

Let's try to disable Hardware Acceleration for Export:

First Test H265 Main 422 10 Bit Frame Reordering Off - Quality Limit to 19000 Failed because can't Export:

"Render Job 69 failed as the current clip could not be processed.
Cannot find appropriate code for encoding the video frame."

Second Test H264 Econding Profile Auto - Entropy mode Auto - Frame Reordering Off - Quality Limit to 19000 Passed

Hi there,

Am on m1 max with DRS 18.1.4, after updating to Mac Os 13.4 i can't properly export h265 422 main 10 files (after exporting it video freeze in certains points while it is playin both in QT and VLC, there are Artifacts also like digital glitches). The issue disappear if i export in h264 or ProRess. Before updating OS i did not have problem at all. But I do hope Blackmagic take a serious look at this as it’s affecting a large number of people by the looks of it!

Checking on my DRS log i saw:

Code: Select all

0x2a04b3000    | SyManager            | ERROR | 2023-05-18 22:13:00,604 | There is no current clip, SetCurrentFrame failed.

Any ideas?

Ty in advance!

I can confirm I am having the exact same issues. Looking at the Apple forums, people are having issues in Final Cut too, but with the video not showing at all and audio only playing with certain codecs. I have a feeling this is an issue with MacOS 13.4 and not Resolve, though I'm hoping Blackmagic will take a serious look at this.

@ameDSL - it would be helpful to know what system you are running, E.g a MacStudio etc..

How long are your videos and what are your exact timeline settings? I tried this with a 10 minute UHDp23.967 timeline on my MacBook Pro and can't reproduce the issue. Very strange.

One thing that occurred to me is that I also have Compressor installed with the associated Pro Video Formats codec pack - I don't know if the codec pack is a standard Apple thing or if it is Compressor-specific. If this were Windows (which I'm more familiar with) I would say that other installed codecs could affect the result reported in Resolve, but with macOS I have no idea.

Normally, this pack comes with either program.

I have this exact same issue. I don't think it was the OS update. I think it was the Pro Codecs update, because I have the same problem exporting h165 from all adobe apps and Apple's Compressor too. This looks like an Apple problem.

Did you update after the new version of FCP-X (10.6.6) came out?

I can confirm two things. First, this issue is not only related to Davinci Resolve Studio, as I have encountered the same problem with Apple Compressor. Second, the problem is not related to Apple's Pro Video Formats because I have manually uninstalled them, and the issue still persists. The only variable, compared to when everything was working correctly, is the update to macOS 13.4. The only way to export a file without issues at the moment is to use the h264 codec (or ProRes). With h265, you might get lucky if you manually set the Key Frames (for example, Every 15 frames), disable Frame Reordering, and turn off "Optimize for speed". But it's a matter of "luck," as even with these adjustments, you might still encounter glitches. We'll have to wait for a patch from Apple... or perhaps a fix from Blackmagic?

PS Even DRS 18.5 have the same issue

Does it happen with HandBrake too?

Does it happen with HandBrake too?

I haven't tried yet, but I just want to be able to work peacefully. I also want to give my feedback to Apple or Blackmagic, but 99% of the time, the customer support of both companies seems more interested in figuring out what the user is doing wrong rather than checking with the development department. The problem will definitely be resolved, in a few months, It has happened in the past and it will happen this time too.

Of course, it's important that BM knows about it (and may communicate it to Apple), so everybody who can confirm should chime in. I intended to add a workaround, but also check if it might be rather on Apple's side.

I seem to remember, that there was an official Pro Video Formats Codepack update recently (can't remember when). The update happened AFTER my update to MacOS 13.4 and some time AFTER the most recent FCPX/Motion/Compressor updates.

I haven't experienced any h265 or h264 rendering problems as such recently (14 inch MacBook Pro M1 Pro 16GB, 1TB), but that may be coincidence, since the latest FCPX upgrade made noise reduction in 5.9k 12-bit ProRES RAW nearly as fast as in DaVinci Resolve Studio (for my 4444 transcoded material).

Recent test sequences rendered both via Compressor (my goto method for Apple Products currently) and DaVinchi Resolve Studio 18.1.4, showed no significant difference in behaviour, except that it was very difficult to near impossible to force rendering DaVinci results into very high bitrates targeting h265, 10bit 422 HLG 25fps.

It posed no problem rendering the same material, with similar (simple) setup via FCPX and Compressor.

DaVinchi Resolve Studios "resistance" to rendering very high bitrate h265 output is no a new phenomenon on my machinery (again involving my source media from Panasonic S5, from ProRES RAW (transcoded to ProRES 4444 before use in DaVinchi) over ProRES 422 down to h265 10-bit 4:2:0 Rec 709 Vlog (5.1k internally) 29.97 fps and more standard h264 4k 10-bit 4:2:2 2020 HLG 25 fps.

Input media seems to have no influence.

Whether I hit the same "soft spot" as you (in a milder form) or not, is hard to say.

Just my report from the recent experiences in the trenches.

Regards

It might be Ventura. If you want full flexibility for final transcode to H.265, HandBrake is a good alternative.

I solved the problem by using FCPX/Compressor instead of DaVinchi Resolve Studio on the same machine (so it is probably not related to Ventura), where that was a feasable solution. In other cases I deduced, that the target audience wouldn’t notice anyhow, only I would know.

It is NOT a transcoding problem per se in DaVinchi Resolve. It is simply very hard to near impossible to force Studio to do a final render/delivery of the edit to high bitrate format (as described earlier).

It may be an Apple Silicon (M1 Pro pr M2 and up) and DaVinchi Resolve Studio interoperability problem, primarily, in the original posters case, but the Studio “resistance” to deliver final renders of edits into high h265 bitrates as described also existed before Ventura on M1 (lesser amount of internal codec support) - also 16GB/1TB.

I will not rule out, that the latest Apple Pro Codecs Update combined with Ventura 13.4 has had some influence.

In some projects, I had experimentally selected and used ProRES 4444 instead of ProRES 422 as Renderig codec setting in FCPX for especially high quality ProRES RAW work and grading. Just a test to see what happened. Only way to know for certain.

There was a visible difference while grading mixed material, especially when involving elements delivered as h264 and h265 10-bit 422 material, which differed visible in quality to ProRES 422 material during editing, when the Render codec in FCPX was set to ProRES 422 instead of ProRES 4444. This may have a perfectly good technical explanation; I chose the practical approach: learning by doing

In one specifically designed test project, I had the same sequence as internal h264 10-bit 422 HLG 25fps recording and simultaneous HDMI output to external ProRES 422 Atomos version. Identical content in two delivery formats. Too tempting for me.

The two versions were overlayed, and the crop on the top laver was gradually moved from left position zero to right to position 3840 and back to zero again. In one case (4444) it was impossible to see the moving crop “line” during HDR work on the MacBook Pro 14 M1 Pro (that screen is a beast). Depending on scene content (my ”video torture corner”) it was possible to clearly spot the moving “border line” between the two original formats (422).

I have the luxury to be able to “play” - ehhh - evaluate to my hearts content, when I decide to. Not everyone has that option.

Using 4444 instead of 422 on these projects has become very “choppy” during playback in edit lately, compared to earlier on same machine, projects etc (in FCPX).

Something did happen with the latest Apple updates, and Ventura certainly is and has been a royal PITA, but less so for my (!!) combination FCPX/Compressor use.

The specific “Rendering into final h265 HDR” high bitrate problem has not changed noticably in Studio. I always put it down to slight differences, development choices and “personality differences” between the two systems. They also exist on the ProRES RAW front; it’s in a way a case of knowing which poison to pick for specific projects

Regards

I solved the problem by using FCPX/Compressor instead of DaVinchi Resolve Studio on the same machine (so it is probably not related to Ventura), where that was a feasable solution. In other cases I deduced, that the target audience wouldn’t notice anyhow, only I would know.

It is NOT a transcoding problem per se in DaVinchi Resolve. It is simply very hard to near impossible to force Studio to do a final render/delivery of the edit to high bitrate format (as described earlier).

It may be an Apple Silicon (M1 Pro pr M2 and up) and DaVinchi Resolve Studio interoperability problem, primarily, in the original posters case, but the Studio “resistance” to deliver final renders of edits into high h265 bitrates as described also existed before Ventura on M1 (lesser amount of internal codec support) - also 16GB/1TB.

I will not rule out, that the latest Apple Pro Codecs Update combined with Ventura 13.4 has had some influence.

In some projects, I had experimentally selected and used ProRES 4444 instead of ProRES 422 as Renderig codec setting in FCPX for especially high quality ProRES RAW work and grading. Just a test to see what happened. Only way to know for certain.

There was a visible difference while grading mixed material, especially when involving elements delivered as h264 and h265 10-bit 422 material, which differed visible in quality to ProRES 422 material during editing, when the Render codec in FCPX was set to ProRES 422 instead of ProRES 4444. This may have a perfectly good technical explanation; I chose the practical approach: learning by doing

In one specifically designed test project, I had the same sequence as internal h264 10-bit 422 HLG 25fps recording and simultaneous HDMI output to external ProRES 422 Atomos version. Identical content in two delivery formats. Too tempting for me.

The two versions were overlayed, and the crop on the top laver was gradually moved from left position zero to right to position 3840 and back to zero again. In one case (4444) it was impossible to see the moving crop “line” during HDR work on the MacBook Pro 14 M1 Pro (that screen is a beast). Depending on scene content (my ”video torture corner”) it was possible to clearly spot the moving “border line” between the two original formats (422).

I have the luxury to be able to “play” - ehhh - evaluate to my hearts content, when I decide to. Not everyone has that option.

Using 4444 instead of 422 on these projects has become very “choppy” during playback in edit lately, compared to earlier on same machine, projects etc (in FCPX).

Something did happen with the latest Apple updates, and Ventura certainly is and has been a royal PITA, but less so for my (!!) combination FCPX/Compressor use.

The specific “Rendering into final h265 HDR” high bitrate problem has not changed noticably in Studio. I always put it down to slight differences, development choices and “personality differences” between the two systems. They also exist on the ProRES RAW front; it’s in a way a case of knowing which poison to pick for specific projects

Regards

I appreciate what you shared about your experience, but before updating to macOS version 13.4, I never, I repeat, never had such issues (of course, I had other problems with DRS, but that's normal). As an end user and professional, I just want things to work. After this experience, I will definitely start using Time Machine again, hoping they fix it within a few months. The DRS Beta 4 has the same problems, and I have the same issue with Compressor (on both the MBP 14 M1 Max and the Mac Studio M1 Max).

I think the fix is on Apple this time.

...before updating to macOS version 13.4, I never, I repeat, never had such issues...The DRS Beta 4 has the same problems, and I have the same issue with Compressor (on both the MBP 14 M1 Max and the Mac Studio M1 Max).

Can you try your problematic export using a ProRes source file? There are some known issues on FCP and Resolve with *decoding* certain 10-bit H264 formats starting with Ventura 13.4 on Apple Silicon, but not *exporting* those (I don't think). However, a decode problem might appear during an export. These are apparently problems specific to MacOS 13.4 on Apple Silicon and are not caused by bugs in FCP or Resolve.

Also, can you state exactly what camera the source files came from? The currently-known problems are: 100 fps & 120 fps 10-bit 4:2:2 Sony XAVC-S, and DJI Mavic 3 H264 5.1k 10-bit 4:2:2, *all* frame rates. Both Sony and DJI Mavic 3 cameras have equivalent H265/HEVC codecs which do not show the problem, so that's an option for new material but not for existing material.

I think the Mavic 3 Pro also has the same (or similar) 5k 10-bit 4:2:0 H264 codec, but I don't have test material for that. Likewise, there are other cameras that shoot 5k or higher resolution using H264 at 10-bit 4:2:0 or 4:2:2, but I don't have those formats to test. So far I haven't seen any reports of problems from those, only Sony and DJI.

...before updating to macOS version 13.4, I never, I repeat, never had such issues...The DRS Beta 4 has the same problems, and I have the same issue with Compressor (on both the MBP 14 M1 Max and the Mac Studio M1 Max).

Can you try your problematic export using a ProRes source file? There are some known issues on FCP and Resolve with *decoding* certain 10-bit H264 formats starting with Ventura 13.4 on Apple Silicon, but not *exporting* those (I don't think). However, a decode problem might appear during an export. These are apparently problems specific to MacOS 13.4 on Apple Silicon and are not caused by bugs in FCP or Resolve.

Also, can you state exactly what camera the source files came from? The currently-known problems are: 100 fps & 120 fps 10-bit 4:2:2 Sony XAVC-S, and DJI Mavic 3 H264 5.1k 10-bit 4:2:2, *all* frame rates. Both Sony and DJI Mavic 3 cameras have equivalent H265/HEVC codecs which do not show the problem, so that's an option for new material but not for existing material.

I think the Mavic 3 Pro also has the same (or similar) 5k 10-bit 4:2:0 H264 codec, but I don't have test material for that. Likewise, there are other cameras that shoot 5k or higher resolution using H264 at 10-bit 4:2:0 or 4:2:2, but I don't have those formats to test. So far I haven't seen any reports of problems from those, only Sony and DJI.

It truly doesn't matter which codec I use (XAVC-S, XAVC HS, 25p - 100p); if I export in H.265, the problem is always there (randomly, to be honest, it's a matter of luck). On the contrary, as I've already mentioned, there are no issues if I export in H.264 or ProRes.

...before updating to macOS version 13.4, I never, I repeat, never had such issues...The DRS Beta 4 has the same problems, and I have the same issue with Compressor (on both the MBP 14 M1 Max and the Mac Studio M1 Max).

Can you try your problematic export using a ProRes source file? There are some known issues on FCP and Resolve with *decoding* certain 10-bit H264 formats starting with Ventura 13.4 on Apple Silicon, but not *exporting* those (I don't think). However, a decode problem might appear during an export. These are apparently problems specific to MacOS 13.4 on Apple Silicon and are not caused by bugs in FCP or Resolve.

Also, can you state exactly what camera the source files came from? The currently-known problems are: 100 fps & 120 fps 10-bit 4:2:2 Sony XAVC-S, and DJI Mavic 3 H264 5.1k 10-bit 4:2:2, *all* frame rates. Both Sony and DJI Mavic 3 cameras have equivalent H265/HEVC codecs which do not show the problem, so that's an option for new material but not for existing material.

I think the Mavic 3 Pro also has the same (or similar) 5k 10-bit 4:2:0 H264 codec, but I don't have test material for that. Likewise, there are other cameras that shoot 5k or higher resolution using H264 at 10-bit 4:2:0 or 4:2:2, but I don't have those formats to test. So far I haven't seen any reports of problems from those, only Sony and DJI.

I predominantly use DCI 4k h264 10-bit 422 HLG 25 fps original material or (lately) 5.1k (3:2 format) h265 10-bit 420 Vlog REC709 29.97fps - both internally recorded LUMIX S5 h264/h265 material (and external 5.9k 12-bit ProRES RAW 25fps 16:9 Atomos Ninja V), and most often UHD h265 10bit 422 2020 HLG 25fps for delivery. Only DaVinchi Studio imposes restrictions on rendering bit rate on the same machine, same media source drives, same media target drives - even for same (simple) project setups as identical as possible.

Machine MacBook Pro 14 M1 Pro 10CPU 16GPU16 GB/1TB (several external 2TB Thunderbolt drives, with sustained read far above 2.5 GByte/sec and sustained write speeds just around 2.5 GByte/sec (the latter limits sustained copy speed for copying large size material between drives). Ventura 13.4, rest “current versions”.

Similar behaviour on Mac Mini M1 16GB/1TB; except for “raw muscle” similar results on same OS and versions of software on identical projects (copied from MacBook Pro to Mac Mini), when required, but less often in daily use.

Resolve Studio 18.1.4 release 9 (from memory). Tend to regard betas as too exciting for my remaining years.

Hope this will help solve the problem.

Regards

...before updating to macOS version 13.4, I never, I repeat, never had such issues...The DRS Beta 4 has the same problems, and I have the same issue with Compressor (on both the MBP 14 M1 Max and the Mac Studio M1 Max).

Can you try your problematic export using a ProRes source file? There are some known issues on FCP and Resolve with *decoding* certain 10-bit H264 formats starting with Ventura 13.4 on Apple Silicon, but not *exporting* those (I don't think). However, a decode problem might appear during an export. These are apparently problems specific to MacOS 13.4 on Apple Silicon and are not caused by bugs in FCP or Resolve.

Also, can you state exactly what camera the source files came from? The currently-known problems are: 100 fps & 120 fps 10-bit 4:2:2 Sony XAVC-S, and DJI Mavic 3 H264 5.1k 10-bit 4:2:2, *all* frame rates. Both Sony and DJI Mavic 3 cameras have equivalent H265/HEVC codecs which do not show the problem, so that's an option for new material but not for existing material.

I think the Mavic 3 Pro also has the same (or similar) 5k 10-bit 4:2:0 H264 codec, but I don't have test material for that. Likewise, there are other cameras that shoot 5k or higher resolution using H264 at 10-bit 4:2:0 or 4:2:2, but I don't have those formats to test. So far I haven't seen any reports of problems from those, only Sony and DJI.

It truly doesn't matter which codec I use (XAVC-S, XAVC HS, 25p - 100p); if I export in H.265, the problem is always there (randomly, to be honest, it's a matter of luck). On the contrary, as I've already mentioned, there are no issues if I export in H.264 or ProRes.

Just as an aside. Have you tried to recreate a virgin version from the bottom up of your project?

Regards

Anyone have a fix for this already? Hardware accelareted h.265 will give me dropped frames on around 90% of my projects currently. Turning off hardware acceleration works but is obviously not ideal.

As I write this, the only effective solution is to install the public beta of macOS Sonoma along with Davinci Resolve Studio beta 5 (18.5). Not only are there no more issues with glitches when exporting in H.265, but I also no longer have the annoying "media offline" message. Of course, I made a backup of everything beforehand. PS Furthermore, after this terrible experience, I started using Time Machine.

Re: Furthermore…

Smile!

Regards

Hi there,

Am on m1 max with DRS 18.1.4, after updating to Mac Os 13.4 i can't properly export h265 422 main 10 files (after exporting it video freeze in certains points while it is playin both in QT and VLC, there are Artifacts also like digital glitches). The issue disappear if i export in h264 or ProRess. Before updating OS i did not have problem at all.

Checking on my DRS log i saw:

Code: Select all

0x2a04b3000    | SyManager            | ERROR | 2023-05-18 22:13:00,604 | There is no current clip, SetCurrentFrame failed.

Any ideas?

Ty in advance!

Hi!

We are having the exact same issue here. Mac Studio M1 Max, Ventura. Freezes and blocky artifacts. Glad to see, that we are not the only ones :/

The problem appeared out of the blue on DVR prior to the 18.5 update, it might be related to a MacOs update.

H264 exports work fine

I reached out to Blackmagic and they suggested, that we should try and turn off hardware acceleration. After doing so, the exports looked fine but this does not solve the issue. Why should anyone want to turn off hardware acceleration??

We hope that this issue will be solved soon.

Cheers!

So glad to stick to Monterey. But I feel for those with newer machines.

I was under the impression that Ventura 13.5 resolved this issue. I guess not since it is still being discussed. I haven't seen it yet but my exports have been short lately.

Maybe 13.5.1?

I'm having the same issue,..

but it's H264 for me, .. getting blotchy pixelated renders.
Prores renders fine.

example here at 0:14 in.
https://www.dropbox.com/scl/fi/k9espp5o ... w8x9e&dl=0

Tried a 1.5 hour long render of a concert from Red R3d raw to H264,
got to about 40% and resolve crashed hard. Just disappeared with no fault message.

Mac studio ultra M1, 64gb. Ventura 13.5.1
Resolve 18.5.0

Ive tried just about everything I know.

Curtis

Render ProRes and try to transcode with HandBrake.

Render ProRes and try to transcode with HandBrake.

Doing that now,.. it'll be nice if it works but not happy about adding another step
to a busy schedule of work.

wonder if this will get fixed

If it's not in the source I'm pretty sure it's going to be fixed. At least there's a workaround.

Seems to be connected to Apple hardware and Ventura, I've seen it too and went back to Monterey. Not seen again, but knocking on wood.

you went back to Monterey and it fixed the issue?

yes, H264 from prores file in Handbrake worked just fine.

you went back to Monterey and it fixed the issue?

Yes, for me it did.

As I write this, the only effective solution is to install the public beta of macOS Sonoma along with Davinci Resolve Studio beta 5 (18.5). Not only are there no more issues with glitches when exporting in H.265, but I also no longer have the annoying "media offline" message. Of course, I made a backup of everything beforehand. PS Furthermore, after this terrible experience, I started using Time Machine.

I only went to Ventura 13.6 two days ago as Monterey has been good for my Mac Pro 2019. No issues on Ventura but my real reason for going to Ventura was the general release of Sonoma tomorrow.

I only started my first major new DaVinci Resolve Studio 18.6 project with the new Ventura macOS yesterday. I have a new minor project coming this week.

Would it be wise to make that upgrade to Sonoma this week based on the success people have had on the Sonoma beta? I’m thinking I should wait a few weeks into October, until I complete my new projects, before updating to Sonoma prior to my next significant new project in November?

If Resolve is working for you now and you can get your projects done, my thought is to hold off upgrading to Sonoma and let others with less critical work beta test the interaction of Resolve with the released version of the new macOS.

Are you able to test your current setup, Rick, to see if artifacts are an issue you will be facing?