Avisynth+

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

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

Originally Posted by Groucho2004

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]

Originally Posted by innocenat

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.

[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, 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]

Originally Posted by 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...

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]

Originally Posted by qyot27

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

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.

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]

Originally Posted by MysteryX

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.p...22#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.ph...18#post1714218
Just coincidence?

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/t...9/MtModes.avsi
which one is the recommened and most recent?

[Reel.Deel]

Originally Posted by jones1913

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/t...9/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 (it's also archived just in case something happens), that link is read only but if you like to contribute you can do so here.

[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