Avisynth+ - Page 56

stax76 · 3rd May 2015, 10:49

@jones1913

It was also reported in the StaxRip thread that AviSynth+ x64 with QTGMC isn't stable using MT, a workaround is using a single thread and run 2 encoding instances to saturate the CPU. We have to wait until ultim or another developer investigates it.

Reel.Deel · 3rd May 2015, 15:09

Quote:

Originally Posted by qyot27

http://avisynth.nl/index.php/AviSynth%2B#MT_Notes

Also of note that using "" in SetFilterMTMode to mean the default was changed; the wiki just hasn't been updated.

Thanks for pointing that out, it's fixed now.

-------

In the hopes of having a stable 64-bit AviSynth+ I started a list of all known 64-bit plugins. I still have a bunch of filters to add, some of you may be surprised of how many 64-bit plugins there actually are. Anyways please test and report back!
http://avisynth.nl/index.php/AviSynt...2B_x64_plugins

Plugins that do not have a 64-bit version:

DctFilter (without it there is no Deblock_QED)
Debilinear, Debicubic (Debilinear can work quite well on content from Canon DSLR cameras)
Deshaker3D and other plugins by David Horman
DePan, DePanEstimate and other plugins by Fizick
frfun7 (closed source so I doubt we'll ever see it)
JpegSource
nnedi3ocl
RedAverage (I still see it used from time to time)
RemoveDirt
ReduceFlicker
ResampleHQ (maybe, there's Dither nowadays)
SimpleResize
SVPflow
Toon v1.1
Unfilter
VariableBlur (latest version missing, only v0.5 is available)
I'm sure there's more but that all of the usable ones I can think of at the moment.

Most plugins by V.C. Mohan and StainlessS can probably be compiled for x64 with no problems. That also goes for just about any other plugin that is not written in ASM.

l33tmeatwad · 3rd May 2015, 17:04

ResampleHQ has a 64bit version for v6 and under.

Sent from my SM-N910V using Tapatalk

Reel.Deel · 3rd May 2015, 23:58

Quote:

Originally Posted by rean

Some note about that internal assembler optimization is disabled would be fine. Because most x64 plugins can be really 2-5 times slower. They just have #ifdef to disable inline assembly code.

That's not the case with the plugins that say "Compiled with Intel Parallel Studio XE 2015 Composer Edition for C++". In fact MVTools2 from that list is indeed ~20% percent faster and uses less memory than it's 32bit counterpart. That might be the case for some plugins compiled by yo4kazu and possibly squid_80 also. Fortunately most of those plugins in question are outdated and have been recompiled the same way as MVTools2, some of those plugins in that list are a modern rewrite of the originals. The rest don't even have any ASM anyways so there's nothing to worry about. I haven't tried all of those plugins in that list but I have yet to come across one that it's slower than the 32bit...

qyot27 · 4th May 2015, 03:29

That's not AviSynth+'s problem, it's 2.6's. And if you want the exception clause, use the C interface (which you should be doing anyway if you want portability).

l33tmeatwad · 4th May 2015, 17:07

Quote:

Originally Posted by Reel.Deel

Thanks for pointing that out, it's fixed now.

-------

In the hopes of having a stable 64-bit AviSynth+ I started a list of all known 64-bit plugins. I still have a bunch of filters to add, some of you may be surprised of how many 64-bit plugins there actually are. Anyways please test and report back!
http://avisynth.nl/index.php/AviSynt...2B_x64_plugins

Plugins that do not have a 64-bit version:

DctFilter (without it there is no Deblock_QED)
Debilinear, Debicubic (Debilinear can work quite well on content from Canon DSLR cameras)
Deshaker3D and other plugins by David Horman
DePan, DePanEstimate and other plugins by Fizick
frfun7 (closed source so I doubt we'll ever see it)
JpegSource
nnedi3ocl
RedAverage (I still see it used from time to time)
RemoveDirt
ReduceFlicker
ResampleHQ (maybe, there's Dither nowadays)
SimpleResize
SVPflow
Toon v1.1
Unfilter
VariableBlur (latest version missing, only v0.5 is available)
I'm sure there's more but that all of the usable ones I can think of at the moment.

Most plugins by V.C. Mohan and StainlessS can probably be compiled for x64 with no problems. That also goes for just about any other plugin that is not written in ASM.

If we are naming ones we'd like to see a 64-bit version of where the source code is available, here's another:
TComb

Reel.Deel · 4th May 2015, 18:09

FTurn is already included in the AviSynth+ core so there's no need for it.

l33tmeatwad · 4th May 2015, 19:11

Quote:

Originally Posted by Reel.Deel

FTurn is already included in the AviSynth+ core so there's no need for it.

I suppose I didn't read the fine print, lol...

snarfies · 9th May 2015, 15:12

SharpAAMCmod (part of AnimeIVTC) is producing garbage output using Avisynth+. It works normally using baseline Avisynth 2.6.

stax76 · 10th May 2015, 19:53

Is somebody maintaining mvtools2 x64? I would like to report the following bug:

exception raised at 0x00007FFE75BA18D6 (mvtools2.dll) in StaxRip.exe: 0xC0000005: access violation reading at 0x000000004F3004E8.

I can provide a detailed description on how to reproduce the bug.

Reel.Deel · 10th May 2015, 20:36

Quote:

Originally Posted by stax76

Is somebody maintaining mvtools2 x64?

Which version are you talking about? The old one by Joshy D or the latest one v2.6.0.5? Regardless is bad news anyways, Joshy D is no longer around and for the other one I'm not sure who the author is. I stumbled across these builds over at 2ch. Ultim told me the authors name might be 'Shion' but he couldn't confirm it. Maybe someone here knows a bit more. Fortunately the source code is available.

stax76 · 10th May 2015, 20:47

I have the latest one v2.6.0.5, maybe a AviSynth/plugin developer can take a look, it would be great being able to use SMDegrain, I would give it a try but somehow doubt I could do much.

Reel.Deel · 10th May 2015, 20:53

If I recall correctly you said this problem only occurs on Windows 8/10, correct? Also, might be worth posting instructions on how to reproduce it just in case the author reads this forum.

stax76 · 10th May 2015, 21:13

There are Win8/Win10 only bugs and there are bugs that only happen in certain applications like StaxRip or MPC-BE.

stax76 · 12th May 2015, 14:45

Who could I contact regarding mvtools2 x64? The help lists the following authors:

Manao, Fizick(Alexander Balakhnin), Tsp, TSchniede, SEt

Who is still active?

l33tmeatwad · 12th May 2015, 16:36

Quote:

Originally Posted by stax76

There are Win8/Win10 only bugs and there are bugs that only happen in certain applications like StaxRip or MPC-BE.

I've seen you complaining a lot to plugin developers about having issues with StaxRip and MPC-BE and blaming the plugins for the fault. I wanted to ask, are you using AviSynth+ (x86 and x64) for all your tests? Keep in mind that the latests builds have been buggier than the official AviSynth builds currently and those problems probably carry over into the x64 builds as well. The cause of these problems may not be entirely the plugins themselves, could you provide more details as to your setup, including what version of AviSynth or AviSynth+ you are using as well as other applications you have tested? Do you have any crash log information?

stax76 · 12th May 2015, 17:32

Requirements to reproduce the access violation are:

Win8 x64 or Win10 x64
AviSynth+ x64
mvtools2 x64
StaxRip x64 or MPC-BE x64

Many x64 problems didn't surface on Win7 and VirtualDub and that's what made it difficult for everybody.

l33tmeatwad · 12th May 2015, 18:04

Could you try with regular AviSynth 2.6 RC3 and then AviSynth+ x86 with the 32-bit build of MPC-BE and any plugin you were having trouble with to see if the same issue exists?

stax76 · 12th May 2015, 19:37

It makes much sense trying different things in order to narrow a problem if you have no real idea what's happening.

In this case tons of things are already known:

many problems appear only on Win8/Win10
many problems appear only in certain applications like StaxRip x64 and MPC-BE x64

it's also known how to reproduce the problem:

Win8 x64 or Win10 x64
AviSynth+ x64
mvtools2 x64
SMDegrain
StaxRip x64 or MPC-BE x64

it's also known that mvtools2 is the currently only plugin known to not work in this environment, about 20 other plugins where successfully tested.

it's also known what kind or error happens where:

exception raised at 0x00007FFE75BA18D6 (mvtools2.dll) in StaxRip.exe: 0xC0000005: access violation reading at 0x000000004F3004E8.

This means the code causing the access violation is mvtools2 and that Visual Studio can show exactly the location in the code. Visual Studio has a option to define at which type of exception is should break in the debugger, that's what I've enabled and that's what has to be enabled when debugging mvtools2. I couldn't setup the built environment because of the Intel compiler and yasm and I don't know ASM so I hope a ASM programmer can investigate it. I don't want to blame or push people, I lost temper and I apologized, take all the time you need to do your ASM magic. I wasn't sure if AviSynth+ x64 is ready when I decided to give up x86, now I know everything basic works and only a few special things are missing so I'm more then happy with the situation.

l33tmeatwad · 12th May 2015, 19:59

The reason I ask to test the x86 versions to see if it recreates the problem with AviSynth+ is to just narrow down if it is truly a plugin issue or just how AviSynth+ is using the plugin. There are several instances in this thread where users have reported plugins that work fine with the original branch of AviSynth putting out bad outputs with AviSynth+ because it works a little different based on the changes they made to try and optimize it. Keep in mind that the x64 version of AviSynth+ is actually still in testing and COULD have issues. If you are using plugins that are somewhat far away from the code of their x86 counterparts, I would suggest maybe further testing with the old (and somewhat unstable) unofficial AviSynth 2.5.8 64-bit version release just to give some variety (assuming the plugin is compatible with anything below 2.6, as some new ports are not). Simply knowing the access violation is happening at the plugin does not always mean that the plugin is 100% to blame, and if something needs to be fixed in AviSynth+ to maintain some compatibility then it may be a good thing for those working on it to know.

As for your earlier question, SEt is still active so you could make him aware of the issue at least.

3rd May 2015, 17:04	#1103 \| Link
l33tmeatwad Registered User Join Date: Jun 2007 Posts: 414	ResampleHQ has a 64bit version for v6 and under. Sent from my SM-N910V using Tapatalk __________________ Github \| AviSynth 101 \| VapourSynth 101

12th May 2015, 17:32	#1117 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	Requirements to reproduce the access violation are: Win8 x64 or Win10 x64 AviSynth+ x64 mvtools2 x64 StaxRip x64 or MPC-BE x64 Many x64 problems didn't surface on Win7 and VirtualDub and that's what made it difficult for everybody. Last edited by stax76; 12th May 2015 at 17:50.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

3rd May 2015, 10:49	#1101 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	@jones1913 It was also reported in the StaxRip thread that AviSynth+ x64 with QTGMC isn't stable using MT, a workaround is using a single thread and run 2 encoding instances to saturate the CPU. We have to wait until ultim or another developer investigates it.

4th May 2015, 03:29	#1105 \| Link
qyot27 ...? Join Date: Nov 2005 Location: Florida Posts: 1,420	That's not AviSynth+'s problem, it's 2.6's. And if you want the exception clause, use the C interface (which you should be doing anyway if you want portability).

4th May 2015, 18:09	#1107 \| Link
Reel.Deel Registered User Join Date: Mar 2012 Location: Texas Posts: 1,666	FTurn is already included in the AviSynth+ core so there's no need for it.

9th May 2015, 15:12	#1109 \| Link
snarfies Registered User Join Date: Apr 2015 Posts: 10	SharpAAMCmod (part of AnimeIVTC) is producing garbage output using Avisynth+. It works normally using baseline Avisynth 2.6.

10th May 2015, 19:53	#1110 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	Is somebody maintaining mvtools2 x64? I would like to report the following bug: exception raised at 0x00007FFE75BA18D6 (mvtools2.dll) in StaxRip.exe: 0xC0000005: access violation reading at 0x000000004F3004E8. I can provide a detailed description on how to reproduce the bug.

10th May 2015, 20:47	#1112 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	I have the latest one v2.6.0.5, maybe a AviSynth/plugin developer can take a look, it would be great being able to use SMDegrain, I would give it a try but somehow doubt I could do much.

10th May 2015, 20:53	#1113 \| Link
Reel.Deel Registered User Join Date: Mar 2012 Location: Texas Posts: 1,666	If I recall correctly you said this problem only occurs on Windows 8/10, correct? Also, might be worth posting instructions on how to reproduce it just in case the author reads this forum.

10th May 2015, 21:13	#1114 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	There are Win8/Win10 only bugs and there are bugs that only happen in certain applications like StaxRip or MPC-BE.

12th May 2015, 14:45	#1115 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	Who could I contact regarding mvtools2 x64? The help lists the following authors: Manao, Fizick(Alexander Balakhnin), Tsp, TSchniede, SEt Who is still active?

12th May 2015, 18:04	#1118 \| Link
l33tmeatwad Registered User Join Date: Jun 2007 Posts: 414	Could you try with regular AviSynth 2.6 RC3 and then AviSynth+ x86 with the 32-bit build of MPC-BE and any plugin you were having trouble with to see if the same issue exists?

12th May 2015, 19:37	#1119 \| Link
stax76 Registered User Join Date: Jun 2002 Location: On thin ice Posts: 6,837	It makes much sense trying different things in order to narrow a problem if you have no real idea what's happening. In this case tons of things are already known: many problems appear only on Win8/Win10 many problems appear only in certain applications like StaxRip x64 and MPC-BE x64 it's also known how to reproduce the problem: Win8 x64 or Win10 x64 AviSynth+ x64 mvtools2 x64 SMDegrain StaxRip x64 or MPC-BE x64 it's also known that mvtools2 is the currently only plugin known to not work in this environment, about 20 other plugins where successfully tested. it's also known what kind or error happens where: exception raised at 0x00007FFE75BA18D6 (mvtools2.dll) in StaxRip.exe: 0xC0000005: access violation reading at 0x000000004F3004E8. This means the code causing the access violation is mvtools2 and that Visual Studio can show exactly the location in the code. Visual Studio has a option to define at which type of exception is should break in the debugger, that's what I've enabled and that's what has to be enabled when debugging mvtools2. I couldn't setup the built environment because of the Intel compiler and yasm and I don't know ASM so I hope a ASM programmer can investigate it. I don't want to blame or push people, I lost temper and I apologized, take all the time you need to do your ASM magic. I wasn't sure if AviSynth+ x64 is ready when I decided to give up x86, now I know everything basic works and only a few special things are missing so I'm more then happy with the situation.

12th May 2015, 19:59	#1120 \| Link
l33tmeatwad Registered User Join Date: Jun 2007 Posts: 414	The reason I ask to test the x86 versions to see if it recreates the problem with AviSynth+ is to just narrow down if it is truly a plugin issue or just how AviSynth+ is using the plugin. There are several instances in this thread where users have reported plugins that work fine with the original branch of AviSynth putting out bad outputs with AviSynth+ because it works a little different based on the changes they made to try and optimize it. Keep in mind that the x64 version of AviSynth+ is actually still in testing and COULD have issues. If you are using plugins that are somewhat far away from the code of their x86 counterparts, I would suggest maybe further testing with the old (and somewhat unstable) unofficial AviSynth 2.5.8 64-bit version release just to give some variety (assuming the plugin is compatible with anything below 2.6, as some new ports are not). Simply knowing the access violation is happening at the plugin does not always mean that the plugin is 100% to blame, and if something needs to be fixed in AviSynth+ to maintain some compatibility then it may be a good thing for those working on it to know. As for your earlier question, SEt is still active so you could make him aware of the issue at least.