Avisynth+

[shekh]

Setting pc_range=true, indeed, fixed the output in the right way, thanks!

Just asking: Is it right that when opening the png (either 32bit or forcing 24bit) with imagesource (without applying any overlay), the image is still blocky like in my previous example?

png must be multiplied by alpha, this is normal

[pinterf]

Yes, this png have only 0 and 255 values in rgb, the greyshades are only in the mask , alpha channel.

[mp3dom]

Ok! Thanks again for the quick fix :thanks:

[Motenai Yoda]

Ok, let's try this one:

http://www.mediafire.com/file/90d7qa1kqj6in07/avsplus-r2331.7z

still get nothing than circle cursor and nothing else after launching avspmod x86 or x64 (same r452 ver)
with avsmeter it seems to work

[Groucho2004]

still get nothing than circle cursor and nothing else after launching avspmod x86 or x64 (same r452 ver)
with avsmeter it seems to work
AVSMeter does not use the C interface.

[ajp_anton]

fadein/fadeout don't work:
"BlankClip: color count 13 does not match to component count 3"

[burfadel]

fadein/fadeout don't work:
"BlankClip: color count 13 does not match to component count 3"

Yes, I've come across that as well when trying to use LSFmod.

[ajp_anton]

Suggestion to CombinePlanes: if source clip only has a Y plane and "source_planes" is not set, use the Y plane.
Also, if "planes" is set, why do we need "pixel_type"? Can't "pixel_type" be figured out automatically, or am I missing some case when it can't?

[fAy01]

Ok, let's try this one:

http://www.mediafire.com/file/90d7qa1kqj6in07/avsplus-r2331.7z

Changes since r2294: see above. Last change:

20161206 r2331dev

YUY2 PlaneToY
C interface compatible array-type AVSValue handling (avspmod issue)


I updated to the latest r3333 build. Avspmod is still not working.

Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArraySize plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'

[pinterf]

I updated to the latest r3333 build. Avspmod is still not working.

Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArraySize plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'

These are not fatal errors.
I have just tried 64 bit avspmod and it was producing me an exception and exited before start and was able to debug avisynth. After one more modification it works for me, those error-like warnings are still there of course.

[pinterf]

Daily nightly build: r2337
http://www.mediafire.com/file/h6nlacgg1y0pla8/avsplus-r2337.7z

20161208 r2337dev

C interface array compatibility vol#2 (zero size arrays) (AvsPMod)
Merge, MergeChroma, MergeLuma: AVX2 (planar)
Possibly a bit faster text overlay


Could someone with AVX2 processor check please, whether there is a speed gain in the merge functions? I have only AVX, and using the intel sde emulator is 10 times slower, so I cannot profile.

e.g. for weight=0.3 and 0.5 (this is special: averaging)
a = MergeLuma(x,x2,weight=weight)
b = MergeChroma(x,x2,weight=weight)
c = Merge(x,x2,weight=weight)

Thanks.

[ChaosKing]

I think a found another bug in Overlay. Try negative values for y -> y=-20. x is ok.
The mask is not moving in y direction!?

I used the Test.png from above https://www.sendspace.com/file/ad7xdd


logo = ImageSource("d:\Test.png",pixel_type="rgb32")
overlay(x=60, y=-20, logo, mask=logo.showalpha(), pc_range=true)

[mp3dom]

Hi,
I'm getting an "Access violation - System Exception" in VDub (on both x86/x64) using xy-vsfilter (3.0.0.306) and "MaskSub" function:


MaskSub("Subtitle.ass", 1920, 1080, 23.976, 34000)


Tnx.

[jpsdr]

Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-06, 14:42:15 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 519.1 | 646.0 | 633.5
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 5%

Time (elapsed): 00:00:15.785


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 14:45:04 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 505.4 | 662.4 | 648.3
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 6%

Time (elapsed): 00:00:15.424


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)

If before AVX2 you allready had AVX, i'm not sure if the difference will be huge.

[pinterf]

I think a found another bug in Overlay. Try negative values for y -> y=-20. x is ok.
The mask is not moving in y direction!?

I used the Test.png from above https://www.sendspace.com/file/ad7xdd


logo = ImageSource("d:\Test.png",pixel_type="rgb32")
overlay(x=60, y=-20, logo, mask=logo.showalpha(), pc_range=true)
Confirmed, fixed.

Mask is converted to greyscale (Y only, w/o U and V) unless the greymask parameter is set to false.

Internally everything is YUV 4:4:4, and with greymask=true (default) the clip's U and V plane is faked from the Y plane. But only the frame pointers were faked, the pitch of U and V planes (which are zero for a greyscale clip) were still used for y shift calculation (mask_offsetU/V = original_mask_offset + x + y*pitchUV which obviously ignores y when pitchUV is zero)

[pinterf]

[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)

If before AVX2 you already had AVX, i'm not sure if the difference will be huge.
Thanks, could you test it with 0.3, please?

Because 0.5 is a special case: read 2x32 bytes, average them (single command), write 1x32 bytes. It seems, that the memory access is the bottleneck, there is not much difference.

For 0.3 it uses the 0.3 and 0.7 weights for clip1 and clip2 then sums it up, so multiplication and addition takes place.

Regarding AVX, this instruction set has only float (single) 256 bit support. From AVX2 we have integer routines like in SSE2 with double (256 bit e.g. 32 bytes) data width. The original version used SSE2.

[jpsdr]

Thanks, could you test it with 0.3, please?

Results are indeed more interesting.


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-06, 14:42:15 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 252.5 | 390.1 | 384.1
Memory usage (phys | virt): 53 | 50 MiB
Thread count: 41
CPU usage (average): 5%

Time (elapsed): 00:00:26.033


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 14:45:04 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 420.9 | 546.9 | 536.8
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 6%

Time (elapsed): 00:00:18.630


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)

[real.finder]

hi pinterf

I check to see if this bug http://forum.doom9.org/showpost.php?p=1736293&postcount=55 still in avs+ after all this work on avs+ then I see it's still not fixed

beside the Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true) I made this for YV16 to test


Function do_PAL_dv (c)
{
c
assert(isyv16(), "only yv16 is allowed.")
SeparateFields()
y=last
B=UToY8()
R=VToY8()

YToUV(b.BicubicResize(b.Width(), Height()/2, src_top= 0.5),r.BicubicResize(r.Width(), Height()/2, src_top=-0.5),y)
Weave()
}

[fAy01]

Daily nightly build: r2337
http://www.mediafire.com/file/h6nlacgg1y0pla8/avsplus-r2337.7z

20161208 r2337dev

C interface array compatibility vol#2 (zero size arrays) (AvsPMod)
Merge, MergeChroma, MergeLuma: AVX2 (planar)
Possibly a bit faster text overlay


Could someone with AVX2 processor check please, whether there is a speed gain in the merge functions? I have only AVX, and using the intel sde emulator is 10 times slower, so I cannot profile.

e.g. for weight=0.3 and 0.5 (this is special: averaging)
a = MergeLuma(x,x2,weight=weight)
b = MergeChroma(x,x2,weight=weight)
c = Merge(x,x2,weight=weight)

Thanks.

Try opening an h264 stream with ffms2. It won't display.

[pinterf]

Chroma placement things and interlaced parameter are not valid for yv16 now. Interlaced is silently set to false if source is not 4:2:0. This may be too strict.
For yv12 test in the link: how do you know which is the correct one?

[ajp_anton]

Do you have any plans on Layer/Overlay? Would it be possible to add colorspaces to Layer, to be able to use it without the forced conversions of Overlay?

[Wilbert]

@pinterf, the bug real.finder is pointing to is fixed in the csv tree of regular AviSynth.

[pinterf]

@pinterf, the bug real.finder is pointing to is fixed in the csv tree of regular AviSynth.
Thanks, I asked it (how can we know which one is wrong - avs or dither tools?), because yes, I can see the visual difference between Dither tools conversion and avisynth conversion, for dv target chroma placement. And I also checked the 2.6.1 source and there was no difference in constants between avs+ and 2.6.1. (I checked convert_planar.cpp Aug.01, 2015). Is there any other place I should check against?

edit: found it

[Sm3n]

Sorry if it's not the right place to talk about that. Dunno if the source of my issue is avisynth+.

About a week now that my x264 encoding process does crazy stuff. After hours of encoding in the middle of a process my cpu which reach most of the time the 100% falls about 20-30%.
I tried to run my avs script directly into x264, using avs4x26x, or piping it using avs2yuv_x64. Same result.
My logic would say it's due to a bad script which makes process to fail (I wonder why because it appears with no reason):

SetMemoryMax(1600)
DGSource("Test1.dgi",fieldop=0,deinterlace=0)
QTGMC(preset="Medium", FPSDivisor=2, DftThreads = 1, EdiThreads = 1)
#crop(2, 2, -2, -2)
Spline36Resize(1280,720)
prefetch(4)

I tried avs+ 2172 and the last mod found here. Here are my avsmeter logs x86 & x64:

AVSMeter 2.3.8 (x86) - Copyright (c) 2012-2016, Groucho2004

[OS/Hardware info]
Operating system: Windows 8.1 (x64) (Build 9600)
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Ivy Bridge (Core i7)
CPU clock (measured): 4346 MHz
CPU cores / Logical cores: 4 / 8

VersionString: AviSynth+ 0.1 (r2337, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 18:02:40
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\yadifmod2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\yadifmod2_avx2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\avss_26.dll (2.0.0.13)
C:\Program Files (x86)\AviSynth+\plugins\DGDecodeNV.dll (0.0.0.2052)
C:\Program Files (x86)\AviSynth+\plugins\DirectShowSource.dll (2.6.1.0)
C:\Program Files (x86)\AviSynth+\plugins\ffms2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\MSharpen.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll (0.9.4.32)
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\TCPDeliver.dll (2.6.1.0)


[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\flash3kyuu_deband.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\AddGrainC.dll (1.5.2.0)
C:\Program Files (x86)\AviSynth+\plugins\AudioLimiter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\avss.dll (2.0.0.13)
C:\Program Files (x86)\AviSynth+\plugins\avstp.dll (1.0.3.0)
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\BassAudio.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\ColorMatrix.dll (2.5.0.0)
C:\Program Files (x86)\AviSynth+\plugins\Convolution3DYV12.dll (1.0.0.5)
C:\Program Files (x86)\AviSynth+\plugins\DctFilter.dll (0.0.1.4)
C:\Program Files (x86)\AviSynth+\plugins\deblock.dll (1.2.0.0)
C:\Program Files (x86)\AviSynth+\plugins\Decomb.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\dfttest.dll (1.9.4.0)
C:\Program Files (x86)\AviSynth+\plugins\DGDecode.dll (1.5.8.0)
C:\Program Files (x86)\AviSynth+\plugins\dither.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\EEDI2.dll (0.9.2.0)
C:\Program Files (x86)\AviSynth+\plugins\EEDI2.dll_back (0.9.2.0)
C:\Program Files (x86)\AviSynth+\plugins\eedi3.dll (0.9.1.0)
C:\Program Files (x86)\AviSynth+\plugins\FFT3DFilter.dll (2.1.1.0)
C:\Program Files (x86)\AviSynth+\plugins\FFT3dGPU.dll (0.8.2.0)
C:\Program Files (x86)\AviSynth+\plugins\FillMargins.dll (1.0.2.0)
C:\Program Files (x86)\AviSynth+\plugins\FluxSmooth.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\gradfun2db.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\GRunT.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\LeakKernelDeint.dll (1.5.4.0)
C:\Program Files (x86)\AviSynth+\plugins\MDeblock.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\MDeblockS.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\NicAudio.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\nnedi.dll (1.3.0.0)
C:\Program Files (x86)\AviSynth+\plugins\nnedi2.dll (1.6.0.0)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE3.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE3.dll_back (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RepairSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RepairSSE3.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\Rotate.dll (1.3.4.0)
C:\Program Files (x86)\AviSynth+\plugins\SSE2Tools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\TDeint.dll (1.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\TDeint.dll_back (1.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\TIVTC.dll (1.0.5.0)
C:\Program Files (x86)\AviSynth+\plugins\TomsMoComp.dll (0.0.1.8)
C:\Program Files (x86)\AviSynth+\plugins\TTempSmooth.dll (0.9.4.0)
C:\Program Files (x86)\AviSynth+\plugins\UnDot.dll (0.0.1.1)
C:\Program Files (x86)\AviSynth+\plugins\unsharpHQ_v05_x86.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VariableBlur.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VerticalCleanerSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VSFilter.dll (3.0.0.306)
C:\Program Files (x86)\AviSynth+\plugins\warpsharp.dll (n/a)


[Avisynth C 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins\yadif.dll (1.7.0.0)
C:\Program Files (x86)\AviSynth+\plugins\yadif.dll_bak (1.7.0.0)

AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004

[OS/Hardware info]
Operating system: Windows 8.1 (x64) (Build 9600)
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Ivy Bridge (Core i7)
CPU clock (measured): 4346 MHz
CPU cores / Logical cores: 4 / 8

VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 15:45:04
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\yadifmod2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\yadifmod2_avx2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\DGDecodeNV.dll (0.0.0.2052)
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins64\msharpen.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll (0.9.4.32)
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll (n/a)


[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\TIVTC.dll (1.0.5.0)


[Avisynth CPP 2.0 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\VSFilter.dll (3.0.0.306)


[Plugin errors]
---------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth+\plugins64\DGDecode.dll"
Cannot load 32 bit DLL with 64 bit Avisynth

---------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll"

Dependencies that couldn't be loaded:
libfftw3f-3.dll

Note: libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

Could it be a hardware failure? (RAM) Or a too high settings for SetMemoryMax and prefetch?

I really need to understand for fixing it. I'd love to have your help.

[pinterf]

Hi,
I'm getting an "Access violation - System Exception" in VDub (on both x86/x64) using xy-vsfilter (3.0.0.306) and "MaskSub" function:


MaskSub("Subtitle.ass", 1920, 1080, 23.976, 34000)


Tnx.
It turned out that it is a filter using avisynth 2.5 plugin interface.

I'm not happy, now I have a deeper clue about the caveats of keeping the backward compatibility with that what is called "baked code".

In its current form I am not able to keep the compatibility between avisynth 2.5 interface and my new AVSValue handling schema. The problem affects arrays (and such, the filter parameter passing). Although the array creation is transparent when 2.6 interface is used and automatically uses the new mechanism for creating and copying AVSValue types, but plugins using "baked code" avs 2.5 interface are not knowing about the feature and use the array creation codes hardcoded in the 2.5 interface.

And since I simply not able to check, what kind of interface made a call to ScriptEnvironment::Invoke, I have to revert that array feature. O.K. having script arrays are only a nice addition to the language but there was quite a bit of work with this feature.

So it seems that I have to revert my nice new array mechanism, even from the dev version of my builds. As there are still some plugins out there with the 2.5 interface, I cannot make avs+ incompatible with them and cause users inconveniance.

[pinterf]

Sorry if it's not the right place to talk about that. Dunno if the source of my issue is avisynth+.

About a week now that my x264 encoding process does crazy stuff. After hours of encoding in the middle of a process my cpu which reach most of the time the 100% falls about 20-30%.
I tried to run my avs script directly into x264, using avs4x26x, or piping it using avs2yuv_x64. Same result.
My logic would say it's due to a bad script which makes process to fail (I wonder why because it appears with no reason)
[...]

Could it be a hardware failure? (RAM) Or a too high settings for SetMemoryMax and prefetch?

I really need to understand for fixing it. I'd love to have your help.
There was a topic some month ago on such a mysterious case.
The solution was that the processor got too hot after a while, and an automatic thermal throttle was kicking in. Try monitoring the processor, and check the heatsink and fan.

[pinterf]

Or there is memory leak somewhere but it needs running your script with avsmeter, perhaps with logging enabled to see whether the slowdown occurs after a specific frame count or memory consumption.

[pinterf]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>

[Sm3n]

There was a topic some month ago on such a mysterious case.
The solution was that the processor got too hot after a while, and an automatic thermal throttle was kicking in. Try monitoring the processor, and check the heatsink and fan.

Or there is memory leak somewhere but it needs running your script with avsmeter, perhaps with logging enabled to see whether the slowdown occurs after a specific frame count or memory consumption.

I'll look into it and post you the log if needed.
:thanks:

[pinterf]

Results are indeed more interesting.


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20

VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
FPS (min | max | average): 252.5 | 390.1 | 384.1

VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
FPS (min | max | average): 420.9 | 546.9 | 536.8

[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)


Thanks for the test. That is spectacular difference, I wish every script has tons of Merge :)
One last request: could you repeat this test with the r2343?

[real.finder]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>


that fix the problem of PAL DV :thanks:

[fAy01]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>


FFms2 is still not working with the new avs+ build. Avspmod still cannot display the video. Whereas, yatta throws this error when I try to open any 10bit h264 ffms2 indexed stream: http://i.imgur.com/anIgSP9.png

[pinterf]

As the error says. Ffms2 opens the video in native 10 bits. Use ConvertBits(8) after ffms2 or specify a 8 bit format if your filter chain is 8 bit only. Or when using avspmod.

[pinterf]

Suggestion to CombinePlanes: if source clip only has a Y plane and "source_planes" is not set, use the Y plane.
Also, if "planes" is set, why do we need "pixel_type"? Can't "pixel_type" be figured out automatically, or am I missing some case when it can't?
You don't need that.
From my earlier post:

CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip

If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

[mcjordan]

Compilation break issue:

8> merge_avx2.cpp
8>C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): error C2664: '__m128i _mm_stream_load_si128(__m128i *)': cannot convert argument 1 from 'const __m128i *' to '__m128i *'
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): note: Conversion loses qualifiers
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(98): note: see reference to function template instantiation 'void average_plane_avx2<uint8_t>(BYTE *,const BYTE *,int,int,int,int)' being compiled

Help?

[pinterf]

Compilation break issue:

8> merge_avx2.cpp
8>C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): error C2664: '__m128i _mm_stream_load_si128(__m128i *)': cannot convert argument 1 from 'const __m128i *' to '__m128i *'
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): note: Conversion loses qualifiers
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(98): note: see reference to function template instantiation 'void average_plane_avx2<uint8_t>(BYTE *,const BYTE *,int,int,int,int)' being compiled

Help?
Comment on git copied here:
Strange, here
https://msdn.microsoft.com/en-us/library/bb531393(v=vs.120).aspx
__m128i _mm_stream_load_si128(__m128i *p);
is mentioned, and you are seeing that.

However, in my smmintrin.h I can see:
__m128i _mm_stream_load_si128(const __m128i*);

Maybe the header (smmintrin.h) has been changed since vs2013?

Try removing the 'const' from cast body.

[mcjordan]

Thank you, pinterf. I'll try asap.

[ajp_anton]

You don't need that.
From my earlier post:

CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip

If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

But for example if I want to join three Y8 clips into RGB, I have to specify "RGB" twice: planes="RGB", pixel_type="RGB".

This is how I'd imagine it working:
version.converttoy8
combineplanes(last,last,last,planes="RGB")"CombinePlanes: too many target planes (3)! Target video plane count is 1!"
Why would the target have 1 plane, when I obviously want to map them into RGB?
version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGB")I know that just "RGB" is not a pixel type, but consequently there's no way to specify just "RGB". It has to be precise in both planar/packed as well as bits. If I write it wrong, the function won't convert it to what I wrote, it will just say it's wrong. Why ask me to specify it if it already knows what it's supposed to be?
version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGBP8")"Source has no such plane "U""
Why not use the only available plane as default, if I don't purposefully try to access an unexisting plane?
version.converttoy8
combineplanes(last,last,last,planes="RGB",source_planes="YYY",pixel_type="RGBP8")This I'm assuming is finally supposed to work, but it crashes both VirtualDub (filtermod) and x264, the two programs I have that can handle Avisynth. Anything I can do to help identify the cause? This is with r2343, both 32- and 64-bits.

[pinterf]

But for example if I want to join three Y8 clips into RGB, I have to specify "RGB" twice: planes="RGB", pixel_type="RGB".

This is how I'd imagine it working:
version.converttoy8
combineplanes(last,last,last,planes="RGB")"CombinePlanes: too many target planes (3)! Target video plane count is 1!"
Why would the target have 1 plane, when I obviously want to map them into RGB?

version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGBP8")"Source has no such plane "U""
Why not use the only available plane as default, if I don't purposefully try to access an unexisting plane?
version.converttoy8
combineplanes(last,last,last,planes="RGB",source_planes="YYY",pixel_type="RGBP8")This I'm assuming is finally supposed to work, but it crashes both VirtualDub (filtermod) and x264, the two programs I have that can handle Avisynth. Anything I can do to help identify the cause? This is with r2343, both 32- and 64-bits.
Don't forget that RGBP8 is unknown for these softwares.
In order to make it work or get it shown in VirtualDub, you have to do a ConvertToRGB32().

As the special case when inputs are greyscale, it is indeed a good idea not defaulting source planes to YUV, your proposal is logical.

edit:

version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGB")I know that just "RGB" is not a pixel type, but consequently there's no way to specify just "RGB". It has to be precise in both planar/packed as well as bits. If I write it wrong, the function won't convert it to what I wrote, it will just say it's wrong. Why ask me to specify it if it already knows what it's supposed to be?.
This is a very special rule: Wwen inputs are greyscale _and_ planes="RGB" (or RGBA) then the output could be planar RGB or RGBA, keeping the bit-depth of the input clips.

[ajp_anton]

Don't forget that RGBP8 is unknown for these softwares.
In order to make it work or get it shown in VirtualDub, you have to do a ConvertToRGB32().Oh. And I could've sworn it crashed also with a ConvertToYV12, but now it doesn't. Nevermind then =).

This is a very special rule: Wwen inputs are greyscale _and_ planes="RGB" (or RGBA) then the output could be planar RGB or RGBA, keeping the bit-depth of the input clips.
Do we need a special rule here? If planes has any permutation of RGB or RGBA, there's only one thing to do: combine the inputs. Throw an error if bitdepths or resolutions don't match.
If it has any permutation of YUV or YUVA, same thing, except also check if the U/V resolutions match 4:2:2 or 4:2:0 before throwing an error.

Also, I would go even further by making source_planes always default to Y if the source clip is YUV(A), because that's what you're usually processing before combining them, and that's what you're actually seeing when previewing anything. If there's at least one RGB source, then require the source_planes string.

[pinterf]

RGBA and YUVA permutations are working already.
But this latter idea can be confusing, e.g. you can specify only one YUV clip, and the default source plane order is YUV, which is good enough I think.
There is a rule that you can specify less input clips, and if no more clips found in the list, but there are still planes to process, the last one will be automatically used further on.

[ajp_anton]

RGBA and YUVA permutations are working already.
How so? Or did you misunderstand?
If planes="RGB" or "BARG" or "AVYU" (weird examples), why does it need pixel_type? There's only one string that's ever going to be accepted by the filter anyway, why not use that? Does there exist a scenario where the user can actually choose between two different pixel_type strings?

[pinterf]

Sorry, I mean they are working because meanwhile I have done it. Specify planes=RRG or GBRA, it will map to planar rgb. pixel_type is good only when single Y or A target is specified or want a target with alpha plane but not filling all 4 planes.

[fAy01]

As the error says. Ffms2 opens the video in native 10 bits. Use ConvertBits(8) after ffms2 or specify a 8 bit format if your filter chain is 8 bit only. Or when using avspmod.

Why do I have to convert my encode from 10bit to 8bit? It worked fine before. Please help :)

[real.finder]

re did same test here http://forum.doom9.org/showthread.php?p=1745799&highlight=qtgmc#post1745799 but with MP_Pipeline and after edit this http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

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


and get ~38 fps :goodpost:

[real.finder]

I note that GScriptClip is incompatible with avs+ mt, with mode 2 not work at all and with mode 3 gave random scriptcilp errors

[jpsdr]

If Prefetch is used in a script, is it possible in a plugin to retrieve the value used?
If yes:
- how?
- Is this value allready avaible when AvisynthPluginInit3 is called, or should i have to wait to be within the Create_xxxx to have the value?

[Groucho2004]

If Prefetch is used in a script, is it possible in a plugin to retrieve the value used?
If yes:
- how?
- Is this value allready avaible when AvisynthPluginInit3 is called, or should i have to wait to be within the Create_xxxx to have the value?
See here (http://forum.doom9.org/showthread.php?p=1666404#post1666404) and here (http://forum.doom9.org/showthread.php?p=1666414#post1666414).

[jpsdr]

This answer half... But i still can make tests, to chek if using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3 will allready give me the correct value.

[Groucho2004]

This answer half... But i still can make tests, to chek if using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3 will allready give me the correct value.
GetProperty() is part of IScriptEnvironment2 and not supported by IScriptEnvironment as far as I know. That should answer your second question.