The power of Avisynth: restoring old 8mm films. [Archive] - Page 23

SnillorZ

20th May 2019, 11:23

Why not set the number of threads to 4 (or 8 if your CPU supports hyperthreading)? I don't know if the necessary plugins have 64-bit builds, but using an x64 version of Avisynth+ should help as well.

As per OP, anything 4 or above causes out of memory or VirtualDub to hang.

I'm pretty sure quite a few of the plugins will not be happy with AVISynth x64. Also, I doubt that x64 will provide any speed improvement although, since some of the stability problems are related to memory issues, x64 might provide a little more room.

I think the OP said he had stability problems when he increased threads beyond two.

As John says, the plugins for his script wont load in Avisynth+ x64.

From my own experience having a 64bit application and everything in the chain x64 hasn't provided significant performance gains over running its equivalent x86 app. Admittedly, I've not been attempting something so resource intensive as this though.

@pinterf

Thank you, will take a look at these and see if I can find x64 verisons of the other plugins John's script uses and see if I can get this running and compare to x86 performance.

I've checked that my source files aren't root cause by using the parade example clip from port #1078 to test run John's script and I'm getting same performance. So I must be missing something or have something fundamental in play here, as I get almost the same low fps performance across 2 different machines that have different hardware and OS using the same Avisynth + VirtualDub setups.

Will keep looking and also explore the x64 plugins.

pinterf

20th May 2019, 12:10

As per OP, anything 4 or above causes out of memory or VirtualDub to hang.
Yep, more threads - more memory is needed, at least in AVS+. Internal frame caches within Avisynth+ and multiple working buffers for external plugins.

You can use the Avsmeter utility to see the increase in memory consumption for Prefetch 2, 3, ... values. Or set SetMemoryMax manually though it cannot count with the extra memory need for external plugins, still worth playing with it.

StainlessS

20th May 2019, 14:57

Also (clutching at straws) suggest use DebugView, see if message from dll requiring Avstp is issued (Google "DebugView", from MicroSoft), execute DebugView and run script, view debugview window.
(I cant say what the error message might be, I'm running encode at the moment and so cannot remove dll to test.
[or just check your plugins directory for dll]
I'm guessin' that some of your filters use avstp (for multithreading), and if absent then can cause all kinds of crashes and such.

Same suggestion to stormy1777 if he sees this.

EDIT: I think message issued by some plugin (rgtools maybe) is something like "Avstp.dll missing, dropping down to single threaded".

EDIT: Could also post result of "AvsMeter avsinfo".

From the Avisynth user point of view, an AVSTP-enabled plug-in requires the avstp.dll file to be installed. Put it in the usual AviSynth 2.5\plugins\ directory, or load it manually with LoadPlugin("path\avstp.dll") in your script. The dll is shared between all plug-ins using AVSTP, so keep only one avstp.dll file in your plug-in set. If you're updating from a previous version, make sure that Avisynth will get access only to the latest one.

If a plug-in requiring AVSTP cannot find the dll file, it could crash, emit an error, or fall back gracefully on a single-threaded mode, depending on its design and implementation. There is no mandatory or pre-defined behaviour for such a case.

The number of threads is automatically set to the number of available logical processors. The thread count can also be controlled via an Avisynth function, so multi-threading can be disabled globally if not desired.

Avstp: https://forum.doom9.org/showthread.php?t=164407
Latest version is v1.0.3

SnillorZ

20th May 2019, 17:06

@pinterf @StainlessS Thanks chaps

You can use the Avsmeter utility to see the increase in memory consumption for Prefetch 2, 3, ... values. Or set SetMemoryMax manually though it cannot count with the extra memory need for external plugins, still worth playing with it.

Thank you for the direction to Groucho's tools, this is very useful and significantly speeds up trail & error testing scripts with the different thread, mem & prefetch options.

Same suggestion to stormy1777 if he sees this.

EDIT: I think message issued by some plugin (rgtools maybe) is something like "Avstp.dll missing, dropping down to single threaded".

EDIT: Could also post result of "AvsMeter avsinfo".

Ok making some progress here, StainlessS was right, without AVSTP plugin, Sysinternals DebugView reports:

RemoveDirt 0.9
AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading.

AVSMeter AVSinfo (with -c)

AVSMeter 2.9.1 (x86) - Copyright (c) 2012-2019, Groucho2004

VersionString: AviSynth+ 0.1 (r2772, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 5
Multi-threading support: Yes
Avisynth.dll location: C:\windows\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:06:28 (UTC)
PluginDir2_5 (HKLM, x86): D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins

PluginDir+ (HKLM, x86): D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins

[CPP 2.6 Plugins (32 Bit)]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll [2018-12-20]

Custom plugin directory : D:\VideoTools\AVSplugins

[CPP 2.5 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\autolevels.dll [0.6.0.0]
D:\VideoTools\AVSplugins\avstp.dll [1.0.3.0]
D:\VideoTools\AVSplugins\deflicker.dll [0.4.0.0]
D:\VideoTools\AVSplugins\FFT3DFilter.dll [2.1.1.0]
D:\VideoTools\AVSplugins\Motion_06Dec05B.dll [2005-12-06]
D:\VideoTools\AVSplugins\mt_masktools.dll [2.0.32.0]
D:\VideoTools\AVSplugins\MVTools.dll [2008-09-11]
D:\VideoTools\AVSplugins\RemoveDirt.dll [2008-04-01]
D:\VideoTools\AVSplugins\RemoveDirtSSE2.dll [0.9.0.0]
D:\VideoTools\AVSplugins\RemoveGrain.dll [2005-05-01]
D:\VideoTools\AVSplugins\RemoveGrainS.dll [2005-05-01]
D:\VideoTools\AVSplugins\RemoveGrainSSE2.dll [2005-05-01]
D:\VideoTools\AVSplugins\warpsharp.dll [2008-04-06]

[CPP 2.6 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\DePan.dll [2.13.1.3]
D:\VideoTools\AVSplugins\DePanEstimate.dll [2.10.0.2]
D:\VideoTools\AVSplugins\ffms2.dll [2016-12-29]
D:\VideoTools\AVSplugins\FredAverage_x86.dll [0.3.0.0]
D:\VideoTools\AVSplugins\GamMac_x86.dll [1.10.0.0]
D:\VideoTools\AVSplugins\mvtools2.dll [2.7.39.0]

[Scripts (AVSI)]
D:\VideoTools\AVSplugins\FFMS2.avsi [2015-05-22]

[Uncategorized files]
D:\VideoTools\AVSplugins\03_RemoveDirtMC.avs [2010-06-29]
D:\VideoTools\AVSplugins\ffms2.lib [2016-12-29]

So this is getting me up to 2 - 2.3fps avg :sly: woo

I'm still progressing to try and test x64 Avisynth / VDub / plugins:

I've found x64 versions or alternatives that can be used with a modified JohnM script. Just left with 3 to find/swap out:

autolevels.dll

Deflicker.dll

warpsharp.dll - for which I've found AWarpSharp2 but this doesn't contain the unsharpmask function from John's script and I'm not sure what its equivalent is.

Anyway must go and do some paid work for a bit :devil:

StainlessS

21st May 2019, 05:19

Firstly, I have not found x64 version of these either.

autolevels.dll
Deflicker.dll
warpsharp.dll

I'll post this first.

[CPP 2.5 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\autolevels.dll [0.6.0.0] # I've got source for this, maybe I'll give it a go for x64.
D:\VideoTools\AVSplugins\avstp.dll [1.0.3.0]
D:\VideoTools\AVSplugins\deflicker.dll [0.4.0.0]
D:\VideoTools\AVSplugins\FFT3DFilter.dll [2.1.1.0] # I have v2.6 dll, fft3dfilter_x86_2_4_0_0.dll (maybe check latest fftw3.dll and libfftw3f-3.dll too, for SysWOW64)
# Does not seem to be used by Fred script
D:\VideoTools\AVSplugins\Motion_06Dec05B.dll [2005-12-06]
D:\VideoTools\AVSplugins\mt_masktools.dll [2.0.32.0]
D:\VideoTools\AVSplugins\MVTools.dll [2008-09-11]

# Remove one of these
D:\VideoTools\AVSplugins\RemoveDirt.dll [2008-04-01] # This is the one in Fred zip (but is slower) [EDIT: Requires MSVCR71.dll runtime in SysWOW64]
D:\VideoTools\AVSplugins\RemoveDirtSSE2.dll [0.9.0.0] # This is faster SSE2 [EDIT: Requires MSVCR71.dll runtime in SysWOW64]
# Missing RemoveDirtS.dll from fred sourcecode/removedirt/removedirt does NOT req (VS2003) MSVCR71.dll runtime in SysWOW64
# But is from 2005.

# Remove Two of these ( *** WARNING Will Robinson ***, Version from Fred script is 1st Oct 2006 - and requires MSVCR71.dll runtime in SysWOW64)
D:\VideoTools\AVSplugins\RemoveGrain.dll [2005-05-01] # Standard compile [EDIT: Probably requires either (Vs2002)MSVCR70.dll or MSVCR71.dll]
D:\VideoTools\AVSplugins\RemoveGrainS.dll [2005-05-01] # S version static linked, dont need runtime
D:\VideoTools\AVSplugins\RemoveGrainSSE2.dll [2005-05-01] # SSE2, faster

D:\VideoTools\AVSplugins\warpsharp.dll [2008-04-06] # Oops, mine seem to be from 2003

MsVCR70.dll and MsVCR71.dll:- https://support.microsoft.com/en-gb/help/326922/redistribution-of-the-shared-c-runtime-component-in-visual-c
[Groucho2004 will probably get a kick out of reading above link again :) ]

Here overrides anything above.

Suggest remove all from Plugins directory, EXCEPT

[CPP 2.6 Plugins (32 Bit)]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll [2018-12-20]
D:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll [2018-12-20]

[CPP 2.5 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\avstp.dll [1.0.3.0]

[CPP 2.6 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\ffms2.dll [2016-12-29]

[Scripts (AVSI)]
D:\VideoTools\AVSplugins\FFMS2.avsi [2015-05-22] # Optional

D:\VideoTools\AVSplugins\ is your general (non fred) plugins directory.

Follow Freds instructions to install (Into suggested directories), eg

D:\Fred_Restore\
helpfiles\
scripts\
sourcecode\

Something like above.

Might need to install install MSVCR71.dll to SysWOW64.

If MSVCR71.dll NOT in SysWOW64, then can find it here(also MSVCR70.dll):- http://www.mediafire.com/file/1220u8g1drmubi8/MSVCR71_70_Runtimes.rar/file

Dependency Walker 2.2(to check if dll needs runtimes):- http://www.dependencywalker.com/

Also can copy/move fftw3.dll to SysWOW64 (for Depan use). [should not then need to be in the script directory, thats where most people put it].

Then suggest go though ALL scripts and where any current relative directory mentioned, prepend with ".\", and Also maybe change path separator slash "/" to "\" (for no real reason)
eg, Loadplugin("plugins/Depan.dll") to

Loadplugin(".\plugins\Depan.dll")

# and

Import(".\plugins\03_RemoveDirtMC.avs")

I've found that Windows 7 seems to have screwed up relative paths somehow and so now avoid by prepending literal current directory relative ".\" thingy.

If you dont keep Fred Plugs (which are old versions) separate from daily use plugins, you will just have problems some other time.
(would be best if scripts fixed up to be working with current plugs, probably be good to get rid of old mvtools).

Gorra get some shuteye, let us know what happens

ta-ta.

pinterf

21st May 2019, 08:39

1.) Probably these RemoveDirt dlls can be deleted as well

D:\VideoTools\AVSplugins\RemoveDirt.dll [2008-04-01]
D:\VideoTools\AVSplugins\RemoveDirtSSE2.dll [0.9.0.0]

RemoveDirt_MC uses only RestoreMotionBlocks from this plugin.
I replaced them with RemoveDirt 0.9.2 version (https://github.com/pinterf/RemoveDirt/releases)

2.) RemoveGrain.DLL, RemoveGrainS.DLL, RemoveGrainSSE.DLL:
All these can possibly be replaced by v0.97 RgTools (https://github.com/pinterf/RgTools/releases)

3.) Then I'm using masktools2 (https://github.com/pinterf/masktools/releases/) instead of 2.0.0.32 mt_masktools

4.) MvTools2 (https://github.com/pinterf/mvtools/releases/) instead of 2008 version of mvtools

Note:
do not keep DLLs containing similarly named plugin functions in one autoloaded directory neither load them all manually. Collision happens. E.g. when multiple DLLs containing "clense" are loaded, referencing "Clense" would call either the 15 year old version or the one from the latest SSE2 or AVX2 capable version.

Some of these newer DLLs are using not only SSE2 but SSE4.1 and AVX2 instructions which can give you further speed up when your processor is capable for that. When you bought your machine in the last 5 years, probably that is the case.

Groucho2004

21st May 2019, 10:23

AVSMeter AVSinfo (with -c)
@StainlessS
Please note that SnillorZ's "D:\VideoTools\AVSplugins" is not an auto-load directory so none of the functions from DLLs in that directory are added to the function pool during auto-load.

Apart from that - everything that pinterf wrote in the previous post is good advice.

SnillorZ

21st May 2019, 11:43

@StainlessS @pinterf @Groucho2004 thank you all.

Yes this:

@StainlessS
Please note that SnillorZ's "D:\VideoTools\AVSplugins" is not an auto-load directory so none of the functions from DLLs in that directory are added to the function pool during auto-load.

I was going to ask StainlessS about his advise:- to check from his experience was Avisynth that sensitive to exact locations of plugins that it could effect performance? Understand from Groucho's comment that SS was referring to auto loading plugins.

Sorry, so to clarify, for all 3 scripts I'm testing they all load the plugins required explicitly - hence using a common "avsplugins" directory with plugins with different versions and runtime requirements etc. I just started working this way as I found it easier to work out which script required what, which plugins caused the scripts to bomb, dll dependencies (thanks Stainless, I'd picked up a recommendation for DepWalker, I think from one of your much earlier posts).

So for VideoFred2012 Script, JohnMeyer2012 (MT) Script and John Meyer2017 (Avisynth+ Gamac) script am loading each plugin explicitly and using the corresponding version of Avisynth (using Groucho's SetAVS)

Also to clarify, the VideoFred2012 script works ok and at a speed that as I understand it could not be improved upon without MT which some of the plugins it uses are not supported.

However I'm preferring the results given by the modifications made in John Meyers scripts - Just checking I have everything set in my environment to get the best performance I can before forging ahead into 3000+ foots worth of footage and finding at a later point in time I could have saved myself a ton of time with a few simple changes. :(

1.)RemoveDirt_MC uses only RestoreMotionBlocks from this plugin.
I replaced them with RemoveDirt 0.9.2 version (https://github.com/pinterf/RemoveDirt/releases)
2.) RemoveGrain.DLL, RemoveGrainS.DLL, RemoveGrainSSE.DLL:
All these can possibly be replaced by v0.97 RgTools (https://github.com/pinterf/RgTools/releases)
3.) Then I'm using masktools2 (https://github.com/pinterf/masktools/releases/) instead of 2.0.0.32 mt_masktools
4.) MvTools2 (https://github.com/pinterf/mvtools/releases/) instead of 2008 version of mvtools

Yes, thank you @pinterf I had already delved into your GitHub to pick up all these:- to get x64 bit replacements/swap outs to those x86 plugins used in johnmeyer 2017 script to test a x64 plugins/Avisynth+ version. Still missing replacements for autolevels.dll & deflicker.dll and what function for AWarpSharp2 would replace the unsharpmask function of warpsharp.dll.

:rolleyes: Doh! I'd not thought of trying swapping out for some of the newer x86 plugins to test for performance increases in the original JM2017 script - I'd focused in on trying to get running in 64bit.
So will try those also and report back.

Hope you managed to get some beauty sleep StainlessS.

Toodle-Pip.

ChaosKing

21st May 2019, 11:55

Maybe someone could just port Unsharpmask from warpsharp as a script? Myrsloik did a port for VS https://github.com/myrsloik/WarpSharpSupport/blob/master/wss.py#L28

pinterf

21st May 2019, 12:21

And probably I can take care of deflicker and autolevels if they are really used so worth doing it.

SnillorZ

21st May 2019, 14:09

:rolleyes: Doh! I'd not thought of trying swapping out for some of the newer x86 plugins to test for performance increases in the original JM2017 script - I'd focused in on trying to get running in 64bit.

So will try those also and report back.

........so modifying the script to use the following newer or replacement plugins with the JM2017 script and Avisynth+ x86 decreases performance further (although not by much, though they perhaps improve on quality?)

AVSMeter 2.9.1 (x86) - Copyright (c) 2012-2019, Groucho2004

VersionString: AviSynth+ 0.1 (r2772, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 5
Multi-threading support: Yes
Avisynth.dll location: C:\windows\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2018-12-20, 12:06:28 (UTC)
Custom plugin directory : D:\VideoTools\AVSplugins\x86

[CPP 2.5 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\x86\autolevels.dll [0.6.0.0]
D:\VideoTools\AVSplugins\x86\avstp.dll [1.0.3.0]
D:\VideoTools\AVSplugins\x86\deflicker.dll [0.4.0.0]
D:\VideoTools\AVSplugins\x86\warpsharp.dll [2008-04-06]

[CPP 2.6 Plugins (32 Bit)]
D:\VideoTools\AVSplugins\x86\DePan.dll [2.13.1.4]
D:\VideoTools\AVSplugins\x86\DePanEstimate.dll [2.10.0.3]
D:\VideoTools\AVSplugins\x86\fft3dfilter.dll [2.6.0.0]
D:\VideoTools\AVSplugins\x86\FredAverage_x86.dll [0.3.0.0]
D:\VideoTools\AVSplugins\x86\GamMac_x86.dll [1.10.0.0]
D:\VideoTools\AVSplugins\x86\masktools2.dll [2.2.18.0]
D:\VideoTools\AVSplugins\x86\mvtools2.dll [2.7.41.0]
D:\VideoTools\AVSplugins\x86\RemoveDirt.dll [0.9.2.0]
D:\VideoTools\AVSplugins\x86\RgTools.dll [0.97.0.0]

StainlessS

21st May 2019, 14:25

@StainlessS
Please note that SnillorZ's "D:\VideoTools\AVSplugins" is not an auto-load directory so none of the functions from DLLs in that directory are added to the function pool during auto-load.

OK, thanks, I thought both were autoload, I dont much bother reading manuals or instructions :(
(I usually point both at same dir, and I dont like putting Avisynth supplied dll's in same dir as others, could cross pollinate dll's when duplicating dll sets to another ver$ avs plugins).

I thought that old version dll's would prompt for futher advice on replace with recent, I expected further posts on that (but thought might be reason for fred/john using old versions).

These are the avs specific dll's that I copy to system32/SysWOW64

AvsRecursion.dll
fftw3.dll # same as below file, name edited only
libfftw3f-3.dll
libsndfile-1.dll

Note also, that the fftw3.dll has probably been updated MANY times since fred supplied, see:- https://forum.doom9.org/showthread.php?t=174470

Pinterf, let me take a crack at AutoLevels x64, it uses DDigit for metrics which has been updated a few times since AutoLevels source supplied version,
If I get into trouble, I'll holla.

Oodles and Oodles of Toodles :)

EDIT: I would probably not be ambitious enouigh yet to attempt avs+ colorspaces for AutoLevels, but let me do standard v2.6 version, and if you wish to add avs+ colorspace stuff then
you can do mod on that.

pinterf

21st May 2019, 14:56

Pinterf, let me take a crack at AutoLevels x64, it uses DDigit for metrics which has been updated a few times since AutoLevels source supplied version,
If I get into trouble, I'll holla.

Oodles and Oodles of Toodles :)

EDIT: I would probably not be ambitious enouigh yet to attempt avs+ colorspaces for AutoLevels, but let me do standard v2.6 version, and if you wish to add avs+ colorspace stuff then
you can do mod on that.
Good news, you won the project :)

pinterf

21st May 2019, 15:04

........so modifying the script to use the following newer or replacement plugins with the JM2017 script and Avisynth+ x86 decreases performance further (although not by much, though they perhaps improve on quality?)

I'm really interested in which replacement is causing you the bottleneck. And what script options are you using (stabilization, autolevels, etc..), degrain on/off?

SnillorZ

21st May 2019, 16:16

@pinterf

Sorry, trying to follow multiple suggestions as methodically as I can without ending up with retrograde steps,

so please hold the line caller. :D

To clarify though all tests as per @johnmeyer suggestion Result4/Comparison4 - So no Autolevels or Colour Corrections. Just DirtRemoval, RemoveGrain, Stabalize, etc

These are the avs specific dll's that I copy to system32/SysWOW64

AvsRecursion.dll
fftw3.dll # same as below file, name edited only
libfftw3f-3.dll
libsndfile-1.dll

Note also, that the fftw3.dll has probably been updated MANY times since fred supplied

I'd overlooked the AVS sys32/wow64 required .dll's - I've updated fftw3/libfftw3f-3 to 02/05/2018 version linked by Goucho in the thread you show.

No performance improvement though.

However, in light of this I've gone back to testing some amendments to JohnMeyer2012 script (using AVS2.6MT) and managed to get 4+fps. Using same "script relevant" plugins as post #1111 - with the exception of RgTools.dll [0.97.0.0] which seems to cause a crash with 2.6MT? Encouraging uptick though.

SnillorZ

21st May 2019, 16:34

@videoFred, @johnmeyer, @StainlessS, @pinterf, @Groucho2004

Just wanted to say that in 20+ years of using forums (for both profession & personally) I've rarely come across a more welcoming and helpful bunch of members.

In fact, sadly more often than not, the experience is the complete opposite and once you admit to being a noob and lurking around a thread and then dain to ask a question, find yourself be chased down the road by the flaming torches & pitchforks wielding mob.

Anyway, just wanted to make that point. If any of you found yourself in my part of the world (English Lake District (https://www.lakedistrict.gov.uk/wow)) would happily buy you a beer

Cheers

P.S. If you see my boss, you've not seen me. If you see my wife, tell her cant come away from the computer just yet as "I've found someone who's wrong on the Internet" :D

StainlessS

21st May 2019, 17:02

chased down the road by the flaming torches & pitchforks wielding mob.
Still plenty of time for that, dont rush us.

Bout 35 years ago, was half way between between Newcastle and Carlisle (English Lake District), stopped at pub in middle of nowhere and went in for a beer.
Manager told me that I should have been there the day before.
Why, I asked.
Because, they heard a terrlible loud noise in back garden (pretty much nothing [EDIT: except Kielder Forest of course] for 40/50/60 miles up to Scotland, big garden),
and looking out of window saw a helicopter landing there. Out jumped Prince Charles and a handfull of bodyguards/lackies.
Somebody wanted a piss, so they stopped for a rest period, and a pint.
Nice to know that the other half have to piss as well, I thought that they just 'glistened', rather a lot.

EDIT: Lovely day here in The Big Smoke, wish I could escape from this pub and go start on AutoLevels x64 mod.

SnillorZ

21st May 2019, 17:19

:D @StainlessS

I wouldn't have been surprised if you'd said Charlie and T'other off-comers in their big metal bird had been chased off.

Some places up here still like "Deliverance" country and you have to be careful where one puts one's banjo.

SnillorZ

21st May 2019, 18:20

@johnmeyer

............Third, you should turn do your initial work with GamMac turned off (if you are using my latest script) and only do the basic dirt/motion/grain enhancements by specifying option "4". GamMac will slow things down a bit.

Please can I revisit your advise above, whilst still testing performance tweaks?

Can I clarify, after doing a R4 processing with your script, are you saying then run the result (VirtualDub>Save As>Uncompressed avi) through a script process using R1/2/3 (as preferred)?

Using same script i.e. letting Stabilise/Denoise/Sharpening process again?

or use a modified version to comment out some of these (I note your comment GamMac introduces some flicker)

:thanks:

pinterf

21st May 2019, 18:25

...with the exception of RgTools.dll [0.97.0.0] which seems to cause a crash with 2.6MT?
Could you please try it with 0.97 again, this time specifying ", align = true" additional parameter for the Crop line?

SnillorZ

21st May 2019, 19:13

Could you please try it with 0.97 again, this time specifying ", align = true" additional parameter for the Crop line?

Sorry not certain which crop line you mean?

You mean like this:

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true) #temporarily remove any black borders on input video

If so the script still bombs the program(s) (e.g. AVSMeter)

StainlessS

21st May 2019, 19:18

Align = true,

its lovely that avs+ made things a bit faster/better,
but woulda been even nicer if mod whatever were not an additional issue.

Lots more work for Devs, but who the hell cares bout them !

pinterf

21st May 2019, 19:25

Sorry not certain which crop line you mean?

You mean like this:

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true) #temporarily remove any black borders on input video

If so the script still bombs the program(s) (e.g. AVSMeter)

Yep, that's it. I'm not sure if there are other Crop commands around.

SnillorZ

21st May 2019, 19:25

Anyway, last post for today.

Quick example of a rough cut taken from the script tests:

Using @johnmeyer (VideoFred) script 2017 (Avisynth+ GamMac, etc)

https://youtu.be/UD0tTJLIrK8

pinterf

21st May 2019, 20:32

Yep, that's it. I'm not sure if there are other Crop commands around.
So, there were two other Crops in the script.
Using AVS 2.6 and Crop without align=true I got the message from RgTools 0.97:
"RemoveGrain: Invalid memory alignment. Unaligned crop?"
Put the missing ", align=true" lines and the script was working for Avisynth 2.6 as well.

Regarding the slowish avs+ 32-bit run:
Even for a single thread Avisynth+ needs 1300M memory for a basic out-of-box side-by-side comparison script (if not limited). My sources are 1600x1200 scans.

In Avisynth+ when the size of internal frame caches have to be shrunk due to low memory, it has much bigger penalty on speed than it happens in classic Avisynth 2.6.

Quick AvsMeter tests with Avisynth+ 2772 x86, using the formerly attached "JM2017" script:

Single thread SetMemoryMax(1024): 0.26 fps
Single thread SetMemoryMax(2048): 0.46 fps (actually 1350M used)
Prefetch(2) SetMemoryMax(1024): 0.43 fps (actually used 1384M)
Prefetch(2) SetmemoryMax(2700): 0.50 fps (actually used 1770M)

In this case an x64 workflow and thus the virtually limitless memory can help a lot for Avs+. Such videos with full-HD resolution and a complex filter chain require huge amount of memory. Too bad there are still filters without x64 version, but it's just a question of time to have them.

(Did not run x64 tests because of the missing unsharpmask function)

SnillorZ

22nd May 2019, 10:25

So, there were two other Crops in the script.

Thank you, found those now.

So now testing John's 2012 script using AVS2.6 MT and the newer plugins that are available, gives the following with 4 Threads and 2048M. On the Parade Example AVI (1920x1080 16fps) with Result S4

AVSMeter 2.9.1 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)

Number of frames: 241
Length (hh:mm:ss.ms): 00:00:15.063
Frame width: 2560
Frame height: 720
Framerate: 16.000 (16/1)
Colorspace: YV12
Active MT Mode: 2

Frames processed: 241 (0 - 240)
FPS (min | max | average): 1.073 | 122698 | 3.818
Process memory usage (max): 2507 MiB
Thread count: 17
CPU usage (average): 77.3%

Time (elapsed): 00:01:03.122

Thank you for the detail regarding the differences in memory handling between Avisynth+ and earlier versions. This has helped me understand why the significant difference in performance between the latest version of the cine film restore script and earlier ones.

So, in a better position now with everyone's input, I am hoping you marvelous code mechanics can come up with the x64 ports of the few remaining external plugins required to give a full 64bit test a run.

Understand that you will all have other priorities (days jobs to do), so no rush, I'll just keep a watching brief here. :cool:

pinterf

22nd May 2019, 13:06

And here is Deflicker 0.5 for x64. Not optimized yet for x64 but at least exists.
https://github.com/pinterf/Deflicker/releases

StainlessS

22nd May 2019, 13:13

Ooooooo Lovely, thanx P.

SnillorZ

22nd May 2019, 13:35

Ooooooo Lovely, thanx P.
What he said +1 :thanks:

videoFred

23rd May 2019, 09:00

Anyway, last post for today.

Quick example of a rough cut taken from the script tests:

Using @johnmeyer (VideoFred) script 2017 (Avisynth+ GamMac, etc)

https://youtu.be/UD0tTJLIrK8

Picture quality is very good! What transfer system have you used?

But aspect ratio is not good: it looks to narrow.
Also, if there is no flicker in the original scan, you can disable deflicker() in the script.

Fred.

SnillorZ

23rd May 2019, 11:56

Picture quality is very good! What transfer system have you used?

But aspect ratio is not good: it looks to narrow.

Also, if there is no flicker in the original scan, you can disable deflicker() in the script.

Fred.

Hi Fred and thank you. Used a "transfer" company here in UK, they said the equipment they use is from the German company MWA-Nova, using MWA "Vario" Flashscan Digital Data Scanners.

I agree on the aspect ratio. This was from an initial test, based on recommendations from Johnmeyer Post #1095 (https://forum.doom9.org/showthread.php?p=1874708#post1874708) for improving fps processing of the scripts and Avisynth, he was making the point that 8mm would see little benefit from anything above SD resolutions, so this example was done at 1024x576, but yes I think with the borders added back it makes the frame too "square". Have you found something that works best for standard 8 and is it the same for Super 8? (most of the footage I have is standard 8). Scans have been supplied full HD 1920x1080.

Its funny, I have some footage from early 60's (like this example) that the original film quality is still pretty good, yet some much later stuff (80's) that has aged nowhere near as good, down to handling and equipment I guess. So some footage will require a lot more attention than others.

Sadly I've come across a couple of bits of footage that have been double exposed and I think will have to be consigned to the "too difficult" pile as they will be way beyond my skill set.

Good to hear from you, it was seeing examples of your work that provided the inspiration for doing this.

johnmeyer

23rd May 2019, 16:06

Your fps, at around 3.5, is starting to look reasonable if your input is really:

Frame width: 2560
Frame height: 720That 2560 width is what you reported above. Is that really what is being fed to the script?

You want to do two things if you are going to somewhat reduce the resolution prior to feeding the result to your script. The first is to crop off any black bars on the side. Even if you are going to keep everything at HD resolution, it is pointless to process all those black/blank pixels. Which brings me to a key point:

You never want to feed black borders into any of these scripts (see my last comment below).

If you still want to process in HD, crop first to remove all borders (including any on top and bottom); then run the script; and then at the end, pad out the result by adding pixels on the side until you get to a standard 1920x1080 resolution. Getting rid of borders should make a huge difference in performance.

So, if you want to process in a lower resolution, resize down to the lower resolution after doing the crop recommended above. Don't include any borders in the resize operation.

If you do re-size, you'll want to pay attention to the aspect ratio of the film compared to the aspect ratio of standard PAL or NTSC SD video. I actually added some parameters for this, which I don't think Fred ever added to his script. I did this primarily for handling 8mm film which is almost perfectly square, unlike NTSC SD video which at 656x480 (square pixel) or 720x480 (non-square pixel) is 4:3. So when you deliver 8mm scans using the SD DVD format, you will always end up with black bars on the side. It's just the way the math works. However, these inevitable borders must be temporarily stripped out before feeding the film transfer to the script, and then added back. I did this with the "in_bord_left" etc. border variables. It lets you easily remove borders and then, as the very last step, adds back black borders so you end up with the same video size you started with, but without ever processing the black pixels.

This is needed not only to reduce processing time, but also to avoid having funky borders from the motion stabilization. If you leave the black borders, the black from the borders will wander into the frame of the final video.

P.S. Your scans look good, although it looks like you may be losing some highlights (that is the fault of the scan) and it also looks like you might need to do more work in post on gaining the shadows, as exhibited by the walk in the square starting at the 0:13 second mark. I do scene-by-scene gamma adjustments in Vegas, using a custom histogram, but others have used a combination of HDRAGC and GamMac in AVISynth to do this automatically. I posted my GamMac results, but I don't have it working well enough to rely on, so I run the script twice: once with, and once without GamMac and then cut between them just before I deliver the final result.

I need to get back to trying HDRAGC. It has been upgraded a lot since I first tried it a decade ago. It produce some really good results, but was prone to go AWOL on some scenes and really mess things up. When it was working, this is what the results looked like:

HDRAGC good results (https://forum.doom9.org/showpost.php?p=868799&postcount=138)

StainlessS

23rd May 2019, 16:24

Also, vast black borders will screw with any auto color correction stuff.

SnillorZ

23rd May 2019, 17:50

That 2560 width is what you reported above. Is that really what is being fed to the script?

John that was just a test run based off a @pinterf advised change to the Crop function. Script will have been pointing to a S4 result as the source i.e. 2 x 1280 side by side.

Your comments on borders sort of brings me back to my question up thread which think you've perhaps missed?

@johnmeyer
Please can I revisit your advise above, whilst still testing performance tweaks?

Can I clarify, after doing a R4 processing with your script, are you saying then run the result (VirtualDub>Save As>Uncompressed avi) through a script process using R1/2/3 (as preferred)?

Using same script i.e. letting Stabilise/Denoise/Sharpening process again?

or use a modified version to comment out some of these (noting your comment GamMac introduces some flicker)

to confirm source scans are 1920x1080 with 208px border left & right on the standard 8 scans and 172px Super8 (I've adjusted these values for Mod8 etc).

To confirm with testing the scripts, have the border crop functions:

in_bord_left=208 in_bord_top=0 in_bord_right=208 in_bord_bot=0 #Borders around input that must be removed

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot) #temporarily remove any black borders on input video

... as I discovered without you end up with side to side "frame weave" or funky borders as you describe.

However are you saying here If you still want to process in HD, crop first to remove all borders (including any on top and bottom); then run the script; and then at the end, pad out the result by adding pixels on the side until you get to a standard 1920x1080 resolution. Getting rid of borders should make a huge difference in performance. that the borders should be removed first outside of your script and not using the crop function as shown above? Sorry I'm a little confused.

Yes I anticipate that when I get into the details of the post edit I'll have scene by scene correction to do. I've never used Vegas and likely will use PPro as I have some experience with it, although some time ago but at least GUI is familiar. So anticipating having to cut some scenes for further AVS processing or something similar in PPro to adjust.

Interested about your comment that some have managed this automatically though. As I know I have a lot of scenes to deal with like the example you picked out - Bless dear old Dad, he did used to like to get his moneys worth by shooting with the same speed film in camera indoors & out, guess film was a good chunk of a working mans wage back then. :)

StainlessS

23rd May 2019, 18:05

John probably just means that there is no included pre-cropping in given scripts, so add your own after source filter and before rest of script, you
can just insert a Return Last before the rest of script whilst getting coords correct.

EDIT: Or Return Source, or whatever the cropped clip is called.

pinterf

23rd May 2019, 18:41

And here is Deflicker 0.5 for x64. Not optimized yet for x64 but at least exists.
https://github.com/pinterf/Deflicker/releases
v0.6 version is ready, SSE2 and AVX2 support in both x86 and x64 version.

SnillorZ

23rd May 2019, 18:56

Sorry that's why I'm confused, as I'm reading them as John's scripts do include pre-processing crop: as all his scripts have these relevant parts (have only changed the relevant bord pixel parameters):

#VIDEO FILE
#Change the following line to point to your video file
film="D:\VideoSource\**SOURCEFILE**.avi"

...........>

#SIZE, CROP AND BORDERS PARAMETERS
CLeft=4 CTop=4 CRight=4 CBottom=4 #crop values after Depan and before final resizing
W=1280 H=720 #final size after cropping
bord_left=0 bord_top=0 bord_right=0 bord_bot=0 #720p= borders 150
in_bord_left=208 in_bord_top=0 in_bord_right=208 in_bord_bot=0 #Borders around input that must be removed

...........>

source= Avisource(film).killaudio().assumefps(play_speed).trim(trim_begin,0).converttoYV12()
trimming= framecount(source)-trim_end
source1= trim(source,0,trimming)

cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot,align = true)

or am I misunderstanding and just outed myself as a noob? is it pitchforks and flaming torches time now StainlessS?

StainlessS

23rd May 2019, 19:30

is it pitchforks and flaming torches time now StainlessS?

No not yet, busy at present, maybe tomorrow.

I muchly doubt that john expects you to do an entire pass just for cropping, do as you deem fit.

johnmeyer

24th May 2019, 00:34

The inborder = 208 should do the trick. 208 is mod 4 which, I have found, makes the script "happier."

StainlessS

24th May 2019, 06:34

John, Fred,

Anybody ever use AutoLevels(autoGamma=true), if so any problems crashes at all ?

Kaboom!

K=BlankClip.Trim(0,-100)
W=K.Invert
K++W++K++W++K++W++K++W
#AutoLevels(autolevel=true,debug=true)
AutoLevels(autogamma=true,debug=true)
return last

Autolevels::adjust() called with gamma=0.0, and so 1/gamma produces Divide by Zero..

I probably will not get time to look further today, but maybe get back to it tomorrow.
Got it compiling x64 OK, thought that I had borked it, but bug in original dll too.

EDIT: Seems to only be RGB24 and RGB32.

SnillorZ

24th May 2019, 13:09

But aspect ratio is not good: it looks to narrow.
Fred.

The inborder = 208 should do the trick. 208 is mod 4 which, I have found, makes the script "happier."

I've realised my schoolboy error - In doing 2 processing steps (for performance - as per up thread) I have the original source borders cropped Result 4 processing but I'd not set what the output borders should be based on the resizing and not realised that if you don't set these you end up with the same original border size added back to the (now) resized output, which is obviously wrong. Then in processing step 2 (levels, colours or whatever) using the same border crop values as in step 1 reduces the actual frame size further. So this was my mistake.

If someone can please check my math(s):

Orginal scan source = 1920x1080 (Standard 8mm) with Left & Right borders gives an actual video frame size width 1504.

Step 1 process script Result 4 (denoise, stabalise, etc) Crop borders 208 left & right. Resize to 1280x720 and set resize borders to give 140px borders and 1000 frame width (being 2/3ds of original 1920 & values adjusted to Mod4)

W=1280 H=720 #final size after cropping
bord_left=-68 bord_top=0 bord_right=-68 bord_bot=0 #720p adjusted borders
in_bord_left=208 in_bord_top=0 in_bord_right=208 in_bord_bot=0 #Borders around input that must be removed

Step 2 process script Result 1 (Levels, Colours) output of Step 1. Crop borders 140 left & right. No further resize or borders resize.

W=1280 H=720 #final size after cropping
bord_left=0 bord_top=0 bord_right=0 bord_bot=0
in_bord_left=140 in_bord_top=0 in_bord_right=140 in_bord_bot=0 #Borders around input that must be removed

I've redone the test samples and posted them here:

Using johnmeyer script 2012 vs 2017 (GamMac) script for comparison. Both do now use latest external plugins available. :thanks: @pinterf

Result1 AVS2012 Script (https://vimeo.com/338231281)

Result1 AVS2017 Script (https://vimeo.com/338233017)

Just to note I've updated both of the above scripts to use v0.6 Deflicker:

v0.6 version is ready, SSE2 and AVX2 support in both x86 and x64 version.

SnillorZ

24th May 2019, 14:26

Just for completeness the AVS2017 (Avisynth+) clip vs the original

Original Source vs AVS Processed (https://vimeo.com/338253419)

Yes scene 2 (0:0:13:0+) needs further work. :p

johnmeyer

24th May 2019, 14:28

Anybody ever use AutoLevels(autoGamma=true), if so any problems crashes at all ?Yes. In fact, if you go to page one of this 58-page thread, you'll see that VideoFred's original script used it. I never liked the results, however.

videoFred

24th May 2019, 17:13

Hi Fred and thank you. Used a "transfer" company here in UK, they said the equipment they use is from the German company MWA-Nova, using MWA "Vario" Flashscan Digital Data Scanners.

Yes, the Flashscan. It gives good overall results but a bit over saturated and not much detail in the shadows.

Its funny, I have some footage from early 60's (like this example) that the original film quality is still pretty good, yet some much later stuff (80's) that has aged nowhere near as good, down to handling and equipment I guess. So some footage will require a lot more attention than others.

Good old regular-8 was top quality. All metal gear, very good film stock and the pressure plate was all metal, in the camera (like single-8) . Super-8 was more plastic gear and less quality filmstock. But more affordable for the common man.

Fred.