Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th June 2019, 07:35   #4761  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
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 is offline   Reply With Quote
Old 28th June 2019, 08:57   #4762  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
@Wilbert: yes, changing version number makes sense.

Quote:
Originally Posted by qyot27 View Post
That said, I've been leaning more toward jumping the major version too (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?

Last edited by pinterf; 28th June 2019 at 09:34.
pinterf is offline   Reply With Quote
Old 28th June 2019, 09:27   #4763  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,359
Quote:
Originally Posted by pinterf View Post
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.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Old 28th June 2019, 10:58   #4764  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 6,952
Quote:
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],

Code:
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)


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]
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 28th June 2019 at 14:47. Reason: Remove nearest barclays bank link
StainlessS is offline   Reply With Quote
Old 28th June 2019, 11:11   #4765  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by StainlessS View Post
small prob,(tested only on current test version r2890) [confusing at the very least],

Code:
    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.
pinterf is offline   Reply With Quote
Old 28th June 2019, 16:56   #4766  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,048
Quote:
Originally Posted by pinterf View Post
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, as pulling the version from the .pc file is generally easier than wrangling with other means of getting it.

Last edited by qyot27; 28th June 2019 at 16:58.
qyot27 is offline   Reply With Quote
Old 28th June 2019, 17:48   #4767  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,048
Quote:
Originally Posted by pinterf View Post
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...-2019#FormatC:
Code:
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/AvsInpain...ed_q=dllexport
vs FFMS2 (where the dllexport stuff is common to both C++ and C interfaces):
https://github.com/FFMS/ffms2/blob/m...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.
qyot27 is offline   Reply With Quote
Old 28th June 2019, 21:06   #4768  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,781
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.
__________________
My AviSynth filters / I'm the Doctor

Last edited by wonkey_monkey; 28th June 2019 at 21:30.
wonkey_monkey is offline   Reply With Quote
Old 28th June 2019, 23:17   #4769  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
Quote:
Originally Posted by pinterf View Post
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?
Quote:
LIBRARY InvertNeg.dll
EXPORTS
avisynth_c_plugin_init@4=_avisynth_c_plugin_init@4
Or do i miss something?
Wilbert is offline   Reply With Quote
Old 28th June 2019, 23:20   #4770  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
Quote:
Originally Posted by qyot27 View Post
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
Quote:
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?
Wilbert is offline   Reply With Quote
Old 29th June 2019, 00:15   #4771  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,048
Quote:
Originally Posted by Wilbert View Post
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.

Quote:
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.

Last edited by qyot27; 29th June 2019 at 00:18.
qyot27 is offline   Reply With Quote
Old 29th June 2019, 10:37   #4772  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by Wilbert View Post
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 is offline   Reply With Quote
Old 29th June 2019, 10:43   #4773  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by wonkey_monkey View Post
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.
pinterf is offline   Reply With Quote
Old 29th June 2019, 17:47   #4774  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 6,952
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
Quote:
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
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 29th June 2019 at 17:58.
StainlessS is offline   Reply With Quote
Old 2nd July 2019, 22:13   #4775  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 6,952
Dont think this posted as yet (results from r2890 test build).

Code:
# 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).



This one produces Access Violation [EDIT: x86/x64].
Code:
# 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]
Code:
# 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].
Code:
# 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.
Code:
# 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)



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.
Code:
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.
Code:
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]
Code:
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

X=18


EDIT: YV411: X=20


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
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 3rd July 2019 at 05:57.
StainlessS is offline   Reply With Quote
Old 3rd July 2019, 06:26   #4776  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
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=1FC...r22zsCtnWiEo9W

As for the secret parameter "opacity", here I copy the new things around "Layer", I'll edit wiki as well later
Code:
- 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)

Last edited by pinterf; 3rd July 2019 at 10:18. Reason: r2895
pinterf is offline   Reply With Quote
Old 3rd July 2019, 09:29   #4777  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,235
Quote:
Originally Posted by pinterf View Post
new Avisynth+ r2894 test build
will the next stable update will have MT runtime fix and this and this?
__________________
My Avisynth Stuff

Last edited by real.finder; 3rd July 2019 at 09:35.
real.finder is offline   Reply With Quote
Old 3rd July 2019, 12:43   #4778  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by real.finder View Post
will the next stable update will have MT runtime fix and this and this?
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"?
pinterf is offline   Reply With Quote
Old 3rd July 2019, 13:08   #4779  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 6,952
New test build, ..., you dont get rid of me that easily.

Code:
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]


RGB64


"Nobody expects the Spanish Inquisition".
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 3rd July 2019, 13:28   #4780  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,231
Quote:
Originally Posted by StainlessS View Post
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.
pinterf is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.