Avisynth+

[wonkey_monkey]

Excellent, I shall optimise to my heart's content. I only have AVX though :(

[StainlessS]

Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)


Colorbars(pixel_type="YV12")
ConvertBits(10) # return this looks ok
return ConvertToY8 # EDIT: ConvertToY() Same

https://i.postimg.cc/4yGRxYNP/zzz-00.jpg (https://postimages.cc/)

EDIT: With info added
https://i.postimg.cc/0yXfkh2H/zzz-02.jpg (https://postimages.cc/)

Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.php?p=1868592#post1868592
2nd code block


ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411 # ConvertBits Will Fail
#ConvertToY8 # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.


Think was also reported in Avs+ thread, but cannot find it.

Please ignore this post.

EDIT: Dec 2018, Wonkey_Monkey already reported problem here:- https://forum.doom9.org/showthread.php?p=1860916#post1860916

Pinterf response
Thanks. Seems that it's not guarded by an error message to allow only 8 bit sources. Based on the upside down result, it simply runs on the 8 bit packed rgb case.

[wonkey_monkey]

pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.

[pinterf]

pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.
Are you missing the 4:2:2 colorspaces such as YV16? The others seem to be supported (source: online documentation)

[wonkey_monkey]

Those, and RGB24/48. I'm trying to be more inconclusive these days and to make sure my filter is fast for every colour space :)

The YUV float colour spaces seem to be wrong (unbiased chroma?):

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

[pinterf]

The YUV float colour spaces seem to be wrong (unbiased chroma?):


Yeah, unbiased chroma. I have fixed it in both ColorBars version, those were hopefully the last ones in connection with zero-based chroma thing.

[real.finder]

Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)


Colorbars(pixel_type="YV12")
ConvertBits(10) # return this looks ok
return ConvertToY8 # EDIT: ConvertToY() Same

https://i.postimg.cc/4yGRxYNP/zzz-00.jpg (https://postimages.org/)

EDIT: With info added
https://i.postimg.cc/0yXfkh2H/zzz-02.jpg (https://postimages.org/)

Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.php?p=1868592#post1868592
2nd code block


ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411 # ConvertBits Will Fail
#ConvertToY8 # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.



I just test this with ConvertToY (which should be ok)

Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY


yes there are bug here

edit: it seems mpc problem
Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY
ConvertBits(8)

work ok

[pinterf]

Test build r2888
https://drive.google.com/open?id=1nfbYGSHFtxfDfkgT7Pnn7KziYTf0BO_Q

For new features and fixes since r2772 see readme_history.txt or the shorter readme.txt.

[Wilbert]

Yep, since months, I will do it as soon as I have time. Probably soon.

And then? Since ultim recently gave us access to the original Avisynth+ repo, we'll have to think about what to do next.
I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.

[qyot27]

I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.
If we were going to go with 0.x versioning, IMO it would be 0.4. 0.2 was very nearly officially released around the r1828 mark, and 0.3 would very likely have been the addition of high bit depth pixfmts and GCC compliancy, with 0.4 being where we'd be now.

That said, I've been leaning more toward jumping the major version too (https://github.com/qyot27/AviSynthPlus/commit/cd0189a28de97da6655e74ac58f29117c00a7235) (that's still in a development branch; I won't push it upstream unless/until there's discussion about it). Namely because there are programs that check for version numbers and got confused by AviSynth+ starting over at 0.x (sure, the proper way would have been to check AVISYNTH_INTERFACE_VERSION, but there's also user confusion over the versioning, and the inadequacy of using sequential revisions on the idea of integrating with pkg-config).

[pinterf]

Meanwhile a question that emerged over another topic, since I wasn't able to compile a C plugin with Visual C++ which was recognized as a C plugin in both Avisynth+ and classic Avisynth 2.6

The code inside the different Avisynth versions is trying to identify a DLL as a C plugin by searching the following entries:

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)

The common solution would be using avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6.
Unfortunately this kind of semi-decorated name is not supported in VC++ (at least I was not able to do it)

The other choice: the non-decorated avisynth_c_plugin_init is not recognized by Avisynth+.

Question (if somebody remembers):
- why are C plugins identified differently in Avisynth+
- does it have any drawback if I put back the support for the nondecorated name?

[pinterf]

@Wilbert: yes, changing version number makes sense.


That said, I've been leaning more toward jumping the major version too (https://github.com/qyot27/AviSynthPlus/commit/cd0189a28de97da6655e74ac58f29117c00a7235) (that's still in a development branch; I won't push it upstream unless/until there's discussion about it). Namely because there are programs that check for version numbers and got confused by AviSynth+ starting over at 0.x (sure, the proper way would have been to check AVISYNTH_INTERFACE_VERSION, but there's also user confusion over the versioning, and the inadequacy of using sequential revisions on the idea of integrating with pkg-config).
Seems logical. You mentioned pkg-config in your comment it's only for your linux environment?
I wonder how many programs or scripts rely on checking "0.1" or "MT" in version string?

[Groucho2004]

I wonder how many programs or scripts rely on checking "0.1" or "MT" in version string?I wouldn't worry about that. Whatever scripts and/or programs rely on this will be updated. After all, making AVS+ clearly distinguishable without script acrobatics should be the target.

[StainlessS]

making AVS+ clearly distinguishable without script acrobatics should be the target.
++1.

small prob,(tested only on current test version r2890) [confusing at the very least],


ERROR=""
Colorbars(Width=1024,Height=64,Pixel_type="YUV444P10")
ORG=Last
try {
ORG.BilinearResize(2,1) # Dest height of 1 problem
}catch (msg){
ERROR=ERROR + Msg + "\n"
RT_Debugf("Msg1=%s",msg)
}

try{
ORG.BilinearResize(1,2) # Dest width of 1 problem
}catch (msg) {
ERROR=ERROR + Msg + "\n"
RT_Debugf("Msg2=%s",msg)
}
ORG.Subtitle(ERROR,lsp=0)

https://i.postimg.cc/FRm4wX4C/test-00.jpg (https://postimages.org/)

Think I posted about this in avs Standard thread, dont know if it got fixed there.

EDIT: Pixel_type not problem, same with Pixel_type="YV24".

EDIT: 2 posts later deleted, was Rubbish. [EDIT: I can understand why source has minimum requirement, why dest does is mysterious]

[pinterf]

small prob,(tested only on current test version r2890) [confusing at the very least],


ORG.BilinearResize(2,1) # Dest height of 1 problem
...
ORG.BilinearResize(1,2) # Dest width of 1 problem


Resizer algorithms all have a minimum width/height requirement which is not fulfilled here. Regarding the error message: yep, not really human understandable. "Don't do that next time please" would be more than enough.

[qyot27]

Seems logical. You mentioned pkg-config in your comment it's only for your linux environment?
Not entirely. pkg-config can be used on Windows (particularly inside MSys2, Cygwin, etc.) or in cross-compile environments, and programs that want to link to AviSynth can refer to the pkg-config file to make sure things like the library location, includes, and any other required libraries and flags are passed to the configuration. It does generally favor the GCC or Clang-mimicking-GCC side, though, since CMakeLists.txt doesn't use the normal *nix FHS conventions when using MSBuild (although it will if using MSVC with either NMake Makefiles or Ninja).

I also use it to get the Version information parsed for the checkinstall step in the cross-compile guide (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L4340), as pulling the version from the .pc file is generally easier than wrangling with other means of getting it.

[qyot27]

Meanwhile a question that emerged over another topic, since I wasn't able to compile a C plugin with Visual C++ which was recognized as a C plugin in both Avisynth+ and classic Avisynth 2.6

The code inside the different Avisynth versions is trying to identify a DLL as a C plugin by searching the following entries:

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)

The common solution would be using avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6.
Unfortunately this kind of semi-decorated name is not supported in VC++ (at least I was not able to do it)

The other choice: the non-decorated avisynth_c_plugin_init is not recognized by Avisynth+.

Question (if somebody remembers):
- why are C plugins identified differently in Avisynth+
- does it have any drawback if I put back the support for the nondecorated name?

The different styles it looks for are one used by MSVC and one by GCC, based on what bittage the binary is. On MSVC's side,
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019#FormatC:
The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. This is also the decoration format that is used
when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. Note that in a 64-bit environment, functions are not decorated.
Calling convention Decoration
__cdecl Leading underscore (_)
__stdcall Leading underscore (_) and a trailing at sign (@) followed by the number of bytes in the parameter list in decimal
_cdecl and _stdcall are the only relevant ones here. The Win32 decorations as provided by MSVC would be _function@X if left alone. __declspec(dllexport) also causes effects on this.

In GCC, however, the result of _stdcall is function@X and _cdecl is function. The C interface was initially designed to allow plugins that could be built with GCC, so 2.6 looks explicitly for GCC's conventions (it would appear).

http://www.willus.com/mingw/yongweiwu_stdcall.html

Essentially, when using _cdecl, MSVC agrees with GCC in only two instances: __declspec(dllexport) and using a .def file. With _stdcall, MSVC and GCC never match (although this is mostly the fault of GCC or MinGW not prefixing the _stdcall functions with a leading underscore; I remember this being difficult to manuever in regard to the FFMS2 C-plugin and external programs using it as a substitute for the normal C++ plugin, not sure if it was ever satisfactorily resolved).

On 64-bit, thankfully, there is only one valid decorating scheme, function. MSVC and GCC both agree on this, and this is why 64-bit programs can use either MSVC or GCC builds of AviSynth+, but 32-bit programs cannot (leading to the need for that rat's nest in avs/capi.h with the AVSC_WIN32_GCC32 define).

What's true of the AviSynth library itself interacting with a host program like FFmpeg is just as true of plugins interacting with the AviSynth library itself.

My guess is that AVSInpaint is not utilizing any sort of dllexport mechanics, so it's falling back onto the default behavior based on the compiler. A Github search seems to agree here:
https://github.com/pinterf/AvsInpaint/search?q=dllexport&unscoped_q=dllexport
vs FFMS2 (where the dllexport stuff is common to both C++ and C interfaces):
https://github.com/FFMS/ffms2/blob/master/include/ffms.h

Making this more headache-inducing, the C plugin tutorial on the AviSynth Wiki and docs don't even mention the dllexport approach with _stdcall, so there's probably a greater-than-average chance a random C plugin won't be using that, and instead will just be using _cdecl (fine for 64-bit, not fine for 32-bit). Like I said in the other thread, it's a nightmare.

[wonkey_monkey]

YV16 is said to be the planar equivalent of YUY2, but chroma placement seems to be treated differently when converting each of those to RGB32. Is that correct? Or at least, not wrong?

PS converttoyuy2 from a YUVA colourspace appears to be faulty.

[Wilbert]

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)
It also supports avisynth_c_plugin_init@4 through a definition file right?

LIBRARY InvertNeg.dll
EXPORTS
avisynth_c_plugin_init@4=_avisynth_c_plugin_init@4

Or do i miss something?

[Wilbert]

Making this more headache-inducing, the C plugin tutorial on the AviSynth Wiki and docs don't even mention the dllexport approach with _stdcall, so there's probably a greater-than-average chance a random C plugin won't be using that, and instead will just be using _cdecl (fine for 64-bit, not fine for 32-bit). Like I said in the other thread, it's a nightmare.
Feel free to add this.

A long time ago i added the following

AVSC_CC stands for Avisynth calling convention. Right now it is stdcall (it used to be cdecl when the C interface was exposes through seperate plugin). By using AVSC_CC you should be able to maintain source code compatibility when the calling convention changes.

to http://avisynth.nl/index.php/Filter_SDK/CInvertNeg

But i forgot to add what happens if you use cdecl despite this. If you do, is the issue that you can't compile the plugin with MSVC then? Are there more issues?

[qyot27]

Feel free to add this.
I feel like I need to fully understand the intricacies of it first before trying to do so. As I describe below, my grasp on it is pretty shaky. Even my last post about it I was really uncertain if I was confusing things.

A long time ago i added the following

to http://avisynth.nl/index.php/Filter_SDK/CInvertNeg

But i forgot to add what happens if you use cdecl despite this. If you do, is the issue that you can't compile the plugin with MSVC then? Are there more issues?
It makes my head hurt every time I try thinking about it. I think I figure it out, then test it to find it's completely wrong, go back to what I thought I was doing before, and it's wrong too. And then I try to cool off for a couple days and approach it later, only to completely forget what I did a couple days ago. I suppose what it needs is a thorough, case-by-case test of the different possible configurations to see which instances are valid under which compiler (and which fail to build at all), and under which build of AviSynth+.

Not to mention the possible incompatibilities that might arise if the dev library of AviSynth is from a MSVC or GCC build, and then attempting to use that sort of plugin build with the AviSynth+ host built by the other. Because I think that might have been where I was hitting a snag when I was playing around with AVSInpaint before pinterf updated it.

[pinterf]

It also supports avisynth_c_plugin_init@4 through a definition file right?

Or do i miss something?

Thanks! I didn't try this one.

[pinterf]

YV16 is said to be the planar equivalent of YUY2, but chroma placement seems to be treated differently when converting each of those to RGB32. Is that correct? Or at least, not wrong?

PS converttoyuy2 from a YUVA colourspace appears to be faulty.
Thanks, I'll check it. Meanwhile you can try ColorBars with 4:2:2 and 4:1:1 color spaces, though latest test build is still w/o rgb24/48 support, but since then I've done it, see git source.

[StainlessS]

Might be nice if ResetMask() was ignored silently if non Alpha channel colorspace [can be awkward handling Layer using ResetMask only if alpha channel to be ignored, ie alpha=255/max].

EDIT: Maybe silent ignored only if Float Mask non supplied or supplied as max for colorspace.
EDIT: Should also be documented thusly.

Current docs
ResetMask

Applies an opaque (white) alpha channel to a clip. The alpha channel of an RGB32 clip is not always well-defined, depending on the source (it may contain random data); this filter is a fast way to apply an all-white mask.

ResetMask(clip clip)

ResetMask(clip clip, float mask) AVS+

clip clip =

Source clip. Alpha channel will be set to opaque. Color format must be RGB32.
AVS+ also supports RGB64, PlanarRGBA and YUVA.

mask float =

AVS+ Optional mask value to set. No bit-depth scaling occurs, but value is clipped to be between 0 and maximum_pixel_value.
Maximum opacity is 1.0 for 32 bit float formats, and (1^bit_depth) - 1 for 8-16 bit formats

[StainlessS]

Dont think this posted as yet (results from r2890 test build).


# E_1
W=100 H=100
Colorbars(Pixel_Type="RGBAP16")
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA)
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)
Return last

Seem to be using rubbish plane (results different every time).
https://i.postimg.cc/8jMhhnGF/E-1-00.jpg (https://postimg.cc/8jMhhnGF)


This one produces Access Violation [EDIT: x86/x64].

# E_2
W=100 H=100
Colorbars
ConvertToPlanarRGBA
ConvertBits(16)
# EDIT: Below, same as above E_1 code block
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Maybe the Alpha plane is rubbish (main clip or blankclip. EDIT: As main clip alpha not really used on layer, probably BlankClip Overlay Alpha).
EDIT: Below extract Alpha looks ok for both Main and Overlay clips ??? [EDIT: Also main and Overlay clips both look alright]

# E_2
W=400 H=400
Colorbars
ConvertToPlanarRGBA
ConvertBits(16)
#Return Last.ExtractA.info # Solid black 16 Bit
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
#Return O.ExtractA.info # Solid white 16 bit
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)

EDIT: Outputting x and y Layer coords and also Lev for above code block to debugView produce x=120 y=40 Lev=$FFFF, so nothing weird there.
EDIT: Maybe some bad intermediate clip/buffer is used during Layer.
EDIT: ConvertBits(8) as last step still crash PotPlayer and VDub2, so problem not external to Avs+.
EDIT: Layer with Lev=0, still crash.
EDIT: Source as John Meyer Parade clip YV12, Resized to 640x480, instead of colorbars source, same result, still crashes, seems unrelated to colorbars.
EDIT: Remove ConvertBits(16), still crashing on 8 bit planar [convinced I tried that before posting and it did not crash].

# E_3
W=400 H=400
Colorbars
ConvertToPlanarRGBA # 8 bit Planar
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF)
Layer(O,op="add", Level=0,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Change "add" to Layer(op="fast"), looks OK when W and H = 400, but a bit screwey when 100 ??? ... No Crash, but surely Level=0 should be no change to colorbars.
EDIT: No, 'fast' is just average of the two and does not use level, so should look different, but still a bit screwy when W and H = 100.

# E_3
W=400 H=W
Colorbars
ConvertToPlanarRGBA # 8 bit Planar
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF)
Layer(O,op="fast", Level=0,x=(Width-O.width)/2,y=(Height-O.Height)/2)

https://i.postimg.cc/jwkJ4qSs/E-4-01.jpg (https://postimg.cc/jwkJ4qSs)


EDIT: "Subtract"/"mul"/"lighten"/"darken", all sometimes crash, sometimes dont. Gotta be Layer (when dont crash just looks like plain colorbars [which it should I suppose b'cos Level=0]).

EDIT: Dont know if intended to work or not[no alpha], but below also crashes.

W=400 H=W
Colorbars
convertToPLanarRGB # RGB 8 bit planar no alpha
O=Last.BlankClip(width=W,height=H,Color=$000000FF) # blue, no alpha
Layer(O,op="add", Level=$7F,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Thus far, I aint found any problems with YUV/A, but I'll be playing a lot with Layer over next few days, and if there are probs, I'm just the one to find em'. :)

EDIT: Nuther prob with float RGB/RGBA, access violation.

W=400 H=W
Colorbars
convertToPlanarRGBA
ConvertBits(32) # RGB Float Alpha OR no alpha, both crash
BCol = (Last.HasAlpha) ? $FF0000FF : $000000FF
O=Last.BlankClip(width=W,height=H,Color=BCol)
Layer(O,op="add", Opacity=0.5,x=(Width-O.width)/2,y=(Height-O.Height)/2) # Using secret Opacity arg instead of int Level
ConvertBits(8)


EDIT: Hi again P, you must be getting a bit sick of me by now, well I'm not yet done :)
Nuther Layer prob, slightly different.
Set X=20, and no probs, layers blankclip all the way to RHS and bottom.
Set X=18, and leaves a two pixel gap at RHS and bottom of frame, only works correctly when X multiple of 4. [If YUY2 then bottom OK, only RHS green line]

BlankClip(width=640,height=480,Pixel_type="YV12",Color=$00FF00)
X=18
Y=X
W=Width-X
H=Height-Y
Q=Last.BlankClip(Width=W,Height=H,color=$FFFF00FF)
#Return Q.Info
Layer(Q,op="add",Level=255,x=X,y=Y)
Subtitle(String(X,"X=%.0f"))
return last

First, X=20
https://i.postimg.cc/BQ7xhRfT/X-20.jpg (https://postimages.org/)
X=18
https://i.postimg.cc/L65PZvgn/X-18.jpg (https://postimages.org/)

EDIT: YV411: X=20
https://i.postimg.cc/q7swZQLp/YV411-20.jpg (https://postimages.org/)

EDIT: The above YV411/YUY2/YV12 problem exists for r2790 too, and persists for YV12 when ConvertBits(16), not tried others, gorra get some sleep.

I'll keep ya bizzy :)

[pinterf]

Thank you S'ssS, really, there's a good reason behind every crashes: to keep you busy. Anyway all those weird things will be investigated and fixed - though I have more serious things to do such as apricot marmelade cooking, I wish I could do programming and cooking at the same time. :)

EDIT: crashes were caused by wrongly indexing the mask clip. (r2894)
EDIT2: problems with X and Y offsets fixed (r2895)

new Avisynth+ r2895 test build
https://drive.google.com/open?id=1FCby_dSxnpPmMkCnEhr22zsCtnWiEo9W

As for the secret :) parameter "opacity", here I copy the new things around "Layer", I'll edit wiki as well later
- Layer: big update
Previously Layer was working only for RGB32 and YUY2. Overlay was used primarily for YUV. Now Layer accept practically all formats (no RGB24).
Note that some modes can be similar to Overlay, but the two filters are still different.
Overlay accepts mask clip, Layer would use existing A plane.
Overlay "blend" is Layer "add", Overlay "add" is different.
Lighten and darken is a bit different in Overlay.
Layer has "placement" parameter for proper mask positioning over chroma.

- Support for all 8-32 bit Y and planar YUV/YUVA and planar RGB/RGBA formats
When overlay clip is YUVA and RGBA, then alpha channels of overlay clip are used (similarly to RGB32 and RGB64 formats)
Non-alpha plane YUV/planar RGB color spaces act as having a fully transparent alpha channel (like the former YUY2 only working mode)

Note: now if destination is YUVA/RGBA, the overlay clip also has to be Alpha-aware type.
Now A channel is not updated for YUVA targets, but RGBA targets do get the Alpha updated (like the old RGB32 mode did)
Todo: allow non-Alpha destination and Alpha-Overlay
- New parameter: float "opacity" (0.0 .. 1.0) optionally replaces the previous "level". Similar to "opacity" in "Overlay"
For usage of "level" see http://avisynth.nl/index.php/Layer
"opacity" parameter is bit depth independent, one does not have to trick with it like with level (which was maxed with level=257 when RGB32 but level=256 for YUY2/YUV)
- threshold parameter (used for lighten/darken) is autoscaled.
Keep it between 0 and 255, same as it was used for 8 bit videos.
- new parameter: string "placement" default "mpeg2".
Possible values: "mpeg2" (default), "mpeg1".
Used in "mul", "darken" and "lighten", "add" and "subtract" modes with planar YUV 4:2:0 or 4:2:2 color spaces (not available for YUY2)
in order to properly apply luma/overlay mask on U and V chroma channels.
- Fix some out-of-frame memory access in YUY2 C code
- Fix: Add proper rounding for add/subtract/lighten/darken calculations. (YUY2, RGB32, 8 bit YUV and 8 bit Planar RGB)
- Fix: "lighten" and "darken" gave different results between yuy2 and rgb32 when Threshold<>0
Fixed "darken" for RGB32 when Threshold<>0
Fixed "lighten" and "darken" for YUY2 when Threshold<>0
All the above was done by specification:
Add: "Where overlay is brigher by threshold" => e.g. Where overlay is brigther by 10 => Where overlay > src + 10
Calculation: alpha_mask = ovr > (src + thresh) ? level : 0;
Add: "Where overlay is darker by threshold" => e.g. Where overlay is darker by 10 => Where overlay < src - 10
Calculation: alpha_mask = ovr < (src - thresh) ? level : 0;
The only correct case of the above was "lighten" for RGB32, even in Classic Avisynth. Note: Threshold=0 was O.K.
- (Just an info: existing lighten/darken code for YUY2 is still not correct, messing up chroma a bit,
since it uses weights from even luma positions (0,2,4,...) for U, and odd luma positions (1,3,5,...) for V)

[real.finder]

new Avisynth+ r2894 test build


will the next stable update will have MT runtime (https://forum.doom9.org/showthread.php?p=1876610#post1876610) fix and this (https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150) and this (https://forum.doom9.org/showthread.php?p=1873360#post1873360)? :)

[pinterf]

will the next stable update will have MT runtime (https://forum.doom9.org/showthread.php?p=1876610#post1876610) fix and this (https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150) and this (https://forum.doom9.org/showthread.php?p=1873360#post1873360)? :)
1.) MT runtime: yes I'd like to do it (but probably not in next release - if the "next" means very near future)
2.) First "this" (unload plugin DLLs and reload only which needed): probably not.
3.) What's wrong with the second "this"?

[StainlessS]

New test build, ..., you dont get rid of me that easily.


Function StringRepeater(String BaseS, String RepS, int n) { # https://forum.doom9.org/showthread.php?p=1878193#post1878193
# Add n instances of repeat string RepS, to base string BaseS.
return (n>=1) ? StringRepeater(BaseS+RepS,RepS,n-1):BaseS
}

Blankclip(color=$FFFFFF)
ConvertToRGB24
#ConvertToRGB48
#ConvertToRGB64
S=StringRepeater("Last",".Blur(1.58)",500)
Eval(S)
return last.Info


RGB24 [RGB32 & RGB48 similar]
https://i.postimg.cc/FKBWLvpw/SRep24.jpg (https://postimages.org/)

RGB64
https://i.postimg.cc/XY873HLr/SRep64.jpg (https://postimages.org/)

"Nobody expects the Spanish Inquisition". :)

[pinterf]

New test build, ..., you dont get rid of me that easily.

Nice catch. Fixed on git: RGB64 Blur leftmost column artifact

No new build, you'll probably find more glitches.

[real.finder]

3.) What's wrong with the second "this"?

it can't has "universal Expr" https://forum.doom9.org/showthread.php?p=1873444#post1873444

[StainlessS]

you'll probably find more glitches.
Hope not but you never can tell.
Getting there step by step, looking quite good.
Looks like S_ExLogo may support all colorspaces that layer supports. [wonder if we have to support YAxx at some point (internally, dont think exists externally, <maybe just strip alpha>)]
https://i.postimg.cc/dLMSNk4b/test-zz.jpg (https://postimg.cc/dLMSNk4b)
Thanks muchly for all of the nice new Layer() stuff, we is gettin' there. :)

[pinterf]

it can't has "universal Expr" https://forum.doom9.org/showthread.php?p=1873444#post1873444

Universal (lut or Expr) expressions make us lazy. I have already put thousands of hacks into the lut and Expr expression syntax.
But sometimes we have to use "IF float ELSE ".

32 bit float expressions can be tricky, using a generic expression would be sub-optimal for lower bit depths.

Anyway, this one seems to work properly for me (I'm using different y and u/v expression) for both 16 and 32 bits:

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)

I'd rather use Expr for high bit depth (speed)

[real.finder]

Universal (lut or Expr) expressions make us lazy. I have already put thousands of hacks into the lut and Expr expression syntax.
But sometimes we have to use "IF float ELSE ".

32 bit float expressions can be tricky, using a generic expression would be sub-optimal for lower bit depths.

Anyway, this one seems to work properly for me (I'm using different y and u/v expression) for both 16 and 32 bits:

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)

I'd rather use Expr for high bit depth (speed)

I am with you here, but sometimes these lazy friendly things help even for none lazy people in testing purpose

I will use "IF float ELSE" only if the lazy method slower :)

[pinterf]

I am with you here, but sometimes these lazy friendly things help even for none lazy people in testing purpose

I will use "IF float ELSE" only if the lazy method slower :)
Passing a differently assembled expression can affect performance and sometimes worth doing it.

Unlike the lut family, Expr can use constant folding internally when it pre-scans an expression. The expression e.g. range_max - range_min (RPN: "range_max range_min -") is a constant expression known before JIT compilation is done, so it'll be replaced with a single constant. (Other optimizations exist in Expr preprocessor such as eliminating "*1" and "+0", replacing "x power 2" with a much faster x*x, etc...)

Since lutxyz is not using JIT (Just In Time) compilation, the subtraction is done as a separate step. In lut versions where the lookup table is precalculated (e.g. lutxyz in 8 bits) this does not affect performance much because the actual expression evaluation is done once during filter creation (unless it's working in a runtime evaluated function, because the size of this lut is 256*256*256 = 16777216 which takes significant time if expression is complex).

[GillesH]

Quick test with the latest AVS+ r2895.
With a active RunTime Function in MT Mode, I no longer have the error message reported to the first post of this topic.
https://forum.doom9.org/showthread.php?t=176502
But, total freezing of the script with active MT (Prefetch).

RunTime Functions works, always, normally WITHOUT MT.

[LouieChuckyMerry]

Hello. I'm attempting to graduate from AviSynth+ x86 to AviSynth+ x64 but I'm encountering difficulty. With Win 7 x64 and MeGUI, my standard script:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
ConvertToDoubleWidth()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
ConvertFromDoubleWidth()
PreFetch(X)

runs fine with MeGUI x86-AviSynth+ x86. When I try to run the same script with MeGUI x64-AviSynth+ x64, I can index, load, and start the script without a problem, but receive the error message "H.264 (MPEG-4 AVC) encoder has stopped working" within a few seconds of starting it. However, if I hash-out the "F3KDB" lines thusly:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
# ConvertToDoubleWidth()
# F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
# ConvertFromDoubleWidth()
PreFetch(X)

the script runs without a problem. I've the minimum plugins necessary for x86 and x64: Dither(_64bit).dll, F3KDB(_64bit).dll, FastLineDarkenMTMod1_44.avsi, MaskTools2_2_18_0MTDualSignatureMod_pinterf(_64bit).dll, MVTools2_7_41_0MTMod_pinterf(_64bit).dll, and SMDegrainMod_rf_3.1.2.101s.dll.

I realize this possibly (probably) isn't an AviSynth+ issue but I couldn't come up with a better place to post a question given the number of geniuses frequenting this thread. Thanks for any redirection or help :) .

[Natty]

try adding input and output depth parameters in f3kdb

[qyot27]

Don't try to use MeGUI to debug anything. Pass the script to AVSMeter or FFmpeg (or mpv) or x264 itself and see what error gets thrown there. Because I can almost guarantee you it's because you're using the new AviSynth+ high bit depth-compatible build of f3kdb and yet still using the input_mode and output_mode parameters, which were removed (technically also the DoubleWidth conversions, but that's mostly because they're irrelevant now, not because they'd actually cause an error).

[FranceBB]

Because I can almost guarantee you it's because you're using the new AviSynth+ high bit depth-compatible build of f3kdb and yet still using the input_mode and output_mode parameters, which were removed (technically also the DoubleWidth conversions, but that's mostly because they're irrelevant now, not because they'd actually cause an error).

This is exactly the reason why I expressed my reluctance in removing 16bit stacked and interleaved in f3kdb here https://forum.doom9.org/showthread.php?t=176553&page=2

And this is just a script that calls f3kdb directly.
Think about how many other plugins/filters are there, who requires f3kdb as a dependency and who call it using those parameters!

[Groucho2004]

Meanwhile a question that emerged over another topic, since I wasn't able to compile a C plugin with Visual C++ which was recognized as a C plugin in both Avisynth+ and classic Avisynth 2.6

The code inside the different Avisynth versions is trying to identify a DLL as a C plugin by searching the following entries:

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)

The common solution would be using avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6.
Unfortunately this kind of semi-decorated name is not supported in VC++ (at least I was not able to do it)

The other choice: the non-decorated avisynth_c_plugin_init is not recognized by Avisynth+.

Why don't you just enumerate all plugin export functions and look for "avisynth_c_plugin_init"? That works for all C-plugins (32 & 64 bit). That way you can also identify all C++ plugs and determine if a plugin is 32 or 64 bit. If you're interested I can put together (and comment :o) the code bits from AVSMeter that you need.

[pinterf]

Isn't it slow?

[Groucho2004]

Isn't it slow?No. I think the current method is slow, just count the number of times you run "GetProcAddress(plugin.Library, "....") on each plugin.
Almost all plugins just have one export so the enumeration is going to be fast. Also, within the same call to "MapAndLoad()" you get the bitness info.
Have a look, the relevant function in AVSMeter is "CAvisynthInfo::GetPluginType" in "AvisynthInfo.h". As I mentioned, I can strip the stuff you don't need and put some comments.

[pinterf]

Sounds interesting. I don't want (= there are other things in my queue) to touch that section right now, but yes, your idea can work.

[real.finder]

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)


I did some test with https://pastebin.com/ade3wBBV (has pmaskmerge and fixed smaskmerge by shifting)


blankclip(length=48,width=720,height=480, color=$00000,pixel_type="YV12")
expr("sx frameno + 32 % 16 < range_half range_max ?","sx frameno 2 / + 16 % 8 < range_half sx 15 / - range_half ?","sx frameno 2 / + 16 % 8 < range_half sx 8 / - range_half ?")
o=last
setbits=32
ConvertBits(setbits) # 32bit float vs 8-16bit integer

video=last
video2=video.trim(20,0)

x1=string(20)
x2=string(600)
y1=string(50)
y2=string(340)
msk=o.expr("sx "+x1+" >= sx "+x2+" <= & sy "+y1+" >= sy "+y2+" <= & & range_max range_min ?", "range_half", "range_half").trim(0,-1).FreezeFrame(0, FrameCount(last)-1, 0)
msk=msk.ConvertBits(setbits) # 32bit float vs 8-16bit integer
##########################

pmaskmerge(video, video2, msk,3,3,3, true).StackVertical(smaskmerge(video, video2, msk,3,3,3, true).Subtitle("smaskmerge"))

ConvertBits(8)

pmaskmerge don't do it, and even if the fixed smaskmerge has many workarounds it's not much slower than pmaskmerge (I think it's because pmaskmerge has additional multiplication in expr)

[Groucho2004]

Sounds interesting. I don't want (= there are other things in my queue) to touch that section right now, but yes, your idea can work.For your reference, below is the latest "GetPluginType()". Every plugin I have thrown at it is correctly detected.

BOOL GetPluginType(std::string sPlugin)
{
BOOL PROCESS_64 = (sizeof(void*) == 8) ? TRUE : FALSE;
BOOL bIs64BitDLL = FALSE;

//The MapAndLoad function maps an image and preloads data from the mapped file.
LOADED_IMAGE li;
BOOL bLoaded = MapAndLoad((LPSTR)sPlugin.c_str(), NULL, &li, TRUE, TRUE);

if (!bLoaded)
{
//error handling, check GetLastError() why the DLL could not be loaded
return FALSE;
}

if (li.FileHeader->FileHeader.Machine != IMAGE_FILE_MACHINE_I386) //check the PE header for bitness
{
bIs64BitDLL = TRUE; //it's a 64 bit DLL
if (!PROCESS_64) //if running a 32 bit process, throw error and return
{
//"Trying to load 64 bit DLL in 32 bit Avisynth"
UnMapAndLoad(&li);
return FALSE;
}
}
else //it's a 32 bit DLL
{
if (PROCESS_64) //if running a 64 bit process, throw error and return
{
//"Trying to load 32 bit DLL in 64 bit Avisynth"
UnMapAndLoad(&li);
return FALSE;
}
}

DWORD expVA = li.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
if (expVA == 0)
{
//error handling -> "Cannot retrieve PE header data"
UnMapAndLoad(&li);
return FALSE;
}

PIMAGE_EXPORT_DIRECTORY pExp = (PIMAGE_EXPORT_DIRECTORY)ImageRvaToVa(li.FileHeader, li.MappedAddress, expVA, NULL);
if (pExp == 0)
{
//error handling -> "Cannot retrieve PE header data", check GetLastError()
UnMapAndLoad(&li);
return FALSE;
}

DWORD rvaNames = pExp->AddressOfNames;
DWORD *prvaNames = (DWORD*)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaNames, NULL);
if (prvaNames == 0)
{
//error handling -> "Cannot retrieve PE header data", check GetLastError()
UnMapAndLoad(&li);
return FALSE;
}


//enumerate DLL exports
DWORD dwName = 0;
std::string sPluginType = "";
for (dwName = 0; dwName < pExp->NumberOfNames; ++dwName)
{
DWORD rvaName = prvaNames[dwName];
std::string sExportFunc((char *)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaName, NULL));
std::transform(sExportFunc.begin(), sExportFunc.end(), sExportFunc.begin(), ::tolower); //convert to lower case for comparison

if (sExportFunc.find("avisynthplugininit3") != string::npos) //CPP 2.6, 32 or 64 bit
{
sPluginType = "AVSCPP26";
break;
}

if (sExportFunc.find("avisynthplugininit2") != string::npos) //CPP 2.5, 32 or 64 bit
{
sPluginType = "AVSCPP25";
break;
}

if ((sExportFunc.find("avisynthplugininit") != string::npos) && !bIs64BitDLL) //CPP 2.0 (these are 32 bit only)
sPluginType = "AVSCPP20"; //don't break here, keep looping

if ((sExportFunc.find("avisynth_c_plugin_init@4") != string::npos) && !bIs64BitDLL) //32 bit C 2.5
{
sPluginType = "AVSC25";
break;
}

if ((sExportFunc.find("avisynth_c_plugin_init") != string::npos) && bIs64BitDLL) //64 bit C 2.5
{
sPluginType = "AVSC25";
break;
}

if ((sExportFunc == "avisynth_c_plugin_init") && !bIs64BitDLL) //C 2.0 (these are 32 bit only)
sPluginType = "AVSC20"; //don't break here, keep looping
}

UnMapAndLoad(&li);

return TRUE;
}

[wonkey_monkey]

converttorgb32 from a 32-bit (float) YUV source results in black, if one of the following matrices is used:

pc.601
pc.709
average

The other matrices and other bit-depths seem to be okay.

[LouieChuckyMerry]

Natty, qyot27, and FranceBB: Thank you for leading me to a solution; updating my F3KDB.dll fixed the problem :) .

[pinterf]

converttorgb32 from a 32-bit (float) YUV source results in black, if one of the following matrices is used:

pc.601
pc.709
average

The other matrices and other bit-depths seem to be okay.
Thank you for the report.
New test build Avisynth+ r2900
https://drive.google.com/open?id=14DJyF9NFPtwU9almef3LX9jCssDt3VeF
Changes since last test build:
- Fix: ConvertToRGB from 32bit float YUV w/ full scale matrixes (pc.601, pc.709, average)
- Fix: FlipHorizontal RGB48/64 artifacts
- Enhanced: a bit quicker FlipHorizontal
- Fix: RGB64 Blur leftmost column artifact

[StainlessS]

Ooooo lovely, thanx P.