AviSynth+ thread Vol.2

[manolito]

I am finally done with my tests of the different AVS+ builds, and at least for my computer it is pretty clear that the decrease in MT stability occurs in r3294f for the first time. So it must be one of the commits which were merged after r3292.

Cheers
manolito

[qyot27]

I am finally done with my tests of the different AVS+ builds, and at least for my computer it is pretty clear that the decrease in MT stability occurs in r3294f for the first time. So it must be one of the commits which were merged after r3292.
Not just 'one of the commits which were merged after r3292', specifically r3293 and r3294f*. While there may be a pile-on effect with later commits, the ones that need to be looked at are 93fd47de (https://github.com/AviSynth/AviSynthPlus/commit/93fd47ded842916a663de0e0ac2e9077bf94ee61) and 5479b184 (https://github.com/AviSynth/AviSynthPlus/commit/5479b18401641ae517c293d8b577d1a816c123f8).

*the test builds with 'f' stuck on the end are that way due to having to move 5479b184 from its original position as r3298 back into the position of r3294 so that the source could compile. r3293 doesn't compile on its own, but it does with the fix applied in 5479b184. Hence, the moved commit is r3294f and all the others that came after it were bumped up +1 and had 'f' tacked on the end. Shuffling the position around will not happen in the upstream master branch, it was only needed so that I could get a working build that pertained to only the changes in 93fd47de (which left a couple stragglers that 5479b184 fixed).

I'm not sure if moving from a typedef to a regular enum would cause this, or if it would be due to an int cast that was removed.

[manolito]

Thanks qyot for the explanation...

I went through these commits, but since I do not speak CPP I don't have a clue about what these commits might do to multithreading stability. I will stick with r3292 right now and see if my next conversions all go well.

Maybe these issues only apply to the 32-bit version of AVS+, maybe the Operating System has an influence (Win7-64), or maybe it is my older ThinkPad T530 notebook, whatever...

Thanks again
manolito

[real.finder]

I think there are some bug here https://forum.doom9.org/showthread.php?p=1918913#post1918913

[DTL]

I think there still exist some bug in resampler engine - https://forum.doom9.org/showthread.php?p=1919151#post1919151
With latest 3.6.1 trying SetMaxCPU to "none" do not helps and it looks equal in both vertical and horizontal resamplers.

[wonkey_monkey]

I've got a funny feeling I may have mentioned this before, but...

Specifying a non-existant blend more for overlay, e.g.:


colorbars.overlay(colorbars, mode = "doesnotexist")


results in an unhanded exception instead of a graceful error.

[qyot27]

I've got a funny feeling I may have mentioned this before, but...

Specifying a non-existant blend more for overlay, e.g.:


colorbars.overlay(colorbars, mode = "doesnotexist")


results in an unhanded exception instead of a graceful error.
I can't replicate this. I tried:
v1=Colorbars()
v2=v1.FlipHorizontal()
Overlay(v1,v2,mode="system")
and
v1=Colorbars()
v2=v1.FlipHorizontal()
Overlay(v2,mode="system")
and even a direct copy-paste:
colorbars.overlay(colorbars, mode = "doesnotexist")

and in all three cases it did throw an actual error message from AviSynth:
E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Overlay: Invalid 'Mode' specified.
(+) Video --vid=1 (rawvideo 640x480 29.970fps)
(+) Audio --aid=1 (pcm_f32le 2ch 48000Hz)
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] ...treating it as fatal error.

Exiting... (Errors when loading file)

E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Script error: Invalid arguments to function 'Overlay'.
[ffmpeg/demuxer] (test.avs, line 5)
[lavf] avformat_open_input() failed
[ffmpeg/demuxer] avisynth: Script error: Invalid arguments to function 'Overlay'.
[ffmpeg/demuxer] (test.avs, line 5)
[lavf] avformat_open_input() failed
Failed to recognize file format.

Exiting... (Errors when loading file)

E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Overlay: Invalid 'Mode' specified.
(+) Video --vid=1 (rawvideo 640x480 29.970fps)
(+) Audio --aid=1 (pcm_f32le 2ch 48000Hz)
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] ...treating it as fatal error.

Exiting... (Errors when loading file)
(although Windows Defender did not like that second one when I tried running it)

What it does seem like it's doing, though, based on the fact the video frame that gets generated matches the dimensions of Colorbars instead of the output of a simple GetMessage error clip, is that the error is getting emitted by avisynth, but it's not being written to the video itself, and the non-clip error is getting output instead (all those [lavf] error reading packet: Unknown error occurred. lines).

[wonkey_monkey]

Oh wait, I think I remember now. For some reason it doesn't throw the error on filter creation, as you would expect, but on GetFrame.

[Boulder]

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur. The clip was originally created in VirtualDub2 by loading an Avisynth script and saving as old format AVI using ffv1 v1.3 at 8 bits to compress. I tried re-encoding that clip to Huffyuv but it didn't help (the sample clip is that one)

Does anyone else see the same?

FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

Here's a 5-frame snippet to test on:
https://drive.google.com/file/d/1AwNgOESljQ5-Q40-vVpqDbq3khrv8uSm/view?usp=sharing

[poisondeathray]

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur. The clip was originally created in VirtualDub2 by loading an Avisynth script and saving as old format AVI using ffv1 v1.3 at 8 bits to compress. I tried re-encoding that clip to Huffyuv but it didn't help (the sample clip is that one)

Does anyone else see the same?

FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

Here's a 5-frame snippet to test on:
https://drive.google.com/file/d/1AwNgOESljQ5-Q40-vVpqDbq3khrv8uSm/view?usp=sharing


I get green bar too.

Changing to src filter to LSmash also results in green bar

Changing blur to 1.0, or 0.5 green bar still there

You can also reproduce with colorbars or blankclip


Colorbars(720,576,"YV12")
#Blankclip(width=720,height=576,pixel_type="YV12")
ConvertBits(16)
Blur(0.65)

[qyot27]

I can't reproduce. What versions of AviSynth+, VirtualDub2, and FFMS2 are you using? Tested here with 3.6.1, 44282, and C-plugin r1346+131 (2020-06-05; never released, but at this point I'd do well to run off a new build anyway). Neither 32 or 64 bit had issues.

[poisondeathray]

I was using avs+ x64 3.6.2 (r3300) . Preview is the same in avspmod x64, mpchc x64, or vdub2 x64

I think it's unrelated to source filter.



Colorbars(720,576,"YV12")
ConvertBits(16)
Blur(0.65)


https://i.postimg.cc/qvJ6rMdQ/greenbar000000.png

[wonkey_monkey]

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.

[qyot27]

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.
AVX might be it. Does it disappear if with SetMaxCPU("none")?

The only setup I've tested thus far is an Apollo Lake, so up to SSE4.2 should be okay. But I couldn't see it on either the source sample above or Colorbars. Apollo Lake doesn't have AVX or AVX2, though.

[Richard1485]

I used to see that same green line sometimes on standard AviSynth. It came up in the context of HD-to-SD conversions, usually involving a call to ColorMatrix(). Changing the order in which I called the functions would resolve it, so I just used to work round it.

[poisondeathray]

AVX might be it. Does it disappear if with SetMaxCPU("none")?

The only setup I've tested thus far is an Apollo Lake, so up to SSE4.2 should be okay. But I couldn't see it on either the source sample above or Colorbars. Apollo Lake doesn't have AVX or AVX2, though.

SetMaxCPU("none") fixes it for me

[Boulder]

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.

I think the line is there even in other cases, but it's not green. It's very faint, almost transparent. Could be placebo effect as well :D

I'm running a Ryzen 3900X system with Avisynth-3.6.2_20200624_test1 installed. I've done a lot of HD and UHD stuff since installing and I have not seen the issue in those so it must be somehow related to lower resolutions. This is the first SD level work I've started for a long time.

[manolito]

I used to see that same green line sometimes on standard AviSynth. It came up in the context of HD-to-SD conversions, usually involving a call to ColorMatrix(). Changing the order in which I called the functions would resolve it, so I just used to work round it.

I remember a similar problem from 2015 when using an older version (pre 2.5) of ColorMatrix. Updating to v 2.5 fixed it. I suppose that you use a "modernized" version of ColorMatrix these days, but maybe a regression from the old times has sneaked back in...

See here:
https://forum.videohelp.com/threads/277852-AVStoDVD-Support-Thread?p=2416492&viewfull=1#post2416492

[stax76]

@manolito

The latest staxrip beta has an experimental x86 build. It has 3 AviSynth modes to choose from, portable, installed and VFW. It misses many tools and all plugins except 2 source plugins. There is a setting under Danger Zone to disable the tool verification and there is a setting to disable plugin loading. For feedback please use the issue tracker.

[Boulder]

Despot v3.6.3.0 (x64) causes an access violation error with 3.6.2-test1. I didn't test any previous releases.

[wonkey_monkey]

Has something changed with animate? I just dug out an old script which used animate without specifying a clip (i.e. using implicit last) but that no longer seems to work. Now I have to specify "last" or tack it directly on the end:


# this works:

colorbars.animate(0,100,"blur",0.1,1.5)

# this works:

colorbars
animate(last, 0,100,"blur",0.1,1.5)

# this DOESN'T work:

colorbars
animate(0,100,"blur",0.1,1.5)


Edit: seems to be a problem with implicit last as in the post below.

[ajp_anton]

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")
"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

[Dogway]

Despot v3.6.3.0 (x64) causes an access violation error with 3.6.2-test1. I didn't test any previous releases.

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.

[Groucho2004]

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.I've been doing some debugging but to no avail. Also, very little time ATM.

[Groucho2004]

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.I have uploaded a new version (3.6.3.1), shouldn't crash any more.

[hello_hello]

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

Thanks.

[poisondeathray]

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.



You should use planar RGB for any processing
ConvertToPlanarRGB()

But maybe a better error message could be added

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()



No

[hello_hello]

You should use planar RGB for any processing
ConvertToPlanarRGB()

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.

But maybe a better error message could be added

But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?

No

Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?

Thanks.

[poisondeathray]

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.



But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?



That was referring planar vs. packed (interleaved) RGB , not "bits"

It's analogous to YV16 vs. YUY2 . Planar vs. Packed

eg. "RGB64" would be "RGBAP16" . Both are 16bit per channel RGB with alpha

http://avisynth.nl/index.php/Avisynthplus_color_formats

Planar processing is faster; most modern filters work with planar. Packed support is only for legacy purposes

When something doesn't work in avisynth for RGB processing , chances are you need planar RGB. That's where some better error message could be helpful


Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?



There should be no difference. You can check with subtract or psnr or simlar methods

"Better or not" depends on the situation

[hello_hello]

Thanks for the info. I'll do the color conversion in 32 bit planer and convert back to RGB64 or RGB32 etc later.

[pinterf]

Has something changed with animate? I just dug out an old script which used animate without specifying a clip (i.e. using implicit last) but that no longer seems to work. Now I have to specify "last" or tack it directly on the end:


# this works:

colorbars.animate(0,100,"blur",0.1,1.5)

# this works:

colorbars
animate(last, 0,100,"blur",0.1,1.5)

# this DOESN'T work:

colorbars
animate(0,100,"blur",0.1,1.5)


Edit: seems to be a problem with implicit last as in the post below.
Fixed on git.
# this DOESN'T work:
colorbars
Animate(0,100,"blur",0.1,1.5)

Animate is special in the way that it has two function signatures: "iis." and "ciis."
Passing the parameters with the syntax above will find the "clipless" version. Animate is created O.K.
When its internal expression parameter "blur" is evaluated later, it turnes out that it requires a clip. But it's too late, function with the matching (clipless) function signature was already chosen and Invoking "Animate" as a whole will fail and giving a function arguments error.

When such function parameter error exception is thrown, Avisynth will try to give a second changce and find the appropriate function with a forced clip ("last") variable.

[pinterf]

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

Thanks.
From RGB64 and RGB48 ConvertBits failed to get its floyd converter function internally, so it crashed.

Fixed on git, result should be the same as with planar RGB formats. Indeed, in this case 16 bit packed formats are treated internally (losslessly converted to and from) as planar RGB.

[pinterf]

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")
"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.
Could not reproduce.

[pinterf]

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur.
[...]
FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

fixed on git
AVX2 issue which occurs with non mod32 width.

[real.finder]

Function SCDetect(clip c, string "scFile", int "thSCD1", int "thSCD2", float "mDiff", int "pel", int "search", int "searchparam", bool "preblur", bool "info"){

scFile = Default(scFile, "scFile.log")
thSCD1 = Default(thSCD1, 360)
thSCD2 = Default(thSCD2, 120)
mDiff = Default(mDiff, 2.5)
pel = Default(pel, 1)
search = Default(search, 4)
searchparam = Default(searchparam, 2)
preblur = Default(preblur, true)
info = Default(info, false)

last = preblur ? c.RemoveGrain(20, 0) : c

Assert( IsYV12 , "SCDetect needs YV12 input!" )

super = MSuper(pel=pel, chroma=false)
vector = super.MAnalyse(pelsearch=pel, search=search, searchparam=searchparam, chroma=false)
global scMask = MSCDetection(vector, thSCD1=thSCD1, thSCD2=thSCD2).Crop(0,0,16,16)

global SC_mD = mDiff
global mean = Histogram(mode="Color").Crop(width+64, 64, 128, 128)

SCTrue = c.Subtitle("Scene change: true" )
SCFalse = c.Subtitle("Scene change: false")

info ? ConditionalFilter( last, SCTrue, SCFalse, "boolSC", "==", "true" )
\ : nop
FrameEvaluate( """global boolSC =
\ (
\ ( scMask.YPlaneMax == 255 ) &&
\ (
\ (mean.YDifferenceFromPrevious > SC_mD*3) ||
\ (
\ (mean.YDifferenceFromPrevious > SC_mD) &&
\ (mean.YDifferenceFromPrevious > (mean.YDifferenceToNext+mean.loop(0, 0, -1).YDifferenceToNext+mean.loop(0, 0, 1).YDifferenceToNext)/1.2)
\ )
\ )
\ )""" )

( scFile != "nul" ) ? WriteFileStart( scFile, """ "# Scene change frame list" """ ).WriteFileIf( scFile, "boolSC==true", "current_frame" ) : nop

return last
}
ColorBars
Converttoyv12
SCDetect

still not work (https://forum.doom9.org/showthread.php?p=1918893#post1918893) with build 0bf7242 I made, but Animate now work

[real.finder]

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")
"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

Could not reproduce.

I can, but you need to have grunt, without grunt not reproduce

[StainlessS]

Suspect BUG.
Prefetch(), seem to interfere with scriptclip evaluated runtime functions, optional named args, following an array of data args.

Here, and the following post:- https://forum.doom9.org/showthread.php?p=1922711#post1922711

[real.finder]

Suspect BUG.
Prefetch(), seem to interfere with scriptclip evaluated runtime functions, optional named args, following an array of data args.

Here, and the following post:- https://forum.doom9.org/showthread.php?p=1922711#post1922711

did you tried with test 2 ? https://drive.google.com/file/d/1h-CyjQPEvmj6ZZgYbYUY1pgrp8eovr9w/view

[StainlessS]

Thanks RF, no I did not yet, I always have problems downloadng Pinterf google drive stuff, I'll boot to linux and re-try download.

EDIT:
Got it under linux.
It actually downloads under Windows 7 with Opera (I forgot this time about Opera, but downloads usually only after some wait),
I have big-ish hosts file on windows blocking all kinds of ads/telemetry and stuff, Also Adblock origin, flash block and other stuff under both linux and
windows versions of firefox, so its probably my system hosts and firefox addons that cause me problems.

[StainlessS]

Yep, 3.6.2 test 2, removes the problem OK, thanks RF, sorry for the bother P & Q.

EDIT: I dont usually download files only test version of Avs+, until/unless there is an XP version included.

[manolito]

What is going on with this 3.6.2 test 2 build???

The first post of this thread still lists test1 as the latest test version. And when using the real.finder link for test 2 Google tells me that the file is infected with a virus and can only be downloaded by the owner...

@ StainlessS
AFAIk all the pinterf files only test versions are XP compatible.

[kedautinh12]

What is going on with this 3.6.2 test 2 build???

The first post of this thread still lists test1 as the latest test version. And when using the real.finder link for test 2 Google tells me that the file is infected with a virus and can only be downloaded by the owner...

@ StainlessS
AFAIk all the pinterf files only test versions are XP compatible.

Try link: https://mega.nz/file/w5w3RBDB#bYXUC82Sa250sxE-91qrfJZYTfnksOOXbJn6fvHx7qY

[StainlessS]

AFAIk all the pinterf files only test versions are XP compatible.
thankx, did not know that.

kedautinh12,
Thank ked, I got it from real.finder Pinterf link via linux.

[real.finder]

What is going on with this 3.6.2 test 2 build???

The first post of this thread still lists test1 as the latest test version. And when using the real.finder link for test 2 Google tells me that the file is infected with a virus and can only be downloaded by the owner...

@ StainlessS
AFAIk all the pinterf files only test versions are XP compatible.

it's from https://github.com/AviSynth/AviSynthPlus/issues/186#issuecomment-683817906

edit: seems you right there are problem with google drive, anyway it's only one https://www.virustotal.com/gui/file/d12c9d105f2a3af7f5b14273064e911d3754e5b1ef5cbfb8a25672dd3bfe4610/detection so it's false positive

also seems you didn't note https://forum.doom9.org/showthread.php?p=1922691#post1922691

[manolito]

No wonder that the unofficial 3.6.2 test2 build is not featured, because I found that it is thoroughly broken...

During a few tests with interlaced sample clips this one crashed reliably using the test2 build:
http://www.nepadigital.com/reencode/avidv.avi

First of all the SSRC audio filter seems to be missing. Plus the encode crashes because a VC++ redistributable is missing. The missing file is VCRUNTIME140D.dll, and this redistributable is not included in the very latest Abbodi VC++ AIO package. Reverting to version 3.6.2 test1 fixed the problems.

[kedautinh12]

No wonder that the unofficial 3.6.2 test2 build is not featured, because I found that it is thoroughly broken...

During a few tests with interlaced sample clips this one crashed reliably using the test2 build:
http://www.nepadigital.com/reencode/avidv.avi

First of all the SSRC audio filter seems to be missing. Plus the encode crashes because a VC++ redistributable is missing. The missing file is VCRUNTIME140D.dll, and this redistributable is not included in the very latest Abbodi VC++ AIO package. Reverting to version 3.6.2 test1 fixed the problems.

I think you need update all vc runtime c++ 2005-2019 last version

[StainlessS]

VCRUNTIME140D.dl looks to be a debug version of VCRUNTIME140.dl from Visual Studio 2015.
[you will not have it without the compiler, but dont seem to cause me problem and I dont have it]

[real.finder]

try this one https://www.sendspace.com/file/qooa40 I made it not as debug

[tormento]

did you tried with test 2
Questo file è infettato da un virus

Solo il proprietario può scaricare i file contenenti virus.
I.e. Drive complains about a virus and doesn't download it.

Any mirror available, please?

[real.finder]

I.e. Drive complains about a virus and doesn't download it.

Any mirror available, please?

for x86 see my post in #648

for x64 see kedautinh12 #642