Quote:
Originally Posted by jackoneill
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).