Avisynth+

[StainlessS]

GMJCZP,

As a recommendation, I suggest you forget NotePad (standard) and right click and select "Open With" to maybe PsPad or NotePad+ (NotePadPlus),
which both supports Edit of Avisynth script (with keyword hi-lite) and Play of the script, really quite a lot more useful than NotePad standard.

As Pinterf mentions in Avs Usage, MPlayer2 is still supplied, even in Win10, I always quite hated WMVxxx, really horrible, whereas MPlayer2 is very
usable and what I use (together with MPC-HC in PsPad) to view/test scripts.

Give'it a whirl, you might like it.

EDIT:
and select "Open With"
You can actually set that inside both PsPad and NotePad+ settings.

EDIT: In XP, some clips do not play in MPlayer2.exe, but for most, I much prefer over WMVxxx.
In XP, MPlayer2, is located in same directory as WMVxx (C:\Program Files\Windows Media Player\).

EDIT: It is a bit peculiar that MPlayer2 is still provided, another weird little thing is that from W98 onwards, there was always
a DVD player included (REALLY basic) , just not an MPEG2 decoder, called DVDPlay.exe (I think, in system32), dont know if it is still there.

[GMJCZP]

TinMan, the idea is that when opening a script open the notepad, as with the old avisynth, if not then I do not understand the idea of file associations, using FileTypesMan was not what I had in mind with AVS+. :(

EDIT: I use "Open With" for VirtualDub/ VirtualDubMod or WMP/ MPC-HC

[StainlessS]

'Open With', (and tick the 'Always' [or whatever its called] tick box).

EDIT: You can still then use "Open With" on the odd occasion for VDub.

[nhope]

Thanks for the update pinterf.

Regarding this screen...

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus1.png

...I got a little confused/concerned because I thought a) maybe it would now install the Avisynth.dll file itself in that folder, and b) I might be about to get only the x86 version.

Of course, it did neither, but I think it would be useful to explicitly state at that stage of the installation that it will install both x86 AviSynth+ in C:\WINDOWS\System32 and x64 AviSynth+ in C:\WINDOWS\SysWOW64, and that the folder being chosen at this stage of the installation is just for the plugins for both versions, along with the license and uninstaller etc..

Another thing the installer did was detect that I had AviSynth installed in d:\Documents\AvisynthRepositor\AVSPLUS_x86:

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus2.png

Actually I didn't. That was just a "dumb" folder, with no files in it being used in my existing AviSynth installation. When I renamed it and ran the installer again, it was ignored.

[Groucho2004]

Of course, it did neither, but I think it would be useful to explicitly state at that stage of the installation that it will install both x86 AviSynth+ in C:\WINDOWS\System32 and x64 AviSynth+ in C:\WINDOWS\SysWOW64It's the other way around (x86 to SysWoW64, x64 to System32). :D




Another thing the installer did was detect that I had AviSynth installed in d:\Documents\AvisynthRepositor\AVSPLUS_x86:

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus2.png

Actually I didn't. That was just a "dumb" folder, with no files in it being used in my existing AviSynth installation. When I renamed it and ran the installer again, it was ignored.
Yes you did. The detected directory is the "default" value in "HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth". Although not strictly necessary, some programs use this registry value to determine if Avisynth is installed (that's why the Universal Installer writes it too). This entry is also written by the classic Avisynth installer.

[mcjordan]

FYI: thru Avisynth+ r2575 compilation

..\avs_core\filters\limiter.cpp ->
#include <core/internal.h> is wrong
right is:
#include <../core/internal.h>

[pinterf]

FYI: thru Avisynth+ r2575 compilation

..\avs_core\filters\limiter.cpp ->
#include <core/internal.h> is wrong
right is:
#include <../core/internal.h>
Modified, thanks. (Why did it work for me and not for you)

[mcjordan]

Hmm... I don't know. I'm under Win7 and VS2017 15.5.2

Another (non-fatal) error that occurs during a compilation of a long time ago:
...
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(384): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(455): note: see reference to function template instantiation 'void overlay_blend_sse2_plane_masked<uint8_t,8,false>(BYTE *,const BYTE *,const BYTE *,const int,const int,const int,const int,const int)' being compiled
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(405): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(957): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(1012): note: see reference to function template instantiation 'void overlay_blend_sse2_plane_masked_opacity<uint16_t,16,true>(BYTE *,const BYTE *,const BYTE *,const int,const int,const int,const int,const int,const int,const float)' being compiled

[pinterf]

Hmm... I don't know. I'm under Win7 and VS2017 15.5.2

Another (non-fatal) error that occurs during a compilation of a long time ago:
...
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(384): warning C4309: 'argument': truncation of constant value

Yes, I know, fortunately it's only a warning, usually this type of warning is switched off temporarily by pragmas, which I have not done yet. (Like setting a 16 bit word to 0xFFFF while the parameter is "short" (signed 16 bit) type)

[mcjordan]

Thank you, pinterf. Sorry for disturbance.
And wish you a happy Мerry Christmas.

[GMJCZP]

Excuse me pinterf, did you read by chance post # 3800? Thanks.

[pinterf]

Excuse me pinterf, did you read by chance post # 3800? Thanks.Yes, but I placed the editor option into "Open With" intentionally in order not to overwrite notepad++ or other existing associations. I could still use rightclick on avs file and select notepad and tick "always use this program" (I'm on win10). I'm not near a computer but I think the reinstall will keep the setting of that checkbox.

[GMJCZP]

Thanks pinterf for answering.

The problem is that if you use "always use this program" the script icon will be notepad and not AVS+, which does not happen with the old avisynth.

[StainlessS]

Cant you just (on XP at least), select Windows Explorer, "Folder Options/File Types" and find "File Extension"
'AVS', click "Advanced", "Change Icon", "Browse", find "Avisynth.dll" (wherever it is located), select your
chosen icon, then "OK" and "Close".

I guess if you change avs version a lot, & havta do it every time it could get a bit tedious.

EDIT: After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions. (not affected by "Do Not Cache Thumbnails"
in folder options).

EDIT: Cant say that I've ever noticed what icon avs came up under. [I ALWAYS have it on Details WITH EXTENSIONS, except in Control Panel
or Administrators Tools [where all icons are different, no point at all in icons when a folder full of identical file types].

I tried to find similar on windows 10 (not quite as horrid as I thought it would be, but hate those damn long
timeouts when it updated to Creators Update [or whatever its called]), but seems like change file icon functionality
has died out. Seems you have to be an IT Pro to want to change file icons, here suggests using ShellExView utility.
https://social.technet.microsoft.com/Forums/windows/en-US/8463dbfe-52f3-4cd2-9118-f07323a83d6e/change-file-types-program-associated-to-an-extensionfile-type?forum=w7itproui

[Groucho2004]

After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions.You can delete the cache manually by deleting "IconCache.db" in "%USERPROFILE%\Local Settings\Application Data".

[GMJCZP]

Cant you just (on XP at least), select Windows Explorer, "Folder Options/File Types" and find "File Extension"
'AVS', click "Advanced", "Change Icon", "Browse", find "Avisynth.dll" (wherever it is located), select your
chosen icon, then "OK" and "Close".

I guess if you change avs version a lot, & havta do it every time it could get a bit tedious.

EDIT: After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions. (not affected by "Do Not Cache Thumbnails"
in folder options).

EDIT: Cant say that I've ever noticed what icon avs came up under.

That's why I prefer the installer of the old avisynth, which already does everything automatic. I only ask that if it is possible to emulate this with the AVS+ installer and not have to resort to a program like FileTypesMan to do things manually.

[StainlessS]

Thanx Grouchy, knew I'de seen it somewhere. :) [EDIT: also forgot about Thumbs.db, I always Do Not Cache Thumbnails].

That's why I prefer the installer of the old avisynth, which already does everything automatic. I only ask that if it is possible to emulate this with the AVS+ installer and not have to resort to a program like FileTypesMan to do things manually.

Computers are not intended to make life easy, just more interesting :)

[GMJCZP]

TinMan, your enigmatic words do not make me feel better :rolleyes: :)

[THEAST]

I decided to give Avisynth x64 a try after a very long time; however, I am not sure how I can use Avisynth x86 and x64 at the same time. I used the latest installer for AVisynth+ MT (r2574) which installs the 32-bit DLLs into SysWOW64, and the 64-bit DLLs to System32. With this configuration, MeGUI x64 can load my existing Avisynth scripts correctly; however, MeGUI x86 and VirtualDub x86 do not work (MeGUI crashes with C:\WINDOWS\SYSTEM32\avisynth.dll as faulting module path, and VDub generates an illegal instruction error). If I move the 32-bit DLLs to System32 and overwrite the 64-bit ones, then the x86 apps work correctly (but MeGUI x64 obviously does not). It seems all these apps default to System32 to find avisynth.dll. Am I missing something here? Is there any way I can use Avisynth x86 and x64 at the same time and choose which one to be loaded depending on the application?

[ajp_anton]

I decided to give Avisynth x64 a try after a very long time; however, I am not sure how I can use Avisynth x86 and x64 at the same time. I used the latest installer for AVisynth+ MT (r2574) which installs the 32-bit DLLs into SysWOW64, and the 64-bit DLLs to System32. With this configuration, MeGUI x64 can load my existing Avisynth scripts correctly; however, MeGUI x86 and VirtualDub x86 do not work (MeGUI crashes with C:\WINDOWS\SYSTEM32\avisynth.dll as faulting module path, and VDub generates an illegal instruction error). If I move the 32-bit DLLs to System32 and overwrite the 64-bit ones, then the x86 apps work correctly (but MeGUI x64 obviously does not). It seems all these apps default to System32 to find avisynth.dll. Am I missing something here? Is there any way I can use Avisynth x86 and x64 at the same time and choose which one to be loaded depending on the application?I didn't even know 32-bit applications could access the System32-folder on a 64-bit Windows. I thought Windows just silently mapped them to SysWOW64 instead.

[Groucho2004]

I didn't even know 32-bit applications could access the System32-folder on a 64-bit Windows. I thought Windows just silently mapped them to SysWOW64 instead.Using the standard LoadLibrary() call or going through the VfW API, 32 bit programs will not be able to access System32 on a 64 bit OS. The OS redirection functionionality takes care of that.

AVSMeter (and AVSMeter64) with the "-avsinfo" switch would probably shed some light on THEAST's problem.

[LigH]

If I move the 32-bit DLLs to System32...

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").

[real.finder]

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").

yes, I see same problem when I enter by TeamViewer in my friend pc that use teracopy, remove the teracopy fix it, I was think it was teracopy bug or limit

[THEAST]

Actually my initial observation was incorrect and it seems the problem is with the latest build of Avisynth+. My script is as follows:

LoadPlugin("*RELEVANT_PATH*\ffms2.dll")
FFVideoSource(*INPUT_FILE*, threads=1)
Spline36Resize(640,480)
QTGMC( Preset="Very Fast", InputType=2)
crop(4, 0, -4, 0)

Using build 2574, this script works fine with Avisynth x64, but with Avisynth x86, both VDub and AVSMeter x86 generate an illegal instruction error and MeGUI x86 crashes. If QTGMC is removed from the script, then all of them work.
Using build 2544, the script works with Avisynth x86 without any issues. I think there might be some incompatibility between the latest version of Avisynth+ in x86 mode and QTGMC (or of the filters it depends on).

The following is the output of AVSMeter x86 on my machine:
AVSMeter 2.7.0 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2574, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2017-12-19, 08:05:06 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+


[CPP 2.5 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth+\plugins\ChromaShift.dll [2003-11-04]

[CPP 2.6 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp.dll [2016-06-24]
C:\Program Files (x86)\AviSynth+\plugins\DePan.dll [2.13.1.3]
C:\Program Files (x86)\AviSynth+\plugins\DePanEstimate.dll [2.10.0.2]
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll [2.2.10.0]
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll [2.7.24.0]
C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll [0.9.4.48]
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll [0.96.0.0]

[Scripts / AVSI]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.avsi [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins\BlindDehalo3_MT2.avsi [2006-03-22]
C:\Program Files (x86)\AviSynth+\plugins\EdgeCleaner.avsi [2015-01-02]
C:\Program Files (x86)\AviSynth+\plugins\MtModes.avsi [2017-12-24]
C:\Program Files (x86)\AviSynth+\plugins\QTGMC-3.357.avsi [2017-04-02]
C:\Program Files (x86)\AviSynth+\plugins\SMDegrain_v3.1.2.93s.avsi [2017-12-24]

[Uncategorized / Other]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins\chromashift.html [2003-11-04]
C:\Program Files (x86)\AviSynth+\plugins\QTGMC-3.33.html [2011-05-05]

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").
The standard windows explorer. I don't think it suffers from this issue.

yes, I see same problem when I enter by TeamViewer in my friend pc that use teracopy, remove the teracopy fix it, I was think it was teracopy bug or limit
That is a limitation/bug in Teracopy which has been confirmed and is on the roadmap to be possibly fixed in the next version:

http://bugs.codesector.com/view.php?id=63

P.S. I am using Windows 10 x64 and my processor is Intel i7-5820k.

[LigH]

I wonder if one of your AviSynth import scripts might explicitly load plugins from a specific directory, so either 32-bit or 64-bit plugins. But that should be less probable if you used them from the URLs in the AviSynth Wiki page of QTGMC and its plugin packs, they should rely on plugins being auto-loaded or explicitly loaded in the calling script ... :o

Try to run both AVSMeter and AVSMeter64 with your script as parameter to "benchmark" it in 32-bit and 64-bit mode, that may produce more verbose error messages in case of a crash.

Furthermore ... MeGUI may use an own copy of AviSynth+ instead of the one installed in your system, depending on its configuration. MeGUI log files should reveal that.

[Groucho2004]

Considering the "illegal instruction" error and the fact that it works with r2544 it seems reasonable to assume that the Avisynth core is to blame. Let's see what pinterf has to say about it.

[THEAST]

I updated all the DLLs from the Github links provided in QTGMC Wiki before updating to the new version; other than QTGMC and SMDegrain, the rest of the "avsi" files should not be loaded in my script.

With build Avisynth+ 2574 x86 and AVSMeter x86, I get the following output if QTGMC is included:

AVSMeter 2.7.0 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2574, MT, i386) (0.1.0.0)

Exception 0xC000001D [STATUS_ILLEGAL_INSTRUCTION]
Module: C:\WINDOWS\SysWOW64\avisynth.DLL
Address: 0x69F0F3A8

If QTGMC is removed, or the 64-bit version of Avisynth and AVSMeter is used, then the benchmark runs correctly.

To use build 2544, I just overwrote the build 2574 x86 DLLs in SysWOW64 with the ones from build 2544 and did not at all touch the x64 or the plugin DLLs; that seems to solve the issue.

P.S. If anyone has other Avisynth+ builds between 2544 and 2574, I can try finding the exact build that causes the problem.

[pinterf]

@THEAST: what processor type are you using?

[THEAST]

@THEAST: what processor type are you using?

Intel i7-5820k.

[pinterf]

I can see the crash. Cannot imagine what has happened. Debug build is not crashing. Nothing has been changed related to this report. I have avx2. Maybe VS updated itself.

[THEAST]

It is a bug in the compiler, then?

[pinterf]

Don't know if vmovntdqa reg,reg is valid or not but it seems to be not. The crash occurs in merge_avx2:

00070 8d 40 20 lea eax, DWORD PTR [eax+32]

; 70 : __m256i src1 = _mm256_stream_load_si256(reinterpret_cast<__m256i*>(p1+x));

00073 c5 fe 6f 40 e0 vmovdqu ymm0, YMMWORD PTR [eax-32]
00078 c4 e2 7d 2a c8 vmovntdqa ymm1, ymm0 ****CRASH HERE! ILLEGAL INSTRUCTION VS15.5.1!!!****

; 71 : __m256i src2 = _mm256_stream_load_si256(const_cast<__m256i*>(reinterpret_cast<const __m256i*>(p2+x)));
0007d c5 fe 6f 44 02 e0 vmovdqu ymm0, YMMWORD PTR [edx+eax-32]
00083 c4 e2 7d 2a c0 vmovntdqa ymm0, ymm0


Will update to 15.5.2 and see what happens.

EDIT:
With VS 15.5.2 the code still fails. Replaced stream_load with normal load, it's O.K.

[VS_Fan]

The guy offering binaries for x265 at http://msystem.waw.pl/x265/ switched from VS 2017 to VS 2015.2 claiming the update 15.5 of VS 2017 is giving serious problems: From version 2.6+17 there are no VS 2017 builds – update 15.5 of VS 2017 is so wrong (and it is not possible to install VS 2017 15.4) that I switched to VS 2015.2

[wonkey_monkey]

vmovntdqa reg,reg seems invalid. I think it should be vmovdqa. Then again I'm not sure what that second use, vmovntdqa ymm0, ymm0, is meant to achieve...

[pinterf]

Compiler bug. Second parameter is an aligned memory address (this instruction is a non-cache-polluting load)

[pinterf]

New release.
Avisynth Plus r2580-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2580-MT)

..and let's hope the best (compiler-quality-wise). I didn't have a machine with Visual Studio 2015 right now, I have just moved to a new computer (finally a one with AVX2 capable processor)

Edit: dates are 26th December inside. Today is 27th. Nevermind. I got one more day in holiday to finish reading Rama II :)

- (workaround): Merge: Visual Studio 2017 15.5.1/2 generated invalid AVX2 code (x86 crashed)
- Temporalsoften 10-14 bits: an SSE 4.1 instruction was used for SSE2-only CPU-s (Illegal Instruction on Athlon XP)

[THEAST]

@pinterf, thank you for the quick update despite the holidays. I can confirm that the new build works correctly on my environment both in x86 and x64 mode.

I performed a few speed tests using AVSMeter with both 6 and 12 threads (6-core Intel i7-5820k, Windows 10 x64). I can reliably get 10-12% FPS improvement on the same script (the main filter being QTGMC) when going from Avisynth+ x86 to x64. I also tested the ICC SSE4.2 and AVX2 versions of NNEDI and compared with the VS version; the ICC version is actually around 1% slower.

Happy holidays to everyone.

[Groucho2004]

Edit: dates are 26th December inside. Today is 27th. Nevermind.
[Avisynth info]
VersionString: AviSynth+ 0.1 (r2580, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: D:\WINNT\system32\avisynth.dll
Avisynth.dll time stamp: 2017-12-27, 19:51:55 (UTC)
PluginDir2_5 (HKLM, x86): E:\Apps\VideoTools\AVSPlugins\AutoLoad
PluginDir+ (HKLM, x86): E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins

[pinterf]

Then in the readme of the files-only pack.

[Groucho2004]

Then in the readme of the files-only pack.I see, didn't look at the readme.

[wonkey_monkey]

Quick question: when creating a NewVideoFrame, is pitch guaranteed to always be rowsize rounded up to a 32-byte boundary?

[Myrsloik]

Quick question: when creating a NewVideoFrame, is pitch guaranteed to always be rowsize rounded up to a 32-byte boundary?

Nope. If you end up running in vapoursynth's compatibility it can be 64 byte alignment too. Sometimes. There are also some cpu cache reasons to avoid row sizes that are a certain multiple. So a future implementation may pad the rowsize to avoid that.

Don't assume anything, it'll break future compatibility.

[wonkey_monkey]

But it will be consistent for a particular clip? So if I call NewVideoFrame(vi), get the pitch, and immediately discard the frame, is it safe to assume the pitch will be the same for all future frames created?

I'm trying to be extremely efficient with something.

[Myrsloik]

But it will be consistent for a particular clip? So if I call NewVideoFrame(vi), get the pitch, and immediately discard the frame, is it safe to assume the pitch will be the same for all future frames created?

I'm trying to be extremely efficient with something.

In vapoursynth it's guaranteed that the stride/pitch is the same. For all frames if they have the same type.

I checked the Avisynth source and the stride will always be the same there too. For NewVideoFrame, not for frames returned from GetFrame obviously.

[pinterf]

Since r2544 the frame alignment is 64 bytes, and pitch/stride size is padded to 64 as well, independently of possible AVX512 support.

[bilditup1]

Does the KAISER patch have any implications for avs performance?

[LigH]

It will probably delay every call to a Windows system function which switches from user space to kernel space.

[pinterf]

There was no change, what happens when you call Eval with the clip as the first parameter? (not tried, I hope syntax is OK)
AVSValue eval_args[] = { clip, env->SaveString("Subtitle(\"Hello world!\")") };
AVSValue val = env->Invoke("Eval", AVSValue(eval_args, 2));

[pinterf]

Eval does not take a clip argument: http://avisynth.nl/index.php/Internal_functions#Eval. The issue seems to be variable scoping.
Then it's not documented.
This other form is for OOP notation, that is clip.Eval("....").
Saves current "last", sets "last" to clip, calls Eval then restores previous "last".
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L191
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L416

But I agree, this is scoping problem, similar to the earlier (still not solved) issue with conditional/runtime functions setting "current_frame" and "last" in a multithreading environment.

[Gavino]

Eval does not take a clip argument: http://avisynth.nl/index.php/Internal_functions#Eval. The issue seems to be variable scoping.
This was added in Avisynth 2.6.0 Alpha 5.

Here is the 5th official release of Avisynth 2.6

========================
Changelist

Additions
* Added Eval(clip, string name, string) alias for oop processing of argument.