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. |
28th June 2019, 07:35 | #4761 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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? |
28th June 2019, 08:57 | #4762 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
@Wilbert: yes, changing version number makes sense.
Quote:
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. |
|
28th June 2019, 09:27 | #4763 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
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 |
28th June 2019, 10:58 | #4764 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
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 |
|
28th June 2019, 11:11 | #4765 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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.
|
28th June 2019, 16:56 | #4766 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
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. |
|
28th June 2019, 17:48 | #4767 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
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 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. |
|
28th June 2019, 21:06 | #4768 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
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. Last edited by wonkey_monkey; 28th June 2019 at 21:30. |
28th June 2019, 23:17 | #4769 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
Quote:
|
||
28th June 2019, 23:20 | #4770 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
A long time ago i added the following Quote:
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? |
||
29th June 2019, 00:15 | #4771 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
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:
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. |
|
29th June 2019, 17:47 | #4774 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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:
__________________
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. |
|
2nd July 2019, 22:13 | #4775 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 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: 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: 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: 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: 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) 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 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. |
3rd July 2019, 06:26 | #4776 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
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 |
3rd July 2019, 09:29 | #4777 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
__________________
See My Avisynth Stuff Last edited by real.finder; 3rd July 2019 at 09:35. |
3rd July 2019, 12:43 | #4778 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
2.) First "this" (unload plugin DLLs and reload only which needed): probably not. 3.) What's wrong with the second "this"? |
|
3rd July 2019, 13:08 | #4779 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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 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 ??? |
Thread Tools | Search this Thread |
Display Modes | |
|
|