H.265 choppy export

Most likely because its a Studio feature? I had it when I was using a 6800XT. It came up as AMD in the settings.

after the terror against AMD, and I am an AMD owner, I am scared to buy the studio version.

Your options are:

1. Find version of AMD drivers recommended by BMD as stable that is working for you. After that spend much less on Resolve Studio than Adobe ($300 for PERMANENT license vs. how much per year)

2. Research what kind of experience Adobe AMD users have, then get few months eval of Adobe and see what you really think, and after that make decision, but be ready it will be much more expensive.

Thank you. Amd users are very hard to find. But yes, your options are right.

The re-econding process with handbrake is also very slow.

Have you tried Shutter Encoder? I think it has support for GPU accelerated encoding.

I never heard about it. I am checking now and the website sees more professional than Handbrake. I will try it out for sure.

The re-econding process with handbrake is also very slow.

Have you tried Shutter Encoder? I think it has support for GPU accelerated encoding.

I never heard about it. I am checking now and the website sees more professional than Handbrake. I will try it out for sure.

I'm not qualified to speak on encoders but it is my understanding that while Handbrake is very powerful Shutter Encoder is very good too and nothing to sneeze at. It will be interesting to hear what you experienced.

Thank you. Amd users are very hard to find. But yes, your options are right.

Here's how it looks with Studio.

The re-econding process with
Have you tried Shutter Encoder? I think it has support for GPU accelerated encoding.

I never heard about it. I am checking now and the website sees more professional than Handbrake. I will try it out for sure.

I'm not qualified to speak on encoders but it is my understanding that while Handbrake is very powerful Shutter Encoder is very good too and nothing to sneeze at. It will be interesting to hear what you experienced.

I just tried. It was faster but the final quality with the same bitrates is lower in my opinion than handbrake. I will try better in the next days.

Thank you. Amd users are very hard to find. But yes, your options are right.

Here's how it looks with Studio.

Thank you

I just tried. It was faster but the final quality with the same bitrates is lower in my opinion than handbrake. I will try better in the next days.

It is my understanding that at identical bit rates CPU based encoders will almost always have better looking results than GPU based ones which is why those looking for highest quality go through Handbrake / ffmpeg. It makes sense that is the price you pay for speed part of which might be recovered by raising bit rate.

I just tried. It was faster but the final quality with the same bitrates is lower in my opinion than handbrake. I will try better in the next days.

It is my understanding that at identical bit rates CPU based encoders will almost always have better looking results than GPU based ones which is why those looking for highest quality go through Handbrake / ffmpeg. It makes sense that is the price you pay for speed part of which might be recovered by raising bit rate.

oh yes, Copilot just explained to me that the GPU encoding has generally less quality.. so lol what's the point in that ahah And it also said to me that also handbrake has the GPU encoding for intel or amd and was activated when I used it the other day. And still, the quality is better on handbrake than shutter encoder.

I just tried. It was faster but the final quality with the same bitrates is lower in my opinion than handbrake. I will try better in the next days.

It is my understanding that at identical bit rates CPU based encoders will almost always have better looking results than GPU based ones which is why those looking for highest quality go through Handbrake / ffmpeg. It makes sense that is the price you pay for speed part of which might be recovered by raising bit rate.

oh yes, Copilot just explained to me that the GPU encoding has generally less quality.. so lol what's the point in that ahah And it also said to me that also handbrake has the GPU encoding for intel or amd and was activated when I used it the other day. And still, the quality is better on handbrake than shutter encoder.

I didn't know Handbrake can do GPU accelerated encoding (as mentioned, I can't speak with authority about them as I don't use these tools, my exports are done with Nvidia GPU acceleration straight from Resolve and for what I do they are more than good enough). What's the point of using one vs. the other, CPU vs. GPU, Handbrake vs. something else? Point is in having options/flexibility. Every individual's needs are different, one finds out which one of options available works best for what they need, which also might change.

FYI: Both HandBrake and Shutter Encoder are just GUIs for ffmpeg. In HandBrake you can decide to use x.265 in software or hardware encoding as offered by the OS.

FYI: Both HandBrake and Shutter Encoder are just GUIs for ffmpeg. In HandBrake you can decide to use x.265 in software or hardware encoding as offered by the OS.

In that case is there any reason why op could feel file encoded by Handbrake looks better than one by Shutter Encoder if he used identical settings like he claims he did?

I would not be so sure he did, I didn't look over his shoulder

Shutter Encoder can be set to soft- or hardware encoding and can also use 2-pass with x.265. It will be documented in full detail in MediaInfo under Encoding settings. I get excellent quality if set to 2-pass and Max. Quality with hardware acceleration 'none' (it'll use.265). You also have full control over bitrates.

I would not be so sure he did, I didn't look over his shoulder

Makes sense, thank you

FYI: Both HandBrake and Shutter Encoder are just GUIs for ffmpeg. In HandBrake you can decide to use x.265 in software or hardware encoding as offered by the OS.

In that case is there any reason why op could feel file encoded by Handbrake looks better than one by Shutter Encoder if he used identical settings like he claims he did?

Our eyes and monitors can play tricks on us so there are various tools to objectively assess generation loss and other types of image quality loss vs the original "reference" file.

On MacOS, Apple provides a free command-line tool called AVQT. It is designed to measure perceptual quality loss, not just a technical parameter. It can be downloaded from the Apple Developer site but that requires you create a free developer account (click "Account" at top-right corner of this page: https://developer.apple.com/.)
WWDC21 talk on AVQT: https://developer.apple.com/wwdc21/10145
Youtube tutorial on AVQT:

You can also measure visual generation loss using a tool developed by NetFlix called VMAF (Video Multi-Method Assessment Fusion). Unlike AVQT, it is available on both Mac and Windows. VMAF is built into certain versions of ffmpeg. On Mac, ffmpeg-VMAF is available through the Homebrew package manager: https://brew.sh

On Windows, pre-built ffmpeg-VMAF binaries are available here: https://www.gyan.dev/ffmpeg/builds/

Our eyes and monitors can play tricks on us ...

Oh, I know ... and the minds too

... so there are various tools to objectively assess generation loss and other types of image quality loss vs the original "reference" file.

Thank you for sharing this, it is very valuable info

Hello,

with davinci 19 I can use the GPU. I wanted to inform you that I have always the same problem.

Yes, it has that as an option.
Keep in mind, though, that hardware encoding will give you less control, and may have lower quality vs. a software encoder like x.265.

I would not be so sure he did, I didn't look over his shoulder

Shutter Encoder can be set to soft- or hardware encoding and can also use 2-pass with x.265. It will be documented in full detail in MediaInfo under Encoding settings. I get excellent quality if set to 2-pass and Max. Quality with hardware acceleration 'none' (it'll use.265). You also have full control over bitrates.

I have not checked this with quality analysis software but my understanding that max quality isn't actually about quality but compression. It gives maximum quality for a given file size, so when encoding at a given quality file sizes from largest to smallest are:

Hardware encode H.265
Hardware encode H.265 - Max Quality
Software encode H.265
Software encode x265 - Max Quality

Quality of all 4 should be very similar

Yes, it has that as an option.
Keep in mind, though, that hardware encoding will give you less control, and may have lower quality vs. a software encoder like x.265.

But the question is: why also with gpu encoding I have the same problem? Since I have a beast gpu? Exactly the same problem, exactly in the same point of the clip. Always the last part of the video is choppy like a stop motion movie. Uff (((

Yes, it has that as an option.
Keep in mind, though, that hardware encoding will give you less control, and may have lower quality vs. a software encoder like x.265.

But the question is: why also with gpu encoding I have the same problem? Since I have a beast gpu? Exactly the same problem, exactly in the same point of the clip. Always the last part of the video is choppy like a stop motion movie. Uff (((

Have you researched possibility suggested while ago that it is your AMD drivers? Hardware accelerated encoding is done by part of code provided by drivers (at least that is the case with my Nvidia card).

Another possibility (because it is done by card) is that your card isn't stable.

P.S. Does it happen only with one same clip or it happens with other clips too?

Yes, it has that as an option.
Keep in mind, though, that hardware encoding will give you less control, and may have lower quality vs. a software encoder like x.265.

But the question is: why also with gpu encoding I have the same problem? Since I have a beast gpu? Exactly the same problem, exactly in the same point of the clip. Always the last part of the video is choppy like a stop motion movie. Uff (((

Have you researched possibility suggested while ago that it is your AMD drivers? Hardware accelerated encoding is done by part of code provided by drivers (at least that is the case with my Nvidia card).

Another possibility (because it is done by card) is that your card isn't stable.

P.S. Does it happen only with one same clip or it happens with other clips too?

I don’t understand your question “ Have you researched possibility suggested…”

How can I know that my card is not stable?

It happens always in the last part of the video with the talking head final clip made with my canon m50. The strange thing is that also the intro is made with the same gear but I never had problems in the intro. Only in the outro.

Did you try the suggestion to add some seconds of black (or whatever) to the end and to render again?
If it works, you can exclude there's a hidden problem in the source footage.

It happens always in the last part of the video with the talking head final clip made with my canon m50. The strange thing is that also the intro is made with the same gear but I never had problems in the intro. Only in the outro.

Have you tried looking at the outro frame by frame and see if there are any obvious skips. This sounds like dropped frames are happening in the source footage.

...Have you tried looking at the outro frame by frame and see if there are any obvious skips. This sounds like dropped frames are happening in the source footage.

That is an excellent point. Does that source clip have dropped frames or only when positioned at the tail of a timeline and exported to an output file?

Are the frames actually dropped/duplicated, or does it only appear that way due to rate conforming? What is the frame rate of that M50 clip vs what is the timeline frame rate? Is speed ramp, optical flow or any other retiming effect applied to that M50 clip?

In the output file, are frames actually dropped, duplicated or what? Is there some other defect in the file encoding which gives that appearance?

An easy first step is to compare these three versions of that clip, EACH having a burn-in timecode overlay using source timecode (Menu: Workspace>Data Burn-in>Source Timecode).

(1) The original M50 trimmed clip as used in timeline but with no other Fx applied. IOW apply an I and O range over that clip and export that.
(2) The above but with all Fx enabled on that clip. Use an I and O range to export just that clip.
(3) Export of the full timeline as normal, but having Data Burn-in Source Timecode on the M50 clip.

This will enable straightfoward examination of that clip under three different conditions. It will show whether it's related to FX, or related to some "warm up" process that happens during timeline processing. It will show whether there is an obvious missing or duplicated frame, and whether each version of the exported clip has the same number of frames.

Depending on what that shows, follow-up troubleshooting steps might include disabling hardware acceleration on export. If needed, I can then provide some diagnostic methods to examine the internal structure of the problematic clips, but we want to do the above steps first.

Did you try the suggestion to add some seconds of black (or whatever) to the end and to render again?
If it works, you can exclude there's a hidden problem in the source footage.

I added a solid black color at the end and the clip was not choppy in the final export. Ok, gut, but what does it mean? and I cannot add every time a solid black color.

It happens always in the last part of the video with the talking head final clip made with my canon m50. The strange thing is that also the intro is made with the same gear but I never had problems in the intro. Only in the outro.

Have you tried looking at the outro frame by frame and see if there are any obvious skips. This sounds like dropped frames are happening in the source footage.

the original raw clip used for the outro was as good as the other clips I used for the intro.

Try to throttle the render a bit (under Advanced).

Try to throttle the render a bit (under Advanced).

I set the render speed at 100 and the final export is as it should be, not choppy.
I am kind of happy because the speed was more than twice slower: now 12 minutes, before 5 minutes (for a 24 m long video). Since I have 2 hours gameplay, this is a nightmare.

Is there some way to have more control over the render speed so that it is not 100 but slightly faster? Maybe there is some option in the AMD Adrenaline app that I can set so my graphic card is not overclocking during davinci?

Don't overclock anything for stable work in DR!

...I set the render speed at 100 and the final export is as it should be, not choppy.
I am kind of happy because the speed was more than twice slower: now 12 minutes, before 5 minutes (for a 24 m long video). Since I have 2 hours gameplay, this is a nightmare.

Is there some way to have more control over the render speed so that it is not 100 but slightly faster? Maybe there is some option in the AMD Adrenaline app that I can set so my graphic card is not overclocking during davinci?

Your "choppy export" problem seems to happen when rendering the end of a long timeline. The system would tend but be under greater thermal stress at that point. Are you saying your system is overclocked? How do you know it's stable under sustained high-intensive CPU and GPU loads, which is what Resolve causes? Can your system reliably run Prime95 and Furmark simultaneously for several hours?

Your situation was presented as a pure Resolve problem, and we've spent a lot of time laboring under that description. If you put all CPU, GPU and memory settings on default, (IOW no over-clocking whatsoever), does the Resolve H.265 choppy export problem still happen? Please do this test.

...I set the render speed at 100 and the final export is as it should be, not choppy.
I am kind of happy because the speed was more than twice slower: now 12 minutes, before 5 minutes (for a 24 m long video). Since I have 2 hours gameplay, this is a nightmare.

Is there some way to have more control over the render speed so that it is not 100 but slightly faster? Maybe there is some option in the AMD Adrenaline app that I can set so my graphic card is not overclocking during davinci?

Your "choppy export" problem seems to happen when rendering the end of a long timeline. The system would tend but be under greater thermal stress at that point. Are you saying your system is overclocked? How do you know it's stable under sustained high-intensive CPU and GPU loads, which is what Resolve causes? Can your system reliably run Prime95 and Furmark simultaneously for several hours?

Your situation was presented as a pure Resolve problem, and we've spent a lot of time laboring under that description. If you put all CPU, GPU and memory settings on default, (IOW no over-clocking whatsoever), does the Resolve H.265 choppy export problem still happen? Please do this test.

I didn't change any settings for overclocking. I used the word "overclocking" because the render speed. Maybe "overlock" is the wrong word. I meant: maybe the software adrenaline of amd should be optimized for davinci.. maybe the software should run the GPU a little bit slower to export the footage with no chop.
I saw that when I changed the render settings to 100 task manager told me that the GPU was working on 70%. When the render settings are to maximum the GPU works during the render at 100%..

There is another issue I want to report: DaVinci is not able to export footage in dnxhr hq 10 bit and even the PC is not able to run footage like that on vlc. (i don't know if it is relevant for our topic).

about the prime 95 and furmark, I have no idea what are they

Don't overclock anything for stable work in DR!

I used the word "overclocking" because the render speed. Maybe "overlock" is the wrong word. I meant: maybe the software adrenaline of amd should be optimized for Davinci.. maybe the software should run the GPU a little bit slower to export the footage with no chop. The question is now: how.
I noticed that when I changed the render settings to 100 task manager told me that the GPU was working on 70%. When the render settings are to maximum the GPU works during the render at 100%..

I've reviewed the previous posts. There is apparently a Resolve "Render Speed" adjustment on the Deliver Page, which is unique to the Windows version of Resolve. It is not on MacOS versions. The default is "Maximum" and it also allows user-selection to a percentage value. It seems that 100% is still more constrained than "Maximum."

The Resolve manual gives the example of Render Speed being reduced to avoid overloading a multi-user NAS server. It should never be required to avoid Resolve producing the wrong results or crashing.

The fact you lowered it below Maximum and your "choppy export" problem vanished implies there may be some system instability in your machine. Resolve should never produce damaged files or crash, even if that setting is on Maximum.

Resolve puts a lots of combined CPU and GPU load on any platform. If that platform is a Mac or a professionally-built workstation from Puget Systems, HP, Dell, etc, they have already been tested and will rarely crash or malfunction under high load.

If it's a self-built PC, then you must do the testing and verification to ensure the machine is reliable under the sustained high CPU and GPU loads that Resolve and other similar apps create. Otherwise you can fruitlessly spend lots of your own and others' time trying to fix a software problem which is actually caused by the system layer.

Prime95 is a free CPU stress program and Furmark is a GPU stress program. Since Resolve creates simultaneous intense CPU and GPU stress, it would be expected that a PC should be able to concurrently run Prime95 and Furmark for an extended period (e.g, a few hours) without crashing, hanging or damaging any data.

This forum is very helpful and cooperative about making suggestions -- even going well beyond the Resolve domain -- but we are not system integrators. The presumption is you have already tested your machine. If you have not, there are lots of PC-specific forums which are focused on troubleshooting self-built PCs.

In general I'd suggest you verify your machine is stable under the high sustained CPU+GPU stress that is typical of Resolve and other similar apps. Running Prime95 and Furmark simultaneously for an extended period is one possible way, but I am not an expert at this. Maybe others have suggestions.

I've reviewed the previous posts. There is apparently a Resolve "Render Speed" adjustment on the Deliver Page, which is unique to the Windows version of Resolve. It is not on MacOS versions. The default is "Maximum" and it also allows user-selection to a percentage value. It seems that 100% is still more constrained than "Maximum."

The Resolve manual gives the example of Render Speed being reduced to avoid overloading a multi-user NAS server. It should never be required to avoid Resolve producing the wrong results or crashing.

The fact you lowered it below Maximum and your "choppy export" problem vanished implies there may be some system instability in your machine. Resolve should never produce damaged files or crash, even if that setting is on Maximum.

Resolve puts a lots of combined CPU and GPU load on any platform. If that platform is a Mac or a professionally-built workstation from Puget Systems, HP, Dell, etc, they have already been tested and will rarely crash or malfunction under high load.

If it's a self-built PC, then you must do the testing and verification to ensure the machine is reliable under the sustained high CPU and GPU loads that Resolve and other similar apps create. Otherwise you can fruitlessly spend lots of your own and others' time trying to fix a software problem which is actually caused by the system layer.

Prime95 is a free CPU stress program and Furmark is a GPU stress program. Since Resolve creates simultaneous intense CPU and GPU stress, it would be expected that a PC should be able to concurrently run Prime95 and Furmark for an extended period (e.g, a few hours) without crashing, hanging or damaging any data.

This forum is very helpful and cooperative about making suggestions -- even going well beyond the Resolve domain -- but we are not system integrators. The presumption is you have already tested your machine. If you have not, there are lots of PC-specific forums which are focused on troubleshooting self-built PCs.

In general I'd suggest you verify your machine is stable under the high sustained CPU+GPU stress that is typical of Resolve and other similar apps. Running Prime95 and Furmark simultaneously for an extended period is one possible way, but I am not an expert at this. Maybe others have suggestions.

I appreciate a lot your help. It is not a self-built pc but a pc built in a shop by professionals and that stress test was already made before they gave me the pc.

It is not a self-built pc but a pc built in a shop by professionals and that stress test was already made before they gave me the pc.

If there are rendering issues when using GPU but not using CPU that points at GPU as likely culprit but it is still possible something is wrong with clip as GPU often doesn't handle issues as gracefully as CPU does.

If issues completely go away just by adding small black clip at the end that indicates nothing is wrong with a clip and it is something about how GPU handled end of that timeline. Voltages at the end drop and that can result in instability.

If issue completely goes away even without adding black clip at the end by throttling down power GPU is using that further indicates GPU is unstable. You might not think it is overclocked but many manufacturers push their cards beyond AMD/Nvidia default settings which can end up a problem. One way to check for that on Nvidia is to put drivers in "debug mode".

Your PC shop might have claimed they tested your system but very few test each and every system as thoroughly as it should be because that would take many hours so always trust but verify. Besides, things could've changed since the time they've done it. Running FurMark and Prime95 is one of the most demanding tests you can do but running Prime95 correctly isn't straightforward for beginners so you should check out OCCT.

It is not a self-built pc but a pc built in a shop by professionals and that stress test was already made before they gave me the pc.

If there are rendering issues when using GPU but not using CPU that points at GPU as likely culprit but it is still possible something is wrong with clip as GPU often doesn't handle issues as gracefully as CPU does.

If issues completely go away just by adding small black clip at the end that indicates nothing is wrong with a clip and it is something about how GPU handled end of that timeline. Voltages at the end drop and that can result in instability.

If issue completely goes away even without adding black clip at the end by throttling down power GPU is using that further indicates GPU is unstable. You might not think it is overclocked but many manufacturers push their cards beyond AMD/Nvidia default settings which can end up a problem. One way to check for that on Nvidia is to put drivers in "debug mode".

Your PC shop might have claimed they tested your system but very few test each and every system as thoroughly as it should be because that would take many hours so always trust but verify. Besides, things could've changed since the time they've done it. Running FurMark and Prime95 is one of the most demanding tests you can do but running Prime95 correctly isn't straightforward for beginners so you should check out OCCT.

the rendering issue was also with the CPU render.
you mean I should make the test with an app called OCCT because is easier?

...the rendering issue was also with the CPU render.
you mean I should make the test with an app called OCCT because is easier?

This is a terminology problem which we have brought upon ourselves. The export process involves two distinct stages: rendering and encoding. Rendering applies edit directives, effects, and transformations and creates a rendered intermediate form, typically a flattened file containing all timeline layers for a given range. The rendering process utilizes the GPU's texture, shader, and streaming units. Encoding, on the other hand, compresses the rendered frames into the desired output codec, often using dedicated hardware encoding blocks bundled on (but functionally separate from) the GPUs. For Intel CPUs, that IP block is the Quick Sync fixed-function encoding hardware on the CPU.

While "render" is commonly used to describe the entire export process, it technically refers only to the processing of effects and edits on a clip or timeline, whereas "export" encompasses both rendering and encoding stages.

The previous discussion about "CPU render" actually did not refer to rendering at all. That was about encoding the already-rendered buffers by either CPU methods or the media acceleration hardware (which is totally separate from the GPU hardware, even though it may be bundled on the GPU card).

So just because you previously tried using CPU vs "GPU" *encoding* does not mean the bulk of the GPU was tested by that procedure. It is possible during a long export, the GPU gets too hot, is somehow hitting a power supply limit or similar.

This might be a useful test: take your existing timeline, put the Deliver Page's "render speed" on maximum, set an I/O range on the tail of the timeline to bracket the M50 clip and see if that exports without any dropped frames. That will be using the exact same clip with the same effects in the same timeline position as normal, just without heating up the GPU beforehand.

the rendering issue was also with the CPU render.

I stand corrected as I have lost track of things you tried. None the less, if issue goes away just because you added short black clip after the part on which it was crashing before then things still point to video card instability as voltages are throttling down at the end.

EDIT: I went back and re-read your posts. In one of them you said export using DNxHR HQ was fine. DNxHR HQ is purely CPU based codec.

you mean I should make the test with an app called OCCT because is easier?

Yes, OCCT is a stress testing app that is more user friendly than Prime95. It still requires users to understand what they are testing (for example, many beginners think their CPU passed and wonder why it is still crashing while they were unaware their CPU has AVX2/AVX3 instruction sets that need to be tested for too).