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.