Avisynth+

[stax76]

@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]

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/AviSynth%2B#AviSynth.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 (http://forum.doom9.org/showthread.php?t=170225))
Deshaker3D and other plugins by David Horman (http://horman.net/avisynth/)
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 (http://www.avisynth.nl/users/vcmohan/) 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]

ResampleHQ has a 64bit version for v6 and under.

Sent from my SM-N910V using Tapatalk

[Reel.Deel]

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 (http://web.archive.org/web/20130922222259/http://yo4kazu.110mb.com/) and possibly squid_80 (http://members.optusnet.com.au/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]

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]

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/AviSynth%2B#AviSynth.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 (http://forum.doom9.org/showthread.php?t=170225))
Deshaker3D and other plugins by David Horman (http://horman.net/avisynth/)
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 (http://www.avisynth.nl/users/vcmohan/) 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 (http://bengal.missouri.edu/~kes25c/)

[Reel.Deel]

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

[l33tmeatwad]

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]

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

[stax76]

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]

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 (http://forum.doom9.org/showpost.php?p=1718402&postcount=1054)? 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]

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]

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]

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

[stax76]

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]

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]

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]

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]

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]

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.

[stax76]

I tried:

mvtools2 v2.5.11.3 x86
AviSynth+ r1825 MT x86
SMDegrain
StaxRip x86

works fine

[l33tmeatwad]

Didn't really want to start a new thread for these, but attached are a few 64-bit versions of AviSynth plugins.

[Reel.Deel]

@l33tmeatwad

Cool, I had compiled these too but have had no time to test and upload them. Out of curiosity, what header did you use? For AviSynth 2.5 plugins that I've compiled for x64 I used the header included in dither. Not sure if that the kosher thing to do. For 2.6 plugins of course I use the latest AviSynth+ headers.

[l33tmeatwad]

I just used the one included with the FFMS2 source code.

[l33tmeatwad]

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 (http://forum.doom9.org/showthread.php?t=170225))
Deshaker3D and other plugins by David Horman (http://horman.net/avisynth/)
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 (http://www.avisynth.nl/users/vcmohan/) 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.
Just an update on some filters as I've been looking into them:

No Source Code:
Debilinear, Debicubic (Closed Source)
Deshaker3D
JpegSource
nnediocl
RedAverage
Toon (Closed Source)

Source Code Available but Unable to Build with VS2013 As-Is:
SVPflow
UnFilter

Source Code Available but needs asm rewrite for x64 compatibility:
ReduceFlicker
RelmoveDirt
SimpleResize
Tcomb
VariableBlur

New Compiles:
ResampleHQ (http://www.mediafire.com/download/4m31za3np4o5d24) - Compiled with a few warnings, but is from a newer SVN date than the v8 release. Use with caution! (NOTE: There were newer revisions, but they were missing a file so it could not be compiled.)

[Sparktank]

Didn't really want to start a new thread for these, but attached are a few 64-bit versions of AviSynth plugins.

New Compiles:
ResampleHQ (http://www.mediafire.com/download/4m31za3np4o5d24) - Compiled with a few warnings, but is from a newer SVN date than the v8 release. Use with caution! (NOTE: There were newer revisions, but they were missing a file so it could not be compiled.)

A new thread, indexed, would make it easier to find these rather than "searching" or even flipping through pages.

It would be pretty easy to lose track of these.
Especially if there are to be more updates.

Thanks for the work, though. Interested in seeing the udpated RHQ.

[l33tmeatwad]

A new thread, indexed, would make it easier to find these rather than "searching" or even flipping through pages.

It would be pretty easy to lose track of these.
Especially if there are to be more updates.

Thanks for the work, though. Interested in seeing the updated RHQ.I linked to the compiles in the AviSynth+ section on the AviSynth wiki in the 64-bit plugins section (except for ResampleHQ, I haven't really tested it a lot to make sure it's stable, although it does work...)

[vcmohan]

I am trying to configure my MS VS 2010 to x64 . I have installed SDK 8.1. However I am unable to configure my vs2010 to X64 as in configuration manager I do not get it in the new platform. I tried following steps given on the web by MS. Do I need to use only SDK 7.1? Or can I instal VS2013 community version and compile my plugins in 64bit version? Hope I need not uninstall VS2010 and SDK 8.1 versions for installing community version.

[captainadamo]

Are you using the community version of 2010? If so, it does not include a 64-bit compiler and you must use the one that comes with the SDK.

[l33tmeatwad]

I am trying to configure my MS VS 2010 to x64 . I have installed SDK 8.1. However I am unable to configure my vs2010 to X64 as in configuration manager I do not get it in the new platform. I tried following steps given on the web by MS. Do I need to use only SDK 7.1? Or can I instal VS2013 community version and compile my plugins in 64bit version? Hope I need not uninstall VS2010 and SDK 8.1 versions for installing community version.Personally I'd say try 2013, I haven't had any trouble compiling plugins using it, however I'm not super knowledgable in this area so I'd lean more towards advice from anyone that is more experienced.

[Wilbert]

Plugins compiled with 2013 don't run in XP.

@vcmohan,

This could be your problem:


Install this update to restore the Visual C++ compilers and libraries that may have been removed when Visual Studio 2010 Service Pack 1 (SP1) was installed. The compilers and libraries are part of the Microsoft Windows Software Development Kit for Windows 7 and the .NET Framework 4 (later referred to as the Windows SDK 7.1). Important: Before you install this update, review the readme (http://go.microsoft.com/fwlink/?LinkID=213290), which has the latest information about this release.


source: https://www.microsoft.com/en-us/download/details.aspx?id=4422 (see also the readme on that page) and https://support.microsoft.com/en-gb/kb/2519277 .

[captainadamo]

Plugins compiled with 2013 don't run in XP.

Only by default. VS2013 can still have XP compatibility when you select the option.

[chainik_svp]

Source Code Available but Unable to Build with VS2013 As-Is:
SVPflow

OK, I think I could release x64 build of SVPflow...
Still it's not usable for SVP itself mainly because of AVS/AVS+ x64 + ffdshow x64 issues.
But it should be fine for Interframe.

[l33tmeatwad]

Only by default. VS2013 can still have XP compatibility when you select the option.Where is that option?

[captainadamo]

Where is that option?

It's the Platform Toolset option under the general properties of the project. Been around since VS2010.

[l33tmeatwad]

It's the Platform Toolset option under the general properties of the project. Been around since VS2010.Thanks for the info. Went ahead and rebuilt those plugins to be XP compatible.

[vcmohan]

This could be your problem:



source: https://www.microsoft.com/en-us/download/details.aspx?id=4422 (see also the readme on that page) and https://support.microsoft.com/en-gb/kb/2519277 .

My computer has windows 8.1 as OS. Do I still need to use only SDK 7.1 and not SDK 8.1?

[vcmohan]

Multithreading: From what I read from previous pages plugins themselves do not declare the type of multithreading it supports. Only in the script the user need to declare. To me this looks it can lead to bad executions. If a plugin does not support multithreading 3 but user in script states it as 3 will it not lead to problem?

[Wilbert]

My computer has windows 8.1 as OS. Do I still need to use only SDK 7.1 and not SDK 8.1?
Sorry I misread your post above. I see that you were using SDK 8.1 (and VC2010). I have no idea why you can't select X64.

[foxyshadis]

My computer has windows 8.1 as OS. Do I still need to use only SDK 7.1 and not SDK 8.1?

That explains it. VC++ 2010 express relies on the SDK 7.1 to provide the x64 compilers. (The SDK has traditionally come with command-line compilers since the 90's.) SDK 8.1 removed all compilers because they're all built into VC++ 2013 community now, so no more access in any VS version. You can have SDK 7.1 and 8.1 side-by-side, but honestly it'd be less work to switch to 2013 (or even 2015 RC, which already seems just as stable as previous versions).

[stax76]

I don't know about C++ but for VB.NET Visual Studio 2015 Community Edition RC has been 100% stable since I use it, I don't remember a single problem.

[vcmohan]

I tried using avisynth plus header for compiling a plugin. Found that I also require <avs/capi.h>, <avs/config.h> and <avs/types.h> It says Refactor public header for capi and types while on config it reads required for architecture detection in cross compiling. This requirement was not mentioned in what headers to use write up.
For FFT I use a dll of FFTW. It requires the number of threads being used to be specified . How do I get this information?

[qyot27]

AviSynth+ now does what most other projects do in regard to its headers: the user is supposed to install the headers to the system (or compiler path, since Windows development understands that concept differently), and then add the header path when their plugin or program is being built. Not that users/plugins can't include local copies, but doing that is not recommended anymore (yes, sometimes it's inevitable*) and is one of those 'here be dragons' moments as far as support goes.

*in FFmpeg, for example, to relieve the user of the burden of tracking the headers down themselves

In other words,
If you use the GNUmakefile, add the $(PREFIX)$(INCLUDEDIR)/avisynth directory to the header paths of the project you're building.
If you *must* ship local, the avs/ subdir has to accompany the avisynth{_c}.h header(s) because they'd be installed together anyway if done properly, and the directory containing the headers and the subdir needs to be added to the include path the way you'd normally do that.

You're not supposed to 'use' the headers in the avs/ subdir, you're only supposed to use avisynth{_c}.h. But avisynth{_c}.h needs those headers, which should have been installed properly anyway.




But what you're referring to are simply the commit log entries for the latest changes made to the headers in the avs/ subdir. Those log messages have no bearing on this topic whatsoever.

[vcmohan]

Thanks. I will now keep a separate include directory for avisynth.h .
I am still in dark about how to get number of threads running.For FFT, I use a dll of FFTW.org. It requires the number of threads being used to be specified . How do I get this information?

[cretindesalpes]

Call GetLogicalProcessorInformation (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683194.aspx) or GetProcessAffinityMask (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683213.aspx) to know the number of threads on your system (count the bits set). But (http://www.fftw.org/doc/How-Many-Threads-to-Use_003f.html#How-Many-Threads-to-Use_003f) if the size of your FFT is small, just set one thread.

In avstp I use this function:
int ThreadMgr::count_nbr_logical_proc ()
{
int nbr_proc = 0;

::DWORD_PTR mask_proc;
::DWORD_PTR mask_sys;
const ::HANDLE proc_hnd = ::GetCurrentProcess ();
const ::BOOL res =
::GetProcessAffinityMask (proc_hnd, &mask_proc, &mask_sys);
if (res != 0)
{
if (mask_proc == 0 && mask_sys == 0)
{
nbr_proc = 64;
}
else
{
while (mask_proc != 0)
{
nbr_proc += int (mask_proc) & 1;
mask_proc >>= 1;
}
}
}

if (nbr_proc <= 0)
{
nbr_proc = 1;
}

return (nbr_proc);
}

Note: if you use C++11, you’d better call std::thread::hardware_concurrency().

[stax76]

I hope I am allowed to re-post feedback luigizaninoni posted in the StaxRip x64 thread. Personally I don't have experimented much with MT but I'm very sure the single most popular use case for MT is QTGMC so trying to make QTGMC work well would make much sense.

Made some more tests on Staxrip 64 bit. In my opinion there are a few important issues:

For the following tests the configuration is: StaxRip x64 pre-release or Staxrip x32 1.2.2.0 - i7-4770S – x265 slow preset – Encode clip 1h 41m (same clip used throughout the tests)

Script:
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\ffms2\ffms2.dll")
Import("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\QTGMC\QTGMC.avsi")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\masktools2\masktools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\mvtools2\mvtools2.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\nnedi3\nnedi3.dll")
LoadPlugin("C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Tools\Plugins\RgTools\RgTools.dll")
FFVideoSource("C:\Users\luigi.TZMS\Desktop\sherlock temp files\sherlock.m2v", cachefile = "C:\Users\luigi.TZMS\Desktop\sherlock temp files\sherlock.ffindex")
QTGMC(Preset="Slow") (InputType=1 for progressive)
SelectEven() (only for interlaced)
RemoveGrain()


ISSUE N.1: AVISYNTH+ GRADUALLY SLOWS DOWN


To show the progressive slowdown of Avisynth+ I made two checkpoints: one at 5.000 frames and one at 150.000 frames (near the end of the encode)

Single-threaded Avisynth+:
Progressive: Encode starts at full steam: CPU at average 75%, fps 19,20 at 5.000-frame checkpoint. CPU is split into about 60% x265, and 15% avs4x26x

However encode gradually gets slower: fps and cpu keep going down. At 150.000-frame checkpoint we have CPU 50% (x265:35% and avs4x26x:15%) and fps 14,50. Fps have gone down 25%

Interlaced: At 5.000 frame checkpoint CPU at average 48% (32% x265 and 16% avs), fps 10,46. Obviously processing interlaced requires more work, so avs produces less frames for x265 to work on. The slowdown of the encoding becomes quite serious on interlaced: at 150.000-frame checkpoint fps are 2,65. Fps have gone down 75% !!

It seems that Avisynth+ is producing less frames over time, so x265 becomes less busy. The more complex the avs script, the more Avisynth+ slows down over time.

I repeated the same test with traditional Avisynth (not plus), and the problem does not exist:
Progressive: 17,75 fps at first checkpoint, 17,89 at second checkpoint. CPU steady around 70%
Interlaced: 11,44 fps and 11,51 respectively; cpu around 51-54%

ISSUE N.2: MULTITHREADED AVISYNTH CRASHES TOO OFTEN

For multithreaded scripts add:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3) (at start of script)
Prefetch(6) (at end of script)

This issue has already been discussed in this thread, but the problem has not been solved yet. Encoding starts very fast, nearly 22 fps. However at a certain unpredictable point it crashes: it may be at the very beginning, it may be after a couple of hours, it seems totally random. If you are doing a very short encode, you might even manage to complete it without errors. Anyway MT Avisynth+ can’t be trusted at the moment.

ISSUE N.3: SOME 64-BIT PLUGINS ARE NOT AVAILABLE

For my workflow, I sometimes use MCTemporalDenoise for some noisy clips. I managed to find most 64-bit plugins required. However, I haven’t been able to find DCTFilter-64bit, so MCTD can’t be used. Is there any workaround, by the way ?

Although 64bit versions exist for most plugins, there is a still a fair number of 32bit-only dlls. So for more complex workflows you need to stick to avisynth-32bit.

CONCLUSIONS
Although very promising, Staxrip 64bit is not ready for prime time. The problems, it seems to me, lie not in Staxrip itself, but rather in Avisynth+ and/or its plugins (I don’t know exactly where the problem/s lie)

So in my opinion Staxrip 32bit should be kept alive at least for the time being, until problems are solved; not necessarily with the introduction of new features, but at least issuing maintenance releases.

Thanks Stax76 for your great work. Staxrip32 is an excellent program, and I am sure that, eventually, Staxrip64 will become very good,too

[luigizaninoni]

It is not an Avisynth problem. It is because the user uses very complex QTGMC script with many plugins. Many MT processing = many bottleneck states. And x264 is extreme optimized software.



It is a non-compatibility of FFVideoSource with some video sources and MT. I was getting constant crashes with this plugin. Therefore, I stop using it.
But, the majority of Avisynth crashes is that in 32 bits there is no free memory for all plugin buffers and frame cache.

Sorry, I don't understand your answer n.1: issue is with Avisynth+ singlethreaded, not multithreaded

For issue n.2, what would you advise instead of FFvideosource ? Anyway, crashes occur also in Avisynth+ 64bit, so it isn't a 32-bit problem.

[vcmohan]

Call GetLogicalProcessorInformation (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683194.aspx) or GetProcessAffinityMask (https://msdn.microsoft.com/en-us/library/windows/desktop/ms683213.aspx) to know the number of threads on your system (count the bits set). But (http://www.fftw.org/doc/How-Many-Threads-to-Use_003f.html#How-Many-Threads-to-Use_003f) if the size of your FFT is small, just set one thread.
Note: if you use C++11, you’d better call std::thread::hardware_concurrency().
I am using VS2013 community version.
I thought that the user script is evaluated by avs+ and number of threads for any processor is decided upon. This ofcourse will be limited by the cpu on which it is run.
In vapoursynth there is a call to get this number. In avisynth+ is it possible to get this value?

[luigizaninoni]

It is not an Avisynth problem. It is because the user uses very complex QTGMC script with many plugins. Many MT processing = many bottleneck states. And x264 is extreme optimized software.



It is a non-compatibility of FFVideoSource with some video sources and MT. I was getting constant crashes with this plugin. Therefore, I stop using it.
But, the majority of Avisynth crashes is that in 32 bits there is no free memory for all plugin buffers and frame cache.

Hi Rean, just wanted to let you know that I tried a different source filter for my .ts encodes as you suggested. I tried with Frimsource, and now no more slowdowns and no more crashes. So it looks like FFVideosource was the real culprit, issues 1 and 2 do not depend on Avisynth+. Thanks a lot for your help

[stax76]

Hi Rean, just wanted to let you know that I tried a different source filter for my .ts encodes as you suggested. I tried with Frimsource, and now no more slowdowns and no more crashes. So it looks like FFVideosource was the real culprit, issues 1 and 2 do not depend on Avisynth+. Thanks a lot for your help

If your source is DVB AVC TS then you first need something to fix av sync, in the last release I made demuxing with DGAVCIndex the default method to demux AVC TS, this was experimental and it was a failure since it failed to keep av sync for a simple recording. The next release again will use dsmux to convert AVC TS to MKV while fixing av sync. This means your source is mkv which means you can use LWLibavVideoSource or DGSource (DGDecNV) as alternative to FFVideoSource, you can make this default at Tools > Settings > Source Filters > default > LWLibavVideoSource

FFVideoSource and LWLibavVideoSource are both based on ffmpeg so you might see the same problems, DGSource might also cause problems and maybe decoding to a loss less codec is a alternative, I've seen people do it before but don't know exactly why. Either way dealing with 1080p or even 4K will push things to the limit.