H.265 low bitrate corruption with Resolve on Apple Silicon

I noticed this issue with the previous version of Resolve and now also with the latest version.

When exporting H.265 using the Apple media encoder, there can be random breakups in the encode. What's really odd is that this seems to only really happen toward the end of the encoding.

The issue looks like a momentary and large drop in the bitrate. Even if using a high bitrate output, the issue can still happen. There's no loss of synch, repeated frames or frame jumps etc. It just looks like a very low bitrate. There's obviously nothing wrong with the source media and the timeline playback is fine with the media and the section of the edit where the issue in the export happens.

I first noticed this on the M4 Max chip (MacBook Pro) but have now seen it with the base M4 chip (MacBook Air).

Could someone at BMD please chime in on this one please and I can tests it further from any suggestions or I can supply examples.

What's really ironic is that I've just done a video showing that Resolve on a base M4 Air will edit 8K/24 and after showing the workflow the end of the video suffers from this encoding issue

I doubt BM will make much effort, H.264/5 export from resolve has largely been ignored. It has been unstable for many users for years.


If you require a h.264/5, export PR422 from resolve and transcode with your favorite flavor of FFMPEG GUI.


If you get the same results with FFMPEG, then it is a feature of the Apple hardware encoding and can only be resolved by them.

Generally hardware h.264/5 prioritizes speed over quality, at least AMD and Nvidia have, I haven't seen anyone doing quality tests of Apple's implementation.

If you don't like what you get from Apple, use x.265. But if you truly do need very small files at reasonable quality, expect to have to tweak a few settings to get there.

I doubt BM will make much effort, H.264/5 export from resolve has largely been ignored. It has been unstable for many users for years.


If you require a h.264/5, export PR422 from resolve and transcode with your favorite flavor of FFMPEG GUI.


If you get the same results with FFMPEG, then it is a feature of the Apple hardware encoding and can only be resolved by them.

Generally hardware h.264/5 prioritizes speed over quality, at least AMD and Nvidia have, I haven't seen anyone doing quality tests of Apple's implementation.

If you don't like what you get from Apple, use x.265. But if you truly do need very small files at reasonable quality, expect to have to tweak a few settings to get there.

Your statement "I doubt BM will make much effort, H.264/5 export from resolve has largely been ignored. It has been unstable for many users for years." Is wholly inaccurate. While there have been some issues with it on Apple Silicon, BMD have been very quick to respond to the issues. I know this from personal experience having done tests requested by BMD support and they very quickly fixed the issue.

Another reason why your statement is wholly inaccurate is because H.264/5 acceleration for decoding and encoding is at the very core of Apple Silicon. BMD are not going to ignore not only one of the USPs of Apple Silicon but they are not going to risk the popularity of Resolve on Apple Silicon by ignoring any issues. Especially when Resolve is quite clearly the best NLE and post application on Apple Silicon and offers functionality way beyond even Apple's own FCP.

I have had my issues with BMD and have been very vocal about it on this forum but credit has to be given when and where it is due and BMD are the fastest responding manufacturer/developer of any post application on the market.

This issue could even be an OS issue, as has happened in the past, and unless pointed out, BMD may not be aware that there's anything to "fix".

As for exporting an edit to an intermediate for it to be re-encoded in another app. If that's what someone finds to be their best workflow, then fair enough. However, I most certainly don't use such a workflow which will extend production time and potentially involve the use of an inconvenient CLI as apposed to a very simple GUI.

Plus for me personally X.265 looks no different to my Apple Silicon outputs via Resolve as bit budgeting is not a concern and time is also a factor.

The issue looks like a momentary and large drop in the bitrate. Even if using a high bitrate output, the issue can still happen. There's no loss of synch, repeated frames or frame jumps etc. It just looks like a very low bitrate. There's obviously nothing wrong with the source media and the timeline playback is fine with the media and the section of the edit where the issue in the export happens.

Is it related to the timeline media though, do you see a pattern with the cause such as a still picture at the end or just before the end, while timeline media where every frame is unique doesn't cause the corruption ?

The issue looks like a momentary and large drop in the bitrate. Even if using a high bitrate output, the issue can still happen. There's no loss of synch, repeated frames or frame jumps etc. It just looks like a very low bitrate. There's obviously nothing wrong with the source media and the timeline playback is fine with the media and the section of the edit where the issue in the export happens.

Is it related to the timeline media though, do you see a pattern with the cause such as a still picture at the end or just before the end, while timeline media where every frame is unique doesn't cause the corruption ?

No stills, it’s all video, either 10Bit 4:2:0 H.265, 8Bit 4:2:0 H.264 or ProRes 422 HQ. All at various frame rates and resolutions.

...No stills, it’s all video, either 10Bit 4:2:0 H.265, 8Bit 4:2:0 H.264 or ProRes 422 HQ. All at various frame rates and resolutions.

David you have multiple machines. Does it seem isolated to the M4 series? Does the exact same scenario using the same MacOS and Resolve version behave differently on M3 or earlier?

In some fairly recent version, there was a change in Resolve's automatic H.265 bit rate on the Deliver page. It previously would default to a low number, which made people think the H.265 encoder was poor quality. I think the latest version uses a more reasonable default bit rate. I can't remember the Resolve version of that change.

Suggestions: Verify the encoded bit rate using MediaInfo (even though you manually set it), try it with export hardware acceleration turned off, and try it on an M3 or prior machine. If it doesn't happen with hardware acceleration off, that would narrow it down and provide an easy test case.

The M4 series has updated hardware accelerators so if it's M4-specific, that would be suspicious.

For QC testing of multiple versions, Apple's command-line AVQT tool can be useful. AVQT can be downloaded from the Apple Developer site, but that requires you to create a free developer account (click "Account" at the top-right corner of this page: https://developer.apple.com/.)
Youtube tutorial on AVQT:

I noticed this issue with the previous version of Resolve and now also with the latest version.

When exporting H.265 using the Apple media encoder, there can be random breakups in the encode. What's really odd is that this seems to only really happen toward the end of the encoding.

The issue looks like a momentary and large drop in the bitrate. Even if using a high bitrate output, the issue can still happen. There's no loss of synch, repeated frames or frame jumps etc. It just looks like a very low bitrate. There's obviously nothing wrong with the source media and the timeline playback is fine with the media and the section of the edit where the issue in the export happens.

I first noticed this on the M4 Max chip (MacBook Pro) but have now seen it with the base M4 chip (MacBook Air).

Could someone at BMD please chime in on this one please and I can tests it further from any suggestions or I can supply examples.

What's really ironic is that I've just done a video showing that Resolve on a base M4 Air will edit 8K/24 and after showing the workflow the end of the video suffers from this encoding issue

Won't be (for 99%) Resolve issue but Apple's hardware encoder. This is typical issue for encoders with poor rate control.
Lower GOP length, by setting a key frames to eg 12 or even 6. Also try multipass encode. If you you can adjust slightly (few frame) start of your last (static) section.
You can for example try making GOP=24 (if it's 24fps timeline) and then make sure your graphics starts exactly at full second (eg 00:12:23:00), so you have a high chance that I frame will be positioned when your graphics start. This would give it higher bitrate and quality.
Proper solution is to use a good software h265 encoder, so export ProRes and use ffmpeg, Handbrake with x265 to encode your final video.

...Won't be (for 99%) Resolve issue but Apple's hardware encoder. This is typical issue for encoders with poor rate control. Lower GOP length, by setting a key frames to eg 12 or even 6. Also try multipass encode.

To see if it's hardware or software, he can try the same export parameters using FCP or Compressor.

Yes, good test although parameters should remain the same (GOP, multipass etc.)
You also need to have those apps

I thought the Resolve H264 encoder was horrible compared to Compressor, until I turned off USE HARDWARE ACCELERATION checkbox. And the quality was much much better, and the encode speed wasn't much slower either. And if you use MP4 and not QT, the color is consistent with REC709 profile and matches the original Davinci GUI output.

I noticed this issue with the previous version of Resolve and now also with the latest version.

When exporting H.265 using the Apple media encoder, there can be random breakups in the encode. What's really odd is that this seems to only really happen toward the end of the encoding.

The issue looks like a momentary and large drop in the bitrate. Even if using a high bitrate output, the issue can still happen. There's no loss of synch, repeated frames or frame jumps etc. It just looks like a very low bitrate. There's obviously nothing wrong with the source media and the timeline playback is fine with the media and the section of the edit where the issue in the export happens.

I first noticed this on the M4 Max chip (MacBook Pro) but have now seen it with the base M4 chip (MacBook Air).

Could someone at BMD please chime in on this one please and I can tests it further from any suggestions or I can supply examples.

What's really ironic is that I've just done a video showing that Resolve on a base M4 Air will edit 8K/24 and after showing the workflow the end of the video suffers from this encoding issue

Won't be (for 99%) Resolve issue but Apple's hardware encoder. This is typical issue for encoders with poor rate control.
Lower GOP length, by setting a key frames to eg 12 or even 6. Also try multipass encode. If you you can adjust slightly (few frame) start of your last (static) section.
You can for example try making GOP=24 (if it's 24fps timeline) and then make sure your graphics starts exactly at full second (eg 00:12:23:00), so you have a high chance that I frame will be positioned when your graphics start. This would give it higher bitrate and quality.
Proper solution is to use a good software h265 encoder, so export ProRes and use ffmpeg, Handbrake with x265 to encode your final video.

Alright, Andrew. I’ve already tried a load of variations but as the issue is random it’s not so easy to pin down and would require more time than I have. Using an intermediate in something else isn’t an option for me due to time and multiple edits and outputs. Again, X265 wouldn’t benefit me either as I use high bitrates and the ARM machines don’t stack up well either against X86 for time with X265.

...No stills, it’s all video, either 10Bit 4:2:0 H.265, 8Bit 4:2:0 H.264 or ProRes 422 HQ. All at various frame rates and resolutions.

David you have multiple machines. Does it seem isolated to the M4 series? Does the exact same scenario using the same MacOS and Resolve version behave differently on M3 or earlier?

In some fairly recent version, there was a change in Resolve's automatic H.265 bit rate on the Deliver page. It previously would default to a low number, which made people think the H.265 encoder was poor quality. I think the latest version uses a more reasonable default bit rate. I can't remember the Resolve version of that change.

Suggestions: Verify the encoded bit rate using MediaInfo (even though you manually set it), try it with export hardware acceleration turned off, and try it on an M3 or prior machine. If it doesn't happen with hardware acceleration off, that would narrow it down and provide an easy test case.

The M4 series has updated hardware accelerators so if it's M4-specific, that would be suspicious.

For QC testing of multiple versions, Apple's command-line AVQT tool can be useful. AVQT can be downloaded from the Apple Developer site, but that requires you to create a free developer account (click "Account" at the top-right corner of this page: https://developer.apple.com/.)
Youtube tutorial on AVQT:

Alright, Joe.

I can’t say if it’s isolated to M4 yet. As soon as I get some time I will try it on M1, I don’t have M2 or M3.

Yes, the auto bitrate control did go a bit side ways, I can’t remember which version but it was especially bad with 8K outputs. However, for my main outputs (UHD) I set a manual high bitrate, either 100Mb/s or 200Mb/s.

In fact, you’ve just got me thinking of something, thanks. I do a lot of stuff where I record with a Ninja at 60 or 59.94, however, my cameras are set to 25. The timeline and outputs are either 59.94 or 60, whichever is the dominant media. I’ll have to check to see if the issues are on the 25 sections within the 59.94 or 60 outputs, that may give a hint to something with the interpolated sections.

If I get time I’ll try out your suggestion of testing with the AVQT tool, thanks.

Here’s an example of the issue. It’s quite a long video but the issue mostly happens at the end. Again, where there’s 25 footage in a 60 project, which is why I’m now thinking that this could be a hint to the issue. Howvere, saying that, I will get a similar but less noticeable issue when there’s a lot of solid single colour on the screen, such as a UI. Which maybe suggests that although a manual bitrate has been selected maybe the encoder just automatically drops anyway when there’s very little detail or temporal difference to encode. BTW, this issue is in the master upload, although, YouTube’s re-encode does make it worse.

EDIT: I deleted the link as the embed didn’t go to the timecode at the end of the video.

...No stills, it’s all video, either 10Bit 4:2:0 H.265, 8Bit 4:2:0 H.264 or ProRes 422 HQ. All at various frame rates and resolutions.

Howvere, saying that, I will get a similar but less noticeable issue when there’s a lot of solid single colour on the screen, such as a UI. Which maybe suggests that although a manual bitrate has been selected maybe the encoder just automatically drops anyway when there’s very little detail or temporal difference to encode. BTW, this issue is in the master upload, although, YouTube’s re-encode does make it worse.

I've seen in other software where a still image is used in video and scene adaptive GOP used. The lower bitrate is rightfully used for the few second image but possibly due to the low bitrate GOP continuing after the image the first frames of motion video will look low bitrate - a fault with scene detection and dynamic GOP. If you watch enough video online you'll see it numerous times especially with older uploads

I thought the Resolve H264 encoder was horrible compared to Compressor, until I turned off USE HARDWARE ACCELERATION checkbox. And the quality was much much better, and the encode speed wasn't much slower either. And if you use MP4 and not QT, the color is consistent with REC709 profile and matches the original Davinci GUI output.

There is absolutely no difference between the Apple encoder or any software encoder or any other hardware encoder as far as quality is concerned as long as you use an appropriate bitrate for any given codec and the complexity of the source.

Differences between MP4 and QT are usually down to the player/decoder misinterpreting the file. Both will look identical to the source as far as chroma and gamma is concerned.

If you want the lowest bitrate outputs possible then yes, a good software encoder is going to be much better. Using the likes of X264 and X265 for H.264 and H.265.

I've seen in other software where a still image is used in video and scene adaptive GOP used. The lower bitrate is rightfully used for the few second image but possibly due to the low bitrate GOP continuing after the image the first frames of motion video will look low bitrate - a fault with scene detection and dynamic GOP. If you watch enough video online you'll see it numerous times especially with older uploads

Yes, this is definitely common with many encoders, both software and hardware. I have been using encoders since the early 90s and have used some that did adhere to CBR properly regardless of the source. However, in the instance of the issue I'm seeing with motion, this is something different. Plus, it's quite telling that it almost always happens toward the end of the encode. Hopefully BMD can work out if this is an Apple thing or something that they can fix.

I wouldn't be surprised if this is an Apple thing as they usually break UVC adherence when they update the OS. Causing issues with the likes of OBS etc.

BM doesn't touch encoder internals (they just send data to encode) and can do nothing to solve it. It's all up to Apple.
As I said- this is very common issue and up to some extent it's present in all encoders, even in x264/5. Fortunately it's minimise there and it doesn't really show up prominently enough to be an real issue. It's all down to rate control.
This was for example very common issue in menu design for DVD, where you had eg. 3 seconds of motion then 2 seconds of still (menus with transitions). Many encoders where causing same quality fall for still bit. You had to use better one or go to extreme and us eg. Cinemacraft and manually force I frame at correct place (at static bit start) to solve issue fully.
Issue is well known and best solution is to use better encoder. Very similar issue is an I frame pumping effect, where I frames receive way more data (too much) than other frames and have much better quality than others, which also shows ups during watching.
Try adding some motion to your still elements, eg. bit of film grain, to force encoder to send more bits into this section.
Don't count on BM looking into it in next 6 months or at all

There is absolutely no difference between the Apple encoder or any software encoder or any other hardware encoder as far as quality is concerned as long as you use an appropriate bitrate for any given codec and the complexity of the source.

This is different than encoder having poor rate control. You can mask it with high enough bitrate, but even this sometimes can be not enough. Also those files may have 5x bigger size for no reason.
Try disabling frame re-ordering which makes encodes without B frames if I'm correct. Then you can compensate with higher bitrate.

BM doesn't touch encoder internals (they just send data to encode) and can do nothing to solve it. It's all up to Apple.
As I said- this is very common issue and up to some extent it's present in all encoders, even in x264/5. Fortunately it's minimise there and it doesn't really show up prominently enough to be an real issue. It's all down to rate control.
This was for example very common issue in menu design for DVD, where you had eg. 3 seconds of motion then 2 seconds of still (menus with transitions). Many encoders where causing same quality fall for still bit. You had to use better one or go to extreme and us eg. Cinemacraft and manually force I frame at correct place (at static bit start) to solve issue fully.
Issue is well known and best solution is to use better encoder. Very similar issue is an I frame pumping effect, where I frames receive way more data (too much) than other frames and have much better quality than others, which also shows ups during watching.
Try adding some motion to your still elements, eg. bit of film grain, to force encoder to send more bits into this section.
Don't count on BM looking into it in next 6 months or at all

Given that BMD have introduced updates very quickly that fixed previously reported issues with H.265 encoding on Apple Silicon, this makes a lot of what you've said completely redundant and incorrect

There is absolutely no difference between the Apple encoder or any software encoder or any other hardware encoder as far as quality is concerned as long as you use an appropriate bitrate for any given codec and the complexity of the source.

This is different than encoder having poor rate control. You can mask it with high enough bitrate, but even this sometimes can be not enough. Also those files may have 5x bigger size for no reason.
Try disabling frame re-ordering which makes encodes without B frames if I'm correct. Then you can compensate with higher bitrate.

Of course I'm talking about encoding without issues. If your encoders are making the file sizes 5x bigger for no reason, I'd suggest you use better encoders or maybe learn a bit more about encoding And no, frame re-ordering does not encode without B frames.

BM doesn't touch encoder internals (they just send data to encode) and can do nothing to solve it. It's all up to Apple.
As I said- this is very common issue and up to some extent it's present in all encoders, even in x264/5. Fortunately it's minimise there and it doesn't really show up prominently enough to be an real issue. It's all down to rate control.
This was for example very common issue in menu design for DVD, where you had eg. 3 seconds of motion then 2 seconds of still (menus with transitions). Many encoders where causing same quality fall for still bit. You had to use better one or go to extreme and us eg. Cinemacraft and manually force I frame at correct place (at static bit start) to solve issue fully.
Issue is well known and best solution is to use better encoder. Very similar issue is an I frame pumping effect, where I frames receive way more data (too much) than other frames and have much better quality than others, which also shows ups during watching.
Try adding some motion to your still elements, eg. bit of film grain, to force encoder to send more bits into this section.
Don't count on BM looking into it in next 6 months or at all

Given that BMD have introduced updates very quickly that fixed previously reported issues with H.265 encoding on Apple Silicon, this makes a lot of what you've said completely redundant and incorrect

Happy waiting...

Of course I'm talking about encoding without issues. If your encoders are making the file sizes 5x bigger for no reason, I'd suggest you use better encoders or maybe learn a bit more about encoding And no, frame re-ordering does not encode without B frames.

Well, I wasted 1min and checked and was correct. It does encode without B frames.
Maybe learn bit more about encoding before you comment bs or simply try lying.

BM doesn't touch encoder internals (they just send data to encode) and can do nothing to solve it. It's all up to Apple.
As I said- this is very common issue and up to some extent it's present in all encoders, even in x264/5. Fortunately it's minimise there and it doesn't really show up prominently enough to be an real issue. It's all down to rate control.
This was for example very common issue in menu design for DVD, where you had eg. 3 seconds of motion then 2 seconds of still (menus with transitions). Many encoders where causing same quality fall for still bit. You had to use better one or go to extreme and us eg. Cinemacraft and manually force I frame at correct place (at static bit start) to solve issue fully.
Issue is well known and best solution is to use better encoder. Very similar issue is an I frame pumping effect, where I frames receive way more data (too much) than other frames and have much better quality than others, which also shows ups during watching.
Try adding some motion to your still elements, eg. bit of film grain, to force encoder to send more bits into this section.
Don't count on BM looking into it in next 6 months or at all

Given that BMD have introduced updates very quickly that fixed previously reported issues with H.265 encoding on Apple Silicon, this makes a lot of what you've said completely redundant and incorrect

Happy waiting...

You quite clearly do not understand what the word redundant means

Of course I'm talking about encoding without issues. If your encoders are making the file sizes 5x bigger for no reason, I'd suggest you use better encoders or maybe learn a bit more about encoding And no, frame re-ordering does not encode without B frames.

Well, I wasted 1min and checked and was correct. It does encode without B frames.
Maybe learn bit more about encoding before you comment bs or simply try lying.

See this is what happens when you think Google is your friend

So you are one of those "google encoding experts".
Repeat what you read without any validation.
This is how internet myths are created

So you are one of those "google encoding experts".
Repeat what you read without any validation.
This is how internet myths are created

You should know

I actually wasted time to verify it to be sure, as I don't repeat after others or google.

Ok, let us know please, when BM will do a fix in Apple's internal engine for their hardware encoders. Very interesting task for BM engineers. But they have google, so who knows.

I actually wasted time to verify it to be sure, as I don't repeat after others or google.

Ok, let us know please, when BM will do a fix in Apple's internal engine for their hardware encoders. Very interesting task for BM engineers. But they have google, so who knows.

So let me get this right. You asked Google for the answer and then asked Google to verify the answer. Now that really is redundent

Gentlemen, this reminds me of the EDIUS forum. I have always appreciated both your inputs to the forums but maybe a cup of coffee or a beer and change of topic would work for everyone.

Gentlemen, this reminds me of the EDIUS forum. I have always appreciated both your inputs to the forums but maybe a cup of coffee or a beer and change of topic would work for everyone.

Alright, Ron.

I appreciate what you are saying and you are right about "stupidity on forums" (my words). However, I'm most certainly not going to be painted with the same brush when, as per usually, I wasn't the one trolling someone else's post. If I had started this BS, then fair enough, but I didn't.

Anyway. As per your suggestion. You won't believe this but I am actually sitting here with two bottles of Spain's finest, Estrella, playing some Warzone Mobile. And I'm definitely taking you up on your suggestion and finishing off that beer before it goes cold. And maybe in the process I may win a game

Hope you are well. Take care buddy.

Cheers,
Dave.

Excellent . Enjoy the game and don't drink too much !!

Best wishes

I doubt BM will make much effort, H.264/5 export from resolve has largely been ignored. It has been unstable for many users for years.

I think that's unkind and unfair. I think H.264 & H.265 have been fine in Resolve, but the reality is both formats are terrible for post, for a lot of reasons. The Long-GOP formats in particular (plus the lack of accurate embedded timecode) is a big limitation.

I occasionally hang out in a few Adobe Premiere forums, and people are regularly screaming about issues with H.264 and H.265 source files. So this is not a Resolve issue -- by any means.

Resolve problem with those formats is heavy reliance on 3rd party, which is dictated by development and licensing costs. There is not much what they can do. It’s good enough for making quick previews etc. For more demanding tasks you need to use other tools designed for it. You can also buy MainConcept plugin. This gives you more control and it’s the same what Adobe uses ( and 80% of industry). Some companies gone further, eg. Edius uses own encoders and decoders, but writing them takes a lot of time and resources.
Hardware encoders always present a compromise in quality ( but are very fast) and non-ideal bitrate allocation or I frame pumping effect are very common issues. Nothing new or special.

There are ways to solve described issue, but some people refuse to try. No idea why they even bother posting it here if they already know things ‘better’. In the meantime they lie and create misinformation which leads to famous internet myths. 1 writes crap, 100 repeat it without verification, or even thinking about it and you have new ‘truth’. Only problem it’s all fake.
Solution here is to change GOP size, data rate control length or disable B frames ( frame reordering option). If this doesn’t help you put grain in those static and problematic cuts to force encoder to put more bit into it. Grain will make them way more complicated to encode, so encoder will raise bitrate. If none of it works you use different encoder. Plain simple. Some are trying to mystify reality instead.

I actually wasted time to verify it to be sure, as I don't repeat after others or google.

Ok, let us know please, when BM will do a fix in Apple's internal engine for their hardware encoders. Very interesting task for BM engineers. But they have google, so who knows.

So let me get this right. You asked Google for the answer and then asked Google to verify the answer. Now that really is redundent

This is how you read it in your head.
No. I encoded 2 files and checked them as I wasn’t 100% sure.
You in comparison negated it just for the sake to be right. What is the source of your statement, because you clearly didn’t try it as then you wouldn’t write it as it’s not true. You simply lied.
This is the difference - I wasted time to verify it where you are mainly about big mouth, which some already know from other forums.

Which exact quality related encoding issues for hardware encoders have BM fixed?