Avisynth+

[aegisofrime]

zerowalker, I don't know how much effort it would take. But there is always a way with avisynth. Whether it be workarounds, actual coding, or a request, there is a way.

ultim, thank you for the clear and concise words (march 23).

Side note: I have been using avs+ since it was introduced on doom9 and now that we have avs+ x64 I have not had a reason to switch back to the main or mt branch.

Agreed, AVS+ 64 is working quite well, but hopefully development hasn't died down again :(

[innocenat]

Do note that Avs+ has single codebase for 32bit and 64bit, unlike original Avisynth. This is the aim from start, hence tremendous rewriting. So main branch and mt branch also apply to Avs+ 64bit. And any development done to Avs+ will benefit both 32bit and 64bit version.

[Boulder]

The big problem is that there are no (up-to-date) 64-bit versions of some plugins, MVTools2 for example.

[Reel.Deel]

The big problem is that there are no (up-to-date) 64-bit versions of some plugins, MVTools2 for example.

Actually there is: mvtools_2.6.0.5_x64.zip (https://www.dropbox.com/s/swk97z4q834vugk/mvtools_2.6.0.5_x64.zip?dl=0)

There's also a 64-bit up-to-date dfttest and aWarpSharp2 amongst other useful plugins. QTGMC() is possible and does work well :).

The plan is to ship these plugins with the next stable release of AviSynth+. I'm not sure when that will be though.

[Boulder]

Hey, that's very good news :) Here's hoping that we'll get AVS+ to a stable level at some point..

[aegisofrime]

Actually there is: mvtools_2.6.0.5_x64.zip (https://www.dropbox.com/s/swk97z4q834vugk/mvtools_2.6.0.5_x64.zip?dl=0)

There's also a 64-bit up-to-date dfttest and aWarpSharp2 amongst other useful plugins. QTGMC() is possible and does work well :).

The plan is to ship these plugins with the next stable release of AviSynth+. I'm not sure when that will be though.

Thanks for that link! The most recent version of MVTools 64 that I could find was 2.5 by JoshyD. Thanks to you I now have a newer version :thanks:

It would be great if there was a one-stop location that consolidates the latest and greatest version of all these plugins. I actually used the Avisynth Wiki to look for these plugins, but seeing as the page for MVTools2 lists v2.5.11.3 as the latest perhaps it's not updated that often.

[qyot27]

Would it be possible to port the Avisource from the latest 2.6 version (that has multi-track support) to Avisynth+ 64bit version?
Or well it's probably possible but more like, would it be a simple task, copy paste;P?
You could also read the last few pages of the thread, which I can tell you haven't done, because you're asking for something that was done an entire month before you posted this and was stated very clearly more than once.

But once more for posterity:
Builds from r1718 onward contain all the relevant changes from 2.6 RC1. A significant part of the gap between ~1698 and 1718 are those migrated RC1 commits.

[qyot27]

Thanks for that link! The most recent version of MVTools 64 that I could find was 2.5 by JoshyD. Thanks to you I now have a newer version :thanks:

It would be great if there was a one-stop location that consolidates the latest and greatest version of all these plugins. I actually used the Avisynth Wiki to look for these plugins, but seeing as the page for MVTools2 lists v2.5.11.3 as the latest perhaps it's not updated that often.
I know it's not exactly the same thing, but I honestly think that having a master plugins repository on Github for hierarchical plugin builds would be a valuable addition.

What I mean is, have all the AviSynth(+) plugins that have their source hosted in separate git repos, but have a centralized repo on github.com/AviSynth that has these individual plugins added as git submodules so they can be pulled in and built all at once with a master buildsystem (probably CMake, all things considered). The only thing actually required for this is that the plugins use git as their DVCS, not a specific hosting service - Github would be the obvious one, but it'd also work for plugins hosted on Sourceforge (if they use Sourceforge's git side), bitbucket, Github, personal repos, etc.

That's mostly to make it easy for those of us on the building and distribution side, but some types of plugin managers could have the ability to track and build updated versions when needed (from the centralized repo or not), so if one ever comes to fruition, end users could benefit from it being organized like that also.

[stax76]

I started to work on 64-bit StaxRip. Is there a documentation or sample code on the script language extensions? For some languages like Chinese or Russian Unicode support is important, right? Is there a way to open source files with Unicode in the file name?

[Groucho2004]

For some languages like Chinese or Russian Unicode support is important, right? Is there a way to open source files with Unicode in the file name?
First of all, NTFS stores all file names in Unicode.

Usually you'll have to set your system locale to the language from which the characters in the file name originate in order to open the file with the standard file open functions.
I can run scripts (through AVSMeter for example) with these names without problem:
ja フリー百科事典.avs (locale set to Japanese)
ru Примечание.avs (locale set to Russian)
tc 分析代碼.avs (locale set to Chinese-Taiwan)

FYI - AVSPMod can open scripts with file names of any language. Very neat feature.

[stax76]

Thanks for the info, I never had the best understanding for text encodings, it quite improved lately though.

[stax76]

Has anybody a idea on this, is it likely a ffmpeg or AviSynth+ bug? I use AviSynth+ r1576 (x86/x64 installer) and ffmpeg-20150422-win64-static


BlankClip(length = 2999, fps = 23.974359, width = 16, height = 16, pixel_type = "YV12")
KillAudio()

"C:\Daten\Projekte\GitHub\staxrip\bin\Tools\ffmpeg\ffmpeg.exe" -i "C:\Daten\Temp\test.avs" -c:v copy -y "C:\Daten\Temp\test.avi"

ffmpeg version N-71633-gcbe2700 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-lzma --enable-decklink --enable-zlib
libavutil 54. 23.101 / 54. 23.101
libavcodec 56. 35.101 / 56. 35.101
libavformat 56. 31.100 / 56. 31.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 14.100 / 5. 14.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
[avisynth @ 0000000002e51000] AviSynth version is too old. Please upgrade to either AviSynth 2.6 >= RC1 or AviSynth+ >= r1718.
C:\Daten\Temp\test.avs: Unknown error occurred

[Groucho2004]

Has anybody a idea on this, is it likely a ffmpeg or AviSynth+ bug? I use AviSynth+ r1576 (x86/x64 installer) and ffmpeg-20150422-win64-static
It's ffmpeg - although the reasoning seems rather arbitrary:
#ifdef USING_AVISYNTH
/* On Windows, FFmpeg supports AviSynth interface version 6 or higher.
* This includes AviSynth 2.6 RC1 or higher, and AviSynth+ r1718 or higher,
* and excludes 2.5 and the 2.6 alphas. Since AvxSynth identifies itself
* as interface version 3 like 2.5.8, this needs to be special-cased. */

if (avs_library.avs_get_version(avs->clip) < 6) {
av_log(s, AV_LOG_ERROR,
"AviSynth version is too old. Please upgrade to either AviSynth 2.6 >= RC1 or AviSynth+ >= r1718.\n");
ret = AVERROR_UNKNOWN;
goto fail;
}
#endif

[stax76]

So the ffmpeg bug tracker would be the right place to report it? Is there more info I should provide when I create a ticket?

[Groucho2004]

So the ffmpeg bug tracker would be the right place to report it? Is there more info I should provide when I create a ticket?
What makes you think it's a bug? The devs have decided to only support interface version 6 and up. I'm sure they have a reason for that.

[stax76]

Sorry I missed my AviSynth+ is outdated, thanks for helping, it's probably better to stop programming today. :)

[stax76]

I would like to thank everybody making 64-Bit possible and suggest releasing a updated installer.

[manolito]

ffmpeg dropping support for AviSynth 2.5x has already been a problem in earlier versions.
Older versions created between March 2013 and September 2013 are not compatible with AviSynth versions prior to version 2.60.

Now the ffmpeg developers in their eternal wisdom have decided to drop support for AviSynth 2.5x for good. The last version which works with AviSynth 2.5x is ffmpeg-20150324-git-a2dd2d7-win32-static.7z.

Still the AviSynth SourceForge download page lists version 2.58 as the current stable release. Go figure...


Cheers
manolito

[qyot27]

The decision to drop support for anything below 2.6 RC1 was due to catastrophic header incompatibilities between 2.5 and 2.6 RC1* and the maintenance burden (and potential licensing minefield that could mean any additional 2.5 support would violate GPL) that would be incurred by trying to continue to support 2.5 while using properly updated 2.6 headers.

*technically, between 2.6a5 and RC1 too.


The gory details:
2.6 RC1 changes several functions in avisynth_c.h from AVSC_INLINE to AVSC_API, functions that libavformat's AviSynth demuxer uses. These changes mean that using the up-to-date version of the header from either classic or Plus would cause libavformat's AviSynth demuxer to fail compilation. The only solution was to change those standalone calls into struct-sourced calls from LOAD_AVSC_FUNC, which allows for supporting the up-to-date headers but breaks all prior versions. 2.5 was supported through a compat header sourced from FFMS2, and only contained the pieces that had been adapted there (regarding the internal functionality of avs_get_row_size_p/avs_get_height_p that changed between 2.5 and the 2.6 alphas).

Attempting to continue supporting 2.5 would require - similarly to what happened in AviSynth itself - moving the baked-in code from the old header into the compat header, swelling the latter with more things. But the compat header is under the MIT License, not the GPL. Moving GPL code into a non-GPL header is a no-no. So that would require trying to reverse engineer it. Further, the reverse engineered form would then require forcing more special-casing and code branching into the libavformat demuxer, which would work against the goal of it being [at least relatively] clean. And no one - not me, nor anyone else in the discussion on the FFmpeg-devel mailing list - were willing to or expressed any kind of interest in reverse engineering that for the sake of supporting a less stable, nearly 7 year old version of AviSynth when more stable and higher performance versions exist. Or for trying to support the 2.6 alphas when the support from the classic AviSynth devs for non-final versions has never lasted longer than the next alpha or RC release (see the CACHE_* changes in 2.6a4 requiring rebuilds of masktools-26).

In short, it was the state of the AviSynth headers themselves that burned this particular bridge. The real preference is for using official headers rather than the transitional form header it used to use.


The primary problem for Plus is that AviSynth+ 0.2 has yet to be formally released, so while we can say '2.6 RC1 or higher' for classic, users that go to avs-plus.net see the current stable version 0.1 (a.k.a. r1576), which is still in a pre-RC1 state and thus suffers from the same problem as classic 2.6a1-5 on this point.

[Groucho2004]

The decision to drop support for anything below 2.6 RC1 was due to catastrophic header incompatibilities between 2.5 and 2.6 RC1* and the maintenance burden (and potential licensing minefield that could mean any additional 2.5 support would violate GPL) that would be incurred by trying to continue to support 2.5 while using properly updated 2.6 headers.

*technically, between 2.6a5 and RC1 too.


The gory details:
2.6 RC1 changes several functions in avisynth_c.h from AVSC_INLINE to AVSC_API, functions that libavformat's AviSynth demuxer uses. These changes mean that using the up-to-date version of the header from either classic or Plus would cause libavformat's AviSynth demuxer to fail compilation. The only solution was to change those standalone calls into struct-sourced calls from LOAD_AVSC_FUNC, which allows for supporting the up-to-date headers but breaks all prior versions. 2.5 was supported through a compat header sourced from FFMS2, and only contained the pieces that had been adapted there (regarding the internal functionality of avs_get_row_size_p/avs_get_height_p that changed between 2.5 and the 2.6 alphas).

Attempting to continue supporting 2.5 would require - similarly to what happened in AviSynth itself - moving the baked-in code from the old header into the compat header, swelling the latter with more things. But the compat header is under the MIT License, not the GPL. Moving GPL code into a non-GPL header is a no-no. So that would require trying to reverse engineer it. Further, the reverse engineered form would then require forcing more special-casing and code branching into the libavformat demuxer, which would work against the goal of it being [at least relatively] clean. And no one - not me, nor anyone else in the discussion on the FFmpeg-devel mailing list - were willing to or expressed any kind of interest in reverse engineering that for the sake of supporting a less stable, nearly 7 year old version of AviSynth when more stable and higher performance versions exist. Or for trying to support the 2.6 alphas when the support from the classic AviSynth devs for non-final versions has never lasted longer than the next alpha or RC release (see the CACHE_* changes in 2.6a4 requiring rebuilds of masktools-26).

In short, it was the state of the AviSynth headers themselves that burned this particular bridge. The real preference is for using official headers rather than the transitional form header it used to use.


The primary problem for Plus is that AviSynth+ 0.2 has yet to be formally released, so while we can say '2.6 RC1 or higher' for classic, users that go to avs-plus.net see the current stable version 0.1 (a.k.a. r1576), which is still in a pre-RC1 state and thus suffers from the same problem as classic 2.6a1-5 on this point.

Thanks for the detailed explanation.

[manolito]

@ qyot27

Thanks for the explanation, too. Looks like for the time being I will be stuck with versions before ffmpeg-20150324.

Right now I mainly use the point release 2.5.2 from Dec_30_2014. Do you know if there are any significant improvements for MPEG2 encoding between this point release and the version from 2015/03/24 which make it worth upgrading?


Cheers
manolito

[stax76]

I've finished porting StaxRip to 64-Bit and would like to release a first beta and need a AviSynth+ installer that is compatible with the latest ffmpeg.

[zero9999]

I've finished porting StaxRip to 64-Bit and would like to release a first beta and need a AviSynth+ installer that is compatible with the latest ffmpeg.
what prevents you from building it yourself?

[stax76]

I've not built an installer in ten years, I don't know how to do it.

[qyot27]

@ qyot27

Thanks for the explanation, too. Looks like for the time being I will be stuck with versions before ffmpeg-20150324.

Right now I mainly use the point release 2.5.2 from Dec_30_2014. Do you know if there are any significant improvements for MPEG2 encoding between this point release and the version from 2015/03/24 which make it worth upgrading?


Cheers
manolito
I have no idea, save for searching the git log for 'mpegvideo' and trying to extrapolate.

http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=mpegvideo

There have been commits, but to what effect I don't know.

[jones1913]

Hey, after the recent StaxRip64 talk I've repeated my test from here (http://forum.doom9.org/showthread.php?p=1714157#post1714157) and here (http://forum.doom9.org/showthread.php?p=1714218#post1714218) with QTGMC and this time with x64 AVS+:

medium thread count:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
LWLibavVideoSource("sample.m2v")
QTGMC(Preset="Medium")
SelectEven()
Prefetch(4)

AVSMeter 1.9.8.0 (x64)
AviSynth+ 0.1 (r1779, MT, x86_64) (0.1.0.0)

Number of frames: 1754
Length (hh:mm:ss.ms): 00:01:10.160
Frame width: 720
Frame height: 576
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 1754 (0 - 1753)
FPS (min | max | average): 4.496 | 182612 | 39.56
Memory usage (phys | virt): 377 | 385 MB
Thread count: 67
CPU usage (average): 52%

Time (elapsed): 00:00:44.339

# x86 result was:
# FPS (min | max | average): 3.741 | 121742 | 35.30
# Memory usage (phys | virt): 350 | 366 MB
# Thread count: 68
# CPU usage (average): 55%

high thread count:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
LWLibavVideoSource("sample.m2v")
QTGMC(Preset="Medium")
SelectEven()
Prefetch(10)

AVSMeter 1.9.8.0 (x64)
AviSynth+ 0.1 (r1779, MT, x86_64) (0.1.0.0)

Number of frames: 1754
Length (hh:mm:ss.ms): 00:01:10.160
Frame width: 720
Frame height: 576
Framerate: 25.000 (25/1)
Colorspace: YV12

Frame (current | last): 983 | 1753
FPS (cur | min | max | avg): 53.29 | 2.133 | 100437 | 54.22
Memory usage (phys | virt): 685 | 706 MB
Thread count: 122
CPU usage (current | average): 94% | 95%

Time (elapsed | estimated): 00:00:18.149 | 00:00:32.350

Press 'Esc' to cancel the process...

# x86 result was:
# FPS (min | max | average): 2.018 | 87337 | 48.62
# Memory usage (phys | virt): 703 | 731 MB
# Thread count: 123
# CPU usage (average): 96%
There is a nice speed boost noticeable, the downside is that the latter script freezes at random points.

[jones1913]

the latter script freezes at random points.

I've cleaned up my plugins folder and leave only AVS+ core plugins and QTGMC core plugins (masktool, mvtools, rgtools, nnedi3), but it is still freezing, even with medium thread count.
And further the x86 version is now freezing too. :angry:
Something strange is going on here, after the last M$ update round a few days ago the system wont booted so I had to recover.

Maybe it is related to overclocking (FX-8320 @ 4100 MHz) but until now it was running fine for more than 1 year.

However, the problem seems to be on my system, sorry for confusion.

[stax76]

updated installer:

http://www.mediafire.com/download/wiwhhbtd3bcqcox/AviSynth+_v0.1.0_r1779.exe

[MysteryX]

What is the simplest way to properly activate MT with AviSynth+ ?

I have this script. I don't know if it's the most optimized but it works. How do I get that to work with AviSynth+ syntax?

SetMTMode(3,4)
PluginPath = ""
AviSource("Input.avi", audio=false, pixel_type="YV12")
SetMTMode(2)
LoadPlugin(PluginPath+"ColorMatrix.dll")
ColorMatrix(mode="Rec.601->Rec.709")
LoadPlugin(PluginPath+"FFT3DFilter.dll")
fft3dfilter(sigma=3, bt=5, bw=48, bh=48, ow=24, oh=24, ncpu=8)
LoadPlugin(PluginPath+"nnedi3.dll")
nnedi3_rpow2 (2)
LoadPlugin(PluginPath+"eedi3.dll")
eedi3_rpow2 (2)
Spline36Resize(960, 720)
fft3dfilter(bt=-1, sharpen=0.2, ncpu=8)
Distributor()

[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.

Personally, I'd format it differently:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)

PluginPath = ""

LoadPlugin(PluginPath+"ColorMatrix.dll")
LoadPlugin(PluginPath+"FFT3DFilter.dll")
LoadPlugin(PluginPath+"nnedi3.dll")
LoadPlugin(PluginPath+"eedi3.dll")

AviSource("Input.avi", audio=false, pixel_type="YV12")
ColorMatrix(mode="Rec.601->Rec.709")
fft3dfilter(sigma=3, bt=5, bw=48, bh=48, ow=24, oh=24, ncpu=8)
nnedi3_rpow2 (2)
eedi3_rpow2 (2)
Spline36Resize(960, 720)
fft3dfilter(bt=-1, sharpen=0.2, ncpu=8)
Prefetch(4)
The only actual things that changed were SetMTMode->SetFilterMTMode and Distributor->Prefetch. That's it, generally.


But, because the goal is that the user shouldn't have to worry about proper mode setting, the encouraged practice is to use the MtModes.avsi (https://gist.githubusercontent.com/tp7/8899021/raw/7733ecee475cdf8b6238967d5a3a4606a3948fd9/MtModes.avsi) master file (linked to the gist because it's more straight-forward for downloading) and have it in your plugin autoload directory. If a plugin or filter you use isn't in that list, you're encouraged to report back which mode should be used for it so it could be added to the list. And, you could always add the SetFilterMTMode lines you come up with personally to that .avsi and never bother with them in-script, only using Prefetch at the end.

[aegisofrime]

Hi qyot27, I understand that you are one of the developers for Avs+. I'm wondering if development has stopped temporarily again. I'm asking because since installing Build 1779 I have been having occasions where encoding jobs crash due to a "STATUS ACCESS VIOLATION". The stable build was Avs+ was a lot more stable (no pun intended).

Is anyone else getting such crashes in 1779? I do like the slight speed increase but I wonder if I should revert back to the stable build.

[qyot27]

I'm more of a contributor than 'one of the developers'. The stuff I do consists mostly of satellite functions, not big core things (or more patch monkey-like tasks, like the RC1 and RC2* integration patchsets). I'm not generally clued-in much on the gritty details since I rarely ever go into the IRC channel (one reason is that my development and testing environments have a fairly high separation from one another, making IRC participation difficult, although I'm also just not much for chatting on IRC anyway).

*which is extremely paltry (https://github.com/AviSynth/AviSynthPlus/pull/59) and affects no central code stuff in avsplus.

r1779 is not actually the newest revision from git; that would be r1825 (or r1833, if rc2integrate gets merged with no other additional commits).

I had uploaded a build r1825 to my MediaFire account some time ago but didn't post it because I was thinking we were on the cusp of 0.2 being released. It might have resolved the issues you're having already, so I guess I'll just go ahead and post the link:
AviSynth+ r1825 (http://www.mediafire.com/download/g69w83ya6kl3i1d)

[innocenat]

It is not called "stable" release for nothing ;-)

Currently there is only one developer for Avs+, ultim. Development relies heavily on his schedule. While qyot27 and I (and tp7 in the past) are contributors, we play insignificant roles (compared to ultim's). So yeah, right now development seems to stop (hopefully temporarily). Crash due to ACCESS VIOLATION may come from many thing; I'd suggest you try the r1825 to see if it solves your problem, and if not, a script would be appreciated.

[Groucho2004]

I see that UPX is still used to compress the binaries, just as in the official Avisynth.
The size argument really doesn't apply any more since hard drives nowadays are bigger than they were in 1990. Reduction of the distribution package size also does not apply, it's packed with 7-Zip anyway.
For some reason, many people use anti virus programs, most of which are so bad that they instantly throw up false positives when they come across a UPX packed file.
Lastly, you're introducing more complexity into the DLL loading process. You might think this argument is ridiculous but no software is bug free.

Just my 2c.

[ryrynz]

Just my 2c.

In agreement, nobody cares about executable file size now. The Internet is plenty quick and HDD space is bountiful. I'm all for less complexity, let it grow.

[innocenat]

Unless my memory serve me wrong, official Avs+ builds does not use UPX. Perhaps you are referring to qyot27's builds?

[Groucho2004]

Unless my memory serve me wrong, official Avs+ builds does not use UPX. Perhaps you are referring to qyot27's builds?
You're right. However, the x86 DevIL.dll is upx'ed in r1576 and r1779. :confused:

[aegisofrime]

Thanks for your kind replies qyot27 and innocenat, I will go ahead and test 1825 first!

[qyot27]

AFAIK, DevIL.dll is the official binary for that rather than one that's custom-built (although I could be wrong). The binary *.dlls themselves are in the Git repository, in already-UPX'd form (https://github.com/AviSynth/AviSynthPlus/blob/master/plugins/ImageSeq/lib/DevIL_x86/DevIL.dll), and just get copied around afterward. An unpacked DevIL.dll is 2 megs in size.

Anyway, my decision to UPX the binaries is based mostly on tradition and habit. After really considering it and looking at some of the adverse affects (I don't consider the anti-virus argument an important reason; the increased memory and loading complexity arguments are important, though), I don't think I'll do that anymore. It was never actually based on the bandwidth argument or disk space, really.

[aegisofrime]

Ok, I'm back after testing with 1825.

Firstly, to eliminate the possibility of a fault with the encoder, I encoded to hfyu instead of HEVC. It crashes at around the same percentage progress.

To eliminate the source filter, I tried L-Smash Works instead of FFMS. Same results, crash at the same percentage progress.

I have since reverted to the stable build and it's chugging along fine. I would like to help knock out this bug so let me know how I can help. For starters, here's the 3 scripts I used that have exhibited this problem:


<input>
QTGMC(Preset="Slow",InputType=3)
nnedi3_rpow2(2,cshift="Spline36Resize",fwidth=720,fheight=480)



<input>
QTGMC(Preset="Very Slow")



<input>
Dither_convert_8_to_16()
Dither_y_gamma_to_linear()
Dither_resize16(1280,720)
Dither_y_linear_to_gamma()
DitherPost()
QTGMC(Preset="Slow",InputType=1)
InterFrame(Cores=4,GPU=True,tuning="Smooth",FrameDouble=True)


It should be noted that not all source files exhibit the same issue. Some complete successfully, in fact most do. I encode a lot of files and I estimate about 20% will crash. Those that do crash always seem to crash at the same percentage of progress...

[Groucho2004]

Ok, I'm back after testing with 1825.

Firstly, to eliminate the possibility of a fault with the encoder, I encoded to hfyu instead of HEVC. It crashes at around the same percentage progress.

To eliminate the source filter, I tried L-Smash Works instead of FFMS. Same results, crash at the same percentage progress.

I have since reverted to the stable build and it's chugging along fine. I would like to help knock out this bug so let me know how I can help. For starters, here's the 3 scripts I used that have exhibited this problem:


<input>
QTGMC(Preset="Slow",InputType=3)
nnedi3_rpow2(2,cshift="Spline36Resize",fwidth=720,fheight=480)



<input>
QTGMC(Preset="Very Slow")



<input>
Dither_convert_8_to_16()
Dither_y_gamma_to_linear()
Dither_resize16(1280,720)
Dither_y_linear_to_gamma()
DitherPost()
QTGMC(Preset="Slow",InputType=1)
InterFrame(Cores=4,GPU=True,tuning="Smooth",FrameDouble=True)


It should be noted that not all source files exhibit the same issue. Some complete successfully, in fact most do. I encode a lot of files and I estimate about 20% will crash. Those that do crash always seem to crash at the same percentage of progress...

First thing I'd do is check memory usage. Run the scripts through AVSMeter and post the log(s).

Edit: Are you using 64 or 32 Bit AVS+?

[MistahBonzai]

Edit: moved as a reply to MysteryX post 1079

[MistahBonzai]

Way off topic however the "fft3dfilter(sigma=3, bt=5, bw=48, bh=48, ow=24, oh=24, ncpu=8)" qualifier ncpu=8 jumped out at me. NCPU is the max number of CPU threads to use for FFT calculation. I have found by trial and error that raising it above 1 for real time playback really increases the CPU load. Lets say using the above fft3dfilter avisynth filter in a simple script w/ncpu=1 consumed 24% CPU..jacking it up to 8 with all things equal could easily push it to 45% on a 4/8 core intel i7-3770. Use with care.

[MysteryX]

But, because the goal is that the user shouldn't have to worry about proper mode setting, the encouraged practice is to use the MtModes.avsi (https://gist.githubusercontent.com/tp7/8899021/raw/7733ecee475cdf8b6238967d5a3a4606a3948fd9/MtModes.avsi) master file (linked to the gist because it's more straight-forward for downloading) and have it in your plugin autoload directory. If a plugin or filter you use isn't in that list, you're encouraged to report back which mode should be used for it so it could be added to the list. And, you could always add the SetFilterMTMode lines you come up with personally to that .avsi and never bother with them in-script, only using Prefetch at the end.

For ColorMatrix, it says this
#note2: tried multiple files, seems to corrupt video even when it is the only filter in a script.
#tried mode 1, 2, and 3, none worked. however it works fine if MT isn't enabled.
#should ColorMatrix still be in the list? as a notice? or should it be removed?

So what should I do about ColorMatrix?

[MysteryX]

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.

Personally, I'd format it differently:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)

PluginPath = ""

LoadPlugin(PluginPath+"ColorMatrix.dll")
LoadPlugin(PluginPath+"FFT3DFilter.dll")
LoadPlugin(PluginPath+"nnedi3.dll")
LoadPlugin(PluginPath+"eedi3.dll")

AviSource("Input.avi", audio=false, pixel_type="YV12")
ColorMatrix(mode="Rec.601->Rec.709")
fft3dfilter(sigma=3, bt=5, bw=48, bh=48, ow=24, oh=24, ncpu=8)
nnedi3_rpow2 (2)
eedi3_rpow2 (2)
Spline36Resize(960, 720)
fft3dfilter(bt=-1, sharpen=0.2, ncpu=8)
Prefetch(4)
The only actual things that changed were SetMTMode->SetFilterMTMode and Distributor->Prefetch. That's it, generally.

Adding these lines causes the script to crash instantly.

[Groucho2004]

So what should I do about ColorMatrix?
ColorMatrix is very fast, no need for MT in my opinion.

[MysteryX]

How can I disable MT for ColorMatrix?

After testing more, NNEDI3 is causing image corruption, while EEDI3 is causing instant crash.

These work fine with AviSynth 2.6 MT

[jones1913]

I've also problems to get this running on my system: https://forum.doom9.org/showthread.php?p=1719222#post1719222.
First I thought that there is a problem with my system, because I had trouble last week (windows update broke something).

I have done the following things to exclude other error sources:

- restored a system restore point prior to the ms-updates
- load bios defaults to disable all overclocking
- tested stability with prime95 and memtest86+ with 100% success
- installed the recommened msvc redist-packages from ultim's linked download folder
- leave only the avs+ and qtgmc core plugins and source plugin in the plugins folder

The linked script completes in 100% of cases with avs 2.6 mt, with avs+ r1689 and with avs+ r1718, also all other software is running fine.
But with avs+ (r1779 + r1825 / x86 + x64) the script freezes in 60% of attempts at random points. The freezing occurs with avsmeter, playing with virtualdub, and on encoding with x264 or x265.

Strange is that I've tested this in the past and noticed no errors: http://forum.doom9.org/showthread.php?p=1714218#post1714218
Just coincidence? :confused:

Apart from that I have also noticed small differences in the linked mt-mode.avsi files
https://pad.riseup.net/p/avs_plus_mt_modes
https://gist.githubusercontent.com/tp7/8899021/raw/7733ecee475cdf8b6238967d5a3a4606a3948fd9/MtModes.avsi
which one is the recommened and most recent?

[Reel.Deel]

Apart from that I have also noticed small differences in the linked mt-mode.avsi files
https://pad.riseup.net/p/avs_plus_mt_modes
https://gist.githubusercontent.com/tp7/8899021/raw/7733ecee475cdf8b6238967d5a3a4606a3948fd9/MtModes.avsi
which one is the recommened and most recent?

A while back some fool messed up the mt pad using Google translate and after that there where some other issues with the pad not being available so tp7 created a gist way back in February 2014. It has not been updated since then (just a comment regarding avstp). The actual pad is a bit more updated but I also believe it's been tampered with in the last few months (I have the suspicion that someone messed up the pad again and "fix it" by pasting an older revision). I tried reverting back but unfortunately it only goes back about a month. Anyways we're doing away with the riseup pad since we've had too many problems! I revised the mt modes pad and uploaded it here: AviSynth+ MT modes (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) (it's also archived (https://web.archive.org/web/20150502160805/http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) just in case something happens), that link is read only but if you like to contribute you can do so here (http://publishwith.me/ooiV92hupl).

[MysteryX]

I've been playing with the latest AviSynth+ MT build with SVP. This build is MUCH better than a previous build I tried, but still has a few issues:
- lag between audio and video
- very occasional glitches or corrupt frames
- causes NNEDI3 filter to corrupt video
- causes EEDI3 filter to instantly crash