Avisynth+

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