Avisynth+

[Groucho2004]

"All of them will return true if the colourspace is RGB (in an way)"

If that's true, then they would all be true whether it's RGB24, RGB32, or Planar RGB. Which means you'd have no way to distinguish RGB24 and RGB32.
Alright, I'm awake now. So, I guess it should be:
IsRGB() - Returns true for all RGB color spaces
IsRGB24(), IsRGB32, IsRGB48, IsRGB64 - Self-explanatory

[Motenai Yoda]

"All of them will return true if the colourspace is RGB (in an way)"

If that's true, then they would all be true whether it's RGB24, RGB32, or Planar RGB. Which means you'd have no way to distinguish RGB24 and RGB32.

as the only difference between rgb24 and rgb32 is the 8 bit alpha channel you can use both bitperpixel==32 and hasalpha to check it

[wonkey_monkey]

as the only difference between rgb24 and rgb32 is the 8 bit alpha channel you can use both bitperpixel==32 and hasalpha to check it

Wouldn't YV24 with Alpha return the same result with those?

Edit: oh, I think you meant if we already knew it was RGB. True, but IsRGB24() and IsRGB32() work as expected anyway, it's the wiki that's wrong.

[StainlessS]

it's the wiki that's wrong.


bool IsRGB() const;
bool IsRGB24() const;
bool IsRGB32() const;

All of them will return true if the colorspace is RGB (in any way). The last two return true if the clip has the specific RGB colorspace (RGB24 and RGB32).

Its a bit [EDIT: well a lot] misleading, is intended to mean 'all RGB colorspaces will return true for IsRGB()'.

Same thing for the IsYUV thing.

[real.finder]

since there are no way to get avs+ version I made AvsPlusVersionNumber() function to use it in avs scripting, the 1st one (IsAvsPlus) from the wiki (http://avisynth.nl/index.php/Internal_functions#Version_functions) but with some edit since there are no need for lower case and other things for all avs+ versions I seen

function IsAvsPlus()
{
FindStr(VersionString, "AviSynth+") != 0
}

function AvsPlusVersionNumber()
{
IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}

blankclip(color=color_white)
Subtitle(String(AvsPlusVersionNumber))

tested with r1576 and above and all fine but let hope nothing will change to make it break in future

[pinterf]

Hi real.finder, I've seen that too-many-DLLs load-unload issue, why MEGUI is hectic about it?

[Groucho2004]

since there are no way to get avs+ version I made AvsPlusVersionNumber() function to use it in avs scripting, the 1st one (IsAvsPlus) from the wiki (http://avisynth.nl/index.php/Internal_functions#Version_functions) but with some edit since there are no need for lower case and other things for all avs+ versions I seen

function IsAvsPlus()
{
FindStr(VersionString, "AviSynth+") != 0
}

function AvsPlusVersionNumber()
{
IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}

blankclip(color=color_white)
Subtitle(String(AvsPlusVersionNumber))

tested with r1576 and above and all fine but let hope nothing will change to make it break in future

For your "IsAVSPlus()" function, would you not rather use a try/catch construct around AddAutoloadDir("")? That function is exclusive to AVS+ and seems a safer check than the version string acrobatics.

[real.finder]

Hi real.finder, I've seen that too-many-DLLs load-unload issue, why MEGUI is hectic about it?

hi pinterf, I think because it has it own plugins folder and use AvisynthWrapper.dll and so, which mean a lot of dll's load already, and also I test it in full portable mode (with system has no avs at all) and then used ClearAutoloadDirs() AddAutoloadDir("path to plugins folder") in script and it's same thing especially after start encode (since it sometimes work in preview)

same script and folder work ok with x264 alone

[real.finder]

For your "IsAVSPlus()" function, would you not rather use a try/catch construct around AddAutoloadDir("")? That function is exclusive to AVS+ and seems a safer check than the version string acrobatics.

that can used too, but as I said those work already since the begin of avs+, and they look nicer than any other methods

[Groucho2004]

that can used too, but as I said those work already since the begin of avs+, and they look nicer than any other methods
Out of curiosity - Under what circumstances would you need the revision number?

[ChaosKing]

A check with AddAutoloadDir whould detect Avisynth Neo also as Avisynth+ (it basically is avs+ with cuda stuff) while AvsPlusVersionNumber returns 0. VersionString() returns on avs neo: "Avisynth Neo 0.1 (r2882, Neo, i386)"
It this case a check with AddAutoloadDir would be prefered.
https://github.com/nekopanda/AviSynthPlus/releases

[real.finder]

Out of curiosity - Under what circumstances would you need the revision number?

same circumstances that old VersionNumber be used, like keep support for some older versions

[Groucho2004]

Avisynth Neo
Arrrgh. Yet another version. Let's confuse the crap out of the average user. :)

[Groucho2004]

same circumstances that old VersionNumber be used, like keep support for some older versionsWhat support? Can you be more specific? Maybe a couple of examples?

[real.finder]

A check with AddAutoloadDir whould detect Avisynth Neo also as Avisynth+ (it basically is avs+ with cuda stuff) while AvsPlusVersionNumber returns 0. VersionString() returns on avs neo: "Avisynth Neo 0.1 (r2882, Neo, i386)"
It this case a check with AddAutoloadDir would be prefered.
https://github.com/nekopanda/AviSynthPlus/releases

I don't have nvidia so and didn't use Avisynth Neo, it already not work with any of IsAVSPlus (both wiki and mine) and AvsPlusVersionNumber, it's better if the Developer of Avisynth Neo make it like this "Avisynth+ 0.1 (r2882, Neo, i386)"

[real.finder]

What support? Can you be more specific? Maybe a couple of examples?

support older avs+ in some scripts, like the old 1576 and so, since there are new functions added every time in avs+

[Groucho2004]

support older avs+ in some scripts, like the old 1576 and so, since there are new functions added every time in avs+
If AVS+ had a simple script function "FunctionExists()" (same as the API function), testing for certain features would be a lot easier.

@pinterf
See above. ;)

Edit: Or maybe a few simple utility functions which return true/false such as IsHighBitDepth() (HasHighBitDepth() ?), IsMultiThreaded(), etc. Just thinking out loud...

[real.finder]

If AVS+ had a simple script function "FunctionExists()" (same as the API function), testing for certain features would be a lot easier.


maybe but I like use it like vanilla AviSynth VersionNumber(), with < or >, simple and nice

[StainlessS]

From RT_Stats function list thing,

AviSynth+_0.1_(r2772,_MT,_i386)_ORDERED_Function_List

FunctionExists "s"


ie, already implemented. [Of course you have to know that its AVS+ before you can use it, or Try/Catch]

[Groucho2004]

already implemented
Ooops, you're right.

[StainlessS]

There is a little bit of inconsistency between function names, some use xxxxExist, and some xxxExists.


Exist "s"
FunctionExists "s"
InternalFunctionExists "s"
VarExist "s"


RT_ uses RT_FunctionExist() which was chosen to match the then existing Exist() function.

[real.finder]

A check with AddAutoloadDir whould detect Avisynth Neo also as Avisynth+ (it basically is avs+ with cuda stuff) while AvsPlusVersionNumber returns 0. VersionString() returns on avs neo: "Avisynth Neo 0.1 (r2882, Neo, i386)"
It this case a check with AddAutoloadDir would be prefered.
https://github.com/nekopanda/AviSynthPlus/releases

ok, so I did this, it will be in next SMDegrain update, nekopanda already did the damage so forget about my old post

function IsAvsNeo()
{
FindStr(VersionString, "AviSynth Neo") != 0
}

function IsAvsPlus()
{
FindStr(VersionString, "AviSynth+") != 0 || IsAvsNeo
}

function AvsPlusVersionNumber()
{
IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}

can you test it to see if it report the number correctly?

[ChaosKing]

Yes it works, I made a small mistake. Correct is: "AviSynth Neo"
IsAvsPlus and IsAvsNeo returning true for AviSynth Neo.

[real.finder]

Yes it works, I made a small mistake. Correct is: "AviSynth Neo"
IsAvsPlus and IsAvsNeo returning true for AviSynth Neo.

and the revision number?

[ChaosKing]

and the revision number?

returns 2822

[real.finder]

The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.

Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)

[...]
}


btw, will this make the systems that use dot has wrong outputs?

so, the final solution for this? rebuild dither.dll with vc15 ?

[pinterf]

Dunno, probably yes. Do those lines really improve anything or it is just kept and copied over many years? Could Zopti (Formerly Avisynth optimizer) help deciding it? No, I'm not volunteering for it :). Still working on the "Layer" stuff.

[real.finder]

Dunno, probably yes. Do those lines really improve anything or it is just kept and copied over many years? Could Zopti (Formerly Avisynth optimizer) help deciding it? No, I'm not volunteering for it :). Still working on the "Layer" stuff.

they doing good job in dark area

btw, don't tell me that masktools lut (and avs+ expr) has this problem too!

if it only the dither one did this update here (https://forum.doom9.org/showpost.php?p=1839229&postcount=1111) fix the problem?

[pinterf]

No, as far as I know masktools is working properly. There have been problems with dither tools' decimal separator, which I'm not sure it it was fixed or not.

[real.finder]

No, as far as I know masktools is working properly. There have been problems with dither tools' decimal separator, which I'm not sure it it was fixed or not.

ok, can someone test? someone that has regional setting use comma for decimal separator

edit: simple test


ColorBars(pixel_type="yv12")
a=Mt_makediff(Dither_Luma_Rebuild(),coloryuv(levels="TV->PC"),u=3,v=3)
b=Mt_makediff(Dither_Luma_Rebuild(lsb=true),coloryuv(levels="TV->PC"),u=3,v=3)
StackVertical(a.Subtitle("luma rebuild vs avs tv to pc"),b.Subtitle("luma rebuild lsb vs avs tv to pc"),Mt_makediff(a,b,u=3,v=3).Subtitle("lsb vs 8bit"))


in case of avs tv to pc vs luma rebuild (whether with or without lsb) there are small difference here and there, so anyone test better post image of it

[ChaosKing]

How should one test it exactly? just call Dither_Luma_Rebuild() ?

[real.finder]

How should one test it exactly? just call Dither_Luma_Rebuild() ?

I know that someone will ask that, see my edit I just made above

[ChaosKing]

https://i.imgur.com/bZfmVX9.jpg

[real.finder]

https://i.imgur.com/bZfmVX9.jpg

it's same I got, my system use dot (Iraq)

btw, what avs you use and what dither.dll?

[ChaosKing]

Win10 x64 german which uses comma as decimal separator, avs+ 2772, 32bit dither.dll (CRC32: 20008b02) is from here http://ldesoras.free.fr/prod.html#src_ditheravsi

[real.finder]

Win10 x64 german which uses comma as decimal separator, avs+ 2772, 32bit dither.dll (CRC32: 20008b02) is from here http://ldesoras.free.fr/prod.html#src_ditheravsi

so that mean the problem already fixed? it was bug in win10 that fixed in later updates or what? let's see what pinterf and tormento said

[ChaosKing]

Idk I never encountered this problem in avs.

[wonkey_monkey]

Got a filter development problem.

In GetFrame, I can do this:

PVideoFrame __stdcall warp::GetFrame(int n, IScriptEnvironment* env) {
PVideoFrame dst = env->NewVideoFrame(vi);
byte* dst_p = dst->GetWritePtr();
...
}

As it's an interleaved RGB clip, this works as expected.

But what I want to do is this:

void some_function(PVideoFrame dst) {
byte* dst_p = dst->GetWritePtr();
...
}

PVideoFrame __stdcall warp::GetFrame(int n, IScriptEnvironment* env) {
PVideoFrame dst = env->NewVideoFrame(vi);
some_function(dst);
}

This doesn't work. GetWritePtr() in the function returns 0.

What's the problem and how can I fix it?

--------------------------------------------------------------

Edit: it looks like I have to pass a pointer to the smart pointer, even though the smart pointer itself has the same value inside and outside of the function. Any brief explanation of this would be gratefully received.

[StainlessS]

Make dst a reference, think that should work.


void some_function(PVideoFrame &dst) {
byte* dst_p = dst->GetWritePtr();
...
}


EDIT: If not reference, it makes a copy of PVideoFrame for calling some_function, and as is a copy is no longer writeable.

[wonkey_monkey]

I checked the actual value of PVideoFrame (assuming it actually is some kind of pointer) and it was the same inside the function. I guess there's another layer of abstraction that ruins this idea.

Anyway, see my edit, as I did manage to figure that out and it now works. Thanks though!

[StainlessS]

PVideoFrame is a so called Safe Pointer (with auto self delete type stuff), and keeps a count of number of references to itself,
if more than a single reference, then is no longer writeable. summick like that.

EDIT: And frame not actually deleted until reference count goes to zero (ie nobody else is using it).

EDIT:
I checked the actual value of PVideoFrame
Also, CPP can do some clever stuff, it probably massages some results that you may get from it, Operators can be overridden to do something a little different,
but the main prob is the reference count not being 1, ie not writable.

[pinterf]

it's same I got, my system use dot (Iraq)

btw, what avs you use and what dither.dll?
Tried two different x64 dither.dll versions, both (CPP 2.5 version from 2015 and a CPP 2.6 version from 2017) are giving me the same results (and similar to the same pic you have posted here).

[poisondeathray]

Bit shifting vs. multiply revisited. 8 to 10 bit scaling in YUV vs. RGB first. Behaviour seems inconsistent

0-1023 seems correct to me . VPY yields 1023 for full range eitherway; even if you convert to 8bit full range YUV first, then 10bit at a 2nd step


This gives 0-1020

#8bit RGB 0-255 source. ImageSource(), packed
ConvertToYV12(matrix="PC.709") #8bit YUV 0-255 full range
ConvertBits(10)


This gives 0-1023 if the 8=>10bit is done in RGB first

#8bit RGB 0-255 source. ImageSource(), packed
ConvertToPlanarRGB()
ConvertBits(10)
ConvertToYV12(matrix="PC.709")


But converting to YUV first, before the 8=>10bit gives 0-1020

#8bit RGB 0-255 source. ImageSource(), packed
ConvertToPlanarRGB()
ConvertToYV12(matrix="PC.709")
ConvertBits(10)



*Nevermind - I guess you can override it by using ConvertBits(10, fulls=true) .

[wonkey_monkey]

overlay doesn't seem to throw errors properly, or at least not in the usual manner. Instead of a popup error, as you get with layer when specifying bad parameters or providing unsupported colourspaces, overlay's internal errors (e.g. "Overlay: Invalid 'Mode' specified.") come up as status bar messages in VirtualDub2 instead.

Is it because they are being thrown in GetFrame instead of in the constructor?

PS Is there any reason layer and overlay couldn't be merged? They seem like they overlap quite a lot.

[StainlessS]

I would class below as a definite bug. We had something similar where Trim() was not trimming audio where source was Colorbars.


A=AVISource("D:\L&M.avi")
B=AVISource("D:\B2.avi")
F=B.trim(0,-1) # Should be single frame
A=A.Trim(18000,0)
#Return F # Returns single frame OK
StackHorizontal(A,F) # SHOULD Stack clip alongside a Fixed Single frame, but F is NOT single frame

StackHorizontal, is ignoring the trim(somehow), this must be fixed.

EDIT:
We had something similar where Trim() was not trimming audio where source was Colorbars.
Perhaps it is the very same problem, in Trim (that problem also incorporated StackHorizontal). Not trimming properley will break scripts.

EDIT: Managed a temporary fix so that I could do as required by inserting an "F=FrameStore(F)" line before the Stackhorizontal line.

[pinterf]

overlay doesn't seem to throw errors properly, or at least not in the usual manner. Instead of a popup error, as you get with layer when specifying bad parameters or providing unsupported colourspaces, overlay's internal errors (e.g. "Overlay: Invalid 'Mode' specified.") come up as status bar messages in VirtualDub2 instead.

Is it because they are being thrown in GetFrame instead of in the constructor?

I'll check it later this week.


PS Is there any reason layer and overlay couldn't be merged? They seem like they overlap quite a lot.

I have finished porting Layer to support all formats and bit depths (it's on git source already, but not finished and published the whole project because the possible integration with Overlay has also come in my mind). Theoretically Overlaps and Layer can be merged - unfortunately we have to keep both - compatibility you know. They are using different set of parameters - though I already introduced 'opacity' for layer, it was needed instead of 'level' because of the consistency among different bit-depth), terminology (add-blend), and they are also using different methods for some of their similar filters (lighten-darken has an additional threshold in Layer), Layer can use a single alpha channel for masking as part or the format (RGB_A, YUV_A), Overlaps is using mask, but this can also be a luma-chroma clip.
In 'Layer' I have done proper chroma masking based on a single luma mask (now you can even choose placement as mpeg2 or mpeg1), for such task Overlay converts 4:2:0 or 4:2:2 clips to 4:4:4, and can only use a not-so-precise conversion for chroma.
So the two filters are similar but there are still differences -> lot of work.

[wonkey_monkey]

That's awesome, thanks pinterf!

[a1s2d3f4]

I just tried upgrading to AviSynth+. During the installation I chose the option that would allow me to downgrade safely back to the old AviSynth I already had installed.
Immediately after the restart I tried one of my .avs scripts and found that the new installation broke my srestore(). I already posted about this on the srestore thread:: https://forum.doom9.org/showthread.php?p=1866853#post1866853.

Because I need this script to work right now, I went into "Uninstall or Change a Program" (Win8.1x64) and selected to uninstall AviSynth+.
It did so quickly, so I tried running my .avs script again and I now got this error
---------------------------
VirtualDub Error
---------------------------
AVI Import Filter error: (Unknown) (80040154)
---------------------------
OK
---------------------------

I am not yet sure how to fix this - hopefully, reinstalling the old AviSynth will help, but I just wanted to show that the current downgrade process isn't working smoothly.

Any help is appreciated.

a1

[StainlessS]

AVI Import Filter error: (Unknown) (80040154)

That tends to come up when CPP runtimes not found.
(I trust that you installed latest AVS+ as pointed out by Groucho2004 [in the other thread]).
Current version avs+ (r2772) requires CPP runtimes for VS 2015:- https://www.microsoft.com/en-us/download/details.aspx?id=53840

And Latest version AVS+ link again here:- https://github.com/pinterf/AviSynthPlus/releases

EDIT: The original AVS+ that you installed was from Jan 2014 (linked from 1st post in this thread).

[manolito]

To make sure you have the latest CPP runtimes you can install an All-In-One package. This one is current and highly recommended:
https://repacks.net/viewtopic.php?f=6&t=247

For a general AVS+ rant and an older Srestore AIO package see here:
https://forum.doom9.org/showthread.php?p=1866896#post1866896


Cheers
manolito