Avisynth+

[LigH]

Don't blame MediaFire in the first place. I would suspect a malicious advertizing network (ab)user spreading malware via Flash ads. But with ad blocker and script blocker add-ons in your browser, and regular updates if not even removal of Flash, chances to catch one should be quite low; passing on such security measures is grossly negligent, though (like visiting a brothel without a condom).

[StainlessS]

Also, use anything other than IE as browser. + nice to have eg FlashBlocker as FireFox AddOn, with everything that Ligh said too.
I rarely have any such problems when set up as above.

EDIT: As well as FlashBlock (linked 3 posts below by qyot27), I also have Flash Stopper (one of them dont always work, dont remember
which one):- https://addons.mozilla.org/en-US/firefox/addon/flashstopper/

[gaak]

Don't blame MediaFire in the first place. I would suspect a malicious advertizing network (ab)user spreading malware via Flash ads. But with ad blocker and script blocker add-ons in your browser, and regular updates if not even removal of Flash, chances to catch one should be quite low; passing on such security measures is grossly negligent, though (like visiting a brothel without a condom).

I use Firefox with Adblocker Plus. Script blocker? I'll look for one. But this only happens with mediafi

What happens is when I click on the download button other tabs open connecting to other web pages. I'm sorry if this is off-topic, but I need more specifics like what script blocker? Please PM me if it's more appropriate. I searched add_ons are you talking about a javascript blocker?

[Sparktank]

I use Firefox with Adblocker Plus. Script blocker? I'll look for one. But this only happens with mediafi

What happens is when I click on the download button other tabs open connecting to other web pages. I'm sorry if this is off-topic, but I need more specifics like what script blocker? Please PM me if it's more appropriate. I searched add_ons are you talking about a javascript blocker?

You could also try a download manager.

Something like JDownloader can load the link if you copy/paste the link without visiting the site and thus remove the risk of abused ads.
Most ad services have no real control over their own content. The users on MF have even less control over that.

uBlock Origin is a good alternative to AD+, it blocks more things where AD+ sold out to let some ads through for certain sites.
https://addons.mozilla.org/en-us/firefox/addon/ublock-origin/

NoScript is a good script blocker, but requires a lot of maintainence for every site you go to.
It can be tedious for new users. Everything is reversible, but has a huge learning curve.

[qyot27]

The aforementioned Flash blocker:
https://addons.mozilla.org/en-US/firefox/addon/flashblock/

[gaak]

Thank you all for your suggestions. It's all Installed.
Let's see what happens.

[sl1pkn07]

I guess that uploading binary builds directly on github should be perfectly fine, isn't it? :thanks:



@printf you can upload the avs+ binaries to github instead of cyberloker?

greetings

;_; (finally I stop feeling like dropout)

[StainlessS]

(finally I stop feeling like dropout)

Nah, you be still a dropout, but, there be other strange people too.

[MysteryX]

It's kind of a stupid question but... does the AVS+ new features work with INT16, FLOAT16 and/or FLOAT32?

[pinterf]

No float16. But avisynth plus can provide you this f16c cpu flag, I included it in the list.
One remark: if you support 16 bit integer, that means your plugin should supports 10, 12, 14 and 16 bit inputs also. "should" may be a strong word, but let's keep us to this rule in the future.

[MysteryX]

Oh... you support 10, 12, 14 and 16 bit? And 32-bit float (if overflow is needed)?

I'm finally starting to slowly take a look at how to add support in AviSynthShader. From 16-bit, it's easy, the data is already 16-bit. Perhaps the components need to be reversed, have to check. But for for 10, 12 and 14 bit, how do I convert? First convert to 16-bit, then convert to Shader format. Easy enough.

What's the function to convert a 10, 12 or 14 bit frame to 16 bit?

And I'm wondering, what's the point of 10-bit data except for input filter? AFAIK you can't calculate 10-bit data unless you convert it to 16-bit. The goal is to save memory space?

Edit: found my answers here (http://forum.doom9.org/showthread.php?p=1783714#post1783714)

[pinterf]

At 10 bits, you can use faster signed 16 bit integer aritmetic in simd, you don't neccessarily have to convert to 32 bits to avoid overflow.
For 10 bits you can still use lookup tables, as I did it in Tweak for example.
You are not saving memory space, 10 bit format still occupies two bytes, but the full range is 0..1023, 0..4095, 0..16383, etc...

[mcjordan]

6> conditional_functions.cpp
6>C:\AviSynthPlus\avs_core\filters\conditional\conditional_functions.cpp(44): fatal error C1083: Cannot open include file: 'filters/focus.h': No such file or directory

This break compiling of Avisynth.dll (VS2015 U3). Help?

[pinterf]

6> conditional_functions.cpp
6>C:\AviSynthPlus\avs_core\filters\conditional\conditional_functions.cpp(44): fatal error C1083: Cannot open include file: 'filters/focus.h': No such file or directory
What happens when you put
#include "../filters/focus.h"
instead of
#include "filters/focus.h"
at the beginning?

In Additional Include directories I have:
C:\Github\AviSynthPlusPf\avs_core\include;C:\Github\AviSynthPlusPf\avs_core;%(AdditionalIncludeDirectories)

and without ../ works for me.

[mcjordan]

Work like a charm! Thank you, pinterf!
Мy mistake - apologize for the oversight.

[cork_OS]

DirectShowSource from Avisynth+ bundle can't properly open MPEG-1 files. Tried both r2294 and last r2397. FFmpegSource2 works ok.
https://t8.pixhost.org/thumbs/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png (https://pixhost.org/show/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png)

[LigH]

That's possibly a general problem with DirectShowSource: It uses DirectShow filters installed in your Windows system, and when anything doesn't work as expected, you'll have to find the reason in your heap of installed DirectShow filters, but not in AviSynth. A tool like GraphStudio(Next) may help, displaying the filter graph which is most probably built. But that's just a first step towards a solution. Finding the optimum of promoted and demoted filters by changing their merits takes a while. Much longer (if successful at all, and not destroying DirectShow completely by accident) than switching to FFMS2 or L-SMASH Works.

All of the above except ... well, maybe DirectShowSource in AviSynth+ is different than the one in legacy AviSynth, and delivers a wrong decoded video format. But then I would expect more video source formats to fail in a similar way, and reliably in the same way.

[Dion]

DirectShowSource from Avisynth+ bundle can't properly open MPEG-1 files. Tried both r2294 and last r2397. FFmpegSource2 works ok.
https://t8.pixhost.org/thumbs/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png (https://pixhost.org/show/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png)

DirectShowSource uses whatever your OS codec is setup to use. Use DGIndex ( not free and requires Nvidia ) or FFMS2 ( Free ). They are much better.

[wonkey_monkey]

Use DGIndex ( not free and requires Nvidia )

That's DGIndexNV (actually one part of DGDecNV), as opposed to DGIndex (part of DGMPGDec, which is free).

[videoh]

DGIndex is free and can open MPEG1 files.

DGIndexNV requires nVidia, is not free, and does NOT open MPEG1 files.

[ajp_anton]

Bug in overlay?

background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")

box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")

mask = box.mt_lut("255")

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
Also when reversing the black and white, using a "maximum" mask (instead of no mask) results in a white box balue of 254 instead of 255.

[real.finder]

Bug in overlay?

background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")

box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")

mask = box.mt_lut("255")

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
Also when reversing the black and white, using a "maximum" mask (instead of no mask) results in a white box balue of 254 instead of 255.

I think this is known thing, even in masktools https://github.com/tp7/masktools/issues/12

edit: in original avisynth


#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0


and there are another thing, if I overlay 2 rgb32 then I get all alpha in zero in normal avs, but in last avs+ it all 255

[pinterf]

The original blending formula is something like that, where an ideal mask is 0..1.0:
new_value = orig*(1-mask) + overlay*mask

This is equivalent to (only one multiplication, faster):
new_value = orig+(overlay-orig)*mask

As mask is coming from a clip, its value is 0..255

The approximation in overlay core:
new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256

When orig=255, overlay=0, mask=255 (overlay is fully visible), we would expect 0 (=overlay)

Unfortunately the approximation above results in:

new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256:
(255*256+128) + (0-255)*255) / 256 = 383/256 =
(65408 - 65025) / 256 =
383/256 = 1
which is obviously incorrect

For orig=0, overlay=255, mask=255 the result is 254 instead of 255.

[ajp_anton]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?

[real.finder]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?

in 16 bit you will get better result, and I think there is no problem at all in float point

but if you need it in 8 bit there are RMerge (https://forum.doom9.org/showthread.php?p=1537311#post1537311) with mode=256

@pinterf
but there are difference between normal avs and avs+ like I mention

[ajp_anton]

in 16 bit you will get better result, and I think there is no problem at all in float point

but if you need it in 8 bit there are RMerge (https://forum.doom9.org/showthread.php?p=1537311#post1537311) with mode=256

@pinterf
but there are difference between normal avs and avs+ like I mention
That's not a solution, it's a workaround. RMerge doesn't have arguments for x and y offsets, so that's not even a workaround. Float probably works while 16 bit still has this problem (though it's less noticeable).

[pinterf]

and there are another thing, if I overlay 2 rgb32 then I get all alpha in zero in normal avs, but in last avs+ it all 255
What is the use case when you rely on having the output alpha is filled by zeros?

On the other hand in classic avisynth the alpha channel of an RGB32 after an Overlay is undefined.
At least after having a quick look at the source, it is not filled up by any defaults. There is always an RGB->444->RGB conversion sequence, and the final conversion back from internal 444 to rgb32 fills only r, g and b channels.

Avisynth+ Overlay may use ConvertToRGB32 (which fills up alpha with 255; full transparency).
Or it just simply preserves source clip's alpha info if it works in conversionless mode (no RGB->444->RGB conversion, blend works in RGB natively)

[pinterf]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?
Mask value of 255 (and in general the maximum pixel value for a given bit depth) is definitely a special case that we have to handle.
It really should work as maximum transparency.
Much more special, I think than 128 / 50%

[real.finder]

What is the use case when you rely on having the output alpha is filled by zeros?

On the other hand in classic avisynth the alpha channel of an RGB32 after an Overlay is undefined.
At least after having a quick look at the source, it is not filled up by any defaults. There is always an RGB->444->RGB conversion sequence, and the final conversion back from internal 444 to rgb32 fills only r, g and b channels.

Avisynth+ Overlay may use ConvertToRGB32 (which fills up alpha with 255; full transparency).
Or it just simply preserves source clip's alpha info if it works in conversionless mode (no RGB->444->RGB conversion, blend works in RGB natively)


background = blankclip(width=400,height=400,length=1, color=$FFFFFF,pixel_type="rgb32")

box = blankclip(width=100,height=100,length=1,pixel_type="rgb32")

overlay(background, box, x=150, y=150)


you can test it with mask too, but anyway it's not important

but I say something else

here in avs+ as ajp_anton say

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1


and here what I get with normal avs

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

edit and here another test without mask in normal avs


overlay(background.invert, box.invert, x=150, y=150) #white box value is 255, background is 0

[real.finder]

let's back to grun

SetFilterMTMode("GScriptClip", 3)
SetFilterMTMode("RequestLinear", 1) #or 3, mode 2 will make avs+ freeze and not respond (with real clip not ColorBars, ColorBars seems ok even with RequestLinear in mode 2 here)
ColorBars(width=640, height=480, pixel_type="yv12").AddGrainC(10000, 10000, seed=1)
#~ srestore() #seems ok
admfilter (http://pastebin.com/2AfwAngu)() #show error on screen
Prefetch(6)

[pinterf]

here in avs+ as ajp_anton say

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

and here what I get with normal avs

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

I think ajp_anton exchanged the comments of 0 and 1 values

My experience is:
background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")
box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")
mask = box.mt_lut("255")
#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
return last

[ajp_anton]

Yes, sorry, looks like I got the 0 and 1 wrong there.

How is 8(or higher)bit to float handled? Shouldn't it also be
0 -> .0
128 -> .5
255 -> 1.0 ?
Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)

Also, y=128 in 8bit -> float is different from 8bit -> 16bit -> float.

[pinterf]

let's back to grun

SetFilterMTMode("GScriptClip", 3)
SetFilterMTMode("RequestLinear", 1) #or 3, mode 2 will make avs+ freeze and not respond (with real clip not ColorBars, ColorBars seems ok even with RequestLinear in mode 2 here)
ColorBars(width=640, height=480, pixel_type="yv12").AddGrainC(10000, 10000, seed=1)
#~ srestore() #seems ok
admfilter (http://pastebin.com/2AfwAngu)() #show error on screen
Prefetch(6)

I have not continued the investigation on grunt freeze, I have spent three day on it in December, and it is still beyond my knowledge, I am not an avisynth expert. All I have seen that it gets deadlocked on an internal mutex. Scriptclip invoke runs under a different thread id and sometimes that conflicts with the internal cache mechanism. The problem can occur when a runtime function e.g. YPlaneMin requests the child frame and that frame should retreived from the cache. So I put aside this problem a bit until I have more time/knowledge on the topic.

[jpsdr]

When i'm creating an ouput like this :

PVideoFrame dst = env->NewVideoFrame(vi);

Is there something i can do to force an alignment value ?
(If i want aligned on 32 or 64 bits for exemple)

[pinterf]

When i'm creating an ouput like this :

PVideoFrame dst = env->NewVideoFrame(vi);

Is there something i can do to force an alignment value ?
(If i want aligned on 32 or 64 bits for exemple)


PVideoFrame dst = env->NewVideoFrame(vi, 64);

[jpsdr]

Easy, lol ! Thanks.
Euh... Of course, i wanted to say 32 or 64 bytes... (YMM registers.... :rolleyes:)

[pinterf]

Avs+ default is 32

[real.finder]

Yes, sorry, looks like I got the 0 and 1 wrong there.

How is 8(or higher)bit to float handled? Shouldn't it also be
0 -> .0
128 -> .5
255 -> 1.0 ?
Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)

Also, y=128 in 8bit -> float is different from 8bit -> 16bit -> float.

yes, I think there are bugs in Runtime Functions, AverageChromaU and AverageChromaV in float too

[MysteryX]

For now, what plugins support the new 16-bit format? RgTools; anything else?

[Reel.Deel]

For now, what plugins support the new 16-bit format? RgTools; anything else?

RgTools, Average, NNEDI3, DCTFilter, YadifMod2, FFMS2, RawSourcePlus, VapourSource, AVSResize, FQPlus, ModPlus, and MovePlus all support 10-16 bit and 32 bit float.

Edit: also pinterf's MVTools, MDepan, and DepanEstimate support 10-16 bit.

There's also VirtualDubFilterMod, avs2pipemod, and Avs2Yuv which support some of the new HBD colorspaces.

[MysteryX]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

[Reel.Deel]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

Don't know, ask Dogway on VideoHelp. If you want the hacks-upon-hacks-mod-of-a-mod version check with real.finder :).

[MysteryX]

I have this line of code for which I want to add 16-bit support with Y16, YUV420P16, YUV444P16, RGB48 and RGB64.

sourceFormat = FormatOut != "" ? FormatOut : IsY8 ? "Y8" : IsYV12 ? "YV12" : IsYV24 ? "YV24" : IsRGB24 ? "RGB24" : IsRGB32 ? "RGB32" : ""


How can I know whether the clip is 8 bit or 16 bit from the script? Is there a way to write it in a way that will still work under AviSynth 2.6?

[real.finder]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

my mod work and use last mvtools, but all prefilter not yet work with > 8 bit, with tv_range=false and prefilter=-1 or prefilter=external clip it should work now

[real.finder]

Don't know, ask Dogway on VideoHelp. If you want the hacks-upon-hacks-mod-of-a-mod version check with real.finder :).

most hack done in YUY2 and that nothing to do with new color format :)

all filter that needed in SMDegrain work with yv16 now, so there is no need for YUY2 in avs 2.6 (Except for contrasharp > 0.0 cuz it use LSFmod), smart users will covert to yv16 if they have YUY2 source ;)

[MysteryX]

that uses the new MVTools or not yet?
Oups what I wanted to ask is "that uses native 16-bit in/out instead of Stack16"

[real.finder]

Oups what I wanted to ask is "that uses native 16-bit in/out instead of Stack16"

in most cases, script functions support depends on plugins supports, lsb is still there in new mvtools, you can use what you want whether old lsb hack or native (but not both), native > 8 support incompatible with lsb things, there are functions in new avs+ that convert native > 8 from/to lsb but I don't want to did this hack in SMDegrain, but anyone can use these functions like this

10 bit source
prefilter=ConvertBits(16).ConvertToStacked().SMDegrain_prefilters(prefilter=3,lsb_in=true).ConvertFromStacked(16).ConvertBits(10) #or prefilter=4
SMDegrain(tv_range=false, prefilter=prefilter) #don't use contrasharp cuz there is no native > 8 support

[MysteryX]

I'm not interested in 10-bit sources... just looking at whether I can drop LSB stuff and use native 16-bit instead. Question is: the filters used by SMDegrain that were using LSB, do they now support native 16-bit? MVTools does.

[real.finder]

I'm not interested in 10-bit sources... just looking at whether I can drop LSB stuff and use native 16-bit instead.

then

prefilter=ConvertToStacked().SMDegrain_prefilters(prefilter=3,lsb_in=true).ConvertFromStacked(16) #or prefilter=4


Question is: the filters used by SMDegrain that were using LSB, do they now support native 16-bit? MVTools does.


in this case, as I already said, you can't use prefilter or tv_range=true or contrasharp cuz there is no native 16 bit for all plugins that used in SMDegrain

[MysteryX]

in this case, as I already said, you can't use prefilter or tv_range=true or contrasharp cuz there is no native 16 bit for all plugins that used in SMDegrain
Native 16-bit will provide great performance improvement over LSB, especially for a heavy script like SMDegrain. However, it's kind of pointless until enough plugins support 16-bit to actually use it.

How about producing a list of filters supporting LSB that don't support the new native formats? Since they already work with high-bit-depth, I'm supposing it wouldn't be too hard to update those.