Nothing obvious for me in there although im still getting crashes on rendering using any form of noise reduction (GPU VRAM i suspect) so maybe “stability improvements” would help.
Same - and some other GPU intensive tasks.
I’m running close to their min spec laptop that has a 7 year old GPU.
I think they just expect people to have better computers if they want to use the serious shit, and don’t expect them to do much about it.
I have found that when it crashes whilst setting up / testing noise reduction, it will actually Deliver without crashing. So using in/outs in the Deliver settings can be a way to check the result for a small section of the timeline.
Chances are it won’t be long before they up the min specs, too.
Ahh im finding the opposite.
NVidia 1050TI (an old Dell XPS15, 2018 i think).
I don’t get crashes on actual editing but 100% of the time on deliver if theres a NR node.
Workaround i’ve found is do the editing, render cache that node then on deliver select “used pre-rendered images”. Then it goes no problem at all.
So for me its something specific in the deliver module itself not the noise reduction as its fine in the colour and edit page once cached.
Resolve is far more powerful than Premiere for me (im in the process of learning and switching) but Premiere Pro is far far softer on specs needed. Never had it crash. Slow yes but never crash.
Ultimately i need to use maybe 5% of what Resolve can offer. Mainly colour corrections, stabilisation, noise reduction and some masking. Im never going to need full Fusion, Fairlight etc.
I much prefer it over Premiere but the crashing out on minimum spec is causing irritating.
I’ve seen many pro colourists, with hefty hardware, say that they’ve abandoned Premiere in favour of Resolve because they experience greater stability with Resolve (all platforms) - and that 18 is even more stable than some reported with 17.
Only had GPU memory related crashes myself … so no biggie. One day I’m have the spare time to warrant investing in something with bigger balls.
Mine is GPU VRAM all the time for sure - i can see it filling up than just disappears to desktop. Sometimes i get a warning about application being denied access to graphics hardware.
The work around is “ok”.
I do a lot of underwater video so the colour correction power of Resolve is very useful for me - its vastly superior to Premiere.
1 Like
Usually mine crashes when trying to open, GPU not opening, which then forces a shut of the program. I usually find restarting computer and then opening DV Resolve first and it will open, after that dont get any crashes, and we are running close to minimum spec…
That month seemed to go by rather quickly! Anyway …
Nothing at all exciting …
What’s new in DaVinci Resolve 18.1.4
• Improved load performance for timelines with a large number of markers.
• Ability to cancel the grab all stills process.
• Support for monochrome decode mode for ARRI raw clips.
• Sync bin views now use creation date instead of modified date.
• Creation date is now preserved by Proxy Generator.
• Addressed an issue with Resolve FX Dehaze in DaVinci Wide Gamut.
• Addressed missing audio when scrubbing in the sync bin.
• Duration markers created from in-out ranges now use the last set color.
• Addressed internet upload issues for file names with non-ascii characters.
• Addressed an intermittent issue trimming gaps with a speed editor.
• Addressed an issue with Resolve FX keyers on the Fusion page.
• Addressed an issue with delete empty tracks deleting locked tracks.
• General performance and stability improvements.
2 Likes
The DeHaze changes maybe of use. Im using that effect more and more in my drone footage.
Still waiting for the “stability improvement” where it wont randomly crash to desktop when the GPU VRAM fills.
wish they would add the 10 bit in the free version haha
As I recall saying above … I think that will be a long wait that will never end.
As for me - it will be new hardware our end that’s needed.
Dehaze works OK for me - but I don’t (usually) use DaVinci Wide Gamut in my workspace environment.
I do occasionally use the Wide Gamut with dehaze (not often) so it might be useful for me in that respect.
I’ve just about got functioning work arounds for most of the crashes now (other than the in-built denoise but NeatVideo takes over that for me) but its still a little confusing how identical resolutions and renders can be so unstable on Resolve v Premiere. Its definitely a coding issue but as you said, one they’re unlikely to bother addressing. Min-spec laptop users aren’t their main market.
Yesterday I may have accidentally stumbled upon a brilliant solution for noise reductions tripping GPU Memory errors on my marginal spec 7 year old laptop.
It was processing 16-bit TIFFs at DSLR resolutions into 8k video using quite onerous levels of de-noise … and it didn’t flip once!
Wanted to complete what I was doing before mucking about and testing the theory further … which I’ll do soon and report back.
1 Like
Any update…
I’d say I’ve found it to be 80%+ successful.
Basically, rather than applying the noise reduction to the clip it self, I added an Adjustment Clip above the video clip, and then added noise reduction to that. It achieves the exact same result.
Has it still flipped? Yes. But only when chucking double noise-reduction (plus other shit) at it by having a second Adjustment Clip … again with the most aggressive noise reduction settings. (The visual result wasn’t great … but that wasn’t my objective.)
I found I was able to move around the timeline in the colour tab (and edit) without it freaking out. Response is understandably slow with what it had to do each time I moved the play-head … but mostly very stable.
The only caveat, so far, is that I’ve only tried this with a time-lapse image series … albeit very hi-res 16-bit TIFFs, as above. (It takes an unsurprising age to render! 
)
I’ve not tried this over 4k video … but I can’t see that it should behave any differently. Indeed - 10-bit D-Log should be easier … 
other than it’s also decompressing the video.
With that in mind, if 4k doesn’t work as well using this “trick”, then low/zero compression proxies should achieve the same whilst in the colour/edit tabs. (Not that they help when rendering, of course.)
Although … … being in a 4k timeline, and with a prior adjustment clip applying a transform to the time-lapse image sequence … it may have already dropped the resolution to 4k before it gets processed by the noise reduction Adjustment Clip. (As in, a subsequent transform would be treating the output from the first as 4k without the spare pixels that existed in the original images.) I’m not totally certain how DR hands data from one Adjustment Clip to the next.
I’ll give it a go. Mine craps out on 4k/25 and anything higher. Always on final render. Never elsewhere.
The workaround i use is to run the NR, then create a render cache. Then on deliver tick the option to use that instead of doing it live.
Then it always works. Which leads me to think its a bug/quirk ONLY of the final render code.
Downsides are having to repeat that process every time you adjust the NR or anything before it in the tree.
Strange - as before, somewhere - I’ve normally only experienced issues whilst in the colour tab (mainly) and sometimes edit tab … and rendering has been relatively OK.
Used to turn the NR node off until I’d done everything, then turn it on immediately before nipping to the Deliver tab.
OK ive never found that.
Looking a HW monitoring i can see the GPU VRAM slowly fill and when full the application just vanishes to the desktop.
By pre-caching as images ive never had it crash. However as above its not optimal as a workaround and makes the editing process very slow.
The other thing that’s changed for me … since I last recall having issues … I’ve doubled my RAM from 16GB to 32GB.
Perhaps that’s removed some burden from the GPU … no idea.
Can’t recall if it’s the Dedicated or Shared GPU memory that totally maxes out when rendering. But it nearly always has done, even without NR in play.