max_cache_size frames?

[asarian]

How many frames does VS actually cache with 'core.max_cache_size = 32768'?

Reason I ask, is because I received the dreaded 'Display driver nvlddmkm stopped responding and has successfully recovered' error, but my ca. 60 hours-taking rendering job that I have running... DIDN'T crash. Wut?! No way it could survive a display driver crash! (Nor do I see how x264 could survive without the driver (as it's running with OpenCL enabled).

So, long story short, could VS have stored thousands of frames, and that I'll only find out later, with a 'delayed' crash?! Because the 'Display driver nvlddmkm stopped responding' error alleged happened several hours ago already.

[_Al_]

raw size should be something:
Y plane size = bytes per sample x w x h
U and V size = bytes per sample x w x h / subsampling (4 if 420, 2 for if 422, 1 if 444)
then frame size is Y+U+V

for RGB it should be 3x bytes per sample x w x h

Chikuzen uses in his script (https://forum.doom9.org/showthread.php?p=1635348#post1635348) this to work with memory, using stride instead of width, not sure if it could be different:
frame = clip.get_frame(frame_number)
data = [(frame.get_read_ptr(p), frame.get_stride(p)) for p in planes]
buff = [b'\0' * data[p][1] * height for p in planes]
for p in planes:
memmove(buff[p], data[p][0], data[p][1] * height)
but you perhaps mean if there is a maximum of those frames in memory?

[jackoneill]

How many frames does VS actually cache with 'core.max_cache_size = 32768'?

Reason I ask, is because I received the dreaded 'Display driver nvlddmkm stopped responding and has successfully recovered' error, but my ca. 60 hours-taking rendering job that I have running... DIDN'T crash. Wut?! No way it could survive a display driver crash! (Nor do I see how x264 could survive without the driver (as it's running with OpenCL enabled).

So, long story short, could VS have stored thousands of frames, and that I'll only find out later, with a 'delayed' crash?! Because the 'Display driver nvlddmkm stopped responding' error alleged happened several hours ago already.

Maybe nothing bad happened because the driver "successfully recovered"? More successfully than you expect? (I don't know how drivers work.) Or maybe x264 can work around problems like this?

VapourSynth probably won't cache as many frames as you can fit in 32768 MiB. How many it will cache depends on the script. Using more temporal filters will result in more frames being cached.

[asarian]

Maybe nothing bad happened because the driver "successfully recovered"? More successfully than you expect? (I don't know how drivers work.) Or maybe x264 can work around problems like this?

VapourSynth probably won't cache as many frames as you can fit in 32768 MiB. How many it will cache depends on the script. Using more temporal filters will result in more frames being cached.

Usually, when the driver goes away, it's near instant death. :) And in driver-land, "successfully recovered" means TdrDelay was exceeded, after which Windows 10 will simply reset the driver (as in: kill it, and restart it). So, it really may be be possible VS actually had enough frames cached before requesting new ones (although an hour worth of it seems unlikely). And as for x264, when you run it with --opencl, it should (and normally will) crash immediately (with some sort of null-pointer error in the Event Log), as OpenCL is constantly being used. So, I'm still baffled. :)

Also, I heard VS only uses about 10% of max_cache_size for actual frames (and the rest goes towards filters). That should still be about 3G worth of frames (in this case, low-res DVD ones).

[asarian]

raw size should be something:
Y plane size = bytes per sample x w x h
U and V size = bytes per sample x w x h / subsampling (4 if 420, 2 for if 422, 1 if 444)
then frame size is Y+U+V

for RGB it should be 3x bytes per sample x w x h

Chikuzen uses in his script (https://forum.doom9.org/showthread.php?p=1635348#post1635348) this to work with memory, using stride instead of width, not sure if it could be different:
frame = clip.get_frame(frame_number)
data = [(frame.get_read_ptr(p), frame.get_stride(p)) for p in planes]
buff = [b'\0' * data[p][1] * height for p in planes]
for p in planes:
memmove(buff[p], data[p][0], data[p][1] * height)
but you perhaps mean if there is a maximum of those frames in memory?

Thanks for the math. :thanks:

No, I didn't mean maximum number of frames per se; was just curious as to how many (ballpark figure) VS was keeping cached, to try and determine how it could be my process was still running after the driver crash.