Avisynth+

[burfadel]

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.

Yes, I did replace avisynth in system32 and the plugin files . I even tried redownloading the 2151 files, but no success.

If I run it from the command prompt (not through Staxrip) I get the following message:



I did also use Chikuzen's updated avs2pipemod, however this isn't the cause. If opening a file in Staxrip regardless of the source filter (L-SMash-Works, FFMS2 etc), with no other filters it still fails.

[Groucho2004]

Originally Posted by burfadel

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.

I suggest you try without any re-direction, feeding the script directly to a client.
Run "AVSMeter -avsinfo". If that doesn't produce any errors, run your script with AVSMeter.

Edit: By the way, "output various data from avs to stdout" is what Windows considers the name of the application (avs2pipemod). This is because Windoze in its infinite wisdom pulls the name from the "FileDescription" entry in the version resources instead of something that would make sense like "ProductName".
In case of avs2pipemod, it's "output various data from avs to stdout".

[jpsdr]

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.

[Groucho2004]

Originally Posted by jpsdr

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.

No problem with DGSource here (x86/x64, XP64).

[burfadel]

This is what happens with Avsmeter with a simple script.



First run is multithreaded mode with 2085. The second is multithreaded mode with 2151, exact same script. Third run is the same script WITHOUT the set MT mode and prefetch set, so running single thread.

It's repeatable and at the same fault addresses. In multithread mode the error is always identical to other multithread runs, and in single thread mode it is always identical to other single thread runs.

The script I am using is a basic one:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
deveed()
prefetch(4)

I chose deveed because it works fine on any other avisynth, just not this one. Some filters in its place did work, including desaltpepper, nirmalam, adaptivemedian, and cnr2. What didn't work is deveed in that line single or multithread (probably others as well), or loading any file with LWLibavVideoSource, DSS2, FFMS2, or Directshowsource.

[Chikuzen]

AVI Import filter error: (Unknown) (80040154).

It's not related DGSource.
VDub64 can't open any avs after this commit.

[Groucho2004]

Originally Posted by burfadel

This is what happens with Avsmeter with a simple script.

Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

[burfadel]

Originally Posted by Groucho2004

Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

It's not only Deveed, that just that happens to be one filter that causes it. There was no point using a filter that was working! However, as any source filter causes it as well it's not as simple as just not using deveed. The only reason why it was working with some filters is the script was just a modified one from the knclmeans performance test, so no source file (thus therefore no source filter) was used.

[ultim]

Originally Posted by Chikuzen

It's not related DGSource.
VDub64 can't open any avs after this commit.

This is now fixed in r2157 (not uploaded), it affected users on x64 if loading an .avs script as an AVI file. The surprise for me is that some COM functions can *only* be exported using a .def file, so I had to add it back for x64, sob.

I'm still looking into burfadel's problem, I will upload a build once I have this fixed too. But now I need to eat.

[ultim]

r2161 fixes the issue reported by jpsdr, and some additional problems that affected only the recently added new color formats (more specifically those with an alpha channel, and Y10/12/14).

The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp by:

val += wpp[offset[i + span2]] * kr[i + span2];

Edit: Since earlier DeVeeds caused a silent corruption, if you are using this filter I recommend you upgrade to this DeVeed build even if it appeared to work earlier.

[burfadel]

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable .

[ultim]

Originally Posted by burfadel

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable .

Did you also install the fixed DeVeed that more than half of my previous post was about?

[burfadel]

Originally Posted by ultim

Did you also install the fixed DeVeed that more than half of my previous post was about?

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

[ultim]

Originally Posted by burfadel

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

No problem, thx for reporting bugs. Let us know if you find anything else

[Chikuzen]

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

[burfadel]

Originally Posted by Chikuzen

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

I tried all MT modes, and yes only mode 3 worked. The access violation on one of the tests seems to be at the same address as I had with my issue with deveed. This isn't exactly repeatable though, the first crash in mode 1 was only repeatable once, most times the crashes in modes 1 and 2 just causes avsmeter64 to fully crash or crash and pause with a whole heap of output like (small excerpt):

pâ³
([ScriptClip], line -1735100535)
ERROR: Þâ³
([ScriptClip], line -1736150327)
---------------------------------------------------------------------
ERROR: ---------------------------------------------------------------------
System exception - Access Violation
------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
ERROR: ERROR:
System exception - Access Violation
ERROR: System exception - Access Violation
 à³
([ScriptClip], line -1728810999)
ERROR: ---------------------------------------------------------------------
---------------------------------------------------------------------
System exception - Access Violation
ERROR: ERROR: Hà³
([ScriptClip], line -1736150327)pà³
([ScriptClip], line -1729857847)
---------------------------------------------------------------------

ERROR: ---------------------------------------------------------------------└à³

I copied this directly from the command prompt. You can do that in modern Windows, just highlight and press ctrl+c.

This is what I get with MT mode set to 1 when it did throw a meaningful error. I know 1 is 'unreliable', I included it for comparison:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\KernelBase.dll
Address: 0x00007FFCC2FF79A8

With mode 2:

---------------------------------------------------------------------
ERROR: System exception - Access Violation
---------------------------------------------------------------------
ERROR: |═
([ScriptClip], line 531728591)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\AviSynth.dll
Address: 0x00007FFC8DB00E75

The issue lies with ScriptClip, the following works:

SetFilterMTMode("DEFAULT_MT_MODE", 1)
SetFilterMTMode("ScriptClip", 3)
SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

I guess it makes sense, there is a message that says:

---------------------------------------------------------------------
WARNING: AviSynth_ScriptClip() has no MT-mode set and will use the default MT-mode. This might be dangerous.
---------------------------------------------------------------------

[vcmohan]

Originally Posted by ultim

r2161
The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp

Thanks for finding the bug. I corrected and uploaded on to my page.

[ultim]

Last update for this week, r2172. The main feature is that it makes MT work for ScriptClip and friends (only ScriptClip tested, please report on ConditionalFilter/Select).
Also interesting could be the new warning diagnostic that fires when you try to set an MT-mode for a script function.

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows. Nevertheless, this is yet another step towards cross-platform support. I am not going to invest a lot more time to this end, but if you want to make Avs+ work on Linux, the compiler won't stand in your way anymore. If anybody wants to tackle what remains, this is a good starting point. Post here if you need tips on specifics.

Oh, and keep the reports coming.

[qyot27]

Originally Posted by ultim

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows.

At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.


And speaking of MinGW, I'll have to whip that CMake install patch into shape against MT.

[ultim]

Originally Posted by qyot27

At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.

It is not functional in that you surely cannot access the library over the C++ interface for one, which is what most applications and plugins do (for that to work those apps and plugins would also need to be compiled using the same MinGW compiler). I haven't tested with the C-interface, but you are right, theoretically that could work. If you are among the bold and the brave, here is a debug version built with MinGW.