Avisynth+

[pinterf]

I started making some changes to the documentation and need some opinions. Here's the difference between the two: http://diff.pics/JbQx0fvGOTeM/1

I added a syntax and parameters section and I also highlighted the syntax and listed all the parameters and their descriptions. I would like to do this to all the internal filters. Yea or nay?
Yes. And a big thanks for dealing with the documentation which is usually the last one in the task queue, at least for the programmers point of view. :)

[pinterf]

Post edited and DGIs inserted.

Please look original thread and see all the trials I did.

Will try to strip down things. As far as I remember, I could even use prefilter 2 instead of 4 or x86 vs x64 and nothing changed.
Thank you for saving time for me. I run too much things parallel nowadays and each one is a challenge for me.

[tormento]

Thank you for saving time for me. I run too much things parallel nowadays and each one is a challenge for me.
Done encoding with any prefilter. Error occurs only with 4.

Uploaded resulting files.

[Groucho2004]

The more I think about it, the more I like the blank slate approach when it comes to how to go from here regarding AVS+.

In order to serve frames to a client, all that's needed is avisynth.dll and optionally a some (compatible) plugins in a directory. The user doesn't have to "install" Avisynth and switching between versions (and auto-load plugin directories) can be done in an instant without rebooting.
Considering this, re-compiling all compatible plugins catering for an all new interface shouldn't be such a big deal.
If a user really has to use some ancient plugin, he could just switch to the "official" AVS2.6.

[MysteryX]

Considering this, re-compiling all compatible plugins catering for an all new interface shouldn't be such a big deal.
Starting with RemoveGrain that was last compiled with VS2005

[Groucho2004]

Starting with RemoveGrain that was last compiled with VS2005Why? What's wrong with RGTools?

[ultim]

Everybody please, there is no need to point out that a conversion layer can be written. As described in #1770 (http://forum.doom9.org/showpost.php?p=1771292&postcount=1770), I know that the old interface can be worked around. But frankly, I will not invest my own time in developing and maintaining compatibility to something which we actually want to switch away from, once we switched away from it. I will not block such attempts, so if somebody comes up with working patches, I'll merge them. But those patches won't come from me.

As for accessing size_t members using int-functions: That will work in *most* cases, as long as plugins are well-behaved. Unfortunately, by some brain-dead decision in the early development of avs classic, the class members have been made public. Knowing the quality standards of many plugins, there is no guarantee that somebody does not access the fields directly, or maybe even create/dereference instances of VideoFrame objects. They shouldn't, most plugins probably don't, but this is a breaking change of the ABI, and I won't be doing code reviews of all plugins to determine which ones we broke and which ones we didn't.

It would be a different story if we had a central repository of all plugins in Git so that we can recompile them with a single click, as well as a package manager, so that if somebody updates the core, plugins will be updated automatically to the new interface. This was a GSoC-proposal once...

[ultim]

As pinterf is now an active contributor, I feel it is time to submit again an old problem I introduced months ago.

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I apply the following script, using AviSynth 2.6 MT, I have good encodings.

13HoursAV26.dgi (http://www76.zippyshare.com/v/rRxxLkBo/file.html)

SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)
ChangeFPS(last,last,true)
SetMTMode(2)
crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Result (http://www59.zippyshare.com/v/hIE3KfV0/file.html).

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

prefilter=1 (http://www62.zippyshare.com/v/HuSWnCqY/file.html) OK
prefilter=2 (http://www62.zippyshare.com/v/5NkG9ias/file.html) OK
prefilter=3 (http://www62.zippyshare.com/v/AXzb0Vqj/file.html) OK
prefilter=4 (http://www62.zippyshare.com/v/EU1MjUsM/file.html) CORRUPTION

Memento:

prefilter

[int: "-1", 0, 1, 2, 3, 4] or [clip: - ]

-1 = off (Default)
0 = light controlled gauss blur
1 = mild median/gauss blur
2 = strong median/gauss blur
3 = dfttest (spatial)
4 = KNLmeansCL (spatio-temporal GPU filter)
variable = prefiltered clip input variable

I have tried to use x86 version of AviSynth+, even DGIndexIM.

Results does not change.

The plugin versions I use are the following for both AviSynth and AviSynth+.

[Avisynth CPP 2.6 plugins]
D:\Programmi\media\AviSynth+\plugins64\KNLMeansCL-0.7.6.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MaskTools-2.1b1-tp7.dll (2.1.0.0)
D:\Programmi\media\AviSynth+\plugins64\MedianBlur2-0.94-tp7.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MVTools-2.7.0.22-pfmod.dll (2.7.0.22)
D:\Programmi\media\AviSynth+\plugins64\RgTools-0.92.1-tp7.dll (n/a)

[Avisynth CPP 2.5 plugins]
D:\Programmi\media\AviSynth+\plugins64\DFTTest-1.9.4.dll (1.9.4.0)
D:\Programmi\media\AviSynth+\plugins64\Dither-1.27.2.dll (n/a)

I can provide other movie examples too.

Ideas? Fixes?

P.S.: Previous post is here (http://forum.doom9.org/showthread.php?p=1739893#post1739893).

Instead of trying to find alternatives, I'd be happy if we found the bug.

Looking at the encodings, to me this looks like a clipping (overflow/underflow) bug, both at high and low pixel values. If that is true, once the binary filter causing this is isolated, the fix should be simple.

[tormento]

Instead of trying to find alternatives, I'd be happy if we found the bug.

Looking at the encodings, to me this looks like a clipping (overflow/underflow) bug, both at high and low pixel values. If that is true, once the binary filter causing this is isolated, the fix should be simple.

Prefilter=4 means KNLMeansCL and the belonging part of SMDegrain. The strange thing is that it happens only with AVS+

[ultim]

Prefilter=4 means KNLMeansCL and the belonging part of SMDegrain. The strange thing is that it happens only with AVS+

Not strange at all. It is with all likelyhood an internal filter in the Avs+ core. Most of those have been rewritten in Avs+ to get rid of inline assembly. And I do see SMDegrain making calls to internal functions along the prefilter=4 paths (too). KNLMeansCL might be the feature of prefilter=4, but I do not think this plugin is the cause of the problem.

[real.finder]

Not strange at all. It is with all likelyhood an internal filter in the Avs+ core. Most of those have been rewritten in Avs+ to get rid of inline assembly. And I do see SMDegrain making calls to internal functions along the prefilter=4 paths (too). KNLMeansCL might be the feature of prefilter=4, but I do not think this plugin is the cause of the problem.

I remember dogway say this happened if DGSourceIM + KNLMeansCL in the same script in avs+

[LigH]

... so are two different plugins using the same hardware for acceleration, therefore might switch hardware operation modes of graphic chips independently of each other, especially when working multi-threaded. There is little surprise that this may corrupt the video when the GPU gets reprogrammed to decode the next frame while filtering the previous.

[jpsdr]

Honestly, about interface, evolution does the job only half, to do thing properly to the end, i would have put all the pitch in ptrdiff_t. If you have to break existing things, break it for a full good purpose, not half. And also the Getpitch functions should return the same.
But, i agree about something. These critical datas shouldn't have been public, and should be accessed only via functions.

Well, personnaly, i would have done :

class VideoFrame {
public:
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const ptrdiff_t pitch;
const uint32_t row_size;
const int32_t height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const ptrdiff_t pitchUV;
const uint32t row_sizeUV;
const int32_t heightUV;

[tormento]

I remember dogway say this happened if DGSourceIM + KNLMeansCL in the same script in avs+

It happens with DGSource (NV) + KNLMeansCL too.

[tormento]

... so are two different plugins using the same hardware for acceleration, therefore might switch hardware operation modes of graphic chips independently of each other, especially when working multi-threaded. There is little surprise that this may corrupt the video when the GPU gets reprogrammed to decode the next frame while filtering the previous.

Ok and why only with AVS+ and not with AVS standard?

[ultim]

It happens with DGSource (NV) + KNLMeansCL too.

Can you provide a minimalistic script that reproduces the problem? Not with SMDegrain, but something without eval, without calling other scripts, without conditional code etc. As few lines as possible.

[tormento]

Can you provide a minimalistic script that reproduces the problem? Not with SMDegrain, but something without eval, without calling other scripts, without conditional code etc. As few lines as possible.



Sorry, not in my capabilities.

[DJATOM]

tormento

Avs+: r1841, MT-pfmod, x86
KNLMeansCL: http://rgho.st/6K5RRq2t8 (dunno how to check file version)
Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSourceIM", 3)
DGSourceIM("13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)
Results: http://screenshotcomparison.com/comparison/176528
Please ensure that your PC is not infected by viruses, then try my KNLMeansCL (32-bit dll).
I didn't tried to check this script on my PC, only on notebook.

[MysteryX]

tormento

Avs+: r1841, MT-pfmod, x86
KNLMeansCL: http://rgho.st/6K5RRq2t8 (dunno how to check file version)
Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSourceIM", 3)
DGSourceIM("13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)
Results: http://screenshotcomparison.com/comparison/176528
Please ensure that your PC is not infected by viruses, then try my KNLMeansCL (32-bit dll).
I didn't tried to check this script on my PC, only on notebook.
I've also been having issues with SMDegrain(prefilter=4) working terrible with MT; working faster with a single thread. I suppose this script will have the same problem.

[DJATOM]

Strange, but in avspmod x64 it only shows the first 800 pixels for height. Applying SMDegrain (with lsb) didn't change it, still 1920x800. 32-bit version works fine. Need to investigate.
Upd: made a new index and problem is fixed now (tested with avs+ r1873, x64; index made with DGIndexIM beta 50 X64). Still can't see any corruption :\

[tormento]

I've also been having issues with SMDegrain(prefilter=4) working terrible with MT; working faster with a single thread. I suppose this script will have the same problem.

Try to remove AVP.dll

[tormento]

Strange, but in avspmod x64 it only shows the first 800 pixels for height. Applying SMDegrain (with lsb) didn't change it, still 1920x800. 32-bit version works fine. Need to investigate.
Upd: made a new index and problem is fixed now (tested with avs+ r1873, x64; index made with DGIndexIM beta 50 X64). Still can't see any corruption :\

Just tried with DGIndexIM beta 50 x64 and I see the same corruption.

This is the script I used:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSourceIM", 3)
LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)

ChangeFPS(last,last,true)

Crop(0, 140, 0, -140)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Prefetch(8)

Have you tried a preview only or real encoding?

Are you under Windows 8 or 10?

[DJATOM]

Have you tried a preview only or real encoding?
Preview in avspmod.
Are you under Windows 8 or 10?
Windows 7 Ultimate.

[Reel.Deel]

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


I also cannot reproduce the corruption. I tried the script exactly as is. However, if I randomly seek multiple times back and forward to random spots it makes VDub freeze. The script finishes without problems in AvsMeter though. No problems in VDub's 'Run video analysis pass' also. What version of SMDegrain are you using? I'll do a bit more testing over the weekend.

I'm using Windows 7, with Windows 10 some problems have been reported:



FAQ

Q) I can't make DGNV and KNLmeansCL work together in avs script.
A) Post #650 (http://forum.doom9.org/showpost.php?p=1764345&postcount=650), Post #664 (http://forum.doom9.org/showpost.php?p=1766150&postcount=664).

[tormento]

Preview in avspmod.

Windows 7 Ultimate.

Problems arose with Windows 10, AFAIK.

Try to do a real encode.

[tormento]

What version of SMDegrain are you using? I'll do a bit more testing over the weekend.
Latest. To make it work with x64 I had to do little tunings for prefilter=2.
FAQ
Q) I can't make DGNV and KNLmeansCL work together in avs script.
A) Post #650, Post #664.
It works in a pure x64 environment. Moreover, the same behaviour happens with DGIndexIM.

P.S: I have tried AVSPmod_x64 in a pure x64 environment. Corruption happens in frame 24 and others.

Thanks for reporting me that on obsolete ;) OS, it works. And, ABOVE ALL, try it in a pure x64 environment.

[DJATOM]

Problems arose with Windows 10, AFAIK.

Try to do a real encode.

http://www114.zippyshare.com/v/zj9xTEWa/file.html

[tormento]

http://www114.zippyshare.com/v/zj9xTEWa/file.html



Not windows 10

[DJATOM]

Indeed, I just don't want to use the worst OS ever.

[tormento]

indeed, i just don't want to use the worst os ever.

omg lol

[pinterf]

Artifact hunting mode ON

Reproduced.

Converted the .h264 into mp4 with ffmpeg because I couldn't get work any dgdecxxx.

Find my input source here (http://www.mediafire.com/download/1ybcg1ocpccvfjv/13HoursCUT.mp4)

Script:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


Let's edit SMDegrain.avsi.
We remove and simplify the non-relevant lines (assuming the SMDegrain calling parameters)

So we replace the whole
pref=eval(""" ......
""")
part with

NL_in = input8.Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),\
StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))
Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

#PF remark:
# We created a big image, assuming that U and V is half the height in YV12
# Y8:
# Y_msb U_msb
# Y_msb V_msb
# Y_lsb U_lsb
# Y_lsb V_lsb

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU") # D=0/1 nochange GPU/CPU:nochange

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

pref=YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))


Ok. Now let's comment out the KNLMeansCL call.
Y8=Y8#.KNLMeansCL(D=1,A=1,h=7.0,lsb_inout=true,device_type="GPU")

No more artifact.

I don't know how KNLMeans work but the idea that all planes are stuffed into one greyscale image and is sent to the plugin may fail sometimes.

Now I really wonder why only avs+ is affected.

[Reel.Deel]

I don't know how KNLMeans work but the idea that all planes are stuffed into one greyscale image and is sent to the plugin may fail sometimes.

Now I really wonder why only avs+ is affected.

I think the script is doing that because KNLMeansCl does not process chroma unless the input format is YV24 or RGB. I wonder why Dogway didn't separate the planes, process them indivdually, and then merge them? :confused:

I wish I could help but I still cannot reproduce the corruption even with the simplified script. :/

Are you using Windows 10?

[pinterf]

No, Win7Prof.
Built a special avisynth.dll in which I switched off SSE3 and newer cpuid detection but the problem remained.

[pinterf]

O.K.

Still smdegrain.avsi, Dither_Luma_Rebuild

Replaced the line with 56064 (219*256) with 61184 (239*256)
(and the 219 with 239 but it does not play now).
The artifact disappeared.

There is another thing that may not be intentional:
String(lsb?65536:255)
For me 65535 would be more logical, but I'm far from fluently reading the avisynth expression syntax :)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
lsb_in = Default( lsb_in ,false)
lsb_out = Default( lsb_out ,false)
lsb = Default( lsb ,lsb_in || lsb_out)
mode = Default( mode ,6)
uv = Default(uv, 3)
s0 = Default(s0, 2.0)
c = Default(c, 1.0/16)
ampn = Default(ampn, 0.0)
slice = Default(slice, true)

k = (s0 - 1) * c
t = lsb_in ? "x 4096 - 61184 / 0 1 clip" : "x 16 - 239 / 0 1 clip"
# t = lsb_in ? "x 4096 - 56064 / 0 1 clip" : "x 16 - 219 / 0 1 clip"
e = String(k)+" "+String(1+c)+" "+String((1+c)*c)+" "+t+" "+String(c)
\ +" + / - * "+t+" 1 "+String(k)+" - * + "+String(lsb?65536:255)+" *"
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=e,expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=e,expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
mt_lut (yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)
lsb_out ? last : (lsb ? Ditherpost(mode=mode,ampn=ampn,slice=slice,staticnoise=ampn!=0.0?true:false,u=uv,v=uv) : last)}

I don't know what is the right constant there, the creators of this script can correct it for the right value.

[pinterf]

Or 220*256-1? instead of 219*256? Anyway it can be different rounding in evaluation than in classic avisynth?

[Reel.Deel]

Have you look at cretindesalpes original script: http://forum.doom9.org/showthread.php?p=1548318#post1548318

[real.finder]

this with TV_range bool http://pastebin.com/vz6Ewuvv


SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
# In a more lucid state I could probably have laid out this block much better... or not...
NL_in = Dither_convert_8_to_16()
NL_W = width(NL_in)
U8 = UToY8(NL_in)
V8 = VToY8(NL_in)
NL_lsb = StackVertical(StackVertical(Dither_get_msb(u8),Dither_get_msb(v8)),StackVertical(Dither_get_lsb(u8),Dither_get_lsb(v8)))

Y8 = StackHorizontal(ConvertToY8(NL_in),NL_lsb)

Y8 = Y8.KNLMeansCL(D=1, A=1, h=7.0,lsb_inout=true,device_type="GPU")

u_h = u8.height()/2
v_h = v8.height()/2

u16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,0,0,-v_h),Dither_get_lsb(Y8).crop(NL_W,0,0,-v_h))
v16 = StackVertical(Dither_get_msb(Y8).crop(NL_W,u_h, 0,0),Dither_get_lsb(Y8).crop(NL_W,u_h, 0,0))

prefilter4 = YToUV(u16,v16,Y8.crop(0,0,-u8.width(),0))


try first

SMDegrain (tr=4,PreFilter=prefilter4,TV_range=false,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


then try

SMDegrain (tr=4,PreFilter=prefilter4.SmoothCustom16("Y>60160?y:y","u>61440?u:u","v>61440?v:v",limiter=true),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)


and

SMDegrain (tr=4,PreFilter=prefilter4.Ditherpost(mode=6,ampn=0.0,staticnoise=false).Limiter(),thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

[LigH]

There is another thing that may not be intentional:
String(lsb?65536:255)
For me 65535 would be more logical, but I'm far from fluently reading the avisynth expression syntax :)

The typical "ternary operator" (boolean_expression ? true_case_result : false_case_result)... inside a function of a C-like language, you could expand this to:

if(lsb) return String(65536); else return String(255);

[Chikuzen]

@ultim or someone

I have a question about multi-threading.

Is it possible to implement a temporal IIR filter as MT_NICE_FILTER ?

[real.finder]

The typical "ternary operator" (boolean_expression ? true_case_result : false_case_result)... inside a function of a C-like language, you could expand this to:

if(lsb) return String(65536); else return String(255);

he mean the value, 65536 is full 16 bit range, 256 is full 8 bit range, so he say that it should (65536 -1) like (256 -1)

[MysteryX]

DitherTools isn't working well with MT.

Try this script repeatedly and it will crash in dither.dll, when all dither functions are set to either MT=1 or 2

Dither_convert_8_to_16()
SMDegrain(thsad=200, prefilter=2, lsb_in=true, lsb_out=true)
DitherPost(mode=6)
Prefetch(8)


A solution I found is to set DitherPost to MT mode 3. However, it then causes a severe slowdown when using SMDegrain(prefilter=4) where performance goes from 2.2 to 1.6fps.

Without setting DitherPost to MT mode 3, I can't get rid of the crashes, so it would be nice for someone to investigate.

[LigH]

Issues with DitherPost have been reported before; I remember the statement that it is sufficient to limit one function of this family if there are several dither function used, may not matter much which of them...

[Groucho2004]

DitherTools isn't working well with MT.
Do you have avstp.dll in your auto-load directory? If so, remove it and try again.

[MysteryX]

Do you have avstp.dll in your auto-load directory? If so, remove it and try again.
No I don't have that

[jpsdr]

@ultim or someone

I have a question about multi-threading.

Is it possible to implement a temporal IIR filter as MT_NICE_FILTER ?

I am affraid you have to be MT_SERIALIZED with this kind of filter, you can't even be MT_MULTI_INSTANCE. At least, from what i've understood.
But there is also a MT_MODE_COUNT, i don't know what it does.

[MysteryX]

Here's another bug. I tried using Deshaker.
http://www.guthspot.se/video/deshaker.htm

Here's a script that will run the first pass and generate a log file to be used for the second pass.

P="Encoder\"
LoadVirtualDubPlugin(P+"deshaker.vdf", "deshaker", preroll=0)
LoadPlugin(P+"LSMASHSource.dll")
file="Source.MOV"
LWLibavVideoSource(file, cache=True)
ConvertToRGB32()
deshaker("19|1|30|4|1|0|1|0|640|640|1|2|1000|1000|1000|1000|4|1|3|2|8|30|300|4|Preview_Deshaker.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|15|15|5|15|0|0|30|30|0|0|0|0|1|0|0|10|1000|1|88|1|1|20|5000|100|20|1|0")
PointResize(8,8)


To run the second pass, re-insert the deshaker line in your full script wherever you want and change the 2nd argument from 1 to 2 to run the 2nd pass from that log file.

With AviSynth 2.6 it works fine. With AviSynth+, I get a crash in the destructor. Whenever I close the preview I get a crash.

Deshaker doesn't seem to work with MT but a single thread tops all 8 CPU cores anyway.

[MysteryX]

The VD plugin bug seems easy to fix so I thought I might take a look myself. Trying to compile AVS+ in VS2015, however, there is this error: redefinition of 'y'. This code really doesn't look right... it's using y for the loop and redefining y twice more within the loop. Pinterf I'll let you look into that one.

For now I'll rename the 2 redefinitions as y2.


static void af_horizontal_yuy2_c(BYTE* p, int height, int pitch, int width, int amount) {
const int center_weight = amount*2;
const int outer_weight = 32768-amount;
for (int y = height; y>0; --y)
{
BYTE yy = p[0];
BYTE uv = p[1];
BYTE vu = p[3];
int x;
for (x = 0; x < width-2; ++x)
{
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
BYTE w = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+5]) * outer_weight);
uv = vu;
vu = p[x*2+1];
p[x*2+1] = w;
}
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
p[x*2+1] = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+1]) * outer_weight);
p[x*2+2] = ScaledPixelClip(p[x*2+2] * center_weight + (yy + p[x*2+2]) * outer_weight);
p[x*2+3] = ScaledPixelClip(p[x*2+3] * center_weight + (vu + p[x*2+3]) * outer_weight);

p += pitch;
}
}

[MysteryX]

The VDub destructor bug isn't so easy to fix; but shouldn't be hard for someone who understands the code better.


// VDubFilter.cpp
void CallEndProc() {
if (fd->endProc) {
int result = fd->endProc(&fa, &g_filterFuncs);
if (result != 0) {
throw AvisynthError("VirtualdubFilterProxy: error calling endProc");
}
}
}


Basically, Deshaker's EndProc is trying to access "something" within fa that is no longer accessible at that time.

Commenting both of these lines does solve the problem, but I doubt it is the right fix

// in FilterAdd
fm->env->AtExit(FreeFilterDefinition, fd);

// in LoadVirtualdubPlugin
env->AtExit(FreeFilterModule, fm);


The destructor needs to be called before these 2 functions.

I'll let you fix it before I start adding a "release timer" to fix the sequence :)

[pinterf]

For now I'll rename the 2 redefinitions as y2.

In my source it is fixed already in focus.cpp.
https://github.com/pinterf/AviSynthPlus/blob/MT-pfmod/avs_core/filters/focus.cpp
Which branch or version are you working on?

[Groucho2004]

Trying to compile AVS+ in VS2015, however, there is this error: redefinition of 'y'.

static void af_horizontal_yuy2_c(BYTE* p, int height, int pitch, int width, int amount) {
const int center_weight = amount*2;
const int outer_weight = 32768-amount;
for (int y = height; y>0; --y)
{
BYTE yy = p[0];
BYTE uv = p[1];
BYTE vu = p[3];
int x;
for (x = 0; x < width-2; ++x)
{
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
BYTE w = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+5]) * outer_weight);
uv = vu;
vu = p[x*2+1];
p[x*2+1] = w;
}
BYTE y = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
yy = p[x*2+0];
p[x*2+0] = y;
p[x*2+1] = ScaledPixelClip(p[x*2+1] * center_weight + (uv + p[x*2+1]) * outer_weight);
p[x*2+2] = ScaledPixelClip(p[x*2+2] * center_weight + (yy + p[x*2+2]) * outer_weight);
p[x*2+3] = ScaledPixelClip(p[x*2+3] * center_weight + (vu + p[x*2+3]) * outer_weight);

p += pitch;
}
}

Earlier compilers didn't complain about re-definitions if they had a different scope. That led to sloppy programming.
The above function is just horrible, it also defines a variable with different types (BYTE y, int y).