Timeline Rendering in Resolve - what's the deal?

[Craig Melville]

I find on long complex timelines, Resolve's timeline rendering behaves in unpredictable and weird ways. I've experimented with both Smart and User modes and caching individual node, and using the Cache colour output methods.  I find  on big projects timeline turns blue in parts, then those blue patches become red again. So unlike other editing software, I can't assume that the rendered areas are fully rendered and I can't trust that they will stay rendered. That becomes a major issue when I'm relying on the timeline's rendered cache to speed up exports. It's not a big deal on a 2 minute edit but when it's a 30 minute program with 8K raw footage inside it, it's the difference between exporting a timeline in 5 minutes vs several hours.  I've noticed this behavior for years, but I've never got to the bottom of what's going on. I assume the timeline is doing multiple passes at different node layers. But hard to tell. And it's then hard to tell when it will decide that everything will need to be re-rendered. Any clues as to what's going on here? I've got lots of RAM 127 GB, 10 core 3.2 GBZ i9 iMac and lots of SSD Cache. And I've deleted the cache. etc.     

https://vimeo.com/561671441

 

Edited June 11, 2021 by Craig Melville

[Ryan Wood]

Would love an explanation for this as well. And any work arounds. I work in commercial edit, and I have clients in session. I am worried about switching from Flame to Resolve for the simple problem of not knowing if I will get stutter or not. I know render in place is supposed to fix that. Much like a "hard commit." But even render in place, I will not often, but sometimes still get a stutter. 

[Craig Melville]

Hey Ryan, I feel your pain. I've done a lot of experimenting on this in the last few days and I think I have a few workable clues I can share:

• If you are using Neat Video it causes problems. Even in a 2k Timeline is causes weird rendering behaviour. And I assume if Neat Video can cause this issue, perhaps other OFX plugins can do this too.

To work around this I tried a bunch of things - playing around with optimized media, changing the GPU setting in Neat etc. None of those worked. I optimized R3d files onto an external SSD which gets about 800MB/sec and was using a 2k timeline.  Original material was 8K r3ds.

What did finally work was making sure all the media and cache files were on an extermely fast SSD drive (I bought a Thunderblade 8TB drive which gets 2400MB/sec). When the original R3d file were on a slower RAID, and even when the Media was optimized onto an SSD it still caused issue of cache disappearing like the above clip. So even though you'd assume the system is reading from the SSD it is somehow seems like its calling on the original media. Which seems totally stupid (if that indeed is what's happening). Surely once it's cached to a fast drive it should not need to do anything with the original media. But clearly something else is going on under the hood.  

- Once everything was on SSD drive that weird disappearing blue line issue also resolved itself. It began caching correctly and overall the performance of the system felt a lot less buggy / crashy. HOWEVER. even though the blue line would stay put and render nicely, I'd get playback issue after that caching had happened. The blue cached timeline area would play at 10-20 FPS. HOWEVER #2: When I restarted Resolve it would play fine. So something bad happens when Resolve caches complex plug-ins - that breaks the playback system temporarily.

- Also you are correct - when the problem clips are "rendered in place" the playback would work fine and that would work straight away without restarting Resolve. I could even get 8K timelines to render in place and playback on my iMac at 23.976. But if I tried to cache those in the timeline (as opposed to Render in Place) it would often  crash the software and the OS. 

- I did notice that upgrading to  Big Sur seemed to fix the worst of the major crashes. In Catalina these complex Neat Video processing  would freeze the whole computer and the iMac would restart. But on Big Sur the worst it would do would be to beach ball.

With the above issue all forms of caching in the timeline did not really have any noticeable effect on stopping the disappearing render and playback issues (prior to the SSD fix) .  I had many examples where the node was cached and blue but the timeline would not cache. Again this issue seems to be fixed by using the SSD.

I really wish I understood what the heck is goin on here. It's super counter intuitive. Surly if the timeline is blue and the cache is on a fast SSD it should play. But this is not the case unless you know all these above tricks.  

Even when I tried optimizing the material to tiny resolution and they trying to playback it would not cache and playback would still give less than realtime playback. However - as mentioned, after restarting Resolve, the cached area would play back fine. And then even when I rendered things further down the timeline they would work - which is very inconsistent behavior. 

My best theory is that Neat Video breaks something in the timeline render process. And I'm not convinced this is a purely hardware related issue. The fact I can actually get the system to render in place an 8K Neat video clip and get it to work and playback fine indicates that the system I have is capable of rendering something x4 bigger. Yet when I try to do the same task but in  2k timeline (not Render in Place) I can not get realtime playback after that task has completed - that to me feels like a failure in the timeline rendering system to manage the process.

I'm ruining on a iMac 10 core i9 with 128 GB of RAM and a 16 GB GPU. And I was still getting these issues when I switch the Neat Video plugin to only render using CPU. 

I've used Neat video in Premiere on the same timeline settings on computers that have 1/4 of the performance of this systems. So something is definitely wrong here. 

• Separate but related issue, I know early versions of Look Designer OFX plug-in have issues because each clip as it would play would do a security check for licensing. So that cause weird playback - the solution was to create a LUT and just use that to regain realtime playback.   This is no longer an issue - but that would drive me crazy too. 

• The caching system in general is very odd in Resolve.  

So in summary: 

1) Beware of Neat Video and other plugins. And remember that caching them with user /smart or Node Caching is no guarantee they will playback or not cause weird issues in the timeline rendering system AND the could cause temporary non-realtime playback issues.

2) Put everything on SSDs - HDD Raids seem to cause issues even if the cache drive / optimized media is on an SSD.

3) Once timeline clips are blue you may still need to restart Resolve to regain realtime playback.

4) "Render in Place" is a much more stable way of making sure the timeline plays back. Render in Place will render far more complex plugins without crashing and at higher resolutions. Also  it is much less susceptible to being lost due to a crash. And I guess you can even drag in the actual files if you got desperate.  One note on that - If you do select a bunch of files to Render in place and the system crashes you will lose all the renders. Even if Live save is one and the system is autosaving. That is a stupid design. Imagine leaving a 30 minute episode to render and you come back hours later to find the whole thing has failed. The you'll have to baby sit individual batches of smaller "Render in Place".   

5) One other thing I learnt is some of the caching modes (I think Smart mode does this)  will render all the version you have of grades on clips. So if you have 20 grade versions on a clip the system will render all of those. That could really cause a massive delay to rendering and increase the likelihood of a crash or cause the system to seem like it is crashing.  You can delete the unused grades in the color page. 

6) one other thing I found was Turing "Render Colour output" to off  sometimes seemed to stop the weird disappearing cache behavior.  No idea why that would make a difference but toggling that did seem to fix it.

I've been in touch with Blackmagic and reported this issue and I've sent them videos.   But you should also submit your experience to make sure the system is improved and the bugs are figured out. 

 

Some of these things don't matter so much when you're just focused on color but for finishing they can be a real deal breaker. 

 

[Marc Wielage]

On 6/18/2021 at 3:00 PM, Craig Melville said:

1) Beware of Neat Video and other plugins. And remember that caching them with user /smart or Node Caching is no guarantee they will playback or not cause weird issues in the timeline rendering system AND the could cause temporary non-realtime playback issues.

I'm actually OK with Neat Video, but I generally only use it as a "second pass" technique. I'll render a timeline to a mezzanine format like ProRes 444 (or XQ), then take the flattened file apply Neat Video on a scene-by scene basis, and then render it again. For our purposes, 444 is what I'd call "visually lossless" and nothing is lost going down one more generation. We do make sure the Neat settings are optimized per sequence, and I'm not afraid to bypass it when it looks OK without any NR. We also optimize Neat for our specific GPUs, and it's actually reasonable, I think somewhere around 5-6fps without caching.

There is a school of thought where you can run the flattened Neat Video pass with the regular timeline, and do a composite or a blend based on screen content: in other words, not use 100% of the NR pass, but just a piece of it. My philosophy is to lean towards "less is more" processing with NR whenever possible. 

I agree that you have to do some strategizing with plug-ins and figure out what's going to drag the system down, what needs to be cached, what a reasonable node structure should be for a specific project, and so on. Every project has different challenges.

Difficult formats, like H.264 and so on, do present problems and we try to transcode those in advance whenever possible. "Render in Place" is a valuable tool and a welcome change in Resolve 17.