26

(29 replies, posted in Using SVP)

MAG79 wrote:

As wroted in given topic "AvisynthPluginInit2" error was connected to Intel GPUs and some MTModes.
What GPU are you using?

It is Nvidia in every PC.  I didn't know there was anything else.  Several different cards/adapters.  Nvidia is driver in each.  Some have only 16 cuda cores; one has 192.

I'm not good at knowing or remembering what MTModes are or do, but I do believe that the two I always use are necessary and I have them in nearly every script at certain spots:
SetMTMode(3,threads)    # very near the top
SetMTMode(2)   # very near the bottom, right before the InterFrame call.

27

(29 replies, posted in Using SVP)

MAG79 wrote:

You can use information from official SVP changelog. See chapters about SVPflow.

SVPFlow plugins are not compatible to AviSynth 2.5 since version 4.0.0.132 - 2016-03-18.
AviSynth 2.6 is supported.
What version of AviSynth are you using?

And you are right. I think GDF needs to be updated to use with latest SVPFlow plugin. wink

A few months back I got wind of the need (I forget in what context) to change to 2.6

And I've been thinking I would volunteer to start a new thread devoted to GDF 4 and 5, with current source for both.  (Yes 4 is still needed.)

28

(29 replies, posted in Using SVP)

MAG79 wrote:

Are you using svpflow2.dll from SVP4?
File Size 670 720 bytes
File version 4.0.0.136

___
The same error about"AvisynthPluginInit2" was early discussed here: Recent crashes

Apparently not.  My file version is 2.0.2.0, size 647,680.

I use InterFrame and GameDropFix in my scripts, and that's all.  I've never been aware of how to be on a mailing list for news of needed updates.  If you can direct me to more current svp*.dlls (as well as confirm that I need two of them, svpflow1.dll and svpflow2.dll), I'll appreciate.  And would there be any needed changes to InterFrame or GDF?  FYI, my script function avsi files as well as svp (and other) dlls are in C:\Program Files (x86)\AviSynth\plugins

Windows 10, 64-bit, but all video software is intentionally 32-bit.

(I did skim over that thread, and felt comforted that I was not alone in "sudden crashes without explanation", but much of it was cryptic to me.)

29

(29 replies, posted in Using SVP)

... and this after months of running many scripts sometimes many per day.  Is there anyone here that can interpret a Vdub crash dump?  (See attached.)  I've created hundreds of Avisynth scripts that use Svpflow2 indirectly through Interframe and GameDropFix both versions 4 and 5, and I've NEVER gotten this.  It gets to a certain point in a certain video and blows up.  (And it's relatively early in the video, about 3600 frames.)

Uh, I think I should hasten to add that when this occurs, Interframe is not even being used, as I comment out everything after SR() for this testing.  Therefore Interframe is not being used.  (I constantly add and take away "__END__" lines during script building/testing.)

MAG79 wrote:

What Preset you using in InterFrame with "Film" tuning?

I repeat, your question doesn't make sense to me.  The line to call Interframe is:

Interframe(Cores=4, Tuning="Film", GPU=true)

So "Film" is the value I set for "Tuning".  The parameters to Interframe are the only way (to my knowledge) to send info *into* Interframe.  Those parameters (3 in this case) are what I "preset" Interframe to.

As to the absence of further action by either of us these several months, (1) I don't know why you've not responded.  And (2), my video circumstances have changed to where most of the files I deal with do NOT need the SR() tool to smart-resize to a larger size.  But I still do have many files where I must use both GDF and SR(), and GDFv5 is still crashing or hanging the system ONLY when SR() is included.  You can use SR() for free, as the artifacts shouldn't affect this test for crashing.

To get around this problem I have to do something very aggravating.  I have to revert to GDFv4.  But when I do that, I cannot run my whole video (1.5 to 2.5 hours long) through Avisynth/Vdub processing in one piece or it will crash due to the memory leak problem of GDFv4.  But it is very tedious to have to break up my video into 20 min. pieces, then after creating the several AVIs, concatenate them back together.  It would be so nice if we could find out why GDFv5 is crashing whenever SR() is present.

MAG79 wrote:

Thanks. It works. I got all your files. I will look them.
What Preset you using in InterFrame with "Film" tuning?

I don't know what you mean.  "Film" IS the preset, the value I give to "Tuning=".  See my Interframe line at the end of the script 2015-10-31.wv.WichSt-v-MoSt.x264v-q20.0720p60.pcm.avs.  Is there some place OTHER than function arguments where something with regard to Interframe gets set?

MAG79 wrote:

TCmullet
Can't download file TCMullet's-GDF-test-scripts2.zip.

File not found

Rats.  I forgot that apostrophes don't come through.  It should work now.  (Welcome back, friend.)

MAG79, in addition to my question above about the Tuning="Film" feature, I have to report some major problems.  These are on the very first file I'm tackling after the NH-v-FL file I supplied earlier.

My new file and script is here:
http://www.tomsgoodfiles.com/DaveP/2015 … 3.Xraw.mp4
http://www.tomsgoodfiles.com/DaveP/TCMullet's-GDF-test-scripts2.zip

1.  Vdub was blowing up for various strange reasons, an often one being, "An out-of-bounds memory access occurred in module 'svpflow1'...  ...reading address 17e8fced."  When I backed out the SetMTMode(1) just after AudioDub(), the problem cleared up.  (At least I was able to go forward.)

2.  The prior file was one of many of mine that did not need resizing.  This one is one of many that do.  (It is 1136x640.)  I use the SR() function as, SR(1280,720) after GameDropFix, as you can see in the script for the new video (WichSt-v-MoSt).  The SR is Super-Res, a moderately-priced licensed product that I've used as needed for several years, and is available here:
http://www.infognition.com/super_resolution_avisynth/
You can use it for free, but the result has visual artifacts, which are probably okay for these tests.

As I build the script, (adding functions, cutting out commercials), etc., I get down to where I experiment with GameDropFix.  Once that is working, I add (uncomment) my next item, which in this case is the SR() function.  The system HANGS.  The Vdub opens the file, but I cannot scroll forward even 1 frame before it hangs.  If I leave out the SR, it works.  If I leave out the GDFv5, it works.  If I include the SR and revert GDF to GDFv4, it works.  I have no idea why I cannot use GDFv5 and SR() together.  It just hangs with no error message of any kind, til I cancel it.  GDF5 must be doing something funky.  Would you please download my files (above) and try it out?

Thanks SO much for all this work, Mag!  I've just now been able to start to tackle usage.  I didn't even download more than the avsi (and change v4 to v5), and my script works!  (The script opens in Vdub and I can scrub forward a bit.)

The one item I am worried about is that when I first started using InterFrame, I was only able to get it to work with any degree of meaningfulness by using the Tuning="Film" setting.  I don't see how you are setting that in the case of DblFPS=true.  Could you please confirm that if I set DblFPS to true, that it will invoke the InterFrame logic with Tuning equal to "Film"?   (I will be very happy to now be able to leave out the InterFrame call in all cases where doubling the frame rate is exactly what I need.)

MAG79 wrote:

TCmullet
No file by your link: File not found (404)

I should have suspected there'd be a problem if I allowed an apostrophe to be in the file name.  When I tested the link, I didn't go as far as saving it, but believed if I got a save dialog, it would work.  No, it gave me a 404, too.  Had to rename it on the server to not have apostrophe, and respell the link.  It now woriks.  (Maybe bbcode has a way to allow, but didn't want to research it.)  Link now works.

Here is my tiny zip file of the several zipfiles.  I realize you don't need Interframe, but as my script uses it, I include it.  For our tests though, I envision us chopping off all of the script after GameDropFix4.
http://www.tomsgoodfiles.com/DaveP/TCMu … cripts.zip

MAG79 wrote:

TCmullet
Your video is on my hard disk. Thank you for the link.
I will use it for debug GameDropFix_v5 wink
It will take some time.

Thank you for getting it and telling me here.  I can understand lots of reasons why it might take a lot of time (both internally to the work and externally in that you have a life).

I propose some further work in connection with this.  I had not considered suggesting this in the past as I did not anticipate delivering a full video file to you.  But now that you have one, may I suggest that we work together to address something that has bothered me from day 1?  There are many times that GDF4 corrects a dupped frame incorrectly.  The part I could do for you is to locate (using this big video) a number of instances where it is incorrect (along with brief description by me of why I believe it is incorrect).  I have overlooked it because (1) I didn't think we could ever correct it, and (2) even when it generates objects incorrectly, it (2a) moves the background correctly and (2b) enduring these errors is much better than having no correction at all.  But maybe we can now attempt correction, now that I have shared a full video.  We'd have to be using the same script as basis, so I will package a zip file containing all my .avs and .avsi that are involved in this video, and upload it here.  (When I first started using GDF4, I was operating on huge temp files that had to be deleted.  But now I'm working with more "compact" Mp4 files that I intend to keep.  For all the many output files I've created using GDF4, I *am* interested in recreating them if we fix the mem. leak AND get the logic anomalies (wrongly fixed frames) solved.

Are you willing to receive from me small groups of frame numbers that I use GDF4 debug mode to identify for you?  Also I'd need to give you my main script and the few .avsi involved.  (My script does lots of chopping out frames, so we'd want to interrupt it near the end, cutting off items that would hinder our search.  You'll understand when you see the script again.)

Here's the link to the big MP4 file that you can use for testing:
http://www.tomsgoodfiles.com/DaveP/2015 … .rawX7.mp4

I can't leave it up indefinitely but will try to leave it up long enough for you to get it.  Please let me know when you have retrieved the entire 6+ GB file.  Uh, maybe I should package up all of the relevant avs and avsi files?

MAG79 wrote:

TCmullet
Can you share to me the file "2015-12-03.1900.wv.R3-Rnd1.NH-v-FL.sec+.rawX7.mp4" for test?

As you not answer me I went another way. ...

I didn't receive notification that you had replied.  Plus I've had to stay off these boards due to too consumed with work (really, this work, but many OTHER video files urgently needing my attention).

Thank you for trying to make logic for your NNJD example.  But all my files are much more random in dupped frames, which is why I really need GameDropFix.  I thought that if you saw what the folks over there at doom9 (via the link I gave) were trying to do, you'd pick up on it and implement the concept in GameDropFix.

Specifically, several appear to be reckoning that the memory-eat-up problem is inherently a part of "ScriptClip".  An Avisynth expert Gavino said "ScriptClip uses up memory in Avisynth's string table for each frame rendered.  Normally this is insignificant, but if it is called with a very long run-time script coupled with lots of source frames, it could eventually eat up a lot of memory.  See this post for the solution."  The post he refers to is this:
http://forum.doom9.org/showthread.php?p … ost1504566
It says to NOT have big content inside a ScriptClip function call (as GameDropFixV4 does), but rather have the voluminous code in it's own function, then call that function in a very brief ScriptClip call.  I figured you would have found that.  I got no emails from either this forum nor that one (doom9), and as I was very consumed with other work, I thought I'd wait y'all out.

Can you please look at at least the link I just gave you (even if you don't further follow what the folks at my first link have been doing)?  I'm hoping you can create GameDropFixv5 to have those ScriptClip calls be tiny by doing the technique at this link right here above.

And now to temporarily upload and make available to you the big Mp4 file you asked for (over 6GB).  I'll post the link after I get it online.

MAG79 wrote:

2. I mean: Start button - SVP - 4GB Patch - select VirtualDub.exe file - OK.
You will see message.

Does this program do the exact same thing that the program (LargeAddressAware.exe) here which I did run?:
http://www.techpowerup.com/forums/threa … re.112556/
If I run it again, it shows the current status has being modified and the former status as not modified.  Date stamp has been updated too.

(The above link was one of the hits in the google link provided by the fellow in the doom9 thread I gave you.)

I've been getting lots of blowups, but for various reasons beyond the one described above.  I've learned over on Doom9 that for 32-bit VirtualDub (any 32-bit software even if running on a 64-bit OS), there is a 2GB limit.  I was prompted to observe the "Process" tab in Task Manager and see that Virtualdub *32 was increasing to the point where memory in use for it was about 1.6GB.  This has been commonly observed by others who have run into it, whether via memory leaks or an app simply allocating too much memory.  So the direct causes of blowup are superficial.  Anything that would allocate memory correctly will blow up if we're already at the approx. 1.6GB limit (2GB minus overhead).

Here is the Doom9 thread.  At the moment, I'm working on two fronts: 1. Get rid of memory leaks that eat up memory, no matter how much memory is available, and 2. increase available memory to beyond the 2GB boundary. #1 is the ultimate solution, but #2 would get me some success in the interim.  So far I've not been able to get past the 1.6GB limit.  But the thread includes some research done by a kind soul there that seems to prove that MY biggest culprit is GameDropFix, and more specifically, the ScriptClip calls in it.  Please see that thread.  You'll see I mentioned I would pass this on to the GameDropFix author, which is you, Mag79.  Hope you'll look at it and into it, with regard to somehow plugging the leaks from GameDropFix/ScriptClip.
http://forum.doom9.org/showthread.php?t=173023

I'm using the smaller avisynth.dll that you all recommended

File version 2.5.8.6
Product name AvisynthMT 2.5
Product version 2, 5, 8, 0

(I get this from the .dll file itself, which is in the c:\windows\SysWOW64 folder.)

Yes, I can get further into my long programs.  But in most cases it still blows up, but closer to the end.

I now have a TON (dozens) of 1.5-2.5 hour videos that HAVE to have the GameDropFix function applied.  (And I foresee having more in the future in an ongoing basis.)  They all blow up, forcing me to the extremely unpleasantly tedious task of breaking the video up into 20-30 min. chunks, then stringing the resultant Virtualdub output chunks together.  I now have this on a 2nd and faster PC than my prior one.  The error message disappears, but one time I saw it and wrote it down in time:

"An out-of-bounds memory access (access violation) occurred in module
'nvopencl' ... ... reading address 000007dc."

I would GREATLY appreciate if I could package up the script files and put a link here to them and my big video file (11gb).  If I do, would you (Mag79) be willing to recreate my bombing situation with a view to finding where the bug is in this process?  Oh, the new machine has 24GB of ram, and I think I had the task manager up at the time, and it had not greatly increased the memory usage when the bomb occurred.  Months ago, when I did this on my original 4-core PC, I seem to recall that it DID increase memory usage til bombing.

My VirtualDub is 1.10.4 and my output codec (video) is the X264 encoder.  Audio out is PCM.

Also, I see that what I found is only 397KB.  Whereas the 2.6.0.5 is a whopping 1,784KB.  I saw something somewhere about 2.6 being less efficient.  Is this a case (just making this analogy up) of 2.6 being in COBOL and compiled to assembly vs 2.5 being directly written in assembler?  That would account for bigger size, slower performance and no additional functionality.

Will try, but I always have difficulty understanding about and deciding about so many "current" versions out there.  After searching I found this page:
https://www.svp-team.com/wiki/Download

The version there is 2.5.8.6.  It does say "MT" in the product name, and it's from the SVP site.  Is this what you meant?  And if it's the most current, why is there a creation date of 9/14/2012 (3 years old)???  This totally misleads me.  If this is not the one you meant, please give a link to what you did mean.  Thank you.

But while I'll proceed to change Avisynth version as you recommend (once you confirm this is the correct one), it doesn't address the cause, namely some kind of memory leak in something that's in something that's in GameDropFix.  (I'm speaking figuratively... I don't know where the leak is, other than that GameDropFix is the only thing that triggers it for me.)  If there's a problem there and it can't be easily fixed, I would prefer that that be admitted.  Then it's easier to proceed with temporary workaround.  (But I like to know that it's a workaround.)

So, back to your workaround...  Is this the version you meant?

Also, will I lose some kind... any kind of functionality that I have presently in 2.6.05 MT?

I was hesitant to go to the trouble of setting up and doing a several hour run merely to get it to bomb again, as I'm very behind and I wasn't sure if you would be willing to look at the bomb info.  But my next run required GameDropFix, so I elected to let it fully fly without breaking up into chunks. I actually thought it might finally finish after almost 5 hours.  Was surprisingly near the end, but it bombed.  Here's the data from VirtualDub:

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    VirtualDub.exe
  Application Version:    1.10.4.0
  Application Timestamp:    526d9abc
  Fault Module Name:    AviSynth.dll
  Fault Module Version:    2.6.0.5
  Fault Module Timestamp:    54c52eeb
  Exception Code:    c0000005
  Exception Offset:    0006cf53
  OS Version:    6.1.7601.2.1.0.256.1
  Locale ID:    1033
  Additional Information 1:    c4b7
  Additional Information 2:    c4b70ae33514c02d7dfd0bc5a628ea21
  Additional Information 3:    51ce
  Additional Information 4:    51ce8eb2bda31fa21b2d212415bc37da

Read our privacy statement online:
  http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
  C:\Windows\system32\en-US\erofflps.txt

This program was 1 hr 5 min. and the run got to 50 min. before the above crash.

This happens whenever I have used GameDropFixV4, whether inline or with your new function.  I hope someday we can find and fix the memory leak or whatever it is.  At the moment I must proceed to redo this program in 3 chunks (a real hassle).  But I have many more such programs to do, so if you find the solution, that will be very helpful no matter when it is.

Mag79, I've used this in multithreaded form several times already.  Thank you!

But both before you made it into a function when I was putting the code inline AND since then, there must be some kind of memory leak.  I have video programs that are 1.5 to 2.5 hours long.  Somewhere between 25 and 40 minutes in, Virtualdub blows up.  To get around this, I've had to create a Vdub AVI output for each segment that's about 20 minutes long.  20 seems to be below the threshold for blowing up, and 20 (or thereabouts) fits to a natural break in the program content.

I will be continuing to use GameDropFix frequently and ongoing.  Do you have any idea of where to look for a suspect memory leak?  When my scripts do not need GameDropFix, I do not have this problem.  Even when I use InterFrame, I do not have this problem.  (I mention that as I know both use some of the same internal SmoothVideo logic.)

Do you need me to post info from Vdub's crash?  Each time I looked it wasn't very meaningful, that is, it simply said that Vdub crashed due to something or other.  I will create another crash if you ask me too, if you think it would help.  (I write this, half suspecting that you and rest may already know about particular modules having memory leaks, so maybe you know this already and are working on it.  But I'll create a crash if you want.)

MAG79 wrote:

Yes. I did it! cool
Working version of GameDropFixFuncs.avsi:

It is single-threaded implementation. To make it multy-threaded you need to uncomment two lines: SetMTMode and trim.

You can use it from your script simply by write a line:

GameDropFixV4()

(gpu-acceleration in on, debug strings are off by default)
or full call of function:

GameDropFixV4(myGPU=true,myDebug=true,myErrSize=150)

Yes, COOL!  While I had already finished a bunch of runs where I inserted the entire code in-line, I just found several that I need to use this one.  Nice to have a one-line function call!

I've done it already on one, in non-multi-thread.  Will now change to multi-thread for another one.  I may have questions.

MAG79 wrote:

One moment: c=last not last=c smile

TCmullet
Have you any experience with avisynth scripting?

Changing it to "c=last" re-causes the "I don't know what 'width' means" message again (as I kind of would expect).  "c" does have the clip in it, as it's passed in by the function call.  (But if the current clip is gone, then it would make sense that c=last wipes out c with the contents of last which contains nothing.)  The question is why isn't the clip still current, seeing as I left it current when I hit the function call?

Experience with avisynth scripting?  That's a little puzzling.  Obviously, I assembled the scripts I pasted here, but GameDropFix logic was written by you guys.  (But notice I made tweaks within it to parameterize it.)

I've been writing scripts on and off for several years now.  Several years ago, I figured out (from docs and experimentation) how to IVTC movies I captured off cable back to 24fps.  I didn't like departing from pure Virtualdub at the time.  And in the last year am using Avisynth to do all processing, with the tail end output being to Virtualdub to make a final encode.  I am greatly appreciating Avisynth's amazing abilities.  And then add Interframe, plus DGBob, and I can now make 60fps output from any source.  (60fps is needed for a current major project I hope to make work.)  I also love the fact that it's self-documenting.

What I do NOT know is the nuances or even meaning of many of the Avisynth statements and functions.  I try to learn each one as needed.  So there is MUCH I do not know yet.  (Including nearly everything about MT mode and "setMTmode" which I find it very hard to get documentation on.)

I didn't think it would be hard to put any logic inside a function.  (I've been doing it for years in other languages.)  I guess I was wrong.  So did I answer your question?

I do have a programming background, even though I'm in poverty right now.  I learned Fortran, Cobol, Assembler etc. in college in the 70s and C#, html, javascript and php in recent years, neophytes in all recent languages.  (I learn a new feature as needed.  I just recently learned Ajax a bit, as I needed it for something.)

I've put "last=c" as the first line of the function.  Yes, it solves the 2 width and height errors.

Now the video does open, but I get two lines of grey text superimposed over the picture saying:

I don't know what "fix_clip" means
([ScriptClip], line 2)