AvsPmod (Windows_x86) mod - Page 30

stax76 · 22nd February 2021, 20:30

Thanks for investigating.

I'm sorry that it's not easy migrating to Python 3.

I think most MS tools support BOM but generally BOM is not very popular, it's fine as an option but should be avoided as the default choice.

gispos · 22nd February 2021, 22:13

Quote:

Originally Posted by stax76

Thanks for investigating.

I'm sorry that it's not easy migrating to Python 3.

I think most MS tools support BOM but generally BOM is not very popular, it's fine as an option but should be avoided as the default choice.

AvsPmod has always saved new scripts in utf-8. Only other programs do not recognize this until there are characters outside of the ASCII table.
When I set the bom the script is recognized as utf-8 with bom. Ascii is just the same as utf-8 Latin1, therefore Ansi is recognized by other programs.
Or the python encoder refuses to encode utf-8 if the characters are only within Ascii

You can test it.
Paste a few Japanese characters into a new script and save it. It is recognized as utf-8 with bom.

Why you don't accept Ansi in your tools? It is not a problem to process both. Isn't a hassle.

Edit:
Save a file with only Ascii characters with Notepad++ as utf-8 without bom. And then open it, Ansi is displayed as the coding.

Edit 2:
https://github.com/staxrip/staxrip/w...indows-10-1903
How do you want to recognize Ansi?

Code:

On Windows 10 1903 or higher all these apps expect AviSynth scripts to be UTF-8 encoded, ANSI encoded scripts will cause errors.

Fjord · 22nd February 2021, 23:26

EDIT1: The crash was due to a bug in RemoveDirt 0.9.2, corrected by pinterf in RemoveDirt 0.9.3. The script shown here does not crash with the new RemoveDirt.dll 0.9.3.
--------------------
I started getting crashes when I added a resizer at the start of my film restoration script for ProRes HQ 10-bit scans. It turns out not related to the input or the resizer, but rather the width of the clip going through the script. Height doesn't seem to cause the crash. I have boiled it down to the following script, with ColorBarsHD as input, which crashes AvsPmod (v2.6.6.6 or .7 x64), but runs ok in VirtualDub2 (build 44282 x64) -- both using AviSynth+ 3.7.0 (r3382 x64). Since this appears to be an AvsPmod issue, I post here -- Let me know if I should be posting somewhere else.

AvsPmod crashes hard (access violation) on the following simplified film restoration script, for 10-bit source (ie YUV444P10, YUV422P10, YUV420P10), when frame width is multiple of 2 or 4. AvsPmod exits abruptly when F5 is pressed, or with first advance to next frame.

However, it runs fine in VirturalDub2, or when frame width is multiple of 8 -- or the source is 8-bit. The frame height doesn't seem to matter. The crashes don't seem to leave a useful traceback, and I am not familiar with AviSynth/AvsPmod debugging, so I don't know where the problem occurs.

Plugins used are latest pinterf x64 versions of MVTools2 (v2.7.44 20201214), RGTools (v1.1 20210104), RemoveDirt (v0.9.2 20190324) -- loaded manually, directly from the unzipped downloads.

The only error information I get are an AvsPmod error pop-up (most times). The first occurs if AvsPmod opens and runs the script on startup:

The second is when the script is run using F5 key:

I did get the following AviSynth warning message on one test run, when I enabled logging with SetLogParams(), but mostly no error messages or warnings for crashes.

Code:

WARNING: A plugin or the host application might be causing memory leaks.

I removed all other code and filters in the script that didn't make a difference for this example.

Does this cause a crash for anyone else?
What steps should I take to find the cause of the crash?

Stripped-down reproducible error script.

Code:

/*

This script crashes AvsPmod (v2.6.6.7 x64), but runs ok in VirtualDub2 build 44282
both running AviSynth+ 3.7.0 (r3382, 3.7, x86_64)

This script is a stripped-down version of a johnmeyer film restoration script, adapted for high bit depth (10-bit)

*/

ClearAutoloadDirs()		# clear autoloader list, to manually load plugins

PluginsFolder = "C:\Users\DRC\Documents\8mm\AVISynth\Plugins"

LoadPlugin(PluginsFolder + "MVtools2\mvtools-2.7.44-with-depans20201214\x64\mvtools2.dll")
				# pinterf v2.7.44 (20201214) x64

LoadPlugin(PluginsFolder + "RgTools\RgTools-v1.1\x64_LLVM_build\RgTools.dll")
				# pinterf v1.1 (20210104) x64 LLVM Clang

LoadPlugin(PluginsFolder + "RemoveDirt\RemoveDirt-0.9.2\x64\RemoveDirt.dll")
				# pinterf v0.9.2 (20190324) x64

#~ Wsrc2 = 888   Hsrc2 = 640		# 888x640 runs ok  -- width 888 & height 640 multiples of 8
#~ Wsrc2 = 890   Hsrc2 = 640		# 890x640 CRASHES AvsPmod  -- width 890 is multiple of 2, height 640 multiples of 8
Wsrc2 = 892   Hsrc2 = 640		# 892x640 CRASHES AvsPmod  -- width 892 is multiple of 4, height 640 multiples of 8

src2 = colorbarsHD( Wsrc2, Hsrc2, pixel_type="YUV444P10" ).killaudio()

stabcrop = RemoveDirtMC( src2, limit=51, _grey=FALSE, show=FALSE )

return stabcrop

#===================================================================================================

function RemoveDirtMC( clip input, int "limit", bool "_grey", bool "show" )
{

	prefiltered = RemoveGrain( input, 2 )
	superfilt = MSuper( prefiltered, hpad=32, vpad=32, pel=2 )
	super = MSuper( input, hpad=32, vpad=32, pel=2 )

	bv1 = MAnalyse( superfilt, isb=true,  blksize=16, overlap=2, delta=1, truemotion=true )
	fv1 = MAnalyse( superfilt, isb=false, blksize=16, overlap=2, delta=1, truemotion=true )
 
	backw = MFlow( input, super, bv1 )	
	forw  = MFlow( input, super, fv1 )

	clp = interleave( forw, input, backw )
	  
	clensed = clp.Clense()
	alt = clp.RemoveGrain( 2 )

	clp = RestoreMotionBlocks( clensed, clp, alternative=alt,	\
				pthreshold=6, cthreshold=8, gmthreshold=40,	\
				dist=3, dmode=2, debug=false, noise=limit, noisy=4, grey=_grey )
								
	clp = clp.SelectEvery( 3, 1 )	# select every third frame, starting at frame 1 (second frame)
	
	return clp
}

When I verified the crash with the above code, using load script in a clean AvsPmod (no other tabs), it does crash, and interestingly the preview window is corrupted and shows some slider/toggles that I did not create, and have not seen before:

Where did these come from?
EDIT2: The spurious slider toggles came from forum [URL=...] [IMG] and [CODE] tags in my avs script comments, that AvsPmod parsed as slider tags.

gispos · 23rd February 2021, 17:14

Hello Fjord,
I just tested it, like you crashed.
In VirtualDub it works, with 8 bit it works that put me on the right track. Because internally AvsPmod only works with 8 bits, so errors caused by a different bit color resolution are hardly possible.

VirtualDub2 uses a different avisynth interface (vfw).
So I tried AviSource with success.

In a new script (tab) open your script with AviSource("your script")
The error must probably come from avisynth.

pinterf · 23rd February 2021, 17:52

More specifically the error comes from RemoveDirt.dll, which I'm gonna fix soon (an SSE2 load from unaligned address caused a C0000005 exception there)
EDIT: check https://github.com/pinterf/RemoveDirt/releases

Fjord · 23rd February 2021, 18:56

Thanks gispos for confirming the crash and clarifying that AvsPmod only uses 8-bits.
Thanks Ferenc for identifying RemoveDirt.dll (RepairMotionBlocks) as the cause of the crash, and the super quick fix -- new version of RemoveDirt 0.9.3.

My script now runs fine, also with odd frame dimensions (non-mod2) for YUV444P10. (mod2 of course required for YUV422P10 or YUV420P10).
I will mark my crash post as resolved.

gispos · 23rd February 2021, 18:58

That was fast

Fjord · 23rd February 2021, 19:34

gispos, I figured out where the odd slider/toggles came from, at the bottom of my crash post above. It's a markup conflict.

To verify my script in the crash post, I literally pasted my entire Doom9 post from the post edit window into a new .avs file, and marked the non-code text as comments with # or /*. When I ran the script in AvsPmod, AvsPmod interpreted the URL, IMG and CODE post markup (in brackets) in the post as AvsPmod slider toggle codes!

I can't show how this now looks in the script, because Doom9 interprets them as post markup. But now there are "URL=1" and "IMG=1" (in brackets) in the script, where the URL= and IMG markup had been for my images. Weird!

(anybody know how to display a literal bracket character in a Doom9 post without being interpreted as start of a post markup?)

videoh · 23rd February 2021, 20:59

Here are some escaped brackets: [lala]

Use the noparse tag around the desired text.

Fjord · 23rd February 2021, 21:24

Thanks videoh for the noparse tip: [noparse]xxx[/noparse]

Is there a similar "noparse" escape in AvsPmod, to "comment out" slider tags, so they don't get used? Even better, a noparse toggle, to turn off and on display of slider sections?

videoh · 23rd February 2021, 21:33

Don't know about AvsPmod. Hopefully author will enlighten us.

gispos · 24th February 2021, 17:23

Quote:

Originally Posted by Fjord

Thanks videoh for the noparse tip: [noparse]xxx[/noparse]

Is there a similar "noparse" escape in AvsPmod, to "comment out" slider tags, so they don't get used? Even better, a noparse toggle, to turn off and on display of slider sections?

Ok, /* (Block comment) will be ignored. # (Comment) works corectly.
Seems to be a minor bug or was ignored. This is placed at the very end of the todo list.

You just have to stick to certain rules and [< >] is reserved for user sliders. It's not an HTML editor.

FranceBB · 24th February 2021, 18:35

Quote:

Originally Posted by gispos

Ok, /* (Block comment) will be ignored. # (Comment) works corectly.
Seems to be a minor bug or was ignored. This is placed at the very end of the todo list.

Wait, what?

I generally use

Code:

Some code

#this is a comment

some code

however when I have to comment out large parts of a huge script, I use

Code:

Some code

/*
commented out stuff
commented out stuff
commented out stuff
*/

some code

Are you actually saying that you're planning to remove /* */ support or did I get it wrong?
'cause so far it has been working like a charm for me.

Fjord · 24th February 2021, 22:09

The forum tags in my script were definitely unintentional, so I have no interest in protecting that sort of tag. The forum tags were in a block comment in my script, and were parsed as section toggle tags by AvsPmod.

I checked the parsing of slider tags in script comments, and confirm that slider, separator and section toggle tags [< >] and [ ] [/ ], are active inside block comments /* */ as well as in script code. They are not active in # or #~ comments.

gispos · 24th February 2021, 23:44

Quote:

Originally Posted by FranceBB

Wait, what?

I generally use

Code:

Some code

#this is a comment

some code

however when I have to comment out large parts of a huge script, I use

Code:

Some code

/*
commented out stuff
commented out stuff
commented out stuff
*/

some code

Are you actually saying that you're planning to remove /* */ support or did I get it wrong?
'cause so far it has been working like a charm for me.

No, no no fear.

It's about the user slider characters [< >] which are also incorrectly found in a /* block comment.

FranceBB · 25th February 2021, 09:19

Ah, got it. No problem then.

pcroland · 25th February 2021, 21:53

Hi!

I updated to the latest version (2.6.6.7) and noticed that framestepping with the arrow keys is really slow. I'm working on a project where I have tons of plugins and scripts being used so the initial load takes a long time, but playing the script works fine (with ~25fps). In the current version playing it works fine but framestepping is really slow, like 2-3fps (holding down arrow). I checked some versions and 2.6.6.0 introduced the slowdown. I tried turning off "Constantly update video while dragging", "Refresh preview automaticaly" and "Video > Video play > Use separate thread" but none of them solved the issue.

Also, could someone explain what "Constantly update video while dragging" and "Refresh preview automaticaly" actually do? The first reloads all the plugins for any kind of frame step and the second one also but when I switch tabs?

I noticed that "Load fonts and colors backup" does not restore the ticked monospace fonts option. Is that on purpose?

Another bug is when you open the sidebar with a lot of plugins, it's really laggy to scroll in them with both the mouse wheel and dragging the bar. Resizing the image window is also laggy if the sidebar is opened: https://i.kek.sh/rzVUZxLMrjB.gif

And I have a suggestion btw: It would be nice if the FPS value would be a little more precise. For example when I have 23.976fps, you can't know if it's proper 24000/1001 or 23976/1000 FPS just by looking at the FPS number.

gispos · 26th February 2021, 18:51

Quote: