Avisynth+

[Groucho2004]

I tried to use it, but it failed to analyze the script...

https://i.imgur.com/EPrABiS.pngWell, I'm out of ideas for now. :(

[real.finder]

AviSynth+ version 3.5.1 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Mostly just bugfixes and tidying up POSIX stuff. Seeing the recent discussion, might want to check against 3.5.1 to see if the issue with C api programs exists.


this seems fix MPP problem (https://i.postimg.cc/NM9pyPHf/Untitled.png) with last test one

[real.finder]

this seems fix MPP problem (https://i.postimg.cc/NM9pyPHf/Untitled.png) with last test one

but it not work with MT!

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)

https://i.postimg.cc/Y0Tbkcqw/Untitled.png (https://postimages.org/)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)

[FranceBB]

AviSynth+ version 3.5.1 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Mostly just bugfixes and tidying up POSIX stuff. Seeing the recent discussion, might want to check against 3.5.1 to see if the issue with C api programs exists.

More compiler coverage on POSIX
Native Clang on FreeBSD 12.1
Native AppleClang on Catalina
general code correctness fixes (-fpermissive is no longer required)
AddAutoloadDir now works on macOS and BSD
FreeBSD requires mounting procfs first in order for autoload to function
Automatic plugin autoloading now enabled on POSIX
ConvertStacked now is built and installed on POSIX by default
SONAME and SOVERSION defined for POSIX libavisynth.so
Fix: BuildPixelType: chroma subsampling of sample clip was ignored.
POSIX: better behaviour under non-Windows because of having multiple sized fixed fonts, not only a single size=20 one.
e.g. MessageClip(), Info(), Version(), ColorYUV "show", internal ApplyMessage
Text filter:
font types with
"Terminus" fixed fonts added (12-14-16-18-20-22-24-28-32, regular + bold)
"Info_h" good old 10x20 fixed font kept under this name
much more international unicode characters (1354), use utf8=true under Windows
use fontname parameter (default "Terminus", other choice is "info_h")
use font_filename parameter (accepts BDF fonts at the moment import is probably not too smart but worked for Terminus)
use size parameter (12 to 32, if no size is available, a smaller one is chosen but at least the smallest one)
new parameter: bold (default false)
Info() filter: when parameter "size" < 0, font is automatically enlarged over 640x480
(POSIX limit: minimum size is 12, maximum size is 32 limited by available fixed fonts)")
SIL OPEN FONT LICENSE added because of usage of Terminus fonts)
able to build w/o GDI and font rendering engine under Windows, so that text-overlay filters
work like in POSIX version of AviSynth+ (mainly for my development test)
Use with NO_WIN_GDI define.
Fix: ReplaceStr when the pattern string to be replaced is empty
New:
Exist() to have bool utf8 parameter
This is another function to have utf8 option:
Usage: b = Exist("Здравствуй.mkv",utf8=true). Avs file is saved as utf8 w/o BOM
Fix: broken Exist for directories (regression appeared in 3.5.0)
Fix: ColorYUV: really disable variable search when parameter "conditional" is false
Development:
ScriptEnvironment::VSprintf: parameter (void *) is changed back to va_list.
May affect C interface (avs_vsprintf) and CPP interface (ScriptEnvironment::VSprintf)
Enhanced: Planar RGB to YUV 444 10-14 bits: more precision (32 bit float internally)
Enhanced: Planar RGB to YUV 444 10-16 bits: AVX2 (speed improvement)

Did you, by any chance, re-compiled with some different option what Ferenc released? Because when I substituted the test build with this one it started working with everything else again, including AVSPmod, AVSMeter etc.
My guess (and it's just a guess) is that the test build wasn't actually compiled with something for XP and the only reason why Dependency Walker was saying that everything was fine was that probably what was "missing" already had an implementation made by the wrapper of my custom kernel but perhaps it wasn't complete and it broke something, I don't know.

Anyway, it works now, so... I guess all's well that ends well :)

[qyot27]

but it not work with MT!

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)

https://i.postimg.cc/Y0Tbkcqw/Untitled.png (https://postimages.org/)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)
3.5.1 does not include the Neo changes in the test build from earlier. I wanted to make sure we had a proper release out before getting into the task of making sure those changes can merge in.

Did you, by any chance, re-compiled with some different option what Ferenc released? Because when I substituted the test build with this one it started working with everything else again, including AVSPmod, AVSMeter etc.
My guess (and it's just a guess) is that the test build wasn't actually compiled with something for XP and the only reason why Dependency Walker was saying that everything was fine was that probably what was "missing" already had an implementation made by the wrapper of my custom kernel but perhaps it wasn't complete and it broke something, I don't know.

Anyway, it works now, so... I guess all's well that ends well :)
I doubt it's the abstraction of XP support to opt-in, since if it wasn't active then the library wouldn't run on XP at all (to see that, just swap in the builds that don't have _xp suffixed to them).

An access violation that only occurs in programs that directly talk to AviSynth, but not in programs that use VfW as a middleman points to it being that something in the Neo patchset changed the API and we need to identify and mitigate that. I haven't taken a look at any of it yet, though, so it may not have anything to do with that.

[real.finder]

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw


I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")

[pinterf]

I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")
Where can I find the latest one?

[real.finder]

Where can I find the latest one?

here https://github.com/realfinder/MP_Pipeline/releases

or last official one mirror https://forum.doom9.org/showthread.php?p=1841228#post1841228

[FranceBB]

An access violation that only occurs in programs that directly talk to AviSynth, but not in programs that use VfW as a middleman points to it being that something in the Neo patchset changed the API and we need to identify and mitigate that. I haven't taken a look at any of it yet, though, so it may not have anything to do with that.

I see... Again, if you need more testing on my end or if you wanna see my computer remotely (if you don't have an XP VM), I'll do everything I can. :)

here https://github.com/realfinder/MP_Pipeline/releases

or last official one mirror https://forum.doom9.org/showthread.php?p=1841228#post1841228

As a side note, it would be great to have audio support for MPP after all these years, along with proper AVS+ colorspaces/bitdepth handling to avoid to make it fail spectacularly like this (https://forum.doom9.org/showpost.php?p=1865072&postcount=273)

[gispos]

I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")
MPP requires a 'return last' in the last section for NEO builds.
Have you tried?

Something has changed from the previous version. Could this cause problems for some people?
More information


example 1 (this was still possible without 'return')
------------
LWLibavVideoSource(SourceFile)
return dummy()

function dummy(clip clp){
clp
}

example 2 (This was possible, not now)
------------
LWLibavVideoSource(SourceFile)

#dummy()
function dummy(clip clp){
clp
}

example 3 (MP_Pipeline needs now also return)
------------
MP_Pipeline("""
### inherit start ###
SourceFile = String(ScriptDir()) + "Goblin.mkv"
### inherit end ###
LWLibavVideoSource(SourceFile, cache=False)
### ###
### platform: Win32
HDRAGC()
### platform: Win64
### ###
audio=LWLibavAudioSource(SourceFile, cache=False)
audioDub(last, audio)
return last
""")
sharpen(0.40)

[pinterf]

Just built a new version from mpp, but I will do tests later

[real.finder]

MPP requires a 'return last' in the last section for NEO builds.
Have you tried?

Something has changed from the previous version. Could this cause problems for some people?
More information


example 1 (this was still possible without 'return')
------------
LWLibavVideoSource(SourceFile)
return dummy()

function dummy(clip clp){
clp
}

example 2 (This was possible, not now)
------------
LWLibavVideoSource(SourceFile)

#dummy()
function dummy(clip clp){
clp
}

example 3 (MP_Pipeline needs now also return)
------------
MP_Pipeline("""
### inherit start ###
SourceFile = String(ScriptDir()) + "Goblin.mkv"
### inherit end ###
LWLibavVideoSource(SourceFile, cache=False)
### ###
### platform: Win32
HDRAGC()
### platform: Win64
### ###
audio=LWLibavAudioSource(SourceFile, cache=False)
audioDub(last, audio)
return last
""")
sharpen(0.40)


thanks that seems make it work!

mp_pipeline("""
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
return last
""")

[tormento]

Would you please create an additional autoload folder "AVSI" on next releases?

I probably suffer from OCD but I'd like to put them in a different directory. :D

[StainlessS]

Tormento,
AvsInit.avsi allows you to use a GIMPORT directory where avs/avsi scripts are auto loaded (by AvsInit), and makes it possible to have scripts that will load
under avs v2.58/2.60/2.61 Std with GScript, OR, under Avs+, either x86 or x64, and where all can use Gscript style constructs [for/While/If].
Can have a GIMPORT in plugins directory specifically for a single version of Avs, or where using G2K4 Avisynth Universal Installer, a
universal GIMPORT directory used by all avs versions, dont need same identical scripts in all avs version plugins.
Also some other functionality.

AvsInit.avsi :- https://forum.doom9.org/showthread.php?t=176749&highlight=AvsInit

EDIT: Some functions callable from inside AvsInit or user scripts.

AvsInit_LoadPlugin(fn) Load CPP dll with filename FN, sending debug stuff (success/fail) to DebugView window.
[Avs+ will also load C plugins].
AvsInit_LoadCPlugin(fn) Load C dll with filename FN, sending debug stuff (success/fail) to DebugView window.
AvsInit_Import(fn) Import[GImport() if GScript Present] avs/avsi script with filename FN, sending debug
stuff (success/fail) to DebugView window.
###
Directory of files load/Import functions. Return total number of scripts imported,
or dll's loaded,
AvsInit_DImport(Dir) Import[GImport() if GScript Present] All avs/avsi scripts in folder Dir, sending debug
stuff (success/fail) to DebugView window.
AvsInit_DLoad(Dir) Load all CPP/C plugin dll's in folder Dir, sending debug stuff (success/fail) to
DebugView window.

Both DImport and DLoad, funcs may be of use in user functions to satisfy some script
dependency, where a complex script requires multiple dll's or script loaded.

The Import style functions use GImport() when GScript is available, otherwise Import(). Any scripts imported should have any
GScript style wrappers removed, eg

>>>> CODE >>>>
GScript(""" # <<<<<<<<<<========= REMOVE THIS LINE
...
Some gscript stuff, if/else/for/next while etc
...
""") # <<<<<<<<<<========= REMOVE THIS LINE
<<<< END CODE <<<<

With GScript wrappers removed and imported via this library, then should be able to use same scripts in any version of avs
standard(with Gscript plugin) or avs+, whether it be avs v2.58, avs v2.60/2.61 Standard, avs+ x86 or x64.


EDIT: With AvsInit, you only need the AvsiInit.avsi in plugins, all others can be in local or global GIMPORT (or some other name) directory.

[tormento]

With AvsInit, you only need the AvsiInit.avsi in plugins, all others can be in local or global GIMPORT (or some other name) directory.
Thanks for your kind reply. I already put my AVSI in plugin64 folder, so they are autoloaded.

A question: why to have such a complicate solution as AvsInit when it would be way easier to have a separate AVSI folder?

[tormento]

url=https://cloud.owncube.com/s/WdARWHb9epfGRwM]AddGrain[/url] port of the vs version.
Is it the r7 VS version?

[pinterf]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset

[FranceBB]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset


OMG you have no idea how long I wished for someone to do this.
I tested it on XP as well with 16bit and even 32bit as bit depth along with things like RGBPS and RGBAPS: they all work fine.
Thank you! Thank you! Thank you!! *_*

Now the cherry on the cake would be audio support. After that, MPP is gonna be perfect! Please, I beg you to do that as this way we can leave it as it is for the years to come and it would actually save me time by avoiding to make an additional separate script without MPP, just for the audio.

p.s Ferenc, if you have a LinkedIn account I'll definitely leave you a good recommendation for everything you've done for this community.

[real.finder]

Now the cherry on the cake would be audio support. After that, MPP is gonna be perfect! Please, I beg you to do that as this way we can leave it as it is for the years to come and it would actually save me time by avoiding to make an additional separate script without MPP, just for the audio.

maybe not audio alone, but also with these https://github.com/SAPikachu/MP_Pipeline/issues/1 :goodpost:

[real.finder]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset


thanks :thanks:

but it's still need return last, so it's avs+ test problem? will it stay like this? there are another examples in gispos post in another cases not only mpp

[StainlessS]

A question: why to have such a complicate solution as AvsInit when it would be way easier to have a separate AVSI folder?

Main reason for AvsiInit is below in BLUE

AvsInit.avsi v1.09 - 27/Jan/2020
Script to perform some tasks before user script is executed.

Also makes a few script functions later available to any other user scripts.
Also assists in removing AVS+ GScript incompatibilites so that an avsi script may run under Avs+, or when Gscript installed, then also v2.58, v2.60.

With GScript wrappers removed and imported via this library, then should be able to use same scripts in any version of avs
standard(with Gscript plugin) or avs+, whether it be avs v2.58, avs v2.60/2.61 Standard, avs+ x86 or x64.

You are looking at it with too limited a view, separate script directory loading is incidental.

[real.finder]

if anyone want to test admfilter (or anything else) with MT, GRunT update is needed http://www.mediafire.com/file/77uromd0j0z56ap/GRunT-1.0.2tst.7z/file

its the one that pinterf made years ago

[pinterf]

p.s Ferenc, if you have a LinkedIn account I'll definitely leave you a good recommendation for everything you've done for this community.
Thanks, but I'm collectiing kudos only on Strava :)

[StvG]

anyone know why? is the VS version has the same output?
VS version has identical output.
Is it the r7 VS version?
It's a port of r7 VS version.

[real.finder]

VS version has identical output.

It's a port of r7 VS version.

so that mean VS one was already has bug

[StvG]

so that mean VS one was already has bug
VS r1 has identical output to AddGrainC 1.71.
The difference comes from here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-AddGrain/commit/8f272c4b7aa3c32e5f6e2b19b20ff4dcb8dad481).

[Music Fan]

Hi,

I'd like to re-install Avisynth+, I still get an old version, but I don't know if I have to select the simple or the vcredist version.
When should the vcredist version be used ?
That's for Win 7 64.
Thanks ;)

[tebasuna51]

When should the vcredist version be used ?

If you don't have Microsoft Visual C++ 2015-2019 Redistributables installed (Control Panel -> Programs...).

[manolito]

Tip:
Always use this All-In-One VC++ redist package from Abbodi and be happy...
https://github.com/abbodi1406/vcredist/releases

[Music Fan]

Thanks ; if I install this package, does it mean I don't have to take the vcredist version ? No risk of conflict if I install it anyway ?

[manolito]

Thanks ; if I install this package, does it mean I don't have to take the vcredist version ? No risk of conflict if I install it anyway ?

Yes and Yes...:D

[Music Fan]

Ok thanks, that seems evident but I prefer to be prudent before to install something ;)

[Music Fan]

Houston, we have a problem :o
Since I re-installed AVS+ (AviSynthPlus-3.5.1_20200402.exe), I get lots of error messages ("can't open avs file", "function does not exist" ...) : I installed all 64 bit dlls in the plugins64+ directory, but Avisynth is installed in C:\Program Files (x86), is that the problem ?
It was the proposed directory during installation.
With the function version(), I see "r3106, 3.5, i386".

I'm a little bit lost now :o, how to install 64 bit version correctly, and which plugin folder to use ? Does it depend on the functions (32 bit in plugins+ and 64 bit in plugins64+) ?

And if it's a 32 bit only version, why are there plugins64 folders ?

[wonkey_monkey]

A long time ago, I pointed out a bug in bicubicresize - well, not so much bicubicresize, but resizing code in general, although by default it only exhibits with bicubicresize.

The problem is that bicubicresize, with its default parameters of b=1/3, c=1/3, is not a "nulll filter" when no resize/shift takes place - it actually blurs the image, because it has non-zero lobes even when the offset is 0.

That's bad already to me, since to me a good resizer should have a null effect if no resize or shift is taking place - and indeed it does, but only because Avisynth tests for and skips resampling in such cases. But it shouldn't, and I seem to remember this skip was removed when I pointed out the problem (I can't remember if pinterf was running the show at the time), which is that doing this skip results in a discontinuity when using bicubicresize.

However it seems that this fix has been reverted somewhere along the way, resulting, once again, in this:

https://i.imgur.com/o0Hc2Ji.gif

This is a very slow scroll of an image by animating the src_top and src_left parameters of bicubicresize. Hopefully you can spot the "jump" when those parameters reach 0,0 and resampling is skipped.

Long story short: resampling should never be skipped - in either direction - just because there is no offset and the scale factor is 1. Not just because bicubicresize has silly default parameters (I know, I know, backwards compatibility...) but because you never know what parameters people may be using with resizers. Actually it may be that Gaussresize is the only other filter currently affected because of its p parameter, but I think it would be good practice to skip this premature optimisation anyway, to protect any future changes.

[StainlessS]

A long time ago, I pointed out ... Bicubicresize,

Post by Colors[I think he's talking bout same thing]:- https://forum.doom9.org/showthread.php?p=1689608#post1689608

Long Time Ago Wonkey Thread:- https://forum.doom9.org/showthread.php?p=1849699

[pinterf]

But it shouldn't, and I seem to remember this skip was removed when I pointed out the problem (I can't remember if pinterf was running the show at the time), which is that doing this skip results in a discontinuity when using bicubicresize.

I have found:

20181218 r2768
- Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces


One single case remained though when frame is unaltered : when starting from exact x = 0 (or y = 0) and use exact width (height).

Horizontal and vertical cases are decided separately.

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L2464

[pinterf]

VS r1 has identical output to AddGrainC 1.71.
The difference comes from here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-AddGrain/commit/8f272c4b7aa3c32e5f6e2b19b20ff4dcb8dad481).
Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

[MeteorRain]

Do you guys have a list of tools+functions+parameters path combination that you think are critical (widely used by various of scripts) but lack AVX optimization or internal parallelism that I should start looking soon?

I'm thinking about mvtools and mask tools, but then I wonder if there are hot paths that I should focus on first because they are pretty huge.

[ChaosKing]

The only filters I can think of right now would be removegrain + nnedi3, maybe also dfttest.

[pinterf]

Is there any benefit of internal parallelism in real life other than in synthetic single-threaded tests?

[Boulder]

Do you guys have a list of tools+functions+parameters path combination that you think are critical (widely used by various of scripts) but lack AVX optimization or internal parallelism that I should start looking soon?

I'm thinking about mvtools and mask tools, but then I wonder if there are hot paths that I should focus on first because they are pretty huge.

Those two are probably things that are shared by many functions and processes, MaskTools maybe the bigger portion. Maybe you could get some AVX2 things off the Vapoursynth core ported?

[MeteorRain]

Is there any benefit of internal parallelism in real life other than in synthetic single-threaded tests?

You can imagine I'm still not a fan of MT flavor~:devil:

[pinterf]

Well, you could try mvtools2.

- replace existing internal mt of mvtools which is not portable (possible linux build in mind) and requires an external avstp dll.
It was probably written well before that any standard mutex or threading concept appeared in C++ standards.

Supported functions have a bool "mt" parameter, search for them in mvtools2.html in the documentation.

- (portability) where dct 1..4 is used in the analysis, there fftw library is used (except for 8 bit 8x8 blocks which case is using integer fft)

I have done smaller and larger cleanups in the past, even succeeded to build the source with clang just this week.

[Reel.Deel]

Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

Thank you pinterf. You're awesome! :)

I updated the wiki also, I know you always do it but your time is too valuable to be doing those things.


****
Edit: I think the syntax for AddGrain() you be kept as it originally was for compatibility with some older scripts (one example: MCSpuds (http://avisynth.nl/index.php/MC_Spuds)). I don't there are many that use AddGrain(). The VS version was ported and just stuck with the syntax of AddGrainC but without the C. VS started from scratch so it was not a problem since all of the scripts had to be re-written anyways.

[jpsdr]

The only filters I can think of right now would be removegrain + nnedi3, maybe also dfttest.
I've allready added AVX and AVX2 on nnedi3, and it always had internal multi-threading since the begining, even before i work on it.

[FranceBB]

Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

On the changelog I read

"Support Avisynth+ high bit depth"

however when I try to use it with 10bit planar or 16bit planar, it reports an access violation.
This is a pretty silly test, however it makes it crash:

ColorBars(width=848, height=480, pixel_type="YV24")

ConvertBits(10)

AddGrainC(var=5.0, uvar=0.0, constant=true)

https://i.imgur.com/iLMXGoB.png

so does this:


ColorBars(width=848, height=480, pixel_type="YV24")

ConvertBits(16)

AddGrainC(var=5.0, uvar=0.0, constant=true)


https://i.imgur.com/iLMXGoB.png

https://i.imgur.com/e20Y6qo.png

while the 8bit planar one works like a charm:

ColorBars(width=848, height=480, pixel_type="YV24")

AddGrainC(var=5.0, uvar=0.0, constant=true)

https://i.imgur.com/YWtLvGH.png

https://i.imgur.com/gfajmS6.png

I thought the culprit was the fact that it was 4:4:4, but even specifying 4:2:0 doesn't help with high bit depth:

ColorBars(width=848, height=480, pixel_type="YV12")

ConvertBits(16)

AddGrainC(var=5.0, uvar=0.0, constant=true)

https://i.imgur.com/JzotLTg.png

however if I use the default values, it works:


ColorBarsHD(width=704, height=396, pixel_type="YV24")

ConvertBits(16)

AddGrainC()


https://i.imgur.com/YZXovTw.png


Is there something I should be aware of when I use the parameters with high bit depth? Like they don't scale automatically and cause some kind of error or something?

[pinterf]

Investigating

[pinterf]

Cannot reproduce. Is it the same Avisynth version (my second test build) which you had troubles with?

[pinterf]

Thank you pinterf. You're awesome! :)

I updated the wiki also, I know you always do it but your time is too valuable to be doing those things.


****
Edit: I think the syntax for AddGrain() you be kept as it originally was for compatibility with some older scripts (one example: MCSpuds (http://avisynth.nl/index.php/MC_Spuds)). I don't there are many that use AddGrain(). The VS version was ported and just stuck with the syntax of AddGrainC but without the C. VS started from scratch so it was not a problem since all of the scripts had to be re-written anyways.

Thanks, reasonable request.

[pinterf]

Next test please

https://github.com/pinterf/AddGrainC/releases/tag/v1.8.1

Original parameters restored, simd noise blocks use now unaligned load (possible solution to FranceBB's crash?)