Avisynth+

[chainik_svp]

I hate to say this but 4K video playback is unusable.

Playback is choppy. Some frames are distorted with green color. It's almost impossible to catch it and make a screenshot so I'm not sure if the whole frame is green or just a part of it.
And it crashes at about 2.5G of used memory.

Needless to say latest "official" AVS MT build is working good with the same script and the same amount of memory.

[ultim]

Okay guys, Murphy never sleeps, and I managed to inadvertently break the symbolic names (MT_NICE_FILTER, MT_MULTI_INSTANCE, MT_SERIALIZED) of the MT modes last minute before release. So if you used these names with r1778, they didn't work correctly. I just published r1779 which corrects this fuckup of mine. Please be sure to pull r1779 (http://avs-plus.net/builds) if you are experimenting with MT, because this fix is kind of vital for it.

[chainik_svp]

So if you used these names

I did not.

[ultim]

I hate to say this but 4K video playback is unusable.

Playback is choppy. Some frames are distorted with green color. It's almost impossible to catch it and make a screenshot so I'm not sure if the whole frame is green or just a part of it.
And it crashes at about 2.5G of used memory.

Needless to say latest "official" AVS MT build is working good with the same script and the same amount of memory.

Hi Chainik,

I just tried to use AVS+ with SVP, and I got SVP working with Avs-MT. The current SVP though doesn't allow me to use Avs+ for any kind of debugging or trials, so I'll need support from your side too. Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this (https://github.com/AviSynth/AviSynthPlus/issues/57) bug report.

[chainik_svp]

ultim
Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this bug report.

OK, I agree.
BUT keep in mind that SVP doesn't do anything "special", it's just a usual AVS filter. So any issue that's looking like "SVP-only" or "ffdshow-only" may, in fact, highlight some more deep problems inside the frame server. Or may not :)

[ultim]

Actually, r1778 crashes with every script. I'm on WinXPSP3.

http://puu.sh/gEgaQ/681f4cc6ed.jpg

Seems to work for me. What is your host application for Avs?

[Groucho2004]

http://puu.sh/gEgaQ/681f4cc6ed.jpg

Seems to work for me. What is your host application for Avs?
I did some more testing and I turns out that a simple script actually runs through despite the "crash":

http://s12.postimg.org/vlagueerh/Image1.png

This also happens when I load the script in MPC (crashes when MPC is closed).

This happens only with r1779, no other Avisynth version.

Edit:
Fixed it in AVSMeter. It seems to be some race condition when releasing the IScriptenvironment and/or unloading avisynth.dll.

I tested some other programs:

Working fine:
MPC-HC
VirtualDub
AVSPMod

Crashing when closing:
MPC 6.4.9.1

[ultim]

Fixed it in AVSMeter. It seems to be some race condition when releasing the IScriptenvironment and/or unloading avisynth.dll.


I am still using AVSMeter 1.7.5 and I saw no problems there. What was the fix in AVSMeter for you? I'd like to check it out to make sure it is not hiding a different problem inside AVS+. Also, it might be related to this commit (https://github.com/AviSynth/AviSynthPlus/commit/422aae83e0ba3b77fd066b6217b2cba7121f6010), which was partially engineered to uncover resource deinitialization mistakes in the host.

[Groucho2004]

I am still using AVSMeter 1.7.5 and I saw no problems there. What was the fix in AVSMeter for you? I'd like to check it out to make sure it is not hiding a different problem inside AVS+. Also, it might be related to this commit (https://github.com/AviSynth/AviSynthPlus/commit/422aae83e0ba3b77fd066b6217b2cba7121f6010), which was partially engineered to uncover resource deinitialization mistakes in the host.
Versions before 1.9.1 are not affected.

Since v1.9.1 I'm using a worker thread to determine a suitable frame interval for measurements. In that thread, the script environment is created and released. I changed the threading code a bit to prevent sync issues. I did a lot of tests and it seems fine now.

[mark0077]

ultim
Since this conversions might take long and I don't want SVP to hijack this forum thread (for most people Avs+ r1778/9 works just fine), I invite you to continue bringing SVP and AVS+ closer together in this bug report.

OK, I agree.
BUT keep in mind that SVP doesn't do anything "special", it's just a usual AVS filter. So any issue that's looking like "SVP-only" or "ffdshow-only" may, in fact, highlight some more deep problems inside the frame server. Or may not :)

Just a quick question for avisynth+ developers and also Chainik. When it comes to these issues that are somewhat unexplained, or like the issues I'm having also with ffdshow buffer values causing either

1) Audio to go out of sync depending on the buffer ahead used, or
2) after a seek occurs an issue that causes a frame from ~4 minutes in the past to seemingly appear for a split second,

where do we turn?

Do we have any ffdshow developers to look into these from ffdshow point of view. If not is there any way to run these avisynth scripts outside of ffdshow in the foreseeable future as my only HTPC issues over the past few months seem to all exist around the ffdshow buffer weirdness causing various side effects like the ones mentioned above and probably don't indicate issues in avisynth+ or SVP?

[chainik_svp]

mark0077, your issues are completely different ;) And the 2nd one is easily fixable with "turn off on seek" SVP option.

[mark0077]

mark0077, your issues are completely different ;) And the 2nd one is easily fixable with "turn off on seek" SVP option.

I understand SVP has workarounds for some of these issues, but they are not fixes. I use a custom InterFrame script, without the SVP tray icon, but the question still stands, where theres issues in ffdshow, do we continue to try to workaround them or is there a solution to get away from ffdshow in the foreseeable future or are workarounds the only option?

[chainik_svp]

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

I use a custom InterFrame script, without the SVP tray icon
It is always by way of pain one arrives at pleasure.

[mark0077]

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

I would still think audio shouldn't go out of sync due to a seek even if ffdshow doesn't / avisynth doesn't know about the seek. I wouldn't mind if things sounded or looked bad right after a seek for example, until it exhausted its current frame buffers. But for future frames, I would still expect them to perform correctly but they don't, thats the issue.

Also ignoring seeks, the other issues with ffdshow buffers that have been highlighted. My question still remains, is ffdshow still the way forward if theres no developers interested in fixing these, or is there a way to run these scripts outside of ffdshow in the future?

[ultim]

There're no reliable ways for Avisynth to know that the seek occurs so it can't reset internal frame buffers.

AviSynth doesn't need to know about seeks to operate correctly in every case. For every frame requested, seek or not, each filter also re-requests every frame they need to calculate the new output. Possible inefficienies caused by this schema are solved by the use of caches along the pipeline (which are implemented in a way to also not need information about seeks). If anything breaks on a seek, that is either a limitation of the source filter (which in SVP's case would be ffdshow), or a bug in one of the filters.

[Groucho2004]

Some interesting test results with QTGMC(). This is a single-threaded test although mvtools runs multi-threaded internally (avstp.dll).

Script (source clip is 720x576, interlaced):
SetMemoryMax(1024)
LoadPlugin("E:\Apps\VideoTools\DGDec\DGDecode.dll")
Import("E:\Apps\VideoTools\AVSPlugins\qtgmc.avsi")
MPEG2Source("F:\DVD_Interlaced\test.d2v", idct = 4)
AssumeTFF()
QTGMC(Preset="Slow")
Trim(1000, 1999)

Avisynth 2.6 RC1:
FPS (min | max | average): 4.429 | 176.3 | 30.95
Thread count: 8
CPU usage (average): 36%
Memory usage (phys | virt): 1036 | 1070 MB
Time (elapsed): 00:00:32.314

AVS+ r1779:
FPS (min | max | average): 3.431 | 163.6 | 28.03
Thread count: 16
CPU usage (average): 35%
Memory usage (phys | virt): 183 | 210 MB
Time (elapsed): 00:00:35.671


The most obvious thing is the very low memory usage of AVS+ compared to RC1. AVS+ is however a bit slower.

[noee]

I've been testing with AVS+/MT mode w/QTGMC. So far, I haven't checked numbers against SETs 2.6RC1, but fwiw, in 64bit version, AVS+ will complete an encode that fails with the older (JoshyD?) 64-bit build.

My very basic script: Import("c:\temp\job1\setfiltermtmodes.avsi")
MPEG2Source("C:\Temp\job1\movie.d2v")
ChangeFPS(last,last,true)
AssumeTFF()
QTGMC( Preset="Faster", FPSDivisor=2, EdiThreads=6)
%RESIZE%
Prefetch(4)

Have you tried yet? If so, what kind of numbers do you see?

[Boulder]

I'm unable to run a test using AVSMeter. At some point, the memory consumption seems to jump up and processing either slows down dramatically or stalls completely. It doesn't seem to matter how many threads I use, I've tested 2-4 as I have a quad-core i5.

If I disable a rather complex function I use to process the video (denoise etc.), the script runs through the test normally.

[Groucho2004]

I'm unable to run a test using AVSMeter. At some point, the memory consumption seems to jump up and processing either slows down dramatically or stalls completely. It doesn't seem to matter how many threads I use, I've tested 2-4 as I have a quad-core i5.

If I disable a rather complex function I use to process the video (denoise etc.), the script runs through the test normally.
After 13 years being a member here and almost 4000 posts one would think that you'd post something more helpful.
- No script
- No mention of whether you used 64 or 32 Bit AVS+
- No mention of whether you used 64 or 32 Bit OS

[Boulder]

Sorry, I definitely should have been more clear. I would post the script but it would require me to post all the helper functions as well and they are a real mess :D I'm on a 64-bit OS but using 32-bit AVS+ since the external plugins I need (MVTools etc.) are not ported.

I was thinking more on the lines of finding out if there are possible problems in memory handling as ultim said he's looking to make the cache handling more robust. Then again, I seem to get the script to stall even with SetMemoryMax(256) and two threads.

So what I'm going to do is to start stripping down my helper function to smaller pieces and see which is the one that breaks things :(

[Boulder]

Hey, I'm in luck today :)

I found out that the very first thing done by my cleaner function is the one that starts acting up.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
DGSource("hotfuzztest.dgi")
Flux5framesT(th=2,chromamotion=true)
Prefetch(4)
and Flux5framesT along with what it needs:
function Flux5framesT(clip c, int "th", int "thC", bool "chromamotion")
{
th = default(th,7)
thC = default(thC, (chromamotion == true) ? th : 0)
med = c.TMedian2(chromamotion=chromamotion)
avg = c.temporalsoften(2,th,thC,24,2)
medD = mt_makediff(c,med,U=chromamotion?3:1,V=chromamotion?3:1)
avgD = mt_makediff(c,avg,U=chromamotion?3:1,V=chromamotion?3:1)
DD = mt_lutxy(medD,avgD,"x 128 - y 128 - * 0 < 128 x 128 - abs y 128 - abs < x y ? ?",U=chromamotion?3:1,V=chromamotion?3:1)
output = c.mt_makediff(DD,U=chromamotion?3:1,V=chromamotion?3:1)
return output
}

function TMedian2(clip c, bool "chromamotion")
{
Median2( c.selectevery(1,-2), c.selectevery(1,-1), c, c.selectevery(1,1), c.selectevery(1,2), chromamotion=chromamotion )
}

Function Median2(clip "input_1", clip "input_2", clip "input_3", clip "input_4", clip "input_5", string "chroma", bool "chromamotion")
{# median of 5 clips from Helpers.avs by G-force

chromamotion = default(chromamotion, true)
chroma = default(chroma, (chromamotion == true) ? "process" : "copy first") #default is "process". Alternates: "copy first" or "copy second"

#MEDIAN(i1,i3,i5)
Interleave(input_1,input_3,input_5)
chroma == "process" ? Clense() : Clense(grey=true)
#chroma == "process" ? MedianBlurT(0,0,0,1).merge(last,0.5).MedianBlurT(0,0,0,1) : MedianBlurT(0,-1,-1,1).merge(last,0.5).MedianBlurT(0,-1,-1,1)
m1 = selectevery(3,1)

#MAX(MIN(i1,i3,i5),i2)
m2 = input_1.MT_Logic(input_3,"min",chroma=chroma).MT_Logic(input_5,"min",chroma=chroma).MT_Logic(input_2,"max",chroma=chroma)

#MIN(MAX(i1,i3,i5),i4)
m3 = input_1.MT_Logic(input_3,"max",chroma=chroma).MT_Logic(input_5,"max",chroma=chroma).MT_Logic(input_4,"min",chroma=chroma)

Interleave(m1,m2,m3)
chroma == "process" ? Clense() : Clense(grey=true)
#chroma == "process" ? MedianBlurT(0,0,0,1).merge(last,0.5).MedianBlurT(0,0,0,1) : MedianBlurT(0,-1,-1,1).merge(last,0.5).MedianBlurT(0,-1,-1,1)
selectevery(3,1)

chroma == "copy first" ? last.MergeChroma(input_1) : chroma == "copy second" ? last.MergeChroma(input_2) : last

Return(last)
}

I think these two plugins are the only ones that are needed: https://drive.google.com/file/d/0BzeF_1syecQwc01uc3VqckJWT1k/view?usp=sharing


EDIT: when replacing the two "chroma ==" lines with the MedianBlurT version in the Median2 function, I just get a crash when opening the script.

EDIT2: In fact, in AVS+ the function doesn't seem to do anything. Comparing it with the original clip doesn't show any differences, with SEt's MT build the changes are obvious.

[ultim]

I was thinking more on the lines of finding out if there are possible problems in memory handling as ultim said he's looking to make the cache handling more robust. Then again, I seem to get the script to stall even with SetMemoryMax(256) and two threads.

Yes the caches need some fine tuning. Currently they work great until memory starts running out.

It would certainly help a lot to be able to test with your scripts. If you use a lot of helper scripts, just post them too :) If you don't want to make them public, maybe you can PM or e-mail them to me?

EDIT: Oh, you made a new post while I wrote my own. Thanks, I'll check it out.

[colours]

I found out that the very first thing done by my cleaner function is the one that starts acting up.

reallylongscript

I know this is not very relevant, but I'm seeing a whole lot of optimisation potential there. Not tested, but should produce identical results and be faster.

function Flux5framesT(clip c,int "th",int "thC",bool "chromamotion")
{
th = default(th, 7)
thC = default(thC, chromamotion ? th : 0)
med = chromamotion ? ytouv(c.utoy8().median5t(), c.vtoy8().median5t(), c.median5t()) : c.median5t().mergechroma(c)
avg = c.temporalsoften(2, th, thC, 24, 2)
output = interleave(c, med, avg).clense(grey=!chromamotion).selectevery(3,1)
return output
}

function median5t(clip src)
{ # from here (https://mechaweaponsvidya.wordpress.com/2014/04/23/ricing-your-temporal-medians-for-maximum-speed/)
function min(clip a, clip b) {return mt_logic(a, b, mode="min")}
function max(clip a, clip b) {return mt_logic(a, b, mode="max")}
src
last + trim(framecount()-1,-1).loop(5)
bcmin = min(SelectEvery(2, -1), SelectEvery(2, 0))
bcmax = max(SelectEvery(2, -1), SelectEvery(2, 0))
demin = bcmin.SelectEvery(1, 1)
demax = bcmax.SelectEvery(1, 1)
x = max(bcmin, demin)
y = min(bcmax, demax)
a = SelectEvery(2, -2)
f = SelectEvery(2, 3)
Interleave(a, x, y, f).Clense(grey=true).SelectEvery(4, 1, 2)
trim(0,length=src.framecount())
}

[Boulder]

Thanks for those, I'll test them and replace the old ones if they are indeed faster :) The old ones have sometimes been posted here on this forum and I've borrowed them as a small pre-cleaner function to the MC'd denoiser.

[Boulder]

Flux5FramesT needed just the line "chromamotion = default(chromamotion, true)" so I added that one since I very rarely disable chroma motion detection.

However, the initial problem still remains, a test with AVSMeter stalls the process at some point. I'm also getting CPU usage below 25% (1 core) even with four threads, maybe that's something to look at (caching again?)

[jones1913]

I've been testing with AVS+/MT mode w/QTGMC. So far, I haven't checked numbers against SETs 2.6RC1, but fwiw, in 64bit version, AVS+ will complete an encode that fails with the older (JoshyD?) 64-bit build.

Have you tried yet? If so, what kind of numbers do you see?

Do you mean that you run QTGMC with 64 bit AVS? Until now I assumed that not all needed plugins are available as 64 bit version.

Here are my results with QTGMC in MT mode on AMD FX 8320 (8 core):

AVS 2.6:
SetMTMode(3, 4)
LWLibavVideoSource("sample.m2v")
SetMTMode(2)
QTGMC(Preset="Medium")
SelectEven()
Distributor()

AVSMeter 1.9.8.0 (x86)
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)
Active MT Mode: 2

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): 5.680 | 91306 | 43.94
Memory usage (phys | virt): 585 | 604 MB
Thread count: 65
CPU usage (average): 74%

Time (elapsed): 00:00:39.919

AVS+:
SetFilterMTMode("DEFAULT_MT_MODE",2)
LWLibavVideoSource("sample.m2v")
QTGMC(Preset="Medium")
SelectEven()
Prefetch(4)

AVSMeter 1.9.8.0 (x86)
AviSynth+ 0.1 (r1779, MT, i386) (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): 3.676 | 114785 | 33.88
Memory usage (phys | virt): 398 | 414 MB
Thread count: 104
CPU usage (average): 56%

Time (elapsed): 00:00:51.768

[Stereodude]

Do you mean that you run QTGMC with 64 bit AVS? Until now I assumed that not all needed plugins are available as 64 bit version.
I've got it working several years ago with AVIsynth x64. I don't recall it being much faster in 64-bit though. It was a giant pain to find x64 versions of all the plugins.

[noee]

I've got it working several years ago with AVIsynth x64. I don't recall it being much faster in 64-bit though. It was a giant pain to find x64 versions of all the plugins.

Yes, that seems to be the case. My scripts with QTGMC are quite simple and when it would work in 64bit, it was about 3% faster than 32bit MT (SET).

[Groucho2004]

Distributor()

Don't put that in the script unless you specified "InvokeDistributor=0" in AVSMeter.ini.
That goes for pretty much every application that uses AVISynth(MT) except ffdshow and some piping tools that don't call Distributor() internally.

[jones1913]

Don't put that in the script unless you specified "InvokeDistributor=0" in AVSMeter.ini.
I have indeed set "InvokeDistributor=0" because initially I had some problems get this to run with AVS+, so I tried several things.

That goes for pretty much every application that uses AVISynth(MT) except ffdshow and some piping tools that don't call Distributor() internally.
OK I didn't know that, thanks.

[chainik_svp]

Here are my results with QTGMC in MT mode on AMD FX 8320 (8 core):

1. You need to set SetFilterMTMode("LWLibavVideoSource",3)

2. If you want to compare performance do it either in singe-threaded mode or with maximum CPU load (with 9+ threads). Your comparsion with 4 threads on 8-threads CPU shows nothing.

[Groucho2004]

I have indeed set "InvokeDistributor=0" because initially I had some problems get this to run with AVS+, so I tried several things.
FYI - The "InvokeDistributor()" setting is ignored in all Avisynth versions that don't implement "Distributor()".

[Groucho2004]

2. If you want to compare performance do it either in singe-threaded mode or with maximum CPU load (with 9+ threads). Your comparsion with 4 threads on 8-threads CPU shows nothing.
He used 4 threads in both cases, I don't see anything wrong with that.
Maximum CPU load or CPU load in general means very little. The most sensible thing would be to put CPU load and processing time in relation and compare that.

[chainik_svp]

Because AVS and AVS+ have completely different thread schedulers and "4" is not a "number of threads" but just one of input parameters to the scheduler. For AVS+ official point of view is given in the function name "Prefetch" - "4" is number of frames calculated in advance. Which is also not true :D.

Those numbers can only be compared after normalization to 100% CPU load.
AVS: 43.94 fps / 74% CPU load = 59.38 fps
AVS+: 33.88 fps / 56% CPU load = 60.05 fps

But such estimation gives too much error value.

[jones1913]

1. You need to set SetFilterMTMode("LWLibavVideoSource",3)
You're right, I wrongly assumed that the LWLibav filter is already specified in avs_plus_mt_modes.avsi file.
Though that has only a small effect on the result:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
LWLibavVideoSource("sample.m2v")
QTGMC(Preset="Medium")
SelectEven()
Prefetch(4)

AVSMeter 1.9.8.0 (x86)
AviSynth+ 0.1 (r1779, MT, i386) (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): 3.741 | 121742 | 35.30
Memory usage (phys | virt): 350 | 366 MB
Thread count: 68
CPU usage (average): 55%

Time (elapsed): 00:00:49.690

2. If you want to compare performance do it either in singe-threaded mode or with maximum CPU load (with 9+ threads). Your comparsion with 4 threads on 8-threads CPU shows nothing.
Well, "shows nothing" is maybe a little exaggerated. Also I have never stated to perform an absolute valid and technical perfect test.
Anyway I repeated the test with your suggestions:
SetMTMode(3, 10)
LWLibavVideoSource("sample.m2v")
SetMTMode(2)
QTGMC(Preset="Medium")
SelectEven()

AVSMeter 1.9.8.0 (x86)
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)
Active MT Mode: 2

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): 3.636 | 167395 | 54.97
Memory usage (phys | virt): 634 | 674 MB
Thread count: 107
CPU usage (average): 96%

Time (elapsed): 00:00:31.906
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
LWLibavVideoSource("sample.m2v")
QTGMC(Preset="Medium")
SelectEven()
Prefetch(10)

AVSMeter 1.9.8.0 (x86)
AviSynth+ 0.1 (r1779, MT, i386) (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): 2.018 | 87337 | 48.62
Memory usage (phys | virt): 703 | 731 MB
Thread count: 123
CPU usage (average): 96%

Time (elapsed): 00:00:36.077
The gap becomes smaller, but the tendency remains the same.

Because AVS and AVS+ have completely different thread schedulers and "4" is not a "number of threads" but just one of input parameters to the scheduler. For AVS+ official point of view is given in the function name "Prefetch" - "4" is number of frames calculated in advance. Which is also not true .

Those numbers can only be compared after normalization to 100% CPU load.
AVS: 43.94 fps / 74% CPU load = 59.38 fps
AVS+: 33.88 fps / 56% CPU load = 60.05 fps

But such estimation gives too much error value.
You posted this while I typed my above text and I have no idea if my results are meaningful, but I'll leave it as it is now...

[Groucho2004]

Because AVS and AVS+ have completely different thread schedulers and "4" is not a "number of threads" but just one of input parameters to the scheduler. For AVS+ official point of view is given in the function name "Prefetch" - "4" is number of frames calculated in advance. Which is also not true

You enable MT by placing a single call to Prefetch(X) at the *end* of your script, where X is the number of threads to use.
Hm. So, ultim's explanation of "prefetch" is wrong in this post?

[martin53]

so you are writing your own avisynth plugin (cool!), and obviously one of the first things you have to do in your code is to include the avisynth header. But which one? ...
what about avisynth+'s header?
the headers of avisynth+ (https://github.com/avisynth/avisynthplus/tree/mt/avs_core/include) are up to date in every aspect and provide the greatest possible compatibility. By using avisynth+'s headers, applications and plugins can cleanly compile and run in 32-bits and 64-bits. It is 100% compatible to the latest 32-bit development on the old avisynth 2.6 project, while supporting all 64-bit binaries. And of course, you can use it regardless if you support multithreading or not. Furthermore and importantly, it is fully compatible to installations of the avisynth 2.6, avisynth-mt, avisynth64, and of course the avisynth+ projects, so your plugin/application will be able to run on any user's machine.

I'm sure there is reason in the things explained in that post, but:
Avisynth+'s header includes <avs/config.h>, <avs/capi.h> and <avs/types.h> which in turn include <avs/cpuid.h> and so on.
I feel this is not plugin writer friendly.
#include <...> in contrast to #include "..." makes success with the Filter SDK compiling instructions (http://avisynth.nl/index.php/Filter_SDK/Compiling_instructions) harder because it requires to further extend the standard library directories settings in the compiler.
Though I think I'd personally be able to manage that, and the files are on GitHub (easy to download), I still feel it's complicated and should not be like that. At quick glance I couldn't find what happened to the GetVarDef function in the avisynth+ header, either, so I'll preliminarily stick to the standard Avisynth 2.6 one.

[chainik_svp]

Hm. So, ultim's explanation of "prefetch" is wrong in this post?

I'm just saying "4 threads" in AVS are different from "4 threads" in AVS+. Performance of AVS and AVS+ can't be compared in that way.
So there're only two reliable ways for comparsion: single thread performance and full system performance with 100% load.

[chainik_svp]

Well, "shows nothing" is maybe a little exaggerated. Also I have never stated to perform an absolute valid and technical perfect test.
Anyway I repeated the test with your suggestions:

yeah, and now it IS interesting :) thanks, I think now I should test the performance myself... (for the SVP usage :))

[qyot27]

I'm sure there is reason in the things explained in that post, but:
Avisynth+'s header includes <avs/config.h>, <avs/capi.h> and <avs/types.h> which in turn include <avs/cpuid.h> and so on.
I feel this is not plugin writer friendly.
#include <...> in contrast to #include "..." makes success with the Filter SDK compiling instructions (http://avisynth.nl/index.php/Filter_SDK/Compiling_instructions) harder because it requires to further extend the standard library directories settings in the compiler.
Though I think I'd personally be able to manage that, and the files are on GitHub (easy to download), I still feel it's complicated and should not be like that.
https://github.com/AviSynth/AviSynthPlus/pull/54

At quick glance I couldn't find what happened to the GetVarDef function in the avisynth+ header, either, so I'll preliminarily stick to the standard Avisynth 2.6 one.
From https://github.com/AviSynth/AviSynthPlus/pull/53:

partial-2 GetVarDef is one of a group of several similar functions that seem to be gone in
avsplus, so don't bother with it.

[ultim]

Hm. So, ultim's explanation of "prefetch" is wrong in this post?

Actually, yes that was a superficial explanation from me. More accurately, Prefetch(X) sets the number of prefetching threads, not the total number of threads.

[ultim]

AVS+ has a new caching architecture that is still being tuned and optimized, and many internal filters have also been rewritten from scratch. Currently, depending on your script, performance can be both above and below of AVS2.6, but in my observations the negative differences (where it's slower) are a lot smaller than the positive ones where AVS+ is faster. Using purely external filter, Avs-MT is still a bit faster ATM, but unlike AVS-MT, AVS+ is not bound by 2.6's implementation so it can be changed (and possibly optimized) over time to a larger extent. And of course it also has a lot of other improvements and functional additions.

[jones1913]

Just for the notes, it was not my intention to imply a weakness of AVS+.
I only shared my results with my setup, no more and no less.

Any further development is much appreciated and I am looking forward to the future of this project.:thanks:

[mark0077]

yeah, and now it IS interesting :) thanks, I think now I should test the performance myself... (for the SVP usage :))

Chainik, Have you had any luck with getting a number of SVP cores, ffdshow buffer ahead, and avisynth+ prefetch values, that outperforms avisynth MT. If so would you mind sharing. Id be interested in trying them as my current settings seem alot slower than avisynth MT. (15 for all 3 values)

[raffriff42]

Are you aware that this code:return BlankClip(color=color_red)does not work in Avisynth+ ("I don't know what 'color_red' means") because no shared function (http://avisynth.nl/index.php/AviSynth%2B#Notes) has been called (thus not loading colors_rgb.avsi)? I have a lot of 'legacy' code that requires certain auto-loaded global variables [eg plugins not auto-loaded)]. As a workaround I will add an Include("<full path>\_global.avsi") statement at the top of all my scripts.

(edit AviSynth+ 0.1 stable (r1576), 32-bit)

[aegisofrime]

Hi ultim!

Running the R1779 build I notice that I have been getting a few encoding jobs crashing due to a "STATUS ACCESS VIOLATION" (as reported in the log of MeGUI) which I never have had in the last stable build. Have you experienced any such crashes yourself?

[colours]

"Access violation" is a very generic descriptor and it'd help if you could post your full script as well as whether you're using 32-bit or 64-bit Avisynth+.

[aegisofrime]

"Access violation" is a very generic descriptor and it'd help if you could post your full script as well as whether you're using 32-bit or 64-bit Avisynth+.

Sure!

Here's my script:


LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("K:\Working\Source.dgi",fieldop=0)
QTGMC(Preset="Very Slow")


The source is a 1080i video, so I guess this script is quite intensive to QTGMC.

I'm using 32-bit AVS+. I'm planning to move to 64-bit but I'm having trouble finding MeGUI 64-bit.

[zerowalker]

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?

[Evil_Burrito]

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.

[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

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

[videoh]

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. You are misusing the DG tools and then claiming they are not working! All the DG tools demux with the required delay adjustment in the audio file name. You must adjust for that delay in your script. If you can demonstrate a real problem when using the tools as intended, then I will be happy to look into it.

[StainlessS]

Stax

### Filled in by DGIndex when using as DGIndex Template
VideoFileName ="__vid__"
AudioFileName =("__aud__")
AudioDelay =Value("__del__")

Dont off hand know if DGxxxx command line allows for template, but above via DGIndex works great (as well as delay in filename as VH suggests).

[stax76]

You are misusing the DG tools and then claiming they are not working! All the DG tools demux with the required delay adjustment in the audio file name. You must adjust for that delay in your script. If you can demonstrate a real problem when using the tools as intended, then I will be happy to look into it.

I double checked it and the file is very simple, I have a very fast connection and could easily upload it but DGAVCIndex is discontinued, right? Would you be willing to fix it? If you want I can also try with DGDecNV and tell you if it works better.

[videoh]

You double-checked what? Please upload your file so I can test it. Thank you.

And you say DGSource() may also cause problems. What problems?

[stax76]

You double-checked what? Please upload your file so I can test it. Thank you.

I tested it two times, it's really not working, here is the log:

http://pastebin.com/TepyAc3G

What's StaxRip does here is just muxing without any encoding and as you can see the delay is accounted in the mkvmerge command line.

I can upload the file no problem but for what do you need it? DGAVCDec is discontinued, right?

And you say DGSource() may also cause problems. What problems?

Problems with QTGMC, so far I'm only observing the topic and collect info.

[videoh]

Please upload the file. I need it to check your claim that one of my tools is failing. I also want to test it against DGDecNV and DGDecIM. Most of the code is the same. Sure, DGAVCDec may be faulty and won't be updated. But I need to check that my other tools are not affected the same way. I helped you with the progress reporting technology, can't you help me by uploading the file?

Problems with QTGMC, so far I'm only observing the topic and collect info. What problems with QTMC, and what is the connection to DGSource()? And if you are only observing and collecting info, why be in such a hurry to blame DGSource()? Why not list every tool used by QTGMC and say they may have problems?

[stax76]

Please upload the file. I need it to check your claim that one of my tools is failing. I also want to test it against DGDecNV and DGDecIM. Most of the code is the same. Sure, DGAVCDec may be faulty and won't be updated. But I need to check that my other tools are not affected the same way.

What problems with QTMC, and what is the connection to DGSource()? And if you are only observing and collecting info, why be in such a hurry to blame DGSource()? Why not list every tool used by QTGMC and say they may have problems?

Yes, it's async with DGDecNV as well but I'm not helping you if you be difficult like that all the time, I rather avoid mentioning DG tools and be super extra careful if I have to.

[videoh]

I think you are overreacting, but have it your way.

Have you tried reversing the sign on your --sync parameter? It may not work the same as DelayAudio(). I could troubleshoot it if I had your file. All DG tools users would potentially benefit.

Good luck with your projects, and if you ever want me to look into your issues, just let me know.

[l33tmeatwad]

...but I'm not helping you if you be difficult like that all the time...I hate to break it to you...but you're actually the one that's being difficult...if you want things fixed work with people or fix it yourself.

[StainlessS]

I hate to break it to you...but

That is how it seemed to me too.

[jpsdr]

I can upload the file no problem...
In that case just do it, videoh even asked for it. You've nothing to loose.

[stax76]

random DVB recording I recorded for testing purpose.

KabelBW, Germany, DVBViewer, ZDF HD, TS, AVC, MP2, 720p, 50fps

http://www.mediafire.com/download/wxi04urz0p1lte7/720p_-_AVC_-_MP2_2.0_-_ZDF_HD.ts

General

ID : 1079
Audio_Codec_List : MPEG-1 Audio layer 2
Audio_Language_List : German
Codec/String : MPEG-TS
FileSize/String4 : 676.7 MiB
Duration/String1 : 7mn 29s 961ms
OverallBitRate/String : 12.6 Mbps
FrameRate/String : 50.000 fps
FrameCount : 22481
StreamSize/String : 34.4 MiB (5%)
File_Created_Date_Local : 2012-02-05 14:35:16.103
File_Modified_Date_Local : 2010-09-27 11:07:12.806

Video

ID : 6110
Format_Profile : Main@L4
Codec/String : AVC
Duration/String1 : 7mn 29s 620ms
BitRate_Mode : VBR
BitRate/String : 11.7 Mbps
Width/String : 1 280 pixels
Height/String : 720 pixels
PixelAspectRatio : 1.000
DisplayAspectRatio/String : 16:9
FrameRate/String : 50.000 fps
FrameCount : 22481
Resolution/String : 8 bits
ScanType : Progressive
StreamSize/String : 629 MiB (93%)

Audio

ID : 6120
Format_Profile : Layer 2
Codec/String : MPEG-1 Audio layer 2
Duration/String1 : 7mn 29s 856ms
BitRate_Mode : CBR
BitRate/String : 256 Kbps
Channel(s)/String : 2 channels
SamplingRate/String : 48.0 KHz
FrameCount : 18744
Compression_Mode : Lossy
Video_Delay : -1053
StreamSize/String : 13.7 MiB (2%)
Language/String : German

Menu

ID : 6100
Codec/String : AVC / MPA1L2 / / / / /
Duration/String1 : 7mn 29s 961ms
Language/String : / German

[videoh]

Thank you. Investigating...

[videoh]

OK, I tested DGDecNV because you said that is not working for you also. I find that it is operating correctly as designed. To show this, I loaded your file and saved project. Then I made this script:

loadplugin("dgdecodenv.dll")
loadplugin("nicaudio.dll")
vid=dgsource("720p - AVC - MP2 2.0 - ZDF HD.dgi")
aud=nicmpg123source("720p - AVC - MP2 2.0 - ZDF HD PID 17e8 L2 2ch 48 256 DELAY -1444ms.mp2").delayaudio(-1.444)
audiodub(vid,aud)

Playing the script in VirtualDub, everything is in sync, showing that DGDecNV is operating correctly as designed.

I also did it by first demuxing the 264 ES using DGIndexNV and then did the above but starting with the demuxed file. The result was the same, ie., in sync.

Then I used mkvtoolnix to mux the 264 ES and the audio, specifying the delay adjustment with --sync. The result was out of sync. I also did a delay cut edit of the audio and then made the MKV again but without --sync. The result was again out of sync.

So the question is why are things out of sync in the MKV? The answer is that there are a lot of leading non-IDR/I frames before the first IDR/I (your stream was not cut at a GOP). DGDecNV is designed to replace those frames with copies of the first IDR/I frame, and the audio is demuxed starting from the beginning. But mkvtoolnix discards all those frames and that is what leads to async.

Every demuxer has to align the starts of the audio and video *as the demuxer sees things*. Other demuxers may discard the leading frames and start the audio demux later at the first I frame. DGDecNV, however, tries to retain all the frames, so it starts the audio demux much earlier.

If we had to assign "blame" anywhere, it is in the assumptions of your workflow, which are incorrect. By using DGDecNV demuxing you are committing to using a muxer that retains all the leading non-IDR/I frames, but the muxer you chose does not do so. For your workflow, a demuxer like eac3to would be suitable.

Conclusion: DGDecNV is operating correctly as designed. Your hybrid workflow makes incorrect assumptions, so DGDecNV demuxing is not suitable for your workflow, but it is not broken. I would respectfully ask you not to jump to conclusions and say some tool is a failure, before consulting with the developer. That is surely what you expect from staxrip users, isn't it?

[manolito]

Interesting source file...
I do not do many HD conversions (oldfashioned DVD guy), but opening HD sources happens frequently, so I played a little with this source:

First of all I ran the file through TSDoctor, but this had no influence at all for the sync issue. The processed file had a slightly shorter audio delay (1005ms instead of 1053ms), and it was significantly shorter than the original. But it did not solve the sync issues.

Trying a conversion to DVD I first opened the video with ffvideosource (audio through DirectShowSource). I had to use the old version 2.17 because all later versions do not run on my machine (SSE2 problem). Result: Terrible audio desync.


Next I used DSS2Mod for video (preroll = 15, otherwise default settings). LAVFilters 0.65 were used.

Result:
When the reported audio delay of 1053ms was corrected, the result was out of sync. But when I ignored the audio delay, I got a perfect conversion without any sync problems. (The TSDoctor processed file gave the same result).

This confirmed my previous experience with the DSS2Mod / LAVFilters combination. Whenever MediaInfo reports an audio delay greater than 100ms, just ignore it and get a perfect result.


Just for fun I then processed the file with the old StaxRip version 1.1.9.0. StaxRip automatically selected DirectShowSource as the source filter (LAVFilters were installed), and I got a resulting file which was in perfect sync.


Cheers
manolito

[videoh]

Thanks, manolito, for the input on this. You have underlined the point that tools must be combined in the right way, taking into account their specific designs and behavior. One can't assume that any combination of tools will do what one wants, and one can't call them broken because one makes an incorrect assumption about how they operate.

So the idea that staxrip can just allow free choice of source filters, etc., without regard to how they are combined is asking for trouble.

[manolito]

Thanks videoh for explaining how your source filters work differently than other source filters.

I noticed this whenever I converted a DVD (or MPEG2) source. AVStoDVD gives me a choice in these cases to either use DGIndex / DGDecode or to use DSS (or DSS2Mod or whatever). When I use DGIndex, I need to honor the reported audio delay even if it is very large. For DSS2Mod I always have to discard large delay values.

So far I had no explanation for this behavior, but now I do... :D


Cheers
manolito

[videoh]

An aside on why DGDecNV does things this way. Suppose you have a stream with a bunch of leading B frames. If you discard them, you have to discard audio too. But what if it's a song or a narration...you don't want to truncate the audio at the beginning. The philosophy is to deliver an output frame for all coded input frames. It just seems like the right thing to do if you want to claim frame accuracy. The user asks for frame N; he shouldn't have to adjust the number depending on how many leading B frames there are. Well, that's my take on things.

I suppose that is why CUVID and MSDK also deliver an output frame for all coded frames, regardless of frame type. That way there is also no need to coordinate with the audio. E.g., how could CUVID signal that is dropping some leading frames or not?

I had to jump through hoops when making DGAVCDec to work around the fact that libav was discarding leading B frames. That's one reason why I decided to stop using libav.

[qyot27]

Trying a conversion to DVD I first opened the video with ffvideosource (audio through DirectShowSource). I had to use the old version 2.17 because all later versions do not run on my machine (SSE2 problem). Result: Terrible audio desync.
Not that it would necessarily do anything to the desync issue, but the C-plugin builds are more lax about this (http://forum.doom9.org/showthread.php?p=1720384#post1720384).

[manolito]

Thanks qyot27 for this reminder, I do know this...

Doesn't help me though because I mainly use AVStoDVD for my encodes, and the LoadPlugin call for ffms2.dll is hard coded into the executable. Not much I can do about it except compiling my own version of AVStoDVD...


Cheers
manolito

[stax76]

the fps drop issue with MT seem to happen only with certain filters, I was successful with this:

DGDource
QTGMC
Prefetch
SelectEven

but as soon as I added crop after DGDource the fps drop issue was back, I tried HW cropping then and again fps drop was happening, unfortunately many popular scripts are not usable at the moment, makes me wonder if QTGMC works better with VapourSynth, adding basic support to StaxRip might be easy.

[chainik_svp]

Please update avisynth.h header accordingly to AVS 2.6 final release!
Restore GPL exemption.
;)

[innocenat]

@chainik_svp: https://github.com/AviSynth/AviSynthPlus/issues/62

[LigH]

Today I tried to play an AviSynth file with a fresh built ffplay, and it complains:

[avisynth @ 00000000030c6f80] AviSynth version is too old. Please upgrade to either AviSynth 2.6 >= RC1 or AviSynth+ >= r1718.

The homepage and the github releases only offer AviSynth+ r1576; so where do I get AviSynth+ r1718 or newer from?!

And on top, will AviSynth+ MT be continued?

[thescrapyard]

Here is the installer for r1779, I'm still hunting for r1825 or r1833

http://www.mediafire.com/download/wiwhhbtd3bcqcox/AviSynth%2B_v0.1.0_r1779.exe


Found it after a few more minutes of hunting and trawling through StaxRip forums topics as he uses AviSynth+ as well

http://www.mediafire.com/download/hvnjb8wy54ys7gl/AviSynth%2B_v0.1.0_r1825-MT.exe


Both links confimed working, as I've just downloaded both

[LigH]

:thanks: a lot!

Now ffplay works well; and by the way, this issue happened with a 64 bit ffplay, so no surprise it didn't work with AviSynth 2.60 final either ... which is 32-bit only :o

[thescrapyard]

This might help others, like me, that use AviSynth+ about development and appearing to have stalled and the current release state

Basically it hasn't stopped, more like idling and does get minor updates as and when needed with the main developer working on the core when he has time. Which apparently may be very little for 'side projects'

https://www.doom9.org/showthread.php?p=1719763#post1719763

[qyot27]

And on top, will AviSynth+ MT be continued?
There is no division there like there is for classic AviSynth; the MT branch has been the main branch of AviSynth+ for nearly a year and a half (the length is mostly because of the hiatus that was in there; we're currently in kind of another one after a rather busy March). MT is the Git HEAD branch.

In the event that 0.2 stable is released sometime soon, it will be MT capable (even if the 'stable' tag would mostly be referring to the single-threaded mode). Whenever that happens, the message in libavformat will get modified to reflect a point release rather than a development revision number.

For quick reference,
r1718 was the update against 2.6 RC1 (and technically would be r1723 or thereabouts if checked out from Git; some of the changes were uncommitted at the time I made that build)
r1825 is the current Git HEAD.
r1833/r1834 (which exists in a still-unmerged pull request) is the extremely-paltry update against RC2. RC3's changes were completely irrelevant to AviSynth+. r1834 adds the exception clause back to avisynth.h and is thus updated against 2.6.0 Final, but as the issue innocenat linked to shows, there's still some pondering about whether that's do-able with the changes already made to avsplus during the 2.6 alpha period.


ffplay isn't really a good way of previewing scripts, because it's more of a test bed for the FFmpeg libraries than a canonical media player. mpv is vastly preferable here. Someone might want to bug the VLC devs to expose AviSynth support through libavformat, since it currently doesn't (or didn't, at least the last time I checked).

[LigH]

Thank you for the summary.

Using ffplay was in fact rather a test if ffmpeg based tools can be used at all; but I will recommend mpv as alternative now, even though I don't always build it, it used to fail compiling often in the past.

[vcmohan]

on my lap top windows 8.1 64 bit quad core, installed from home page avisynth+. Compiled plugins in 64 bit mode using VC++ community edition 2013. With loadplugin("....") call get message unable to load. If I paste the plugin dll in avisynth64+ plugins folder, get a message of no such function. Earlier I had 2.6 and opted for upgrade. Both 32bit and 64bit check boxes were ticked. Regular 32 bit plugins compiled for avisynth2.6 are being loaded. In the installation log I see the avissynth.dll (almost an year older to avisynth2.6) is installed. I also see in the wow64bit folder also a avisynth.dll.
In the documentation I do not see any help for using setFilterMtMode or prefetch.Do I need to do any thing else to be able to load 64 bit plugins compiled using the recommended header file for avisynth+?

[LigH]

You'll have to call the AviSynth script directly from a 64 bit application to load 64 bit AviSynth+ to load 64 bit plugins.

Try it first with AVSMeter64.exe – when it passes the analysis and starts processing frames, it worked.

[Reel.Deel]

@vcmohan

You can also try 64-bit VirtualDub (http://www.videohelp.com/software/virtualdub). You might want to upgrade to the latest AviSynth+ (r1825) (http://avisynth.nl/index.php/AviSynth%2B#Latest_Release) also.

The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes

[vcmohan]

@vcmohan
The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes
Many thanks. I did not understand clearly the following.
Per-frame heap allocations should be avoided, because they can act as implicit synchronization points between threads.
Can I use in getFrame method say float * var = new float[vi.width*vi.height]; and at end of this getFrame method use a delete []var; ? Does this cause the implicit synchronization? If so what should I do to have a writable buffer in getFrame section?

[innocenat]

If you don't care about original Avisynth support, current Avisynth has IScriptEnv2.Allocate (just cast from your original IScriptEnv), which you should use with mode AVS_POOLED_ALLOC. But I don't know whether this solve the implicit synchronization, nor whether this API is stable. It is being used by internal filter though: https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/resample.cpp#L755

[8-BaLL]

What is more stable/powerful at the moment AVS+ or AVS 2.6 final? Which one do you guys prefer atm?

[Groucho2004]

What is more stable/powerful at the moment AVS+ or AVS 2.6 final? Which one do you guys prefer atm?
You're going to get variety of opinions with this kind of question. I'd say use AVS 2.6 for serious work. The current AVS+ builds are really in Alpha stage and I've had problems with them, especially using complex scripts like QTGMC.

[stax76]

You're going to get variety of opinions with this kind of question. I'd say use AVS 2.6 for serious work. The current AVS+ builds are really in Alpha stage and I've had problems with them, especially using complex scripts like QTGMC.

MT is alpha I agree but single threaded works completely fine in my experience.

[Groucho2004]

MT is alpha I agree but single threaded works completely fine in my experience.
In my tests the 32 bit r1825 (have not tested 64 bit) slows down continuously with QTGMC, no matter if single threaded or multi threaded.
There is something odd with the memory management in the newer builds, they use much less memory than r1576 or 2.6 but it seems that this is exactly what causes the slowdown. Just a hunch.

[8-BaLL]

Alright thanks, I guess I will just keep using 2.6 then.

[vcmohan]

@vcmohan

You can also try 64-bit VirtualDub (http://www.videohelp.com/software/virtualdub). You might want to upgrade to the latest AviSynth+ (r1825) (http://avisynth.nl/index.php/AviSynth%2B#Latest_Release) also.

The documentation for SetFilterMTMode and Prefetch is here: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes
I have virtualdub 64 bit version. With version() call I get a message AVISYNTH+ 0.1 (r1576 x64)
I thought home page installer puts the latest dll.
However with SetFilterMTMode("..", 1)
I get a message no function named setFilterMTMode
The script I am using is:
loadplugin("C:\TransPlugins\bin_64\HistogramAdjust\x64\Release\HistogramAdjust.dll")
#----------------------------------------

SetFilterMTMode("HistogramAdjust",1)
imagesource("c:\images\source1_z.jpg",end = 500)

converttoyV12()
HistogramAdjust(limit = 70)
prefetch(6)
what is the problem?

[foxyshadis]

Try a script with nothing but
Version()
and see what that gives.

[Groucho2004]

I have virtualdub 64 bit version. With version() call I get a message AVISYNTH+ 0.1 (r1576 x64)
I thought home page installer puts the latest dll.
However with SetFilterMTMode("..", 1)
I get a message no function named setFilterMTMode
The script I am using is:
loadplugin("C:\TransPlugins\bin_64\HistogramAdjust\x64\Release\HistogramAdjust.dll")
#----------------------------------------

SetFilterMTMode("HistogramAdjust",1)
imagesource("c:\images\source1_z.jpg",end = 500)

converttoyV12()
HistogramAdjust(limit = 70)
prefetch(6)
what is the problem?
The installer from avs-plus.net installs the latest stable (r1576) which does not support MT.
A link to the r1825 binaries is here (http://forum.doom9.org/showthread.php?p=1719768#post1719768).

[goorawin]

I have just started using the latest version Avisynth+ (r1825) and seems to be working reasonable well and quicker in some situations where 64bit can be used. Looks very promising, so great work by those who have developed it to this stage.
The version I have found to work really well for almost everything is 2.6 MT but it is only 32bit.
However although I can get many scripts that work in 2.6 MT to work in plus, I can not get the following script to work at all. So I'm hoping someone can help. I use this script a lot in batch encoding and it should allow VirtualDub 64 bit to be used for that.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("FFVideoSource", 3)
LoadVirtualDubPlugin ("C:\Virtual Dub\plugins32\Deshaker.vdf", "deshaker", preroll=0)Clip="D:\Batch Script Render\Iutput Files\Test.mts"
V1=FFVideoSource(Clip)
A1=FFAudioSource(Clip,track = -1)
AudioDub(V1, A1)#.AdvancedMultiTrim("0,-25")
ConvertToRGB32()
SCRIPT_1=Deshaker("19|1|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
ForceProcess(SCRIPT_1)
SCRIPT_1 = 0
SCRIPT_2=ConvertToRGB32(matrix="Rec709").Deshaker("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
\.ConvertToYUY2() # I can add other plugins here


return SCRIPT_2

Function ForceProcess(clip c) {
# Force process c clip
RT_DebugF("Starting Force process of clip") # EDIT: Output to DebugView (google)
GScript("""
for(i=0,c.FrameCount-1) {
RT_YankChain(c,i)
}
""")
}

This line SCRIPT_1=Deshaker .......... causes "system exception- access violation"

Any suggestion to get this to work in Avisynth + would be very much appreciated.
Thanks

[qyot27]

Does 64-bit VirtualDub load 64-bit plugins from plugins64? Because you're pointing to the Deshaker plugin in plugins32.

Also, GScript's extensions were integrated into AviSynth+; you can just use those features natively now.

[goorawin]

I am trying to use virtualdub 32bit to get it to work. I'm testing it on Avspmod, which only handles 32bit. I did try to load it direct into ffmpeg but that failed as well.
It is the first deshaker pass that fails to load.
I'll look at the Gscript issue later, but that shouldn't cause any of these issues.
I have also tried loading just the first pass which works in 2.6.
Thanks for your input

[bxyhxyh]

Deshaker plugin is not really compatible with MT avisynth. It is also internally multi-threaded. This maybe the case. Have you tried single threaded settings (if is there exist)?

[goorawin]

Well it may not be compatible with MT but I have been using it now for a year or more with 2.6 MT.
It took many days to set it up so it would work and it renders quicker than a single thread setup.
This is an example of the script I use.
SetMemoryMax(512)
Setmtmode(5,4)
LoadVirtualDubPlugin ("C:\Virtual Dub\plugins32\Deshaker.vdf", "deshaker", preroll=0)Clip="G:\Africa\Wilds\Final Edit\Part02\199.mts"
V1=avss_26_DSS2(Clip, fps = 50)
A1=FFAudioSource(Clip,track = -1)
AudioDub(V1, A1).AdvancedMultiTrim("0,-25")
Setmtmode(2)
SCRIPT_1=ConvertToRGB32(matrix="Rec709").Deshaker("19|1|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
ForceProcess(SCRIPT_1)
SCRIPT_1 = 0
Setmtmode(2)
SCRIPT_2=ConvertToRGB32(matrix="Rec709").Deshaker("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|1000|1000|4|1|4|2|8|30|300|4|C:\\Users\\Peter\\AppData\\Local\\Deshaker\\Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|8|8|3|8|0|0|30|30|0|0|1|0|1|1|0|10|1000|1|90|1|1|20|5000|100|20|1|0|ff00ff")
\.ConvertToYV12()
\.MTClipEnhance(levels=245, gamma=1.05, WB=0.20, saturation=1.20, Hue1=-2,Hue2=1)

return SCRIPT_2

Function ForceProcess(clip c) {
# Force process c clip
RT_DebugF("Starting Force process of clip") # EDIT: Output to DebugView (google)
GScript("""
for(i=0,c.FrameCount-1) {
RT_YankChain(c,i)
}
""")
}

The MTClipEnhance also has a Setmtmode within it.
I would just like to be able to use it within Avisynth + . This would save the need for changing versions and hopefully we could get a further increase in rendering speed.

[goorawin]

I forgot to mention that yes I did try, as best as I could, a single threaded settings.

[RenderGuy2]

This may already be known and deemed unimportant as ffdshow is no longer being developed, but I have noticed that r1825 is not available to ffdshow rev4533 x64. Avisynth+ r1779 works as it should with ffdshow. Scripts added to ffdshow with r1825 simply have no effect.

[ianken]

Any idea when there will be a new release with installer? Makes deployment a bit easier.

[sl1pkn07]

http://avisynth.nl/index.php/AviSynth%2B#Latest_Release (?)

[vcmohan]

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).
I have been using vs2013 community edition and compiled several avs+ plugins in 64 bit. I did not notice that the 2013 community edition was a one month trial edition and I need to pay over $6800 to continue working. This amount I can not afford. So far whichever plugins are compiled are at my down load page. In future I will switch back to 2010 edition possibly.

[Sparktank]

I have been using vs2013 community edition and compiled several avs+ plugins in 64 bit. I did not notice that the 2013 community edition was a one month trial edition and I need to pay over $6800 to continue working. This amount I can not afford. So far whichever plugins are compiled are at my down load page. In future I will switch back to 2010 edition possibly.

Users in the comment section (bottom of page) have said to just sign-in again into your Micro$oft account and ignore any promotions. After that, you're good to go again for another year or so without hassle.
http://blogs.msdn.com/b/quick_thoughts/archive/2014/11/12/visual-studio-community-2013-free.aspx

[MysteryX]

Any idea when will be the next release of the MT version? The latest release doesn't sync audio and video when playing videos with SVP, and crashes with NNEDI3. Apparently there is a somewhat stable version but it's not yet public.

[Groucho2004]

In my tests the 32 bit r1825 (have not tested 64 bit) slows down continuously with QTGMC, no matter if single threaded or multi threaded.
There is something odd with the memory management in the newer builds, they use much less memory than r1576 or 2.6 but it seems that this is exactly what causes the slowdown. Just a hunch.
Importing the AVSMeter performance data into a spread sheet program shows the issue with r1825 slowing down continuously quite nicely.

Script:
SetMemoryMax(1024)
LWLibavVideoSource("src\test.m2v")
AssumeTFF()
QTGMC(Preset="slow")


Result with r1576 x86:
http://s1.postimg.org/c20lkxnof/1576.png

Result with r1825 x86:
http://s7.postimg.org/s1hv5tyob/1825.png

[vcmohan]

Users in the comment section (bottom of page) have said to just sign-in again into your Micro$oft account and ignore any promotions. After that, you're good to go again for another year or so without hassle.
http://blogs.msdn.com/b/quick_thoughts/archive/2014/11/12/visual-studio-community-2013-free.aspx

thanks.

[stax76]

@Groucho2004

I didn't know r1576 don't has the slowdown issue, for StaxRip this don't help unfortunately because several StaxRip features rely on ffmpeg and last time I tried ffmpeg with r1576 an error was returned by ffmpeg stating that AviSynth r1576 is too old.

[Groucho2004]

last time I tried ffmpeg with r1576 an error was returned by ffmpeg stating that AviSynth r1576 is too old.
Yes, FFMPEG and some plugins require Avisynth interface version 6, r1576 is still 5.
Let's hope development picks up again and the issue(s) will be fixed.

[vcmohan]

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

-------


Most plugins by V.C. Mohan (http://www.avisynth.nl/users/vcmohan/) .
I have converted most of my plugins to 64bit using avisynth+ header file. I have tested them with virtual dub (and not yet with avsmeter). All of these are MT_NICE mode. Only those that require visual examination viz: frequency spectrum are serialized.

[ryrynz]

Thought I'd give Avisynth+ MT another shot after a year or so

The following script runs fine with 1576

Loadplugin("C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins+\psharpen.avs")
ffdshow_source()
Psharpen(100)

installed 1825, updated to this and get an system exception access violation error.

SetFilterMTMode("DEFAULT_MT_MODE", 3)
Loadplugin("C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins+\psharpen.avs")
ffdshow_source()
Psharpen(100)
Prefetch(2)

Are things still that broken with MT?

[Groucho2004]

This script works fine for me on r1825, x86:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1)
Psharpen(100)
Prefetch(4)

DEFAULT_MT_MODE 3 either crashes or has no performance impact.

Have not tried ffdshow.

[ryrynz]

This script works fine for me on r1825, x86:

DEFAULT_MT_MODE 3 either crashes or has no performance impact.

Have not tried ffdshow.

Tried mode 3 for compatibility and to strip the source line out, I had also set mode 2 as default and mode 3 for source and also had the same issue. Disappointing, 64 bit Avisynth+ and ffdshow would hopefully gain me some performance, guess we're not there yet. Looks like SEt's MT is still the way to go for real-time work for now.

[LigH]

You would probably need a 64-bit ffdshow to use a 64-bit AviSynth+ as a realtime post-processing filter. Which is not quite the purpose AviSynth was made for, anyway.

[ryrynz]

You would probably need a 64-bit ffdshow to use a 64-bit AviSynth+ as a realtime post-processing filter. Which is not quite the purpose AviSynth was made for, anyway.
Yup, aware of that. Been using 32 bit, need to have that working before I even attempt 64.

[RenderGuy2]

Yup, aware of that. Been using 32 bit, need to have that working before I even attempt 64.

I have used ffdshow rev4533 x64 raw video filter with mpc-hc x64. As I mentioned in an earlier post, Avisynth+ r1779 works well, however r1825 doesn't work (at least not on my systems).

Perhaps someone more knowledgeable than me would know what changed between r1779 and r1825 that would make it incompatible with ffdshow.

[ryrynz]

I have used ffdshow rev4533 x64 raw video filter with mpc-hc x64. As I mentioned in an earlier post, Avisynth+ r1779 works well, however r1825 doesn't work (at least not on my systems).

Perhaps someone more knowledgeable than me would know what changed between r1779 and r1825 that would make it incompatible with ffdshow.

Oh yah, I remember seeing aegisofrime's post about the access violation error a while back. Thanks, I'll hopefully get this running today.

[ryrynz]

Thanks, I'll hopefully get this running today.

Yeah.. MT obviously isn't stable. Just trying to run a single line awarp4 with nnedi3 results in green screens, quarter screens and garbage depending on how many threads I give it. Looks like 2.6 MT is still the way to go for real time work, shame that.

I guess I'll look at this again once another phase of development has occurred, hopefully some time next year.

[Elegant]

Importing the AVSMeter performance data into a spread sheet program shows the issue with r1825 slowing down continuously quite nicely.

Script:
SetMemoryMax(1024)
LWLibavVideoSource("src\test.m2v")
AssumeTFF()
QTGMC(Preset="slow")


Result with r1576 x86:
http://s1.postimg.org/c20lkxnof/1576.png

Result with r1825 x86:
http://s7.postimg.org/s1hv5tyob/1825.png

I might make some time for this issue. This issue should not necessarily require a full understanding of AviSynth+. All that should be needed is the ability to compile AviSynth+ and test it with AVSMeter. Then just check a series of revisions and narrow it down until you find the one commit where it goes south and if possible, revert the change.

Now if it happens to degrade over each revision then I can't help fix it but I can see a few commits on GitHub that make me question if that might be the cause.

[Groucho2004]

Now if it happens to degrade over each revision then I can't help fix it but I can see a few commits on GitHub that make me question if that might be the cause.
I think this started somewhere in build 17xx. I'm not certain though...

[Reel.Deel]

I have a few different r17xx test builds by ultim, when I get home I'll do some testing to see if any of those revisions show the same behavior.

---

Ok I finally finished testing...

So it seems something went wrong after r1765; it's still slightly slower than r1576 but at least the FPS is consistent. I only tested the 32-bit version for now, hopefully I'll have time later to test the 64-bit versions. Thanks to Groucho2004 for reporting this issue and also for his nifty AVSMeter :).

Script:

SetMemoryMax(1024)
LWLibavVideoSource("test.m2v")
AssumeTFF()
QTGMC(Preset="slow")

Clip info:

Number of frames: 43596
Length (hh:mm:ss.ms): 00:12:07.327
Frame width: 720
Frame height: 480
Framerate: 59.940 (60000/1001)
Colorspace: YV12



AviSynth+ r1576
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 6.934 | 171.0 | 24.55
Memory usage (phys | virt): 1048 | 1070 MB
Thread count: 26
CPU usage (average): 9%
Time (elapsed): 00:29:35.825

http://s18.postimg.org/r0w7jeyq1/Avi_Synth_r1576.png


AviSynth+ r1689
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 6.617 | 170.8 | 22.27
Memory usage (phys | virt): 178 | 184 MB
Thread count: 39
CPU usage (average): 10%
Time (elapsed): 00:32:37.568
http://s8.postimg.org/ec4wbuy1h/Avi_Synth_r1689.png


AviSynth+ r1765
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 5.686 | 170.4 | 22.23
Memory usage (phys | virt): 178 | 184 MB
Thread count: 39
CPU usage (average): 11%
Time (elapsed): 00:32:41.305
http://s3.postimg.org/mdoxion6r/Avi_Synth_r1765.png


AviSynth+ r1779
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 3.793 | 112.9 | 11.70
Memory usage (phys | virt): 193 | 199 MB
Thread count: 39
CPU usage (average): 9%
Time (elapsed): 01:02:06.727
http://s18.postimg.org/l9egv8ifd/Avi_Synth_r1779.png


AviSynth+ r1825
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 5.607 | 116.3 | 12.31
Memory usage (phys | virt): 193 | 200 MB
Thread count: 39
CPU usage (average): 10%
Time (elapsed): 00:59:00.326
http://s13.postimg.org/6fogsu047/Avi_Synth_r1825.png


AviSynth 2.6 (just for validation)
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 7.780 | 174.3 | 18.85
Memory usage (phys | virt): 1055 | 1077 MB
Thread count: 26
CPU usage (average): 10%
Time (elapsed): 00:38:33.056
http://s11.postimg.org/fhgdfyfrn/Avi_Synth_2_6.png

[jpsdr]

Absolute winner is...... avs+ 1576 ! :D

[Reel.Deel]

Absolute winner is...... avs+ 1576 ! :D

Yes indeed. I hope this issue can be resolved. KNLMeans and even FFmpeg (http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-March/170699.html) requires AviSynth+ r1779 or greater (or any version with the latest header) :(.

[Groucho2004]

Ok I finally finished testing...
I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

[Reel.Deel]

I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

Intel core i7 4930k (http://ark.intel.com/products/77780/Intel-Core-i7-4930K-Processor-12M-Cache-up-to-3_90-GHz) on 64-bit Windows 7. I'll test 2.6/AVS+ r1576 on another processor to see if I get similar results.

I also added this issue to GitHub: https://github.com/AviSynth/AviSynthPlus/issues/63

[Groucho2004]

Intel core i7 4930k (http://ark.intel.com/products/77780/Intel-Core-i7-4930K-Processor-12M-Cache-up-to-3_90-GHz) on 64-bit Windows 7.
Hm. I ran this on my i5-2500K on XP. The only difference between XP and Win7 that could be relevant here is that Win7 supports AVX intrinsics. However, I'm not aware of any AVX intrinsics in AVS+. Maybe one of the plugins is using them?

Edit: Which nnedi3 are you using?

[Reel.Deel]

I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

Here's the results with an i7-4770k (http://ark.intel.com/products/75123/Intel-Core-i7-4770K-Processor-8M-Cache-up-to-3_90-GHz) also on Windows 7; more or less the same as the previous results. Out of curiosity I might test this with my old computer (Q6600 / XP).

AviSynth+ r1576:
[Runtime info]
Frames processed: 45338 (0 - 45337)
FPS (min | max | average): 10.25 | 218.7 | 32.83
Memory usage (phys | virt): 1046 | 1068 MB
Thread count: 18
CPU usage (average): 15%
Time (elapsed): 00:23:00.899
http://s16.postimg.org/ia6tliuyt/Avi_Synth_r1576_i7_4770k.png


AviSynth 2.6:
[Runtime info]
Frames processed: 45338 (0 - 45337)
FPS (min | max | average): 6.128 | 222.0 | 27.15
Memory usage (phys | virt): 1053 | 1074 MB
Thread count: 18
CPU usage (average): 15%
Time (elapsed): 00:27:49.653

http://s17.postimg.org/ln4g7b0jj/Avi_Synth_2_6_i7_4770k.png


Which nnedi3 are you using?
I'm using jpsdr's nnedi3 (SSE4.2). Both AVS/AVS+ are using the the exact same plugins.

[qyot27]

While it was mentioned in the issue on Github, the drastic difference in memory consumption between r1576 and newer builds of avsplus is because r1576 still uses the old cache system that 2.6 does, just bugfixed and tweaked a bit with the rest of the performance boosts that were already present in 0.1. But the MT branch (which is where *all* post-r1576 builds come from, since there weren't any public builds made available prior to r1689, IIRC) has a redesigned cache system, leading to the much-reduced memory consumption and different thread count numbers. It's a bit of comparing apples to oranges there.

So more correctly, the drop-off in performance after r1765 is a regression that was introduced late in the cycle for the new cache system. I may go in and do some builds so we can try to bisect this, once I have access to my VS2013 build environment again.

[Boulder]

The performance issue aside, is r1825 generally safe to use for MT purposes or are there other issues still lurking?

[jpsdr]

Yes indeed. I hope this issue can be resolved. KNLMeans and even FFmpeg (http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-March/170699.html) requires AviSynth+ r1779 or greater (or any version with the latest header) :(.

Stupid thought : Can't the r1576 just be compiled with the latest header ?

[Groucho2004]

Stupid thought : Can't the r1576 just be compiled with the latest header ?
You mean having avisynth.dll pretend to support AVISYNTH_INTERFACE_VERSION 6?
That would almost certainly crash if a plugin tries to use for example the updated Avisynth_C API.

[Reel.Deel]

Can someone please make an AviSynth+ changelog (or list) that contains revision numbers and the corresponding commit hash? Since AviSynth+ uses revision numbers for it's releases is kinda hard to find the corresponding commit unless it's been tagged. I'm not familiar with GitHub so I'm not sure how to accomplish this.

[qyot27]

That's actually impossible, because the commit count can change during merges because git slips commits into the history by date (and in fact, this is exactly what happened when the Sphinx docs were merged). This is expected git behavior. The reason some projects don't have this as an issue is because they don't do merges, and apply patchsets through git am.

The revision numbers are more akin to plain commit counts than static revision numbers like in Subversion. In fact, the method by which the number is generated is 'git rev-list --count HEAD'.

The better option (although it wouldn't do anything to existing commits), would be to have the abbreviated commit hash visible in the output of Version().


The dumb way of doing it is to simply do 'git rev-list HEAD', and then open it in a spreadsheet so you can look at the row numbers or generate them in a column. But like I said, that only shows which commits were in those positions at the time you perform the operation, not forever.

[Reel.Deel]

Thanks for the info qyot27. If I'm understanding correctly does that mean that AviSynth+ rxxxx actually means the commit count rather than the revision number?

[qyot27]

Pretty much, yes. Revision numbers are a form of commit counts, even in Subversion. The difference is that where Subversion's are static numbers and thus the revision number is always true for X commit, in normal git usage the number is only representative of the latest commit on the branch you're on (and since the most common usage for the numbers is as a constantly tracking upward number of commits, it works well enough). Like I said, some projects - x264, for instance - don't do merges and force git to keep a strictly linear history, in which case the revision numbers and commit hashes would be static and pretty much just like in Subversion. But those would definitely be the exceptions for projects using git, not the rule.

For AviSynth+, the revision numbers are really just a shorthand, and the only ones that might pack extra meaning are those that are shown in the Version() output for an official point release. That's why 'AviSynth+ r1576' is treated as synonymous with the official release of 'AviSynth+ 0.1'. Otherwise, the numbers are more for seeing how much activity has occurred between builds (or in relation to classic AviSynth; currently, avsplus is about 500 commits ahead or so). Whatever the number happens to be when 0.2 gets tagged and released will have the same popular association to it.

[LigH]

It is certainly similar for x265 which uses Hg (Mercurial), a kind of git variant. There are version "milestones" and additional patch counts. But it seems not to progress as sequentially as expected either; I remember a point when the "stable" branch got merged into the "default" branch and should have raised the count of patches by about half a dozen, I expected, but it increased only by one... So I am not sure if only the patches in the "default" branch count, or if there are "meta patches" which don't increase the number after the version milestone. Only the hash pattern is sufficient as identification.

[foxyshadis]

Tagging specific builds/releases makes the most sense, then a changelog for the tagged revision will be the same forever. Tags are a lot easier to find visually than hashes.

[qyot27]

Okay, here's a pack of 4 different snapshots so that we can start narrowing down where in the last 100 commits this regression appeared:
http://www.mediafire.com/download/ajfnwwvpebr3ppm/avsplus_bisect_test.7z

I also included the git hash in the directory names so we know what the exact commits are.

[Groucho2004]

Okay, here's a pack of 4 different snapshots so that we can start narrowing down where in the last 100 commits this regression appeared:
http://www.mediafire.com/download/ajfnwwvpebr3ppm/avsplus_bisect_test.7z
I also included the git hash in the directory names so we know what the exact commits are.
Thanks for building these. r1727 and r1770 are OK, everything above (r1779, 1783, ...) is not.

A script for quickly checking if the dll exhibits the "fps deterioration":
SetMemoryMax(1024)
colorbars(width = 640, height = 480, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 49999)
AssumeTFF()
QTGMC(Preset="Super Fast")
Running this through AVSMeter you'll see after 3000~5000 frames whether the FPS is stable or not.

[qyot27]

Thanks for building these. r1727 and r1770 are OK, everything above (r1779, 1783, ...) is not.
Okay, that narrows it down to 13 commits that need to be checked. Better yet is that some of them are clearly not related to this at all, and some of the others only have to do with how filters register themselves as MT or in naming (which probably wouldn't be causing any issues with speed drops after the script starts). Which only really leaves 4 that are highly suspect, and they're all together:
c4972da Fix leaking subframes.
b361e59 Fix #37 by not using filter instances to get their MT mode.
422aae8 At least avoid leaking the VFBs when plugin or host is leaking.
3cb1122 Report invalid param of SelectEvery to user.
I strongly suspect it's either 422aae8 or c4972da that's doing it. Of course, those commits look like they're supposed to fix leaks in the core, so it's either doing it too aggressively, or it may even actually be exposing leaks in the plugins QTGMC uses.

[qyot27]

Round 2:
http://www.mediafire.com/download/f2nvkzwleszaub0/avsplus_bisect_test_round2.7z

This has builds of the four commits I mentioned in the last post.

[Reel.Deel]

r1774 (c4972da) (https://github.com/AviSynth/AviSynthPlus/commit/c4972da35ca1f2803c64d33b372327c468d03cde) is definitely the culprit; it even had this comment:
// TODO: Figure out why uncommenting this line causes problems

Tested using the Groucho's script above.

r1773:
http://s2.postimg.org/f0g3pjz1h/Avi_Synth_r1773.jpg (http://postimg.org/image/f0g3pjz1h/)

r1774:
http://s15.postimg.org/ypicd8fav/Avi_Synth_r1774.jpg (http://postimg.org/image/ypicd8fav/)

I believe this is the issue (http://forum.doom9.org/showthread.php?p=1713107#post1713107) that spawned that/those commit(s).

Edit: old commit that might be relevant to this issue: https://github.com/AviSynth/AviSynthPlus/commit/71b9187abce06c74b1ddd62daff5af7dfab2c1a5

[Thunderbolt8]

I'd like to request the addition of Rec. 2020 support for UHD Blu-rays & corresponding conversion options to compare UHD screenshots with normal Blu-ray screenshots. Otherwise we'd have to do it all manually.

Would be nice if the developers could add this in the future.

[LigH]

This would certainly mean that all probable decoder plugins need to be able to signal source colorimetry metadata to the AviSynth+ kernel as well.

[Elegant]

r1774 (c4972da) (https://github.com/AviSynth/AviSynthPlus/commit/c4972da35ca1f2803c64d33b372327c468d03cde) is definitely the culprit; it even had this comment:


Tested using the Groucho's script above.

r1773:
http://s2.postimg.org/f0g3pjz1h/Avi_Synth_r1773.jpg (http://postimg.org/image/f0g3pjz1h/)

r1774:
http://s15.postimg.org/ypicd8fav/Avi_Synth_r1774.jpg (http://postimg.org/image/ypicd8fav/)

I believe this is the issue (http://forum.doom9.org/showthread.php?t=168856&page=48#post1713107) that spawned that/those commit(s).

Edit: old commit that might be relevant to this issue: https://github.com/AviSynth/AviSynthPlus/commit/71b9187abce06c74b1ddd62daff5af7dfab2c1a5

I did a whole bunch of comparisons between the AVS 2.6 and AVS+ regarding this. Could you test this build (https://www.dropbox.com/s/k2p0a4wakxyzarp/AVS%2B%20Test%20Build%20-%2020150901.7z?dl=0) and see if the issue still occurs? I'll test it myself later when I have access to my PC with my plugins.

[Reel.Deel]

I did a whole bunch of comparisons between the AVS 2.6 and AVS+ regarding this. Could you test this build (https://www.dropbox.com/s/k2p0a4wakxyzarp/AVS%2B%20Test%20Build%20-%2020150901.7z?dl=0) and see if the issue still occurs? I'll test it myself later when I have access to my PC with my plugins.

I get this error with AVSMeter: Exception 0xC0000005
STATUS_ACCESS_VIOLATION

Edit: tried another time with AVSMeter and this time it ran for about 500 frames and then I got the error above. Using VirtualDub to run an analysis pass, the fps drop is very obvious, it goes from 100fps to 2 within 500 frames and then I got this error:

Avisynth read error:
Could not allocate video frame. Out of memory.

[Elegant]

Thanks, looking back at the change I made, that makes sense since I actually forgot to apply it to the rest of file and only fixated on the lines listed in that commit mentioned earlier and assumed the rest of it would work itself out (bad idea!). I'll test it fully at home and hopefully my idea pans out.

I found this comment very interesting as AVS 2.6 utilizes it in the "troubled" area:

// Hack note :- Use of SubFrame will require an "InterlockedDecrement(&retval->refcount);" after
// assignement to a PVideoFrame, the same as for a "New VideoFrame" to keep the refcount consistant.

This comment is made in both AVS 2.6 and AVS+ but AVS+ never utilizes InterlockedDecrement yet we use the refcount with AVS+ as well as InterlockedIncrement. More importantly we use refcount while going through the FrameRegistry list mentioned in the commit where frame is a value in the FrameRegistry:

if (0 == frame->refcount)
{
delete frame;
}

At a glance this looks like a problem. I can't say for certain but I do not like that we never decrement a counter and yet have a condition for when it's 0 to delete it. I thought simply adding that comment to the "troubled" area would fix the problem but I think there are more areas that need an visiting in order for that to work.

EDIT: I did do a build where I reverted that commit and it does rectify the issue but it doesn't seem right to be using it as is...

[raffriff42]

AviSynth+_v0.1.0_r1779.exe
http://avisynth.nl/index.php/AviSynth%2B#DownloadsColorbars(pixel_type="YV12")
return Histogram("audiolevels")
==> "Integer Divide by Zero"

ConvertAudioTo16bit does not help.
v2.60 Jan 14 2013 is OK.

[qyot27]

AviSynth+_v0.1.0_r1779.exe
http://avisynth.nl/index.php/AviSynth%2B#DownloadsColorbars(pixel_type="YV12")
return Histogram("audiolevels")
==> "Integer Divide by Zero"

ConvertAudioTo16bit does not help.
v2.60 Jan 14 2013 is OK.
That seems to be an issue with the tone ColorBars generates. If you kill the audio and replace it with the output of Tone(), Histogram works fine.

[raffriff42]

It's not only ColorBars:Colorbars(pixel_type="YV12")

#[[ choose a source
A=WAVSource("pinknoise.wav") ## mono
A=MonoToStereo(A, A)
## 2 ch, 16 bit, 44100
#][
# A=Tone
# ## 2 ch, float, 48000
#]]
AudioDub(A)

#[[ choose one or more - any of these causes divide-by-zero
# ConvertAudioToFloat
# ConvertAudioTo32bit
# ConvertAudioTo16bit
#]]

Histogram("audiolevels")
Info
return Last
:confused:

[burfadel]

So... Any new post 1825 test builds? I'm particularly interested in the 64-bit version.

[qyot27]

Development has entered a hiatus again, so there's nothing past r1825 to build (pull requests notwithstanding, but aside from #64 those wouldn't add very much to the end-user's experience).

I nearly start having an anxiety attack when I try to jump back into working on the SIMD splitting necessary for the Linux (or generally GCC, really) branch. The RC1 integration majorly sidetracked it.

[burfadel]

Development has entered a hiatus again, so there's nothing past r1825 to build (pull requests notwithstanding, but aside from #64 those wouldn't add very much to the end-user's experience).

I nearly start having an anxiety attack when I try to jump back into working on the SIMD splitting necessary for the Linux (or generally GCC, really) branch. The RC1 integration majorly sidetracked it.

Ah ok, all good! Has anyone attempted merging the latest Avisynth branch with Avisynth+ recently?

[qyot27]

There is amazingly little that changed between 2.6 RC1 (which was already merged into AviSynth+ in the early 1700s revision range) and 2.6.0 Final that were a concern to avsplus, or otherwise. The changes that do apply to avsplus are in the RC2 integrate branch/pending pull request (https://github.com/AviSynth/AviSynthPlus/pull/59) - which AFAICT, along the whatever the resolution of the QTGMC slowdown issue a few posts back happens to be, are really all that are blocking 0.2 being tagged and released.

If classic's CVS isn't beyond the state of 2.6.0, then there's nothing else to merge from classic at the moment. Finding that out basically requires running a full cvsimport and doing a commit comparison unless you want to wander aimlessly through Sourceforge's CVS webviewer. The last time I did that was just after 2.6.0 was released.

[tormento]

I have tried to search and read the wiki but can't find:
- which is the criteria to put a plugin inside plugin or plugin+?
- is there a list of tested plugins that fill that criteria?

[Groucho2004]

I have tried to search and read the wiki but can't find:
- which is the criteria to put a plugin inside plugin or plugin+?
- is there a list of tested plugins that fill that criteria?
Most plugins that work with 2.6 should work with AVS+.

However, AVS+ r1576 (the "official" stable version) supports only interface version 5. There are already a few plugins that are based on interface version 6 (KNLMeansCL for example), so these won't work. Also, the latest builds of ffmpeg require interface version 6. A workaround would be to install r1576 and then replace the DLLs with r1825.

[tormento]

Most plugins that work with 2.6 should work with AVS+.

However, AVS+ r1576 (the "official" stable version) supports only interface version 5. There are already a few plugins that are based on interface version 6 (KNLMeansCL for example), so these won't work. Also, the latest builds of ffmpeg require interface version 6. A workaround would be to install r1576 and then replace the DLLs with r1825.
Thanks for your reply and I still haven't understood which is the difference between plugin and plugin+ directory. :(

[ryrynz]

I really wish development of this would start up again soon.. getting this is a fully workable state to finally replace AvisynthMT would be great.

[tormento]

I am playing back and forth between Avisynth 2.6.0MT and AviSynth+ 1825 MT, testing speed and image quality.

I went thru the following image corruption.

AviSynth output:
http://i.imgur.com/8MGljqrm.jpg (http://imgur.com/8MGljqr)

from script:
SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
SetMTMode(2)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)


AviSynth+ output:
http://i.imgur.com/PXXdVqam.jpg (http://imgur.com/PXXdVqa)
from script:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSourceIM", 3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(4)
Any idea?

[Groucho2004]

Thanks for your reply and I still haven't understood which is the difference between plugin and plugin+ directory. :(
All you need to know is here (http://avisynth.nl/index.php/AviSynth%2B), including the auto-load priorities.

[Groucho2004]

I went thru the following image corruption.
What happens if you comment out the Prefetch() statement?

[tormento]

What happens if you comment out the Prefetch() statement?
This night I'll try. It was already in my mind, such as use an older build.

[Reel.Deel]

@tormento

Just out curiosity do you have the MT modes script (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) loaded? Also I see that you're using SMDegrain with prefilter=4, I beleive that uses KNLMeans which the author said it's not MT friendly. Try adding SetFilterMTMode("KNLMeans", 3).

[tormento]

@Groucho2004 @Reel.Deel

Even without MT or with SetFilterMTMode("KNLMeansCL", 3), the corruption is still there.

[Reel.Deel]

@Groucho2004 @Reel.Deel

Even without MT or with SetFilterMTMode("KNLMeansCL", 3), the corruption is still there.

Is the video corrupted before SMDegrain?

[MysteryX]

@tormento

Just out curiosity do you have the MT modes script (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) loaded? Also I see that you're using SMDegrain with prefilter=4, I beleive that uses KNLMeans which the author said it's not MT friendly. Try adding SetFilterMTMode("KNLMeans", 3).
I was told that KNLMeans requires mode 5 or 6. 6 was considerably slower, 5 is working well for me.

[Reel.Deel]

I was told that KNLMeans requires mode 5 or 6. 6 was considerably slower, 5 is working well for me.

AviSynth+ MT only has modes 1-3 (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes).

[burfadel]

I really wish development of this would start up again soon.. getting this is a fully workable state to finally replace AvisynthMT would be great.

+1

People with programming skills are more than welcome to assist... I guess lol.

[MysteryX]

Smooth Video Project is greatly moving forward and is also waiting for a functional version of AviSynth+; as AviSynth is what makes SVP unstable and causes it to crash all the time.

I guess everybody wants it and nobody wants to touch the code lol

[ryrynz]

I guess everybody wants it and nobody wants to touch the code lol

That was part of the reason why Avisynth+ was made, code maintainability.

[tormento]

Is the video corrupted before SMDegrain?

The raw video or the result from AviSynth without filters?

[tormento]

I was told that KNLMeans requires mode 5 or 6. 6 was considerably slower, 5 is working well for me.
KNLMeansCL works perfectly with mode 3. See AviSynth comparison.

[tormento]

Is the video corrupted before SMDegrain?
Ok, it seems to be SMDegrain, both with prefilter=2 and with prefilter=4. No problems with standard AviSynth.

[tormento]

I am trying to use 64bit part of AviSynth+.

I am getting some strange errors and I can't understand why. I put KNLMeansCL in the plugins64 or plugins64+ and it gives me two different error.

Script:
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi")
KNLMeansCL(D=1, A=1, h=7.0,device_type="GPU")

Error:
[E:\in\2_01 favoloso mondo di Amelie, Il]d:avs4x264mod-x64.exe -o amelie_64.mkv amelie_64.avs
avs [error]: Script error: There is no function named 'KNLMeansCL'.
(amelie_64.avs, line 4)

Script:
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
LoadPlugin("D:\programmi\media\AviSynth+\plugins64+\KNLMeansCL-0.6.11.dll")
DGSource("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi")
KNLMeansCL(D=1, A=1, h=7.0,device_type="GPU")

Error:
[E:\in\2_01 favoloso mondo di Amelie, Il]d:avs4x264mod-x64.exe -o amelie_64.mkv amelie_64.avs
avs [error]: Cannot load file 'D:/programmi/media/AviSynth+/plugins64+/KNLMeansCL-0.6.11.dll'. Platform returned code 126:
Impossibile trovare il modulo specificato.

(amelie_64.avs, line 2)

I am sure it is a very stupid thing but can't go thru.

[LigH]

Are you sure you put the 64 bit version of KNLMeansCL{-0.6.11}.dll into the plugins64 directory? A 64 bit AviSynth won't load a 32-bit plugin from there. I would possibly avoid the plugins64+ directory for generally AviSynth compatible plugins (not very specific to AviSynth+) unless I am certain what the difference is.

Does the same work when you use 32-bit AviSynth in a 32-bit application?
_

Not sure if and how that will work, just an idea: Can DependencyWalker Win64 confirm that it can use a 64-bit OpenCL driver? LoadLibrary error 126 seems to be related to unavailable dependencies sometimes.

Ah, another idea: I believe to remember that some plugins already use API version 6 while AviSynth+ may still use API version 5, might be a reason why it can't load plugins with a higher API version?

[Groucho2004]

I am sure it is a very stupid thing but can't go thru.
What error does AVSMeter64 return?

[StainlessS]

I really wish development of this would start up again soon.. getting this is a fully workable state to finally replace AvisynthMT would be great.

If you did something, and other people followed your lead, then your wish could come well come true. (EDIT: So we are all waiting for YOU !)

[foxyshadis]

That was part of the reason why Avisynth+ was made, code maintainability.

It's a wonderful codebase, I almost cried for joy the first time I dove in to debug something. Unfortunately, now all the easy stuff and most of the hard stuff is done, and what remains is one of the hardest problems in all of computer science: Performant but correct synchronization of bits of code that were never meant to be threaded (plugins, especially old ones). Since failures are unreproduceable by nature, it's a real head-desk problem.

Fixing it completely might require a threading expert who has tools like VTune, though even small improvements would be welcome!

[RazorBurn]

Error:
[E:\in\2_01 favoloso mondo di Amelie, Il]d:avs4x264mod-x64.exe -o amelie_64.mkv amelie_64.avs
avs [error]: Cannot load file 'D:/programmi/media/AviSynth+/plugins64+/KNLMeansCL-0.6.11.dll'. Platform returned code 126:
Impossibile trovare il modulo specificato.

(amelie_64.avs, line 2)

I am sure it is a very stupid thing but can't go thru.

I have the same exact error on KNLMeansCL or any plugin that use VC redist 2013..

The problem relies on the bug in upgrading your Build in Windows 10..

My Solution was Install clean state windows 10 build 240.. And Dont upgrade to new Win10 Builds..

[tormento]

What error does AVSMeter64 return?

AVS script:

LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi")
KNLMeansCL(D=1, A=1, h=7.0,device_type="GPU")
CompTest(1)

AVSMeter 2.1.2 (x64)
AviSynth+ 0.1 (r1825, MT, x86_64) (0.1.0.0)

Number of frames: 1764
Length (hh:mm:ss.ms): 00:01:13.500
Frame width: 1920
Frame height: 816
Framerate: 24.000 (24/1)
Colorspace: YV12

Frames processed: 1764 (0 - 1763)
FPS (min | max | average): 2.087 | 41.93 | 22.76
Memory usage (phys | virt): 101 | 389 MB
Thread count: 23
CPU usage (average): 10%

Time (elapsed): 00:01:17.497

OMG.

I means two things:


DGDecNV and KNLMeansCL works in 64 bit and not in 32 bit
there must be something I forget when using avs4x26x


Is possible to use x264 directly with avs or can you tell me how to pass it thru without avs4x26x?

[tormento]

Are you sure you put the 64 bit version of KNLMeansCL{-0.6.11}.dll into the plugins64 directory? A 64 bit AviSynth won't load a 32-bit plugin from there. I would possibly avoid the plugins64+ directory for generally AviSynth compatible plugins (not very specific to AviSynth+) unless I am certain what the difference is.
Read my previous reply. :p

[tormento]

The problem relies on the bug in upgrading your Build in Windows 10..

My Solution was Install clean state windows 10 build 240.. And Dont upgrade to new Win10 Builds..
My decision to jump over fast build wagon was AFTER I tested it on plain build and did not work. Are you on 32 or 64 bit?

[Groucho2004]

Is possible to use x264 directly with avs
It should work just like 32 bit AVS/x264. Why don't you just try it? Takes 10 seconds to find out.

[tormento]

It should work just like 32 bit AVS/x264. Why don't you just try it? Takes 10 seconds to find out.
I use MeGUI for 32 bit. Just have to try harder. :p

[Groucho2004]

I use MeGUI for 32 bit. Just have to try harder. :p
x264_64 -o foo.264 script.avs

[tormento]

x264_64 -o foo.264 script.avs

LOL

d:x264_64.exe --level 4.1 --pass 1 --qp 16 --ref 3 --bframes 3 --analyse all --me umh --trellis 1 --subme 9 --merange 16 --keyint 250 --min-keyint 25 --b-adapt 2 --direct auto --weightb --mixed-refs --b-pyramid strict --8x8dct --no-fast-pskip --threads 8 --output amelie_64.mkv amelie_64.avs
avs [info]: 1920x816p 0:0 @ 24/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:121 Avg QP:13.00 size:191308
x264 [info]: frame P:569 Avg QP:16.00 size: 64478
x264 [info]: frame B:1074 Avg QP:17.63 size: 25673
x264 [info]: consecutive B-frames: 13.0% 7.3% 30.8% 49.0%
x264 [info]: mb I I16..4: 21.2% 0.0% 78.8%
x264 [info]: mb P I16..4: 23.8% 0.0% 0.0% P16..4: 66.2% 0.0% 0.0% 0.0% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 4.0% 0.0% 0.0% B16..8: 36.3% 0.0% 0.0% direct:35.8% skip:23.9% L0:31.4% L1:40.8% BI:27.9%
x264 [info]: direct mvs spatial:99.0% temporal:1.0%
x264 [info]: coded y,uvDC,uvAC intra: 67.1% 89.3% 72.8% inter: 27.2% 61.6% 8.6%
x264 [info]: i16 v,h,dc,p: 39% 29% 20% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 22% 8% 6% 8% 8% 7% 8% 6%
x264 [info]: i8c dc,h,v,p: 41% 21% 28% 10%
x264 [info]: Weighted P-Frames: Y:3.9% UV:3.0%
x264 [info]: kb/s:9513.83

encoded 1764 frames, 22.83 fps, 9513.91 kb/s

LOL

[Groucho2004]

LOL

d:x264_64.exe --level 4.1 --pass 1 --qp 16 --ref 3 --bframes 3 --analyse all --me umh --trellis 1 --subme 9 --merange 16 --keyint 250 --min-keyint 25 --b-adapt 2 --direct auto --weightb --mixed-refs --b-pyramid strict --8x8dct --no-fast-pskip --threads 8 --output amelie_64.mkv amelie_64.avs
avs [info]: 1920x816p 0:0 @ 24/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:121 Avg QP:13.00 size:191308
x264 [info]: frame P:569 Avg QP:16.00 size: 64478
x264 [info]: frame B:1074 Avg QP:17.63 size: 25673
x264 [info]: consecutive B-frames: 13.0% 7.3% 30.8% 49.0%
x264 [info]: mb I I16..4: 21.2% 0.0% 78.8%
x264 [info]: mb P I16..4: 23.8% 0.0% 0.0% P16..4: 66.2% 0.0% 0.0% 0.0% 0.0% skip:10.0%
x264 [info]: mb B I16..4: 4.0% 0.0% 0.0% B16..8: 36.3% 0.0% 0.0% direct:35.8% skip:23.9% L0:31.4% L1:40.8% BI:27.9%
x264 [info]: direct mvs spatial:99.0% temporal:1.0%
x264 [info]: coded y,uvDC,uvAC intra: 67.1% 89.3% 72.8% inter: 27.2% 61.6% 8.6%
x264 [info]: i16 v,h,dc,p: 39% 29% 20% 13%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 22% 8% 6% 8% 8% 7% 8% 6%
x264 [info]: i8c dc,h,v,p: 41% 21% 28% 10%
x264 [info]: Weighted P-Frames: Y:3.9% UV:3.0%
x264 [info]: kb/s:9513.83

encoded 1764 frames, 22.83 fps, 9513.91 kb/s

LOL
So, the problem you had appears to be related to some GUI?

[tormento]

So, the problem you had appears to be related to some GUI?
No, to 32bit.

The 64bit versions of anything solve the problem of using DGDecNV and KNLMeansCL together.

Same image corruption even in 64 bit version.

[qyot27]

Ah, another idea: I believe to remember that some plugins already use API version 6 while AviSynth+ may still use API version 5, might be a reason why it can't load plugins with a higher API version?
That's only true of AviSynth+ 0.1/r1576. The changes from RC1 (API version 6, et al.) were merged into the MT/HEAD branch back in March. All the builds since then are v6.

[LigH]

avs4x26x is a 32-bit application, calling 32-bit AviSynth, and piping the raw video stream to another (possibly, but not necessarily, 64-bit) encoder.

[tormento]

This (http://forum.doom9.org/showthread.php?p=1739893#post1739893) image corruption appears even in 64bit, one thread.

Plugin authors tell it's AviSynth+ fault.

Any idea?

[qyot27]

Due to the differing rules in setting the MT mode between the two, you're using mode 3 for SetMemoryMax in AviSynth-MT, but mode 2 in AviSynth+ (the same point also applies for LoadPlugin). I'll go on record saying I highly, highly doubt this has anything to do with the problem, but that difference means the script isn't as 1:1 a conversion from Avs-MT to Plus that it otherwise would be.

[tormento]

Due to the differing rules in setting the MT mode between the two, you're using mode 3 for SetMemoryMax in AviSynth-MT, but mode 2 in AviSynth+ (the same point also applies for LoadPlugin). I'll go on record saying I highly, highly doubt this has anything to do with the problem, but that difference means the script isn't as 1:1 a conversion from Avs-MT to Plus that it otherwise would be.
In MT I use the same memory modes, both in AviSynth and in AVS+, I did not know that SetMemoryMax could enter into equation. After this encoding session I'll try to remove the line or put as exception in initial plugin declaration and see. My current scripts, are quite similar:

SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
SetMTMode(2)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)


SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSourceIM", 3)
SetFilterMTMode("KNLMeansCL", 3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(4)

The corruption however is even in single thread.

[ndjamena]

Are the updated audio parameters in BlankClip not included in AVISynth+ or has it been changed to something else. I can't find any mention of it anywhere.

http://avisynth.nl/index.php/BlankClip

int channels, string sample_type

VirtualDub is complaining that BlankClip has no such arguments.

[Reel.Deel]

Are the updated audio parameters in BlankClip not included in AVISynth+ or has it been changed to something else. I can't find any mention of it anywhere.

http://avisynth.nl/index.php/BlankClip

int channels, string sample_type

VirtualDub is complaining that BlankClip has no such arguments.

BlankClip(channels=2, sample_type="16bit") works for me on r1576. Are you sure you're not doing anything wrong? Those parameters have been there since v2.58...

[ndjamena]

I must have made a typo somewhere.

[real.finder]

mt test

http://i.imgur.com/Ubp7NCb.png


ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToYV12()
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()
Prefetch(12)

http://i.imgur.com/LyXLxY7.png


setmtmode(2,12)
ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToYV12()
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()

[stranno]

I'm testing a bit and it seems that 1576 is a bit faster than 1773 that is more faster than 1825.

But i'm interested in ffmpeg so i must use a newer version.

Is there any way to set 1773 only for ffmpeg and keeping 1576 for daily work with x264? Aside switching the avisynth files every time.

[MysteryX]

If you open the script with avs2yuv.exe and pipe into ffmpeg, then it won't care which version of AviSynth you're using.

[qyot27]

I'm testing a bit and it seems that 1576 is a bit faster than 1773 that is more faster than 1825.

But i'm interested in ffmpeg so i must use a newer version.

Is there any way to set 1773 only for ffmpeg and keeping 1576 for daily work with x264? Aside switching the avisynth files every time.
Put the AviSynth.dll from the r1773 package in the same directory as ffmpeg.exe.

[stranno]

Very useful, thanks both for the tips.

[real.finder]

and you can use MP_Pipeline and load 1576 dll in it
and use the script any where you want regardless of the version you have installed in the system

[NightSprinter]

This is odd, running a Core i7 920 (4 cores, 8 threads) with everything done as posted on the tutorial. However, when I enable prefetch, I get an error along the lines of "I don't know what 'zb' means". I'm using the latest AVS+ installer from the wiki page, and the filter script chain I'm using is the CRT simulation filter that's on this forum as well. I'm including the script in .txt format

[Reel.Deel]

This is odd, running a Core i7 920 (4 cores, 8 threads) with everything done as posted on the tutorial. However, when I enable prefetch, I get an error along the lines of "I don't know what 'zb' means". I'm using the latest AVS+ installer from the wiki page, and the filter script chain I'm using is the CRT simulation filter that's on this forum as well. I'm including the script in .txt format

Line 269 of the crt_display.avsi:
zb = mt_lut (y=0)
From your script it seems you're using MaskTools V2.0a48. This version is incompatible with AviSynth 2.6/AviSynth+, use the update version here (https://github.com/tp7/masktools/releases).

[NightSprinter]

I tried using the version you linked to, but it appears to be the same file if not smaller than the one included with AviSynth+. Using the linked file gives me the exact same error.

[real.finder]

I am playing back and forth between Avisynth 2.6.0MT and AviSynth+ 1825 MT, testing speed and image quality.

I went thru the following image corruption.

AviSynth output:
http://i.imgur.com/8MGljqrm.jpg (http://imgur.com/8MGljqr)

from script:
SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
SetMTMode(2)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)


AviSynth+ output:
http://i.imgur.com/PXXdVqam.jpg (http://imgur.com/PXXdVqa)
from script:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSourceIM", 3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\DGDecodeIM.dll")
DGSourceIM("E:\in\2_01 favoloso mondo di Amelie, Il\amelie.dgi",engine=1)
CompTest(1)
ChangeFPS(last,last,true)
Crop(0,132,0,-140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(4)
Any idea?

it will be better if you put a sample

I remember your problem after I remember http://forum.doom9.org/showpost.php?p=1675980&postcount=718 and play with that sample with http://www.mediafire.com/download/iw507kav586cp6t/ffms2-r734-libav-e6160bd.7z and reproduce it, with the last ffms2 can't reproduce, maybe this has relation to your problem

[tormento]

and reproduce it, with the last ffms2 can't reproduce, maybe this has relation to your problem

As you can see I don't use ffms2 but DGSourceIM

[martin53]

This filter
ColorBars(pixel_type="RGB32")
LoadVirtualDubPlugin("...\MSU_SmartDeblock_0.8.vdf","MSU_Smart_DeblockingVDF", 0)
MSU_Smart_DeblockingVDF(1, 1, 1, 1)
loads thanks to VDubFilter.dll (3/23/2015), but then crashes with System exception - Access Violation
(...vdcrash.avs, line 3)

Does anyone know of help? I feel I need MSU_SmartDeblock, and this keeps me once more from moving to Avisynth+.

The system is a Win7 uptimate x64 with only x86 Avisynth + plugins. The script and everything works with latest Avisynth 2.6 and Avisynth 2.6 MT.
Oh, and Avisynth+ is r1815-MT

[Groucho2004]

The system is a Win7 uptimate x64 with only x86 Avisynth + plugins. The script and everything works with latest Avisynth 2.6 and Avisynth 2.6 MT.
Oh, and Avisynth+ is r1815-MT
Works fine with the stable version of AVS+ (r1576).

[jihyo]

no function SetMTMode :( (and some others)

[Groucho2004]

no function SetMTMode
No, that's specific to SEt's MT builds.
Documentation for AVS+ can be found here (http://avisynth.nl/index.php/AviSynth%2B).

[jihyo]

No, that's specific to SEt's MT builds.

Got it.

Who can help me to update the code with SetFilterMTMode of AS+?
SetMTMode(6,#CPUS * 2)
SetMTMode(2)
LoadPlugin("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\Dependencies\svpflow1.dll")
LoadPlugin("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\Dependencies\svpflow2.dll")
Import("#PROGRAMDIR\AviSynth\plugins\InterFrame-2.8.2\InterFrame2.avsi")
InterFrame(Preset="Medium", Tuning="Animation", GPU=true, Cores=#CPUS)
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

[foxyshadis]

Get this script (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest), save it and import it. Remove all the *MTMode lines from the script you posted, and you're done. Avs+ handles the rest.

[qyot27]

Get this script (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest), save it and import it. Remove all the *MTMode lines from the script you posted, and you're done. Avs+ handles the rest.
The GetMTMode/Distributor line needs to be replaced with Prefetch(# of threads) to actually enable MT.

[siella]

I've got this error messega "There is no function named 'SSRC'"

[Groucho2004]

I've got this error messega "There is no function named 'SSRC'"
In AVS+, this function has been moved to an external plugin (shibatch.dll). When you install AVS+, this plugin would be copied to the auto-load directory an you should not receive that message.
You have to elaborate a bit in order troubleshoot this.
- Did you use the AVS+ installer?
- Which version are you using, 64 or 32 bit?
- Which program throws the error message?

[siella]

In AVS+, this function has been moved to an external plugin (shibatch.dll). When you install AVS+, this plugin would be copied to the auto-load directory an you should not receive that message.
You have to elaborate a bit in order troubleshoot this.
- Did you use the AVS+ installer?
- Which version are you using, 64 or 32 bit?
- Which program throws the error message?

Thanks i found avisynth+ with ssrc from megui

[Octo-puss]

So just out of curiosity, is this project dead and left abandoned in unfinished state as it appears?

[qyot27]

More like extended hiatuses. The same thing happened between March 2014 and February 2015.

IMO, this could be ameliorated by getting the support for GCC and Linux banged out, since that would expand the ability for collaboration. Properly getting it to play nice with GCC's braindead handling of intrinsics is something I've attempted to do a couple times but gotten sidetracked and haven't gone back.

[Octo-puss]

It's just that the last commit on Github is from december 2013, so one naturally assumes the project is dead :) If it's not the case, good.

[qyot27]

No, the last commit on Github is from March 2015. The master branch isn't the current development branch; MT is.

[THEAST]

I used the MT build 1689 for a while alongside with QTGMC without any issues and encoded a lot of videos. Later I switched to latest MT build 1825 but didn't encode anything for a while. Recently I started encoding again and realized that all my of encodes run into a deadlock very early into the job. After going back and force between builds 1689, 1779 and 1825, I noticed that even though the exact same script runs fine under 1689, it deadlocks under 1779 and 1825, while all of the three versions give more or less the same speed (checked with AVSMeter). Anybody has any idea about this? My scripts look like this:

1689:
SetMemoryMax(8000)
SetFilterMTMode("", 2)
#SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("video.d2v", info=3)
LoadPlugin("ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
TRIM(x,x)
crop(x,x,x,x)
QTGMC( Preset="Very Fast", x,x,x,x,x,x ).SelectEven()
Prefetch(6)

1779 & 1825:
SetMemoryMax(8000)
#SetFilterMTMode("", 2)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("DGDecode.dll")
DGDecode_mpeg2source("video.d2v", info=3)
LoadPlugin("ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
TRIM(x,x)
crop(x,x,x,x)
QTGMC( Preset="Very Fast", x,x,x,x,x,x ).SelectEven()
Prefetch(6)

[thescrapyard]

Reduce your memory, maybe your running out of memory. 8GB I think is a bit much, I use no more than 2GB (2048). Unless you have 32GB of memory. I've got 16GB and are now running with an i7 slightly overclocked

Try reducing the number of threads as I think each thread has its own memory requirements, maybe start at 2 threads and work up until it deadlocks again

[Groucho2004]

Recently I started encoding again and realized that all my of encodes run into a deadlock very early into the job. After going back and force between builds 1689, 1779 and 1825, I noticed that even though the exact same script runs fine under 1689, it deadlocks under 1779 and 1825
Start reading here (http://forum.doom9.org/showthread.php?p=1736090#post1736090) for a potential cause for your issue.

[THEAST]

Reduce your memory, maybe your running out of memory. 8GB I think is a bit much, I use no more than 2GB (2048). Unless you have 32GB of memory. I've got 16GB and are now running with an i7 slightly overclocked

Try reducing the number of threads as I think each thread has its own memory requirements, maybe start at 2 threads and work up until it deadlocks again

I have 16 GB of memory, I don't think Avisynth x86 can use more than 2 GB memory anyway, that number I am using is mostly for cosmetics. In my experience, on the latest builds, the code deadlocks even with two threads, it might just take longer. The only way to get it to work is to remove the "prefetch" line in which case the avisynth part of the work will run in single-threaded mode. Even in that case, the encode starts at something like 8 FPS but the speed gradually goes down until it becomes 1 FPS or so.

Start reading here (http://forum.doom9.org/showthread.php?p=1736090#post1736090) for a potential cause for your issue.

That doesn't seem to be a multi-threaded test, at least based on the reported CPU usage values. Still, it confirms my observations regarding the encoding speed going down with time using the latest builds. Do you guys recommend sticking with avisynth+ for MT or switching to normal Avisynth and SET's MT dll? I might try build r1765 later and see if the deadlock also happens there. I have a feeling this issue started when the syntax for setting default MT mode changed from "SetFilterMTMode("", 2)" to "SetFilterMTMode("DEFAULT_MT_MODE", 2)".

[Groucho2004]

I have 16 GB of memory, I don't think Avisynth x86 can use more than 2 GB memory anyway, that number I am using is mostly for cosmetics.
Cosmetics? WTF? RTFM.

All credit to ultim and the rest of the AVS+ dev team but the latest builds, particularly with MT and QTGMC(), are not stable. If you really have to multi-thread QTGMC(), use SEt's AVS MT.

Since you're using the "very fast" QTGMC() preset, I don't think you even need Avisynth(+) MT. Some of the filters are already internally multi-threaded. Your bottleneck is most likely the encoding.

For reference, here (http://forum.doom9.org/showthread.php?p=1758254#post1758254) are some benchmarks with SEt's AVS MT.

[THEAST]

Cosmetics as in that amount is supposed to be some absolute maximum that avisynth+ is never going to reach; trying to follow the "better safe than sorry" approach, even though it might not make much sense here. My script seems to use 400-500 MB of memory with 6 threads, on build 1689.

Regarding QTGMC, I am not actually using the Very Fast preset out of the box. The preset just acts as a baseline and I have like 15-20 of QTGMC's options manually set (I removed them here for the sake of brevity), which I will modify based on the source or encoding speed constraints. The final result is something along the lines of slow or very slow.

I remember I did some comparison between Avisynth+ MT and SEt's MT build a while back and the former was quite a bit faster and hence, I stuck with Avisynth+. It was before Avisynth v2.6.0 final, though. Maybe I should take a look at SEt's MT build's performance again.

[Groucho2004]

Cosmetics as in that amount is supposed to be some absolute maximum that avisynth+ is never going to reach; trying to follow the "better safe than sorry" approach
Had you read the documentation for SetMemoryMax (http://avisynth.nl/index.php/Internal_functions/SetMemoryMax#SetMemoryMax) you would know that your interpretation of the purpose of that function is completely wrong. You should hardly ever have to set it to more than about 1000.

[THEAST]

Had you read the documentation for SetMemoryMax (http://avisynth.nl/index.php/Internal_functions/SetMemoryMax#SetMemoryMax) you would know that your interpretation of the purpose of that function is completely wrong. You should hardly ever have to set it to more than about 1000.

Hmm, okay, I will change the value that I am using, thanks for the tip.

[pinterf]

Hello,

Last week I was starting to play with avs+ source, specifically with the MT branch because I was interested in the background of the slowdown issue.
The issue was probably solved, but before I upload test dlls I would like to ask some questions.

Question#1

I'm working with VS2015 on 64 bit Windows 7.
I have cloned the MT branch, run cmake and built x86. After minor modifications I succeeded.
Then tried to build x64 but this configuration did not exist, so I created one from VS Configuration manager. Linking was not successful, because the machine type of obj files did not match the linking target, even if I set it explicitly in the project properties (under Linker, target machine type).
LNK1112: module machine type 'x64' conflicts with target machine type 'X86'
I think that the generated cmake configuration is overriding this setting.

The only workaround I found was the following:

Compile for x86:
download cmake x86
delete CMakeCache.txt from project root
run cmake-gui from c:\Program Files (x86)\cmake\bin
choose directories
configure
Specify the generator for this project: Visual Studio 14 2015
(appears /machine=x86 in xxxxx_LINKER_FLAGS)
generate
Start visual studio, only Win32 is available: build.

Compile for x64:
download cmake x64
delete CMakeCache.txt from project root
run cmake gui from c:\Program Files\cmake\bin
choose directories
configure
Specify the generator for this project: Visual Studio 14 2015 Win64
(appears /machine=x64 in xxxxx_LINKER_FLAGS)
generate
Start visual studio, only x64 is available: build.

My question is that how can I tell cmake to generate the solution for both Win32 and x64 targets?

Question#2
Forgive me, I am new to git and these open source things (it was a whole day for me to see only MT branch as a separete source :) ), what is the usual workflow if I'd like to participate in the project?
Fork the project to my git account, and make modification inside it? Clone it?
How is it done if I put a lot of debug mess in my source (and don't want to remove it on my side) but the original project does not need them? Can the owner of the main project merge only specific lines?

Question#3
When I build the dll's they have the very same version (build number, etc. as the latest 'official' release. Version.h is autogenerated by some magic cmake thing.
How can I specify this version manually? E.g. 1825-test instead of 1825?

Thank you and sorry for the lame questions :)

[LigH]

Just a small remark: hg (Mercurial) is not completely equal to git.

[Reel.Deel]

Hello,

Last week I was starting to play with avs+ source, specifically with the MT branch because I was interested in the background of the slowdown issue.
The issue was probably solved, but before I upload test dlls I would like to ask some questions.


Awesome, I'll gladly help out with testing. Hopefully someone comes along and answer your other questions.

[qyot27]

My question is that how can I tell cmake to generate the solution for both Win32 and x64 targets?
There's no need to. AviSynth+'s build system is via CMake, not MSVC project files. CMake doesn't work this way (to my knowledge). It certainly would cause problems for the other generators - NMake and Ninja - that you can use with MSVC's compilers.

And you don't need 64-bit CMake to do this either, since the Win64-specific generator calls in the correct MSVC toolchain regardless of what CMake is.

Question#2
Forgive me, I am new to git and these open source things (it was a whole day for me to see only MT branch as a separete source :) ), what is the usual workflow if I'd like to participate in the project?
Fork the project to my git account, and make modification inside it? Clone it?
How is it done if I put a lot of debug mess in my source (and don't want to remove it on my side) but the original project does not need them? Can the owner of the main project merge only specific lines?
This is the usual for git projects:
Clone project
Create new branch with descriptive name
Make modifications, commit changes (broken up topically, usually).
Submit pull request (Github) or patchset (on mailing list oriented projects) to upstream.
Upstream reviews patches, suggests changes, and either allows the user to fix those in the patchset or sometimes upstream does it after merging it.
If you want to 'put a lot of debug mess in my source (and don't want to remove it on my side)', I'd suggest keeping a branch specifically *for* that, and having a pull request-ready branch with the actual changes but without the debug stuff.

Also remember that AviSynth+ is extraordinarily unlikely to accept compiler-specific stuff, what with sporadic efforts to move beyond MSVC for compilation. See the coding guidelines (http://avs-plus.net/coding-guidelines.php) for more general information on what should or should not be acceptable.

Question#3
When I build the dll's they have the very same version (build number, etc. as the latest 'official' release. Version.h is autogenerated by some magic cmake thing.
How can I specify this version manually? E.g. 1825-test instead of 1825?
Don't do that. Make sure the CMake versioning generator is working correctly and allow it to do its job. If you want to keep your branched DLLs straight, I'd put the branch name in the filename of the archive you pack the DLLs in.

[qyot27]

On a quasi-related note, I've been meaning to check the build instructions I posted before (http://forum.doom9.org/showpost.php?p=1643929&postcount=7) against VS Community 2015, but haven't gotten around to it. They still should work, just change the -G parameter (and optionally the -T parameter if XP support still matters to you) to the correct name.

[pinterf]

This is the usual for git projects:
Clone project
Create new branch with descriptive name
Make modifications, commit changes (broken up topically, usually).
Submit pull request (Github) or patchset (on mailing list oriented projects) to upstream.
Upstream reviews patches, suggests changes, and either allows the user to fix those in the patchset or sometimes upstream does it after merging it.
If you want to 'put a lot of debug mess in my source (and don't want to remove it on my side)', I'd suggest keeping a branch specifically *for* that, and having a pull request-ready branch with the actual changes but without the debug stuff.


Thank you, suppose you mean "fork" in the first step?

Regarding the multi target make file, I have read your instructions, but I was hoping that CMake evolved in the last one or two years to do that.

Just recognized that VS2015 has git integration.
Now it points to the official MT repository, tell me that I cannot do any harm (commit, false merge) to that, wherever I click with my mouse to :)

[LigH]

No, "clone" means "get a copy from the remote repository to your local working directory" in git slang (CVS or SVN use "checkout", IIRC).

[pinterf]

After two weeks of learning curve, I have uploaded a new avs+ build, both 32 and 64 bit MT dlls.

This build is primarily for addressing the huge slowdown issue of recent MT builds.

Please give it a try.

AviSynth+ r1828-pfmod (http://www.mediafire.com/download/csrdoqj5tesi640/avsplus1828-pfmod.7z)

I have no slowdowns (none or very minor), so longer clips could be tested: QTGMC fast with a 92 minutes DV-AVI source.

Some notes.

The artificial test case of colorbars is not quite good, although it allowed me to find out the main cause of the slowdown. Colorbars is using a static source framebuffer that is kept referenced throughout the whole qtgmc process, so its ref_count will never be released. During the qtgmc script the framebuffer-reusing logic had to iterate many hundred thousand (!) entries until it would find a free entry or see that no free buffer exists. After thousands of frames, one failed lookup needed almost 0.03 seconds (normally it should lookup 1000-10000x faster!), and it got linearly worse.

Todo: "hack" or parameterize colorbar to be able to generate new frames: copy the pre-generated pattern into a brand new frame instead of just linking to it.

Having no slowdown I realized the next problem: framebuffers sometimes are not released.

Example.
The first 17800 frames of an AVI source needs approx. 200 MBytes of framebuffers to deinterlace with Qtgmc, number of framebuffers is 300. Suddenly avs+ cannot find any buffers that has reference count 0 and starts allocating new framebuffers. Reaching the 20000 frames limit (that is 40000 frames after Qtgmc) we need already 500MB, so with SetMemoryMax(512) the script is soon exiting.

And later the memory consumption goes up in waves.

40525 frames (81050 QTGMC): 973 framebuffers, 613MB
49381 frames (99600 QTGMC): 1178 framebuffers, 745MB
56725 frames (113450 QTGMC): 1255 framebuffers, 816MB
61046 frames (122092 QTGMC): 1348 framebuffers, 876MB
65084 frames (130168 QTGMC): 1508 framebuffers, 980MB
68988 frames (137978 QTGMC): 1736 framebuffers, 1128MB
114512 frames (129024 QTGMC): 2121 framebuffers, 1376MB
etc...

Good news: my 1h32min 720x576 dv-avi video - that has finally 278000 50p frames - just succeeded with the SetMemoryMax(2048) setting. Needed approx. 1700MB memory.

But it can be done with much less memory.
Whick plugin or avs core logic is getting those frames stuck?
Have to figure out, how. Seems it is not related to MT.

Script (+having rgtools, mvtools2, masktools2.dll and nnedi3.dll in the plugins64 directory)

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
SetMemoryMax(2048)
#colorbars(width = 640, height = 480, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 29999)
Avisource("c:\tape13\Videos\Tape02_digitall_Hi8.avi").killaudio().assumefps(25,1)#.trim(0, 29999)
AssumeBFF()
QTGMC(Preset="Fast")
prefetch(3)

[ryrynz]

Gosh, might we finally have an MT build stable enough to use as a replacement to SEt's MT? Or perhaps sometime soon? Nice to see some progress finally!
Will see how it fares, thanks for the considerable contribution!

[LigH]

Your efforts are very appreciated, pinterf.

:thanks:

[pinterf]

One note, my mod was built with VS2015, v140_xp toolset.
I have no "virgin" machine, so it works out-of-box for me. It may require Visual C++ Redistributable for Visual Studio 2015 Update 1 (https://www.microsoft.com/en-us/download/details.aspx?id=49984) for you.

[Reel.Deel]

After two weeks of learning curve, I have uploaded a new avs+ build, both 32 and 64 bit MT dlls.

This build is primarily for addressing the huge slowdown issue of recent MT builds.

Please give it a try.

AviSynth+ r1828-pfmod (http://www.mediafire.com/download/csrdoqj5tesi640/avsplus1828-pfmod.7z)

I have no slowdowns (none or very minor), so longer clips could be tested: QTGMC fast with a 92 minutes DV-AVI source.
.....


Thanks pinterf! Any comments on what was the problem, or how did you fix it? Just curious if it had anything to do with this (http://forum.doom9.org/showthread.php?p=1736551#post1736551).

I ran the same test (http://forum.doom9.org/showthread.php?p=1736090#post1736090) as I did when the issue was first discovered. So far it's looking good, r1576 is still faster but that has always been the case. Here's the results:

[General info]
Log file created with: AVSMeter 2.1.5 (x86)
Script file: M:\AviSynth+ Testing\Regression\AviSynth+ r1828 pfmod.avs
Avisynth version string: AviSynth+ 0.1 (r1828, MT-pfmod, i386)
Avisynth file version: 0.1.0.0
Avisynth Interface Version: 6
Avisynth MT support: Yes
Avisynth.dll linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth.dll time stamp: 2016-03-29, 07:50:15
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[Clip info]
Number of frames: 43596
Length (hh:mm:ss.ms): 00:12:07.327
Frame width: 720
Frame height: 480
Framerate: 59.940 (60000/1001)
Colorspace: YV12



[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 5.967 | 174.4 | 19.99
Memory usage (phys | virt): 166 | 175 MB
Thread count: 38
CPU usage (average): 10%
Efficiency index: 1.999
Time (elapsed): 00:36:21.112


[Script]
SetMemoryMax(1024)
LWLibavVideoSource("S:\ITAS_Chappelle\VIDEO_TS\VTS_02_1.demuxed.m2v")
AssumeTFF()
QTGMC(Preset="slow")

http://s22.postimg.org/dzout8kfj/Avi_Synth_r1828_pfmod.png

[pinterf]

The FrameRegisty concept is a brilliant idea which helps avs core to reuse released frames and their video frame buffers (vfb) to recycle thus keeping the memory consumption low.

Why allocate new framebuffer when we can use an existing one that no process uses anymore.

When a frame and its vfb is created, their pointers are inserted in a list. That is FrameRegistry. For faster lookup it is "indexed" based on the requested size.

For subframes, only the frame object is created, but its vfb is just linked to the parent's vfb.

How the recycle logic works?

Both frames and their vfbs are reference counted.

A frame can be re-used if its refcount _and_ its vfb's refcount is zero. So when a new frame is created, first we lookup in the list of the frames with vfb's that have the required size.

We are linearly searching through the list, until we find a frame with zero refcount, then we check if it's vfb is zero or not. And that is where there is a problem in real-life.

QTGMC process creates many-many subframes. All these subframes share the same vfb. Creating subframes is fast. All we need is "abusing" pitch and rowsize.

To imagine: this is a small example how multiple frames share the same vfb. In the colorbars example, there are thousands of frame entrys for a single vfb (e.g. 300000+ frames if the frame count is big enough!)
Personally it took me some hours to understand what a subframe is, but now I like the concept :)
frame 000000000AF050A0 RowSize=720 Height=576 Pitch=736 Offset=16
frame 000000000B1771F0 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 000000000B177270 RowSize=360 Height=144 Pitch=768 Offset=534928
frame 000000000B1772F0 RowSize=360 Height=144 Pitch=768 Offset=424336
frame 000000000B177370 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 000000000B1773F0 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 000000000B177470 RowSize=360 Height=144 Pitch=768 Offset=534544
frame 000000000B1774F0 RowSize=360 Height=144 Pitch=768 Offset=423952
frame 000000000B177570 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF17B0 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF1830 RowSize=360 Height=144 Pitch=768 Offset=534928
frame 0000000013FF18B0 RowSize=360 Height=144 Pitch=768 Offset=424336
frame 0000000013FF1930 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF19B0 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF1A30 RowSize=360 Height=144 Pitch=768 Offset=534544
frame 0000000013FF1AB0 RowSize=360 Height=144 Pitch=768 Offset=423952
frame 0000000013FF1B30 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF2E30 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF2EB0 RowSize=360 Height=144 Pitch=768 Offset=534928
frame 0000000013FF2F30 RowSize=360 Height=144 Pitch=768 Offset=424336
frame 0000000013FF2FB0 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF3030 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF30B0 RowSize=360 Height=144 Pitch=768 Offset=534544
frame 0000000013FF3130 RowSize=360 Height=144 Pitch=768 Offset=423952
frame 0000000013FF31B0 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF44B0 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF4530 RowSize=360 Height=144 Pitch=768 Offset=534928
frame 0000000013FF45B0 RowSize=360 Height=144 Pitch=768 Offset=424336
frame 0000000013FF4630 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 0000000013FF46B0 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 0000000013FF4730 RowSize=360 Height=144 Pitch=768 Offset=534544
frame 0000000013FF47B0 RowSize=360 Height=144 Pitch=768 Offset=423952
frame 0000000013FF4830 RowSize=720 Height=288 Pitch=1472 Offset=16
frame 00000000067F15B0 RowSize=720 Height=288 Pitch=1472 Offset=752
frame 00000000067F1630 RowSize=360 Height=144 Pitch=768 Offset=534928
frame 00000000067F16B0 RowSize=360 Height=144 Pitch=768 Offset=424336
frame 00000000067F1730 RowSize=720 Height=288 Pitch=1472 Offset=752
etc...


So frame count exceeds vfb count by a huge margin.

Most of the frames then are released.
Finally we have a frame list, in which (r1825MT frequent worst case) the frame refcount is already zero, but their (very same) vfb's refcount is not. Frames get into the queue, they are finally released, but their vfb is not.

The lookup process iterates in the frame list linearly through hundreds of thousands lines, but may find not a single frame with vfb refcount zero.

The lookup time is growing seriously, nearing to the 1/10 second range, instead of the initial microseconds.

So I took a reverse approach.

In the source I named it FrameRegistry2, I still left the original FrameRegistry declaration (but do not use it anymore).

Instead of frame list, let's have a list of vfb's, and under them, a frame list that are referencing this vfb.

When a vfb is not free (refcount > 0), we can freely ignore checking all the frames owning it. No need for iterating this huge frame list, only the vfb list. It is true, that once a vfb has zero refcount, all frames owning it has also zero refcount. Thus we can simply reuse the first frame and its free vfb, and delete all the other frame objects previously owning the specific vfb. (This can still be made faster, in this r1828 release it's not optimal)

The complexity of the search is still linear, but we are iterating through some hundred of vfb's instead of hundreds of thousands of frames.

typedef std::multimap<size_t, VideoFrame*> FrameRegistryType;

typedef std::list<VideoFrame*> VideoFrameArrayType;
typedef std::map<VideoFrameBuffer *, VideoFrameArrayType> FrameBufferRegistryType;
// P.F. tried vector instead of list http://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html
// but in our case it is slower than std::list
typedef std::map<size_t, FrameBufferRegistryType> FrameRegistryType2; // P.F.


It's a long story but I hope it cleared some of the technical background.

P.S.
another very useful thing I learned

std::chrono::time_point<std::chrono::high_resolution_clock> t_start, t_end;
t_start = std::chrono::high_resolution_clock::now();
..process to profile..
t_end = std::chrono::high_resolution_clock::now();
std::chrono::duration<double> elapsed_seconds = t_end - t_start;

[stax76]

Awesome to see some progress, maybe somebody can also help with making QTGMC work with StaxRip x64 and Windows 10. In managed (.NET) x64 hosts under Windows 10 mvtools2 causes a access violation. I can give a reward of 50€/56$ for making it work.

edit:

mvtools2 issue was fixed by pinterf!

[StainlessS]

Pinterf, excellent work and explanation of the problem, made for very interesting reading.
Go sit yourself down and have a well earned glass of port. :)

[Groucho2004]

One note, my mod was built with VS2015, v140_xp toolset.
I have no "virgin" machine, so it works out-of-box for me. It may require Visual C++ Redistributable for Visual Studio 2015 Update 1 (https://www.microsoft.com/en-us/download/details.aspx?id=49984) for you.Unfortunately, WinXP compatibility is broken. It chokes when initializing IScriptEnvironment. I tried the usual tools, VirtualDub, mpc-hc, AVSMeter.

Neither Dependency Walker nor PE Explorer reveal any incompatibilities with XP. Weird.

[qyot27]

Just one comment on the commits (https://github.com/pinterf/AviSynthPlus/commits/MT-pfmod): AviSynth+ uses (preferably 4x) spaces for indentation; no tabs. This is stated in the coding guidelines I linked to earlier.

[pinterf]

Thank you qyot27, I will check it.

[pinterf]

Unfortunately, WinXP compatibility is broken. It chokes when initializing IScriptEnvironment. I tried the usual tools, VirtualDub, mpc-hc, AVSMeter.

Neither Dependency Walker nor PE Explorer reveal any incompatibilities with XP. Weird.
Dunno, I found this topic:
http://forum.doom9.org/showthread.php?t=172400

[Groucho2004]

Dunno, I found this topic:
http://forum.doom9.org/showthread.php?t=172400
No, that's not it. I have the latest re-distributable packages installed.

[pinterf]

Help. Windows 10 is too smart, and is trying to protect me from myself :)
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?

[stax76]

Help. Windows 10 is too smart, and is trying to protect me from myself :)
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?

I've never heard or experienced something like this, maybe ProcessExplorer could help since it can show the paths of DLLs used by a process.

[Groucho2004]

Help. Windows 10 is too smart, and is trying to protect me from myself :)
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?
"AVSMeter64 -avsinfo" shows you the path to the avisynth.dll it loads. What does it show?

[pinterf]

"AVSMeter64 -avsinfo" shows you the path to the avisynth.dll it loads. What does it show?
Machine is not stupid. Lazy non-commandline man is.
I made the copy from a 32 bit Total Commander, that shows c:\windows\SysWOW64 content under c:\windows\system32. And I always worked into that. Grrr.

[Groucho2004]

Machine is not stupid. Lazy non-commandline man is.
I made the copy from a 32 bit Total Commander, that shows c:\windows\SysWOW64 content under c:\windows\system32. And I always worked into that. Grrr.
Yeah, I had that problem before. The only reliable way to get the correct system32/syswow64 directories across all Windows versions is to go through "CreateFileMapping()", "MapViewOfFile()", "GetLogicalDriveStrings()", "QueryDosDevice()".
Have a look at the "GetFileNameFromHandle()" function in AVSMeter's source (AvisynthInfo.h).

I didn't expect Total Commander would fall into that trap.

[manolito]

That's one of the most important reasons why I still love WinXP. I just hate it to no end when the operating system lies to me about the true location of my files.

[Groucho2004]

That's one of the most important reasons why I still love WinXP. I just hate it to no end when the operating system lies to me about the true location of my files.
The GetModuleFileName() WoW64 redirection issue is also present in XP64 and Server 2003 x64. Apparently, it was fixed in Win7 and re-appeared in Win8 (and, it would seem, Win10).

Some info in the comment section here (https://technet.microsoft.com/en-us/library/ms683197.aspx).

[thescrapyard]

Help. Windows 10 is too smart, and is trying to protect me from myself :)
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?


Disable UAC, no nagging prompts about allowing things to run everytime, even if software runs correctly it will keep poping up until it 'learns' whats safe and isn't. Turn it OFF and everything is considered safe. Also block software calling other software, such as AviSynth calling plugins etc etc from non-standard file locations outside windows 10 control


http://winaero.com/blog/how-to-turn-off-and-disable-uac-in-windows-10/

Your virus software should protect you from any nasties


I've just sorted my daughters brand new laptop that came with Win10. First thing I did was disable UAC and installed decent security suite and Office so she's happy now

[Groucho2004]

Disable UAC
:confused: What does this have to do with the redirection issue?

[AzraelNewtype]

Nothing, it's just some stunningly bad advice.

[TheFluff]

Yeah, I had that problem before. The only reliable way to get the correct system32/syswow64 directories across all Windows versions is to go through "CreateFileMapping()", "MapViewOfFile()", "GetLogicalDriveStrings()", "QueryDosDevice()".
Have a look at the "GetFileNameFromHandle()" function in AVSMeter's source (AvisynthInfo.h).

I didn't expect Total Commander would fall into that trap.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365743(v=vs.85).aspx

hope this helps

Help. Windows 10 is too smart, and is trying to protect me from myself :)
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?

It's 2016, stop dumping random dll's into system folders. There's absolutely no reason for you to be mucking around in there. Then again it's not really your fault, Avisynth should have stopped putting the dll in there in the first place like four major Windows versions ago.

[Groucho2004]

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365743(v=vs.85).aspx

hope this helps
Been there, done that. I have had the same frustrating experience with "Wow64DisableWow64FsRedirection()" as the user who reported in the comment section of "GetModuleFileName()" on technet. It just does not work, at least not for every OS.

[TheFluff]

Been there, done that. I have had the same frustrating experience with "Wow64DisableWow64FsRedirection()" as the user who reported in the comment section of "GetModuleFileName()" on technet. It just does not work, at least not for every OS.

wontfix: working as intended. if you use xp64 you deserve to suffer.

[Groucho2004]

if you use xp64 you deserve to suffer.I didn't expect any other reply from you. :)

[Groucho2004]

It's 2016, stop dumping random dll's into system folders. There's absolutely no reason for you to be mucking around in there. Then again it's not really your fault, Avisynth should have stopped putting the dll in there in the first place like four major Windows versions ago.
Where else would you put it?

Let's explore the options:
1. System32/SysWoW64
Every client can find and load avisynth.dll, be it 32 or 64 bit. 32 and 64 bit Avisynth can both be installed.

2. Any directory that is referenced in the "PATH" environment variable.
The installer would need to parse the PATH environment and then ask the user where it should be placed. Also, this only works for either 32 or 64 bit.

You decide which one is better.

[TheFluff]

It doesn't need to be on the $PATH (actually, it shouldn't be on it). It's kinda late to do anything about all the ancient third-party software now, but the Right Thing is to just install into whatever folder the user chooses and use a registry key (different ones for 32- and 64-bit, obvs) to point to its location. VS does this. VfW programs can still load it as normal and everything that needs to interface with the DLL directly can find it via the registry key (or by letting the user point it out, if you want a portable version). Installing it globally was acceptable when Avisynth was designed (and you kinda had to do it, AFAIK?) but it's an all around awful idea. It's one of the many things Avs+ should've broken backwards compatibility with when they had the chance.

2. Any directory that is referenced in the "PATH" environment variable.
The installer would need to parse the PATH environment and then ask the user where it should be placed. Also, this only works for either 32 or 64 bit.
I haven't tried it, but the internet claims that if you have a 32-bit lib in one dir and the same lib except 64-bit in another dir, and both those dirs are on the $PATH, LoadLibrary is smart enough to figure out which one to grab for your process. Not that it's a thing you should do.

[Groucho2004]

It doesn't need to be on the $PATH (and probably definitely shouldn't be). It's kinda late to do anything about all the ancient third-party software now, but the Right Thing is to just install into whatever folder the user chooses and use a registry key (different ones for 32- and 64-bit, obvs) to point to its location. VS does this. VfW programs can still load it as normal and everything that needs to interface with the DLL directly can find it via the registry key (or by letting the user point it out, if you want a portable version). Installing it globally was acceptable when Avisynth was designed (and you kinda had to do it, AFAIK?) but it's an all around awful idea. It's one of the many things Avs+ should've broken backwards compatibility with when they had the chance.
Not sure what you mean by "ancient third party software". Pretty much every client program that uses Avisynth loads avisynth.dll through "LoadLibrary()" implicitly, i.e. without specifying a fully qualified path. If avisynth.dll is not in one of the directories included in the standard Windows search hierarchy, it fails to load.
Therefore, the code of each of these clients (VDub, AVSP, x264, mpc(hc), ...) would have to be changed.

And yes, in hindsight it may have been a good idea to use registry pointers.

[thescrapyard]

:confused: What does this have to do with the redirection issue?

Just trying to be slightly helpful and assumed the problem was windows deciding it knew best and thought it was blocking the DLL being put where he wanted it to be and the software was looking for it, as has happened to me when the OS thought everything was a suspicious file so either silently blocked it or poppingup nag requesters asking if its OK to run when installed software that calls other software

Such as AviSynth or other ones I use such as AVStoDVD that also had issues in the past. Not with the package but UAC blocking everything from running and permissions aggravation

[edcrfv94]

Scripts add to ffdshow with r1828-pfmod have no effect.

[LigH]

I have no clue, but wonder if ffdshow possibly supports only an outdated API version and may not be compatible with AviSynth+ regarding internal post-processing scripts?

[chainik_svp]

That commit (https://github.com/AviSynth/AviSynthPlus/commit/ec72100460f7ad5eb7ed22c599a20fe44a154805) broke ffdshow.
It's impossible now for ffdshow to add a function into ScriptEnv.

PluginManager::AddFunction()
...
newFunc = AVSFunction(name, NULL, params, apply, user_data);
assert(newFunc.IsScriptFunction());

...

AVSFunction::AVSFunction(const char* _name, const char* _plugin_basename, ...)
...
if ((NULL != _name) && (NULL != _plugin_basename))

[jpsdr]

One note, my mod was built with VS2015, v140_xp toolset.
I have no "virgin" machine, so it works out-of-box for me. It may require Visual C++ Redistributable for Visual Studio 2015 Update 1 (https://www.microsoft.com/en-us/download/details.aspx?id=49984) for you.

Unfortunately, XP support is partialy broken in VS2015, and it's still the case with Update 2.
For having a proper support of XP, as it's explained here (https://connect.microsoft.com/VisualStudio/feedback/details/1789709/visual-c-2015-runtime-broken-on-windows-server-2003-c-11-magic-statics), you have to compile with the /Zc:threadSafeInit- option, otherwise it will not work.
My advice would be, if you want to support XP, to make 2 builds.
One generic with v140 toolset and no XP support, and another XP support specific, with v140_xp toolset and the /Zc:threadSafeInit- option.

[bxyhxyh]

Help. Windows 10 is too smart, and is trying to protect me from myself
I have troubles to put properly avisynth.dll into c:\windows\system32.
Once I had there an r1825 version, then I copied the r1828 over it.
Avsmeter64 is still showing avisynth+ version r1825.
Then I purged avisynth.dll from c:\windows\system32.
And a (not so big) surprise: avs scripts are still running fine using a ghost r1825. Where is this dll cache? How can I tell windows 10 to clear all historical use of avisynth.dll?

When I was trying to use Groucho's avisynth switching tool, I had similar issue (http://forum.doom9.org/showthread.php?p=1716779#post1716779)
For your case, isn't it in syswow64 folder?
Anyway If it's 64bit Windows, shouldn't you replace syswow64's dll?
I don't know if it would help you since you guys are professional programmers.

[asarian]

When I was trying to use Groucho's avisynth switching tool, I had similar issue (http://forum.doom9.org/showthread.php?p=1716779#post1716779)
For your case, isn't it in syswow64 folder?
Anyway If it's 64bit Windows, shouldn't you replace syswow64's dll?
I don't know if it would help you since you guys are professional programmers.

The 32-bit AviSynth DLL goes into the syswow64 folder (and vice versa). Don't ask me why, but that's how it works. :)

[pinterf]

When I was trying to use Groucho's avisynth switching tool, I had similar issue (http://forum.doom9.org/showthread.php?p=1716779#post1716779)
For your case, isn't it in syswow64 folder?
Anyway If it's 64bit Windows, shouldn't you replace syswow64's dll?
I don't know if it would help you since you guys are professional programmers.
The solution was using 64bit Total Commander because 32 bit version was showing the syswow64 folder content while pretending that i am in system32.

Tapatalkkal küldve az én GT-I9195I eszközömről

[Groucho2004]

The 32-bit AviSynth DLL goes into the syswow64 folder (and vice versa). Don't ask me why, but that's how it works. :)
64 Bit Windows versions have a 32 bit sub-system called WoW64. It stands for "Windows on Windows64" which makes it possible to run 32 bit processes/applications on 64 bit Windows. I suppose it would be less ambiguous if it was called "W32oW64" or similar. So, "SysWoW64" is the system directory for 32 bit DLLs called by 32 bit processes on 64 bit Windows.

The issue that pinterf had was rectified, it had to do with inconsistent behaviour of file system redirection functions in the Windows API across various Windows versions.

[pinterf]

Unfortunately, XP support is partialy broken in VS2015, and it's still the case with Update 2.
For having a proper support of XP, as it's explained here (https://connect.microsoft.com/VisualStudio/feedback/details/1789709/visual-c-2015-runtime-broken-on-windows-server-2003-c-11-magic-statics), you have to compile with the /Zc:threadSafeInit- option, otherwise it will not work.
My advice would be, if you want to support XP, to make 2 builds.
One generic with v140 toolset and no XP support, and another XP support specific, with v140_xp toolset and the /Zc:threadSafeInit- option.
Thank you, it works! Without the option (with the "-" at the end, first I missed it) I get a fine 0xC0000005.
(I realized that I have a Virtual XP in my Win7Prof).
I will make a build later, since I made more debug mess in the code than you can imagine.

Some progress:
Last week I tried to narrow down the random-increasing memory consumption problem that I wrote earlier about. Frankly I was getting mad. The problem occured only when passing the 35800th frame and also from that time on in random waves. It's not easy to debug something that first appears after 15-20 minutes of running. This problem does not occur with colorbars, nor with a modded (non-static base frame) colorbars.
Only with a DV-AVI. I already debugged the cache system (nice one :-)), put timestamps to each framebuffer registration to see which frames got stuck and did not get reused in the last 10 seconds.

Yesterday I happily realized that it happens both with avisource or ffms2 so I could exclude them from the culprit list.

After one week I found out that the behaviour is not time-dependent, today I made a brave Trim() :) from before the problematic frames and wonder! it started to eat memory from the same source frames. All I know that these frames have heavy camera shake.

So it seems that one of the plugins in qtgmc(Fast) is leaking frames under these speficic circumstances.

At least now I don't have to wait forever for the problem to occur.

[LigH]

Tested with AviSynth+ r1825 MT and r1828-pfmod (MSVC2015 Redist installed):

LoadPlugin("E:\Programme\AviSynth 2.5\plugins\LSMASHSource\LSMASHSource.dll")
a=LwLibavAudioSource("truehd.mka").AssumeFPS(50,1)
v=ColorBars(1280,720,"YV12").AssumeFPS(50,1).Trim(0,Round(a.AudioDuration*50.0))
AudioDub(v,a)
Info()
Histogram(mode="Audiolevels")

crashes upon loading; AVSMeter (and VirtualDubMod similarly) report:

AVSMeter 2.1.6 (x86)
AviSynth+ 0.1 (r1828, MT-pfmod, i386) (0.1.0.0)

System exception - Integer Divide by Zero
(H:\Video\Test\truehd.avs, line 6)

It works when I comment out the Histogram() command in line #6.

In original AviSynth up to v2.6.0 MT final, it loads the TrueHD track with 8 channels and displays audio levels overlayed.

[Reel.Deel]

System exception - Integer Divide by Zero


raffriff42 posted similar problems a while back also. Take a look at post #1251 through #1253 (http://forum.doom9.org/showthread.php?p=1737382#post1737382).


@pinterf
If is not a big deal, can you include PR #64 (https://github.com/AviSynth/AviSynthPlus/pull/64) with your next build?

[Chikuzen]

https://github.com/AviSynth/AviSynthPlus/pull/65/commits/9b1745694e6d527cad04d8a8f3625dde2a736b87

https://dl.dropboxusercontent.com/u/19797864/forum/fix_audio.jpg

[pinterf]

Ok. I will check it.

[pinterf]

Avisynth+ r1841-pfmod

http://www.mediafire.com/download/eadynn3jpv720jl/avsplus-r1841-pfmod.7z

From readme:

AvisynthPlus r1841-pfmod
2016.04.08
- TemporalSoften frame leak fix (short to write but it took me 30 hours :) )
- minor FrameRegistry2 tunings
- PR #64 rgb24<->rgb32 ssse mod: https://github.com/AviSynth/AviSynthPlus/pull/64
- PR #65 Fix audio cache #65 (Chikuzen)
- Colorbars new parameter: Boolean staticframes
true (default): returns the precalculated static frame's pointer
false: copies the precalculated frame into a new frame and returnes this new frame pointer
- XP versions: v140_xp toolset with extra C++ commandline option /Zc:threadSafeInit-

Very good memory consumption
r1841:
QTGMC(Fast) on x64 + Prefetch(8) + 720x576 DV-AVI Source = 350-400 MB

r1828:
QTGMC(Fast) on x64 + no MT + 720x576 DV-AVI Source = 200->1900 MB increasing

Please test it, good night!

[TheFluff]

7z files on mediafire isn't a reasonable way to contribute to open source projects in 2016. Please consider putting your stuff on github so other people can easily backport your changes to the official repo or to their own forks if they want.

e: oh wait your source isn't even in the 7z. Not that anyone cares, but you should really put it up somewhere or you're technically violating the GPL.

[Reel.Deel]

Avisynth+ r1841-pfmod

http://www.mediafire.com/download/eadynn3jpv720jl/avsplus-r1841-pfmod.7z


Thanks pinterf! Will definitely test it out.


7z files on mediafire isn't a reasonable way to contribute to open source projects in 2016. Please consider putting your stuff on github so other people can easily backport your changes to the official repo or to their own forks if they want.

e: oh wait your source isn't even in the 7z. Not that anyone cares, but you should really put it up somewhere or you're technically violating the GPL.

It's already on GitHub: https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod

[raffriff42]

It's fixed my little complaint, so I can come back to AVS+. Thanks pinterf!

[TheFluff]

It's already on GitHub: https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod
Oh okay, sorry. I didn't see it in the fork list for some reason.

[chainik_svp]

ffdshow fix: https://github.com/pinterf/AviSynthPlus/pull/1

sadly memory leak when the script environment is re-inited by the ffdshow 64-bit still not fixed... (while it can be a ffdshow's issue)

[Groucho2004]

sadly memory leak when the script environment is re-inited by the ffdshow 64-bit still not fixed... (while it can be a ffdshow's issue)
I'd say it's definitely a ffdshow issue. ffdshow initialises IScriptEnvironment in several places and releases it with "delete env;" and "delete clip;". It's recipe for disaster. With AVS 2.6 one can use "DeleteScriptEnvironment()" which properly releases the pointers and memory.

Are you sure the same does not happen with 32 bit ffdshow?

[chainik_svp]

> Are you sure the same does not happen with 32 bit ffdshow?

Absolutely. It's like hundreds of MBs on each re-init.
We've already talked about this back in March 2015 as I can remember... :)

[Groucho2004]

We've already talked about this back in March 2015 as I can remember... :)
True, just found it.

[jones1913]

Avisynth+ r1841-pfmod

http://www.mediafire.com/download/eadynn3jpv720jl/avsplus-r1841-pfmod.7z

Thanks, this has also fixed the crashes I had with QTGMC and AVS+.

[pinterf]

Now I have a special 32 bit debug build that only differs from the working version that there is a 1/10000 or 1/1000 sec wait cycle in the caching code in the "not found but get frame from child then push it in cache".
This delay results in zero pointer frames appearing in the cache. My tests run fine with mt mode 2 but with this version Qtgmc fast is giving C0000005 exceptions at random places, if thread count is big enough. E.g. prefetch(8).
If I set all masktools2 filters to mt mode 1 (serialize) then it works again.
But its not because of masktools. Having its filters serialized only modifies the timing conditions.
There must be a race condition, the lru cacheing code seems to be perfect, I suspect the prefetcher and the worker threads and the caches are not perfercly synchronized.
Then it turned out that I can make it to freeze with simple 3 lines. When i will back at my PC I will show you.

Is there anybody here who was deeply involved in these mt and prefetch queue and cache core things? Not an easy read to reverse engineer it :)

[chainik_svp]

I can try! :D

[Chikuzen]

Is there anybody here who was deeply involved in these mt and prefetch queue and cache core things? Not an easy read to reverse engineer it :)

I think the man is tp7.
I recommend you to just send a mail to him.

[TurboPascal7]

tp7 hardly remembers anything about the threading codebase, pretty much all of which was written by ultim.
Have fun.

[pinterf]

Thanks tp7, anyway.
There are clear drawbacks of a one man show. At least the codebase is pretty nice.

[pinterf]

Meanwhile I think the cache corruption is solved.

Problem:
- a debug build with an extra command placed in the caching code
- random crashes 0xC0000005, null frame pointers, etc..., somewhere in the big black hole of QTGMC
- could not debug in IDE, since the 8 threads and 1/10000 sec timing differences made the problem disappear. Debugging was possible only by analyzing long debug outputs.

After some days I managed to shrink down the original QTGMC.avsi to this very-very complex script:
Blankclip(width = 320, height = 200, pixel_type = "yv12").KillAudio()
# no freeze without KillAudio. KillAudio is giving us a new caching level
SeparateFields()
Prefetch(8)
Nice, isn't is?

And this is the code fragment that deals with case, when the Nth frame is not found in cache. (Sorry, just to feel the pain :) )
PVideoFrame result;
LruCache<size_t, PVideoFrame>::handle cache_handle;

switch(_pimpl->VideoCache->lookup(n, &cache_handle, true))
{
case LRU_LOOKUP_NOT_FOUND:
{
try
{
cache_handle.first->value = _pimpl->child->GetFrame(n, env);
#ifdef X86_32
_mm_empty();
#endif
_pimpl->VideoCache->commit_value(&cache_handle);
}
catch (...)
{
_pimpl->VideoCache->rollback(&cache_handle);
throw;
}
#ifdef _DEBUG
// !!! some process during the next 1/10000 seconds is overwriting the
// content of this cache handle (frame) with NULL!
// 1/10000 sec delay, but a simple _RPT debug line is enough, albeit the
// corruption occurs more rarely
std::chrono::time_point<std::chrono::high_resolution_clock> t_start2, t_end2;
std::chrono::duration<double> elapsed_seconds;
t_start2 = std::chrono::high_resolution_clock::now();
do {
t_end2 = std::chrono::high_resolution_clock::now();
elapsed_seconds = t_end2 - t_start2;
} while (elapsed_seconds.count() < 1.0 / 10000.0);
// end of delay
assert(NULL != cache_handle.first->value); // and now it's NULL!!!
#endif
result = cache_handle.first->value;
// its content may change after commit when the last lock is released
// (cache is being restructured by other threads, new frames?)
break;
[...]


Solution: fill 'result' _before_ the commit. Easy eh? Six letters and plus one line and a deleted line at the bottom. It took me three or four days, again. But now you can ask me about the caching.

Although it happened only to the debug version, theoretically it would occur anytime. I don't know, at different processor speeds, thread count, load, etc...

And as a new adventure I had to plunge into masktools2 a bit when I thought it would be the suspect, since putting its filters into serialized MT mode, the corruption did not occur in QTGMC. It was false alarm, it works fine in mode 2 (MT_MULTI_INSTANCE).

[ryrynz]

Meanwhile I think the cache corruption is solved.


Great work, I think this entire thread now loves you. All hail the new Ultim.

[LigH]

Let's be happy about it:

http://cosgan.de/images/smilie/musik/e050.gif http://cosgan.de/images/smilie/musik/n015.gif

[pinterf]

Haha :)
Then all readers here are obeyed to run with me on that 54K 2800D+
Just for plain solidarity :)

[pinterf]

(Those numbers are not the newest avs+ versioning scheme but the data of the trail running race next weekend on which I trained almost nothing because of these avs+ riddles. :)

[pinterf]

New AVS+ build: r1847

x64/x86, including XP versions

r1847 MT-pfmod (2016.04.18)
- fixed broken ffdshow integration (chainikdn)
- fixed theoretical and debug case cache corruption

Download from
https://github.com/pinterf/AviSynthPlus/releases/tag/r1847-MT-pfmod
or
http://www.mediafire.com/download/r7bgaq94cbr9kmf/avsplus-r1847-pfmod.7z

[MysteryX]

Thanks!! This newer version finally works fine with SVP.

[ryrynz]

I guess I'll look at this again once another phase of development has occurred, hopefully some time next year.

'Kay well I gave 1847 a shot but it just crashes MPC_BE x86 (build 1417) instantly with exception code 0xc0000005 when passed through ffdshow (4533) Even with nothing in the Avisynth field it still happens. No problems with Avisynth-MT.

[jpsdr]

@pinterf
First, thanks for your work, i think a lot of people appreciate what you did, even if they stay silent.

And...
Do you think, by any chance, you can take a look at this issue, if it can be fixed ?
You can see the whole thread here (https://www.neatvideo.com/nvforum/viewtopic.php?t=1127), but the most important point is this information :

It seems that the x64 version of Avisynth has a different size of the CScriptValue structure that is used to pass arguments to a filter (as compared with the 64-bit VirtualDub). This makes NeatVideo crash when processing the preset name (the second argument of NeatVideo4). The size difference may be a bug in Avisynth x64.


Anyway, thanks again for your work.

[pinterf]

'Kay well I gave 1847 a shot but it just crashes MPC_BE x86 (build 1417) instantly with exception code 0xc0000005 when passed through ffdshow (4533) Even with nothing in the Avisynth field it still happens. No problems with Avisynth-MT.
Perhaps missing VS2015 redistributable?

[pinterf]

@pinterf
Do you think, by any chance, you can take a look at this issue, if it can be fixed ?
You can see the whole thread here (https://www.neatvideo.com/nvforum/viewtopic.php?t=1127), but the most important point is this information :

Anyway, thanks again for your work.
So charting unknown seas :). Feedback is always welcome, anyway. I'll look into it.
And thank you, I like silence only when it means that things are working fine.

[ryrynz]

Perhaps missing VS2015 redistributable?

Yup. Thanks, it's working well in comparison to MT so far.

[pinterf]

@jpsdr
(vdub) Found something. Who can test it? I don't want to circulate an interim test build in public.

[jpsdr]

PM me a link. Don't need XP build for this test, but need both 32 and 64 bits dll.

[MysteryX]

So charting unknown seas :). Feedback is always welcome, anyway. I'll look into it.
And thank you, I like silence only when it means that things are working fine.
Thank you so much. There's a LOT of people who have been waiting a LONG time for someone to make a MT version of AviSynth+ that works fine, and it's been dead for so long.

Finally someone who puts his butt into use.

I'll do some testing of replacing AVS 2.6 with this version for encoding and let you know how it goes. The previous version wasn't working with all filters.

According to my first tests, however, it seems that L-MASHSOURCE lags on some videos, even when CPU isn't fully used, whereas with 2.6 it worked fine. This would require more testing to see where that's coming from.

[Stereodude]

Does it actually work? I gave up on MT Avisynth a long time ago. I couldn't get satisfactory results no matter how I tweaked the settings for FHD material. It would crash well before you could encode an entire ~2 hour movie with it. I had much better luck using MP_Pipeline to separate different high CPU usage filters into their own threads. Using MP_Pipeline and splitting the source across several simultaneous lossless intermediate files (usually 4) that were joined and then encoded worked best for me.

IE: If I have a 100,000 frame source, I generate a lossless intermediate file from 0-25010, another from 24990-50010, another from 49990-75010, and another from 74990-100000. I would do that with four simultaneous Virtualdub jobs each generating an AVI file. Trim the overlap areas in an AVIsynth and use that to do my 2 pass x264 encode.

[MysteryX]

For me AviSynth 2.6 MT has been working well. Perhaps there are a few filters that are more unstable with MT but those I use were working well. This AviSynth+ appears to be very stable so I'm sure it will work fine although I have to try first. The previous version of AviSynth+ MT wasn't working with some filters such as NNEDI3.

[StainlessS]

Stereodude,

You are recommending Overlap again despite your acceptance that it is unnecessary, here (final edit):- http://forum.doom9.org/showthread.php?p=1714239#post1714239

EDIT: Edit: Now I see what you're saying to do. Trim the output not the input and run those scripts in parallel.

You can Trim at END of script and overlap is NOT necessary.

EDIT: The "MakeMultiPartScripts.avs" script given earlier in that thread generates multi-part scripts
to avoid making mistakes in your Trim frame numbers. [EDIT: Post #15 in that thread]

[mark0077]

Hi, I tried avisynth+ a few times in the past and have just put together a new PC and am wondering is it worth using it for SVP usage performance wise or not now with the latest versions? If theres a significant performance difference I will look at the steps to get SVP working with avisynth+ instead of Sets MT version of avisynth.

[Stereodude]

Stereodude,

You are recommending Overlap again despite your acceptance that it is unnecessary, here (final edit):- http://forum.doom9.org/showthread.php?p=1714239#post1714239

EDIT:

You can Trim at END of script and overlap is NOT necessary.

EDIT: The "MakeMultiPartScripts.avs" script given earlier in that thread generates multi-part scripts
to avoid making mistakes in your Trim frame numbers. [EDIT: Post #15 in that thread]
I was saying what I've done in the past. Frankly, I'd forgotten about our prior conversation. I haven't done one of these since our back and forth, but I'm glad you're following me around the forum remembering everything I've posted in the past to correct me. This way when I do one in the near future it'll be fresh in my memory. Especially now that I have systems with 8 and 16 physical core Xeon CPUs (with HT) and parallelism is going to be even more important.

[StainlessS]

Yep, I keep a close track on all of your posts just so I can do a little nit picking :)

Nah, I was gonna point out that thread and discovered (to my joy and delight) that it was you who was on the other end
of conversation, hehe.

My previous favorite similar lil ol correction was in this post:- http://forum.doom9.org/showthread.php?p=1729222#post1729222

EDIT: In response to fvisagie.

[MysteryX]

Hi, I tried avisynth+ a few times in the past and have just put together a new PC and am wondering is it worth using it for SVP usage performance wise or not now with the latest versions? If theres a significant performance difference I will look at the steps to get SVP working with avisynth+ instead of Sets MT version of avisynth.
For AviSynth+ and SVP, view this thread
http://www.svp-team.com/forum/viewtopic.php?id=3270

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.

As for the videos that would lag with L-SMASH Source, playing with the threads fixes it. In fact, I am now able to use LWLibavVideoSource for real-time playback without using MT. MT wasn't recommended for this plugin but it was the only way to prevent lag according to my test. With AviSynth+, no MT works perfect :) So far. I'll have to try with a wider variety of videos.

[Sparktank]

For AviSynth+ and SVP, view this thread
http://www.svp-team.com/forum/viewtopic.php?id=3270

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.

This is exciting news!

I'll have to dedicate some time to getting AVS+ set up again (Groucho's switcharoo setup).

I'm currently still using 260_MT to play.
I remember liking old AVS+ for awhile, but for non-SVP things, it was naturally unstable to use in AvsPmod (even with updates to APM).

[pinterf]

Do not fear of MT mode and use 64 bit, there may be more x64 filters than you would think before!

If you have enough memory, don't limit your script using it, even if avs+ occupies much less memory footprint than at the beginnings.

You can test the peak memory need with SetMemoryMax(bigvalue) and watch AvsMeter/AvsMeter64.

As for MT, set default mt mode to 2, for source filters 3, Prefetch(8) then rock'n'roll.

OK, fps-wise on my i7 processor Prefetch(7) or Prefetch(8) is not scaling well compared to Prefetch(6), but is still faster a bit.

This night an AVS+ x64 with SetMemoryMax(6000), UHD (3840x2160) colorbars + QTGMC(Fast) + Prefetch(8) is trying to kill my PC in the office.
(Fast i7 with 8G RAM, now it's at more than 4 fps and is working hard at 80% CPU since 3 hours).

Wondering, at what memory consumption would this UHD source script stabilize itself if I didn't put that 6G limit. So, which volunteer has 24G RAM? :) That should be more than enough for the test I think.

[ryrynz]

I find it to be the fastest and most stable so far. Memory usage is TWICE LOWER.


Yeah memory usage is a lot lower, I used to have a max mem set of 500MB with MT and my usage is almost 500MB lower using AVS+.

As CPU usage goes it's very close for me just using a couple of filters, the dynamic CPU clock almost looked to be a touch lower.
Might be time to finally give 64 bit a go.

Gave it a shot and get instant crashes on playback. Replaced AVS+ with the 64 bit version, ffdshow 64 bit, MPC-BE 64 bit with the 64 bit VS2015 redistributable installed also.
Removed all filters and it still crashes.

[pinterf]

Ok. So at least one component needs polishing. It is 2016 now, 64 bit things should work*. We can exclude the redistributables :) Remains: avs+, a remaining filter, source filter, mpc, ffdshow, interaction between them

*or let's be sarcastic: it's 2016 now, higher than 8 bit color spaces should be supported natively in the whole workflow.... er ...not for current avisynth. But we should think about it seriously. Opinions? Biggest obstacles? I know there is VapourSynth with plenty of high-bit-depth filters, but I'd like to have spare batteries also :)

[qyot27]

I'm going to place the blame firmly on ffdshow there. AviSynth+ 64-bit is known to work with 64-bit builds of ffmpeg from after March 2013, or by extension, things that link against the libavformat from those builds of ffmpeg, like LAV Filters or mpv; that does not include ffdshow. And if ffmpeg fails, only then would that point to one of the filters being the problem.

[qyot27]

*or let's be sarcastic: it's 2016 now, higher than 8 bit color spaces should be supported natively in the whole workflow.... er ...not for current avisynth. But we should think about it seriously. Opinions? Biggest obstacles? I know there is VapourSynth with plenty of high-bit-depth filters, but I'd like to have spare batteries also :)
ultim mentioned some time back that it wouldn't be *that* difficult to fix the >8bit support in the core, more that it would be tedious.

Personally, I'd urge us to get cross-platform support working first, because it means more ready-to-deploy testing environments so those that are willing to do the tedious work can have fast turnaround testing times. More eyes and potential contributors overall.

[pinterf]

What is missing for cross platformity? I guess the first step that the project could be compiled with GCC?

As for the high bit depth: yes, I already looked into the core for possible 8bit+ usage too, and mostly its a mechanic work. Luts will be ugly, for some filters templates could be used. At least for C implementation because intrinsics need to be optimized for distinct color depths. Then there will be theoretical problems with colors, primaries, gamma, why we use 16-235 or its 16 bit counterpart when cameras are using 16-255 and happily ignore the so called standards etc.

[MysteryX]

AVS+ might be a little bit more stable than AVS 2.6 but it still has random crashes and freezes, which is noticeable when playing videos with SVP and seeking. It would be nice if we could get the bugs sorted out in the standrad AVS before implementing other major features that will add complexity and may add to the instability. When small bugs are left out, they accumulate until they become unmanageable.

Edit: I just saw a comment that this freeze may be in ffdshow and not related to AviSynth

[chainik_svp]

64-bit ffdshow + AVS+ 1847 actually works.


09:51:34.322 [I]: VideoPlayer: new ffdshow video [405c2] in unknown player (64-bit) [MPC-BE x64 1.4.3.5182] on screen 0
09:51:34.556 [I]: Playback [405c2]: Frame server (64-bit) 0.1.0.0, AviSynth+ 0.1 (r1847, MT-pfmod, x86_64), C:\Program Files\MPC-BE x64\avisynth.dll


If it crashes on start I can suggest to double-check all the dependencies (with the Dependeny Walker) for the given avisynth.dll

[pinterf]

My poor PC has successfully finished a nightly UHD stress-test
HW: i7-3770@3.4GHz, 8G RAM, Win7 Prof x64


AVSMeter 2.1.6 (x64)
AviSynth+ 0.1 (r1847, MT-pfmod, x86_64) (0.1.0.0)

Number of frames: 215784
Length (hh:mm:ss.ms): 01:11:55.680
Frame width: 3840
Frame height: 2160
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 215784 (0 - 215783)
FPS (min | max | average): 0.285 | 331285 | 4.601
Memory usage (phys | virt): 5851 | 6260 MB
Thread count: 90
CPU usage (average): 83%

Time (elapsed): 13:01:41.985

script:

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetMemoryMax(6000)
colorbars(width = 3840, height = 2160, pixel_type = "yv12", staticframes=false).killaudio().assumefps(25, 1)
AssumeBFF()
QTGMC(Preset="Fast")
PreFetch(8)


used modules:
- QTGMC 3.33
- mvtools2 2.7.0.1 - my mod based on 2.6.0.5 https://github.com/pinterf/mvtools/releases
- nnedi3 (SSE4.2 build) - JPSDR v0.9.4.20 (05/09/2015) https://github.com/jpsdr/NNEDI3/releases
- masktools2 (12/20/2013) https://github.com/tp7/masktools
- rgtools (02/02/2014) https://github.com/tp7/RgTools/releases

[chainik_svp]

can I suggest to build it with VS 2013?
otherwise it becomes tricky to install this on some client machine:
1. install AVS+ using official installer (which will install VC++ 2013)
2. install VC++ 2015
3. replace the dll

[pinterf]

I suppose once the version deserves, there will be a new installer package.
At the beginning I spent three days with reinstalling VC++ things to have VS versions simultaniously side-by-side (in theory it works, for me not), I don't want back those times. Updating one made the other unusable. Even the last VS2015 update 2 killed itself (splashscreen flashed then nothing happens) and had to iterate between uninstall something/repair/restart machine loops.

[ryrynz]

AVS+ might be a little bit more stable than AVS 2.6 but it still has random crashes and freezes, which is noticeable when playing videos with SVP and seeking. It would be nice if we could get the bugs sorted out in the standrad AVS before implementing other major features that will add complexity and may add to the instability. When small bugs are left out, they accumulate until they become unmanageable.

Edit: I just saw a comment that this freeze may be in ffdshow and not related to AviSynth

This. If pinterf or anyone else could fix this issue it would be a god send. As he said, it sucks having to run 32 bit programs just to get Avisynth running in real time.
Surely it can't be any more difficult than what was done recently to fix the performance issues with AVS+.

64-bit ffdshow + AVS+ 1847 actually works.

If it crashes on start I can suggest to double-check all the dependencies (with the Dependency Walker) for the given avisynth.dll

I'll take a look.

Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

First time using this app, so here's a link (http://www.filedropper.com/avisynth) to the dwi, would appreciate if someone could tell me what's possibly causing the crash, cheers.

[MysteryX]

I believe there are many able and willing to provide great feedback for improvements and testing, but few will go into the AviSynth+ source code itself.

If pinterf is willing to work on this until we get a great stable official version, then we can do our part to test and fix most of the bugs that are left.

I think that polishing the current version is more important than implementing big new features such as increased colorspace. Once an official stable version is released, then looking into additional features could be the next step.

This certainly encourages me to get back into testing scripts and code with this new version.

[MysteryX]

As for the random crashes, I was using AviSynth 2.6 MT *and* AviSynth+ (non-MT) with my software. For previews, I found AviSynth+ to be the most stable but it would still crash sometimes. AviSynth 2.6 MT is the version that provided the best performance for actual encoding.

This wasn't using ffdshow so we can put that out of the equation in this case.

[pinterf]

If it is reproducible, it can be caught.
Can you provide the steps to reproduce?
From the beginnings if possible, e.g. download this and that, open xy type media file, click here and there, etc...

[MysteryX]

Absolutely RANDOM!!

Good luck :)

[LigH]

The more random, the more probably the reason may be hardware related...

[Groucho2004]

The more random, the more probably the reason may be hardware related...
Maybe. However, a scenario with Avisynth/QTGMC()/[encoder] is very complex and seemingly random events are reproducible if one uses strict and systematic testing procedures. Just using a different version of a filter can easily change the result.

[pinterf]

Absolutely RANDOM!!

Good luck :)
Bad answer :)

Random =>
Occurs in X minutes
or Y times you start the program
or seek the video back and forth =>
Crash =>
We can catch it =>
Fix it =>
Happier world

No steps to reproduce =>
No crash =>
No Problem

So what did you do with which software on what video before the random things appear?

[pinterf]

Random things. TemporalSoften memory leak occured after the 35000th frame in the QTGMC process. And from that frame on at other random places.
I had to wait 10-30 minutes for each event, but it wasn't even a nice "crash", just something, somewhen was not freed properly from memory I didn't even know what to search for.
It appeared randomly. Turned out that when there was a lot of movement in the video, a number remained under a threshold and it was treated as a scene change.
And then (but only then) a program code was triggered that caused the memory leak.

Or the recent cache corruption issue in debug mode. 1/10000 sec differences here or there and how windows background processes were interrupting the avs code, sometimes the crash occured, but mostly not.
One crash vs twenty good encoding. The same script, same machine. Random. But it was reproducible, because it had happened.

[qyot27]

What is missing for cross platformity? I guess the first step that the project could be compiled with GCC?
The intrinsics have to be split up into separate files, and some parts (like the plugin loader) need to be rewritten or have a separate implementation to work on Linux or OSX. That's all I'm immediately aware of, aside from making sure none of the code is written in some MSVC-specific or GCC-specific dialect unless those compilers are the only ones ever touching that piece of code.

Pull request #45 (https://github.com/AviSynth/AviSynthPlus/pull/45) on Github already implements a basic set of the install rules that can be tailored better to fit *nix-specific shared objects when the time comes, but the basic process of getting stuff into the right install dir hierarchy is already there and works just fine on Windows with either NMake or Ninja controlling cl.exe (even though Windows doesn't use the Filesystem Hierarchy Standard, though Cygwin and MSys(2) both do).

innocenat started on the migration with the 'linux' branch, and I'd synced from it and started splitting the intrinsics on my side, but the run-up to integrating RC1 put that on the backburner and I haven't managed to pick it back up.

[MysteryX]

Random things. TemporalSoften memory leak occured after the 35000th frame in the QTGMC process. And from that frame on at other random places.
I had to wait 10-30 minutes for each event, but it wasn't even a nice "crash", just something, somewhen was not freed properly from memory I didn't even know what to search for.
It appeared randomly. Turned out that when there was a lot of movement in the video, a number remained under a threshold and it was treated as a scene change.
And then (but only then) a program code was triggered that caused the memory leak.

Or the recent cache corruption issue in debug mode. 1/10000 sec differences here or there and how windows background processes were interrupting the avs code, sometimes the crash occured, but mostly not.
One crash vs twenty good encoding. The same script, same machine. Random. But it was reproducible, because it had happened.
You're good to have nailed these down!

I haven't done much testing with your version yet, but I'll post more detailed stuff once I get to testing it more in-depth.

The way I was using AviSynth+ (non-MT, the most stable of all) was to load a preview AVS script within a Windows Media Player ActiveX control within my Natural Grounding Player application. After doing the 20-30th preview or so (which really is only opening up a script within a player), the whole application would hang. I haven't tested if it still happens with your version.

Or with SVP, there is the infamous bug that it would regularly and randomly freeze when loading videos. If you play around with SVP, I'm sure you'll see it freeze.

[chainik_svp]

The intrinsics have to be split up into separate files

Why? neither gcc nor clang requires that...

If it was my decision, I'd better took one solid and cross-platform core that's already here (e.g. vapoursynth :D) and just add a complete Avisynth API around it (which is already done (?) from the plugins PoV) plus an Avisynth script parser.
I really don't get what's the point in existence of three different half-working frame servers...

[MysteryX]

If it was my decision, I'd better took one solid and cross-platform core that's already here (e.g. vapoursynth :D) and just add a complete Avisynth API around it (which is already done (?) from the plugins PoV) plus an Avisynth script parser.
I really don't get what's the point in existence of three different half-working frame servers...
It would be faster to get AviSynth+ 100% working than to finish implementing such a bridge.

Plus VapourSynth doesn't support audio processing yet, nor can it be integrated with ffdshow.

Correct me if I'm wrong, but VapourSynth still needs a lot of work to be a replacement to AviSynth.

[chainik_svp]

We're talking about Avisynth+ port for Linux ;)

[MysteryX]

We're talking about Avisynth+ port for Linux ;)
Oh... for Linux. Getting into politics here.

Would all the standard AviSynth filters work on Linux or have to be rewritten and recompiled?

My opinion is that if all the plugins would work on Linux, porting AviSynth+ to Linux would be a great idea. If the plugins are window-specific, then the development may be better spent on VapourSynth.

Based on my limited C understanding, I do believe most plugins are limited to Windows but could be made cross-platform quite easily. Except my AviSynthShader that is and will always remain Windows-only :) (unless someone wants to port the dead DX9 API to Linux?)

All GPU-accelerated plugins may require more work to port.

[pinterf]

New AVS+ build: r1849 and vdubfilter.dll

x64/x86, including XP versions

r1849 MT-pfmod (20160422)
- Tweak internal FrameRegistry
- [VDubFilter.dll] Fix: VirtualDub filter x64 crash
- [VDubFilter.dll] Add: VirtualDub filter parameter type double

This build primarily aims to fix virtualdub x64 issues. Special thanks to jpsdr for providing the test environment.

Although avisynth.dll was not affected, since r1847 I put a minor tweak into the FrameRegistry logic (list->vector internally), sometimes it was faster a bit. So I included it also.

Download r1849 and vdubfilter.dll:
http://www.mediafire.com/download/fbtzo1pvo8aidoq/r1849-pfmod-with-vdubfilter.7z
or
https://github.com/pinterf/AviSynthPlus/releases/tag/r1849-MT-pfmod

[jackoneill]

It would be faster to get AviSynth+ 100% working than to finish implementing such a bridge.

Plus VapourSynth doesn't support audio processing yet, nor can it be integrated with ffdshow.

Correct me if I'm wrong, but VapourSynth still needs a lot of work to be a replacement to AviSynth.

Wasn't ffdshow abandoned by the maintainer, hence the need for lavfilters?

[qyot27]

Why? neither gcc nor clang requires that...
Clang may not require it, but GCC definitely does if you want a binary that's usable on anything older than the newest SIMD instruction set used in the intrinsics. Which means that AVX/AVX2 paths could not be added to the filters as soon as they're ready, because it would make CPUs older than Sandy Bridge/Haswell unable to run GCC builds of AviSynth+.

http://www.virtualdub.org/blog/pivot/entry.php?id=363

The 'workaround' for that (by littering __attribute__ or #pragma overrides throughout the file) is entirely either GCC-specific or messy, and thus, ineligible from how I understand the project coding guidelines. Not because it wouldn't work, but because it would also mean potentially adding tons of ifdefs just to make sure MSVC doesn't choke on them.

The only option that leaves us with is to split the intrinsics per-SIMD into discrete files, and then use the build system to add the correct -mSIMD flags when building the files that need them and omit them otherwise. In fact, x265 did just what I described when they still relied on intrinsics rather than on yasm. Several autotools-based projects in the FFmpeg dependency chain also segregate their intrinsics this way, likely for the exact same reason(s).

The thing that actually causes the problem is the inclusion of the intrinsics headers, which require the application of the -mSIMD flags in order to not fail compilation. But applying those project-wide means that codepaths that don't even use those SIMD sets will get optimized by the compiler for those sets, and become unable to run on anything lower. And the way to apply them per-file is to make sure the intrinsics are split into separate files so they don't contaminate each other.


At which point it might as well be stated that GCC won't be supported, only Clang (if it doesn't require these contortions to make the intrinsics and runtime detection work right).

[qyot27]

Oh... for Linux. Getting into politics here.

Would all the standard AviSynth filters work on Linux or have to be rewritten and recompiled?

My opinion is that if all the plugins would work on Linux, porting AviSynth+ to Linux would be a great idea. If the plugins are window-specific, then the development may be better spent on VapourSynth.

Based on my limited C understanding, I do believe most plugins are limited to Windows but could be made cross-platform quite easily. Except my AviSynthShader that is and will always remain Windows-only :) (unless someone wants to port the dead DX9 API to Linux?)

All GPU-accelerated plugins may require more work to port.
Even if no plugins could be ported to Linux*, getting AviSynth+ cross-platform is necessary to get AvxSynth out of the way for good and have a singular up to date AviSynth implementation that FFmpeg or x264 can use on non-Windows. AvxSynth has all its assembly disabled (some filters don't even work right) and is limited by the same constraints as AviSynth 2.5.8; it has a use, but it's severely limited and was mostly important because it made sure the libavformat demuxer for AviSynth was rewritten correctly. AviSynth+ wouldn't suffer from any of those problems, since the first release on a non-Windows OS would already incorporate the intrinsics, multithreading, and 2.6 colorspaces, and probably even get >8bit not long after if the effort was there.

*which is far from true; most plugins don't rely on Windows system calls (something IanB mentioned in the AvxSynth thread, as part of a musing that a thunking layer could make the Windows plugin *.dlls usable on Linux without recompiling them) and would only need to be able to be built by GCC or Clang with some fixes for how Linux expects libraries to act. And there's always the option of adding AviSynth+ interfaces to existing VapourSynth plugins that work better than their old AviSynth counterparts on Windows.

[pinterf]

Huh, it's not easy. I'd better stay in the background regarding any multiplatform things. Two month ago I even could not recognize that these codes were written in CPP. It was in 2000 when I was last using C :) In DOS I didn't need fancy constructor syntaxes. So I just listen and learn.

[MysteryX]

OK I've done some testing. The most stable with SVP is to use SVP 4.0.0.60 and MPC-HC 1.7.9 with AviSynth+. The latest SVP appears to crash more, so does MPC-HC 1.7.10 (maybe?)

After loading 20-30 videos in MPC-HC while playing with SVP, the player will freeze which requires to kill the process manually.

[Groucho2004]

OK I've done some testing. The most stable with SVP is to use SVP 4.0.0.60 and MPC-HC 1.7.9 with AviSynth+. The latest SVP appears to crash more, so does MPC-HC 1.7.10 (maybe?)

After loading 20-30 videos in MPC-HC while playing with SVP, the player will freeze which requires to kill the process manually.
What's the point of this post? Avisynth cannot magically fix the SVP and/or mpc bugs.

Also, have a look at this thread (http://www.svp-team.com/forum/viewtopic.php?id=3247). I'd refuse to look into anything related to SVP.

[MysteryX]

It's hard to identify where the bug is coming from when there are various components linked.

I've also been getting freezes on load when loading simple AVS+ scripts without SVP, although I haven't tried this latest version but I don't think the bug has been resolved since the last stable build.

As for that thread, I refuse to go into GPL politics here.

[MysteryX]

OK I did some more testing. I have this script file.


P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA - Endless.mkv"
LWLibavVideoSource(file, cache=false)
AudioDub(LWLibavAudioSource(file, cache=false))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)


I drag/drop it into MPC-HC 1.7.9 repeatedly. It froze at the second loading. Then I killed the process and tried again, and it froze again at the 6th loading.

[pinterf]

Well, this is a usable report. Thank you. 32 or 64 bit?

[MysteryX]

32 bit.

I may have a different version of L-SMASH Source but I don't think it will change anything.

[pinterf]

Prefetch(100) nightly MT stress-test.
15 cycles, w/o problem

Script:
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
SetMemoryMax(6000)
Avisource("Tape02_Hi8.avi").killaudio().assumefps(25,1)
AssumeBFF()
QTGMC(Preset="Fast")
prefetch(100)


Typical output:

AVSMeter 2.2.2 (x64)
AviSynth+ 0.1 (r1849, MT-pfmod, x86_64) (0.1.0.0)

Number of frames: 278762
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 278762 (0 - 278761)
FPS (min | max | average): 3.365 | 1226976 | 110.3
Memory usage (phys | virt): 4773 | 4950 MiB
Thread count: 918
CPU usage (average): 96%

Time (elapsed): 00:42:06.507

[Groucho2004]

Prefetch(100) nightly MT stress-test.
15 cycles, w/o problem
That's quite impressive! Nicely done.

Thread count: 918Yikes.

[LigH]

Avisource("Tape02_Hi8.avi").killaudio()

Maybe easier:

Avisource("Tape02_Hi8.avi", audio=false)

[pinterf]

OK I did some more testing. I have this script file.


P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA - Endless.mkv"
LWLibavVideoSource(file, cache=false)
AudioDub(LWLibavAudioSource(file, cache=false))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)


I drag/drop it into MPC-HC 1.7.9 repeatedly. It froze at the second loading. Then I killed the process and tried again, and it froze again at the 6th loading.
Tried with
- MPC-HC 32 bit 1.7.9 and 1.7.10
- TimeStretchPlugin found here:
http://avisynth.nl/index.php/TimeStretchPlugin#Audio_Filters
linked to here
http://forum.doom9.org/showpost.php?p=1722472&postcount=20
- LSMASHSource.dll
LSMASHSource-AviSynth-plugin-r859-msvc-32bit.7z
and
LSMASHSource-AviSynth-plugin-r877-msvc-32bit.7z
- Avs+ 1841 and 1849 (32 bit)

No freeze here.

Which version of LSMASHSource are you using?
Maybe you could send me the source mkv, or you can trim it if it is too large (and the trimmed version also produces the freeze)

[Leinad4Mind]

Hi there, I've installed avisynth+. I've windows 7 x64.
I'm trying just to do the basic of the basics. To be able to run FFVideoSource, but I got the message "There is no function".

I got here the ffms2: https://github.com/FFMS/ffms2/releases

If I use the folder plugins, and put the x86 version on it, all runs well.
BUT, if I put the x64 dll on the plugins64, it doesn't work, why? (I am trying to work with the fastest plugins, for the same results)

And I've a clean install, so if I put x86 ffms2 on plugins+, it will work too. But which is the difference between plugins and plugins+?(I presume the + will be faster?) How do I know it will work on plugins+? (just testing it?)
But for 64 bits, I am not able to put this working. If I put only the ffms2 x64 version on the plugins64 or plugins64+ it doesnt work :/
And where can I find plugins for plugins+? And for x64?

Cheers!

[qyot27]

plugins+ is intended to be for AviSynth+-specific plugins. Currently, there really aren't any because the AviSynth+ API hasn't matured yet and developing plugins against it is still officially discouraged. The plugins built from the AviSynth+ source code are a plausible set to place there, but in the end it really doesn't matter - the reason for the directory separation was for cleanliness (because unlike classic AviSynth, avsplus can use multiple plugin directories), not for some magical purpose.

[Leinad4Mind]

I see. So we just have the basics plugins that comes with the installer and thats it.
But why does my x64 folder not work? Do I need to do something special?

If I try to "LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\ffms2.dll")" it gaves me error "Cannot load file" -.-

What da hell I'm missing...

[pinterf]

For x64 plugins you can find a nice collection here:
http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

For exploring dll locations, run avsmeter64 -avsinfo
PluginDir2_5 will tell you where it searches for plugins.

[Groucho2004]

For x64 plugins you can find a nice collection here:
http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

For exploring dll locations, run avsmeter64 -avsinfo
PluginDir2_5 will tell you where it searches for plugins.
AVSMeter also enumerates plugins in the "plugins+" directory if there is an entry in the registry that points to them.
Here are the registry locations it checks:
PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER (32 and 64 bit registry branch)
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE (32 and 64 bit registry branch)
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER (32 and 64 bit registry branch)
PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE (32 and 64 bit registry branch)

Some of these may never be populated but who knows...

[Leinad4Mind]

For x64 plugins you can find a nice collection here:
http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

For exploring dll locations, run avsmeter64 -avsinfo
PluginDir2_5 will tell you where it searches for plugins.

Thanks for the info. But the FFMS2 from that link, its from the github, where I download. I've tried the 3 last versions 2.20, 2.21 and 2.22.

Put all the x64 folder dll on the plugins64 folder, and on avspmod I get the error "There is no function". Thats very strange!

[Groucho2004]

Thanks for the info. But the FFMS2 from that link, its from the github, where I download. I've tried the 3 last versions 2.20, 2.21 and 2.22.

Put all the x64 folder dll on the plugins64 folder, and on avspmod I get the error "There is no function". Thats very strange!
As mentioned, run "avsmeter64 -avsinfo -log" and post the log file.

[yup]

Hi All!

I am beginer for using Avisynth+, before using Set MT build.
When I switch to Avisynth+ speed drop down from 17 fps to 11 fps.
Please advice.
Script for Set MT build
SetMemoryMax(1536)
SetMTMode(3,8)
Edibob=AVISource("pre14last.avi")# source YUY2 50 fps bobbed
SetMTMode(2)
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize",threads=1).Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3,nthreads=1)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709
Script for Avisynth+
SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",3)
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
SetFilterMTMode("DEFAULT_MT_MODE",2)
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
PreFetch(8)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")


yup.

[Groucho2004]

Put all the x64 folder dll on the plugins64 folder, and on avspmod
Is there even a 64 bit version of avspmod?

[Leinad4Mind]

Here it is:
http://i.imgur.com/4KqtpFB.png

[stax76]

@Leinad4Mind

StaxRip x64 can teach you much about AviSynth+ x64, especially when you are new to it and have problems to get it running, it includes 24 popular AviSynth+ x64 plugins and a scripting editor to write code or choose filters via menu, the menu can be customized via filter profiles, here is a pastebin (http://pastebin.com/ZFKRuXe2) showing the included profiles.

[Groucho2004]

OK. Now create a script with FFVideoSource() and run it with AVSMeter64.

Edit: Why do you have two 64 bit ffms DLLs in your plugin directory?

[Leinad4Mind]

lol forget about the 2 dlls, I was testing old releases, one by one. And I just let 1 dll each time.
I'm not new at this. I know how to deal with avisynth and avspmod and megui. But Its my first time to try to work with avisynth+ x64 plugins. I can work with x86 without problems.
And If I recall correctly some years ago, I used avisynth 2.5.8 64bits without any problem. Dont remember if I used avpsmod, but I guess I was using. And I dont recall to have any kind of problems.

[Leinad4Mind]

@Leinad4Mind

StaxRip x64 can teach you much about AviSynth+ x64, especially when you are new to it and have problems to get it running, it includes 24 popular AviSynth+ x64 plugins and a scripting editor to write code or choose filters via menu, the menu can be customized via filter profiles, here is a pastebin (http://pastebin.com/ZFKRuXe2) showing the included profiles.


I'll give a shot to your GUI. Some good years ago I didn't like it, but It seems to be evolve a lot. Thanks for the info.

[Groucho2004]

If I try to "LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\ffms2.dll")" it gaves me error "Cannot load file" -.-

What da hell I'm missing...
That's another thing - why would you use Loadplugin() for a DLL that is already in the auto-load directory? Not that it causes problems but it's redundant.

[Leinad4Mind]

I know its redundant, but if my autoload directory was not autoloading, I was trying to force to read that dll. But even so, didn't work.
I installed now the staxrip, with it I was able to update the avisynth+ to the latest version (and I tought I was using the last one lol)
This works too with vapoursynth, thats nice. I'll be able to work easely with it. Let's see if I'm getting old to this **** xD

EDIT: Hey stax76, can I load an .avs on staxrip? Because I tried and get the same error "FFVideoSource: Can't open 'C:\file.mkv'"

my avs for test purposes is just: "FFVideoSource("C:\file.mkv")

And lets say I open directly the mkv, how can I create a avs script manually? Any option so I can write like on a text zone? (I saw how to add new filters on the profiles, but this is counter productive ^^' I would prefer to be able to write all the lines at once and preview the result)

[stax76]

@Leinad4Mind

Opening avs and vpy instead of a media file is supported. I tried a script that has only FFVideoSource in it and it worked fine, did you try if the script generally works by opening it with MPC x64?

StaxRip has a script editor that can be much used like a normal text editor to edit code, the menu has a join option and a code preview so if you really want you can get rid of macros and the split fields, it looks much like notepad and pure AviSynth code then. You loose many integrated features then of course. The easiest way to open the editor is double-clicking the list view.

[Leinad4Mind]

It works on MPC-HC, but doesnt work on StaxRip. (For simple encodes, or encodes with just gradfun for x264 8 bits, I'll try to use staxrip, but how can I choose the 8bit x264 from the 10bits? I can't find any option for that, sorry for this litlle offtopic)

About the text editor, you mean here, right?
http://i.imgur.com/f3mJvtT.png

[pinterf]

Hi All!

I am beginer for using Avisynth+, before using Set MT build.
When I switch to Avisynth+ speed drop down from 17 fps to 11 fps.
Please advice.
yup.

Try this one:
SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
Prefetch(8)

[Groucho2004]

It works on MPC-HC, but doesnt work on StaxRip. (For simple encodes, or encodes with just gradfun for x264 8 bits, I'll try to use staxrip, but how can I choose the 8bit x264 from the 10bits? I can't find any option for that, sorry for this litlle offtopic)

About the text editor, you mean here, right?
http://i.imgur.com/f3mJvtT.png
How about taking this to the appropriate thread?

[stax76]

@Leinad4Mind

Yes, it's too much of topic here, you can post to the StaxRip x64 thread. StaxRip x64 unlike MPC x64 uses VFW x64 to connect with AviSynth x64 so for testing your system you need VirtualDub x64 which also connects to AviSynth x64 using VFW x64.

[Leinad4Mind]

OMFG, I found the bug. My Filename was "Leão.mkv" and it doesn't support the character " ã " LOL After change to Leao StaxRip works great ;)
Failed to load script.

FFVideoSource: Can't open 'C:\Le?o.mkv'
(C:\rei_Source.avs, line 2)

About the topic here, even with Leao.mkv I can't get avspmod working with x64, a pitty.

[stax76]

It can be represented in ANSI charset and therefore should work with AviSynth (which don't support Unicode), if you like you can post a sample to the StaxRip thread.

[Reel.Deel]

Is there even a 64 bit version of avspmod?

Indeed there is: http://forum.doom9.org/showthread.php?p=1733655#post1733655

[Leinad4Mind]

Indeed there is: http://forum.doom9.org/showthread.php?t=153248&page=58#post1733655

I Love you man :P I didn't know about the x64 version.

Now it works! Thanks for all folks! :)

[pinterf]

It there any specific reason, why Avisynth lacks unicode support?
It's by design or just nobody complained so far?

[stax76]

here is a thread about it:

http://forum.doom9.org/showthread.php?t=110467

[yup]

Hi pinterf!

I get error
---------------------------
VirtualDub Error
---------------------------
Avisynth read error:
CAVIStreamSynth: System exception - Access Violation at 0xae1fc65
---------------------------
ОК
---------------------------

previous version work fine.
If I comment line with Colormatrix a get other message
---------------------------
VirtualDub Error
---------------------------
Out of memory (unable to allocate 7116224 bytes)
---------------------------
ОК
---------------------------

yup.

[pinterf]

Hi pinterf!
previous version work fine.
If I comment line with Colormatrix a get other message
VirtualDub Error
Out of memory (unable to allocate 7116224 bytes)


yup.

What happens if you set default mt mode to 3?
If it works, then one of the filters possibly cannot run in mode 2, only mode 3, (this is serialized mode).

Edit:
For me it works from avsmeter, though max memory consumption is 1860MB (see when set memory max to 2400).
YUY2 conversion inside QTGMC is eating a lot of memory, and speed.
Using SetMemoryMax(1536) it really uses around 1500M but it's not optimal.

[mcjordan]

Little sample of plugin including (in StaxRip):
Scripting Editor -> Misc ->
Loadplugin("C:\Portable Apps\StaxRip\Apps\Plugins\avs\MSharpen\msharpen.dll")MSharpen(threshold = 10, strength=100, highq=true, mask=false)

[LigH]

Is there no linebreak in the middle?

[stax76]

The profile editor supports multiline:

parentMenu | profileName =
Loadplugin("C:\Portable Apps\StaxRip\Apps\Plugins\avs\MSharpen\msharpen.dll")
MSharpen(threshold = 10, strength=100, highq=true, mask=false)

[pinterf]

@yup

This is my script that worked. I had no YUY2 source so I converted to YUY2 right after the source filter.

SetMemoryMax(2400) # or SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
Edibob=Avisource("dv_avi_sd_test.avi").ConvertToYUY2()
#Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
Prefetch(8)

This is the result after the first 3000 frames


AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frame (current | last): 3349 | 139380
FPS (cur | min | max | avg): 21.09 | 9.361 | 26.31 | 18.52
Memory usage (phys | virt): 1868 | 1894 MiB
Thread count: 67
CPU usage (current | average): 87% | 89%


When I converted the source back to YV12 right after the YUY2 simulated source filter, it became much faster and consumed 1000MB less memory.
Edibob=Avisource("dv_avi_sd_test.avi").ConvertToYUY2().ConvertToYV12()

AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 3320 (0 - 3319)
FPS (min | max | average): 5.220 | 52.07 | 31.33
Memory usage (phys | virt): 824 | 844 MiB
Thread count: 69
CPU usage (average): 91%


You can try SetMemoryMax(1000).
It will continously shrink the memory demand, less caching, thus the speed is lower (13.6 vs 18.5 fps) compared to the non-memory limiting version.

AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 3270 (0 - 3269)
FPS (min | max | average): 7.503 | 18.69 | 13.63
Memory usage (phys | virt): 1212 | 1250 MiB
Thread count: 67
CPU usage (average): 75%


Two remarks
- SetMemoryMax as we can see is not a 100% limit, setting it to 1000 still uses 1000-1200 MB, minor overshoot is possible.
- Seems that YUY2 is not the optimal format for processing

[TheFluff]

It there any specific reason, why Avisynth lacks unicode support?
It's by design or just nobody complained so far?

It's the standard Avisynth thing. It didn't support Unicode in 2001, everything must be backwards compatible all the way to 2001 and therefore you can't ever change anything, or if you do you have to jump through a bunch of hoops to make it backwards compatible which makes it so complex that it never gets done. It's not a huge deal, just another one of the countless minor irritations about it. Most people just rename their files if they need to.

[real.finder]

@yup

This is my script that worked. I had no YUY2 source so I converted to YUY2 right after the source filter.

SetMemoryMax(2400) # or SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
Edibob=Avisource("dv_avi_sd_test.avi").ConvertToYUY2()
#Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
Prefetch(8)

This is the result after the first 3000 frames


AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frame (current | last): 3349 | 139380
FPS (cur | min | max | avg): 21.09 | 9.361 | 26.31 | 18.52
Memory usage (phys | virt): 1868 | 1894 MiB
Thread count: 67
CPU usage (current | average): 87% | 89%


When I converted the source back to YV12 right after the YUY2 simulated source filter, it became much faster and consumed 1000MB less memory.
Edibob=Avisource("dv_avi_sd_test.avi").ConvertToYUY2().ConvertToYV12()

AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 3320 (0 - 3319)
FPS (min | max | average): 5.220 | 52.07 | 31.33
Memory usage (phys | virt): 824 | 844 MiB
Thread count: 69
CPU usage (average): 91%


You can try SetMemoryMax(1000).
It will continously shrink the memory demand, less caching, thus the speed is lower (13.6 vs 18.5 fps) compared to the non-memory limiting version.

AVSMeter 2.2.2 (x86)
AviSynth+ 0.1 (r1849, MT-pfmod, i386) (0.1.0.0)

Number of frames: 139381
Length (hh:mm:ss.ms): 01:32:55.240
Frame width: 960
Frame height: 720
Framerate: 25.000 (25/1)
Colorspace: YV12

Frames processed: 3270 (0 - 3269)
FPS (min | max | average): 7.503 | 18.69 | 13.63
Memory usage (phys | virt): 1212 | 1250 MiB
Thread count: 67
CPU usage (average): 75%


Two remarks
- SetMemoryMax as we can see is not a 100% limit, setting it to 1000 still uses 1000-1200 MB, minor overshoot is possible.
- Seems that YUY2 is not the optimal format for processing

yes, YUY2 will be slow because:-

1- more data than yv12

2- processing hack (Interleaved to Planar or reverse) if we have yv16 support for all filters it will be faster and less memory processing

[yup]

pinterf!
:thanks:
Increasing SetMemoryMax increase fps, when using avsmeter, but during open in VirtualDub I get error, also I am try using ffmpeg for conversion to AVI I see frame with green and pink bars.
All problem gone when Prefetch place after QTGMC call, may be unsharp (when I am replaced nnedi3_rpow2 and unsharp), but not lower (appear color bars in output video).
Folowing script work fine in VirtualDub
SetMemoryMax(2400) # or SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
Edibob=AVISource("pre14last.avi")#.ConvertToYV12(interlaced=false)
#.Trim(0,10000)
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
#QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
unsharp(varY=310,varC=155,strength=0.15,U=3,V=3)
#unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV16(interlaced=false)
Prefetch(8)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
#unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
#Prefetch(8)
I am agree that problem may be related with YUY2 colorspace, but my source YUY2 and I want save chroma planes before ConvertToYV12().
yup.

[qyot27]

Prefetch must be placed at the end of the script. (http://avisynth.nl/index.php/AviSynth%2B#Enabling_MT)

Also, make sure the latest version of the MT modes .avsi file (linked to from here (http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes)) is in the plugin autoload directory.

[ismail0100]

Why does not support all character say utf8 etc.

[pinterf]

here is a thread about it:

http://forum.doom9.org/showthread.php?t=110467
Thanks. Extremely problematic if we want 100% backward compatibility.

[LigH]

@ ismail0100: Because it seems to be more complicated than expected...

here is a thread about it:

http://forum.doom9.org/showthread.php?t=110467

[MysteryX]

OK I'm doing some tests with AVS+.

Here's my script.


P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"KNLMeansCL.dll")
LoadPlugin(P+"Shaders\Shader.dll")
Import(P+"Shaders\Shader.avsi")
LoadPlugin(P+"nnedi3.dll")
LoadPlugin(P+"FTurn.dll")
Import(P+"edi_rpow2.avsi")
LoadPlugin(P+"svpflow1.dll")
LoadPlugin(P+"svpflow2.dll")
Import(P+"InterFrame2.avsi")
Import(P+"ResizeX.avsi")

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
SetFilterMTMode("LWLibavAudioSource",3)
SetFilterMTMode("KNLMeansCL",3)

#SetMTMode(3,8)
file="F:\NaturalGrounding\2002 Rahtree\Original\Meu-Ayw-Tua-Lae-Tur.mpg"
LWLibavVideoSource(file, cache=false, threads=1)
AudioDub(LWLibavAudioSource(file, cache=false))
Crop(0, 0, -8, -0)
ConvertToYV24()
#SetMTMode(5)
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0)
#SetMTMode(2)
ConvertToYV12()
SuperRes(2, 0.6, 0, """edi_rpow2(2, nns=4, cshift="Spline16Resize", Threads=2)""", MatrixIn="601")
InterFrame(Cores=8, Tuning="Smooth", NewNum=60, NewDen=1, GPU=true)
SuperRes(2, 0.6, 0, """edi_rpow2(2, nns=4, cshift="Bicubic", a1=0, a2=.75, fWidth=1012, fHeight=778, Threads=2)""")
ResizeX(1004, 768, 0, 5, -8, -5, kernel="Bicubic", a1=0, a2=.75)

Prefetch(8)


With AviSynth 2.6 MT

AVSMeter 2.1.6 (x86)
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)

Number of frames: 13726
Length (hh:mm:ss.ms): 00:03:48.767
Frame width: 1004
Frame height: 768
Framerate: 60.000 (60/1)
Colorspace: YV12
Active MT Mode: 2

Frames processed: 338 (0 - 337)
FPS (min | max | average): 2.133 | 1000000 | 10.07
Memory usage (phys | virt): 885 | 1236 MB
Thread count: 311
CPU usage (average): 37%

Time (elapsed): 00:00:33.563


With AviSynth+ MT

AVSMeter 2.1.6 (x86)
AviSynth+ 0.1 (r1847, MT-pfmod, i386) (0.1.0.0)

Number of frames: 13726
Length (hh:mm:ss.ms): 00:03:48.767
Frame width: 1004
Frame height: 768
Framerate: 60.000 (60/1)
Colorspace: YV12

Frames processed: 508 (0 - 507)
FPS (min | max | average): 1.103 | 1000000 | 8.148
Memory usage (phys | virt): 738 | 1109 MB
Thread count: 345
CPU usage (average): 41%

Time (elapsed): 00:01:02.344


I tried it several times. With AVS 2.6, the speed remains at ~10.3fps. With AVS+, it starts at 11 and then drops at 8.8, and dropped all the way to 8fps. There is something causing the speed to drop over time.

[MysteryX]

I also tried replacing KNLMeansCL with xNLMeans.

Documentation says: "XNLMeans is a MT_NICE_FILTER for Avisynth_MT or Avisynth+, but without SIMD instructions or GPU acceleration."

This works
SetFilterMTMode("xNLMeans",2)

If I change to this, the script never loads.
SetFilterMTMode("xNLMeans",1)

[pinterf]

OK I'm doing some tests with AVS+.
I tried it several times. With AVS 2.6, the speed remains at ~10.3fps. With AVS+, it starts at 11 and then drops at 8.8, and dropped all the way to 8fps. There is something causing the speed to drop over time.

I wrote a longer reply, that I'm not seeing the difference at all, avs+ being some hundredth fps faster. I had the same minor fps difference with KNLMeans device_type=CPU instead of GPU.

Then I started another test, locked the computer, later returned to continue the post, looked at avsmeter, and the fps started to decrease constantly from a significantly higher fps value compared the state when I left the machine alone.

It turned out that while I'm watching avsmeter to work, I can see fps = 6-7. When I'm away from the computer, the fps is increased to 16-24. (logged the data into cvs)

So it seems that I encountered the "observer effect".

[MysteryX]

It turned out that while I'm watching avsmeter to work, I can see fps = 6-7. When I'm away from the computer, the fps is increased to 16-24. (logged the data into cvs)

So it seems that I encountered the "observer effect".
!??

Is part of the algorithm written in Quantum Physics? Perhaps it's using quantum field patterns for denoising.

[pinterf]

Left computer means I locked it. Unused gpu?

[asarian]

Left computer means I locked it. Unused gpu?

Idle screen display takes lliterally 0% GPU load (at least under GPU-Z's threshold of being measurable). Stepping away from his desk shouldn't really affect anything.

[Groucho2004]

I had the same minor fps difference with KNLMeans device_type=CPU instead of GPU.
Could you elaborate? The difference between "CPU" and "GPU" is usually huge, at least with a reasonably modern graphics card.

[pinterf]

Could you elaborate? The difference between "CPU" and "GPU" is usually huge, at least with a reasonably modern graphics card.
Sorry. The difference between AVS 2.6 and AVS+ script.

[MysteryX]

ImageSource doesn't work when switching to AviSynth+. Is there a separate library I must load to have access to this?

[MysteryX]

This build is broken. There are additional parameters that were changed in SuperRes that I didn't account for. I'm trying to fix it.

[Groucho2004]

ImageSource doesn't work when switching to AviSynth+. Is there a separate library I must load to have access to this?
The plugin is called "ImageSeq.dll" and the latest would be part of the r1825 package. See here (http://avisynth.nl/index.php/AviSynth%2B#Downloads).

[MysteryX]

Here's another bug


edi_rpow2(2, nns=4, cshift="Spline16Resize")


The image is shifted to the left in AviSynth+

AviSynth 2.6 (OK)
http://s32.postimg.org/5oxq1qqjl/Nnedi26.png (http://postimg.org/image/5oxq1qqjl/)

AviSynth+ (shifted)
http://s32.postimg.org/iwnx379b5/Nnedi.png (http://postimg.org/image/iwnx379b5/)

[pinterf]

If I'm using the provided fturn.dll, there is no shift.
I read here (http://avisynth.nl/index.php/AviSynth%2B) that fturn was integrated in the core in 2013. I will check it.

edit:
TurnLeft and TurnRight have no problem.

But in edi_rpow2.avsi when no FTurnLeft function found, it goes to another logic: splitRGB24 = false

In the avsi script I changed that line to check for TurnRight (still not using external fturn.dll) and it does not shift the image.


# If using FTurn, it's faster to split RGB24 channels into an interleaved Y8 clip because FTurn doesn't support RGB24
try {
tft = BlankClip(pixel_type="Y8").FTurnRight()
pow2 = Interleave(input.ShowRed("Y8"),input.ShowGreen("Y8"),input.ShowBlue("Y8"))
pow2 = pow2.edi_rpow2_nnedi3(rfactorX,rfactorY,alignc,true,false,false,nsize,nns,qual,etype,pscrn,threads,opt,fapprox)
splitRGB24 = true
}
catch(err_msg) {
pow2 = input.edi_rpow2_nnedi3(rfactorX,rfactorY,alignc,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox)
splitRGB24 = false
}
""")


Then I am lost in the avsi script, what happens exactly when splitRGB24 is false.
The "Center shift correction" part is different. Could you check it?

[pinterf]

This is the script I used

P="Encoder\"
#LoadPlugin(P+"FTurn.dll")
Import(P+"edi_rpow2.avsi")

ImageSource("clown.png").ConvertToRGB24().Trim(0,99)
edi_rpow2(2, nns=4, cshift="Spline16Resize")

[yup]

Hi pinterf!
When I try investigate script
SetMemoryMax(2048)
SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("AviSource",3)
Edibob=AVISource("testgpulast.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
Prefetch(8)
I try remove filters, first only QTGMC, second add nnedi3_rpow2 and problem starting with chroma bars pink and green, if I remove line with nnedi3_rpow2 script work without problem. May be this related with MysteryX problem?
Forst time I think that problem related with unsharp.
yup.

[pinterf]

Tried and it works.
Just converted to YUY2 my previous sample, resized then the other parts are from your script.

P="Encoder\"
#LoadPlugin(P+"FTurn.dll")
Import(P+"edi_rpow2.avsi")

ImageSource("clown.png").ConvertToRGB24().Trim(0,99)

Edibob=BilinearResize(720,480).ConvertToYUY2()
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize")
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
Prefetch(8)

The question whether we are working with the same plugin set, same avsi script, etc. Let's assume that the test is source content independent.

[MysteryX]

If I'm using the provided fturn.dll, there is no shift.
I read here (http://avisynth.nl/index.php/AviSynth%2B) that fturn was integrated in the core in 2013. I will check it.

edit:
TurnLeft and TurnRight have no problem.

But in edi_rpow2.avsi when no FTurnLeft function found, it goes to another logic: splitRGB24 = false

In the avsi script I changed that line to check for TurnRight (still not using external fturn.dll) and it does not shift the image.


# If using FTurn, it's faster to split RGB24 channels into an interleaved Y8 clip because FTurn doesn't support RGB24
try {
tft = BlankClip(pixel_type="Y8").FTurnRight()
pow2 = Interleave(input.ShowRed("Y8"),input.ShowGreen("Y8"),input.ShowBlue("Y8"))
pow2 = pow2.edi_rpow2_nnedi3(rfactorX,rfactorY,alignc,true,false,false,nsize,nns,qual,etype,pscrn,threads,opt,fapprox)
splitRGB24 = true
}
catch(err_msg) {
pow2 = input.edi_rpow2_nnedi3(rfactorX,rfactorY,alignc,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox)
splitRGB24 = false
}
""")


Then I am lost in the avsi script, what happens exactly when splitRGB24 is false.
The "Center shift correction" part is different. Could you check it?
That code only gets execute for RGB24 content, and the bug disappears when using YV12. It's only with RGB24 content so it's related to that. Also, NNEDI3 alone works fine.

splitRGB24 is then only used in the Center Shift Correction section so perhaps the problem is there.

So to be clear: this bug only happens when
1. FTurn.dll isn't present
2. Source is RGB24

[Desbreko]

This is the code for handling the center shift of RGB24 in edi_rpow2:

\ : cshift != "" && csp == "RGB24" && !splitRGB24 ?
\ Eval("""
shift = lsb ? Interleave(pow2.ShowRed("Y8"),pow2.ShowGreen("Y8"),pow2.ShowBlue("Y8")) : pow2
shift = shift.ResizeX(fwidth,fheight,cshiftH,cshiftV,0,0,cshift,taps,a1,a2, chroma=false, lsb=lsb)
""")
\ : cshift != "" && csp == "RGB24" && splitRGB24 ?
\ Eval("""
shift = pow2.ResizeX(fwidth,fheight,cshiftH,cshiftV,0,0,cshift,taps,a1,a2, chroma=false, lsb=lsb)
shift = !lsb ? MergeRGB(shift.SelectEvery(3,0),shift.SelectEvery(3,1),shift.SelectEvery(3,2),"RGB24") : shift
""")
I can't find anything that stands out as wrong here. The only real difference is whether the center shift correction is done on an RGB24 clip or an interleaved Y8 clip.

I also can't reproduce the shift on Avs 2.6 either with or without FTurn loaded, so I get the feeling the problem is in Avs+'s TurnLeft/TurnRight code for RGB24. Didn't that get changed a while back to add new optimizations? Maybe something got borked then.

[Reel.Deel]

...I get the feeling the problem is in Avs+'s TurnLeft/TurnRight code for RGB24. Didn't that get changed a while back to add new optimizations? Maybe something got borked then.

In the x64 support in core filters, part 1 (https://github.com/AviSynth/AviSynthPlus/pull/12) PR tp7 mentioned that only planar and RGB32 turn functions were optimized. However, the turn filter was refactored (https://github.com/AviSynth/AviSynthPlus/pull/12/commits/3abd944178c2cb0d8a6a132d3c1661b5deb97914).

[MysteryX]

By the way, now that we have a somewhat stable x64 version of AviSynth, what performance gain have you guys seen with x64 compared to x86? Are the gains worth the pain of converting my whole processing chain to x64?

[MysteryX]

I thought I might as well give it a try. Nowadays, almost all filters have x64 versions except Stainless' filters.

Here's my test script.

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"KNLMeansCL.dll")
LoadPlugin(P+"Shaders\Shader.dll")
Import(P+"Shaders\Shader.avsi")
LoadPlugin(P+"svpflow1.dll")
LoadPlugin(P+"svpflow2.dll")
Import(P+"InterFrame2.avsi")
Import(P+"ResizeX.avsi")

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
SetFilterMTMode("LWLibavAudioSource",3)
SetFilterMTMode("KNLMeansCL",3)
file="Input.mpg"
LWLibavVideoSource(file, cache=false, threads=1)
AudioDub(LWLibavAudioSource(file, cache=false))
Crop(0, 0, -8, -0)
ConvertToYV24()
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=1)
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2, MatrixIn="601")
ConvertToYV12()
InterFrame(Cores=8, Tuning="Smooth", NewNum=60, NewDen=1, GPU=true)
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2, fWidth=1012, fHeight=778)
ResizeX(1004, 768, 0, 5, -8, -5)
Prefetch(8)

With AviSynth+ r1849 x86

Frames processed: 506 (0 - 505)
FPS (min | max | average): 1.000 | 1000000 | 8.996
Memory usage (phys | virt): 543 | 1057 MiB
Thread count: 154
CPU usage (average): 15%


With AviSynth+ r1779 x64

Frames processed: 510 (0 - 509)
FPS (min | max | average): 0.526 | 155897 | 8.819
Memory usage (phys | virt): 2429 | 2887 MiB
Thread count: 157
CPU usage (average): 12%


With AviSynth+ r1849 x64, it doesn't load at all. AvsMeter stays stuck at "Reading frames..."

Edit: It is InterFrame that AVS+ x64 doesn't like. If I comment out Interframe, I get this


Frames processed: 502 (0 - 501)
FPS (min | max | average): 0.766 | 194871 | 7.700
Memory usage (phys | virt): 2248 | 2696 MiB
Thread count: 154
CPU usage (average): 10%

Memory usage is 150% higher than the x86 version and performance is 15% slower even without Interframe

Definitely no gain here.

[StainlessS]

almost all filters have x64 versions except Stainless' filters.

Anyone else is welcome to try compile x64 versions of my plugs.
I am still on XP32 and have no interest in AVS+ or 64bit.

[Groucho2004]

Edit: It is InterFrame that AVS+ x64 doesn't like. If I comment out Interframe, I get this


Frames processed: 502 (0 - 501)
FPS (min | max | average): 0.766 | 194871 | 7.700
Memory usage (phys | virt): 2248 | 2696 MiB
Thread count: 154
CPU usage (average): 10%
I wonder which filter in your script makes it so slow and keeps the CPU usage at 10% despite invoking 8 threads. There's clearly also a lot of internal multi-threading going on in some of your filters, otherwise you wouldn't end up with 154 threads.

I'd say it's one of (or the combinations of) these:
SuperResXBR()
ResizeX()

[Nevilne]

Do you not realize you're GPU constrained

[Groucho2004]

Do you not realize you're GPU constrained
Care to elaborate? Do you know which GPU he's using?

[Reel.Deel]

@MysteryX

The latest SVPflow (v4.0.0.128) states that all filters are compatible with MT mode 1 so you might want to add this:

SetFilterMTMode("SVSuper", 1)
SetFilterMTMode("SVAnalyse", 1)
SetFilterMTMode("SVSmoothFps", 1)

Also are you sure that your Shader plugin is compatible with mode 2? Add the following and see if it helps any (are these all the filters in your plugin?).

SetFilterMTMode("ConvertFromShader", 3)
SetFilterMTMode("ConvertToShader", 3)
SetFilterMTMode("ExecuteShader", 3)
SetFilterMTMode("Shader", 3)

[pinterf]

In the x64 support in core filters, part 1 (https://github.com/AviSynth/AviSynthPlus/pull/12) PR tp7 mentioned that only planar and RGB32 turn functions were optimized. However, the turn filter was refactored (https://github.com/AviSynth/AviSynthPlus/pull/12/commits/3abd944178c2cb0d8a6a132d3c1661b5deb97914).

No problem with Turnleft/TurnRight

Managed to invoke the problem as:
(clown.png is 192x256)
ImageSource("clown.png").ConvertToRGB24().Trim(0,49)
Spline16resize(Width(),Height(),-0.5,-0.5)

In AVS+ there is a shift, in avs 2.6 no shift.
Question: which is the correct one?

[pinterf]

With AviSynth+ r1849 x64, it doesn't load at all. AvsMeter stays stuck at "Reading frames..."

Edit: It is InterFrame that AVS+ x64 doesn't like. If I comment out Interframe, I get this


Frames processed: 502 (0 - 501)
FPS (min | max | average): 0.766 | 194871 | 7.700
Memory usage (phys | virt): 2248 | 2696 MiB
Thread count: 154
CPU usage (average): 10%


I also had this problem some days ago, without Interframe worked, with Interframe did not.
The last thing I saw in debugView:
[17364] Cache::GetFrame LRU_LOOKUP_NOT_FOUND: [ConvertToShader] n= 0
child=0000000003A2F310
frame=000000000A1BB2A0
framebefore=000000000A1BB2A0 videoCacheSize=1 SeekTimeWithGetFrame:0.004151

and the process is stuck here. (Avsmeter64 says: reading frame)
But previously there were successful similar actions, such as:

[17364] Cache::GetFrame LRU_LOOKUP_NO_CACHE: [ConvertToShader] n= 0
child=0000000003A2F3E0
frame=000000000A145890 vfb=0000000005128F30 videoCacheSize=0 SeekTime :0.818723
[17364] Cache::GetFrame LRU_LOOKUP_NO_CACHE: [ConvertToShader] n= 0
child=0000000003A2F3E0
frame=000000000A145610 vfb=0000000005128F90 videoCacheSize=0 SeekTime :0.821725
[17364] Cache::GetFrame LRU_LOOKUP_FOUND_AND_READY: [ConvertToYV12] n= 0
child=00000000036B8B10
frame=000000000AF2A810 vfb=0000000005121F10 videoCacheSize=1 SeekTime :0.000005
[17364] Cache::GetFrame LRU_LOOKUP_FOUND_AND_READY: [ConvertToYV12] n= 0
child=00000000036B8B10
frame=000000000AF2A810 vfb=0000000005121F10 videoCacheSize=1 SeekTime :0.000003
etc...


so I cannot tell you what happened.

Then I disabled MT (no Prefetch line). It worked.
And re-enabled Prefetch(1) and now I got only:
(mostly) ExecuteShader: CopyInputClip failed
(rarely) ExecuteShader: ProcessFrame failed

[MysteryX]

Do you not realize you're GPU constrained
Yes, I'm using AviSynthShader which I wrote myself. The bottleneck is memory transfers from the GPU back to the CPU.

@MysteryX

The latest SVPflow (v4.0.0.128) states that all filters are compatible with MT mode 1 so you might want to add this:

SetFilterMTMode("SVSuper", 1)
SetFilterMTMode("SVAnalyse", 1)
SetFilterMTMode("SVSmoothFps", 1)

Also are you sure that your Shader plugin is compatible with mode 2? Add the following and see if it helps any (are these all the filters in your plugin?).

SetFilterMTMode("ConvertFromShader", 3)
SetFilterMTMode("ConvertToShader", 3)
SetFilterMTMode("ExecuteShader", 3)
SetFilterMTMode("Shader", 3)

Perhaps this "might" help, but it works perfectly in x86. There is no reason why the x64 code should be any less compatible.

In AVS+ there is a shift, in avs 2.6 no shift.
Question: which is the correct one?
AVS 2.6 is correct with no shift.

Then I disabled MT (no Prefetch line). It worked.
And re-enabled Prefetch(1) and now I got only:
(mostly) ExecuteShader: CopyInputClip failed
(rarely) ExecuteShader: ProcessFrame failed
That is strange. I wrote those myself. I haven't really tested the x64 version of AviSynthShader but some people tried it and said it works. Does it work with a previous build of AVS+?

[pinterf]

@MysteryX
Also are you sure that your Shader plugin is compatible with mode 2? Add the following and see if it helps any (are these all the filters in your plugin?).

SetFilterMTMode("ConvertFromShader", 3)
SetFilterMTMode("ConvertToShader", 3)
SetFilterMTMode("ExecuteShader", 3)
SetFilterMTMode("Shader", 3)

When I set either ConvertToShader _or_ ConvertFromShader to MT mode 3, it works.
If both of them are mode 2, it stucks.

[Groucho2004]

the process is stuck here. (Avsmeter64 says: reading frame)
That simply means that Avisynth doesn't return from a "PVideoFrame::GetFrame()" call.

[MysteryX]

When I set either ConvertToShader _or_ ConvertFromShader to MT mode 3, it works.
If both of them are mode 2, it stucks.
I could debug the DLL to see where it crashes, but the fact that it works with mode 2 in x86 and that it works with mode 3 in x64 indicates that the code itself is working.

[MysteryX]

Every since I switched from AviSynth 2.6 to AviSynth+, with SVP, sometimes there is green bars artifacts. It happens rarely and only for a frame or two and then it's fine so it's hard to reproduce, but it would be something to keep an eye out for.

[pinterf]

Managed to invoke the problem as:
(clown.png is 192x256)
ImageSource("clown.png").ConvertToRGB24().Trim(0,49)
Spline16resize(Width(),Height(),-0.5,-0.5)

In AVS+ there is a shift, in avs 2.6 no shift.
Question: which is the correct one?

Fixed

RGB24 and RGB32 resizers were shifting the image horizontally to the opposite direction.
The phenomenon became more pronounced when the crop values were much larger than MysteryX sample with 0.5.

b=ImageSource("clown.png").Trim(0,49).ConvertToRGB24()
a=b.Spline16resize(b.Width(),b.Height(),20,20)
b=b.Spline16resize(b.Width(),b.Height(),-20,-20)
StackHorizontal(a,b)


Now it looks the same as in other color spaces.
MysterX, thank you for the report. Release: later.

[Reel.Deel]

@Everyone using MT

Small update to the MT modes list (http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes). Added a handful of source filters, SVPflow, and a few corrections. Hopefully more to come.
Someone recently added LanczosResize to the list. I thought all the internal filters already register themselves?


@pinterf
Thanks for the fix!

[BakaProxy]

Idk if this has already been asked and/or answered but is it possible to use mvtools in mt? Uhh more like whenever I use mdegrain (and the vectors that come allong) cpu utilization is rather low, some scenarios even only 20%. I've tried every mt mode with mvtools but it either completely freezes the encode or it doesn't change anything performance wise. Prefetch amounts don't change anything as well, it just takes longer to start with large amounts.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[Chikuzen]

Someone recently added LanczosResize to the list. I thought all the internal filters already register themselves?


It's strange.
All internal resizers except PointResize are using common code.
The differences are just coefficients(calculated at the time of initialization of a script) and number of refference samples.
If LanczosResize is not MT_NICE_FILTER, then others are also same.

[pinterf]

Only source filters (AVISource, AVIFileSource, WAVSource, OpenDMLSource) and ChangeFPS are MT_SERIALIZED, everything else is NICE_FILTER. They are registered inside Avisynth+

[Reel.Deel]

Only source filters (AVISource, AVIFileSource, WAVSource, OpenDMLSource) and ChangeFPS are MT_SERIALIZED, everything else is NICE_FILTER. They are registered inside Avisynth+

Thanks for the clarification, I'll add a note so people won't add internal filters to the MT modes list.

Quick question: there's a undocumented parameter in SetFilterMTMode (bool force) (https://github.com/pinterf/AviSynthPlus/blob/MT-pfmod/avs_core/include/avisynth.h#L1010). Do you have any idea what it does? Is the default false? I never got a chance to ask ultim when he was still around.

[Reel.Deel]

According to avisynth.cpp, if 'force' is set to true, MTMode of the filter refuses to be overwritten by a script.
Thus, users cannot change MTMode of all internal filters.

Thanks Chikuzen, I first saw it used here (http://archive.fo/DvrEB), unfortunately I cannot read Japanese.

If I add force=true to the mt modes list would that prevent users from overwriting it in their scripts or does it only work for internal filters/ external filters that register themselves?

[Chikuzen]

Thanks Chikuzen, I first saw it used here (http://archive.fo/DvrEB), unfortunately I cannot read Japanese.

If I add force=true to the mt modes list would that prevent users from overwriting it in their scripts or does it only work for internal filters/ external filters that register themselves?

oops, sorry. I was wrong.
If user set 'SetFilterMTMode("somefilter", mode, force=true)', he can overwrite the MTMode.

[MysteryX]

@MysteryX

The latest SVPflow (v4.0.0.128) states that all filters are compatible with MT mode 1 so you might want to add this:

SetFilterMTMode("SVSuper", 1)
SetFilterMTMode("SVAnalyse", 1)
SetFilterMTMode("SVSmoothFps", 1)

Adding this causes the x86 script to freeze on start.

[MysteryX]

I have this script. When I open in MPC-HC x86, it loads fine and plays slowly.

When I seek, however, 50-80% of the times it completely freezes the player.


P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"KNLMeansCL.dll")
LoadPlugin(P+"Shaders\Shader.dll")
Import(P+"Shaders\Shader.avsi")
LoadPlugin(P+"svpflow1.dll")
LoadPlugin(P+"svpflow2.dll")
Import(P+"InterFrame2.avsi")
Import(P+"ResizeX.avsi")

SetFilterMTMode("DEFAULT_MT_MODE",2)
SetFilterMTMode("LWLibavVideoSource",3)
SetFilterMTMode("LWLibavAudioSource",3)
SetFilterMTMode("KNLMeansCL",3)
file="Input.mpg"
LWLibavVideoSource(file, cache=false, threads=1)
AudioDub(LWLibavAudioSource(file, cache=false))
Crop(0, 0, -8, -0)
ConvertToYV24()
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0)
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2, MatrixIn="601")
ConvertToYV12()
InterFrame(Cores=8, Tuning="Smooth", NewNum=60, NewDen=1, GPU=true)
SuperResXBR(2, 0.6, 0, XbrStr=2, XbrSharp=1.2, fWidth=1012, fHeight=778)
ResizeX(1004, 768, 0, 5, -8, -5)
Prefetch(8)

[Boulder]

Isn't the freezing due to cache=false?

[MysteryX]

Isn't the freezing due to cache=false?
No.

If I replace with AviSource, then it freezes all the time.

If I remove InterFrame, then it loads and seeks fine; which is weird because SVP itself is working perfectly.

I made sure to copy the latest SVP DLLs from SVP's plugin folder into my Encoder folder, but that's not helping.

[pinterf]

I have this script. When I open in MPC-HC x86, it loads fine and plays slowly.
When I seek, however, 50-80% of the times it completely freezes the player.


1.) What is the resolution of your input file? In Avs+ 32bit, using 1280x720 source I have memory problems.
Seems that when other (non-avsplus-core) processes occupy significant amount of memory after the script starts, and the total nears to 3GB, could not balance and free-up enough memory.

2.) My source is 384x288.With this original size there are no memory problems.
Your script still doesn't run for me even with prefetch(1) (from avsmeter. The usual "reading frames")
If I set only one of these to mode 3
SetFilterMTMode("ConvertFromShader", 2)
SetFilterMTMode("ConvertToShader", 2)
SetFilterMTMode("ExecuteShader", 2)
SetFilterMTMode("Shader", 2)
SetFilterMTMode("SVSmoothFps", 3)

then it works.

[asarian]

Memory usage is 150% higher than the x86 version and performance is 15% slower even without Interframe

Definitely no gain here.


Thanks for the testing.

I myself have decided not to bother with AviSynth 64-bit any more. Last time I did (which, granted, was a while back; but your data doesn't look promising), it was crashing all over the place. We got VapourSynth now. :)

[Groucho2004]

1.) What is the resolution of your input file? In Avs+ 32bit, using 1280x720 source I have memory problems.
Seems that when other (non-avsplus-core) processes occupy significant amount of memory after the script starts, and the total nears to 3GB, could not balance and free-up enough memory.

2.) My source is 384x288.With this original size there are no memory problems.
Your script still doesn't run for me even with prefetch(1) (from avsmeter. The usual "reading frames")
If I set only one of these to mode 3
SetFilterMTMode("ConvertFromShader", 2)
SetFilterMTMode("ConvertToShader", 2)
SetFilterMTMode("ExecuteShader", 2)
SetFilterMTMode("Shader", 2)
SetFilterMTMode("SVSmoothFps", 3)

then it works.
Very accurate assessment.
This Shader thingy is monstrous and uses insane amounts of memory.
The SVP stuff is quite buggy and also uses the GPU and should therefore run in mode 3, I suppose. Not sure if "SetFilterMTMode("SVSmoothFps", 3)" is sufficient, though.

[pinterf]

No change if I set GPU=false in Interframe parameter.
I think that we face an unlucky timing, where the problem of a missing critical section or causes the problem.
I will definitely look into it because I like solving puzzles.

[pinterf]

Thanks for the testing.

I myself have decided not to bother with AviSynth 64-bit any more. Last time I did (which, granted, was a while back; but your data doesn't look promising), it was crashing all over the place. We got VapourSynth now. :)
Regarding the statement of much larger memory usage: it was tested with the old x64 build vs new x86 version.
(Because the script did not run on the current x64 build)

When we make the script runnable (setting MT mode 3, as I wrote previously), x64 version has lower memory need than the x86 version.

But it is true that the x86 version is 10-20% faster in this specific situation (based on comparison with my r1850 builds for x64 and x86, but it should be the same with r1849). Reason? One or more plugin do not have optimized x64 assembly path and use C code instead? Maybe.
For QTGMC I have a 4-8% speed gain using avs+ x64 version.

[MysteryX]

1.) What is the resolution of your input file? In Avs+ 32bit, using 1280x720 source I have memory problems.
Seems that when other (non-avsplus-core) processes occupy significant amount of memory after the script starts, and the total nears to 3GB, could not balance and free-up enough memory.
I use 352x288 input file.

Your script still doesn't run for me even with prefetch(1) (from avsmeter. The usual "reading frames")
If I set only one of these to mode 3
SetFilterMTMode("ConvertFromShader", 2)
SetFilterMTMode("ConvertToShader", 2)
SetFilterMTMode("ExecuteShader", 2)
SetFilterMTMode("Shader", 2)
SetFilterMTMode("SVSmoothFps", 3)

then it works.
For me it works with AVS x86.

Very accurate assessment.
This Shader thingy is monstrous and uses insane amounts of memory.
The SVP stuff is quite buggy and also uses the GPU and should therefore run in mode 3, I suppose. Not sure if "SetFilterMTMode("SVSmoothFps", 3)" is sufficient, though.
Yet there's nothing better to replace them, and they both produce great results :) SVP works good in mode 2. In fact, it's entirely designed and optimized for multi-threading as it must run in real-time... often with 16+ threads for real-time playback. SVP itself is now actually very stable with the latest build of AVS+. It's working better than ever. Not sure why we're having problems with it here. Maybe the script calling it (InterFrame) didn't get updated and that's where the difference is?

[MysteryX]

Chainik said this about SVP

There's a little mess with SVP libs versions and MT mode 1 support.
- all pre-Vapoursynth libs are MT mode 2 only
- builds 128 - 132 are compatible with MT mode 1 BUT there's a mysterious memory corruption somewhere in svpflow2 which gives us that error (http://www.svp-team.com/forum/viewtopic.php?id=3200)
- as a temporary fix we released svpflow2.dll .135 as an old (pre-VS) version upgraded for the latest SVP Manager, so it is NOT compatible with MT mode 1

The script with SetFilterMTMode("SVSmoothFps", 1) using svpflow2.dll ver.135 will definitely freeze on start.


However I really don't see any improvement in using MT mode 1 with build 132 libs.
Here's how it works:

"old" Avisynth-only libs in MT=2: N instanes of AVS's VideoFilters running at the same time.

"new" multi-platform libs contain a platform-independent thread-safe "cores"
- Vapoursynth: 1 thread safe VS filter uses 1 "core"
- Avisynth MT=2: N single-threaded VideoFilters share 1 thread safe "core"
- Avisynth MT=1: 1 thread safe VideoFilter uses 1 "core" - just like in Vapoursynth version

The point is there's just one "core" is all cases.

[Reel.Deel]

Adding this causes the x86 script to freeze on start.

Hmm, if I set your shader filters to mode 3 and SVP to mode 1 it doesn't freeze, tested with 32 and 64-bit. Both perform about the same. I see that pinterf has to set SVSmoothFps to mode 3 to get it to work, something is really odd here.

One thing I did notice while testing is that performance is about the same with MT and with it disabled. Just out of curiosity, what's the performance of your script when you run it with MT disabled?


I myself have decided not to bother with AviSynth 64-bit any more. Last time I did (which, granted, was a while back; but your data doesn't look promising), it was crashing all over the place. We got VapourSynth now. :)

I don't think MysteryX's result are a proper depiction of AviSynth+ MT. With QTGMC I get better performance with AVS+ than with VS.

[MysteryX]

what's the performance of your script when you run it with MT disabled?
With MT I get 9.1fps
Without MT I get 2.2fps

That's because I have 8 cores. Without MT, only 1/8th of my computing power is used. Plus with AviSynthShader, the CPU has to wait for the GPU to finish processing so the CPU is idle a lot of the time; alternating between the CPU and the GPU working but not both simultaneously.

I don't think MysteryX's result are a proper depiction of AviSynth+ MT. With QTGMC I get better performance with AVS+ than with VS.
I do get slightly better performance with AviSynth+ than AviSynth 2.6 MT, and considerably lower memory usage, but only with the x86 version.

However, my results aren't very representative of the effectiveness of CPU frame processing because the bottleneck is GPU memory transfers. It does, however, test the memory usage, effectiveness and stability of memory transfers. I agree that a script where the CPU is the bottleneck would be a better representation of the computing effectiveness of AviSynth+.

[MysteryX]

I had posted benchmark results of x64 which were not good, however x86 works well. It would be more fair to show the good results with x86.

Curiously enough, after updating SVPFlow to the latest version, it started crashing in AVS+. After reverting back to the version that comes with InterFrame, it works again (??)

AND, after reverting back to that version of SVPFlow, I'm no longer getting freezes when seeking. That's odd because SVP itself is working perfectly fine with AVS+.

AviSynth 2.6

Frames processed: 304 (0 - 303)
FPS (min | max | average): 1.391 | 1000000 | 9.087
Memory usage (phys | virt): 823 | 1200 MiB
Thread count: 139
CPU usage (average): 11%


AviSynth+ r1849

Frames processed: 303 (0 - 302)
FPS (min | max | average): 1.032 | 1000000 | 9.121
Memory usage (phys | virt): 544 | 992 MiB
Thread count: 155
CPU usage (average): 13%

AviSynth+ is very slightly faster and the speed is more consistent. Memory usage is clearly lower.

Again, running it in x64 is a whole other story.

[pinterf]

Ok, MysteryX, check PM.
It works in x64, with your plugins in mode 2 and spvflow in mode 1 (spv version 4.0.0.128)
(but only one test is not a test)

[Chikuzen]

When a temporal filter calls child->GetFrame() more than one times, the speed of the filter will be changed by the order of that calls on MT mode.

I noticed this when I rewrote ReduceFlicker for avs2.6/avs+.

my repository (https://github.com/chikuzen/ReduceFlicker/blob/master/avisynth/src/ReduceFlicker.cpp#L68)
binary(32bit) (https://dl.dropboxusercontent.com/u/19797864/forum/ReduceFlicker26.dll)


LoadPlugin("ReduceFlicker26.dll")
SetFilterMTMode("ReduceFlicker", MT_NICE_FILTER)
ColorBars(1920, 1080, "YV12").Spline36Resize(1280, 720)
ReduceFlicker(strength=3, aggressive=true, grey=false, opt=1, raccess=true)
prefetch(4)


When I set raccees(I added this option to confirm this behavor) to false, almost all prefetch loses its power.
(490fps -> 175fps on my i7-4790 desktop)

Probably, it'll be also same as this that prefetch doesn't work for TemporalSoften().

[pinterf]

First I wanted to say that hmmm, interesting phenomenon. If someone would develop a filter chain visualizer I would be grateful.

Then a memory came to mind, from times when I was bothering with the cache problem thingy.

I've seen an adaptive pattern matching in the prefetch code. As I recall that the algorithm tries to guess the request pattern, e.g. frames are requested by one (1-2-3-4...), two (2-4-6-8... what is it used for, I don't know, SelectEven?), or backward(100-99-98-97...), etc.
If there is enough data for a rule, it "locks" on this pattern and continues the prefetch using this prediction.

(And I noticed that Frame 0 is not prefetched, prefetching starts with frame 1 .... Tried to fix it for the sake of perfectness but did not have the knowledge and patience for this)

[LigH]

Long, long time ago, I remember a project named "AVE AviSynth Visual Editor". I doubt it ever reached practical relevance...

[kypec]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

[pinterf]

Maybe I could use a signature line

[MysteryX]

Maybe I could use a signature line
I'd see something more simple for you, such as

> Me :) (https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod)

[tebasuna51]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

Done.
Let me know if it is OK.

[yup]

pinterf!
Please advice how install your 64 build.
I am try first install stable release
http://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.exe
and after replace Avisynth.dll in windows\system32 directory, but I can not use commands SetFilterMTMode and #Prefetch.
yup.

[kypec]

Done.
Let me know if it is OK.

Excellent, :thanks::thanks::thanks:

[LigH]

@ yup:

If you ran the installer, I would expect it having already put the DLLs in place. I heavily doubt you should still replace DLLs in system directories after running the installer.

[kypec]

@ yup:

If you ran the installer, I would expect it having already put the DLLs in place. I heavily doubt you should still replace DLLs in system directories after running the installer.
Replacing DLLs manually is the only way at the moment since pinterf's builds do not have installer.

[LigH]

Then I misinterpreted the existence of *.exe downloads...

[luigizaninoni]

Staxrip test builds https://github.com/stax76/staxrip/blob/master/md/test-build.md include avisynth+ installer with pinterf mods (perhaps not the very latest)

[yup]

kypec You are right I ant install pinterf's build.
When I see simple script in Virtualdub64
Version()
I see version Avisynth+ 0.1 r1576 64, not r1849.
Where my fault? I am only replace dll after install r1576.
yup.

[Groucho2004]

kypec You are right I ant install pinterf's build.
When I see simple script in Virtualdub64
Version()
I see version Avisynth+ 0.1 r1576 64, not r1849.
Where my fault? I am only replace dll after install r1576.
yup.
The easiest way to troubleshoot your Avisynth install is to run "AVSMeter64 -avsinfo -log" and post "avsinfo.log". Use the latest AVSMeter version.

[yup]

I am uninstall Avs+ and install StaxRip test build.
Avsmeter message can not load avisynth.dll.
May be need some Microsoft redistributable?
yup.

[Groucho2004]

May be need some Microsoft redistributable?
Yes, you do (2015).

[yup]

Yes, you do (2015).

Groucho2004 :thanks:
Now all work.
yup.

[Groucho2004]

Avsmeter message can not load avisynth.dll.
Was that the whole error message?

[yup]

Was that the whole error message?
Now all work (after install VS2015), no error.
yup.

[Groucho2004]

Now all work (after install VS2015), no error.
yup.
Yes, I understand. My question was about the AVSMeter error message you got before.

[yup]

Yes, I understand. My question was about the AVSMeter error message you got before.

I can not read first time (not readable symbol) , I am under Windows 10 Russian.
yup.

[Reel.Deel]

Could any moderator be so kind and include link to pinterf's Git repo with latest Avisynth+ builds on the first page of this thread, please? It took me quite some time to dig those information from his posts scattered across dozens of the last pages...

Just for future reference, the AviSynth+ wiki page has all of this information: http://avisynth.nl/index.php/AviSynth%2B#Downloads

[pinterf]

I hope, this week I release a new version including that rgb resizer crop fix. Then I think we should create a version with real installer. Volunteer needed for this task.

After this I think I will clean the code a bit and merge back all my modifications to my master branch and get rid of the pfmod suffix.
Clean code is a big advantage of this project. Without it I would not understand and reverse engineer the core in such a short time (my first debug logs were created two month ago).

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?). Or playing with preparing the core for 16bit/float support, this will require an extended interface later.

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future? Can we expect a more dynamic development cycle there or we can experiment with it freely? I could ask them (who?) directly but maybe you, old guys here with broader knowledge on the avs history and developers can give some informations about it.

[MysteryX]

@Everyone using MT

Small update to the MT modes list (http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes). Added a handful of source filters, SVPflow, and a few corrections. Hopefully more to come.
Someone recently added LanczosResize to the list. I thought all the internal filters already register themselves?

Perhaps it would be good to post this list on the first page of this thread? It's difficult to find.

I tried this list and this showed up corrupt

nnedi3_rpow2(2)


Adding this doesn't help

SetFilterMTMode("nnedi3_rpow2", MT_MULTI_INSTANCE)


So the problem must be in one of the other filters being called by NNEDI3; kind of hard to debug.

SVSuper, SVAnalyse and SVSmoothFps also has issues with MT=1 right now; better leave to MT=2 until it is fixed and the fixed DLLs are released with an update to InterFrame. They said there was a weird memory leak, and in either case, whether using MT=1 or MT=2, there is still a single SVP core running so it doesn't change much.

You can add this to the list.
ConvertToShader, ConvertFromShader and Shader support MT=1. ExecuteShader supports MT=2.

Just released AviSynthShader v1.4 (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.4) with Pinterf's code corrections and a few other fixes and improvements.

[MysteryX]

Then I think we should create a version with real installer. Volunteer needed for this task.
Why not use the existing installer? Who produced it? Is the source code available? Ideally we'd have an open source Inno Setup project file that anyone can edit and build. I'd put that Inno Setup file in the same repository as AviSynth+.

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?).
Isn't AviSynth supposed to be written with plain C to work with various compilers?


Or playing with preparing the core for 16bit/float support, this will require an extended interface later.

System architecture starts to get more in my field. If an extended interface needs to be done, this has to be well-planned. This would also mean that all plugins written for it won't work with previous versions, but previous filters will be compatible with this version. Such an upgrade to the interface has to be done right the first time. And then, none of the filters will support it yet as they have to be adapted for 16-bit support.

Here's some information about 16-bit support
http://avisynth.nl/index.php/High_bit-depth_Support_with_Avisynth
Previous efforts
http://forum.doom9.org/showthread.php?t=162436

and what would be the advantages over using Stack16 format? 16-bit processing can be done right now with Stack16 format and AviSynthShader.

In terms of major features, there are 2 options for next steps:

1. Getting x64 to work as expected

2. Implementing 16-bit support

Which one is most important?

I believe that fixing the code for x64 might uncover a few hidden issues affecting the x86 build. Working on 16-bit support is definitely more exciting to program.

[MysteryX]

Honestly, I wouldn't try to convince the community to rebuild all plugins with AviSynth+ 16-bit support until AviSynth+ itself is good enough to convince the majority of users to use it instead of v2.6

Which brings this question: are there still reasons for people to keep using AviSynth 2.6 at this point?

[pinterf]

Isn't AviSynth supposed to be written with plain C to work with various compilers?

There are intrinsics, the problem was mentioned recently.


and what would be the advantages over using Stack16 format? 16-bit processing can be done right now with Stack16 format and AviSynthShader.

Ugly and slow. Dead end but exists because of Avisynth limitations.


In terms of major features, there are 2 options for next steps:
1. Getting x64 to work as expected

I think this point now depends on plugin writers.


2. Implementing 16-bit support
Which one is most important?
I believe that fixing the code for x64 might uncover a few hidden issues affecting the x86 build. Working on 16-bit support is definitely more exciting to program.

The second point is more entertaining for me. Personally I don't like coding if there is no fun in doing it.

I wouldn't convince anyone. We are still in the phase of convincing plugin writers to support the avs 2.6 color spaces as a minimum.

[Reel.Deel]

Then I think we should create a version with real installer. Volunteer needed for this task.


stax76 made installers for r1779 and r1825, maybe he can help out.

Perhaps it would be good to post this list on the first page of this thread? It's difficult to find.

I tried this list and this showed up corrupt

nnedi3_rpow2(2)


Adding this doesn't help

SetFilterMTMode("nnedi3_rpow2", MT_MULTI_INSTANCE)


So the problem must be in one of the other filters being called by NNEDI3; kind of hard to debug.

It seems the output for nnedi3_rpow2 is corrupt for all colorspaces except YV24 and Y8. nnedi3_rpow2 uses the turning functions and resizers (for correcting center shift, only when cshift is enabled). Maybe jpsdr can help out.

SetFilterMTMode("nnedi3", 2)
SetFilterMTMode("nnedi3_rpow2", 2)

ColorBars()
ConvertToRGB24()
nnedi3_rpow2(2)
Prefetch(4)

You can add this to the list.
ConvertToShader, ConvertFromShader and Shader support MT=1. ExecuteShader supports MT=2.
I'll add it, better yet, maybe you can make your plugin self-register the appropriate MT mode. Take a look here: http://forum.doom9.org/showthread.php?p=1667529#post1667529

Why not use the existing installer? Who produced it? Is the source code available? Ideally we'd have an open source Inno Setup project file that anyone can edit and build. I'd put that Inno Setup file in the same repository as AviSynth+.
Line0 made the installer and it's already in the repository: https://github.com/pinterf/AviSynthPlus/tree/MT-pfmod/distrib

[yesmanitsbearman]

Just a random note, I have done a first full 64 bit encode with
sanimebob()
srestore(omode=4, cache=10).srestore(frate=23.976)
smam()

Only thing that was missing really is GrunT plugin x64 build. I have made one and posted in appropriate thread. Perhaps someone can add it to the wiki.

[qyot27]

After this I think I will clean the code a bit and merge back all my modifications to my master branch and get rid of the pfmod suffix.
The better way would be to open a pull request for your changes (not with the fixes from Chizuken, etc.) on the upstream git repo, just to keep things clean. Upstream doesn't use master for the MT stuff yet, so it could potentially create all sorts of headaches when/if ultim shows up again.

I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case. Worse comes to worst, a new organization and repo setup would be needed to make sure there's always someone to commit (I could do that, I just would prefer not to until there's no other choice).

And remember when cleaning up that AviSynth+ uses four white spaces for indentation, not tabs.

There are still many interesting tasks, qyot27 mentioned the possibility for using non MSVC compilers (clang?). Or playing with preparing the core for 16bit/float support, this will require an extended interface later.
ultim started adding stubs for a newer AviSynth+-specific API, but it's never stabilized. High bit depth likely would have been part of that.

The non-MSVC compiler thing would mostly be when targeting non-Windows. Linux and OSX support in particular (clang is OSX's and FreeBSD's default compiler).

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future? Can we expect a more dynamic development cycle there or we can experiment with it freely? I could ask them (who?) directly but maybe you, old guys here with broader knowledge on the avs history and developers can give some informations about it.
Generally, we've been caring less and less about what classic AviSynth does, if only for the fact that the entire reason Plus exists is because Classic (or rather, IanB, who is pretty much the only active dev to classic aside from Wilbert occasionally fixing things) was resistant to ultim's changes - partly because there were so many of them at the time*. But 2.6 development has been moving at a snail's pace for years; last I checked, the CVS for it hasn't been touched since last September.

*somewhere around 56 commits; but after the fork happened, Plus development rocketed forward with several hundreds of commits in a very short timeframe. And then Plus entered a hiatus for about a year, then another sprint of activity in March 2015, and that's more or less where we are today.

In the wake of 2.6's RC1 and RC2/RC3/Final updates, I've taken the CVS history, compared it against AviSynth+, determined to the best of my ability what can be merged, and opened a pull request containing those changes. The RC1 integration was what started things up again in March 2015, which eventually left off at r1825. RC2/RC3/Final was so meager that it still hasn't been merged (also, there was a bit of a back-and-forth about the issues of Plus' changes to avisynth.h during the restricted license era and moving them up into the restored-clause header; the C interface header, avisynth_c.h, never had this problem - it's completely unique to the C++ interface AviSynth traditionally focused on).

Isn't AviSynth supposed to be written with plain C to work with various compilers?
AviSynth is written in C++. AviSynth+ moved this requirement to C++11. It's only ever been expected to be compiled on MSVC or MSVC-compliant compilers (like ICL), so things like portability weren't that big of a concern.

The problem isn't actually the code, it's the fact that the main AviSynth API was written in C++ as well, which means that C++ plugins have to be built with the same compiler as the core or else they'll fail to load. This stems from VC++ and g++ not being compatible with each other's addressing and name mangling and all sorts of other things. For plain C, cl and gcc are [mostly?] compatible, and is why the C interface exists.

At least what I hoped (and the talk seemed to be leaning toward) was that any new AviSynth+ APIs would be written in C or the C interface would be mainlined and focused on (especially with a potential move to Linux/OSX), which would erase the portability problem from the start. The C++ problem doesn't matter on non-Windows, though, since they don't have the VC++/g++ divide to worry about.

There are intrinsics, the problem was mentioned recently.
The intrinsics issue has less to do with whether it will build and far more to do with not causing grief for users with even slightly older computers to use them. It was also specifically in regard to building with GCC; if Clang truly does not require the same 'intrinsics must be split' nonsense, then dealing with them is not the dealbreaker for cross-platform support that it is with GCC.

The intrinsics themselves are portable; in fact, they replaced the extremely non-portable SoftWire assembly that classic AviSynth relies on (and improved performance over SoftWire in most cases as well).

[TheFluff]

Btw. is there a roadmap in the old avisynth for supporting high bit depth in the near future?

Isn't AviSynth supposed to be written with plain C to work with various compilers?

The current Avisynth 2.6 development effort (alpha release earlier today!) is dedicated to making it possible to build Avisynth with any Microsoft Visual C++ version newer than 6.0. Up until now, it was not possible to build "official" Avisynth builds with any compiler other than VC6. Microsoft Visual C++ 6.0 was released in 1998. I don't call Avisynth software for the previous millennium only to provoke people - it's the literal truth.

Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.

[MysteryX]

Official Avisynth development is as dead as a doornail. You don't need to care about what happens with it. You don't even need support its plugins if you don't want to (but you can if you want to; if VS can fake the plugin interface so can you). Fork away - there are already like five commonly used variants competing for attention so one more can hardly hurt.
To be honest, the advantage of AviSynth over VapourSynth is mainly the vast library of available plugins.

If you create a custom interface for AviSynth+, I think it is very unlikely that plugin developers will get back in the game years after they wrote their plugin to support the new interface. Working on porting those plugins to VapourSynth would be a better path for them.

But then VapourSynth has these limitations:
- No ffdshow support for SVP
- No audio support yet
- Limited library of plugins

In which cases AviSynth+ comes to the rescue.

[MysteryX]

btw, AviSynth 2.6 requires DevIL. Does AviSynth+ depend on that same library?

[MysteryX]

Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.


SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)


So this looks like a bug in AviSynth+. Without MT, it works.

[TurboPascal7]

I have no clue if anyone else (tp7?) has commit privileges to the main repo; because it would make things a lot easier if more than one person had the ability to push and were more easily contacted, just in case.

I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits (https://github.com/pinterf/AviSynthPlus/commit/7e0ae85b9e00b4a405f86bc4aeca6ced69732b22) will be cleaned up.

[Groucho2004]

Bug: NNEDI3 simply doesn't work with MT. It causes image corruption.


SetFilterMTMode("DEFAULT_MT_MODE", 3) #neither 2 nor 3 works
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3_rpow2(2, Threads=1)
Prefetch(8)


So this looks like a bug in AviSynth+. Without MT, it works.

Try this:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)

[pinterf]

I have full repository rights and unless something unexpected happens will be there to (at least lazily) review the changes and merge the PR, assuming debug/blogging commits (https://github.com/pinterf/AviSynthPlus/commit/7e0ae85b9e00b4a405f86bc4aeca6ced69732b22) will be cleaned up.
Yes, that's why I still left my original master branch untouched, did not want to mess it up with excessive comments that were important for me at that time.

[MysteryX]

Try this:
AviSource("Preview.avi", audio=false, pixel_type="YV12")
nnedi3(dh = true, Threads=1)
fturnleft()
nnedi3(dh = true, Threads=1)
fturnright()
Prefetch(8)

This one is working; and with turnleft instead of fturnleft it works too. Strange that the standard function is failing.

edi_rpow2 works though.

[jpsdr]

Maybe jpsdr can help out.

Sorry, but not realy. I don't see anything suspcious in the code, but and all the MT thing is not realy my stuff.
I think the code for nnedi3_rpow2 is linear (and clear i hope...) enough to reproduce all the steps/functions used in an avs script, if someone want to investigate.

[pinterf]

This nnedi_rpow2 thing happens in YV12 and YV16. No Prefetch and Prefetch(1) is OK. Nice task.

[jpsdr]

In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
If the MT mode is not happy with the way i do things, you'll have to explain me where and why. :confused:
The code is avaible on github, so anyone is free to take a look.

[MysteryX]

If MT doesn't like it, the question remains: why does it work with AviSynth 2.6 and not in AviSynth+?

[Groucho2004]

In that case, it probably also happen in YV411 and YUYV.
As it can easely be seen in the code, there is two paths : (RGB24,YV24,Y8) and (YV16,YV12,YV411,YUYV).
The only major difference between them it's that in case of YV16 and others, planes are extracted and processed separately.
But again, i see absolutely nothing wrong.
The problem is the same in the original nnedi3 from tritical. I don't think your changes have anything to do with it.

[Chikuzen]

Interesting information was written on comment space of this page by Takuan (Oh, he is my internet friend:D).
http://archive.fo/DvrEB

Takuan 2014/3/22 05:37

DGDecode_MPEG2Source returns 'env->Invoke(“crop”, AVSValue(CropArgs,5));' when crop is needed.
avs+ recognizes this filter as Crop(), not MPEG2Source() in this case.
avs+ tries to make MPEG2Source() work as MT_NICE_FILTER because Crop() is set as MT_NICE_FILTER internally.
This is why MPEG2Source crash on avs+'s MT mode.

Thus, you should set SetFilterMTMode("Crop", MT_SERIALIZED, force=true) when MPEG2Source requires Crop().

Probably, nnedi3_rpow2 will be recognized as internal resizer(MT_NICE_FILTER).
So you should use user script function instead of nnedi3_rpow2 when you want to set prefetch() if my guess is correct.

[Reel.Deel]

Interesting information chikuzen. I saw that too when I asked about the force parameter in SetFilterMTMode, I didn't quite understand it though. The MPEG2Source issue was fixed so maybe there's hope for nnedi3_row2. More information here: https://github.com/AviSynth/AviSynthPlus/issues/37

[pinterf]

Just wanted to ask, if there is any specific in the nnedi3_rpow2 function, because it seems that applying SetFilterMode on it is simply ignored and works like a NICE filter. I saw parallel calls to the rpow2 function in the debug logs and the corruption pattern is something like that nnedi3 core is working on the same internal buffers. 4x size images, U and V copied to the Y plane, etc.
Have to dig into it.
Remark: it looks like a regular avisynth script but written in C, learned again something new (Invoke).

[Chikuzen]

The MPEG2Source issue was fixed so maybe there's hope for nnedi3_row2.
The way to fix nnedi3_rpow2 issue is just remove tritical's PlanarFrame hack and internal buffers to make nnedi3 as MT_NICE_FILTER.

[jpsdr]

The way to fix nnedi3_rpow2 issue is just remove tritical's PlanarFrame hack and internal buffers to make nnedi3 as MT_NICE_FILTER.
But this is used only inside nnedi3, as nnedi3_rpow2 is "just" calling nnedi3. If it was this (and i agree for the possibility), shouldn't nnedi3 in that case also have corruption ? But it seems it's not the case.

Nevertheless, it could indeed be interesting and cleaner if possible to get rid of this hack, but it means i have to dig deaper on the code, and for now, i have no idea (and not much time) of how doing it.
Any advice, clue, very global ideas like (function "xxx" and "yyy" are a good start to look) is welcome.
Basicaly, the 1rst step would be, how doing properly what it's doing (creating using/buffer).

[Chikuzen]

But this is used only inside nnedi3, as nnedi3_rpow2 is "just" calling nnedi3. If it was this (and i agree for the possibility), shouldn't nnedi3 in that case also have corruption ? But it seems it's not the case.
env->Invoke does not automatically insert a cache after the filter you invoke. (http://avisynth.nl/index.php/Filter_SDK/Env_Invoke)
It seems that avisynth can't handle automaticaly a filter which invoked from other filter.
If it's possible, why plugin author have to call "InternalCache" manually ?
I don't think Avisynth+ can choose MT mode appropriately on invoked filter though it cannot insert internal cache automatically.

Any advice, clue, very global ideas like (function "xxx" and "yyy" are a good start to look) is welcome.
Basicaly, the 1rst step would be, how doing properly what it's doing (creating using/buffer).
TCannyMod (https://github.com/chikuzen/TCannyMod/blob/master/avisynth/src/tcannymod.cpp) ?
tcanny uses PlanarFrame hack and floating point read/write buffer allocated on constructor.
I removed them and change allocate buffers per each GetFrame().

[Groucho2004]

Wouldn't it be better to use a script function to achieve rpow2 with nnedi3/(f)turn calls and sort out chroma/luma alignment issues in that function instead of hard-coding it into the plugin?

[jpsdr]

If i understand properly, basicaly, it means that any filter which needs buffer and allocate them once for all in constructor and so free them in destructor (which is normaly the best and correct way to do) will be screwed with MT mode, because for the same instance/variable filter, several getframe can be runned in the same time (which doesn't occur in not MT mode), and so both will access the same buffer and corrupt each other.
Issue is not because of PlanarFrame hack, it's deeper, meaning that for being MT compatible, if you need buffers, you have to allocate and free them in GetFrame... Honestly, i don't like the idea, but don't know if actualy there is a better solution.
We are hitting here something deeper. It's design restriction. If you want your filter being MT compatible, you have design restrictions. But again, it's specific to this MT mode.
A better solution, but again hitting MT specific design, would be that constructor allow, once for all, several buffers, the number of buffer being decided by the number of multi-thread, and each GetFrame get some "Thread number" information, and so the correct buffer is used by the getframe. Again, the MT scheduler must assure that there is never two getframe of the same filter instance with the same number.

Anyone of course can discuss, agree, disagree (but in that case explain me why and where i'm wrong) with this.

[Chikuzen]

@jpsdr
If your filter repeats alloc/free same sized memory, Windows calculates the memory needed by all threads, and reserves them.
Freed buffer doesn't return to the system and waits for the next request, and reused just as it is.
Thus, allocate/free buffers per GetFrame is cheap costs now a day.
And this is very akin to the scheduler you want actually.

I think that implementing buffer scheduler is worse idea than re-implementing memcpy.

[Myrsloik]

Actually this is a bit of a problem in practice. In vs2015 and probably all somewhat modern versions it's only fast for small allocations. Like up to 1080p frames. Once you start allocating a whole 4k frame of space it simply calls virtualalloc. That's quite slow. Even stupid buffer reuse behind a global mutex easily beats that.

Not going to comment on any specific ideas but some kind of buffer reuse can (unfortunately) still help. Or just shove in tcmalloc if you don't use vs2015 and it'll basically do it for you.

[Chikuzen]

@mylsroyk
hmmm, interesting.
In that case first avisynth itself should use tcmalloc like VapourSynth.

[jpsdr]

I juste take a look at how to use mutex, i think i'll try to do something with some kind of buffer scheduler, but don't expect it too soon.

Edit :
I'll need to know how to do the following in the plugin :
- Get the avisynth version, to not use MT functions if you're not in a MT version (basicaly, if you're in avs+ or not, and which release).
- If you're in avs+, is there a way to detect if MT has been enable or not ? And if MT has been enabled, is there a way to know how many thread will be running ?

Is there a link on some information/tutorial or anything which explain how to do the listed before ?

:thanks:

Edit 2 :
Or... I'll just add (at the end, of course), an "MT" parameter, set to "1" by default, where you specify the maximum number of possible threads.

[pinterf]

I'm lost.
I have put a mutex in the nnedi3 class, and use it inside nnedi3 GetFrame, and there is no curruption. There are still parallel calls to nnedi3::GetFrame with the same frame number, but they are for different class instances. Different class, different mutexes, they are working fine.
But this is just a workaround and not the basic problem.

Except that how nnedi3_rpow2 works internally, it should work as-is.

But after inserting the nnedi3 mutex, something is still weird.

Avs 2.6 mt runs at 28.7 fps
Avisynth+
no prefetch: 7.6 fps (13%, thread count=20)
prefetch(1): 7.7 fps (13%, thread count=20) (same)
prefetch(2): 8.2 fps (15%, thread count=21)
prefetch(4): 8.7 fps (15%, thread count=23)
prefetch(8): 8.7 fps (15%, thread count=27)

[TurboPascal7]

jpsdr
I'm just gonna leave this (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/core/avisynth.cpp#L980) here. And here's an example (https://github.com/tp7/SangNom2/blob/e1f56542dac1e2ee69ff3f68e80339d23938ca01/SangNom2/sangnom.cpp#L833).

It should be pretty obvious that avisynth+ would not require every single plugin author ever to implement his own memory pool.

And I really should stop checking this thread.

[jpsdr]

AVSValue __cdecl Create_SangNom2(AVSValue args, void*, IScriptEnvironment* env) {
if (!env->FunctionExists("SetFilterMtMode")) {
env->ThrowError("SangNom2: this plugin only works with multithreaded versions of Avisynth+!");
}

Euh... Not for me ! ;)

But thanks for the example, it will allow me to see how to get informations and check things.

If the memory pool handle things "right", meaning allocating only if something asked doesn't exist yet, meaning it should stop allocating very quickly and only giving allready allocating pointers, yes, indeed, this doesn't bother me. But, if it's allocating/freeing on each getframe, i don't like it.
But didn't take a look at the pool code, so for now, doubt benefit...

[real.finder]

@jpsdr

I don't know if you could do it or not, but if you link nnedi3 with AVSTP it will easy to control MT in the script outside nnedi3

[jackoneill]

Reminder that NNEDI3 for Avisynth has internal multithreading: https://github.com/jpsdr/NNEDI3/blob/master/nnedi3/nnedi3.cpp#L577

[jpsdr]

This is begining nnedi3 specific, so i'll switch to the nnedi3 thread to continue discuss this topic.

[MysteryX]

I'll add it, better yet, maybe you can make your plugin self-register the appropriate MT mode. Take a look here: http://forum.doom9.org/showthread.php?t=168856&page=30#post1667529

I tried adding it but it doesn't seem to be having any effect.

This should cause the memory usage to go WAY down, and also to run much slower, which doesn't happen.

class ExecuteShader : public GenericVideoFilter {
public:
// Supported MT mode for AviSynth+
int __stdcall SetCacheHints(int cachehints, int frame_range) override {
return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
}
...
}

[MysteryX]

AviSynthShader now specifies its supported MT modes to AviSynth+ and is not necessary in the MT definition file anymore.

KNLMeans, however, isn't in the file either, so this line must be added.

SetFilterMTMode("KNLMeansCL", MT_SERIALIZED)

[jpsdr]

Is there a place/link which explain the differences and impact between all MT status like, MT_SERIALIZED, MT_NICE_FILTER to eventualy add in my filter the report of what they support.
I need the list of all the avaible status, and what they exactly mean for the filter reporting a such status. Where there is such information ?

[LigH]

A few hints are in AviSynth Wiki: AviSynth+ (http://avisynth.nl/index.php/AviSynth%2B); a few more are in the Avisynth+ MT modes definitions (https://gist.github.com/tp7/8899021) (you may have to log in to github to have access here).

As a thumb rule: To be an MT_NICE_FILTER, the code must be programmed in a "threading aware" ~ "re-entrant" style (preferably only function parameters and local variables, no global variables where they don't need to be global) and should not fork own threads. If a filter produces at least probably wrong output in an MT environment, it may have to be set to MT_SERIALIZED even though that will produce a bottleneck, reducing its execution to one thread and possibly even requesting its input in an ordered manner. Filters creating own threads may work as MT_MULTI_INSTANCE filter only in case their number of internal threads is limited, possibly to only 1.

[MysteryX]

From what I understand,

MT_NICE_FILTER means there is one class instance and GetFrame gets called several times at once from various threads on the same class. When Pinterf went through my code, he wrote "Say no to globalism!" No global variables unless they are read-only. All working buffers must be created within GetFrame.

MT_MULTI_INSTANCE means that one instance of the class gets created for each thread and each instance is single-threaded. One thread may process frames 1, 4, 7 and 9 while other threads process other frames.

I'm not yet sure what impact MT_SERIALIZED has on the code.

The way to define it is in the Init function


extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
env->AddFunction("ConvertToShader", "c[Precision]i[lsb]b", Create_ConvertToShader, 0);
env->AddFunction("ConvertFromShader", "c[Precision]i[Format]s[lsb]b", Create_ConvertFromShader, 0);
env->AddFunction("Shader", "c[Path]s[EntryPoint]s[ShaderModel]s[Param0]s[Param1]s[Param2]s[Param3]s[Param4]s[Param5]s[Param6]s[Param7]s[Param8]s[Clip1]i[Clip2]i[Clip3]i[Clip4]i[Clip5]i[Clip6]i[Clip7]i[Clip8]i[Clip9]i[Output]i[Width]i[Height]i", Create_Shader, 0);
env->AddFunction("ExecuteShader", "c[Clip1]c[Clip2]c[Clip3]c[Clip4]c[Clip5]c[Clip6]c[Clip7]c[Clip8]c[Clip9]c[Clip1Precision]i[Clip2Precision]i[Clip3Precision]i[Clip4Precision]i[Clip5Precision]i[Clip6Precision]i[Clip7Precision]i[Clip8Precision]i[Clip9Precision]i[Precision]i[OutputPrecision]i", Create_ExecuteShader, 0);

void* is_plus = env->FunctionExists("SetFilterMTMode") ? "true" : nullptr;
if (is_plus != nullptr) {
auto env2 = static_cast<IScriptEnvironment2*>(env);
env2->SetFilterMTMode("ConvertToShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ConvertFromShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("Shader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ExecuteShader", MT_MULTI_INSTANCE, true);
}

return "Shader plugin";
}

[Chikuzen]

void* is_plus = env->FunctionExists("SetFilterMTMode") ? "true" : nullptr;
if (is_plus != nullptr) {
auto env2 = static_cast<IScriptEnvironment2*>(env);
env2->SetFilterMTMode("ConvertToShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ConvertFromShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("Shader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ExecuteShader", MT_MULTI_INSTANCE, true);
}

Why do you convert bool to void* there is no need to do it ?


if (env->FunctionExists("SetFilterMTMode")) {
auto env2 = static_cast<IScriptEnvironment2*>(env);
env2->SetFilterMTMode("ConvertToShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ConvertFromShader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("Shader", MT_NICE_FILTER, true);
env2->SetFilterMTMode("ExecuteShader", MT_MULTI_INSTANCE, true);
}

I think this is smart and better.

[MysteryX]

I just copied the code from someone else. Monkey see monkey do :)

I agree it was written in a weird way!

[Reel.Deel]

Is there a place/link which explain the differences and impact between all MT status like, MT_SERIALIZED, MT_NICE_FILTER to eventualy add in my filter the report of what they support.
I need the list of all the avaible status, and what they exactly mean for the filter reporting a such status. Where there is such information ?

I don't know if you've seen this already but read this post by ultim: http://forum.doom9.org/showthread.php?p=1651071#post1651071

[Groucho2004]

I don't know if you've seen this already but read this post by ultim: http://forum.doom9.org/showthread.php?t=168856&page=11#post1651071
I have seen this here and also on avisynth.nl - when you link to Doom9 forum posts, your links always contain a page reference which of course only works when users have not changed their posts/page forum preference.
Every time I click on one of your links I get transported to some random place since I don't use the default.

I suggest you use the "Link" reference, top right of every post.

[Reel.Deel]

I have seen this here and also on avisynth.nl - when you link to Doom9 forum posts, your links always contain a page reference which of course only works when users have not changed their posts/page forum preference.
Every time I click on one of your links I get transported to some random place since I don't use the default.

I suggest you use the "Link" reference, top right of every post.

Thanks for pointing that out, I'll use the suggested link from now.
The links have always worked for me so I never noticed. I'll try to fix the wiki links as I come across them.

[Groucho2004]

Thanks for pointing that out, I'll use the suggested link from now.
The links have always worked for me so I never noticed. I'll try to fix the wiki links as I come across them.
I think it's only when you link to specific posts, not when you link a whole thread.

[LigH]

So for everyone else: reply #204 (http://forum.doom9.org/showthread.php?p=1651071#post1651071)

[Reel.Deel]

I think it's only when you link to specific posts, not when you link a whole thread.

Correct. A while back archive.org had trouble archiving the top right link so I used the alternative link because it worked. I used that style on the wiki just so if it ever gets crawled by archived.org. Just checked and it seems the top-right link also works now.

Sorry to anyone who was directed to a random place. That was not my intent. :o

So for everyone else: reply #204 (http://forum.doom9.org/showthread.php?p=1651071#post1651071)

I fixed the link in #1628.

[jpsdr]

Ok, i think i understand the differences between the 3.
MT_NICE_FILTER : Not possible if you have to use global internal buffer. Personnaly, i'll never malloc/free on each get frame, and don't want to use MT specific features making the filter working only on MT versions. But on something so simple as brigthness/contrast (for exemple), it will work.
MT_MULTI_INSTANCE : You can use global internal buffer, no several getframe from the same instance, but input frames are "random", so works only if, basicaly, the filter needs only the actual frame. I think it's this case for the actual nnedi3.
MT_SERIALIZED : The filter needs the frames to be entered in the correct order, and probably also have buffer. A simple example would be something like an RII filter (like y[n]=0.5*x[n]+0.25*x[n-1]+0.25*y[n-1]). A such filter is not compatible with the others two modes.

Thanks, things are clear now. I think...

[LigH]

I believe even a filter which requires a temporal range of frames can be MT-friendly if the AviSynth(+) core knows about it working on a temporal window and buffering such a range...

[jackoneill]

Personnaly, i'll never malloc/free on each get frame,

It's really not that bad. The VapourSynth plugin with work buffers allocated in the getframe function is about as fast as the Avisynth plugin. See http://forum.doom9.org/showthread.php?p=1600999#post1600999 and some posts below.

[fAy01]

The current installer of avs-plus detects avisynth 2.5/2.6. Is there a possibility to have both 32bit and 64bit working without having to overwrite or uninstall the other?

[LigH]

For 32 bit applications, only one DLL can be registered system-wide as AviSynth frameserver, either the "vanilla" AviSynth DLL or the AviSynth+ DLL.

But it is possible to place one of the DLLs next to the application into the same directory, and if the application loads "the next available avisynth.dll", it will probably look first in its own directory before looking into the Windows system directory. This way it may be possible to exchange the AviSynth version used by a specific application independently of the system-wide AviSynth installation, by installing the application in two directories (preferably outside an UAC protected branch, means: not in "Program files") and copying either DLL to either directory.

For 64 bit applications, there is no reliable 64-bit "vanilla" AviSynth build, anyway.

[Groucho2004]

The current installer of avs-plus detects avisynth 2.5/2.6. Is there a possibility to have both 32bit and 64bit working without having to overwrite or uninstall the other?
Any 32 bit and 64 bit Avisynth versions can live happily together. The 32 bit avisynth.dll/devil.dll are placed in SysWOW64, the 64 bit versions in system32. A client application will (should) automatically load the correct DLL.

However, only Avisynth+ has the option of specifying separate plugin directories which is needed for auto-loading filters.

To answer your question - yes, you can install just 64 bit AVS+ alongside your existing 32 bit Avisynth.

[Groucho2004]

For 32 bit applications, only one DLL can be registered system-wide as AviSynth frameserver, either the "vanilla" AviSynth DLL or the AviSynth+ DLL.
Avisynth.dll does not need registration. A client application can load any avisynth.dll.

For 64 bit applications, there is no reliable 64-bit "vanilla" AviSynth build, anyway.I find AVS+ r1576 and the latest build from pinterf very usable.

[LigH]

I find AVS+ r1576 and the latest build from pinterf very usable.

But that's AviSynth+ (plus), not vanilla/legacy/original AviSynth... how should I call it to make it distinct from the "plus" fork?

A 64-bit AviSynth (without "plus") does exist; but it was mainly known as unstable (I guess many of the programming tricks the 32-bit version survived would crash the 64-bit version, and only few plugins were ported before this project was abandoned).

[Groucho2004]

But that's AviSynth+ (plus), not vanilla/legacy/original AviSynth... how should I call it to make it distinct from the "plus" fork?

A 64-bit AviSynth (without "plus") does exist; but it was mainly known as unstable (I guess many of the programming tricks the 32-bit version survived would crash the 64-bit version, and only few plugins were ported before this project was abandoned).
I know what you meant and I agree with all of the above. :D

I just pointed out that there are a couple of very usable 64 bit builds because your statement "there is no reliable 64-bit "vanilla" AviSynth build, anyway" may be misleading for folks not familiar with vanilla flavour in this context.

[MysteryX]

I posted some time ago about AviSynth+ x64 taking HUGE amounts of memory. The fault is mine. AviSynthShader takes more than twice the memory in x64, trying to figure out why. If I remove that, all the other filters take slightly more memory but perform faster.

From what I tested so far, AviSynthShader may be the only x64 filter that isn't working as expected.

[fAy01]

Any 32 bit and 64 bit Avisynth versions can live happily together. The 32 bit avisynth.dll/devil.dll are placed in SysWOW64, the 64 bit versions in system32. A client application will (should) automatically load the correct DLL.

However, only Avisynth+ has the option of specifying separate plugin directories which is needed for auto-loading filters.

To answer your question - yes, you can install just 64 bit AVS+ alongside your existing 32 bit Avisynth.

https://i.imgur.com/limOBsh.png

avs-plus suggests otherwise :)

[Groucho2004]

https://i.imgur.com/limOBsh.png

avs-plus suggests otherwise :)
Odd. I use this tool (http://forum.doom9.org/showthread.php?t=172124) to install/switch Avisynth versions and I assure you that Avisynth 2.6 and Avisynth+ 64 bit each work perfectly fine:
http://s33.postimg.org/kv0sde2en/Image1.png

[qyot27]

@fAy01:
You do realize that AviSynth+ installs both 32 and 64 bit versions, right? There's no reason whatsoever to use classic AviSynth for 32-bit and only Plus for 64-bit, instead of Plus for both. You can't put both the 32-bit-only classic AviSynth and a 32-bit AviSynth+ in sysWOW64, you have to choose one or the other. It is exactly the same reason you can't put AviSynth 2.5 and AviSynth 2.6 in sysWOW64 at the same time, not that there's some kind of 'incompatibility' involved.

Although if you need to use FFmpeg, you have to use AviSynth+ r1779, r1825, or pinterf's test builds, not r1576. This is because FFmpeg no longer supports the pre-2.6 AviSynth API.

[Groucho2004]

@fAy01:
I just tried the installer and got the same warning dialog. However, I clicked "Next" and selected only the 64 bit version. The original 32 bit version as well as the 64 bit version are working fine.

I agree however with qyot27 - just uninstall the old version and install AVS+ 32 and 64 bit.

[MysteryX]

As several mentioned, you can only have one 32-bit version and one 64-bit version of AviSynth.dll, but they can be different, as one is in Windows\System32 and the other is in Windows\Syswow64. You can manually place the AviSynth DLL version you like into each of these folders.

In addition to that, you can use a separate version per application by placing another AviSynth.dll version into the same folder as the EXE and that version will be used instead.

Knowing this is especially useful for testing and comparing various versions.

[pinterf]

I posted some time ago about AviSynth+ x64 taking HUGE amounts of memory. The fault is mine. AviSynthShader takes more than twice the memory in x64, trying to figure out why. If I remove that, all the other filters take slightly more memory but perform faster.

From what I tested so far, AviSynthShader may be the only x64 filter that isn't working as expected.
Pointers are double in size in x64. Although there are arrays and structs with pointers in your code but it does not explain the difference. Perhaps DirectX?

[MysteryX]

Pointers are double in size in x64. Although there are arrays and structs with pointers in your code but it does not explain the difference. Perhaps DirectX?
Yes it's most likely related to a difference in the way DX9 manages its texture memory buffers in x64. The issue is being discussed here. (http://www.gamedev.net/topic/678905-dx9-doubling-memory-usage-in-x64/)

[tormento]

What about creating a installer with latest versions from pinterf? ;)

[fAy01]

What about creating a installer with latest versions from pinterf? ;)

he's busy porting other plugins to x64.

[pinterf]

he's busy porting other plugins to x64.
And I have no experience in installers.

[pinterf]

Is it intentional that ColorbarsHD is 1288x720 and not 1280x720?
The avisynth doc also mentions 1288.

[jpsdr]

Is it possible for a filter to set its MT mode on the constructor instead of inside AvisynthPluginInit3 ?
It's, for example, if a filter is MT_NICE_FILTER if parameter x=0, and MT_MULTI_INSTANCE if parameter x=1.

[pinterf]

New maintenance release for 32 bit/64 bit Avisynth+, also with XP versions.

Avisynth+ MT r1858 (https://github.com/pinterf/AviSynthPlus/releases/tag/r1858-MT-pfmod)

Changes from r1849:

r1858 MT-pfmod (20160531)

- fix: RGB resizers shift horizontally to the opposite direction when src_left param is used (reported by MysteryX)
- prevent fragmentation vfb buffer list for small sized vfbs
- fix: x64 compatible type in acmDriverEnum call in VD_Audio

The r1849 build was downloaded by 522 times from github in the last six weeks.
I hope the previous authors' enormous amount of time has not been wasted.

[Chikuzen]

Is it intentional that ColorbarsHD is 1288x720 and not 1280x720?
The avisynth doc also mentions 1288.

no.
ARIB STD-B28 says it should be 16:9 (and 75% colorbars should be 4:3).
The difference with the standard has occured because that's calculating the location of each colors with integer arithmatic.
I don't know why original author(IanB?) didn't calculate with floating point.

[Groucho2004]

@pinterf
Thanks for the new build.

@all
I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

[Reel.Deel]

@pinterf
Thanks!

What about creating a installer with latest versions from pinterf? ;)

Just yesterday I added installers for r1841 and r1847 to the wiki (http://avisynth.nl/index.php/AviSynth%2B#Downloads) (courtesy of stax76). Whenever he updates it I'll update the wiki also.


I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

Thanks, I'll add a link to on the wiki.

[qyot27]

Sidenote: similar to what happened a couple years ago with VS 2013 builds, Wine 1.9.x (i.e. the current dev branch) cannot use binaries built with VS 2015 yet. Even if you do have all the correct redist dlls available.

[burfadel]

@pinterf
Thanks for the new build.

@all
I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)

The installer is 21.6 MB versus one for 1847 which is 4.02 MB. Also, once installed it didn't even seem to work. I use Staxrip, and Staxrip came up with an app error saying Avisynth wasn't installed. When I reinstalled 1847 and used the pinterf replacement archive files for 1858 it works fine!

[real.finder]

New maintenance release for 32 bit/64 bit Avisynth+, also with XP versions.

Avisynth+ MT r1858 (https://github.com/pinterf/AviSynthPlus/releases/tag/r1858-MT-pfmod)

Changes from r1849:

r1858 MT-pfmod (20160531)

- fix: RGB resizers shift horizontally to the opposite direction when src_left param is used (reported by MysteryX)
- prevent fragmentation vfb buffer list for small sized vfbs
- fix: x64 compatible type in acmDriverEnum call in VD_Audio

The r1849 build was downloaded by 522 times from github in the last six weeks.
I hope the previous authors' enormous amount of time has not been wasted.

thanks, and do you include 2.6.1 alpha 1 changes?

[Groucho2004]

I use Staxrip, and Staxrip came up with an app error saying Avisynth wasn't installed.
I don't know how staxrip determines if Avisynth is installed. It worked fine for me (32 and 64 bit).

[Groucho2004]

The installer is 21.6 MB versus one for 1847 which is 4.02 MB.
The staxrip AVS+ installer is heavily modified, does not have the MS redistributables and is 64 bit only.
I used the original AVS+ installer script and just removed the FilterSDK and Docs.

[pinterf]

thanks, and do you include 2.6.1 alpha 1 changes?
Not yet.

[stax76]

@burfadel

Groucho's installer is fine, StaxRip only reports wrong version, when you press F12 you can enter what version it actually is.

https://i.imgur.com/faqUH92.png

[Reel.Deel]

The staxrip AVS+ installer is heavily modified, does not have the MS redistributables and is 64 bit only.
I used the original AVS+ installer script and just removed the FilterSDK and Docs.

Thanks for the information. I'll remove stax76's installers from the wiki. I didn't know it was 64-bit only.

Wishful thinking: it would be nice to have an 'official' installer along side the binaries on GitHub.

[Groucho2004]

Wishful thinking: it would be nice to have an 'official' installer along side the binaries on GitHub.Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.

[MysteryX]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).
This Inno Setup project should definitely be in GitHub.

[burfadel]

@burfadel

Groucho's installer is fine, StaxRip only reports wrong version, when you press F12 you can enter what version it actually is.

https://i.imgur.com/faqUH92.png

Ah ok, for some reason for me it came up as not installed when using his installer, even though it was and the files were in place.

The benefit of having the redists combined in the installer is two sided. Of course it makes it easier for people who don't already have VS2015 runtimes installed, but it does take up most of the space of the installer since the redists are in their original state. Also, the redists included are 14.0.23026, the latest 2015 runtimes available are 14.0.24018.

There are many fallacies of how the redists are handled in general, although it's not quite as bad as it used to be.

[MysteryX]

For setup, I think it's best to only download VS2015 if it's needed. It can easily be configured to download and install.

Modular InnoSetup Dependency Installer (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

[burfadel]

For setup, I think it's best to only download VS2015 if it's needed. It can easily be configured to download and install.

Modular InnoSetup Dependency Installer (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

That is a much better concept.

[Groucho2004]

The benefit of having the redists combined in the installer is two sided. Of course it makes it easier for people who don't already have VS2015 runtimes installed, but it does take up most of the space of the installer since the redists are in their original state. Also, the redists included are 14.0.23026, the latest 2015 runtimes available are 14.0.24018.
I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
Anyway, the best thing an Avisynth user (or any user for that matter) can do is to use either ricktendo's or your AIO installer but knowledge about these and their benefits is not widespread unfortunately.

[pinterf]

I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
I have just compiled the plugins for the very same reason, because unfortunately they are mixed. At the moment there are troubles with DirectShowSource, have to look into it. The header file in 2.6.1 alpha 1 was refreshed with build hints.

[Groucho2004]

At the moment there are troubles with DirectShowSource, have to look into it.
Do you have the DS SDK installed?

[MysteryX]

I agree. Additionally, the plugins included need the VS2012 runtimes. I'll make another build without them.
Anyway, the best thing an Avisynth user (or any user for that matter) can do is use either ricktendo's or your AIO installer but knowledge about these and their benefits is not widespread unfortunately.
With the link I posted above, you can easily make the setup install VS2012, VS2015 and whatever other dependency is needed, without bundling it into the setup file.

[Groucho2004]

With the link I posted above, you can easily make the setup install VS2012, VS2015 and whatever other dependency is needed, without bundling it into the setup file.
Maybe if there is ever a release of AVS+. For now, a note on the final installer dialog should suffice. This is still in Alpha stage.

[stax76]

The VapourSynth installer handles the VC++ runtime issue smarter, it's not included but downloaded if necessary.

https://github.com/vapoursynth/vapoursynth/tree/master/installer

[pinterf]

Do you have the DS SDK installed?
Not the right version. Only DirectX (February 2010). Downloading August, 2009.

[Groucho2004]

I made a "lean" installer for this new build, no docs/Filter SDK. It does however include the latest 2015 redistributables.
(AviSynth+ r1858.7z) (https://www.dropbox.com/sh/6kb3723po5oqd4b/AADbP8gIJ3YrHVoLU3joqJDma?dl=0)
I made a new r1858 build without the 2015 runtimes.

[Groucho2004]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.
Added build environment without VC runtimes -> DL (https://www.dropbox.com/s/2i7ti3rbdz6zrb9/BuildAVSPLUS_no_redist.7z?dl=0).

[MysteryX]

Maybe if there is ever a release of AVS+. For now, a note on the final installer dialog should suffice. This is still in Alpha stage.
Yet it is very easy to add. There's no reason to not implement it now. For many, AVS+ in its current form is the best AVS so far. Especially for SVP users. They might appreciate to be able to bundle an installer that takes care of dependencies properly into the SVP update system.

However there were a few things that I needed to tweak to implement it myself, such as removing the German language option. One option is to just copy the code from my installer here (https://github.com/mysteryx93/NaturalGroundingPlayer/tree/master/Setup)

Edit: I see that in my folder, I only have the code for VC2010. The official project does have support for VC2010, 2012, 2013 and 2015. (http://www.codeproject.com/Articles/20868/NET-Framework-Installer-for-InnoSetup)

[ryrynz]

For many, AVS+ in its current form is the best AVS so far.

Without a doubt. Thank's to pinterf's efforts we have things in pretty good shape now.

[pinterf]

Successfully built DirectShowSource with VS2015.
Unlike avisynth.dll, with Platform Toolset set to v140 it runs on XP.
No need for v140_xp toolset, nor the extra /Zc:threadSafeInit- parameter. Why?

[Groucho2004]

No need for v140_xp toolset, nor the extra /Zc:threadSafeInit- parameter. Why?
My wild guess would be that only certain Win32 APIs/functions require these switches in order for the code to run on XP. For others, the object code created by the compiler would be the same with or without the switches.

[Reel.Deel]

Building the installer is very easy and takes one minute. If pinterf is willing to supply an installer - I have uploaded my installer build environment here (https://www.dropbox.com/s/2lpsfuv3ggdo0lu/BuildAVSPLUS.7z?dl=0).


Install InnoSetup (http://www.jrsoftware.org/isdl.php) (innosetup-5.5.9-unicode.exe)
Update the binaries in "Bin_x86" and "Bin_x64"
Open "avs_plus.iss" with InnoSetup
Set "Version" (first line) to the correct revision
Build (Ctrl-F9)
Done.

Wow, that was super easy! :cool:

---

@qyot27
I know a while back you were working on the documentation. I'm not sure if it was finished or not but from what I've seen it looks really good. How would I go about helping out?

https://web.archive.org/web/20160601135459/http://s33.postimg.org/d7b8r6n6z/avsplus_doc.jpg (https://web.archive.org/web/20160601135441/http://s33.postimg.org/u7u4zv08d/avsplus_doc.png)

[qyot27]

@qyot27
I know a while back you were working on the documentation. I'm not sure if it was finished or not but from what I've seen it looks really good. How would I go about helping out?

https://web.archive.org/web/20160601135459/http://s33.postimg.org/d7b8r6n6z/avsplus_doc.jpg (https://web.archive.org/web/20160601135441/http://s33.postimg.org/u7u4zv08d/avsplus_doc.png)
Yes, the RST/Sphinx conversion was finished, at least to the point that the documentation was on par with the docs from classic AviSynth at the time (2.6 RC1, and RC2-Final if the rc2integrate branch is considered (https://github.com/AviSynth/AviSynthPlus/pull/59/commits)).

The rc2integrate branch also adds a note into README.md about how to build the Sphinx documentation.

Actually editing the docs mostly only requires basic text editing, since the RST syntax is meant to be human-readable. Updating the docs against classic AviSynth's changes is pretty trivial, just do an dump of the page with lynx before and after the commit that changes a particular file(s) (so you don't have to deal with all the HTML), compare the changes in something like Meld, and adjust the corresponding *.rst files in AviSynth+'s docs to match the text content, adjusting for RST or Sphinx-specific syntax.

EDIT: After looking at the commits since 2.6 Final, there were no docs changes, so the docs in rc2integrate are still as up-to-date as classic's docs. Also, generally, some of those 2.6.1 changes in classic's CVS make me want to scream in agony.

[bilditup1]

The latest mt_modes list (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) says:

#note1: Can't use mode 1 or 2 on any filters if encoding 1080i files(480i works perfectly fine).

The alternative mt_modes list (https://gist.github.com/tp7/8899021) by tp7 further says:

#As far as I know, the only workaround seems to be running a deinterlacer right after the video source and running it as "MT_SERIALIZED",
#than running any desired filters after. Filters after the deinterlacer, seem to be able use any mode.

So:

Is this information still accurate? I am trying to use the 32-bit version of pinterf's latest mod with the following plugins:

DGDecodeIM (beta 50) (http://rationalqm.us/mine.html)
NNEDI3 (jpsdr 30/05/16) (http://forum.doom9.org/showthread.php?p=1662264#post1662264)
RgTools (tp7) (http://forum.doom9.org/showthread.php?p=1655989#post1655989)
MaskTool2 (tp7) (http://forum.doom9.org/showthread.php?p=1655989#post1655989)
MvTools2-pfmod (29/04/16) (http://forum.doom9.org/showthread.php?p=1762741#post1762741)

with A.SONY/real.finder's QTGMC mod (http://forum.doom9.org/showpost.php?p=1732845&postcount=2041).
What behavior should we expect with a 1080i source, if modes 1 or 2 are used normally? A crash? Artifacts? Very slow processing?
Since QTGMC uses several filters, which of them should be set to MT_SERIALIZED in order to avoid problems? NNEDI3 is one, I suppose, but others are used as well, right?
Specifically I'm curious about the filters used with the Medium and Fast presets of QTGMC.


Separately:
Is this note about ColorMatrix still accurate?
#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?
If so, is there any alternative for doing colorspace conversions that works with AVS+ MT?


Without making any modifications to the MT modes file, on a 4770K@4.5Ghz, I seem to be getting 5-6.5 fps with MT enabled on a 1080i source being downscaled to 360p. By contrast, mainline AVS 2.6.1 with avs_tp (and ColorMatrix enabled) yields 6-7.5 fps, and AVS MT yields 12 fps but always crashes about 50-66% of the way through (again with ColorMatrix enabled). Is this within expected norms?

Also, this line in the MT modes files is incorrect:
SetFilterMTMode("DGDecIM", MT_SERIALIZED) #DGDecIM beta 50 2015/10/10
The correct line with the proper function name is:
SetFilterMTMode("DGSourceIM", MT_SERIALIZED) #DGDecIM beta 50 2015/10/10

[Reel.Deel]

@bilditup1

tp7's list is just an older revision of the latest MTModes list. He put it up on GitHub a while back as a backup because the original list was tampered with. Unfortunately it hasn't been updated since in over a year.

Regarding the notes, I'm not sure who wrote that or how or when it was tested. It was probably before this issue was fixed: https://github.com/AviSynth/AviSynthPlus/issues/37
It's probably best to test and report back if you find any problems.

All filters used by QTGMC work with MT mode 1 or 2 and they're already included in the MT Modes list (except for some filters from MVTools). I've successfully used QTGMC with:


SetFilterMTMode("WhateverSource" 3)
SetFilterMTMode("DEFAULT_MT_MODE", 2)

WhateverSource("somevideo.file")
QTGMC()

Prefetch(x)

or


Import("MTModes.avsi")
SetFilterMTMode("WhateverSource" 3)
SetFilterMTMode("DEFAULT_MT_MODE", 2)

WhateverSource("somevideo.file")
QTGMC()

Prefetch(x)

I do not use ColorMatrix so I don't if it crashes with MT or not. I use dither tools to change colorimetry.

Thanks for the DGSourceIM report. I'll correct it right now.

[bilditup1]

@bilditup1

tp7's list is just an older revision of the latest MTModes list. He put it up on GitHub a while back as a backup because the original list was tampered with. Unfortunately it hasn't been updated since in over a year.

Regarding the notes, I'm not sure who wrote that or how or when it was tested. It was probably before this issue was fixed: https://github.com/AviSynth/AviSynthPlus/issues/37
It's probably best to test and report back if you find any problems.


Thanks for all that; will do. I am testing with QTGMC and without ColorMatrix now and will do another one with CM later.


All filters used by QTGMC work with MT mode 1 or 2 and they're already included in the MT Modes list (except for some filters from MVTools). I've successfully used QTGMC with:


OK. I am using QTGMC atm without issue. Let's see if it holds. Hopefully we'll be able to remove these disclaimers and prevent this kind of confusion :)


I do not use ColorMatrix so I don't if it crashes with MT or not. I use dither tools to change colorimetry.


Off-topic I know, but how does this work? I found this snippet at the wiki:


Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720)
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)


For HD to SD conversion, should I just get rid of the resize, and switch the matrix parameters in the third and seventh lines? I don't understand what I'm looking at, specifically the SelectEvery() lines.

Thanks for the DGSourceIM report. I'll correct it right now.

OK great! No problem.

[Reel.Deel]

OK. I am using QTGMC atm without issue. Let's see if it holds. Hopefully we'll be able to remove these disclaimers and prevent this kind of confusion :)

Indeed, hopefully more people will help out in testing and validating filters. This list was meant to be community-driven but so far only a few people have actually contributed. :(
Off-topic I know, but how does this work? I found this snippet at the wiki:


Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720)
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y", lsb_in=true)
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)


For HD to SD conversion, should I just get rid of the resize, and switch the matrix parameters in the third and seventh lines? I don't understand what I'm looking at, specifically the SelectEvery() lines.


That script is on the wiki upscales SD to HD content, you want to downscale so use this instead:


Dither_convert_8_to_16 ()
Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions
Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true) # convert to RGB using the 709 color matrix commonly used in HD content
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12") # convert to YUV using the 601 color matrix commonly used in SD content

First the YUV clip is scaled from HD to SD. Then it gets converted to RGB and finally back to YUV with the appropriate matrix for SD. The SelectEvery() is used to process 48-bit RGB clips, from the docs:
48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
I added csp="YV24" to Dither_resize16 to avoid any unnecessary resizing on the chroma planes. Finally, the output will be 8-bit YV12 if you want 16-bit just set lsb=true, if you want another colorspace just change the output parameter.

[bilditup1]

Indeed, hopefully more people will help out in testing and validating filters. This list was meant to be community-driven but so far only a few people have actually contributed. :(


Yeah they must not have if that's stayed in there for two years. That's rough. Whelp, I'll be sure to report anything I find personally, at least :)


That script is on the wiki upscales SD to HD content, you want to downscale so use this instead [...]


Thanks for this, quite helpful. I know I'm really hijacking the thread here, but have a couple more questions.

Dither_resize16 (640, 480, csp="YV24") # change to the desired dimensions

So it is best to do the resize now, with Dither's resize, as opposed to just putting a Spline36Resize() at the end?

Dither_convert_yuv_to_rgb (matrix="709", output="rgb48y", lsb_in=true) # convert to RGB using the 709 color matrix commonly used in HD content
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="601", lsb=false, mode=0, output="YV12") # convert to YUV using the 601 color matrix commonly used in SD content
OK so basically, you just switched the matrix parameters between the first and last lines here. Cool.
The SelectEvery() is used to process 48-bit RGB clips, from the docs:
48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
But then I'm wondering why we're using 48-bit RGB - I don't really understand the advantages or necessity either way. Is this because of the Dither_convert_8_to_16 () before?

[Reel.Deel]

Yes, the RST/Sphinx conversion was finished, at least to the point that the documentation was on par with the docs from classic AviSynth at the time (2.6 RC1, and RC2-Final if the rc2integrate branch is considered (https://github.com/AviSynth/AviSynthPlus/pull/59/commits)).

The rc2integrate branch also adds a note into README.md about how to build the Sphinx documentation.

Actually editing the docs mostly only requires basic text editing, since the RST syntax is meant to be human-readable. Updating the docs against classic AviSynth's changes is pretty trivial, just do an dump of the page with lynx before and after the commit that changes a particular file(s) (so you don't have to deal with all the HTML), compare the changes in something like Meld, and adjust the corresponding *.rst files in AviSynth+'s docs to match the text content, adjusting for RST or Sphinx-specific syntax.

EDIT: After looking at the commits since 2.6 Final, there were no docs changes, so the docs in rc2integrate are still as up-to-date as classic's docs. Also, generally, some of those 2.6.1 changes in classic's CVS make me want to scream in agony.

Thanks for the information. Hopefully it won't be too hard.

I would like too add some updates from the wiki, mainly the internal filters which raffriff42 has worked on (sadly the official documentation does not include these changes, see here (http://forum.doom9.org/showthread.php?p=1754316#post1754316)). Also add a few things from the AviSynth+ wiki page, and maybe start documenting MT.

[bilditup1]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

[MysteryX]

Is there any alternative for doing colorspace conversions that works with AVS+ MT?
The problem with ColorMatrix is that it can cause banding due to rounding errors as it processes with integers. Processing with 16-bit-depth avoids this problem.

In addition to DitherTools, you can try AviSynthShader. You can convert color matrix and resize your image through the GPU. Might be faster than DitherTools, not sure.

[Reel.Deel]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity. Attached is a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

Can share attachments elsewhere? Sometimes it takes a while to get approved.

Regarding your other questions, if you post them in appropriate thread (http://forum.doom9.org/showthread.php?t=153589) I'll gladly help where I can.

[bilditup1]

The problem with ColorMatrix is that it can cause banding due to rounding errors as it processes with integers. Processing with 16-bit-depth avoids this problem.

In addition to DitherTools, you can try AviSynthShader. You can convert color matrix and resize your image through the GPU. Might be faster than DitherTools, not sure.

I didn't know that ColorMatrix was basically obsolete, will keep that mind. Thanks for the info.

I'm not sure who is in charge of the AviSynth wiki, but maybe this can be pointed out somewhere? Like maybe here (http://avisynth.nl/index.php/External_filters#Chroma_correction), where neither DitherTools nor AviSynthShader are mentioned at all?

ED: I just realized that anyone can sign up there, and just did. But I don't think I'm really qualified to begin mucking around there just yet.

[bilditup1]

Can share attachments elsewhere? Sometimes it takes a while to get approved.
Hmph, I hadn't noticed. I've uploaded them to mega.nz and placed the link in the original post above. Here it is again. (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM)


Regarding your other questions, if you post them in appropriate thread (http://forum.doom9.org/showthread.php?t=153589) I'll gladly help where I can.

Aight. But I think this:
Processing with 16-bit-depth avoids this problem.
basically answers one of them already. I'll ask there too though, as I can't be the only one curious about this.

[bilditup1]

Here it is again. (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM)

Balls, I never modified this line to what it should have properly been:
SetFilterMTMode("WhateverSource", 3)
The MT mode for my source filter was setup properly in the mt_modes file I imported at the beginning, so presumably this line just did nothing. Still...sloppy of me, eh

[qyot27]

Thanks for the information. Hopefully it won't be too hard.

I would like too add some updates from the wiki, mainly the internal filters which raffriff42 has worked on (sadly the official documentation does not include these changes, see here (http://forum.doom9.org/showthread.php?p=1754316#post1754316)). Also add a few things from the AviSynth+ wiki page, and maybe start documenting MT.
It made it a lot easier for me to proof the changes between old (HTML) and new (Sphinx) versions by using the Tile View extension in Firefox, so I could see both side-by-side instead of needing to switch between tabs, with Notepad2 (or Leafpad, since I was under Linux while doing this) off to the side to edit the actual RST files.

It's really as simple as 'make html' in the distrib/docs/english directory, so long as you've installed Python and Sphinx. Sphinx will tell you if there are syntax errors in the files, and if the built HTML version is open in your browser, you can see the errors and work them down until it complies. And it'll also only rebuild the files that have been touched, rather than needing to rebuild the entire doc tree.

[bilditup1]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

I ran this again, but this time using MeGUI and encoding to x264. The first time, MeGUI appears to have totally crashed. The second time, it completed without issue, at 10.17fps. The latter is pretty good. I will continue doing tests and reporting back, especially with respect to how well 1080i works and regarding matrix operations.

[pinterf]

Using AVSMeter 2.2.8 with r1858, it appears to work most of the way through...and then just sort of hangs with zero CPU activity.

Click here (https://mega.nz/#!jIQUjTbT!mcKmFFu61QoRJi71GtdOPNxNVscc7bzFKSAJzwTo_pM) for a screenshot of where it stopped and the script I used. Source is still 1080i60 MPEG2, OS is Win10x64.

What happens when you trim the video right after the source filter and process only around the part when the freeze occurs. If the position of the freeze also moves back, the problem is source dependent. Maybe the problem is not with the source itself, but filters can behave content dependent e.g. at a scene change.

[bilditup1]

What happens when you trim the video right after the source filter and process only around the part when the freeze occurs.

In other words, everything after frame #34406, per the screenshot?

If the position of the freeze also moves back, the problem is source dependent.

Not sure what this means, sorry?

Maybe the problem is not with the source itself, but filters can behave content dependent e.g. at a scene change

OK, so that could be a problem with this artificial test of mine, where I'm taking 1,000 frames out of every 5,000, to avoid having to do a full encode that I don't even need? That should cause pretty abrupt scene changes, in theory.

[pinterf]

In other words, everything after frame #34406, per the screenshot?


Some month ago I fixed a problem when the memory consumption in avisynth suddenly increased after the 33000th frame, then at around 39000th, etc.. When I trimmed the source to begin at the 32000th frame, the same thing happened 32000 frames earlier, at the 1000th, 7000th, etc. frames. The problem was source dependent. And it turned out that there had been heavy camera shake at that problematic position. One of the filters detected a new scene (too much difference between neighbouring frames) and other parts of that filter were involved in processing and caused memory leak.

Such a basic script must not cause freeze should it be artificial or not.

[Reel.Deel]

A while back NightSprinter reportred this problem with crt_display (http://forum.doom9.org/showthread.php?t=170732) while using MT.

This is odd, running a Core i7 920 (4 cores, 8 threads) with everything done as posted on the tutorial. However, when I enable prefetch, I get an error along the lines of "I don't know what 'zb' means". I'm using the latest AVS+ installer from the wiki page, and the filter script chain I'm using is the CRT simulation filter that's on this forum as well. I'm including the script in .txt format

I recently tried with this script and get a similar error "I don't know what 'z3' means". Disable MT and the script works just fine. :confused:

Import("MTModes.avsi")
Import("crt_display.avsi")

SetFilterMTMode("DEFAULT_MT_MODE", 2)

ColorBars()
Trim(0,500)

ar = 10.0 / 11.0
crt_display (2*ar, 2, ppp=1*ar, blurh=2.0)

Prefetch(4)

[jpsdr]

Question about the multi-threading parts.
In case filter is MT_NICE, or MT_MULTI_INSTANCE. Especialy for this last case, are the multiple instances of the filter real different instances, or should i worry about eventualy copy constructor issues ?

[pinterf]

Strange.

O.K. (Default MT = 3 + Eval + Function Call)
SetFilterMTMode("DEFAULT_MT_MODE", 3)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}


Fail, (Default MT = 2 + Eval + Function call)
# I dont' know what 'r' means
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}


O.K. (Default MT = 2 + NO Eval + Function call)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
#Eval("Interleave (r, g, b)")
Interleave (r, g, b) # ok
}


O.K (Default MT = 2 + Eval + no function call)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

#test()

r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")

Prefetch(1)

[MysteryX]

Question about the multi-threading parts.
In case filter is MT_NICE, or MT_MULTI_INSTANCE. Especialy for this last case, are the multiple instances of the filter real different instances, or should i worry about eventualy copy constructor issues ?
With MT_MULTI_INSTANCE, they are completely separate instances. The only way the various instances can communicate with each other is through global variables.

[bilditup1]

I will continue doing tests and reporting back, especially with respect to how well 1080i works and regarding matrix operations.

Tested 1080i60 with downscaling to 360p30 and matrix conversion from 709 to 601, and getting some weird results. Download screenshots and scripts here (https://mega.nz/#!GAgBgQIJ!NLBwb567WQyfi3w8r6jPymNqzfEYmWrZiTmIdDhPMbM). I think the file naming/numbering is intuitive and you guys should be able to figure it out.

Four passes:


just straight downscaling (Spline36) and deinterlacing, no matrix operations. This yielded 10.17fps (including x264 compression).
using ColorMatrix for 709->601. This was done in almost real-time, yielding 10.06fps.
using Dither for 709->601 and downscaling (still using Spline36 kernel). Slowed things down significantly, only got 6.32fps, which I guess is to be expected.
using AviSynthShader for 709->601 and downscaling (using Bicubic kernel). Slowed things down even more, only got 5.85fps - again, to be expected with a lowly HD4600 - and MeGUI crashed at 99.83% (there's a screenshot of this in the zip).
I had intended to do comparisons with this last also, after muxing the 264. However I had neglected to delete the original encoding job from the MeGUI queue, and as a result the original file got destroyed once the queue commenced - instead of the muxing job, it tried to do the encode again, since when MeGUI itself totally crashes, the job that causes the crash is never marked as done, and shows up as 'waiting' in the queue - and I didn't want to wait for the encode to finish before I posted here. In any case, it's not really relevant to me right now, so I left it be.

A few observations:

CPU, when I bothered to check, was running at at least 60%.
I had to disable MT for the comparison clips (using FFMS2), otherwise the overlays with the frame-numbers and such got garbled and destroyed.
1080i in and of itself does not appear to be an issue.
But, from these clips it looks like ColorMatrix might in fact still be causing problems?
In frame 0, the scrolling text is corrupted on the bottom right, only in the ColorMatrix one (not in the others or the source).
At frame 39287, there are big green horizontal bars across the upper middle and bottom of the frame.
Both of these only show up in an actual encode, not in the mere preview (using AvsPmod, for example).
There might be other problems, but they were too quick to catch.

Dither has some weirdness, too. The first two frames look like some interlaced abortion of some kind. But, again, this only happens in an actual encode.
All of them had trouble at 29300...but this turned out to be in the source. I've included it because it's a pretty weird artifact and I'm curious as to what could cause it.
Due to the nature of these problems - crashing/not crashing with no modifications to the avs, problems showing up in the encode but not the preview, &c - I'm beginning to suspect that perhaps my overclock is too aggressive. So I think you may need to take all of these with a grain of salt. I'll be fiddling with that and trying again once I get back in town.

[Groucho2004]

Tested 1080i60 with downscaling to 360p30 and matrix conversion from 709 to 601, and getting some weird results. Download screenshots and scripts here (https://mega.nz/#!GAgBgQIJ!NLBwb567WQyfi3w8r6jPymNqzfEYmWrZiTmIdDhPMbM). I think the file naming/numbering is intuitive and you guys should be able to figure it out.

Four passes:


just straight downscaling (Spline36) and deinterlacing, no matrix operations. This yielded 10.17fps (including x264 compression).
using ColorMatrix for 709->601. This was done in almost real-time, yielding 10.06fps.
using Dither for 709->601 and downscaling (still using Spline36 kernel). Slowed things down significantly, only got 6.32fps, which I guess is to be expected.
using AviSynthShader for 709->601 and downscaling (using Bicubic kernel). Slowed things down even more, only got 5.85fps - again, to be expected with a lowly HD4600 - and MeGUI crashed at 99.83% (there's a screenshot of this in the zip).
I had intended to do comparisons with this last also, after muxing the 264. However I had neglected to delete the original encoding job from the MeGUI queue, and as a result the original file got destroyed once the queue commenced - instead of the muxing job, it tried to do the encode again, since when MeGUI itself totally crashes, the job that causes the crash is never marked as done, and shows up as 'waiting' in the queue - and I didn't want to wait for the encode to finish before I posted here. In any case, it's not really relevant to me right now, so I left it be.

A few observations:

CPU, when I bothered to check, was running at at least 60%.
I had to disable MT for the comparison clips (using FFMS2), otherwise the overlays with the frame-numbers and such got garbled and destroyed.
1080i in and of itself does not appear to be an issue.
But, from these clips it looks like ColorMatrix might in fact still be causing problems?
In frame 0, the scrolling text is corrupted on the bottom right, only in the ColorMatrix one (not in the others or the source).
At frame 39287, there are big green horizontal bars across the upper middle and bottom of the frame.
Both of these only show up in an actual encode, not in the mere preview (using AvsPmod, for example).
There might be other problems, but they were too quick to catch.

Dither has some weirdness, too. The first two frames look like some interlaced abortion of some kind. But, again, this only happens in an actual encode.
All of them had trouble at 29300...but this turned out to be in the source. I've included it because it's a pretty weird artifact and I'm curious as to what could cause it.
Due to the nature of these problems - crashing/not crashing with no modifications to the avs, problems showing up in the encode but not the preview, &c - I'm beginning to suspect that perhaps my overclock is too aggressive. So I think you may need to take all of these with a grain of salt. I'll be fiddling with that and trying again once I get back in town.

You are posting in the wrong thread. None of this is related to AVS+.

[bilditup1]

You are posting in the wrong thread. None of this is related to AVS+.

It most certainly is. The latest MT_modes list still has warnings about processing 1080i and about using the ColorMatrix plugin. These warnings have been there for years and nobody has bothered to verify them in ages. See the discussion starting here (https://www.doom9.org/showpost.php?p=1769237&postcount=1688).

[Groucho2004]

It most certainly is.
I'm beginning to suspect that perhaps my overclock is too aggressive.
Even if it were, do really think anyone will bother to look at your results after the above statement?

[bilditup1]

Even if it were, do really think anyone will bother to look at your results after the above statement?

I have only vague suspicions though. If this is a stability issue I have not seen other symptoms. BOINC runs all the time without errors, programs open the way they should, no BSoDs or random restarts. I included that disclaimer for completion's sake.

[ryrynz]

You are posting in the wrong thread. None of this is related to AVS+.
Did you really need to quote that entire unrelated post? Lol.


I have only vague suspicions though. If this is a stability issue I have not seen other symptoms. BOINC runs all the time without errors, programs open the way they should, no BSoDs or random restarts. I included that disclaimer for completion's sake.

That doesn't matter.. Instability can often go unseen. Go back to defaults and retest.

[bilditup1]

That doesn't matter.. Instability can often go unseen. Go back to defaults and retest.

...yes...hence my suspicions...I was just saying that there wasn't a traditional smoking gun just yet. I will in fact be retesting a few times and at stock, plus hopefully on another machine entirely if I can manage it.
I will also split off the rest of this discussion to its own thread. Not here to make trouble - just trying to make a positive contribution.

[MysteryX]

Ever since I added Dither Tools in this script, sometimes it works and sometimes it crashes the encoder or MPC-HC or freezes VirtualDub.

I tried running the same under AviSynth 2.6 MT and opened it 10-15 times without any crash or freeze. I'm guessing the most likely cause is a difference in MT modes for one of the DitherTools filters.


P="Encoder\"
Import(P+"AviSynthMT.avsi")
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"Dither.dll")
Import(P+"Dither.avsi")
LoadPlugin(P+"KNLMeansCL.dll")
LoadPlugin(P+"svpflow1.dll")
LoadPlugin(P+"svpflow2.dll")
Import(P+"InterFrame2.avsi")
Import(P+"ResizeX.avsi")
LoadPlugin(P+"Shaders\Shader.dll")
Import(P+"Shaders\Shader.avsi")

file="VCD.mpg"
LWLibavVideoSource(file, cache=False, threads=1)
AudioDub(LWLibavAudioSource(file, cache=False))
Crop(0, 0, -8, -0)
Dither_convert_8_to_16()
Dither_resize16(Width, Height/2, kernel="Spline36", csp="YV24")
KNLMeansCL(D=1, A=2, h=2.1, cmode=true, device_type="GPU", device_id=0, lsb_inout=true)
SuperResXBR(5, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, MatrixIn="601", lsb_in=true, lsb_out=true)
Dither_resize16(Width, Height/2, kernel="Spline36", csp="YV12", invks=true)
DitherPost()
InterFrame(Cores=8, Tuning="Smooth", NewNum=60, NewDen=1, GPU=true)
SuperResXBR(3, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, fWidth=1012, fHeight=778, fKernel="Bicubic", fB=0, fC=.75)
ResizeX(1004, 768, 0, 5, -8, -5)
Prefetch(8)


By the way, LWLibavVideoSource runs with MT mode 3 which means there is a single instance? In that case, I don't need to specify 1 thread and I should just let it manage its own threats, correct?

[MysteryX]

I have set all DitherTools functions to MT mode 2. The first time I opened it, it freezed again, but afterwards I couldn't get it to freeze again. Dither Tools will require more testing for its MT compatibility/stability level.

By the way, at the top of the MT modes list, there should be a link to where the list actually came from and how to update it. When I want to refer changes about it, I don't even remember where it came from and who wrote it.

[pinterf]

This "I dont' know what 'r' means" is not an easy bug hunt.
At least now I know how to reproduce it.

All these conditions must be me met:

MT is on (Prefetch(x))
Eval is set to MT_MULTI_INSTANCE
either by SetFilterMTMode("Eval", MT_MULTI_INSTANCE)
or
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
Eval is within a function
Within Eval the last filter is NonCacheableVideoFilter
(responds != 0 to SetCacheHints(CACHE_DONT_CACHE_ME, 0))
Such filters: Trim, DuplicateFrame, Interleave, etc.
The last filter in Eval in the function is NICE_FILTER


There were quite a few permutations of these possible cases.

Sample scripts.

Fail. "I dont' know what 'r' means"
Eval MT mode 2 + function call + last filter in Eval is non cacheable and NICE_FILTER (Interleave)

SetFilterMTMode("Eval", 2)
#or SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}

O.K. - MT mode 2 + last filter in Eval is cacheable (StackVertical)

SetFilterMTMode("Eval", 2)
#or SetFilterMTMode("DEFAULT_MT_MODE", 2)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("a=Interleave (r, g, b)
StackVertical(a,a)")
}

O.K. - Eval MT mode 1

SetFilterMTMode("Eval", 1)
ColorBars()
Trim(0,2500)

test()

Prefetch(1)

Function test(clip src)
{
src
r = ShowRed ("Y8")
g = ShowGreen ("Y8")
b = ShowBlue ("Y8")
Eval("Interleave (r, g, b)")
}

[pinterf]

I have set all DitherTools functions to MT mode 2. The first time I opened it, it freezed again, but afterwards I couldn't get it to freeze again. Dither Tools will require more testing for its MT compatibility/stability level.

By the way, at the top of the MT modes list, there should be a link to where the list actually came from and how to update it. When I want to refer changes about it, I don't even remember where it came from and who wrote it.
Can it be that the memory is simply not enough? What happens is you downsize the original video to 320x200? Or use only Prefetch(4)?

[Reel.Deel]

This "I dont' know what 'r' means" is not an easy bug hunt.
At least now I know how to reproduce it...

I found another scenario where it happens but this time without MT.

This works, but if I change SMDegrain() to SMDegrain(globals=1) I get "I don't know what 'bv2' means". I do not know how to reproduce this without SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution) but if I find an alternative I'll let you know.

ColorBars(pixel_type="YV12")
SMDegrain ()

[MysteryX]

Setting DitherTools to MT=3 appears to work so far. Will have to test which filter breaks with MT=1 or MT=2.

Memory usage is only ~900MB.

[MysteryX]

DitherPost appears to be the one crashing. This works so far.


SetFilterMTMode("DitherPost", MT_SERIALIZED)


The other DitherTools filters appear to work with MT_NICE_FILTER although I haven't tested all of them.

[pinterf]

DitherPost appears to be the one crashing. This works so far.


SetFilterMTMode("DitherPost", MT_SERIALIZED)


The other DitherTools filters appear to work with MT_NICE_FILTER although I haven't tested all of them.
Setting one filter to a stricter MT mode affects the timing and parallel execution conditions of the other filters in the chain, too. So unfortunately you cannot say that DitherPost is culprit. We can only state that bottlenecking MT at DitherPost solves this problem.

[pinterf]

I found another scenario where it happens but this time without MT.

This works, but if I change SMDegrain() to SMDegrain(globals=1) I get "I don't know what 'bv2' means". I do not know how to reproduce this without SMDegrain (http://forum.videohelp.com/threads/369142-Simple-MDegrain-Mod-v3-1-2d-A-Quality-Denoising-Solution) but if I find an alternative I'll let you know.

ColorBars(pixel_type="YV12")
SMDegrain ()
Same happens to avisynth 2.6, because globals=1 is for read globals and Process

bv2 is a variable that a former processing phase outputs as global

You have to run a first phase in order to bv2 and the other variables exist.
ColorBars(pixel_type="YV12")
SMDegrain (globals=3) # 3 - Output globals only, don't process
SMDegrain (globals=1) # 1 - Read globals and Process

[Reel.Deel]

Same happens to avisynth 2.6, because globals=1 is for read globals and Process

bv2 is a variable that a former processing phase outputs as global

You have to run a first phase in order to bv2 and the other variables exist.
ColorBars(pixel_type="YV12")
SMDegrain (globals=3) # 3 - Output globals only, don't process
SMDegrain (globals=1) # 1 - Read globals and Process


Oops, you are totally correct. Its been a while since I've used SMDegrain. Sorry for the false alarm.

[qyot27]

Okay, challenge/project time.

Does anyone have a definitive (or near-definitive) list of C-plugins that have been written? Browsing the External Filters page on the wiki only brings up four or five (ColorDiff, FFMS2's C-plugin variant, AssRender, the old Yadif, and I feel like I'm probably forgetting another one...). Additionally, how many of them besides FFMS2 can be built as 64-bit?

The reason for this is part of my attempting to determine the best course of properly addressing pull request #41 (https://github.com/AviSynth/AviSynthPlus/pull/41).

For those interested, even if I supplied 64-bit builds of FFMS2's C plugin like I do for 32-bit, you can't use them with 64-bit AviSynth+, because it rejects them as invalid. If you fix 64-bit C plugin loading by applying the 'fix' from that pull request, 32-bit C plugins get seen as invalid in 32-bit AviSynth+.

So to quote my response on the pull request,
Perhaps it's not this complicated and there is a middle ground that can work for both (or something we need to add to the C API doc page to account for this weirdness if this is something that only plugin authors can do). But this pull request as it is is not the solution to this problem.

EDIT: I mean, the ugly, kinda-hackish way of fixing it would be to branch the C plugin check so that it does one thing if _WIN64 (a macro that I keep forgetting exists) is true and a different one otherwise, but hopefully there's a better way than that.

[pinterf]

EDIT: I mean, the ugly, kinda-hackish way of fixing it would be to branch the C plugin check so that it does one thing if _WIN64 (a macro that I keep forgetting exists) is true and a different one otherwise, but hopefully there's a better way than that.

As for Microsoft: "Note that in a 64-bit environment, functions are not decorated."
https://msdn.microsoft.com/en-us/library/56h2zst2.aspx#FormatC
For other compilers, I don't know.

So in 64 bit it looks like avisynth_c_plugin_init
In 32 bit _avisynth_c_plugin_init@4

Avisynth+ now tries with then w/o underscore
First: _avisynth_c_plugin_init@4
Then if fails: avisynth_c_plugin_init@4

I think, none of them matches with x64

The proposed patch tries the 64 bit convention first, then the 32 bit one
First: avisynth_c_plugin_init
Then if fails: _avisynth_c_plugin_init@4

I think the final patch can keep the two old version (with and without underscore) but would attempt to use the undecorated version before them.

[Groucho2004]

FYI - "avisynth_c_plugin_init" is what old C2.0 plugins export.

The "official" avisynth code looks first for the C2.5 export "avisynth_c_plugin_init@4" and if that fails for the C2.0 export "avisynth_c_plugin_init".

Of course this is moot since AVS+ doesn't support C2.0 plugs at all.

As for the determination whether a plugin to be loaded is 64 bit or 32 bit I would use the MapAndLoad() API and then examine the PE header. It's just a few lines of code (shown without any error handling):

LOADED_IMAGE li;
MapAndLoad("something.dll", NULL, &li, TRUE, TRUE);
if (li.FileHeader->FileHeader.Machine == IMAGE_FILE_MACHINE_I386)
{
//32 bit module
}
else
{
//64 Bit module
}
UnMapAndLoad(&li);

[pinterf]

Unlike this problematic version, when trying to load AvisynthPluginInit2 and AvisynthPluginInit3 the undecorated version is used on the first place.

AvisynthPluginInit2Func AvisynthPluginInit2 =
(AvisynthPluginInit2Func)GetProcAddress(plugin.Library, "AvisynthPluginInit2");
if (!AvisynthPluginInit2)
AvisynthPluginInit2 =
(AvisynthPluginInit2Func)GetProcAddress(plugin.Library, "_AvisynthPluginInit2@4");


Loading avisynth_c_plugin_init misses this option

[jackoneill]

In case you were wondering why it even checks for a partially decorated function: it's what you get by default when cross-compiling with gcc/mingw.

[qyot27]

I initially tried to do a cleaner version that simply set #defines and used those in the normal init checker, but that didn't work, so I just did it the way I'd hoped I wouldn't have to:
https://github.com/AviSynth/AviSynthPlus/pull/66

End result: 64-bit AviSynth+ can use 64-bit FFMS2-C, 32-bit AviSynth can use 32-bit FFMS2-C.

For those wanting to test:
http://www.mediafire.com/download/40b03f39ghip7w1/avisynth__r1826-g8d447dd-20160607.7z
http://www.mediafire.com/download/i78pcwd2m8c0yov/ffms2_r1110%2B100-avs%2Bvsp-test64.7z

[qyot27]

In case you were wondering why it even checks for a partially decorated function: it's what you get by default when cross-compiling with gcc/mingw.
The other thing I'd been considering is that the function decorations and such should be the task of the plugin author to get right, not of AviSynth+ to handle.

The only problem with that is that up until now, it was either never considered and/or never enforced, and there's no mention of it in the C API docs so that plugin authors can make sure GCC or MSVC decorates the stuff correctly.

So I support either case here: either AviSynth+ checks for the way the compilers are set up by default (leading to branching the init check as per pull #66), or we get strict about how the functions get decorated in C plugins and provide this guidance in the documentation so plugin authors can do so correctly (in which case I'll then fix FFMS2 instead).

[pinterf]

qyot27, integrated your changes, commit comment links to your pull request

[ajp_anton]

crop handles RGB as expected, but crops while resizing (the arguments after the target width/height) are reversed. Can this be fixed, or am I missing the reason for why this is?

[MysteryX]

crop handles RGB as expected, but crops while resizing (the arguments after the target width/height) are reversed. Can this be fixed, or am I missing the reason for why this is?
This was fixed in the latest release

[StainlessS]

RGB is upside down, perhaps somebody forgot :)
(is it just top/bottom that are wrong)

EDIT: Just beaten by MX.

[qyot27]

qyot27, integrated your changes, commit comment links to your pull request
...

For future reference, this is sort of the exact reason* that git's cherry-pick (https://git-scm.com/docs/git-cherry-pick) or format-patch (https://git-scm.com/docs/git-format-patch)/am (https://git-scm.com/docs/git-am) options exist.

*read: the commit can be applied as-is but you don't want to litter the git history with merge commits.

[pinterf]

I recently tried with this script and get a similar error "I don't know what 'z3' means". Disable MT and the script works just fine. :confused:

Import("MTModes.avsi")
Import("crt_display.avsi")

SetFilterMTMode("DEFAULT_MT_MODE", 2)

ColorBars()
Trim(0,500)

ar = 10.0 / 11.0
crt_display (2*ar, 2, ppp=1*ar, blurh=2.0)

Prefetch(4)

After three day of debugging I finally I came to the conclusion that Eval should be forced as NICE_FILTER.

The problem was that although Eval is a special passthrough script function, its behaviour was affected by setting the default mt mode.

When Eval is set to MT mode 2 (by setting default mt mode), but the last filter () inside Eval was NICE_FILTER, plus this filter is forced to have no cache, creation of Eval's MT guard entries inside the core are executed after Prefetch. But since in the problematic scenario this Eval was inside a function, it had lost its variable context: could not access the function-local z3 variable anymore.

The real mt behaviour is still defined by the content of the script passed to Eval as parameter.

[MysteryX]

Wow pinterf that's a good one!

It might take 3 days of debugging to catch such a small tricky detail, but it's by taking the time to do this for every little bug that we're going to get a stable platform. It just takes someone crazy enough to put their hands into it :)

There's one small bug I've been occasionally seeing while playing via SVP, that I mentioned earlier. "Sometimes" when it re-initializes the playback, some parts of the video are covered by pain green zones for a very brief period and then everything is fine. I've *never* seen this issue while using AviSynth in any other way, so I have suspicions that the memory corruption might be related to the way it relates with ffdshow. Since it's rare and random, it's very hard to reproduce and debug.

I've also been thinking about your idea of adding 16-bit support. As it has been proven by configuring SetMTFilterMode only when running AVS+, it's possible to write a plugin that works on both AVS 2.6 and AVS+ and that will provide extra features only if running on AVS+. Thus, a filter can support 16-bit when running on AVS+ while still providing regular 8-bit support for other versions.

Then, at first, it might be like Dither Tools that is integrated into the core and faster. If there is a replacement to Dither Tools in the core (16-bit resize, etc), then that would definitely be useful in and of itself. Then on top of that, over time, some developers will add 16-bit support into their plugins, but we'd have benefits even if few other filters support it.

[MysteryX]

I can know whether an MT version of AviSynth is running like this


bool IsMt = env->FunctionExists("SetMTMode") || env->FunctionExists("SetFilterMTMode");


Is there a way to know whether MT mode is actually enabled? Does the AVS+ extended interface provide information about the current MT status?

[Groucho2004]

Is there a way to know whether MT mode is actually enabled? Does the AVS+ extended interface provide information about the current MT status?
See posts #546 and #550.

[LigH]

In the original AviSynth MT, you could request GetMTMode(false) if available. No clue about AviSynth+ returning the Prefetch(threads) value, though; and there may be a reason why it has to be used as very last command in a script...
_

P.S.:

See posts #546 and #550.

Kindly providing a link to #546 (http://forum.doom9.org/showthread.php?p=1666404#post1666404) ;)

In brief: Due to the association of modes with filters, instead of the script position, requesting the "current mode" is not supported in AVS+. For plugin developers, the IScriptEnvironment2 interface has a property to return the thread count.

[MysteryX]

Kindly providing a link to #546 (http://forum.doom9.org/showthread.php?p=1666404#post1666404) ;)
Thanks!


Yes, you can tell that using IScriptEnvironment2::GetProperty(AEP_FILTERCHAIN_THREADS), but please don't use it before the whole IScriptEnvironment2 is finalized. This is not a licensing restriction, it has to do with the fact that if you start using it and the class changes after that, your application will break.


What is the right way to use it so that it doesn't crash if the API changes?

For now I have this


// Runs as MT_NICE_FILTER in AviSynth+ MT, otherwise MT_MULTI_INSTANCE
isMT = false;
if (env->FunctionExists("SetFilterMTMode")) {
auto env2 = static_cast<IScriptEnvironment2*>(env);
isMT = SUPPORT_MT_NICE_FILTER && env2->GetProperty(AEP_FILTERCHAIN_THREADS) > 1;
}

[Chikuzen]

Hi.

It seems that FlipHorizontal is broken on RGB32.
https://dl.dropboxusercontent.com/u/19797864/fh_bug.png

patch

diff --git a/avs_core/filters/transform.cpp b/avs_core/filters/transform.cpp
index c56a56e..390ea53 100644
--- a/avs_core/filters/transform.cpp
+++ b/avs_core/filters/transform.cpp
@@ -156,7 +156,7 @@ PVideoFrame FlipHorizontal::GetFrame(int n, IScriptEnvironment* env) {
if (vi.IsRGB32()) {
for (int y = 0; y<height; y++) {
for (int x = 0; x<width/4; x++) {
- *reinterpret_cast<int*>(dstp+x) = *reinterpret_cast<const int*>(srcp-x);
+ (reinterpret_cast<int*>(dstp))[x] = (reinterpret_cast<const int*>(srcp))[-x];
}
srcp += src_pitch;
dstp += dst_pitch;

[pinterf]

Chikuzen, thank you, fixed.

[ultim]

I came to visit the forums, and after catching up with this thread, boy I cannot express how glad I am that pinterf picked up where I left. I am sorry for my unfinished work. I honestly never intended to abandon the project, and the reason I never said anything about leaving was because I was telling even myself “nah, I don't feel like it right now, but I'll be sure to continue working on avs+ in a month or so.” I guess it is safe to say now that this has been going on for so long, that who am I kidding?!

I guess partly the reason is that 1) my work on avisynth was strongly linked to my involvement in the fansubbing scene, which I stopped participating in about a year ago (we'll see if I'll be back now). Also, 2) I also got a bit demotivated due to some other reasons.

Anyway, pinterf seems to have done a splendid work on ironing out the most important rough edges. But most importantly, I am writing to offer my help. I doubt I'll be as active as before regarding coding, but reading back this thread, I have seen a few posts where I think I can be of help.

1) At some point it was mentioned it'd be good if somebody was around to answer questions about the current design, mostly relating to caches. It seems pinterf has since then figured out what he needed at that point, but still, if he has any questions, I'll be here.

2) He also mentioned he is keeping his changes on a different branch so that should it come to that, integration to Avs+ can be done easily. If he would like to, I'd be more than happy to pull his changes into the Avs+ repository. pinterf said somewhere something about a code review, I can do that too if he'd like to.

3) As an extension to the previous point, I'd like to give him full rights to the main Avs+ repository (I do not intend to monopolize on the development of Avs+, after all, maybe the most important goal of the whole fork was to try to revitalize the community).

4) I also see no problem in issuing an updated installer with the new improvements.

5) Am I back? To some small extent. I'd like to be an active member of the community, but realistically speaking new talents are needed to ensure active development. Please let us give pinterf and other interested people our support.

[Sparktank]

This is good news, Ultim! :goodpost:

Even if you will be scarce, it's great to hear continued interest.

[ryrynz]

Great news. Nice to see you back and what that'll mean for this project going forward.

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

[ultim]

Great news. Nice to see you back and what that'll mean for this project going forward.

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

Eh, that's assembly :p

TurboPascal has more than enough experience in doing such things (porting things over to much better intrinsics, which at the same time brings proper x64 support), but I think he lost interest in Avs.

Asking cannot hurt though.

[jackoneill]

Eh, that's assembly :p

TurboPascal has more than enough experience in doing such things (porting things over to much better intrinsics, which at the same time brings proper x64 support), but I think he lost interest in Avs.

Asking cannot hurt though.

I think you could copy them from the VapourSynth plugin.

[Reel.Deel]

I guess nows a good a time as any to ask if anyone here would be willing to put together a compatible 64 bit version of cretindesalpe's updated awarpsharp 2. I'm getting instability using the 2012 64 bit build and it's the only filter keeping me from a full 64 bit work flow, cheers.

Apparently this only happens with 64-bit ffdshow (http://forum.doom9.org/showthread.php?p=1769711#post1769711). I remember the SVP people also had troubles with 64-bit ffdshow. In the end it turned out to be an issue with ffdshow. Not saying that's the issue here, just something to keep in mind.

More info here: https://github.com/AviSynth/AviSynthPlus/issues/50

[ryrynz]

You know, that could quite well be it.. I don't hold much hope of anyone wanting to delve into ffdshow to fix this but if anyone is going to then I guess it would be either pinterf or ultim. I'll just continue to use the 32 bit version like I always have done for years no worries.

It would be nice to see if fixing the above issue resolves it, ffdshow is still required for real time processing and a full 64 bit chain should be more efficient. The crash occurs instantly on start up about 20% of the time. I am fairly certain that just a single basic awarpsharp call will trigger it, I'll confirm it and update this post later tonight, thanks.

[MysteryX]

The issue with SVP and ffdshow x64 doesn't cause a crash but is a serious memory leak that happens on every seek. It doesn't liberate its resources.

[ryrynz]

To be clear, the player (in this case mpc-be) crashes instantly. I'll pin point it down a bit better and play with a few options.

[real.finder]

Apparently this only happens with 64-bit ffdshow (http://forum.doom9.org/showthread.php?p=1769711#post1769711). I remember the SVP people also had troubles with 64-bit ffdshow. In the end it turned out to be an issue with ffdshow. Not saying that's the issue here, just something to keep in mind.

More info here: https://github.com/AviSynth/AviSynthPlus/issues/50

Actually awarpsharp2 has bugs in x64 http://forum.doom9.org/showthread.php?p=1745892#post1745892

[Reel.Deel]

Hey there ultim. Nice too see you around :).

I've recently started to work on the documentation (http://forum.doom9.org/showthread.php?p=1769249#post1769249), so far almost all of it comes from cherry picked posts from this thread. There are a few things here and there that may need a bit of elaborating/clarification, unfortunately I do not know too much about these things to do so. Maybe once I'm done you can give it a quick review. Right now it's just a sloppy word file, some of it is what's already on the AviSynth+ wiki.

It made it a lot easier for me to proof the changes between old (HTML) and new (Sphinx) versions by using the Tile View extension in Firefox, so I could see both side-by-side instead of needing to switch between tabs, with Notepad2 (or Leafpad, since I was under Linux while doing this) off to the side to edit the actual RST files.

It's really as simple as 'make html' in the distrib/docs/english directory, so long as you've installed Python and Sphinx. Sphinx will tell you if there are syntax errors in the files, and if the built HTML version is open in your browser, you can see the errors and work them down until it complies. And it'll also only rebuild the files that have been touched, rather than needing to rebuild the entire doc tree.

I installed Python 2.7.11 and the latest Sphinx, I also updated to the latest pip(8.1.2). Whenever I click 'make.bat', a command prompt window quickly opens and closes. Am I missing something here?

[pinterf]

I came to visit the forums, and after catching up with this thread, boy I cannot express how glad I am that pinterf picked up where I left....
Hi! I'm glad you are back, and yes, I have so many questions, contrary to the fact that (unfortunately) I'm the kind of a man that first tries to make sure of things alone, in order not to ask obviously stupid questions. Not the fastest way of getting the knowledge, though. I'm still on the learning curve on both avisynth internals, sometimes even syntax elements that I never use.
I am still a humble maintainer of the avisynth plus code. I wish I were a young student again with plenty of free time :)

[MysteryX]

Humble, courageous and patient.

[Reel.Deel]

In classic AviSynth I can load plugins like this:
LoadPlugin("AddGrainC", "MedianBlur2.dll")

ColorBars(pixel_type="YV12")
AddGrainC(100)
MedianBlur()

However, in AviSynth+ the second plugins does not load:
Script error: There is no function named 'MedianBlur'.

Is this the expected behavior or is it a bug?

[qyot27]

I installed Python 2.7.11 and the latest Sphinx, I also updated to the latest pip(8.1.2). Whenever I click 'make.bat', a command prompt window quickly opens and closes. Am I missing something here?
Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

[LigH]

In classic AviSynth I can load plugins like this:
LoadPlugin("AddGrainC", "MedianBlur2.dll")
...
...

Probably:

LoadPlugin("AddGrainC.dll", "MedianBlur2.dll")
...

Still, I don't remember anyone using this syntax, even if it is allowed. So I could imagine that AviSynth+ did not implement it as variable parameters...

[Reel.Deel]

Probably:

LoadPlugin("AddGrainC.dll", "MedianBlur2.dll")
...

Still, I don't remember anyone using this syntax, even if it is allowed. So I could imagine that AviSynth+ did not implement it as variable parameters...

Oops, even if I add .dll to AddGrainC the second plugin still fails to load. Kinda odd that it loads without .dll at the end.

Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

Thanks, I'll try it when I get back at home.

[Chikuzen]

However, in AviSynth+ the second plugins does not load:

Is this the expected behavior or is it a bug?

It's a bug.

patch

diff --git a/avs_core/core/PluginManager.cpp b/avs_core/core/PluginManager.cpp
index 517f713..5141866 100644
--- a/avs_core/core/PluginManager.cpp
+++ b/avs_core/core/PluginManager.cpp
@@ -867,7 +867,7 @@ AVSValue LoadPlugin(AVSValue args, void* user_data, IScriptEnvironment* env)
IScriptEnvironment2 *env2 = static_cast<IScriptEnvironment2*>(env);

bool success = true;
- for (int i = 0; i < args.ArraySize(); ++i)
+ for (int i = 0; i < args[0].ArraySize(); ++i)
{
AVSValue dummy;
success &= env2->LoadPlugin(args[0][i].AsString(), true, &dummy);

[Reel.Deel]

Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

I always have trouble with the command line, got it working though. Now I can start messing around with the documentation. :)

Shift and right click (I learned something new):

http://i.imgur.com/fnR4hup.gif

It's a bug.

patch


Thanks Chikuzen.

[pinterf]

It's a bug.
patch
Thank you, applied.

[ryrynz]

I'm getting instability using the 2012 64 bit build and it's (Awarpsharp) the only filter keeping me from a full 64 bit work flow, cheers.

Actually found out that it's Hysteria (Uses masktools) that hates working in MT mode 2 on 64 bit. Works fine in 32 bit using that mode, switched to mode 3 and no more crashes (am using tp7's most recent version)

Would still love to see a up to date 64 bit build of Awarpsharp though :)

FWIW It's really nice to be able to run 64 bit Avisynth using MT now.. was such a long wait.

[ultim]

Last night I was going through all the outstanding commits and pull requests. Basically two big groups, one for catching up to Avs 2.6, the other from pinterf (which has most if not all other PRs against Avs+ already integrated). pinterf's changes are mostly alright, I still need to inspect in detail the changes regarding the FrameRegistry, but I'm gonna pull it anyway simply because it works. There were maybe 2 other small commits that I'd like to offer feedback on, but nothing major. We can discuss if necessary after pulling.

I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).

But summing it up, meh... I don't like any of these options. Not to mention I see this as a very important and key decision. I don't mean to over-dramatize, but given the already fragile state of Avs, one wrong step here could mean the end of Avisynth as a whole. Maybe we could just ask IanB to roll back the corresponding changes? Arrrrgh... I have no idea what we should do.

[ultim]

Just by following the questions from my previous post further, we can get into really deep woods. Like for example, without trying to imply anything: What are our expectations of our community? Where do we want Avisynth to go long-term? Do we want it to go anywhere long-term? If we'd like to change Avs to a great extent, should people invest in a re-write of Avs or just adopt VapourSynth? Do both projects have unique selling points? What about existing plugins? What about future plugins?

It's not like these questions are being asked now for the first time, but IMHO it surely wouldn't hurt to finally discuss these, since we're talking about possibly diverging from Avs2.6, which basically means making Avs+ a community of its own. And even if that split doesn't happen, which is also fine, it would help to lay the future, survey opinions, and plan resources.

[MysteryX]

I wasn't even aware v2.6 had a x64 version, and I haven't heard of anyone using it. I'd say v2.6 is at least 95% used in x86 mode, and AviSynth+ should be compatible with v2.6 x86 and further provide x64 support.

If someone really wants to use v2.6 x64, then correcting that version to make it compatible again is an option but I don't think many care.

The main advantage of AviSynth is its compatibility with a large library of plugins. If we were to rewrite all plugins, better as well rewrite them in VapourSynth.

I think VapourSynth has great potential but it still lacks major features:
- audio support
- ffdshow support
- extensive library of plugins

There's also the issue of AviSynth+'s extended interface. I think we can write plugins that make 'optional' use of AviSynth+'s extra features while also working without, by first checking whether the functions exist. That way, we can maintain compatibility without being limited to the old interface.

[ultim]

Avs2.6 does not yet have a x64 version. But the changes in question make me think IanB is working on 64-bit support and might be adding that in the future, because the changes only make a difference for 64-bits. So if he is not planning on 64-bit support, why did he change it in the first place? And if Avs2.6 really introduces it, then the same plugins wouldn't work correctly on both Avs2.6 and Avs+.

About the extensibility: Avs+ is built exactly like that. It maintains compatibility with all plugins, but each has the possibility to selectively make use of Avs+ features if it decides so at runtime. The interface is still limiting though and is hindering a lot of modernization efforts. Even up to now there have been multiple occasions where we needed to find a workaround at the expense of increased code complexity, just because the old interfaces aren't accommodating enough, and we also didn't want to break them. This results in various levels of ugliness, like an increased amount of compatibility layers, a sub-optimal compromise of features, or illogically/badly placed functions or hidden functionality out of necessity.

[Reel.Deel]

I started making some changes to the documentation and need some opinions. Here's the difference between the two: http://diff.pics/JbQx0fvGOTeM/1

I added a syntax and parameters section and I also highlighted the syntax and listed all the parameters and their descriptions. I would like to do this to all the internal filters. Yea or nay?

[TheFluff]

Last night I was going through all the outstanding commits and pull requests. Basically two big groups, one for catching up to Avs 2.6, the other from pinterf (which has most if not all other PRs against Avs+ already integrated). pinterf's changes are mostly alright, I still need to inspect in detail the changes regarding the FrameRegistry, but I'm gonna pull it anyway simply because it works. There were maybe 2 other small commits that I'd like to offer feedback on, but nothing major. We can discuss if necessary after pulling.

I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).

But summing it up, meh... I don't like any of these options. Not to mention I see this as a very important and key decision. I don't mean to over-dramatize, but given the already fragile state of Avs, one wrong step here could mean the end of Avisynth as a whole. Maybe we could just ask IanB to roll back the corresponding changes? Arrrrgh... I have no idea what we should do.
This is a problem of your own making. You introduced a sorta working 64-bit Avisynth version without making the plugin API properly 64-bit. There were a few x64 plugins before Avs+ but nothing really useful and nobody used 64-bit Avisynth anyway because it was really broken. IanB did the right thing when he fixed those pointer sizes and you should have done it too - it would've been less painful to you early on.

What you should have done back then (and you can still do it) was to create a new plugin API and emulate the old one (like Vapoursynth does). I believe this was pointed out to you at length, back then.

I also think you overestimate the effort required to recompile "all" plugins. I would estimate the number of commonly used and actually conceivably useful (with a very wide definition of "useful") Avisynth plugins today, in 2016, to be less than two dozen.

- ffdshow support
Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.

[qyot27]

I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).
At one point I remember someone bringing up the idea of eliminating the C++ compiler difference in the event of MinGW builds by having a compatibility shim that wraps C++ plugins and loads them through the C interface.

Would something like that be able to also eliminate the compatibility problems with 2.6's switch to size_t to support 64-bit? Alternately, have a separate loader for size_t-based 64-bit plugins that the user can do specific overrides for if necessary (e.g., LoadPlugin("Plugin.dll", alt_loader=true), or Load_New64_Plugin("Plugin.dll")). If that'd even work, that is.

On a purely philosophical level, I'd say break with the old interface completely and start fresh. On a practical level, I know that's ill-advised. I'd prefer that we have some kind of fallback so that plugin devs can migrate to the new interface organically without shocking users. But design the new interface so it doesn't collide at all with the old and is completely self-contained. This way plugins can simply add another interface for AviSynth+ alongside their interfaces for classic AviSynth (which avsplus could still load in this scenario) and VapourSynth without any real hiccups.

[MysteryX]

Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.
I use SVP and it remains the only way to use it. Although they recently added a VapourSynth version but only with mpv player. So far AviSynth+ can't be replaced for that here.

[Groucho2004]

I use SVP and it remains the only way to use it.
The point is that a broken 64 bit ffdshow has nothing to do with Avisynth(+). Why don't the SVP guys fix it themselves?

[ultim]

This is a problem of your own making. You introduced a sorta working 64-bit Avisynth version without making the plugin API properly 64-bit. There were a few x64 plugins before Avs+ but nothing really useful and nobody used 64-bit Avisynth anyway because it was really broken. IanB did the right thing when he fixed those pointer sizes and you should have done it too - it would've been less painful to you early on.

I don't agree. Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, dozens because I collected links to all of what I could find.

Second, those changes, while "correct" on a theoretical level, bring absolutely zero advantage to any realistic use case or application. At least not unless you have video frames which are each 4GB-sized. Even in the era of UHD this is irrealistic, and so the whole change is unnecessary. Yes I'd have taken size_t for data type too if developing a new interface from scratch, but once you consider you have a far-from-zero existing ecosystem to support and not to break, I wouldn't change to it unless it brings some important (and, importantly quantifiable) technical benefits - which it does not.

Changing something which only causes breakages and brings zero advantages whatsoever, is, I'd argue, inexplicable and questionable, so honestly, I don't see why I should be held responsible for future problems to arise. I can justify my decision like above, unlike the other side which is "I ruin a bunch of things for no gain, but at least this is how I should have done it at the beginning, provided there had been any real benefits."

And besides, our result was not a "sorta working 64-bit Avisynth version without making the plugin API properly 64-bit", but a fully functional one, supporting 64-bits perfectly in the core as well as in the plugin interface. The only 64-bit-related problems we have are not due to errors in the interface, but due to non-64-bit-ready external plugins, for example due to hand-written asm.

[TheFluff]

I don't agree. Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, literally dozens because I collected links to all of what I could find.
You did it wrong. You just counted links without any concern for actual usefulness or popularity. Last time I called you out on this (http://forum.doom9.org/showthread.php?p=1712704#post1712704) you mainly cited JoshyD's and squid80's ports of an eclectic bunch of about two dozen plugins, most made in the first half of 2010 and never updated after that, and without any attempts at modernization whatsoever. I think they just ripped out a bunch of things that didn't work in many cases and some of the ports were pretty buggy. There were like three people who used this x64 version of 2.5.8 and it died a peaceful death within a year or two. I don't think many people ever were aware these plugin versions even existed (burying mediafire links deep in some thread on d9 isn't a great marketing strategy).

Other than that you also cited tp7's modernized plugins, which should have been trivial to recompile for a new API. Even JoshyD's and squid80's plugins should have been fairly trivial to just recompile against a new header.

This wasn't an "ecosystem", it was an abandoned garbage dump.

Second, those changes, while "correct" on a theoretical level, bring absolutely zero advantage to any realistic use case or application.
From a strict API standpoint perhaps, but you gotta consider that it locks both you and your users into a particular allocation strategy.

And besides, our result was not a "sorta working 64-bit Avisynth", but a fully functional one.
Remind me again, for how many months did the latest release version have a critical slowdown issue?

Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar. If all these people who have attempted to hack on Avisynth in the last ten years would have spent half as much effort on a well designed and thought out rewrite instead of hacking on the increasingly broken 90's garbage we would have been in an infinitely better situation today.

[Reel.Deel]

I also think you overestimate the effort required to recompile "all" plugins. I would estimate the number of commonly used and actually conceivably useful (with a very wide definition of "useful") Avisynth plugins today, in 2016, to be less than two dozen.


That's your opinion, what you consider useless might not be to another person.

Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, dozens because I collected links to all of what I could find.


Indeed, the amount of 64-bit plugins has definitely grown. There's over a 100 plugins now: http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

And besides, our result was not a "sorta working 64-bit Avisynth version without making the plugin API properly 64-bit", but a fully functional one, supporting 64-bits perfectly in the core as well as in the plugin interface.

Yes, 64-bit AviSynth+ r1576 is rock solid.

[ultim]

From a strict API standpoint perhaps, but you gotta consider that it locks both you and your users into a particular allocation strategy.

All it locks down is that Avs can only allocate frame planes in a single allocation call. That is hardly the part of frame allocation strategy that matters for speed or features.


Remind me again, for how many months did the latest release version have a critical slowdown issue?

Remind me what that had to do with either the stable release or with the 64-bit port. The slowdown that pinterf has recently solved was in a testing release of the MT-branch. The stable one, with already existing 64-bit functionality, didn't suffer from it AFAIK. The problem you are pointing out has nothing to do with the quality of our 64-bit port, and there is a reason why the buggy build was not issued as stable.


Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar. If all these people who have attempted to hack on Avisynth in the last ten years would have spent half as much effort on a well designed and thought out rewrite instead of hacking on the increasingly broken 90's garbage we would have been in an infinitely better situation today.
Amen, unfortunately. This I can agree with. As for me, I didn't dare to gut out Avisynth and refactor it in an even more extreme way, because I see its existing support for its greatest plus. And frankly I do not see a way of completely rewriting everything AND keeping compatibility with existing plugins. VapourSynth tried something similar, but AFAIK not even he succeeded completely, though the results are more than commendable. At this point, if somebody went ahead and threw out all the existing code base AND existing plugin support, it might be worth considering to rather implement an Avisynth-language frontend for VapourSynth instead - I'm not sure though but I think Myrsloik at some time stated that it wouldn't be possible for some reason. Which kind of leads to the questions I noted down a few posts earlier.

[ryrynz]

This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call.

Avisynth is going nowhere. He's what, the only person working on it? His code changes don't appear to be significant, I could be wrong but to me it seems pinterf has done more work on this branch than IanB has done on Avisynth recently, will Avisynth 2.7 ever come?

One can basically conclude that after 2.6, Avisynth is going nowhere fast. I guess it's a prime opportunity for Avisynth+ to take over, this was basically the intention wasn't it?


I think VapourSynth has great potential but it still lacks major features:
- ffdshow support



Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.
Would've been more accurate to say piping to Directshow, I agree ffdshow should go, but while it would seem an easy task based upon what you said below.. nobody has yet to write a replacement
that could deal with scripts and support loading conditions.

Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?


Not at this time. It'd be pretty easy to implement for someone who is familiar with dshow though (and that's usually the bottleneck for dshow-related stuff anyway).

Anyone able to poke around for someone capable of doing this?

[Wilbert]

Avisynth is going nowhere. He's what, the only person working on it? His code changes don't appear to be significant, I could be wrong but to me it seems pinterf has done more work on this branch than IanB has done on Avisynth recently, will Avisynth 2.7 ever come?

One can basically conclude that after 2.6, Avisynth is going nowhere fast. I guess it's a prime opportunity for Avisynth+ to take over, this was basically the intention wasn't it?
You are exaggerating a lot without checking your statements first. Note i'm not defending Avisynth here, i know that Avisynth+ has some nice features that Avisynth as not (and will not have in the short term).
Your last comment would have merit if several people would be working on Avisynth+ continuously (meaning without large breaks), but that's not really the case.

@Ultim, i talked with Ianb about that issue (size_t) more than a year ago, but he has a different opinion and won't revert those changes back. So that leaves us at a shitty situation with that many 64 bit plugins out there nowadays.

[MysteryX]

Ultim is back; why is there so much aggressiveness in the air?


Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar.
I don't agree.

Pinterf's efforts have already paid off in great ways. AviSynth+ MT is very solid.

I don't think learning a new scripting language is a big deal at all. The reason me and many are staying with AviSynth instead of going with VapourSynth is mostly because VapourSynth is still early in its development stage. It has advantages but also lacks features, and most importantly, has much less plugins (although that's growing). Many plugin writers nowadays write it for both. I haven't ported my plugin AviSynthShader to VapourSynth because I haven't used it yet and because it would provide no performance advantage. If VapourSynth was to include audio support and support all the plugins I'm using, I would consider switching over.

There seems to be an ego battle as to who's version we're using. For those who spent so much time developing one of the branches, there's a lot of pride associated to that and it can be hard to let it go to focus on what's best for all.

AviSynth 2.6, AviSynth+ or VapourSynth? I really don't care. Let's just use whatever works best.

I like Pinterf's mindset: just do your stuff and don't care what people think. He wants to add native 16-bit support that way. As long as it doesn't break existing plugins, some plugin developers can use it while others won't. It won't hurt anyone.

About the specific x64 problem, considering that there is no AviSynth 2.6 x64 out there and that AviSynth+ x64, I don't see why put any efforts in releasing a AviSynth 2.6 x64. If he does release it, then it's his job to ensure its compatibility with existing plugins unless he can take responsibility for recompiling every plugin -- which I doubt will go smoothly.

The most important point is to leave our egos on the side. Whether AviSynth has a future is irrelevant. It's here, it is working and it will remain useful to many. It gets better over time, slowly. Will VapourSynth take over AviSynth? Maybe. I hope it so. But that may take a lot of time and AviSynth still can't be replaced in most cases.

[Reel.Deel]

Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work.

Have you even tried it? The last time I checked, QTGMC in AviSynth+ MT performed a bit better than VapourSynth. So if you call that kinda sorta maybe working, then there's something really wrong with VS. I also love that you keep saying that AviSynth is 90's software yet a good percentage of the VapourSynth plugins and scripts are just ports from AviSynth. I have nothing against VS, in fact I was one of the early testers back in 2012 through 2014 and still use it to this day. You on the other hand, it seems you have some sort of personal vendetta against AviSynth. If you really care about VS so much than why is it that I've yet to see anything productive from you? Not a single bug report, or a plugin, or any help with the development, nothing, all you do is talk.


Ultim is back; why is there so much aggressiveness in the air?

Post #1773 and #1778. :)

[MysteryX]

Blaming and arguing what could have been done in the past won't lead anywhere, I think we can all agree on that. So let's look at what's the best course of action for now.

If we're to require every plugin writer to adapt their plugins, better as well ask them to make them VapourSynth-compatible. IMO that's not a good idea.

In terms of code ugliness, honestly, I really don't care about the code being "theoretically correct" or "politically correct" as a user, as long as it's stable.

I see AviSynth continuing with its interface, and evolving with an extended interface that will need to be clearly defined at some point.

If IanB decides to release a version of AviSynth 2.6 x64 that isn't compatible with all the plugins already out, that will be his problem. Convincing everybody to recompile won't work when most are using AVS+ x64 anyway. He'll then have 2 options: adjust his x64 to match the existing libraries, or that version will end up in the abyss of times. Personally I don't see the need for AviSynth 2.6 x64 but the x86 version is still widely used. Here's another thing to consider, if we did get every plugin developer to re-compile, every single user would have to replace every single one of their plugins. That would be a mess. The forum would be flooded with newbies asking why their plugins aren't working anymore. Not counting DLL mixups and confusion all around the Internet, never knowing whether you're downloading the right version. Just think of what happened when the video industry decided to shift Rec.601 to Rec.709 to make it "better". We're still dealing with the side-effects.


I would see 2 points of improvements.

1. Clearly defining the extended interface of AviSynth+

2. Writing guidelines about how to write plugins that work with both AviSynth and VapourSynth. As a developer, it would be useful to have a comprehensive list of the differences and a roadmap to make them compatible.

[ultim]

@Ultim, i talked with Ianb about that issue (size_t) more than a year ago, but he has a different opinion and won't revert those changes back. So that leaves us at a shitty situation with that many 64 bit plugins out there nowadays.

Thank you for talking to him. Knowing he won't revert takes at least one variable out of the equation.

Ultim is back; why is there so much aggressiveness in the air?
That's kind of a side-effect of my exchange with TheFluff, for which I am sorry, we both didn't mean it this way. And about me being back, please don't give me too much credit, I've told earlier that while I may help out now, others will have to start to take over my place.

You on the other hand, it seems you have some sort of personal vendetta against AviSynth. If you really care about VS so much than why is it that I've yet to see anything productive from you? Not a single bug report, or a plugin, or any help with the development, nothing, all you do is talk.
TheFluff doesn't have any vendetta, I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth. Also, as for his contributions, I think he is the maintainer of one of the most important source filters, FFMSSource and the associated library ffms2. Correct me if I'm wrong.

[MysteryX]

I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth.
AviSynth was never dead. It will live for as long as it serves its purpose.

I use it for
- SVP live video conversion to 60fps
- Auto-attune video playback from 440hz to 432hz
- Video/audio processing and encoding

Out of all this, so far, VapourSynth can only do video processing and encoding. And that has nothing to do with the limited set of plugins available in it. That's just my personal situation -- AviSynth can't be replaced at this point.

[burfadel]

I prefer Avisynth myself, I guess I'm not used to Vapoursynth.

There's a consideration for Avisynth in that legacy support should be offloaded, and have Avisynth primarily 'clean'. Basically to use a plugin requiring legacy support, you call the plugin for legacy support plugin commands, like:
legacyplugin(dooflakey(str=2.5))

Ideally thought the legacy plugins should be updated, not Avisynth. It's coming up to 2017, really should only be using 64-bit anyway :). That would probably make things a lot easier if only the 64-bit side of things were developed, and have the corresponding plugins updated.

[ryrynz]

Wouldn't it be pretty straight forward to just fork it, have a legacy branch that receives whatever updates Avisynth gets, plus any easily portable updates and one branch where everything goes it's own way.

[tormento]

As pinterf is now an active contributor, I feel it is time to submit again an old problem I introduced months ago.

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I apply the following script, using AviSynth 2.6 MT, I have good encodings.

13HoursAV26.dgi (http://www76.zippyshare.com/v/rRxxLkBo/file.html)

SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)
ChangeFPS(last,last,true)
SetMTMode(2)
crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Result (http://www59.zippyshare.com/v/hIE3KfV0/file.html).

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

prefilter=1 (http://www62.zippyshare.com/v/HuSWnCqY/file.html) OK
prefilter=2 (http://www62.zippyshare.com/v/5NkG9ias/file.html) OK
prefilter=3 (http://www62.zippyshare.com/v/AXzb0Vqj/file.html) OK
prefilter=4 (http://www62.zippyshare.com/v/EU1MjUsM/file.html) CORRUPTION

Memento:

prefilter

[int: "-1", 0, 1, 2, 3, 4] or [clip: - ]

-1 = off (Default)
0 = light controlled gauss blur
1 = mild median/gauss blur
2 = strong median/gauss blur
3 = dfttest (spatial)
4 = KNLmeansCL (spatio-temporal GPU filter)
variable = prefiltered clip input variable

I have tried to use x86 version of AviSynth+, even DGIndexIM.

Results does not change.

The plugin versions I use are the following for both AviSynth and AviSynth+.

[Avisynth CPP 2.6 plugins]
D:\Programmi\media\AviSynth+\plugins64\KNLMeansCL-0.7.6.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MaskTools-2.1b1-tp7.dll (2.1.0.0)
D:\Programmi\media\AviSynth+\plugins64\MedianBlur2-0.94-tp7.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MVTools-2.7.0.22-pfmod.dll (2.7.0.22)
D:\Programmi\media\AviSynth+\plugins64\RgTools-0.92.1-tp7.dll (n/a)

[Avisynth CPP 2.5 plugins]
D:\Programmi\media\AviSynth+\plugins64\DFTTest-1.9.4.dll (1.9.4.0)
D:\Programmi\media\AviSynth+\plugins64\Dither-1.27.2.dll (n/a)

I can provide other movie examples too.

Ideas? Fixes?

P.S.: Previous post is here (http://forum.doom9.org/showthread.php?p=1739893#post1739893).

[Reel.Deel]

TheFluff doesn't have any vendetta, I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth. Also, as for his contributions, I think he is the maintainer of one of the most important source filters, FFMSSource and the associated library ffms2. Correct me if I'm wrong.

It certainly seems that way (here and in other threads in the past year). He has helped maintained FFMS2, but not in recent times nor anything to do with VS: https://github.com/FFMS/ffms2/graphs/contributors

Anyways, lets get back on topic. :)

[TheFluff]

I haven't contributed to any open source projects in many years now. In fact I don't even code for a living anymore, I've switched careers. I don't use Avisynth or Vapoursynth myself either since I don't encode any video anymore and haven't done so for at least four or five years. For some reason though I still hang around with people who do work with these things and for some reason I still care. You are of course always free to disregard my opinions on any grounds you prefer.

To be clear, when I'm talking about pinterf's insane things, I'm referring to the recent problems with eval() having to be treated as a MT_NICE_FILTER. This is of course patently insane, eval() isn't a filter and should be seen as a component of the script parser, but nope, this is what you get for trying to tack on multithreading to a hobbyist project from the 90's. The amount of "cleverness" (to put it nicely) required to keep it working in all cases just keeps growing until you have a completely unmaintainable mess.

What the Avisynth community definitely needs the least these days is more fragmentation. It's been pretty bad for many years with all the different MT versions and official versions and Avxsynth and god knows what else, but at least they had compatible plugins and script interpreters. When pinterf showed up I thought it was going to take yet another alarming turn for the worst with another fork and new version but fortunately that didn't happen. Instead, though, we now have, what, five different MVTools versions? Jeez, people, consolidate! I really don't think the plugin interface thing is such a huge deal either, it should be fairly easy to write wrappers to let you load other/older plugin interface versions in Avs+. Just ignore the "official" version IMO - you have the userbase on your side, the people who are still using the official version today are the kind of people who are still using Windows XP and are likely never going to upgrade either Avisynth or their plugins or their computers, even if a new version actually was released. 2.5.0 was released in 2003, 2.5.8 in 2008 and 2.6 last year, so at this rate, if you want a "final" 2.6 in the style of 2.5.8, expect to wait until 2020, and for "2.7" you're going to have to wait at least until 2027 or so. There's no point in trying to have a half-hearted fork that doesn't even attempt to supplant the parent project, either. Aim for the stars.

[TheFluff]

If VapourSynth was to include audio support and support all the plugins I'm using, I would consider switching over.
Out of curiosity, what plugins are you missing in VS? Also, are you aware it can load Avisynth plugins? I'm not trying to sell you a bridge or anything, I just believe you have a mistaken view of the state of VS.

[MysteryX]

Out of curiosity, what plugins are you missing in VS? Also, are you aware it can load Avisynth plugins? I'm not trying to sell you a bridge or anything, I just believe you have a mistaken view of the state of VS.

This is one of the scripts I use for live playback at 432hz. This can't be done in VapourSynth.

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA\In Your Eyes.mkv"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Preroll(int(FrameRate*3))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)


I haven't looked into what filters are or are not available in VapourSynth. RoboCrop to detect cropping isn't x64 compatible so I don't think that's in VapourSynth unless there's a replacement. If I crop the video and change the speed, I need to process the audio in the same way and I then call WriteToWAV and process the audio file separately.


As for "MT not working", I just realized something. There are two types of plugins out there. There are stand-alone plugins that just require a DLL to work, and there are "throw it all on the wall"-type plugins that depend on a chain of plugins that each depend on another chain of plugins. The first type is generally very stable with MT. The second type is not.

I was experimenting with SMDegrain and was surprised by the results, especially when combined with KNLMeans.

This did a great job on my SD videos and worked with MT.

SMDegrain(thsad=2000, contrasharp=true, lsb_in=true, lsb_out=true)


With HD content, it failed miserably. In fact I still can't get ContraSharp to run at all. With contrasharp=false, I can get it to work as long as MT is off, as MT causes deadlocks.

That's not an issue with AviSynth+ MT; but these plugins that depend on a whole chain of other plugins tend to be very unstable.

[real.finder]

This is one of the scripts I use for live playback at 432hz. This can't be done in VapourSynth.

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA\In Your Eyes.mkv"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Preroll(int(FrameRate*3))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)


I haven't looked into what filters are or are not available in VapourSynth. RoboCrop to detect cropping isn't x64 compatible so I don't think that's in VapourSynth unless there's a replacement. If I crop the video and change the speed, I need to process the audio in the same way and I then call WriteToWAV and process the audio file separately.


As for "MT not working", I just realized something. There are two types of plugins out there. There are stand-alone plugins that just require a DLL to work, and there are "throw it all on the wall"-type plugins that depend on a chain of plugins that each depend on another chain of plugins. The first type is generally very stable with MT. The second type is not.

I was experimenting with SMDegrain and was surprised by the results, especially when combined with KNLMeans.

This did a great job on my SD videos and worked with MT.

SMDegrain(thsad=2000, contrasharp=true, lsb_in=true, lsb_out=true)


With HD content, it failed miserably. In fact I still can't get ContraSharp to run at all. With contrasharp=false, I can get it to work as long as MT is off, as MT causes deadlocks.

That's not an issue with AviSynth+ MT; but these plugins that depend on a whole chain of other plugins tend to be very unstable.

try this http://pastebin.com/6Czuj5s0

[Myrsloik]

The binary compatibility stuff is really the smallest problem. You can always write a shitty wrapper. See the VapourSynth compatibility code on how to wrap things to something not completely identical.

Btw, the size_t thing is also possibly the smallest problem ever. I just realized that I'd implemented my own x64 compatility with the plain 2.6 header. Guess what? IT WROKSKSKSSS!!!!!!!1111 So just recompile everything with a 2.6 header and you're good.

Btw, TheFluff is the chief VS evangelist so you have to respond to all his trolling. No excuses.


And in regards to VS and plugins. I believe all popular unported plugins should work using the avisynth compatibility. If you find one that doesn't just post about it and I'll take a look.

[StainlessS]

TheFluff is the chief VS evangelist
What, you mean he does a lot of shouting, we all knew that !

[ryrynz]

Just ignore the "official" version IMO - you have the userbase on your side, the people who are still using the official version today are the kind of people who are still using Windows XP and are likely never going to upgrade either Avisynth or their plugins or their computers, even if a new version actually was released. 2.5.0 was released in 2003, 2.5.8 in 2008 and 2.6 last year, so at this rate, if you want a "final" 2.6 in the style of 2.5.8, expect to wait until 2020, and for "2.7" you're going to have to wait at least until 2027 or so.

Yup, that's what I said too. It's going nowhere fast. Wrap away.

[qyot27]

Wouldn't it be pretty straight forward to just fork it, have a legacy branch that receives whatever updates Avisynth gets, plus any easily portable updates and one branch where everything goes it's own way.
Simpler than that, actually; the AviSynthPlus repo on Github was itself forked from jeeb's, which (on a good day) was/is up-to-date with the CVS*. Cherry-pick and adapt whatever patches are relevant into an integration branch, and open a pull request to merge the integration branch into AviSynth+ HEAD. This is exactly how the RC1 and still-yet-unmerged RC2 integration was done, and how I'm currently slogging through the remainder of the 2.6a1/CVS stuff up to the beginning of June.

*and when it hadn't been updated with cvsimport in a while, I went ahead and pushed up a classic_avisynth (https://github.com/qyot27/AviSynthPlus/commits/classic_avisynth) branch into my personal avsplus repo that exists alongside MT and co.

[StainlessS]

I find myself asking why IanB would not want to sit back and relax, if others are prepared to take what has been achieved and carry it forward, great,
Ian deserves a rest and to watch whilst others add to his baby, no way should it be perceeived as anything less than total success, because that is what it is.
For myself I could not desert the current official state, and would I think not do so, but I do recognise the vigour of the new pretenders.
I dont know why Ian has chosen to isolate himself from the world, I at one time had my suspicions as to why, but rightly or wrongly, it is the path he has chosen to take,
however isolation cannot be good for anyone here. One cannot oversee or steer from afar something akin to Avisynth, perhaps Ian should forgo his ownership
of avs and let the new lads have a go.

Above was so very hard for me to say.

[MysteryX]

try this http://pastebin.com/6Czuj5s0
That's the version I have.

I'm discussing that issue in this thread (http://forum.doom9.org/showthread.php?p=1771486#post1771486)

[pinterf]

Btw, the size_t thing is also possibly the smallest problem ever. I just realized that I'd implemented my own x64 compatility with the plain 2.6 header. Guess what? IT WROKSKSKSSS!!!!!!!1111
For historical reasons my mvtools2 mod is also using that size_t version of the classic avs 2.6 header, and encountered no problem.
Why? Because these fields are accessed through methods instead of direct reference? I suppose it would break in a plugin running under avs+ x64 if we used avs 2.6 header and access pitch instead of calling GetPitch()?

int GetPitch(int plane = 0) const AVS_BakedCode(return AVS_LinkCall(GetPitch)(plane))


Classic
class VideoFrame {
public:
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const int pitchUV, row_sizeUV, heightUV;

avs+
class VideoFrame {

volatile long refcount;
VideoFrameBuffer* vfb;

// Due to technical reasons these members are not const, but should be treated as such.
// That means do not modify them once the class has been constructed.
int offset, pitch, row_size, height, offsetU, offsetV, pitchUV; // U&V offsets are from top of picture.
int row_sizeUV, heightUV;

[tormento]

Nobody went into my same issue? Nobody wants to investigate?

:(

[pinterf]

Nobody went into my same issue? Nobody wants to investigate?
:(
Can you upload your exact source somewhere (the dgi one, not the .264 - I was stuck how to convert it)
Then it would be much help if you stripped down the script until the corruption disappear. (Change parameters, uncomment SMDegrain internals). This is how I would start.
Does it happen when you convert your source and not using dgi?

[tormento]

Can you upload your exact source somewhere (the dgi one, not the .264 - I was stuck how to convert it)
Then it would be much help if you stripped down the script until the corruption disappear. (Change parameters, uncomment SMDegrain internals). This is how I would start.
Does it happen when you convert your source and not using dgi?

Post edited and DGIs inserted.

Please look original thread and see all the trials I did.

Will try to strip down things. As far as I remember, I could even use prefilter 2 instead of 4 or x86 vs x64 and nothing changed.

[pinterf]

I started making some changes to the documentation and need some opinions. Here's the difference between the two: http://diff.pics/JbQx0fvGOTeM/1

I added a syntax and parameters section and I also highlighted the syntax and listed all the parameters and their descriptions. I would like to do this to all the internal filters. Yea or nay?
Yes. And a big thanks for dealing with the documentation which is usually the last one in the task queue, at least for the programmers point of view. :)

[pinterf]

Post edited and DGIs inserted.

Please look original thread and see all the trials I did.

Will try to strip down things. As far as I remember, I could even use prefilter 2 instead of 4 or x86 vs x64 and nothing changed.
Thank you for saving time for me. I run too much things parallel nowadays and each one is a challenge for me.

[tormento]

Thank you for saving time for me. I run too much things parallel nowadays and each one is a challenge for me.
Done encoding with any prefilter. Error occurs only with 4.

Uploaded resulting files.

[Groucho2004]

The more I think about it, the more I like the blank slate approach when it comes to how to go from here regarding AVS+.

In order to serve frames to a client, all that's needed is avisynth.dll and optionally a some (compatible) plugins in a directory. The user doesn't have to "install" Avisynth and switching between versions (and auto-load plugin directories) can be done in an instant without rebooting.
Considering this, re-compiling all compatible plugins catering for an all new interface shouldn't be such a big deal.
If a user really has to use some ancient plugin, he could just switch to the "official" AVS2.6.

[MysteryX]

Considering this, re-compiling all compatible plugins catering for an all new interface shouldn't be such a big deal.
Starting with RemoveGrain that was last compiled with VS2005

[Groucho2004]

Starting with RemoveGrain that was last compiled with VS2005Why? What's wrong with RGTools?

[ultim]

Everybody please, there is no need to point out that a conversion layer can be written. As described in #1770 (http://forum.doom9.org/showpost.php?p=1771292&postcount=1770), I know that the old interface can be worked around. But frankly, I will not invest my own time in developing and maintaining compatibility to something which we actually want to switch away from, once we switched away from it. I will not block such attempts, so if somebody comes up with working patches, I'll merge them. But those patches won't come from me.

As for accessing size_t members using int-functions: That will work in *most* cases, as long as plugins are well-behaved. Unfortunately, by some brain-dead decision in the early development of avs classic, the class members have been made public. Knowing the quality standards of many plugins, there is no guarantee that somebody does not access the fields directly, or maybe even create/dereference instances of VideoFrame objects. They shouldn't, most plugins probably don't, but this is a breaking change of the ABI, and I won't be doing code reviews of all plugins to determine which ones we broke and which ones we didn't.

It would be a different story if we had a central repository of all plugins in Git so that we can recompile them with a single click, as well as a package manager, so that if somebody updates the core, plugins will be updated automatically to the new interface. This was a GSoC-proposal once...

[ultim]

As pinterf is now an active contributor, I feel it is time to submit again an old problem I introduced months ago.

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I apply the following script, using AviSynth 2.6 MT, I have good encodings.

13HoursAV26.dgi (http://www76.zippyshare.com/v/rRxxLkBo/file.html)

SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)
ChangeFPS(last,last,true)
SetMTMode(2)
crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Result (http://www59.zippyshare.com/v/hIE3KfV0/file.html).

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

prefilter=1 (http://www62.zippyshare.com/v/HuSWnCqY/file.html) OK
prefilter=2 (http://www62.zippyshare.com/v/5NkG9ias/file.html) OK
prefilter=3 (http://www62.zippyshare.com/v/AXzb0Vqj/file.html) OK
prefilter=4 (http://www62.zippyshare.com/v/EU1MjUsM/file.html) CORRUPTION

Memento:

prefilter

[int: "-1", 0, 1, 2, 3, 4] or [clip: - ]

-1 = off (Default)
0 = light controlled gauss blur
1 = mild median/gauss blur
2 = strong median/gauss blur
3 = dfttest (spatial)
4 = KNLmeansCL (spatio-temporal GPU filter)
variable = prefiltered clip input variable

I have tried to use x86 version of AviSynth+, even DGIndexIM.

Results does not change.

The plugin versions I use are the following for both AviSynth and AviSynth+.

[Avisynth CPP 2.6 plugins]
D:\Programmi\media\AviSynth+\plugins64\KNLMeansCL-0.7.6.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MaskTools-2.1b1-tp7.dll (2.1.0.0)
D:\Programmi\media\AviSynth+\plugins64\MedianBlur2-0.94-tp7.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MVTools-2.7.0.22-pfmod.dll (2.7.0.22)
D:\Programmi\media\AviSynth+\plugins64\RgTools-0.92.1-tp7.dll (n/a)

[Avisynth CPP 2.5 plugins]
D:\Programmi\media\AviSynth+\plugins64\DFTTest-1.9.4.dll (1.9.4.0)
D:\Programmi\media\AviSynth+\plugins64\Dither-1.27.2.dll (n/a)

I can provide other movie examples too.

Ideas? Fixes?

P.S.: Previous post is here (http://forum.doom9.org/showthread.php?p=1739893#post1739893).

Instead of trying to find alternatives, I'd be happy if we found the bug.

Looking at the encodings, to me this looks like a clipping (overflow/underflow) bug, both at high and low pixel values. If that is true, once the binary filter causing this is isolated, the fix should be simple.

[tormento]

Instead of trying to find alternatives, I'd be happy if we found the bug.

Looking at the encodings, to me this looks like a clipping (overflow/underflow) bug, both at high and low pixel values. If that is true, once the binary filter causing this is isolated, the fix should be simple.

Prefilter=4 means KNLMeansCL and the belonging part of SMDegrain. The strange thing is that it happens only with AVS+

[ultim]

Prefilter=4 means KNLMeansCL and the belonging part of SMDegrain. The strange thing is that it happens only with AVS+

Not strange at all. It is with all likelyhood an internal filter in the Avs+ core. Most of those have been rewritten in Avs+ to get rid of inline assembly. And I do see SMDegrain making calls to internal functions along the prefilter=4 paths (too). KNLMeansCL might be the feature of prefilter=4, but I do not think this plugin is the cause of the problem.

[real.finder]

Not strange at all. It is with all likelyhood an internal filter in the Avs+ core. Most of those have been rewritten in Avs+ to get rid of inline assembly. And I do see SMDegrain making calls to internal functions along the prefilter=4 paths (too). KNLMeansCL might be the feature of prefilter=4, but I do not think this plugin is the cause of the problem.

I remember dogway say this happened if DGSourceIM + KNLMeansCL in the same script in avs+

[LigH]

... so are two different plugins using the same hardware for acceleration, therefore might switch hardware operation modes of graphic chips independently of each other, especially when working multi-threaded. There is little surprise that this may corrupt the video when the GPU gets reprogrammed to decode the next frame while filtering the previous.

[jpsdr]

Honestly, about interface, evolution does the job only half, to do thing properly to the end, i would have put all the pitch in ptrdiff_t. If you have to break existing things, break it for a full good purpose, not half. And also the Getpitch functions should return the same.
But, i agree about something. These critical datas shouldn't have been public, and should be accessed only via functions.

Well, personnaly, i would have done :

class VideoFrame {
public:
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const ptrdiff_t pitch;
const uint32_t row_size;
const int32_t height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const ptrdiff_t pitchUV;
const uint32t row_sizeUV;
const int32_t heightUV;

[tormento]

I remember dogway say this happened if DGSourceIM + KNLMeansCL in the same script in avs+

It happens with DGSource (NV) + KNLMeansCL too.

[tormento]

... so are two different plugins using the same hardware for acceleration, therefore might switch hardware operation modes of graphic chips independently of each other, especially when working multi-threaded. There is little surprise that this may corrupt the video when the GPU gets reprogrammed to decode the next frame while filtering the previous.

Ok and why only with AVS+ and not with AVS standard?

[ultim]

It happens with DGSource (NV) + KNLMeansCL too.

Can you provide a minimalistic script that reproduces the problem? Not with SMDegrain, but something without eval, without calling other scripts, without conditional code etc. As few lines as possible.

[tormento]

Can you provide a minimalistic script that reproduces the problem? Not with SMDegrain, but something without eval, without calling other scripts, without conditional code etc. As few lines as possible.



Sorry, not in my capabilities.

[DJATOM]

tormento

Avs+: r1841, MT-pfmod, x86
KNLMeansCL: http://rgho.st/6K5RRq2t8 (dunno how to check file version)
Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSourceIM", 3)
DGSourceIM("13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)
Results: http://screenshotcomparison.com/comparison/176528
Please ensure that your PC is not infected by viruses, then try my KNLMeansCL (32-bit dll).
I didn't tried to check this script on my PC, only on notebook.

[MysteryX]

tormento

Avs+: r1841, MT-pfmod, x86
KNLMeansCL: http://rgho.st/6K5RRq2t8 (dunno how to check file version)
Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSourceIM", 3)
DGSourceIM("13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)
Results: http://screenshotcomparison.com/comparison/176528
Please ensure that your PC is not infected by viruses, then try my KNLMeansCL (32-bit dll).
I didn't tried to check this script on my PC, only on notebook.
I've also been having issues with SMDegrain(prefilter=4) working terrible with MT; working faster with a single thread. I suppose this script will have the same problem.

[DJATOM]

Strange, but in avspmod x64 it only shows the first 800 pixels for height. Applying SMDegrain (with lsb) didn't change it, still 1920x800. 32-bit version works fine. Need to investigate.
Upd: made a new index and problem is fixed now (tested with avs+ r1873, x64; index made with DGIndexIM beta 50 X64). Still can't see any corruption :\

[tormento]

I've also been having issues with SMDegrain(prefilter=4) working terrible with MT; working faster with a single thread. I suppose this script will have the same problem.

Try to remove AVP.dll

[tormento]

Strange, but in avspmod x64 it only shows the first 800 pixels for height. Applying SMDegrain (with lsb) didn't change it, still 1920x800. 32-bit version works fine. Need to investigate.
Upd: made a new index and problem is fixed now (tested with avs+ r1873, x64; index made with DGIndexIM beta 50 X64). Still can't see any corruption :\

Just tried with DGIndexIM beta 50 x64 and I see the same corruption.

This is the script I used:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSourceIM", 3)
LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)

ChangeFPS(last,last,true)

Crop(0, 140, 0, -140)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Prefetch(8)

Have you tried a preview only or real encoding?

Are you under Windows 8 or 10?

[DJATOM]

Have you tried a preview only or real encoding?
Preview in avspmod.
Are you under Windows 8 or 10?
Windows 7 Ultimate.

[Reel.Deel]

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


I also cannot reproduce the corruption. I tried the script exactly as is. However, if I randomly seek multiple times back and forward to random spots it makes VDub freeze. The script finishes without problems in AvsMeter though. No problems in VDub's 'Run video analysis pass' also. What version of SMDegrain are you using? I'll do a bit more testing over the weekend.

I'm using Windows 7, with Windows 10 some problems have been reported:



FAQ

Q) I can't make DGNV and KNLmeansCL work together in avs script.
A) Post #650 (http://forum.doom9.org/showpost.php?p=1764345&postcount=650), Post #664 (http://forum.doom9.org/showpost.php?p=1766150&postcount=664).

[tormento]

Preview in avspmod.

Windows 7 Ultimate.

Problems arose with Windows 10, AFAIK.

Try to do a real encode.

[tormento]

What version of SMDegrain are you using? I'll do a bit more testing over the weekend.
Latest. To make it work with x64 I had to do little tunings for prefilter=2.
FAQ
Q) I can't make DGNV and KNLmeansCL work together in avs script.
A) Post #650, Post #664.
It works in a pure x64 environment. Moreover, the same behaviour happens with DGIndexIM.

P.S: I have tried AVSPmod_x64 in a pure x64 environment. Corruption happens in frame 24 and others.

Thanks for reporting me that on obsolete ;) OS, it works. And, ABOVE ALL, try it in a pure x64 environment.

[DJATOM]

Problems arose with Windows 10, AFAIK.

Try to do a real encode.

http://www114.zippyshare.com/v/zj9xTEWa/file.html

[tormento]

http://www114.zippyshare.com/v/zj9xTEWa/file.html



Not windows 10

[DJATOM]

Indeed, I just don't want to use the worst OS ever.

[tormento]

indeed, i just don't want to use the worst os ever.

omg lol

[pinterf]

Artifact hunting mode ON

Reproduced.

Converted the .h264 into mp4 with ffmpeg because I couldn't get work any dgdecxxx.

Find my input source here (http://www.mediafire.com/download/1ybcg1ocpccvfjv/13HoursCUT.mp4)

Script:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


Let's edit SMDegrain.avsi.
We remove and simplify the non-relevant lines (assuming the SMDegrain calling parameters)

So we replace the whole
pref=eval(""" ......
""")
part with

NL_in = input8.Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),\
StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))
Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

#PF remark:
# We created a big image, assuming that U and V is half the height in YV12
# Y8:
# Y_msb U_msb
# Y_msb V_msb
# Y_lsb U_lsb
# Y_lsb V_lsb

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU") # D=0/1 nochange GPU/CPU:nochange

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

pref=YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))


Ok. Now let's comment out the KNLMeansCL call.
Y8=Y8#.KNLMeansCL(D=1,A=1,h=7.0,lsb_inout=true,device_type="GPU")

No more artifact.

I don't know how KNLMeans work but the idea that all planes are stuffed into one greyscale image and is sent to the plugin may fail sometimes.

Now I really wonder why only avs+ is affected.

[Reel.Deel]

I don't know how KNLMeans work but the idea that all planes are stuffed into one greyscale image and is sent to the plugin may fail sometimes.

Now I really wonder why only avs+ is affected.

I think the script is doing that because KNLMeansCl does not process chroma unless the input format is YV24 or RGB. I wonder why Dogway didn't separate the planes, process them indivdually, and then merge them? :confused:

I wish I could help but I still cannot reproduce the corruption even with the simplified script. :/

Are you using Windows 10?

[pinterf]

No, Win7Prof.
Built a special avisynth.dll in which I switched off SSE3 and newer cpuid detection but the problem remained.

[pinterf]

O.K.

Still smdegrain.avsi, Dither_Luma_Rebuild

Replaced the line with 56064 (219*256) with 61184 (239*256)
(and the 219 with 239 but it does not play now).
The artifact disappeared.

There is another thing that may not be intentional:
String(lsb?65536:255)
For me 65535 would be more logical, but I'm far from fluently reading the avisynth expression syntax :)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
lsb_in = Default( lsb_in ,false)
lsb_out = Default( lsb_out ,false)
lsb = Default( lsb ,lsb_in || lsb_out)
mode = Default( mode ,6)
uv = Default(uv, 3)
s0 = Default(s0, 2.0)
c = Default(c, 1.0/16)
ampn = Default(ampn, 0.0)
slice = Default(slice, true)

k = (s0 - 1) * c
t = lsb_in ? "x 4096 - 61184 / 0 1 clip" : "x 16 - 239 / 0 1 clip"
# t = lsb_in ? "x 4096 - 56064 / 0 1 clip" : "x 16 - 219 / 0 1 clip"
e = String(k)+" "+String(1+c)+" "+String((1+c)*c)+" "+t+" "+String(c)
\ +" + / - * "+t+" 1 "+String(k)+" - * + "+String(lsb?65536:255)+" *"
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=e,expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=e,expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
mt_lut (yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)
lsb_out ? last : (lsb ? Ditherpost(mode=mode,ampn=ampn,slice=slice,staticnoise=ampn!=0.0?true:false,u=uv,v=uv) : last)}

I don't know what is the right constant there, the creators of this script can correct it for the right value.

[pinterf]

Or 220*256-1? instead of 219*256? Anyway it can be different rounding in evaluation than in classic avisynth?

[Reel.Deel]

Have you look at cretindesalpes original script: http://forum.doom9.org/showthread.php?p=1548318#post1548318

[real.finder]

this with TV_range bool http://pastebin.com/vz6Ewuvv


SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
# In a more lucid state I could probably have laid out this block much better... or not...
NL_in = Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))

Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

prefilter4 = YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))


try first

SMDegrain (tr=4,PreFilter=prefilter4,TV_range=false,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


then try

SMDegrain (tr=4,PreFilter=prefilter4.SmoothCustom16("Y>60160?y:y","u>61440?u:u","v>61440?v:v",limiter=true),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


and

SMDegrain (tr=4,PreFilter=prefilter4.Ditherpost(mode=6,ampn=0.0,staticnoise=false).Limiter(),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

[LigH]

There is another thing that may not be intentional:
String(lsb?65536:255)
For me 65535 would be more logical, but I'm far from fluently reading the avisynth expression syntax :)

The typical "ternary operator" (boolean_expression ? true_case_result : false_case_result)... inside a function of a C-like language, you could expand this to:

if(lsb) return String(65536); else return String(255);

[Chikuzen]

@ultim or someone

I have a question about multi-threading.

Is it possible to implement a temporal IIR filter as MT_NICE_FILTER ?

[real.finder]

The typical "ternary operator" (boolean_expression ? true_case_result : false_case_result)... inside a function of a C-like language, you could expand this to:

if(lsb) return String(65536); else return String(255);

he mean the value, 65536 is full 16 bit range, 256 is full 8 bit range, so he say that it should (65536 -1) like (256 -1)

[MysteryX]

DitherTools isn't working well with MT.

Try this script repeatedly and it will crash in dither.dll, when all dither functions are set to either MT=1 or 2

Dither_convert_8_to_16()
SMDegrain(thsad=200, prefilter=2, lsb_in=true, lsb_out=true)
DitherPost(mode=6)
Prefetch(8)


A solution I found is to set DitherPost to MT mode 3. However, it then causes a severe slowdown when using SMDegrain(prefilter=4) where performance goes from 2.2 to 1.6fps.

Without setting DitherPost to MT mode 3, I can't get rid of the crashes, so it would be nice for someone to investigate.

[LigH]

Issues with DitherPost have been reported before; I remember the statement that it is sufficient to limit one function of this family if there are several dither function used, may not matter much which of them...

[Groucho2004]

DitherTools isn't working well with MT.
Do you have avstp.dll in your auto-load directory? If so, remove it and try again.

[MysteryX]

Do you have avstp.dll in your auto-load directory? If so, remove it and try again.
No I don't have that

[jpsdr]

@ultim or someone

I have a question about multi-threading.

Is it possible to implement a temporal IIR filter as MT_NICE_FILTER ?

I am affraid you have to be MT_SERIALIZED with this kind of filter, you can't even be MT_MULTI_INSTANCE. At least, from what i've understood.
But there is also a MT_MODE_COUNT, i don't know what it does.

[MysteryX]

Here's another bug. I tried using Deshaker.
http://www.guthspot.se/video/deshaker.htm

Here's a script that will run the first pass and generate a log file to be used for the second pass.

P="Encoder\"
LoadVirtualDubPlugin(P+"deshaker.vdf", "deshaker", preroll=0)
LoadPlugin(P+"LSMASHSource.dll")
file="Source.MOV"
LWLibavVideoSource(file, cache=True)
ConvertToRGB32()
deshaker("19|1|30|4|1|0|1|0|640|640|1|2|1000|1000|1000|1000|4|1|3|2|8|30|300|4|Preview_Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|0|0|30|30|0|0|0|0|1|0|0|10|1000|1|88|1|1|20|5000|100|20|1|0")
PointResize(8,8)


To run the second pass, re-insert the deshaker line in your full script wherever you want and change the 2nd argument from 1 to 2 to run the 2nd pass from that log file.

With AviSynth 2.6 it works fine. With AviSynth+, I get a crash in the destructor. Whenever I close the preview I get a crash.

Deshaker doesn't seem to work with MT but a single thread tops all 8 CPU cores anyway.

[MysteryX]

The VD plugin bug seems easy to fix so I thought I might take a look myself. Trying to compile AVS+ in VS2015, however, there is this error: redefinition of 'y'. This code really doesn't look right... it's using y for the loop and redefining y twice more within the loop. Pinterf I'll let you look into that one.

For now I'll rename the 2 redefinitions as y2.


static void af_horizontal_yuy2_c(BYTE* p, int height, int pitch, int width, int amount) {
const int center_weight = amount*2;
const int outer_weight = 32768-amount;
for (int y = height; y>0; --y)
{
BYTE yy = p[0];
BYTE uv = p[1];
BYTE vu = p[3];
int x;
for (x = 0; x < width-2; ++x)
{
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
BYTE w = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+5]) * outer_weight);
uv = vu;
vu = p[x*2+1];
p[x*2+1] = w;
}
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
p[x*2+1] = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+1]) * outer_weight);
p[x*2+2] = ScaledPixelClip(p[x*2+2] * center_weight + (yy + p[x*2+2]) * outer_weight);
p[x*2+3] = ScaledPixelClip(p[x*2+3] * center_weight + (vu + p[x*2+3]) * outer_weight);

p += pitch;
}
}

[MysteryX]

The VDub destructor bug isn't so easy to fix; but shouldn't be hard for someone who understands the code better.


// VDubFilter.cpp
void CallEndProc() {
if (fd->endProc) {
int result = fd->endProc(&fa, &g_filterFuncs);
if (result != 0) {
throw AvisynthError("VirtualdubFilterProxy: error calling endProc");
}
}
}


Basically, Deshaker's EndProc is trying to access "something" within fa that is no longer accessible at that time.

Commenting both of these lines does solve the problem, but I doubt it is the right fix

// in FilterAdd
fm->env->AtExit(FreeFilterDefinition, fd);

// in LoadVirtualdubPlugin
env->AtExit(FreeFilterModule, fm);


The destructor needs to be called before these 2 functions.

I'll let you fix it before I start adding a "release timer" to fix the sequence :)

[pinterf]

For now I'll rename the 2 redefinitions as y2.

In my source it is fixed already in focus.cpp.
https://github.com/pinterf/AviSynthPlus/blob/MT-pfmod/avs_core/filters/focus.cpp
Which branch or version are you working on?

[Groucho2004]

Trying to compile AVS+ in VS2015, however, there is this error: redefinition of 'y'.

static void af_horizontal_yuy2_c(BYTE* p, int height, int pitch, int width, int amount) {
const int center_weight = amount*2;
const int outer_weight = 32768-amount;
for (int y = height; y>0; --y)
{
BYTE yy = p[0];
BYTE uv = p[1];
BYTE vu = p[3];
int x;
for (x = 0; x < width-2; ++x)
{
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
BYTE w = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+5]) * outer_weight);
uv = vu;
vu = p[x*2+1];
p[x*2+1] = w;
}
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
p[x*2+1] = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+1]) * outer_weight);
p[x*2+2] = ScaledPixelClip(p[x*2+2] * center_weight + (yy + p[x*2+2]) * outer_weight);
p[x*2+3] = ScaledPixelClip(p[x*2+3] * center_weight + (vu + p[x*2+3]) * outer_weight);

p += pitch;
}
}

Earlier compilers didn't complain about re-definitions if they had a different scope. That led to sloppy programming.
The above function is just horrible, it also defines a variable with different types (BYTE y, int y).

[pinterf]

The VDub destructor bug isn't so easy to fix; but shouldn't be hard for someone who understands the code better.


// VDubFilter.cpp
void CallEndProc() {
if (fd->endProc) {
int result = fd->endProc(&fa, &g_filterFuncs);
if (result != 0) {
throw AvisynthError("VirtualdubFilterProxy: error calling endProc");
}
}
}


Basically, Deshaker's EndProc is trying to access "something" within fa that is no longer accessible at that time.

Commenting both of these lines does solve the problem, but I doubt it is the right fix

// in FilterAdd
fm->env->AtExit(FreeFilterDefinition, fd);

// in LoadVirtualdubPlugin
env->AtExit(FreeFilterModule, fm);


The destructor needs to be called before these 2 functions.

I'll let you fix it before I start adding a "release timer" to fix the sequence :)
Did you checked the last commit? It is not yet in the last pfmod release, there were changes integrated from classic avs regarding "Fix VDub plugin race on cleanup"

[MysteryX]

Pinterf, I took your branch.

The destruction sequence is the problem. This is something to be very careful about so it's better if I don't touch it; it touches the core of AVS and will affect every plugin.


ScriptEnvironment::~ScriptEnvironment() {

closing = true;

// Before we start to pull the world apart
// give every one their last wish.
at_exit.Execute(this);


Here it wants to execute these functions before pulling the world apart, and with VDubFilter we must call the destructor before calling these functions.

[MysteryX]

Did you checked the last commit? It is not yet in the last pfmod release, there were changes integrated from classic avs regarding "Fix VDub plugin race on cleanup"
I see, I forgot to manually select the right branch after downloading the code.

Now it compiles fine right away. The VDub bug is still the same. Good luck Pinterf.

[pinterf]

Let's look at this silly code fragment
lsmashvideosource(film, stacked=true, format="YUV444P16")
# Open Prores422 10 bit as YUV444P16
ConvertStackedToNative()
Spline64Resize(400,300)
Crop(9,7,-9,-7)
FlipHorizontal().FlipVertical()
TurnLeft().TurnRight().Turn180()
PointResize(3200,2400)
GrayScale()
BilinearResize(1600,1200)
ConvertNativeToStacked()
source1=last
...

Nothing special, we are in 2016, UHD era, with 14-16 bit linear uncompressed raw in cameras. I was a bit surprized when this very basic 16 bit workflow started to work on my bench. Funny last minute techdemo from Avisynth. A kind of Second Reality :)
For everything else there's DitherTools.

[Chikuzen]

lsmashvideosource(film, stacked=false, format="YUV444P16")
# Open Prores422 10 bit as YUV444P16
Spline64Resize(400,300)
...


Why do you take a side trip and waste your time?
You can open the source as NativeFormat:p

[LigH]

A kind of Second Reality :)

You might know that Smash Designs created a C=64 version of the Future Crew PC VGA demo. Maybe that's how we used to feel with only 8 bits per component... ;)

[real.finder]

lsmashvideosource(film, stacked=false, format="YUV444P16", dr=true)
# Open Prores422 10 bit as YUV444P16
Spline64Resize(400,300)
...


Why do you take a side trip and waste your time?
You can open the source as NativeFormat:p

We discussed this in #avs-plus@irc.rizon.net

Currently lsmashvideosource without stacked will out in interleavexbit not in NativeFormat, so this will need something like ConvertInterleaved16ToNative() and ConvertNativeToInterleaved16()

Interleaved16 will be like the clip that out from dither_out()

more clearly details in flash3kyuu_deband.txt, input_mode and output_mode and stacked bool in f3kdb_dither

[MysteryX]

VDub destructor crash fixed

Fixed crash on exit due to FreeFilterModule being called before VirtualdubFilterProxy's destructor

diff --git a/plugins/VDubFilter/VDubFilter.cpp b/plugins/VDubFilter/VDubFilter.cpp
index df512ee..7d97fef 100644
--- a/plugins/VDubFilter/VDubFilter.cpp
+++ b/plugins/VDubFilter/VDubFilter.cpp
@@ -365,10 +365,11 @@ typedef struct FilterDefinition {

class FilterDefinitionList {
public:
+ FilterModule* fm;
FilterDefinition* fd;
FilterDefinitionList* fdl;

- FilterDefinitionList(FilterModule* fm, FilterDefinition* _fd) : fd(_fd), fdl(fm->fdl) { };
+ FilterDefinitionList(FilterModule* _fm, FilterDefinition* _fd) : fm(_fm), fd(_fd), fdl(fm->fdl) { };
};

//////////
@@ -575,6 +576,7 @@ public:
class VirtualdubFilterProxy : public GenericVideoFilter {
PVideoFrame src, dst, last;
VFBitmap vbSrc, vbDst, vbLast;
+ FilterDefinitionList* const fdl;
FilterDefinition* const fd;
FilterStateInfo fsi;
FilterActivation fa;
@@ -602,9 +604,11 @@ class VirtualdubFilterProxy : public GenericVideoFilter {
}

public:
- VirtualdubFilterProxy(PClip _child, FilterDefinition* _fd, AVSValue args, IScriptEnvironment* env)
- : GenericVideoFilter(_child), fd(_fd), fa(vbDst, vbSrc, &vbLast)
+ VirtualdubFilterProxy(PClip _child, FilterDefinitionList* _fdl, AVSValue args, IScriptEnvironment* env)
+ : GenericVideoFilter(_child), fdl(_fdl), fd(_fdl->fd), fa(vbDst, vbSrc, &vbLast)
{
+ if (!fd)
+ env->ThrowError("VirtualdubFilterProxy: No FilterDefinition structure!");
if (!vi.IsRGB32())
throw AvisynthError("VirtualdubFilterProxy: only RGB32 supported for VirtualDub filters");

@@ -763,16 +767,29 @@ public:

~VirtualdubFilterProxy() {
CallEndProc();
+ FreeFilterModule(fdl->fm);
if (vbSrc.hdc)
ReleaseDC(NULL, vbSrc.hdc);
}

+ void __cdecl FreeFilterModule(FilterModule* fm) {
+ for (FilterDefinitionList* fdl = fm->fdl; fdl; fdl = fdl->fdl) {
+ delete fdl->fd;
+ fdl->fd = 0;
+ }
+
+ fm->deinitProc(fm, &g_filterFuncs);
+ FreeLibrary(fm->hInstModule);
+ if (fm->prev)
+ fm->prev->next = fm->next;
+ if (fm->next)
+ fm->next->prev = fm->prev;
+ delete fm;
+ }
+
static AVSValue __cdecl Create(AVSValue args, void* user_data, IScriptEnvironment* env) {
FilterDefinitionList* fdl = (FilterDefinitionList*)user_data;
-
- if (!fdl->fd) env->ThrowError("VirtualdubFilterProxy: No FilterDefinition structure!");
-
- return new VirtualdubFilterProxy(args[0].AsClip(), fdl->fd, args, env);
+ return new VirtualdubFilterProxy(args[0].AsClip(), fdl, args, env);
}
};

@@ -803,24 +820,6 @@ FilterDefinition *VDcall FilterAdd(FilterModule *fm, FilterDefinition *pfd, int
}


-void __cdecl FreeFilterModule(void* user_data, IScriptEnvironment* env) {
- FilterModule* fm = (FilterModule*)user_data;
-
- for (FilterDefinitionList* fdl = fm->fdl; fdl; fdl = fdl->fdl) {
- delete fdl->fd;
- fdl->fd = 0;
- }
-
- fm->deinitProc(fm, &g_filterFuncs);
- FreeLibrary(fm->hInstModule);
- if (fm->prev)
- fm->prev->next = fm->next;
- if (fm->next)
- fm->next->prev = fm->prev;
- delete fm;
-}
-
-
AVSValue __cdecl LoadVirtualdubPlugin(AVSValue args, void*, IScriptEnvironment* env) {
const char* const szModule = args[0].AsString();
const char* const avisynth_function_name = args[1].AsString();
@@ -879,7 +878,6 @@ AVSValue __cdecl LoadVirtualdubPlugin(AVSValue args, void*, IScriptEnvironment*
fm->next->prev = fm;

env->SetGlobalVar("$LoadVirtualdubPlugin$", (const char*)fm);
- env->AtExit(FreeFilterModule, fm);

return AVSValue();
}


Git isn't allowing me to push the changes; is there something I'm doing wrong or you just have to add those changes yourself?

git.exe push -v --progress "origin" master:MT-pfmod

remote: Permission to pinterf/AviSynthPlus.git denied to mysteryx93.
fatal: unable to access 'https://github.com/pinterf/AviSynthPlus.git/': The requested URL returned error: 403
Pushing to https://github.com/pinterf/AviSynthPlus.git

[qyot27]

Git isn't allowing me to push the changes; is there something I'm doing wrong or you just have to add those changes yourself?

git.exe push -v --progress "origin" master:MT-pfmod

remote: Permission to pinterf/AviSynthPlus.git denied to mysteryx93.
fatal: unable to access 'https://github.com/pinterf/AviSynthPlus.git/': The requested URL returned error: 403
Pushing to https://github.com/pinterf/AviSynthPlus.git

You have to have your own account on Github, use Github's tools* to spawn your own AviSynthPlus repo, and then push up to your own account. You can then open a pull request through Github to have the change integrated.

*well, technically you don't need to use Github's tools to do it so long as the SSH remotes are correct and you've authenticated your keys on your Github account, but it won't show up on the Network graph.

[MysteryX]

You have to have your own account on Github, use Github's tools* to spawn your own AviSynthPlus repo, and then push up to your own account. You can then open a pull request through Github to have the change integrated.

*well, technically you don't need to use Github's tools to do it so long as the SSH remotes are correct and you've authenticated your keys on your Github account, but it won't show up on the Network graph.
OK I created a new Fork into my account, but MT-pfmod doesn't show up in the list of branches

[qyot27]

OK I created a new Fork into my account, but MT-pfmod doesn't show up in the list of branches
This is where git's remotes come in:
git remote add pinterf git://github.com/pinterf/AviSynthPlus.git
git fetch pinterf
git checkout MT-pfmod (or git checkout -b MT-pfmod pinterf/MT-pfmod if it doesn't let you do it with just the branch name)

[tormento]

@pinterf

So, it is a bug of AVS+ you will fix or a bug of the script that appears in AVS+ only? :)

[jpsdr]

VDub destructor crash fixed
....


I hope Wilbert follow this thread, because maybe this issue is also in standard avisynth 2.6, and this fix should also be include within.

[MysteryX]

This is where git's remotes come in:
git remote add pinterf git://github.com/pinterf/AviSynthPlus.git
git fetch pinterf
git checkout MT-pfmod (or git checkout -b MT-pfmod pinterf/MT-pfmod if it doesn't let you do it with just the branch name)
Ah! After toying around with it, I finally got it. There you go Pinterf, you can merge the changes with a single click :)

[Wilbert]

Here's another bug. I tried using Deshaker.
http://www.guthspot.se/video/deshaker.htm

Here's a script that will run the first pass and generate a log file to be used for the second pass.

P="Encoder\"
LoadVirtualDubPlugin(P+"deshaker.vdf", "deshaker", preroll=0)
LoadPlugin(P+"LSMASHSource.dll")
file="Source.MOV"
LWLibavVideoSource(file, cache=True)
ConvertToRGB32()
deshaker("19|1|30|4|1|0|1|0|640|640|1|2|1000|1000|1000|1000|4|1|3|2|8|30|300|4|Preview_Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|0|0|30|30|0|0|0|0|1|0|0|10|1000|1|88|1|1|20|5000|100|20|1|0")
PointResize(8,8)


To run the second pass, re-insert the deshaker line in your full script wherever you want and change the 2nd argument from 1 to 2 to run the 2nd pass from that log file.

With AviSynth 2.6 it works fine. With AviSynth+, I get a crash in the destructor. Whenever I close the preview I get a crash.

Deshaker doesn't seem to work with MT but a single thread tops all 8 CPU cores anyway.
Could you give a link to an AviSynth+ version where this results in a crash?

[MysteryX]

Could you give a link to an AviSynth+ version where this results in a crash?
I'm using Pinterf's latest version. I fixed the crash already and the changes have been merged into MT-pfmod branch

[ryrynz]

Next build will be official?

[Wilbert]

I'm not able to crash AviSynth v2.61a1 like you do with Deshaker, but it hasn't your changes. If i close VirtualDub during or at the end of the second pass it just exists without crashing.

avsplus-r1858-pfmod doesn't have the fix right? If i install the XP_x86 (yes still running that on my laptop) and run Version.avs it complains: 'AVI Import Filter error'. Anyone?

Guess i need to turn my pc on and try again.

[MysteryX]

v2.6 works fine, only AVS+ crashes.

The fix is here
https://github.com/pinterf/AviSynthPlus/pull/4/commits/78efa4e1dfbee153b05b669f9cacacb7b7661f37

If you want the updated VDubFilter.dll now (x86), I uploaded it here (https://mega.nz/#!DYJhwCqZ!fSc2UcKWynczGCIYaAJGi1jq75oLb6rKBnutpGhk0Y0) (compiled with VS2015)

Deshaker is complicated to use; so that's a good reason to integrate it into my Media Encoder software

[Wilbert]

Let me reword it. I don't understand why it crashed in AVS+ and it works fine in v2.61a1. I guess it must have something to do with VDubFilter being a plugin in AVS+ and part of the core in v2.61a1?

@pinterf, any ideas?

[MysteryX]

The plugin code has been altered since v2.6. Just looking at the code history, there has been quite a few changes over time.

[pinterf]

@Wilbert: no idea, nor have I deeper insight on this area

[ultim]

Next build will be official?

pinterf and I will consult (it seems we might be able to do that IRL), and his changes will be merged. Until then, just overwrite the avisynth dll from the official installer package with pinterf's version, there is nothing wrong with doing that.

[Wilbert]

@pinterf,

I can't get your fork to work: https://github.com/pinterf/AviSynthPlus/releases (x86).
I copied your dll over the regular avisynth+ version (AviSynthPlus-r1576.exe). The regular version works fine, but when overwriting it by your dll i get 'AVI Import Filter error' when opening Version.avs in 32-bit Virtualdub (Win7).

edit: Guess i needed Microsoft Visual C++ 2015 Redistributable.

[pinterf]

@pinterf,

I can't get your fork to work: https://github.com/pinterf/AviSynthPlus/releases (x86).
I copied your dll over the regular avisynth+ version (AviSynthPlus-r1576.exe). The regular version works fine, but when overwriting it by your dll i get 'AVI Import Filter error' when opening Version.avs in 32-bit Virtualdub (Win7).
Do you have VS 2015 Redistributables installed?
edit: I see, O.K. - at least I found again where my virtualdub folder is :)

[pinterf]

@pinterf

So, it is a bug of AVS+ you will fix or a bug of the script that appears in AVS+ only? :)
Still couldn't identify which part works differently, but the modified SMDegrain script (http://forum.doom9.org/showthread.php?p=1771735#post1771735) with TV_range parameter solves the problem (does not call rebuild luma if TV_range false)

[pinterf]

this with TV_range bool http://pastebin.com/vz6Ewuvv

try first

SMDegrain (tr=4,PreFilter=prefilter4,TV_range=false,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


then try

SMDegrain (tr=4,PreFilter=prefilter4.SmoothCustom16("Y>60160?y:y","u>61440?u:u","v>61440?v:v",limiter=true),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


and

SMDegrain (tr=4,PreFilter=prefilter4.Ditherpost(mode=6,ampn=0.0,staticnoise=false).Limiter(),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

The one with the new TV_range=true parameter is O.K.
The other two clips are corrupted.
What is the conclusion? The second method receives a limited prefiltered clip, still it shows garbage

[tormento]

Still couldn't identify which part works differently, but the modified SMDegrain script (http://forum.doom9.org/showthread.php?p=1771735#post1771735) with TV_range parameter solves the problem (does not call rebuild luma if TV_range false)



Ok... Anyway understanding why AVS+ works differently would be better :)

What does that modified scripts do exactly? If reduces color range is no go...

[ultim]

It turns out pinterf and I live close to each other, so we took advantage of this and met up in person. We talked about many things, like introductions ofc, what we do for a living, how we got into Avisynth. We also looked at various parts of the code, some parts he still needed to look into, and others that I needed to refresh my own memory about. We also spoke about how important it is that when we get a bug report, we receive a sample video and a minimalistic script to reproduce it. We both felt compelled to point out that a script which has only two lines, but in one of them calls a multi-hundred-line script, is not minimal. We know there are a multiple things to improve and many wishes, but neither of us have the resources to make everything come true, so we need to aggressively prioritize.

pinterf has a lot of development experience, though he only recently started using C++, so he is still experimenting a lot. There are also some other things he's been working on, all related to Avisynth, so you can expect more goodies from him soon :) As for me, I have taken home a list of stuff for me to investigate/debug. I'd say once I catch up to this list, pinterf's changes, and Avs 2.6.1, I'll feel comfortable to do another release. Pinterf will probably release other builds earlier.

Of course we went into a lot more detail on each of these topics, but I think this gives you a basic overview of the things we talked about.

[LigH]

It turns out pinterf and I live close to each other, so we took advantage of this and met up in person.

Rare occasion... I hope you had http://cosgan.de/images/smilie/nahrung/a015.gif

[pinterf]

Rare occasion... I hope you had http://cosgan.de/images/smilie/nahrung/a015.gif

Cola vs Beer :)

[real.finder]

The one with the new TV_range=true parameter is O.K.
The other two clips are corrupted.
What is the conclusion? The second method receives a limited prefiltered clip, still it shows garbage

something in Dither_Luma_Rebuild not like avs+, did you try something else? like prefilter 1 and 2 and 3?

[tormento]

something in Dither_Luma_Rebuild not like avs+, did you try something else? like prefilter 1 and 2 and 3?

Only prefilter=4 (knl) gives corruption.

[real.finder]

Only prefilter=4 (knl) gives corruption.

try this then


SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
# In a more lucid state I could probably have laid out this block much better... or not...
NL_in = Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))

Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

prefilter4 = YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))

SMDegrain (tr=4,PreFilter=prefilter4.SmoothLevels16(preset="tv2pc"),TV_range=false,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


+ this one http://pastebin.com/JtWFN124 (not tested enough)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=false,mode=6)
Prefetch(8)

yes, use it with no lsb for testing purpose

[tormento]

try this then

+ this one http://pastebin.com/JtWFN124 (not tested enough)



Both works. No corruption.

[pinterf]

Weird.

Replaced the one-pass combined YUV KNLMeans path

NL_in = Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))

Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

prefilter4 = YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))


With a 3 pass KNLMeans path (distinct Y, U, V)

NL_in = Dither_convert_8_to_16()
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
Y8 = ConvertToY8(NL_in)
U16 = U8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
V16 = V8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
Y16 = ConvertToY8(NL_in).KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
prefilter4 = YToUV(u16,v16,Y16)

Result is:
KNLMeansCL: fatal error!

No MT.

Then I tried with different avisynth DLLs I have:
Classic AVS 2.6: no error
Avisynth+ r1576: no error
From Avisynth r1689 on: KNLMeansCL: fatal error!

When omitting KNLMeans calculation for clip V16, it works again.
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
Y8 = ConvertToY8(NL_in)
U16 = U8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
V16 = U16 #V8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
Y16 = ConvertToY8(NL_in).KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
prefilter4 = YToUV(u16,v16,Y16)

Could you try if it works or not for you?

[MysteryX]

Ultim, Pinter said that making AviSynth+ cross-platform-compatible wasn't his area of expertise and someone would have to do that. Is that something you'll handle or we'll have to wait until someone else volunteers?

[tormento]

When omitting KNLMeans calculation for clip V16, it works again.
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
Y8 = ConvertToY8(NL_in)
U16 = U8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
V16 = U16 #V8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
Y16 = ConvertToY8(NL_in).KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")
prefilter4 = YToUV(u16,v16,Y16)

Could you try if it works or not for you?

Works.

P.S: When I say it "works", it is corruption related. I am not doing any analysis about quality of output.

[pinterf]

Works.

P.S: When I say it "works", it is corruption related. I am not doing any analysis about quality of output.

Just to make sure, I suppose you tried with the non-uncommented V16 line (the quote is the commented one)?

[tormento]

Just to make sure, I suppose you tried with the non-uncommented V16 line (the quote is the commented one)?

The "works" is for the commented one.

The uncommented works with Prefetch(6) instead of Prefetch(8) because otherwise GPU memory requirements goes beyond my 2GB card.

[Groucho2004]

@tormento, pinterf
You guys realize that using Prefetch(8) will use 8 times the GPU memory, right? I ran a little test and ran out of memory at Prefetch(4). I do however only have 1G graphics memory.

Use AVSMeter with the -gpu switch to check GPU memory usage.

When you run out of GPU memory you'll get this:
KNLMeansCL: fatal error! (AviSynthGetFrame)

[tormento]

Use AVSMeter with the -gpu switch to check GPU memory usage.

When you run out of GPU memory you'll get this:
KNLMeansCL: fatal error! (AviSynthGetFrame)

You are right. I have 2 GB on my GPU and the "uncommented script" with Prefetch(6) works, with following stats:

[Runtime info]
Frames processed: 107 (0 - 106)
FPS (min | max | average): 0.362 | 830086 | 8.244
Memory usage (phys | virt): 1272 | 2775 MiB
Thread count: 171
CPU usage (average): 54%
GPU usage (average): 29%
Video engine load (average): 15%
GPU memory usage: 1741 MiB
Time (elapsed): 00:00:12.980

With Prefetch(8), it goes to 1920 MB and then KNL crashes.

[tormento]

Just to make sure, I suppose you tried with the non-uncommented V16 line (the quote is the commented one)?

As I wrote, the uncommented works with Prefetch(6) and no corruption too.

[pinterf]

@tormento, pinterf
You guys realize that using Prefetch(8) will use 8 times the GPU memory, right? I ran a little test and ran out of memory at Prefetch(4). I do however only have 1G graphics memory.

Use AVSMeter with the -gpu switch to check GPU memory usage.

When you run out of GPU memory you'll get this:
KNLMeansCL: fatal error! (AviSynthGetFrame)
No MT mode here

[MysteryX]

The author of KNLMeansCL explicitely recommended NOT to use MT with KNLMeans, and if you use, set it to MT mode=3. A single instance of it then gets created.

[pinterf]

Weird.

Replaced the one-pass combined YUV KNLMeans path
...
With a 3 pass KNLMeans path (distinct Y, U, V)

NL_in = Dither_convert_8_to_16()
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
Y8 = ConvertToY8(NL_in)
U16 = U8.KNLMeansCL(D=0, A=1, h=7.0,lsb_inout=true,device_type="GPU")
V16 = V8.KNLMeansCL(D=0, A=1, h=7.0,lsb_inout=true,device_type="GPU")
Y16 = ConvertToY8(NL_in).KNLMeansCL(D=0, A=1, h=7.0,lsb_inout=true,device_type="GPU")
prefilter4 = YToUV(u16,v16,Y16)


With D=0 it works. (tried before without success: GPU/CPU, lsb_inout=false,h=1.0)
Still no MT. Maybe we should pass the problem to the right forum.

[Groucho2004]

With D=0 it works. (tried before without success: GPU/CPU, lsb_inout=false,h=1.0)
Still no MT. Maybe we should pass the problem to the right forum.
"d=0" uses less gpu memory.
What graphics card do you have? How much memory? Have you tried monitoring the GPU memory usage?

[pinterf]

AMD 7570, 1G RAM. 385 MB Dedicated, 98 MB Dynamic.
With classic AVS and Avs+ 1576 there is no problem.

[tormento]

Still no MT. Maybe we should pass the problem to the right forum.

+1

Let's stay on image corruption topic.

[pinterf]

1.) Image corruption solved*

Avisynth.dll compiled for Debug has no corruption.
Release version has.

2.) KNLMeansCL fatal error (3*call in a sequence + SMDegrain) solved**

Avisynth.dll compiled for Debug has no fatal error.
Release version has.

Programmers' dream: debug the release.

*, **not solved

[tormento]

Avisynth.dll compiled for Debug has no corruption.
You mean you will release a fixed version soon? :cool:

[pinterf]

You mean you will release a fixed version soon? :cool:
Asked the Avisynth Plus Customer Service Center (APCSC) and they said: no.
They also said that the problem was a nice one, but they wished the solution process to their enemies.
Finally they said: yesofcoursewhynot.

[tormento]

Asked the Avisynth Plus Customer Service Center (APCSC) and they said: no.
They also said that the problem was a nice one, but they wished the solution process to their enemies.
Finally they said: yesofcoursewhynot.



LOL... It took months from my first post but... Hey... At last...

[pinterf]

Unfortunately I cannot issue a Prefetch(100) command to myself

[MysteryX]

Quick question. What's the difference between having a filter run in MT=1 with a unique_lock in GetFrame vs having a filter run in MT=3?

In both cases, there is a single instance and the work is sequential. With MT=3, it's always the same thread calling instead of each request coming from a different thread. Besides that, what's the difference?

[tormento]

Unfortunately I cannot issue a Prefetch(100) command to myself

It's great to have you here XD

[ultim]

EDIT: There is a newer version available in this post (http://forum.doom9.org/showthread.php?p=1772944#post1772944).

I have compiled a new build of Avisynth+ for testing, you can find it here (http://avs-plus.net/builds).
(To download all files at once, there is a "Download" button at the top right corner of the page)

This is r2003, and is built on top of the most up-to-date code for Avs+ as of now. It includes all the changes from Avisynth 2.6.1, all of pinterf's work, all code-related pull-requests sent to me, and some additional fixes from me. So it is pretty cutting edge ;) Let us know your experiences. Some notes to bear in mind:
- Important: This build breaks some plugins. If you are a regular user, you might not want this build. It it is for testing anyway.
- This was built with a new compiler (MSVS 2015 Update 3). You'll find corresponding runtimes that you must install first under the same link above. These will be included in the next installer.
- XP-support might not work, I cannot test it. Let me know and I'll try to correct it.
- ConvertStackedToNative/ConvertNativeToStacked have been renamed to ConvertHbdFromStacked/ConvertHbdToStacked (HBD = high bit-depth). These are transitional functions and exist to support old plugins which tried to hack around missing HBD support. We expect that these functions will not be needed in a year from now.
- The high bit-depth support is still provisional. Some important and useful functions for dealing with it are still missing.
- While testing, please keep an extra eye on the correctness of Resizers/Resamplers, mergers, and SoundTouch. Let us know if you see any problems.

Cheers.

[chainik_svp]

Quick question. What's the difference between having a filter run in MT=1 with a unique_lock in GetFrame vs having a filter run in MT=3?

order of the requested frames?
the filter working in mt=3 knows that it processes frames one-by-one so it's free to use some info from the previous frame(s) to process current one
a simple motion blur filter can be a good example

[ultim]

order of the requested frames?

When Prefetch() is used, the order of the frames requested in plugins is not guaranteed in any of the MT modes.

[ultim]

order of the requested frames?
the filter working in mt=3 knows that it processes frames one-by-one so it's free to use some info from the previous frame(s) to process current one
a simple motion blur filter can be a good example

mt=3 only guarantees that the code will not be executed in parallel, but frame requests might still arrive non-sequentially. For filters where this is a problem, Prefetch must not be enabled, but such filters are faulty.

Filters should request each frame they need every time they receive a request and must not try to "remember" frames on their own. This way filters do not depend on a specific order of requests. The caches in Avisynth will make sure that processing is still efficient by avoiding the re-calculation of frames that have been already requested in the recent past.

[qyot27]

- XP-support might not work, I cannot test it. Let me know and I'll try to correct it.
If the last time the VS2015 and XP issues cropped up is still true, it'll need /Zc:threadSafeInit- to work on XP. Dunno if that's the 'correct' thing to do, though.

[qyot27]

Also, for anyone wanting to experiment with native 16-bit output, here are FFmpeg and mpv builds that support opening 16-bit scripts:
http://www.mediafire.com/download/k7e2tb1yavu05tr/ffmpeg_r80789_avshbd.7z
http://www.mediafire.com/download/rsfawx6jjpd07tu/mpv_r43454_avshbd.7z

ConvertHbdFromStacked/ConvertHbdToStacked

are bad function names. You ask users to remember very strange word "Hdb", that is unknown in avisynth world and even in video software world. many-many users who use old plugins will have remember problems, and mistakes.

ConverFromStacked/ConvertToStacked is a very clean name.
'HBD' is a known abbreviation of 'High Bit Depth'. Although I suppose we could just tell people it stands for 'Here be dragons'. :P

[Reel.Deel]

I have compiled a new build of Avisynth+ for testing, you can find it here (http://avs-plus.net/builds).

With this simple script I get an error in VDub (64-bit works though):

ColorBarsHD()
Dither_convert_8_to_16()

Avisynth open failure:
System exception - Access Violation
(M:\AviSynth+ r2003 test\16-bit resizers.avs, line 2)


Edit: also the resizers are messed up, if I comment out the resizers then the output is correct, otherwise I get this (https://s33.postimg.org/yzcd6oldp/avisynth_hbd_test.png?dl=0).


ColorBarsHD(1280, 720)
Dither_convert_8_to_16()
ConvertHbdFromStacked()
Spline64Resize(400,300)
Crop(9,7,-9,-7)
FlipHorizontal().FlipVertical()
TurnLeft().TurnRight().Turn180()
PointResize(3200,2400)
GrayScale()
BilinearResize(1600,1200)
ConvertHbdToStacked()

[Groucho2004]

It is called HDR in a computer graphic world.
High Dynamic Range != High Bit Depth.

[qyot27]

With this simple script I get an error in VDub (64-bit works though):

ColorBarsHD()
Dither_convert_8_to_16()
Ditto here (32-bit Windows 10, Silvermont Z3735F). It seems to happen on any function after the first.

Version() by itself works. Version().ConvertToYV12() throws an Access Violation.

[Groucho2004]

Ditto here (32-bit Windows 10, Silvermont Z3735F). It seems to happen on any function after the first.

Version() by itself works. Version().ConvertToYV12() throws an Access Violation.
Ha, I thought it was a problem with WinXP. Getting clip properties or a simple colorbars() worked, anything further gave me an access violation in avisynth.dll with AVSMeter.
The build could still be incompatible with WinXP though...

[ultim]

High Dynamic Range != High Bit Depth.

Well said. High bit Depth is the ability to use more than 8-bits to represent finer color gradations, and (probably much more importantly) to present more correct processing results due to less errors in in-between operations.

HBD is basically a technical prerequisite of HDR. In addition to HBD, HDR allows to process color and brightness values outside of your limited display range. This usually means 1) using HBD to represent values outside of the valid displayable range, and 2) at the end some kind of tone mapping algorithm to bring it back down to valid pixel values. With HBD Avisynth+ can now do the first of part of HDR, for the second some kind of plugin to perform the tone mapping would be required.

About the naming: "Native" and "Stacked" are even less standardized than "HBD". AFAIK, "native" and "stacked" were invented in this community to give method names to an Avisynth-specific hack.

XP and crashes: Looking into it. I could run an MCTemporalDenoise script and some resizers before I uploaded.

[Groucho2004]

XP and crashes: Looking into it.Not just XP, see qyot27's post.

[qyot27]

About the naming: "Native" and "Stacked" are even less standardized than "HBD". AFAIK, "native" and "stacked" were invented in this community to give method names to an Avisynth-specific hack.
While we're on the subject, are there any plans to also have a convert function to handle the Interleaved16 format? That's actually the one I usually use when dithering up with f3kdb.

I mean, it's not like it's difficult to just switch from using output_mode=2 to using output_mode=1, but having the option would be nice.

[ultim]

I cannot reproduce any of the crashes. Tried 32-bits in VDub, AvsPmod, and AVSmeter, none of them crashed with any of the three scripts posted earlier. Did you guys install the new runtime?
I can however reproduce the corrupted output from the resizer using Reel.Deel's script. Also, I am adding the /Zc switch for XP.

[Reel.Deel]

Did you guys install the new runtime?


Yes, 1st thing I did.

Edit: the filters that have been updated to support HBD allow 16/32-bit, is there a way to specify what bit depth to use?

[qyot27]

Yup, I'd had VS2015 installed for a long while too, but switched back to VS2013 once pinterf really got going and I tried testing 64-bit because Wine didn't like VS2015 binaries. But I did go ahead and install the runtime again, just in case.

And I can also reproduce with my own VS2013 builds, so VS2015 miscompiling it isn't a factor here.

[ultim]

Fixes for the resizer corruption (it only affected some HBD formats) and XP support are on GitHub. I will publish a new build tomorrow, assuming I get a handle on the crashes, because I haven't been able to reproduce them yet. Help appreciated in making them reproducible.

[Reel.Deel]

Help appreciated in making them reproducible.

Found something odd, If use BlankClip().TurnLeft() it works, but if I use it like the example below it gives me the access violation error.


BlankClip()
TurnLeft()

Error from AVSMeter:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Unknown module
Address: 0x00000001

[Groucho2004]

Found something odd, If use BlankClip().TurnLeft() it works, but if I use it like the example below it gives me the access violation error.


BlankClip()
TurnLeft()

Error from AVSMeter:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Unknown module
Address: 0x00000001

The "Unknown module" is probably avisynth.dll but access may be restricted. Do you have UAC enabled? Run AVSMeter as admin.

[Reel.Deel]

The "Unknown module" is probably avisynth.dll but access may be restricted. Do you have UAC enabled?

I have UAC disabled, turned it on but it gives the same error. I was using AVSMeter 2.2.8 , update to 2.2.9 and now it gives the "AVSMeter - Avisynth Script Testing has stopped working". Here's the details:

Problem signature:
Problem Event Name: BEX
Application Name: AVSMeter.exe
Application Version: 2.2.9.0
Application Timestamp: 5776dcf1
Fault Module Name: StackHash_0a9e
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset: 00000001
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

Run AVSMeter as admin.

Without loading a script, if I right click AVSMeter.exe, run as admin I get the error above, same as without run as admin. 64-bit works fine.

Edit: works fine in Avs+ r1576 and Avs 2.6.1. Any other Avs+ version, same error. Tested all the way down to r1828.

[Groucho2004]

I have UAC disabled, turned it on but it gives the same error. I was using AVSMeter 2.2.8 , update to 2.2.9 and now it gives the "AVSMeter - Avisynth Script Testing has stopped working". Here's the details:
Fault Module Name: StackHash_0a9e
Haven't seen that before. I assume this only happens with this particular Avisynth version?

[Groucho2004]

works fine in Avs+ r1576 and Avs 2.6.1. Any other Avs+ version, same error. Tested all the way down to r1828.So this only happens with the latest version of AVSMeter?

[Reel.Deel]

So this only happens with the latest version of AVSMeter?

Correct.

[Groucho2004]

Without loading a script, if I right click AVSMeter.exe, run as admin I get the error above, same as without run as admin. 64-bit works fine.

Edit: works fine in Avs+ r1576 and Avs 2.6.1. Any other Avs+ version, same error. Tested all the way down to r1828.
Unfortunately, I can't reproduce this. Could you please try this test build (https://www.dropbox.com/s/y1ut2ofuap8yuoa/AVSMeter.7z?dl=0)?

[Reel.Deel]

Unfortunately, I can't reproduce this. Could you please try this test build (https://www.dropbox.com/s/y1ut2ofuap8yuoa/AVSMeter.7z?dl=0)?

No I get the same error as in post #1931, with or without a script.

[Groucho2004]

No I get the same error as in post #1931, with or without a script.
So, the same as 2.2.8, right?

[Reel.Deel]

So, the same as 2.2.8, right?

Yes. I reverted back to pinterf's r1858, run AVSMeter test build and now I get "bad array new length". Could this have something to do with updating to MS redistributable 2015 update 3? I see that update 2 is gone from the programs list.

[Groucho2004]

Yes. I reverted back to pinterf's r1858, run AVSMeter test build and now I get "bad array new length". Could this have something to do with updating to MS redistributable 2015 update 3? I see that update 2 is gone from the programs list.
No idea...

The difference between AVSMeter 2.2.8 and 2.2.9 is that the new version enumerates and checks the auto-load plugins right at the start and not just when using the "-avsinfo" switch. Maybe you have a dodgy plugin. You should try with an empty auto-load directory.

[Reel.Deel]

No idea...

The difference between AVSMeter 2.2.8 and 2.2.9 is that the new version enumerates and checks the auto-load plugins right at the start and not just when using the "-avsinfo" switch. Maybe you have a dodgy plugin. You should try with an empty auto-load directory.

I used r1858 and the plugins included with Avs+ r2003. I downgraded to what I had (core plugins from r1825 and pinterf's recent VDub filter) and now 32-bit works with v2.2.8 again. So it must be something with the distributed plugins in ultim's r2003.

Edit: using the updated plugins from r2003, if I remove DirectShowSource.dll then 32-bit r1858 works again.

[qyot27]

The only-first-function works thing is really weird. It does 'work' if you use the . syntax, but only for the first *two* functions, the third in the . syntax then fails with an Access Violation.

Bisecting it appears to point to the merge commit fcae803fbd. git log fcae803fbd^..fcae803fbd shows that it merges in some stuff from classic's CVS from very early on in the 2.6.1 cycle, which presents some difficulty in trying to figure out which one to try and revert (and moreover, why this merge would even do anything, since the file paths are different and it should have just been the history that was merged...right?). 10e4dc50a5b seems to be the last commit prior to the merge which works like expected.

[MysteryX]

Do you understand the more important problem? You enter hundreds of Avisynth users to use your own non-intuitive term.

I even cannot remember this HBR DRB BDR etc. It just a letter noise. For example "Stacked" is many years well know term here.

Please write code for real users, not robots or assembly programmers. It is the most common computer software problem for API developers. They create over-complicated stuff in cases where it is not required.
When we consider that these 2 functions exist for the sole purpose of supporting Stack16 format, and Stacked implies that we're working with HBD, "ConvertToStacked" and "ConvertFromStacked" work just fine.

Just like "ConvertToShader" and "ConvertFromShader" in AviSynthShader. I switched to different names and then came back to that. What format it converts to isn't part of function name, but is rather the "format" and "lsb" arguments.

[pinterf]

Uh, what a weekend!
While I was chasing Strava KOMs on my bike in the nice tailwind, ultim gave avisynth+ a tailwind, too :) I will look at all these merging things in the evening, but anyway, it was a good job!

[fAy01]

Uh, what a weekend!
While I was chasing Strava KOMs on my bike in the nice tailwind, ultim gave avisynth+ a tailwind, too :) I will look at all these merging things in the evening, but anyway, it was a good job!

Is there a point of having 4-5 different branches of avs+?

[MysteryX]

Is there a point of having 4-5 different branches of avs+?
Pinterf had to create a new branch for his new development.

Ultim has the official branch and is merging all the changes both from Pinterf and from v2.6.1 into it. That's a good thing.

Whether there's a point in having a v2.6.1 branch, an official AVS+ branch and Pinterf's dev branch is irrelevant; we have that. What matters is to merge it into an official build.

[Reel.Deel]

Maybe you have a dodgy plugin. You should try with an empty auto-load directory.

So I kept getting the same error as in post #1932 (http://forum.doom9.org/showthread.php?p=1772699#post1772699) with 32-bit r2003 and AVSMeter v2.2.9. I cleared out my auto-load directory. Added plugins until I got the error message again, it turns out the latest nnedi3 (v0.9.4.22). If I remove it, AVSMeter works as it should. Kinda odd that 64-bit nnedi3 works though.

Edit: removing nnedi3 from the auto-load folder also fixes the problem reported in post #1930 (http://forum.doom9.org/showthread.php?p=1772694#post1772694).

[Groucho2004]

So I kept getting the same error as in post #1932 (http://forum.doom9.org/showthread.php?p=1772699#post1772699) with 32-bit r2003 and AVSMeter v2.2.9. I cleared out my auto-load directory. Added plugins until I got the error message again, it turns out the latest nnedi3 (v0.9.4.22). If I remove it, AVSMeter works as it should. Kinda odd that 64-bit nnedi3 works though.

Edit: removing nnedi3 from the auto-load folder also fixes the problem reported in post #1930 (http://forum.doom9.org/showthread.php?p=1772694#post1772694).Thanks for looking into this. I don't use that version of nnedi3 since I don't need the additional color spaces. I guess that's why I could not reproduce it.

[qyot27]

Well, it resolved itself here once I replaced the core plugins in plugins+ with the ones built with r2005.

[qyot27]

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?

[LigH]

One may even think of a debug build using Windows Debug Messages (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) readable with DebugView (https://technet.microsoft.com/en-us/sysinternals/debugview.aspx) or DebugView++ (https://debugviewpp.wordpress.com/2014/01/04/7/).

[MysteryX]

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?
I don't even know how to locate such errors when debugging my own code. If there's a way, I'd love to hear about it.

[Groucho2004]

Thinking about this, can the Access Violation error message be made more verbose or checks made more robust so that errant plugins that cause issues like this get reported in the message and can be dealt with?
AVSMeter reports the module that caused the exception but that only works if Avisynth doesn't catch the exception first.
It should be simple to add this to the SEH code in Avisynth.

[ultim]

qyot, Reel, you two are kings! I checked the sources of nnedi3 after Reel found it was a possible cause, and realized what the problem is. The merge commit that qyot bisected reinforced my analysis. In short, nnedi3 needs to be recompiled at a minimum, and better, a small fix be made to it to avoid the problem in the future. EDIT: A proper fix needs to come from Avs+. See later posts.

Here is what happened:
1) In commit 2ee19354 of classic Avs (JEEB's repo), GetVarDef() was added to the IScriptEnv interface, and this was merged to Avs+ in the commit found by qyot.
2) The addition of GetVarDef is in general OK, because it maintains ABI for IScriptEnv, and while it breaks ABI for IScriptEnv2 (because it is a derived interface), it was merged anyway because IScriptEnv2 is not (yet) supposed to be used by external plugins. There is a big fat warning block above the interface definition that warns plugin developers, that the interface is not stable and should only be used for testing.
3) Now comes the fun part. nnedi3 ignored this warning, and in its newest version is relying on the unstable interface, which just got changed, and hence the plugin got broken.
4) War, famine, and epidemics, not to mention the wasted hours for the community in debugging this. Warnings are there for a reason. Once that warning gets remove, only then can you rely publicly on the interface.

This also explains why I couldn't reproduce this: I have an older version of nnedi3 that does not use IScriptEnv2.

It seems nnedi3 is using the unstable API to register its MT mode. The proper way to implement this functionality is instead of using IScriptEnv2, respond to the CACHE_GET_MTMODE query in the plugin's SetCacheHints() with the proper constant. Here (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618) is an example of doing it right. This is future proof and is compatible with both classic Avs and Avs+.
EDIT: Ah darn, this functionality got disabled in Avs+ to fix related problems. So a "proper fix" is not that easy. See comment below.

A real fix in Avs+ is not trivial, but a new build will still be issued later tonight to at least fix the HBD resizers and XP compatibility.

[Groucho2004]

One may even think of a debug build using Windows Debug Messages (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) readable with DebugView (https://technet.microsoft.com/en-us/sysinternals/debugview.aspx) or DebugView++ (https://debugviewpp.wordpress.com/2014/01/04/7/).
This won't tell you much if you don't write the code for catching structured exceptions.

[MysteryX]

Quite a few plugin authors, including me, started using IScriptEnv2 to set the MT mode.

Is there a way to use IScriptEnv2 so that it doesn't crash if the interface changes?

[Reel.Deel]

qyot, Reel, you two are kings! I checked the sources of nnedi3 after Reel found it was a possible cause, and realized what the problem is. The merge commit that qyot bisected reinforced my analysis. In short, nnedi3 needs to be recompiled at a minimum, and better, a small fix be made to it to avoid the problem in the future.

Here is what happened:
1) In commit 2ee19354 of classic Avs (JEEB's repo), GetVarDef() was added to the IScriptEnv interface, and this was merged to Avs+ in the commit found by qyot.
2) The addition of GetVarDef is in general OK, because it maintains ABI for IScriptEnv, and while it breaks ABI for IScriptEnv2 (because it is a derived interface), it was merged anyway because IScriptEnv2 is not (yet) supposed to be used by external plugins. There is a big fat warning block above the interface definition that warns plugin developers, that the interface is not stable and should only be used for testing.
3) Now comes the fun part. nnedi3 ignored this warning, and in its newest version is relying on the unstable interface, which just got changed, and hence the plugin got broken.
4) War, famine, and epidemics, not to mention the wasted hours for the community in debugging this. Warnings are there for a reason. Once that warning gets remove, only then can you rely publicly on the interface.

This also explains why I couldn't reproduce this: I have an older version of nnedi3 that does not use IScriptEnv2.

It seems nnedi3 is using the unstable API to register its MT mode. The proper way to implement this functionality is instead of using IScriptEnv2, respond to the CACHE_GET_MTMODE query in the plugin's SetCacheHints() with the proper constant. Here (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618) is an example of doing it right. This is future proof and is compatible with both classic Avs and Avs+.

There's actually a few recent plugins using the same method as nnedi3. If I'm not mistaken a few from Chikuzen, and MysteryX's AviSynthShader.

It was asked about not too long ago: http://forum.doom9.org/showthread.php?p=1768175#post1768175

See this also: http://forum.doom9.org/showthread.php?p=1768838#post1768838

[ultim]

There's actually a few recent plugins using the same method as nnedi3. If I'm not mistaken a few from Chikuzen, and MysteryX's AviSynthShader.

It was asked about not too long ago: http://forum.doom9.org/showthread.php?p=1768175#post1768175

See this also: http://forum.doom9.org/showthread.php?p=1768838#post1768838

Ah, okay, so nnedi3 actually had a proper reason for using IScriptEnv2. Either because of bug #37 (https://github.com/AviSynth/AviSynthPlus/issues/37), or because I actually disabled the mechanism for CACHE_GET_MTMODE, also in a sad attempt to work around #37. Darn.

I see how this leaves plugins like nnedi3 in a crossfire... I'll try to come up with something for this problem.

[ultim]

Is there a way to use IScriptEnv2 so that it doesn't crash if the interface changes?

Unfortunately, no there is not. Or else the warning wouldn't be there. Or at least not if the IScriptEnv is extended using inheritance, but any other method would be really ugly, also for plugin developers.

Basically what I need is a proper fix for #37 so that I can re-enable CACHE_GET_MTMODE.

[Reel.Deel]

Ah, okay, so nnedi3 actually had a proper reason for using IScriptEnv2. Either because of bug #37 (https://github.com/AviSynth/AviSynthPlus/issues/37), or because I actually disabled the mechanism for CACHE_GET_MTMODE, also in a sad attempt to work around #37. Darn.

I see how this leaves plugins like nnedi3 in a crossfire... I'll try to come up with something for this problem.

Correct, but nnedi3() works fine, it's nnedi3_rpow2() that's affected by bug #37. I think eedi3_rpow2() will have the same problem but I haven't checked.

[easyfab]

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

[Reel.Deel]

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

RawSource26 self-registers the MT mode the same way that latest nnedi3 does. See post #1955 (http://forum.doom9.org/showthread.php?p=1772809#post1772809).

[easyfab]

Ok Thanks so it's a known problem.

[Reel.Deel]

Ok Thanks so it's a known problem.

Just recently :)

[qyot27]

It wasn't nnedi3 that caused it for me, I have an older version of it and hadn't updated. It was a mismatch between the plugins built with an early 16-bit test build from pinterf's branch, and the core of r2003/r2005, since I was using Windows' directory-first dll override tactic to make ffmpeg see the new build instead of the one in system32. Once I put the new plugins in the autoload directory, the problem went away.

So something changed in the plugins too. Probably DirectShowSource, since Reel.Deel mentioned that earlier.


And this wouldn't be the first time *VarDef has caused an issue. I couldn't figure out how to integrate it into avsplus properly back during RC1 when it was first brought into 2.6, so it may be piggybacking on that too.

[hector40]

Hi,

I'm a simple user ( not a dev ) and I update to r2003 and it crashed for me with 32bit version, AvsPmod doesn't open for example. After research it comes with rawsource26.dll ( https://github.com/chikuzen/RawSource_2.6x/releases ). Remove this from plugins, it works again ? No problem with 64bit version.
Is this a problem with rawsource26 or avisynth+ ?

I have the same problem with r2003 32bit, the plugins that crashing are, RawSource26-20160528, TCannyMod-1.2.0, yadifmod2-0.0.4.
The r2003 64bit, don't have the same problem.

[ultim]

It wasn't nnedi3 that caused it for me, I have an older version of it and hadn't updated. It was a mismatch between the plugins built with an early 16-bit test build from pinterf's branch, and the core of r2003/r2005, since I was using Windows' directory-first dll override tactic to make ffmpeg see the new build instead of the one in system32. Once I put the new plugins in the autoload directory, the problem went away.

So something changed in the plugins too. Probably DirectShowSource, since Reel.Deel mentioned that earlier.


And this wouldn't be the first time *VarDef has caused an issue. I couldn't figure out how to integrate it into avsplus properly back during RC1 when it was first brought into 2.6, so it may be piggybacking on that too.

DirectShowSource uses iscriptenv2 too, so it has the same problem as nnedi3. except dss is automatically rebuilt with every build of avs+, so as soon you updated dss, the problem went away. it will go away for nnedi3 too if you recompile it for the newest headers. With one word: same problem.

[pinterf]

LOL... It took months from my first post but... Hey... At last...
Tormento, just one more thing (C) Columbo, do your Windows use comma or dot for decimal separator?

[tormento]

Tormento, just one more thing (C) Columbo, do your Windows use comma or dot for decimal separator?

Comma, italian regional setting.

[pinterf]

O.K. then. Same for me.

After approximately 150 iterations (delete-run-view) I managed to shrink down that nice, easy-to-read SmDegrain to a simple return Dither_Luma_Rebuild line. And the visual experience was staggering. Big white blocks were moving to and fro on my screen. No wonder that the MSuper/MAnalyze did bad conclusion with this input.

Why?

Inside Dither_Luma_Rebuild the lut expression is assembled dinamically.

(Values come from the real test case)
S0=1.0
c=0.0625

k = (s0 - 1) * c
t = "x 4096 - 56064 / 0 1 clip"
e = String(k)+" "+String(1+c)+" "+String((1+c)*c)+" "+t+" "+String(c)
\ +" + / - * "+t+" 1 "+String(k)+" - * + 65536 *"
... and e is used here:
Dither_lut16 (yexpr=e,expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv)

With these values variable "e" should look like something like this (I left "t" as is):
"0 1.0625 0.06640625 "+t+" 0.0625 "+" + / - * "+t+" 1 0 - * + 65536 *"


But we are using commas for decimal separator.
String(float_type) results in commas in this case, but the lut functions do not like it. Surely they rely strictly on dots. This becomes a mess for the function:
"0 1,0625 0,06640625 "+t+" 0,0625 "+" + / - * "+t+" 1 0 - * + 65536 *"


The fix is probably to override windows settings and use dot only for formatting floats.

The annoying thing that the debug build was O.K. as it did not take into account windows settings and used dots for formatting floats.

[ultim]

The fix is probably to override windows settings and use dot only for formatting floats.
+1

The annoying thing that the debug build was O.K. as it did not take into account windows settings and used dots for formatting floats.
Sounds a lot like Connect #2185894 (https://connect.microsoft.com/VisualStudio/feedback/details/2185894), with the exception that MS claims it has been already fixed in Update 2.

[ultim]

sry guys, i know i promised, but no builds today. time flew and now i need to sleep. instead there was plenty of diagnosing and exchanging with others. i'm also tempted to only publish next build either when there is a proper fix for #37, or if not that, at least a recommendation for plugin authors about how to handle it. these are next on my agenda.

[ajp_anton]

I'm throwing another vote on it being called "ConvertToStacked" and "ConvertFromStacked", without the "Hbd" in the name.

The Hbd there is unnecessary, because what else would you convert it to/from? There is no advantage, but it has the disadvantage of it being a relatively unknown abbreviation (no matter how "official" and "real" it might be). Whoever said it looks just like a random pile of letters, I agree.
The "Stacked" is already well established in the community, at least with everyone who actually uses it. It's also not an abbreviation, and it's an easy word to pronounce and thus remember.

Another minor problem with HBR is that we don't know how many bits it actually is. Not really a problem now when only 16 bits is introduced (right?), but more formats might be added in the future, in which case we will need "ConvertTo8bit", "ConvertTo12bit" and so on. "HBR" has no place there, it's better to call them by how many bits they actually are.
Stacked is and will ever be only 16 bits, because it's a dead end and will never evolve past that.

[Chikuzen]

Hi.

I updated some my plugins.

RawSource26 (https://github.com/chikuzen/RawSource_2.6x/releases)
PlanarTools (https://github.com/chikuzen/PlanarTools/releases)
yadifmod2 (https://github.com/chikuzen/yadifmod2/releases)
TMM2 (https://github.com/chikuzen/TMM2/releases)
CombMask (https://github.com/chikuzen/CombMask/releases)
TCannyMod (https://github.com/chikuzen/TCannyMod/releases)
VapourSource (https://github.com/chikuzen/VapourSource/releases)

Recompile is easy.
But the announcement is annoy for me...

[MysteryX]

HBD is basically a technical prerequisite of HDR. In addition to HBD, HDR allows to process color and brightness values outside of your limited display range. This usually means 1) using HBD to represent values outside of the valid displayable range, and 2) at the end some kind of tone mapping algorithm to bring it back down to valid pixel values. With HBD Avisynth+ can now do the first of part of HDR, for the second some kind of plugin to perform the tone mapping would be required.
Even without the tone mapping plugin, HDR is still useful to avoid clipping values in the middle of calculations and conversions. It can still be added now. It would be wise to plan this at the same time as HBD. Tone mapping can be added later.

[tormento]

The annoying thing that the debug build was O.K. as it did not take into account windows settings and used dots for formatting floats.

If debug is usable, can you upload and make me test it?

[ultim]

I'm throwing another vote on it being called "ConvertToStacked" and "ConvertFromStacked", without the "Hbd" in the name.

The Hbd there is unnecessary, because what else would you convert it to/from? There is no advantage, but it has the disadvantage of it being a relatively unknown abbreviation (no matter how "official" and "real" it might be). Whoever said it looks just like a random pile of letters, I agree.
The "Stacked" is already well established in the community, at least with everyone who actually uses it. It's also not an abbreviation, and it's an easy word to pronounce and thus remember.

Another minor problem with HBR is that we don't know how many bits it actually is. Not really a problem now when only 16 bits is introduced (right?), but more formats might be added in the future, in which case we will need "ConvertTo8bit", "ConvertTo12bit" and so on. "HBR" has no place there, it's better to call them by how many bits they actually are.
Stacked is and will ever be only 16 bits, because it's a dead end and will never evolve past that.

Since ppl on IRC were also whining about the names, they'll be renamed to ConvertToStacked and ConvertFromStacked. Another suggestion I've received and I like it, is to move these functions into a plugin. This plugin will be distributed along with the core for some time.

[ultim]

Even without the tone mapping plugin, HDR is still useful to avoid clipping values in the middle of calculations and conversions. It can still be added now. It would be wise to plan this at the same time as HBD. Tone mapping can be added later.

No need for special considerations. float type support automatically handles this case. All we need to ensure is to not clamp float to 0..1 at every operation.

[ultim]

EDIT: There is a newer build here (http://forum.doom9.org/showthread.php?p=1773721#post1773721).

Okay, new build r2022 (avs-plus.net/builds).
Please also update the included plugins (if you have an older version installed) to avoid problems. Also, use the updated plugins (http://forum.doom9.org/showpost.php?p=1772902&postcount=1975) from chikuzen for the same reason.

The changes compared to r2003 include:
- Fix for corrupted output of HBD resizers.
- ConvertHbd*() functions renamed to ConvertToStacked() and ConvertFromStacked().
- DirectShowSource() compatibilty fix for VapourSynth.
- Restored XP support.
- (pinterf) New HBD functions added: ConvertToYUV420/422/444(). These convert between different plane formats while keeping the current bit depth. Bit depth conversions will be added in an upcoming build.
- (pinterf) Floating point formatting bug fix, hopefully resolving issues like this (http://forum.doom9.org/showpost.php?p=1771397&postcount=1789).
- (chikuzen) Added ASM-optimized Turn functions for HBD.

Furthermore, the download link now includes new AvsPmod versions, including one also for x64.

As always, please test and give us feedback.

[ultim]

Achievement Unlocked: Page 100.

[LigH]

Well, that escalated quickly...

http://cosgan.de/images/smilie/musik/e050.gif

[pinterf]

2022. So we are in the future from now on :)

[Groucho2004]

r2022 running smoothly on XP32 so far.

[MysteryX]

- (pinterf) New HBD functions added: ConvertToYUV420/422/444(). These convert between different plane formats while keeping the current bit depth. Bit depth conversions will be added in an upcoming build.
This will create confusion with ConvertToYV12, ConvertToYV16 and ConvertToYV24.

Why not keep the same standard functions and add a parameter? They can maintain compatibility with existing scripts while providing the extra feature.

[qyot27]

This will create confusion with ConvertToYV12, ConvertToYV16 and ConvertToYV24.

Why not keep the same standard functions and add a parameter? They can maintain compatibility with existing scripts while providing the extra feature.
The old names didn't go anywhere.

[MysteryX]

Here's an idea for a new feature. Someone wrote AvsFilterNet (https://avsfilternet.codeplex.com/) to allow writing plugins in .NET. One issue is that the .NET plugin must be loaded by AvsFilterNet which is not practical for the user. A .NET library can't be loaded directly by AviSynth.

Could AviSynth+ natively provide an interface for .NET plugins?

This could come useful for utility plugins dealing with multi-threading, multi-processes or performing other complex tasks without requiring raw assembly binary computations.

MP_Pipeline, for example, would have much simpler code by being written in C#. Creating a LoadImage plugin also could be done with just a few lines of code.

Then someone can write a plugin that sends the workload across 10 cloud servers and compares all the data against a database with all communications highly encrypted :P If that'd be useful for someone.

[pinterf]

Ideally we shouldn't have distinct names for each format conversion, just one function with parameters. But it started when only Y8, YV12 and YUY existed besides rgb.

[Chikuzen]

There are already ConvertAudioTo8bit/16bit/Float, and no one complained to those name.
I think ConvertVideoTo8bit/16bit/Float are simple enough.

[tormento]

- (pinterf) Floating point formatting bug fix, hopefully resolving issues like this (http://forum.doom9.org/showpost.php?p=1771397&postcount=1789).
Sorry, not :(

[pinterf]

Sorry, not :(
Are you sure you use the fresh 2022 version? What does avsmeter say (avsmeter -avsinfo) ?
Downloaded ultim's version, and also mine, no artifact. Changed back to a previous r1858, and my intermediate r1908-pfmod, and the artifact came back.

[TurboPascal7]

Here's an idea for a new feature. Someone wrote AvsFilterNet (https://avsfilternet.codeplex.com/) to allow writing plugins in .NET. One issue is that the .NET plugin must be loaded by AvsFilterNet which is not practical for the user. A .NET library can't be loaded directly by AviSynth.

Could AviSynth+ natively provide an interface for .NET plugins?

First of all, .NET really wouldn't simplify stuff too much. Plugins rarely contain anything but the most trivial code and C++ is perfectly fine for that these days.

Second, I see no reason why something like AvsFilterNet couldn't just autoload other plugins on its own. What's the point of moving something like this into the core?

[pinterf]

There are already ConvertAudioTo8bit/16bit/Float, and no one complained to those name.
I think ConvertVideoTo8bit/16bit/Float are simple enough.
Yes, those are tasks for today. 8 bit comes without dithering options first. Float will have a scale parameter defaulting to 0-1.0.

[pinterf]

Another suggestion I've received and I like it, is to move these functions into a plugin. This plugin will be distributed along with the core for some time.

I was thinking the same. And there can be other converting functions (real.finder mentioned lnterleaved16 format), that can ease the transition until filters handle the new colorspaces natively.

[jpsdr]

Euh... Where do you get the new avisynth.h header ? I don't see any link, and it's not put in the package of the new release. Do i have to search it on the github repo ? It would be easier to put it with the release.

Edit : Found it (i think...) on searching on github.

[tormento]

Are you sure you use the fresh 2022 version? What does avsmeter say (avsmeter -avsinfo) ?
Downloaded ultim's version, and also mine, no artifact. Changed back to a previous r1858, and my intermediate r1908-pfmod, and the artifact came back.

Sorry. I had so many mkv outputs that I watched the wrong one.

No artifacts here.

Without going too much OT, can you please paste here the latest modified version of SMDegrain you are using and the script too?

Thanks.

[pinterf]

Sorry. I had so many mkv outputs that I watched the wrong one.

No artifacts here.

Without going too much OT, can you please paste here the latest modified version of SMDegrain you are using and the script too?

Thanks.
Nice. Avisynth Plus Customer Service is happy.

I tested with this script
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

and for the comparison I used the script from here (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

[tormento]

Nice. Avisynth Plus Customer Service is happy.
:thanks:

and for the comparison I used the script from here (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

What about this (http://pastebin.com/JtWFN124)?

[MysteryX]

Euh... Where do you get the new avisynth.h header ? I don't see any link, and it's not put in the package of the new release. Do i have to search it on the github repo ? It would be easier to put it with the release.

Edit : Found it (i think...) on searching on github.
Good question. I'm searching for it.

Here (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/include/avisynth.h)

[tormento]

@real.finder

Can you please explain me the following changes?


add Prefilter auto 16 (lsb) support
add TV_range bool
less lsb if not use lsb things and get ready for yv16 and yv24

Thanks ;)

[Groucho2004]

Some odd behaviour (XP64, 4GB RAM) using a script that should cause Avisynth throw an out of memory error:

Script:
setmemorymax(16000)
n = 12
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "rgb32").killaudio().assumefps(25, 1)
turnleft().pointresize(width() - 1920, height() - 1080)
turnright().pointresize(width() + 1920, height() + 1080)


Exception with r2022:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: D:\WINNT\system32\vcruntime140.dll
Address: 0x000000000207CA44

Exception with r1576:
GetFrameBuffer: Returned a VFB with a 0 data pointer!
size=1194393631, max=3196588032, used=3583180893
I think we have run out of memory folks!


This happens for both, x86 and x64.

r1576 throws what you would expect. I tried the same with the last of pinterf's builds - No exception thrown, Avisynth simply never returns from the first GetFrame() call.

[pinterf]

Some odd behaviour (XP64, 4GB RAM) using a script that should cause Avisynth throw an out of memory error:

Script:
setmemorymax(16000)
n = 12
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "rgb32").killaudio().assumefps(25, 1)
turnleft().pointresize(width() - 1920, height() - 1080)
turnright().pointresize(width() + 1920, height() + 1080)



This happens for both, x86 and x64.

r1576 throws what you would expect. I tried the same with the last of pinterf's builds - No exception thrown, Avisynth simply never returns from the first GetFrame() call.
The cause is possibly the resizer temporary buffer allocation failure that is not caught. I think "simply does not return" means: with 8G RAM, the first frame was OK, but even a turnleft took 1200 seconds.
More info later.

[Groucho2004]

The cause is possibly the resizer temporary buffer allocation failure that is not catched I think "simply does not return" means: with 8G RAM, the first frame was OK, but even a turnleft took 1200 seconds.
More info later.
Thanks for looking into this.
I should have mentioned that I used AVSMeter to test this which reports the module in which an exception occurs. Then again, you probably knew that. ;)

[pinterf]

Thanks for looking into this.
I should have mentioned that I used AVSMeter to test this which reports the module in which an exception occurs. Then again, you probably knew that. ;)
The basic frame is 1.2Gbytes (23040x12960 rgb32)
When the horizontal resizer works, it creates a *21120 x 23040 sized (1.9GByte) videoframe, plus two temporary buffers, one 1.1Gbyte and a 1.9GByte one.

No wonder that with 4/8GB physical RAM is not enough (and this is the real limit, not the declared 160000MB you set in SetMemoryMax, it is overridden). 1.1GB for the Colorbars source frame, another 3-4x frame size during the resize process.

The 1200sec/frame was because of the OS memory swapping.

*This may be suboptimal to work with a new_horizontal*original_horizontal sized temporary frame, maybe it is needed for the horizontal resizer, because it works as turn+resize+turnback. Have to check it.

[Groucho2004]

The basic frame is 1.2Gbytes (23040x12960 rgb32)
When the horizontal resizer works, it creates a *21120 x 23040 sized (1.9GByte) videoframe, plus two temporary buffers, one 1.1Gbyte and a 1.9GByte one.

No wonder that with 4/8GB physical RAM is not enough (and this is the real limit, not the declared 160000MB you set in SetMemoryMax, it is overridden). 1.1GB for the Colorbars source frame, another 3-4x frame size during the resize process.
I'm aware of how much memory these frame sizes need (more or less).
I'm not sure if you realize that the point of that script is simply to force Avisynth to run out of memory and see how it behaves.

So, the only question is why the new version behaves differently.

[sl1pkn07]

any installer for dummies?

greetings

[ryrynz]

any installer for dummies?


Groucho has an installer but it's for 1858. Perhaps he can update it with the latest build and link it.

If you're needing a hand installing it then you'll likely wish to read a guide on how to use Avisynth as well.