AviSynth+ thread Vol.2

[FranceBB]

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.

Yep, the only drawback on XP is if just like me you have an AVX, AVX2 capable CPU 'cause it will stick with SSE4.2 at best 'cause Microsoft never implemented AVX/AVX2 on XP.
In other words, it's gonna use SSE, SSE2, SSSE3, SSE4.1, SSE4.2 only.
If, however, you use an xp compatible build on - let's say - Windows 10, it should use AVX and AVX2 (I can't say for AVX512 as I never tried: I don't have an AVX512 capable CPU).

Yes, whatever you changed in this version, it did solve all the previous problems... :D:D

Tested with the old StaxRip 32-bit version (which uses the VfW interface) and with VDub.

I can happily confirm that it does work with the VfW interface on Virtual Dub, in fact I was able to run pretty much every test script (and I tried several external filters as well).
Ferenc, whatever you changed, it worked, however... (yes, there's an "however") AVSMeter 3.0.0.4 still reports an ACCESS VIOLATION, AVSPmod says that there's been an error loading Avisynth and avs4x264mod shows this:

avs [error]: Exception while processing ScriptEnvironment::ThrowError().
(AVS Script.avs, line 1)

followed by:

https://i.imgur.com/sO2ZDgv.png

and then it just hangs there...
ffmpeg shows the very same message:

https://i.imgur.com/Gp82HZD.png

Please note that none of them was working before, so now at least Virtual Dub works.
We're making progress.

[pinterf]

Avspmod, ffmpeg and avs4x64mod are using C interface. Probably their problems have the same root. Not really important but 32 or 64 bit versions? Then Avsmeter crash how? With a script? Or avsmeter avsinfo?

[Groucho2004]

Result: (taken at 10% into the encode)
3.5.1 : 43.98 fps
3.6 test : 44.05 fps

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.These results are well within the margin of error. Windows is not a real-time OS.

[stax76]

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users? Almost everybody else gave up XP support long before.

Unicode support could be improved and a setup option to phase out VFW support, VirtaulDub2 is maybe the last tool that uses VFW and it's actively maintained, so the maintainer could access avisynth and vapoursynth directly, avisynth being in system32 blocks portable mode in staxrip.

On the long run avisynth will just die a slow death like other tools that were never modernized, like for instance megui.

FranceBB could easily fix it himself.

http://www.vapoursynth.com/2014/11/r25-death-to-windows-xp/

[real.finder]

FranceBB

can you try with this script?

ClearAutoloadDirs()
Version()

[Groucho2004]

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users? Almost everybody else gave up XP support long before.Funny, usually it's the XP promoting posts that are not popular.
To be honest, I'm surprised pinterf and qyot27 go through so much trouble keeping XP users happy.

[manolito]

I think you guys did not read my posts about this issue... :devil:

It had absolutely NOTHING to do with Win XP. This memory leak was under Win7-64 on a CORE i5 CPU. What it was about was a host software interfacing with AviSynth through the VfW interface AND at the same time loading a CPP 2.5 plugin in an AVS script.

If these two conditions are met then AVS+ 3.6 cannot release plugins from scripts which were terminated from memory. Reproduceable each and every time with VDub and StaxRip 1.1.9.0. And just any CPP 2.5 plugin. Only eliminating ALL 2.5 plugins OR not using the VfW interface would prevent this issue.

Now of course the AVS+ devs could prevent this issue by just dropping support for VfW and CPP 2.5 plugins. Maybe even raise the OS requirement to Win10 and ditch 32-bit. This is what folks like stax76 would like to see. I just hate this school of thinking to no end.

Anyways, I am very grateful to pinterf and this fellow devs for taking the time to fix this problem. To me it did not look like something which was necessary for the sake of progress. There was no such problem in AVS+ 3.5.1, and the new test version proves that it does not have to be a problem in 3.6.

[manolito]

These results are well within the margin of error. Windows is not a real-time OS.

Yes, this is exactly what I was saying. Using the XP compatible version under Win7-64 does not come with any speed penalty.

[FranceBB]

Avspmod, ffmpeg and avs4x64mod are using C interface. Probably their problems have the same root. Not really important but 32 or 64 bit versions? Then Avsmeter crash how? With a script? Or avsmeter avsinfo?

Yep, they're probably having all the same issue.
The version is 32bit (I have 32 GB DDR4 with PAE, but I'm planning to upgrade to 64 GB DDR4 for Christmas. Hilariously 64GB is the maximum amount of RAM that XP x86 can recognize as it was seen as something enormous back then).

As for AVSMeter:

AvsMeter.exe Avsinfo -lf -log

pause

https://i.imgur.com/pXJyYv5.png

I thought I could get some more info by making it write a log file but despite the flag it didn't really write one, probably because of the ACCESS VIOLATION error.


AvsMeter.exe "test.avs"

pause


test.avs


ColorBars(848, 480)


also has the same error, however VirtualDub works 'cause it's using the VfW interface:

https://i.imgur.com/oEpc0o7.png

And just to make sure that the VfW interface is working correctly with both internal and external plugins both new and old from 2003 to 2020, I made the "stupid_useless_test_filterchain.avs" with random filters and a list of gibberish values for the only purpose of trying to find incompatibilities:


ColorBars(848, 480, pixel_type="YV12")

maa2(mask=1, chroma=true, ss=2.0, aa=70, show=0)

ColorMatrix(mode="Rec.601->Rec.709", interlaced=false, threads=0, thrdmthd=0)

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false,
opt=3, mt=true, keep_tv_range=true, input_depth=8, output_depth=8)

gradfun3(thr=2.00, thrc=2.00, radius=68, smode=2, staticnoise=false, lsb_in=false, lsb=false)

Deblock_QED(quant1=30, quant2=36, aOff1=1, aOff2=1, bOff1=10, bOff2=10, uv=3)

FFT3DFilter(sigma=3.0, beta=1.0, plane=4, bw=16, bh=16, ow=8, oh=8, bt=3, kratio=3.0, sharpen=1.0, scutoff=0.3, svr=1.0,
smin=4.0, smax=30.0, measure=true, interlaced=false, wintype=0, degrid=1.0, dehalo=1.0, hr=2.0, ht=50.0)

dfttest(sigma=64, tbsize=1, lsb_in=false, lsb=false, Y=true, U=true, V=true, opt=0, dither=0)

super = MSuper(pel=2, sharp=1)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super,bv1,fv1,bv2,fv2,thSADC=800, thSAD=800)

ConvertBits(16)

ConverttoDoubleWidth()

hqdn3d(ls=8.0, cs=8.0, lt=6.0, ct=4.5, restart=7)

ConvertFromDoubleWidth()

ConvertBits(bits=8, dither=1)

AddGrainC(var=5.0, uvar=0.0, constant=true)

Spline64ResizeMT(704, 396)

HighlightLimiter(gblur=5.0, threshold=150, twopass=false)

LCE(brightness=80, correction=false, gblur=0.1, mode=1, contrast=1.5)

ContrastMask(enhance=10.0, tvcolor=true, gblur=20.0)

ConverttoRGB()

GamMac(dither=true, LockChan=-3, Scale=2, RedMul=1.0, GrnMul=1.0, BluMul=1.0, loTh=0.0, hiTh=0.0,
LockVal=128, RngLim=12, GamMax=10.0, omin=16, omax=235, Show=false, Coords=false)

ConverttoYUY2()
Declick(lthresh=35, cthresh=15, map=false)

Converttoyv12()

LUTDeCrawl(ythresh=10, cthresh=10, maxdiff=80, scnchg=100, usemaxdiff=true, mask=false)

checkmate(thr=12, max=18, tthr2=10)

tdeint(mode=2, order=-1, field=-1, mthreshL=6, mthreshC=6, map=0, type=2, debug=false, mtnmode=1,
sharp=true, cthresh=6, blockx=16, blocky=16, chroma=true, MI=64, tryWeave=true, link=1, denoise=true, slow=2, opt=4)

ChubbyRain2(th=10, radius=10, show=false, sft=10, interlaced=false)

DeScratch(mindif=5, asym=10, maxgap=3, maxwidth=3, minlen=90, maxlen=2048, maxangle=5, blurlen=15, keep=30,
border=2, modeY=3, modeU=3, modeV=3, mindifUV=0, mark=false, minwidth=1)

DeSpot(mthres=16, mwidth=7, mheight=5, merode=33, interlaced=false, show=0, show_chroma=false)

LGhost()

Levels(16, 1, 235, 0, 255, coring=false)

FastLineDarkenmod()

InterFrame(GPU=false, Preset="Medium", Tuning="Animation", NewNum=60000, NewDen=1001, InputType="2D", OverrideAlgo=13, Cores=1, FrameDouble=false)

ConvertBits(16)

ConverttoStacked()

nnedi3_resize16(target_width=848, target_height=480, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true,
kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)

ConvertFromStacked()

ConvertBits(bits=8, dither=1)

asharp(T=2, D=4, B=-1, hqbf=false)

aWarpSharp2(thresh=180, blur=3, type=0, depth=35, depthC=10, chroma=4)

ConverttoYV12()


and it worked just fine:

https://i.imgur.com/4HwvuSV.png


So we can say that VfW works fine and Avisynth 3.6.1 is correctly recognizing old and new plugins.
All is left is to understand why the C interface is producing an ACCESS VIOLATION, then...


FranceBB

can you try with this script?

ClearAutoloadDirs()
Version()

Works fine in VirtualDub, ACCESS VIOLATION on everything else:

https://i.imgur.com/z8ZWpZd.png



On the long run avisynth will just die a slow death like other tools that were never modernized, like for instance megui.


Never modernized? Modern indexers allow to deal with pretty much every new codec, new plugins allow to deal with HDR sources and apply tone-mapping or linear transformations like from HLG to PQ and so on. I think that looks pretty modern to me. I don't think Avisynth will die as long as people like Ferenc keep updating the core and developers like Jean Philippe Scotto di Rinaldi, StainlessSs, Groucho, Real.Finder, MeteorRain, Donald Graft and others keep working on plugins.
In the past there were people like Didee, WarpEnterprise, Tritical and other who left, but did Avisynth die? Oh no, it's more alive than ever and this community proves it. :)

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users?

I'm sure Win10 x64 users voices will be heard as well.
For the records, it's not like I bury my head in the sand, I have Win10 x64 with a modern Xeon CPU at work as well as at home as dual boot, so I enjoy efforts to modernize things like GPU acceleration in indexers like LSMASH or DGIndexNV as well. (This is from this evening, just saying: Link (https://i.imgur.com/WJD6iVH.png) I'm on Win10 x64 as you can see)

setup option to phase out VFW support, VirtaulDub2 is maybe the last tool that uses VFW and it's actively maintained, so the maintainer could access avisynth and vapoursynth directly

Why phasing that out? It's been around for so long that there could be other things relying on it.

avisynth being in system32 blocks portable mode in staxrip.

What do you mean? It doesn't have to be in system32.
It's in system32 only if it's installed as it's the default location, however I can definitely use Avisynth without installing it as long as I know its directory. For instance, FFASTrans it's an example of how Avisynth.dll can be used without installing anything on the system.


Now of course the AVS+ devs could prevent this issue by just dropping support for VfW and CPP 2.5 plugins. Maybe even raise the OS requirement to Win10 and ditch 32-bit. This is what folks like stax76 would like to see. I just hate this school of thinking to no end.

Anyways, I am very grateful to pinterf and this fellow devs for taking the time to fix this problem.

I quote everything.
Like, I don't really take this kind of support for granted, but if Ferenc is so kind to spend time on the issues we all report (me included), then I'm really glad.
Heck, when this whole coronavirus story is over it would be fun to meet you all somewhere like at some broadcast/encoding event and if Ferenc comes I'll buy him lunch, I really will.


FranceBB could easily fix it himself.

Believe me, I would love to contribute directly to the Avisynth code on Github, but I still have to learn a lot of C++ before I will be able to contribute.
I studied Computer Science Engineering (bachelor degree) and I'm now doing a master degree while working in broadcast, so my schedule is already pretty full; it's so full that I don't watch TV anymore... I rarely watch a movie every once in a while... When I travel instead of listening to music I listen to my own recorded voice reading formulas or theorems trying to memorize them... And you know why? 'cause I can't afford to just stay at home, pay my rent with I don't even know what money, without a job and pay for my studies. So... "yes", I gotta keep working and "yes" I gotta keep studying and "no" I can't actively contribute to the Avisynth Core even if I really wanted to... :(

[stax76]

@manolito

I've sympathy for people that hang on to old things or not the most popular choices. I'm just trying to say that sometimes it's necessary to give something old up in order to make room for something new, for instance to correct bad decisions made in the past. If people hang on, that's fine, if people don't, that's fine too, in reality you always have and need both type of people.

What do you mean? It doesn't have to be in system32.
It's in system32 only if it's installed as it's the default location, however I can definitely use Avisynth without installing it as long as I know its directory. For instance, FFASTrans it's an example of how Avisynth.dll can be used without installing anything on the system.

staxrip supports portable mode for both avisynth and vapoursynth. The avisynth and vapoursynth SDK should clearly describe how client tools are supposed to load the DLL in order to support things like portable mode. A client tool like staxrip should be able to give the user the choice between using an included avisynth version or the installed version, right now that's difficult due to the way how avisynth and tools are designed, it works with vapoursynth much better, like a couple of other things, it's more modern and ironically Python is not modern at all.

[manolito]

@FranceBB

I tried to reproduce your issues using C-Plugins with the latest test build by pinterf. But I couldn't...

What is this error about ScriptEnvironment? I do not understand. I have GrunT.dll in my autoload folder, and it does not interfere with anything. Do you autoload any GScript stuff?

The only C-Plugins I use are the old original YADIF plugin and the ffms2 C-plugin. And both work just fine under this latest pinterf test build. AVS+ autoloads these C-Plugins just fine, and under AVStoDVD (which does not use the VfW interface) both work without any issues.

This is under AVS+ 32-bit, Win7-64 .

[qyot27]

Funny, usually it's the XP promoting posts that are not popular.
To be honest, I'm surprised pinterf and qyot27 go through so much trouble keeping XP users happy.
Most of the time it's just certain CMake parameters/CXXFLAGS/LDFLAGS given when configuring the project, so the only time consumed is what it takes to compile. As long as it's just something like that, I don't feel a compelling reason to drop it.

It's really not a whole lot of energy at all. Oh, copy-paste line 1 instead of line 2. Go fix some coffee.

[kedautinh12]

Dear volunteers, please test this version with as much CPP-2.5 plugins as you can (including those which were crashing with 3.6)
Avisynth+ 3.6.1-20200527 test (https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing)

Files only, *XP-compatible version, 32 bit version runs on SSE
*cannot guarantee until you are reporting that is really works.

Features: a bit (much) more friendly to Avisynth 2.5 style plugins

- AvisynthPluginInit2 passes a separate ScriptEnvironment for CPP2.5 plugins, so Avisynth+ can catch their AddFunction and Invoke methods
- since Avs2.5-ness is registered during plugin loading and AddFunction, calling such plugins from Avisynth+ core can happen in a compatible way without memory leaks.

This results in stopping memory leak (on e.g. "last" clip would not freed up on destroying ScriptEnvironment) resulted in increasing memory consumption when doing consecutive script reloads in VirtualDub or probably in other editors.

Can you make 3.6.1 for megui win 10???

[FranceBB]

@FranceBB

I tried to reproduce your issues using C-Plugins with the latest test build by pinterf. But I couldn't...

What is this error about ScriptEnvironment? I do not understand. I have GrunT.dll in my autoload folder, and it does not interfere with anything. Do you autoload any GScript stuff?

The only C-Plugins I use are the old original YADIF plugin and the ffms2 C-plugin. And both work just fine under this latest pinterf test build. AVS+ autoloads these C-Plugins just fine, and under AVStoDVD (which does not use the VfW interface) both work without any issues.

This is under AVS+ 32-bit, Win7-64 .

I have GrunT as well in my auto-load folder, but that's not the problem. The problem is that whenever I call Avisynth with the C interface instead of the VfW interface, it prompts me to an ACCESS VIOLATION.
You see, just like you have Win7 and WinXP and you wanna keep one version of every plugin on both to keep everything in the two machines consistent, I have the very same setup on Win10 and WinXP where I keep everything the same (except for the x64 version which is Win10 only for me), however with Avisynth 3.6.x on XP x86 I can't use programs that call the frameserver using the C interface like AVSPmod, AVSMeter etc.
On Win10 it works like a charm now, though...
So it must be something in the C interface to call Avisynth that makes XP misbehave. Solving your problem in AVS 3.6.1 actually partially solved mine too, 'cause before, with AVS 3.6.0, not even the VfW interface was working, so we made progress. I'm sure Ferenc or qyot27 will come up with a solution.

[Groucho2004]

..however with Avisynth 3.6.x on XP x86 I can't use programs that call the frameserver using the C interface like AVSPmod, AVSMeter etc.AVSMeter uses the C++ API to interface with Avisynth.

[pinterf]

AvsMeter has no C interface.

And unfortunately for me all tools are working properly (Win10 with avs+ 32 or 64 bits), Avspmod, x264 versions, AvsMeter (32 and 64 bits)
But the problem needs to be investigated. Not because of XP support but it can be a hidden bug which later can occur on other systems as well.
No crash occurs without a good reason.

[pinterf]

Can you make 3.6.1 for megui win 10???
Grab it and use.
XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.

[Groucho2004]

@FranceBB
You're testing this on a vanilla XP, not the one with modified kernel, right?

[pinterf]

Unicode support could be improved

As a small step, if you need, you can open scripts from an unicode path, no need for ansi conversion.

https://github.com/staxrip/staxrip/blob/master/FrameServer/AviSynthServer.cpp#L72


AVSValue args[2] = { utf8file.c_str(), true };
const char* const arg_names[2] = { 0, "utf8" };
env->Invoke("Import", AVSValue(args, 2), arg_names);

[FranceBB]

@FranceBB
You're testing this on a vanilla XP, not the one with modified kernel, right?

Untouched SP3 on my VirtualBox VM where I test.
SP4 with Microsoft Extended Updates 'till July 2019, custom kernel with Win Vista and a bit of 7 backported APIs, unlocked PAE, DirectX 11 on my real PC.
They both behave the same in this case.
As a matter of fact, they've always behaved the same for Avisynth.
The custom kernel did the trick by implementing kernel calls necessary to run things like Audacity, Blender, Adobe Acrobat Reader DC and other things.

[tormento]

Grab it and use. XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.
Any caveat about performance, AVX etc?

[Groucho2004]

Untouched SP3 on my VirtualBox VM where I test.OK, just checking. :)

[kedautinh12]

Grab it and use.
XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.

I replaced 3.5.1 but can't open megui x64, moved back work again

[LigH]

@tormento:

Nothing is disabled. Xp as an os does not support avx and up but that's all

[pinterf]

I replaced 3.5.1 but can't open megui x64, moved back work again
See Megui section in first post. And the others as well.

[stax76]

As a small step, if you need, you can open scripts from an unicode path, no need for ansi conversion.

I saw the discussion with v0lt, made some experiments and thought if I could work around the limitation by creating soft links but gave up the idea. In another country I might have tried changing the system code page to utf8 which is a Win 10 feature, I'm on 1252. There was a post by TheFluff that explained there is some utf8 support in ffms2 and it appeared to work but not with the cachefile parameter, in that old thread I participated without great Unicode experience, it has improved meanwhile and my apps have solid Unicode support but find the topic still rather difficult, but also very interesting and important. I opened an avs Unicode issue in the mpv tracker and wm4 didn't have much good to say about avisynth, some time later I found out why, see here (https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe).

[manolito]

@FranceBB

I tried to reproduce your issues using C-Plugins with the latest test build by pinterf. But I couldn't...
-------------------------------------------------------
This is under AVS+ 32-bit, Win7-64 .

I believe this was a slight misunderstanding...

My tests were under Win7-64, not under WinXP. My XP computer has a single core CPU and only 576 MB of RAM. So using AVS+ with multithreading would not make sense. I tried it with a previous AVS+ version, but soon went back to classic AVS because it was faster.

After your issues I installed the current 3.61 test version under XP, but I could not get it working at all. The version() call returned the correct version, but neither AVStoDVD nor StaxRip were able to load any source files. AVStoDVD could not even detect an installed AviSynth version and gave me a non-fatal warning at startup. No crashes, though.

I never tried AVS+ 3.5.1 on the XP machine, but I suppose that it would work.

//EDIT//
Being curious and not tired yet I just did install the 3.5.1 XP version on my WinXP machine. And just as I suspected this version works fine under XP. Overinstalling the latest test version again broke it completely. So for me this 3.6.1 test version fixes all previous 3.6 issues under Win7, but it sure does not deserve the label "XP version".

[FranceBB]

After your issues I installed the current 3.61 test version under XP, but I could not get it working at all. The version() call returned the correct version, but neither AVStoDVD nor StaxRip were able to load any source files. AVStoDVD could not even detect an installed AviSynth version and gave me a non-fatal warning at startup. No crashes, though.

Exactly. You didn't try virtual dub, though. After your issue with Windows 7, Ferenc released another version and managed to make virtual dub work on XP.

In other words:

3.6.0 - nothing works.
3.6.1 - Programs accessing Avisynth directly don't work, but those who use VfW like virtual dub do.


I never tried AVS+ 3.5.1 on the XP machine, but I suppose that it would work.

Yes, 3.5.1 works like a charm.

Thank you for testing it on your system, though, it makes 2 out of 2 so I'm sure it's not related to my configuration.

[manolito]

3.6.0 - nothing works.
3.6.1 - Programs accessing Avisynth directly don't work, but those who use VfW like virtual dub do.


Right, I did not test VDub, just forgot about it. But I did test StaxRip 1.1.9.0 which also uses the VfW interface. Not good, it was unable to open any source file regardless of the source format. All source filters (DSS2Mod, ffms2, LSmash and DirectShowSource) quit with an error.

[vcmohan]

hi vcmohan
since you about update your plugins, can you make your plugins look for libfftw3f-3.dll first, then fftw3.dll like https://github.com/pinterf/fft3dfilter/blob/8c47e8d371afc7d6f9dce08ecb3443761a1cea00/fft3dfilter/FFT3DFilter.cpp#L711 ?
Certainly. But I do not know what all have changed from avisynth interface version 6 to this new version. Where can I get the avisynth new version header file?
Is there a problem if I look for fftw3.dll first or is there an advantage of looking for libfftw3f-3?

There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.

[real.finder]

Certainly. But I do not know what all have changed from avisynth interface version 6 to this new version. Where can I get the avisynth new version header file?

I think new version header here https://github.com/AviSynth/AviSynthPlus/tree/master/avs_core/include

Is there a problem if I look for fftw3.dll first or is there an advantage of looking for libfftw3f-3?

both, fftw3.dll were used to be old one that come with FFT3DFilter, the default name for new one one is libfftw3f-3.dll


There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.

don't know about this maybe pinterf or qyot27 will answer

[pinterf]

I have succesfully done an XP install inside my Win10 using the MS supported Win7 VirtualBox machine and started to debug.
Debug means that I write to debug output: "Hi, I am here", "Hi, I am there", etc.. and look the latest sign of life.
Presently there seems to be the problem with thread local storage technique which was needed for fixing the infamous mt bugs.
But it seems that XP behaves badly on this aspect when DLL is loaded dynamically so I'll dig into MSDN and StackOverflow, this will be a learning weekend.

[pinterf]

Dear volunteers, please test this build, it is working on my XP so let's hope the best.
Avisynth+ v3.6.1 test build (20200529) (https://drive.google.com/file/d/1sDlI4Kdkf5PA2NyIkQ9XsrcCDs5QwHCg/view?usp=sharing)

[pinterf]

There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.
MakeWritable is create new frame + copy from original + copy frame properties. It preserves everything. You cannot make this task in less steps.
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3681

[stax76]

For staxrip it's a problem that avisynth.dll is located in system32 because this does not allow portable mode. staxrip uses about 10 avisynth tools, many just call LoadLibrary("avisynth.dll") which results in the DLL from system32 is used instead of the one from PATH which staxrip sets to enable portable mode.

It's not strictly necessary I believe that avisynth is located in system32 and it's probably also not good practice, vapoursynth don't put any DLL in system32 I believe (except VC++ redist), for compatibility with existing tools it would be necessarily to put avisynth in PATH.

[pinterf]

And a really portable version is not using registry.

[stax76]

For portable mode I needed minimal changes:

1. put in PATH: AviSynth, VapourSynth/Python, FFTW

2. create avisynth soft link for ffmpeg because ffmpeg blocks default DLL loading which uses PATH

For vapoursynth to use PATH:

core.std.LoadPlugin(..., altsearchpath=True)

Registry is not needed, PATH is modified per process, needed folders are put on top.

All this only works if avisynth is not installed, that is the problem, all fine with vapoursynth as it don't use system32.

[manolito]

Dear volunteers, please test this build, it is working on my XP so let's hope the best.
Avisynth+ v3.6.1 test build (20200529) (https://drive.google.com/file/d/1sDlI4Kdkf5PA2NyIkQ9XsrcCDs5QwHCg/view?usp=sharing)

Thanks very much...

Tested it first under Win7 to make sure that there are no regressions compared to the previous test build. And I could not detect any... :D

Then installed it under WinXP SP3. Most of the previous problems were gone. AVStoDVD and StaxRip could open files and process them without issues.

The only problem which is still there is the script environment. One of my avsi scripts uses GrunT and calls the GScriptClip function. This still does not work, I get this error message in the preview:
Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3)
Looks like the built-in ScriptClip function in AVS+ conflicts with the GScriptClip function from GrunT.
AVS+ 3.51 for XP handles this without errors.

FranceBB, what do you think?

[FranceBB]

Dear volunteers, please test this build, it is working on my XP so let's hope the best.
Avisynth+ v3.6.1 test build (20200529) (https://drive.google.com/file/d/1sDlI4Kdkf5PA2NyIkQ9XsrcCDs5QwHCg/view?usp=sharing)

Today I was told by the boss of my boss of my boss to stay at home on an enforced paid leave 'till June 14th even if I didn't want to and to come back on Monday June 15th as all sport events in every nation are gonna be back.

Such a dreadful day was quickly turned into a good one as I logged off from my server, opened this tread, found this build, tried it and saw that it's working perfectly.

Thank you, Ferenc, once again.
What would we do without you... :)

AVStoDVD and StaxRip could open files and process them without issues.

The only problem which is still there is the script environment. One of my avsi scripts uses GrunT and calls the GScriptClip function. This still does not work, I get this error message in the preview:

Looks like the built-in ScriptClip function in AVS+ conflicts with the GScriptClip function from GrunT.
AVS+ 3.51 for XP handles this without errors.

FranceBB, what do you think?

Well, I don't have StaxRip but avs4x264mod, AVSMeter, AVSPmod, PotPlayer, MPC-BE, MPC-HC, ffmpeg all work.

[pinterf]

Well, so it's (almost) working for at least two people, thanks for the feedback. Test it over the weekend, I'll be offline for some days (if I can :) ) because of a postponed Lth bd party, be good testers.

[MeteorRain]

I have never used megui so I wonder what that means. As I understand it, megui is just a frontend for various encoders and uses Avisynth to gather information about the source file/script. So, if I'm correct it just has to load the script and extract the information from it, right?

That's definitely challenging. AviSynth has a vfw interface, has a C++ interface, and has a C interface. I can trust vfw interface because it hasn't changed for decades. But C/C++ interface? They are vulnerable to all kinds of compatibility issues.

Out of curiosity, I am bit confused about how the HBD plugins treat the images.

AFAIK the most used bit depths nowadays are 8 and 10 (12 on some specialized streams only).

How does it work when you set HBD or a plugin receives a HBD?

Doest it switch to 16 bits (or more) regardless of true bit depth or does it work with the same bit depth of the source?

Because if it goes straight to 16 bit to work on a 10 bit stream, it seems to me really a waste of power and it would need a dedicated algorithm to process 10 bit only, as they are the second most common after 8, and get faster.

All depends on how the author writes the plugin, and also depends on how complicated the plugin is.
For example, a simple medium filter does not need to raise bit depth because no computing is needed. However a similar average filter may need to raise bit depth because average operation gets accuracy benefit from higher bit depth.

Also for some plugins it's easier to raise 10-14 bit to 16 bit so you only need to write a 16 bit version, and a bit shifter / dither.

[vcmohan]

MakeWritable is create new frame + copy from original + copy frame properties. It preserves everything. You cannot make this task in less steps.
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3681

Well thanks for dispelling misconception. So I will hearafter use this wherever appropriate. I have been using env2->Allocate(.......) to get required buffer for thread safety. It looks I can not get over this problem easily by testing for version. Or can I do a similar try and catch scenario? like
if (v8) env->Allocate(...); else env2->Allocate(...)

[StainlessS]

@ vcmohan, I had posted this previously
Not sure but I think MakeWritable was originally referred to as the "MakeWritable hack" [and was used via a MACRO/define, probably some time prior to v2.58],
it was later officially incorporated as env->MakeWritable(&src);

So nothing wrong now using MakeWritable.

EDIT: DG would probably remember exactly, it was before my time with avs.

Was a bit before my time here though.

EDIT: You still see some MakeWriteable hack references in old source code.

[manolito]

Well, so it's (almost) working for at least two people, thanks for the feedback. Test it over the weekend,

Did some more tests under Win7 and WinXP, but I did not find anything new. Under Win7 there are no issues whatsoever, and under XP this "GScriptClip" issue is the only problem I found.

I am not very knowledgeable about the AVS runtime stuff. But after calling "GScriptClip" this error message is a little confusing:
Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3)
I did not call ScriptClip at all. There is no text file "ScriptClip" with line numbers in my plugin folder. Does the GRunT "GScriptClip" function call the internal AVS "ScriptClip" function? Sure looks like it.

Something must have changed with the internal "ScriptClip" function of AVS+ after version 3.5.1.

It is not a big deal, though. The "GScriptClip" call can be replaced with a "ConditionalFilter" call, and this method works. The drawback is that "ConditionalFilter" does not work well in MT mode (this is what I read), but then again I cannot use MT anyways on my WinXP computer.

Cheers
manolito

[StainlessS]

What is your script Mani ?

[manolito]

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
\ (" + string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
\ (" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M",
\ args = "EMskip,M,B,BHard", Local=true)


Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.

[StainlessS]

GScriptClip is just an nicety to explicitly state that you are using Grunt version of Scriptclip.
The alternative (G*) names may be used if you wish, but this is optional in AviSynth version 2.58 or later
http://avisynth.nl/index.php/GRunT#ScriptClip

The fact that you use Args arg, should only use Grunt version G/Scriptclip (Avs+ ver$ dont have Args arg).


The Float thing got me stumped :(

Your ScriptClip call had me a little perplexed/confused, not easy to read, and so I started dissecting it,
and once I started could not stop, it dont look correct to me when compared to the original commented out ConditionalFilter stuff.

Hope you can figure this lot out, I'm whacked and gotta get some kip soon.


## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M

# Roughly Mani script
SSS="""
Skip = EMskip.AverageLuma()
("
+ string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
(" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M
"""

# Vars with trailing '_I' are numbers directly inserted. Renamed Skip to AverageLuma_Skip.
SSS="""
AverageLuma_Skip = EMskip.AverageLuma()
(SkipOver_I > 0 && AverageLuma_Skip >= SkipOver_I ) ? BHard : (BlendOver_I > 0 && AverageLuma_Skip >= BlendOver_I) ? B : M
"""

# Dissect original Conditionalfilter stuff.
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
M2 = SkipOver <= 0 || AverageLuma_Skip < SkipOver ? B : BHard # Equivalent
M2 = SkipOver > 0 && AverageLuma_Skip >= SkipOver ? BHard : B #

# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = Blendover_I <= 0 || AverageLuma_Skip < Blendover_I ? M : M2 # Equivalent
M = Blendover_I > 0 && AverageLuma_Skip >= Blendover_I ? M2 : M #

# Only calc M2 [ie B or BHard] when we have to, ie detect where M result first. # All 4 Equivalent (Hopefully)
M = (Blendover_I <= 0 || AverageLuma_Skip < Blendover_I) ? M : (SkipOver <= 0 || AverageLuma_Skip < SkipOver) ? B : BHard
M = (Blendover_I <= 0 || AverageLuma_Skip < Blendover_I) ? M : (SkipOver > 0 && AverageLuma_Skip >= SkipOver) ? BHard : B
# I hate doing ternary conditionals this way, possibly messed these 2 up.
M = (Blendover_I > 0 && AverageLuma_Skip >= Blendover_I) ? (SkipOver <= 0 && AverageLuma_Skip < SkipOver) ? B : BHard : M
M = (Blendover_I > 0 && AverageLuma_Skip >= Blendover_I) ? (SkipOver > 0 && AverageLuma_Skip >= SkipOver) ? BHard : B : M


# Somewhat different to this (Should only be BHard or B when BlendOver > 0 && AverageLuma_Skip >= Blendover_I, Otherwise always M)
(SkipOver_I > 0 && AverageLuma_Skip >= SkipOver_I ) ? BHard : (BlendOver_I > 0 && AverageLuma_Skip >= BlendOver_I) ? B : M


Hope I aint screwed up, I'm sure somebody will delight in pointing it out if I have [and please do] :)

[real.finder]

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:



Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.

can you try this? https://www.solidfiles.com/v/Q4WmdaAZ3jMYn

[pinterf]

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:



Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.
Uh, I think I found another unhandled case when a 2.5 plugin function (namely ScriptClip clone in Cpp 2.5 GRunT) is created but it calles back Invoke in the filter constructor before instantiating itself.

[pinterf]

New build:
Avisynth+ 3.6.1. test build 4 - 20200531 (https://drive.google.com/file/d/1EfjzGE9qSYc-ZZAakT2xbIrkpHJ_pwxI/view?usp=sharing)

@manolito: please test with your script that was giving you that strange error of
"Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3) "
I wonder what message you get this time (if any)
Thanks!