Search options (Page 2 of 5)

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.)

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.)

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, 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?

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.

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.)

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.

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

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.

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.

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.