Dermot Shane wrote:i do not see that issue here, retimming useing optical flow does not cause a crash
as a test i took a Helium @ 8k source clip, on a DCi4k timeline, and ramped it up and down, slowed it to a stop, speed it up from a stop, ran it fast, ran it slow.. a total of 30 min of a 4k timeline, set it to render the timeline to DCi4k dpx, scaling at best, debayer at best, and let it go
ran for about 15 min, CPU @ 60%, GPU @ 15%, target disk @ 12%, source disk @ 100%, approx 5 Fps render speed
so i was disk bound, by the source footage disk on USB3, but no crashes in 15 min, no particular stress on the machine, all threads where running around the same
could you post a .drp with a single timeline containing single clip, use generator to create bars as the source, with a speed effect that causes your machine to crash? that should make it easy to replacate / validate the fault on other machines
what does taskmanager say if you leave it on top while rendering a opticalflow retime? is either CPU, ram or GPU running at 100%?
+1
Same here on a HD project (18 to 25 fps)
Retime Process : Optical Flow
Motion Estimation : Enhenced Better
Motion Range : Large
Play without cache : 15.5 to 16 fps fps... (OK HD project...
)
but with Timeline node :
1 node TNR 3 + SNR Faster
1 node Radius
1 node 1 OFX Shadows and HighLight
1 node LGG