Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 9th March 2019, 23:07   #1  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,419
max_cache_size frames?

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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 10th March 2019, 19:42   #2  |  Link
_Al_
Registered User
 
Join Date: May 2011
Posts: 216
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 this to work with memory, using stride instead of width, not sure if it could be different:
Code:
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?

Last edited by _Al_; 10th March 2019 at 20:12.
_Al_ is offline   Reply With Quote
Old 10th March 2019, 22:31   #3  |  Link
jackoneill
unsigned int
 
jackoneill's Avatar
 
Join Date: Oct 2012
Location: 🇪🇺
Posts: 730
Quote:
Originally Posted by asarian View Post
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.
__________________
Buy me a "coffee" and/or hire me to write code!
jackoneill is offline   Reply With Quote
Old 11th March 2019, 02:29   #4  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,419
Quote:
Originally Posted by jackoneill View Post
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).
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Old 11th March 2019, 02:34   #5  |  Link
asarian
Registered User
 
Join Date: May 2005
Posts: 1,419
Quote:
Originally Posted by _Al_ View Post
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 this to work with memory, using stride instead of width, not sure if it could be different:
Code:
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.

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.
__________________
Gorgeous, delicious, deculture!
asarian is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 08:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.