AviSynth+ thread Vol.2

[videoh]

devs dont like dirtying their hands talking to users What a load.

[StainlessS]

What a load of bullcrap.

Agreed, really sad, time for Usage forum threads.

EDIT: Usage forum thread originator need not be constantly present, others would probably be more than happy to give advice there,
its just somewhere where users can ask a simple question without feeling that they are intruding into the devs area,
it scares the hell out of me just reading stuff in devs forum.

EDIT: JohnMeyer [somebody some devs may / or may not have heard of] said some time ago that he
did not visit devs forum often / at all, so could be a mistake to think that lesser mortals visit devs forum at every opportunity

[qyot27]

since I am not with or against new fork but if it will be new fork in the end, then maybe better call it AvxSynth+ (since there are old AvxSynth (https://github.com/avxsynth/avxsynth/wiki)) because it work in Linux and so :)
There's no need to fork anything (and let AvxSynth rest in peace; the only reason it even had a different name was because it was not a 1:1 extension of AviSynth onto Linux - it was a separate port based on a not-even-current-at-the-time version of AviSynth, and it lost the ability to build on Windows at all, never mind all the other things that were idiosyncratic to it). If there are important fixes that users want applied to an older release series, they can be either backported from the master branch or written explicitly for the older branch. Look at many other projects out there that have periodic bugfix releases for older branches in parallel with releases from the current stable branch.

We've not had to do so yet, but the means to facilitate it already exists: every time a new release series happens, I create a branch for it. 3.4 has one, 3.5 has one, 3.6 has one. Since 3.4 had only one release, and 3.5 had two, those branches basically just tracked the current state of the master branch at the time. All someone needs to do is request something to be backported, and after a certain amount of time/number of commits have accumulated in the older release branch, a new bugfix release from that branch could be made. But that requires actually notifying us of changes that should be backported, and for the user to know it was fixed in a later version to be able to ask in the first place (meaning: we will ask you if it works in the current release or git version; if you can supply the commit hash itself, even better). I would generally consider the 3.4 branch as end-of-life unless there's some catastrophic reason to issue a bugfix for it, not least because having support for more OSes means more eyes potentially looking at the code and finding issues to fix. And 3.5 is the baseline for the other OSes because it's the first one that supports them. 3.6 would be a similar baseline for non-x86 processors, although the ability to do so would be a candidate for backporting to 3.5 (it was originally developed against 3.5.1, but I don't think I have the old 3.5.1-based branch around anymore).

And, for that matter, anyone that wants to actively contribute can help us by assisting with that backporting effort and then opening a pull request so that it gets applied to the upstream repository. Because of the fact that we do support Linux now, this division of labor between development branch/current stable/old stable is part-and-parcel of the way many Linux distributions or FOSS projects in general operate, and I'd expect that something like this will end up happening anyway as any hypothetical maintainers of AviSynth+ packages in various repositories find things that need bugfixes for what their distro ships¹. There still comes a point where old branches are just left alone, but a new release series does not mean the automatic end of the old one, git allows them to be maintained in parallel, albeit probably with reduced frequency for the older branches unless we suddenly get a flood of new contributors that accelerate the main branch's development and can simultaneously identify all the things that can be backported to older releases.

¹because distros that operate on point release versions themselves will often prefer to stick to a particular release series for one or several iterations of the main distro, before finally making the switch some time later. For instance, if AviSynth+ had miraculously gotten an upstream package in the repositories for Ubuntu 20.04 LTS, it would have frozen 3.5.x and only possibly package subsequent bugfix releases from the 3.5 branch. 20.10, 21.04, or 21.10 might also stick to shipping 3.5.x, only moving to 3.6.x during the cycle for 22.04 LTS (and by that time, who knows if we'll still be actively on the 3.6 branch or have moved up to some other milestone). The cycles are long and that means probably having to field support questions on a particular release.

[FranceBB]

Oh boy, it broke everything here on XP x86 (SSE4.2 capable CPU).

https://i.imgur.com/CPgl5jF.png
https://i.imgur.com/snyaueD.png


ColorBars(848, 480)


Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.


SetMaxCPU("C")
ColorBars(848, 480)


Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.
3 errors one after the other on avs2yuv.exe

https://i.imgur.com/x5AwSgF.png
https://i.imgur.com/i9UouR2.png
https://i.imgur.com/j0883zN.png

ffmpeg instead complains about my SetMaxCPU("C"):

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

so I removed it and tried again with just ColorBars(848, 480):

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

I thought it was going to work as it correctly received both the audio and video stream, however it quickly stopped encoding and it generated a completely empty (0 byte) output file:

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


avs4x264mod.exe:

https://i.imgur.com/7HYPog7.png

AVSEditPlus 1.25 crashes without any error.
Avisynth_ProxyGUI:

https://i.imgur.com/H7WcDAr.png
https://i.imgur.com/YCJxr3w.png
https://i.imgur.com/g0k63id.png

Potplayer version 1.7.21212 (latest):

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

but then, when I was going to abandon every hope, I found out that MPC-BE was working just fine! It's really weird!

https://i.imgur.com/GTYX2O8.png
https://i.imgur.com/IEQjz1o.png

"It cannot be!" I though, so I tried with a different script which involves at least an external filter such as ffms2:


FFVideoSource("Analog_bad_source.avi")


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

And there it was, working as expected.

So I tried a few filters like:


FFVideoSource("Analog_bad_source.avi")

neo_dfttest(sigma=64, tbsize=1, Y=3, U=3, V=3, dither=0, opt=0)


and suddenly it became black. No error, it did allocate RAM, but the window was completely black:

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

So I thought: "I got it! It must be some incompatible plugin!"
So I removed every plugin from plugins and plugins+ and I ran AVSMeter again, but... nothing. Still access violation.
I even checked Avisynth.dll with Dependency Walker just to make sure, but everything was fine and of course I have all the C++ Redistributable and .NET Framework installed, so... what's going on?

Setup Log: https://pastebin.com/M5LizfCW

[poisondeathray]

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64


colorbars(pixel_type="YV12")
qtgmc()


error message

Script error: expected `)'
((null), line1, column 4)
(SMDegrain 3.1.2.104s.avi, line 879)
(QTGMC_3.364.avsi, line 186)


smdegrain line 879

IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0


qtgmc line186

sisphbd = AvsPlusVersionNumber > 2294



Reverting back to 2.5.1 works ok

[StainlessS]

I am reluctant to class avs+neo, same as, the Nekopanda Avs Neo, cant really compare them, dont know what to do with either
but they are not similar.
EDIT: The script writer has to make some sense of it, but there aint any.

EDIT: Above rant related to "IsAvsNeo".

[stax76]

I had to do some updates and minor tweaks but after that everything works.

[real.finder]

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64


colorbars(pixel_type="YV12")
qtgmc()


error message


smdegrain line 879

IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0


qtgmc line186

sisphbd = AvsPlusVersionNumber > 2294



Reverting back to 2.5.1 works ok

update qtgmc and smdegrain

[poisondeathray]

update qtgmc and smdegrain

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

[real.finder]

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

Check the Thread in my signature

[poisondeathray]

Check the Thread in my signature
Thanks, it's ok now

It needed Zs_RF_Shared.avs as well

[feisty2]

Interesting ideas, they are a bit abstract for our present thinking.
I wish that was the only task to simplify. Instead there are many other opportunities to make the code a bit cleaner. E.g. removing all checks for 16 byte frame aligment in Avisynth (no unaligned frames allowed), and there are still other ancient techniques there which are sometimes workarounds for a VS2005 behaviour.

cool, and if ur ever gonna design a new API for new plugins, feel free to take a look at vsfilterscript and see how coding c++ plugins could be easy as scripting with a modern API. it might attract more developers since writing filters is a cinch. a few rules to make things simple,

1) there must be no base class/interface and inheritance, and thus no virtual functions, polymorphism should be implemented by duck typing (or more precisely, structural typing)

2) there should be no type declaration unless it's a type cast, everything should be of type "auto". this is essential to structural typing since we differentiate types by their behaviors rather than their names, use a concept if the type must be constrained.


template<typename T>
concept string_alike = requires(T x) { std::string{ x }; };

auto f(string_alike auto&& str) {
...
}

auto x = "aaa";
f(x); // OK, str instantiates to const char*
f("aaa"); // OK, str instantiates to const char[4]
f("aaa"s); // OK, str instantiates to std::string
f("aaa"sv); // OK, str instantiates to std::string_view
f(123); // Error


this is vastly different from manually defining a bunch of interfaces (base classes) and subtypes, note that there is no common base type for const char*, const char[4], std::string and std::string_view, yet they all satisfy the "string_alike" concept since they share the same behavior (convertible to std::string), there is also no type erasure so the type precision is fully preserved.

3) constexpr if and requires expressions are your friend, these are extremely powerful tools and let you go even beyond structural typing, you can detect if a certain behavior is legal to a certain type and specialize your code based on that information.


auto print(auto&& stuff) {
// see if stuff is a container by detecting if it has the "begin()" member
if constexpr (requires { stuff.begin(); })
for (auto x : stuff)
std::cout << x << " ";
else
std::cout << stuff;
}

print(std::array{ 1, 2, 3 }); // prints "1 2 3"
print(std::vector{ "hello", "world" }); // prints "hello world"
print(3.14); // prints "3.14"


functions may return different types like in dynamically typed languages as long as the type can be determined at compile time with a little help from constexpr if


// consteval parameter is planned as a C++23 core language feature
auto f(consteval auto x) {
if constexpr (x == "a"sv)
return 123;
else
return 3.14;
}

auto x = f("a"); // x == 123, x is of type int
auto y = f("b"); // y == 3.14, y is of type double


nominal typing (type declaration) is evil and is the root cause of highly coupled, inflexible, unmaintainable code and all the ugliness out there

[qyot27]

ffmpeg instead complains about my SetMaxCPU("C"):

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

The message is from SetMaxCPU, not FFmpeg. It passes through the clip messages from AviSynth to stdout.

I had just copied the Changelog entries as-is out of readme.txt, which still contained the old invocation syntax. readme_history.txt shows it correctly: "" or "none". I've edited the post and release summary to reflect that.

so I removed it and tried again with just ColorBars(848, 480):

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

I thought it was going to work as it correctly received both the audio and video stream, however it quickly stopped encoding and it generated a completely empty (0 byte) output file:

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

I couldn't grab that exact build of ffmpeg, probably because Zeranoe's forum is dead, but with the one from ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z, that command works and produces a valid output on Win10.

I also started up my old WinXP/Coppermine-128 machine and tested it on there (with 3.6.0 and ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z). ffmpeg.exe with the exact same command is cool with it, and ffplay.exe can play back the result of the encode.

[pinterf]

Download MeGUI AviSynth Wrapper test (https://drive.google.com/open?id=1FAkgwYQ0IipKiiYGgiOGST4sx8xU4RU7).

I think it works not only for AviSynth+ but for avs2.6 or newer in general.

Copy over the existing one.

Probably the old one bundled with MEGUI was compiled with an AviSynth CPP 2.5 header.

The bundled DLL set is a "bit" old as well.
The x64 CPP 2.5 plugins are especially outdated.

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\ColorMatrix.dll [2.5.0.0, 2010-03-18]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb.dll [n/a, 2013-12-01]
C:\Download\MeGUI-64\tools\avisynth_plugin\FluxSmooth.dll [n/a, 2010-11-30]
C:\Download\MeGUI-64\tools\avisynth_plugin\leakkerneldeint.dll [1.5.4.0, 2010-03-14]
C:\Download\MeGUI-64\tools\avisynth_plugin\NicAudio.dll [n/a, 2012-01-02]
C:\Download\MeGUI-64\tools\avisynth_plugin\TDeint.dll [1.1.0.0, 2010-03-14]
C:\Download\MeGUI-64\tools\avisynth_plugin\undot.dll [0.0.1.1, 2006-09-19]

[C++ 2.6 Plugins (64 Bit)] [Version, Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\EEDI2.dll [0.9.2.0, 2017-11-17]
C:\Download\MeGUI-64\tools\avisynth_plugin\TimeStretch.dll [n/a, 2016-10-20]
C:\Download\MeGUI-64\tools\avisynth_plugin\TIVTC.dll [1.0.11.0, 2018-03-23]
C:\Download\MeGUI-64\tools\avisynth_plugin\VSFilter.dll [3.1.0.801, 2018-09-04]
C:\Download\MeGUI-64\tools\avisynth_plugin\yadifmod2.dll [0.0.2.0, 2017-02-21]

[Uncategorized files] [Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\_versions.txt [2018-09-08]
C:\Download\MeGUI-64\tools\avisynth_plugin\ColorMatrix.htm [2009-01-25]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_Copying [1995-10-18]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_FAQ.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_ReferenceManual.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\DecombTutorial.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\EEDI2_README.txt [2006-06-07]
C:\Download\MeGUI-64\tools\avisynth_plugin\LeakKernelDeintHelp.html [2005-01-19]

[Zetti]

Many Thanks pinterf

The wrapper test works fine for my needs.

[tormento]

Download MeGUI AviSynth Wrapper test[/URL].
Don't know if a coincidence but after replacing file, MeGUI_x64 asked me to update AVS+ to 3.5 r3106 with release date 01/05/2020. :D

[pinterf]

Don't know if a coincidence but after replacing file, MeGUI_x64 asked me to update AVS+ to 3.5 r3106 with release date 01/05/2020. :D
Dunno, it wasn't me :) Did they update the plugin set as well?

[FranceBB]

The message is from SetMaxCPU, not FFmpeg. It passes through the clip messages from AviSynth to stdout.

I had just copied the Changelog entries as-is out of readme.txt, which still contained the old invocation syntax. readme_history.txt shows it correctly: "" or "none". I've edited the post and release summary to reflect that.


I couldn't grab that exact build of ffmpeg, probably because Zeranoe's forum is dead, but with the one from ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z, that command works and produces a valid output on Win10.

I also started up my old WinXP/Coppermine-128 machine and tested it on there (with 3.6.0 and ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z). ffmpeg.exe with the exact same command is cool with it, and ffplay.exe can play back the result of the encode.

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D

[kalehrl]

Too bad Zathor stopped developing MeGUI.

[tormento]

Dunno, it wasn't me :) Did they update the plugin set as well?


Nope. It sorta triggered something...

[pinterf]

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D
Have you tried both the xp installer and the fileonly versions (just to exclude a wrongly packaged dll version)?

[Zathor]

Download MeGUI AviSynth Wrapper test (https://drive.google.com/open?id=1FAkgwYQ0IipKiiYGgiOGST4sx8xU4RU7).

I think it works not only for AviSynth+ but for avs2.6 or newer in general.

Copy over the existing one.

Probably the old one bundled with MEGUI was compiled with an AviSynth CPP 2.5 header.

Thank you very much. Sadly it does not work for me with AVS+ r3106 installed. The internal check in AviSynthWrapper.cpp:468 returns NULL and therefore MeGUI assumes that the DLL and/or the installed AviSynth version are outdated. Do you mind to share the source code?

And yes, the wrapper is/was still using the interface 3 as the interface 6 from AVS+ does have the issue that in MeGUI the FFMS filter cannot show the input preview - it is black (lsmash does work). You need to refresh the preview again to show it properly (and yes, using 8bit input files). I was too lazy to rewrite the preview to trigger a new input bitmap when the first one is completly black.
Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.
In any case I am not very much familiar with C++ so I did not had the chance to improve the wrapper much. Likely there are way better methods to serve the data to MeGUI.

[qyot27]

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
I don't know. My experience using a debugger is restricted to gdb, which won't work with the MSVC builds.

By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D
I know; that's where I downloaded it from.

[tormento]

Thank you very much. Sadly it does not work for me with AVS+ r3106 installed. The internal check in AviSynthWrapper.cpp:468 returns NULL and therefore MeGUI assumes that the DLL and/or the installed AviSynth version are outdated.
I had the same problem and found that not all the 7Z file was unpacked and the AviSynth was missing in the internal folders. Just unpack the file in the update manually.

[pinterf]

Thank you very much. Sadly it does not work for me with AVS+ r3106 installed. The internal check in AviSynthWrapper.cpp:468 returns NULL and therefore MeGUI assumes that the DLL and/or the installed AviSynth version are outdated. Do you mind to share the source code?

And yes, the wrapper is/was still using the interface 3 as the interface 6 from AVS+ does have the issue that in MeGUI the FFMS filter cannot show the input preview - it is black (lsmash does work). You need to refresh the preview again to show it properly (and yes, using 8bit input files). I was too lazy to rewrite the preview to trigger a new input bitmap when the first one is completly black.
Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.
In any case I am not very much familiar with C++ so I did not had the chance to improve the wrapper much. Likely there are way better methods to serve the data to MeGUI.

Hi, now that thing is interesting, I wonder why 3106 does not work.

btw is there any chance that the project move from sourceforge to github?

The source is here. Header files copy, a new ifdef and build.
Source:
https://drive.google.com/open?id=1zWDRGB_4wpYRwiMVTunLf8I4SHctdsrc

Are you using the C interface as well?

[pinterf]

Ahh got it!
You can use the header file but please use
pstr->env = CreateScriptEnvironment(AVISYNTH_CLASSIC_INTERFACE_VERSION)
instead of
pstr->env = CreateScriptEnvironment(AVISYNTH_INTERFACE_VERSION);

This AVISYNTH_INTERFACE_VERSION comes from the actual avisynth.h but since this avisynth.h is "universal" and defines the actual IF version, you should use a former one.
I put the enum AVISYNTH_CLASSIC_INTERFACE_VERSION in the header for this very reason.

With this technique both former Avs 2.6 and Avs+ and current 3.6 will work and you'll get the environment properly.

EDIT: there are another places, altogether 4.
EDIT2:
I saw you are using v141_xp toolset, this only may not be enough for XP, this is usually needed:
/Zc:threadSafeInit-
to be put into the additional compiler flags


EDIT3:
Avisynth wrapper binaries (using only V6 restriction + WinXP additional safety flag)
https://drive.google.com/open?id=1JfiokTy2IOqOn1VTXN0eXQEDCC3vUdN4
Source
https://drive.google.com/open?id=18tjLGgdhgrHjjKRsgr-7hv5qMqDojYXp

[tormento]

@pinterf
@Zathor

After some testing I confirm that older AVS+ doesn't work.

To stop the update request, do it once and copy AviSynth.dll from the update_cache\avisynthplus-3.5.1-64.7z to MeGUI\tools\avs and set it read only or MeGUI will delete it at every run (strange...).

Problem is when you add AVS script, it will tell you AviSynth 2.6 required as error.

With latest external AviSynth, no problems at all (you have anyway to put the read only AVS the same).

[pinterf]

@pinterf
@Zathor

After some testing I confirm that older AVS+ doesn't work.

To stop the update request, do it once and copy AviSynth.dll from the update_cache\avisynthplus-3.5.1-64.7z to MeGUI\tools\avs and put it read only or MeGUI will delete it at every run (strange...).

Problem is when you add AVS script, it will tell you AviSynth 2.6 required as error.

With latest external AviSynth, no problems at all.
Have you tried the binaries in my previous post?

[stax76]

Maybe somebody can help with some errors I get with the new headers.

Severity Code Description Project File Line Suppression State
Error C1083 Cannot open include file: 'avs/cpuid.h': No such file or directory FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1337
Error C2365 'paAppend': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1163
Error C2365 'paReplace': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1162
Error C2365 'paTouch': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1164
Error C2365 'peIndex': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1158
Error C2365 'peType': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1157
Error C2365 'peUnset': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1156
Error C2365 'ptData': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1149
Error C2365 'ptFloat': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1148
Error C2365 'ptFrame': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1151
Error C2365 'ptInt': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1147
Error C2365 'ptUnset': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1146
Error C1083 Cannot open include file: 'avs/cpuid.h': No such file or directory FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1337

https://github.com/staxrip/staxrip

[pinterf]

Replace "avs/cpuid.h" instead of <avs/cpuid.h>

[pinterf]

The others may conflict with vapoursynth definitions?

[stax76]

Thank you, unfortunately Error C2365 remains.

[tormento]

Have you tried the binaries in my previous post?
Nope, I am using the v8 interface wrapper.

[pinterf]

Nope, I am using the v8 interface wrapper.

This latter is good for both v6 and v8, I hope.

[stax76]

The others may conflict with vapoursynth definitions?

I think so, will try to workaround it tomorrow.

[Morku]

Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.


Uh, this must be the reason, why the AVS Script Creator window turns black now.

https://i.imgur.com/E14i11E.gif

I have updated to AviSynth 3.6 and replaced the Wrapper from pinterf.
When I load a avs in the AVS Script Creator (I have tried ffmpegsource and dgsource, so it is unrelated) the preview turns black after 1 second. Also the Input DAR changes? You see in gif.

But when I load in Input and click Reopen Video Preview, the preview stays open fine.
No errors in the log when I reproduce the issue.

And thank you for all the time and support of MeGUI :)

[tormento]

This latter is good for both v6 and v8, I hope.

It works both enabling and disablint "Always use the included AviSynth", however I always get the following log:
--[Information] [22/05/2020 19:50:31] No package requires an update
-[Information] AviSynth Wrapper
-[Information] File Version: 3.5
-[Information] File Date: 02-04-2020
-[Information] File Name: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] File Path: d:\eseguibili\media\megui\avisynth.dll
-[Information] AviSynth Version: AviSynth+ 3.5 (r3106, 3.5, x86_64)

It seems like MeGUI is ignoring that setting or there is something wrong in the logging.

[stax76]

I'm not using these enums so just out comment them.

Maybe there is still time to rename these things?

[pinterf]

Yep or I'll define them as class enums. I do not think that many of you around the world is using them presently :)

[FranceBB]

I don't know. My experience using a debugger is restricted to gdb, which won't work with the MSVC builds.

I see...

Have you tried both the xp installer and the fileonly versions (just to exclude a wrongly packaged dll version)?

I installed the vcredist one and it didn't work on XP, so then I installed the xp installer (without vcredist) and I still got an access violation.

I even tried with

SetMaxCPU("none")
ColorBars(848, 480)

Still access violation everywhere (AVSPmod, AVSMeter, VirtualDub, avs4x264mod, avs2yuv, empty file in ffmpeg - although it recognizes the A/V stream) but on MPC-BE.
On MPC-BE it works with its internal functions and ffms2 but as soon as I try to use some filters it doesn't...

I then installed the normal non-xp version and I've still got the same ACCESS VIOLATION error.
I re-installed again the XP version, I uninstalled 0patch (it provides security patches past Microsoft EoS in July 2019) and I also uninstalled the Antivirus (Avast Premier) and ran it again: same ACCESS VIOLATION.

I then downloaded the files only version, I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 from the x86-xp folder, I tried to run AVS and I've got an ACCESS VIOLATION.

Then I finally tried the x86 non XP one files only version and I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 once again.
Guess what? ACCESS VIOLATION.

On Windows 10 the normal installer x86 works like a charm on the same computer with the very same hardware.

At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...

Of course, reverting to Avisynth+ 3.5.1 works and everything works again.
As I said, I have no idea about how to debug it other than saying that it doesn't have any missing dependencies when
I look at it with Dependency Walker and it's supposed to work fine, but it doesn't. I generally rely on AVSMeter but it just shows ACCESS VIOLATION just like any other program this time, so I don't know.
Any idea?
I don't know if you have an XP VM to test, but if you want something to test, I would happily let you login in mine via Anydesk or Team Viewer or RDP or whatever you want if you wanna take a look at how it behaves on XP.

[qyot27]

Test this one (32-bit only):
http://www.mediafire.com/file/we5m234xrxbxjd6/AviSynth%252B_3.6.0_i686-xp-nosimd.7z/file

[pinterf]

This is weird, - I'm using cmakegui, checked the XP support checkbox, generated the solution file and it listed that v141_xp toolset is forced, OK.
Went into VS2019 GUI, opened project properties and there was no sign of XP toolset settings, only the /Zc:threadSafeInit- option. It still listed the non-XP v142 toolset.
EDIT: When I pressed the "Generate" once again then it created the proper xp targeted solution

[manolito]

This is a follow-up to this post:
https://forum.doom9.org/showthread.php?p=1912913#post1912913

At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...
and I do agree with FranceBB on his conclusion.

My issues occur under Win7-64 on a Core i5 CPU with 8GB of RAM.

I made some more tests with StaxRip v. 1.1.9.0 (the last stable 32-bit version from 2013). I have no idea how StaxRip interfaces with AviSynth. All I can say is that for all the very long time I am using StaxRip, it never gave me any issues with AVS versions starting from early 2.5x versions through 2.6x up to AVS+ 3.5.1.

The weird behavior with LAV filters was only revealed because I had enabled the tray icons for LAV. So it is very easy to see that multiple instances are still running.

For ffvideosource and LWLibavVideoSource it is hard to tell if they have the same problem. They do not have tray icons, and in Task Manager I did not find a way to tell if there are several processes for the same DLL active.

So all I can be sure of is that LAV filters are not released from memory after the script which invokes them has finished and is terminated by StaxRip. The only way to release these filter instances from memory is to terminate StaxRip.

This behavior has nothing to do with the AVS+ MT feature. It does not matter if the Prefetch call is present or commented out, the behavior is identical.

The next thing I tried was to use DirectShowSource instead of DSS2Mod. Not good at all. The LAV filters behavior was the same, but in addition StaxRip would crash after 30 to 50 seconds after opening the source. This is reproduceable each and every time regardless of the source file format.

Since I almost never use DirectShowSource for video I became curious. I went back to AVS+ 3.5.1 (identical scripts and settings) and loaded a source using DirectShowSource. LAV filters behaved normally, and there were no crashes. But I only got one third of the conversion speed compared to other source filters (including DSS2Mod). Again regardless if Prefetch was used or not. Very weird.

To be absolutely sure I removed AVS+ and went back to classic AVS 2.6.1 Alpha. And here DirectShowSource was only a tad slower than the other source filters (about 0.5 fps).

Does not make any sense to me... :confused:

In any case I feel that AVS+ 3.6 is not ready for prime time yet. Please implement a more thorough quality control before publishing "stable" builds which turn out to be not that stable at all.


Cheers
manolito

[stax76]

@manolito

The StaxRip version you use is very old, it's using VFW, new versions use AviSynth and VapourSynth directly in portable mode, everything is included and works without installing or configuring anything, if AviSynth is installed then the installed version is used and the portable version cannot be used due to how AviSynth and tools are designed, StaxRip includes about ten tools that read avs and vpy. For VapourSynth both modes can be used, at least for what I could test (cannot test hw encoders). The beta from today uses AviSynth 3.6, works fine.

[Boulder]

Here's an example of a script which starts pounding on the GPU at 100%. I've tried changing the prefetch value, but I've not found a good value which would put the CPU (12c/24t) to work at 90-100%. In Vapoursynth, a very similar script uses 95-100% of the CPU and is much faster. GPU usage stays below 10% almost all the time.

DGSource("potter_stone.dgi", ct=280, cb=280, cl=0, cr=0) # UHD source

c2 = convertbits(bits=16)
c2blur = c2.blur(0.2)
prefilt = convertbits(bits=10)

w = prefilt.width()
h = prefilt.height()
prefilt = prefilt.removegrain(12, 12).gaussresize(w, h, 0, 0, w+0.0001, h+0.0001, p=2).mergeluma(prefilt, 0.1)

sharp_luma = c2.sharpen(0.6)
sharp_chroma = c2.sharpen(0.2)
sharp = sharp_luma.mergechroma(sharp_chroma)

superanalyse = prefilt.msuper(pel=2, hpad=16, vpad=16, sharp=2, rfilter=4)
supermdg = sharp.msuper(pel=2, hpad=16, vpad=16, levels=1, sharp=2, rfilter=4)

fv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
bv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)

fv1scaled = fv1.mscalevect(bits=16)
bv1scaled = bv1.mscalevect(bits=16)

c2blur.mdegrain1(supermdg, bv1scaled, fv1scaled, thsad=200, thsadc=200, plane=4, limit=255, limitc=255, thscd1=200, thscd2=70)

Prefetch(24)
I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.

[manolito]

@manolito

The StaxRip version you use is very old, it's using VFW, new versions use AviSynth and VapourSynth directly in portable mode, everything is included and works without installing or configuring anything, if AviSynth is installed then the installed version is used and the portable version cannot be used due to how AviSynth and tools are designed, StaxRip includes about ten tools that read avs and vpy. For VapourSynth both modes can be used, at least for what I could test (cannot test hw encoders). The beta from today uses AviSynth 3.6, works fine.

I see your point, but this will not work for me... :devil:

This old version 1.1.9.0 is very stable, it was at a time when you took a long break from StaxRip development. When you resumed the development, one of the first things you did was dropping XP support, and shortly after this you abandoned 32-bit completely.

I use StaxRip on at least 3 computers, and one of them is the ancient WinXP machine with a Coppermine CPU (no SSE2 support) and very low system RAM. I really do not want to maintain different StaxRip versions and different AVS plugins on these machines, they all use the "least common denominator" principle. Which means 32-bit and XP compatible.

There are also a couple of 32-bit only AVS plugins I want to keep on using, so I have no intention to ditch this old StaxRip version. Looking at your current StaxRip versions I can see that there are tons of new features which I do not care for (Hi Bit Depth, Hi Color, X265 support, VS support), but some things I do care for are missing (like XviD VFW support). And with all these new features also tons of new bugs were introduced.

So being a "Retro" person I will stick with this old StaxRip version, and if newer versions of AVS+ no longer support it then I will stop using these AVS+ versions. Newer is not always better...

[pinterf]

I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.

A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.

I suppose, you get those numbers with older avisynth versions as well?
Last year (or before that) I investigated a similar source which behaved sub-optimally, to say at least. I could reach e.g. 60% CPU max. Could not solve it.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

Does your source filter have a debug or more verbose logging mode?

[Boulder]

I suppose, you get those numbers with older avisynth versions as well?At least with v3.5.1 as I started my experiments with that version.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

So the frames + threads parameter is not like "process m frames with n threads simultaneously"? Has the multithreading functionality changed a lot since SEt's Avisynth MT? Of course, it could be that it's much harder to utilize all the 24 threads the CPU has.


Does your source filter have a debug or more verbose logging mode?
As far as I know DGSource doesn't have one, but I also tested LWLibavVideoSource with SW decoding and it doesn't resolve the issue.

Would you like me to test something specific? I also tried a BD source but it has the same problem, I cannot get CPU utilization past 40-45% or so.

[pinterf]

I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.

All you can do is experimenting and share your findings

1.) You can have now multiple Prefetchers (new in 3.6)
2.) At the moment, forget "frames" parameter
3.) Try another cache mode (new in 3.6) default is 0.
- SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment

[pinterf]

BTW your script is using isb=false for both forward and backward vectors, which seems to be wrong.