Neat Video not respecting clip retiming - 17.1 / NV 5.4.0

Greetings community, cross-posting from NeatVideo's forum.

NeatVideo OFX 5.4.0 appears to not respect clip speed/retming settings in Resolve v17.1.

Temporal filtering introduces incorrect frames in shots that have been slowed down, sped up, or reversed at 100%. Of course this could be a bug on Resolve's side and how it supplies adjacent retimed frames...

I've tried altering, with no change:

- Noise profile generic vs. custom.
- Temporal NR quality, radius.
- Render settings (CPU vs. GPU vs. both).
- Node and clip-level caching.
- New project vs. existing project.

Disabling NV temporal NR fixes the issue.

Anything else you can recommend, or a bug fix?

I've seen NeatVideo's Resolve known issues, but the clips showing problems are not standard, not nested/compound, and are progressive @ 24 fps.

(Logs sent to BMD support via email) — system details: Mac Pro 5,1 / AMD RX580 / MacOS Catalina 10.15.7 / Resolve 17.1 build 24 / NeatVideo 5.4.0

Thanks!
Stephen

I think you might need to change your work flow a bit such that the two effects are separated.

Apply the speed changes first, then the NR. Couple ways you might do that.

1. Use the new Render in Place feature on the re-timed clip, then add the NR to to that.
2. Create a Compound Clip of the re-timed clip, then add NR to the Compound.

Hi Jim,

Thanks for the suggestion. Rendering out 'mezzanine' shots is possible as a last resort, but is a rather clunky workaround:

1. This worked fine in DR 17.0 / NV 5.3.0.
2. This is on an existing project with ~150 noise reduction shots.
3. NeatVideo does not do temporal NR on compound clips (nor on timeline nodes), as explained in their note about Known issues with Resolve.

So, I will hold out for a proper fix just a little while longer...

BTW, I also tried all of Resolve's retiming/blending options, to no avail. "Nearest" doesn't appear to be working at all once passed through NeatVideo, "Frame blended" has no effect, "Optical Flow" changes the appearance but not the nature of the error.

Regards,
Stephen

1. Use the new Render in Place feature on the re-timed clip, then add the NR to to that.

Render in Place is an interesting feature, I will dig more into that...

Over on their forum, Neat Video confirmed the issue as reproducible on their side. No solution yet, I'll post here if anything changes.

Same Problem here

on Win 10 and catalina 10.15.7

davinci 17.1

NV 5.4

I think Jim has the best idea: Render in Place would be a good workaround. My guess is that Neat Video trips up when it looks at blended frames or any kind of non-standard (unpredictable) speeds and weird frame boundaries.

What kind of method are you using for the speed change? We've generally had good luck with Optical Flow+Enhanced Better, with a minimum of frame/field artifacts. Try that and see if anything changes. Worst cases, particularly large slow-downs, look best with Optical Flow+Speed Warp, but that's really resource-intensive.

Another possibility would be to render out the entire show without NR to a mezzanine format, then apply the NR to the rendered file. I've had good luck with this method on complex projects with tons of nodes and so on. I still chop up the rendered file so that Neat is aware of scene boundaries and so on, and I use different settings for Neat depending on scene content -- even bypass it entirely if it isn't needed.

Hi Marc,

Thanks for your reply, sorry for the long delay on my side.

I did try all different speed change rendering methods — they produced the same glitches (batches of frames fed from all over the clip). In the end I went with render-in-place, just another video layer to keep everything sane on the timeline.

I'm opposed to a full mezzanine before NR, but only on a philosophical basis: "It's just computation, it should just work!" But in reality and on a deadline, that's a good intermediate step, too.

Stephen

If possible, I would suggest looking for a way to apply the noise reduction BEFORE the retiming instead of after.

Hi Frank.

Yes, that's reasonable. But I don't think Resolve gives you control of the processing order.

For simplicity in my timeline, I opted for the reverse with the render–in–place technique: bake out the retiming, then apply the NR to a native framerate export.

Stephen

I'm opposed to a full mezzanine before NR, but only on a philosophical basis: "It's just computation, it should just work!" But in reality and on a deadline, that's a good intermediate step, too.

To me, sometimes it's just a necessary step because of the realities of life and the limitations of available hardware. Neat is slow as molasses (even when you optimize it for your specific system and available GPUs), and if it's eating up 75% of your resources, that doesn't leave much else available for color, sharpening, keys, secondaries, and all the other very complex processing that Resolve can do.

I think as long as it's a very high-quality codec (like ProRes 444 or DNxHR 444), I'd call that "visually lossless" to the point where it won't change the pictures at all. Another good thing about doing it this way is you can off-load the project to a different system and let it process the NR while you move on with other projects on your main system. Even if the NR is happening at 2-3fps, it won't slow you down or prevent you from doing other things.