AviSynth+ thread Vol.2

[DTL]

Either I doing something wrong or some degradation happens:

BlankClip(1000,100,100,"RGB24",25,color=$00101010)

BilinearResize(target_width=width, target_height=height, src_left=0.5, src_top=0.3, src_width=width, src_height=height)

Looks like all built-in resizers start to fail with target_width and target_height params directly typed. Resizers from jpsdr pack works OK.
Documentation still lists these params - http://avisynth.nl/index.php/Resize and supplied with 3.7.0 release too.

Error message: Script error: Invalid arguments to function 'BilinearResize'. If delete 'target_width' and 'target_height' params names it works.

This:

BilinearResize(width, height, src_left=0.5, src_top=0.3, src_width=width, src_height=height)

works.

Tested with latest 3.7.0 release and also on some previous like 3.6.2.

[pinterf]

They are non-optional, unnamed parameters. They have names in the description just to have a clue what they really are for.

[DTL]

May be change error message to describe to user what to do to got resizer to work finally ? Or accept these params with names as we have in jpsdr's versions of resizers ?

Current error message is completely mysterious about what going wrong.

[StainlessS]

Originally Posted by DTL

May be change error message to describe to user what to do to got resizer to work finally ? Or accept these params with names as we have in jpsdr's versions of resizers ?

Current error message is completely mysterious about what going wrong.

You're pretty much asking for NEARLY EVERY existing builtin filter to be updated [and if extended to non builtins, then an awful lot more].
Also ALL docs would likely need update, or at least compulsory arg names checked against implemented compulsory arg names. [for eg error messages]

Perhaps it aint gonna happen any time soon.

Originally Posted by pinterf

They are non-optional, unnamed parameters. They have names in the description just to have a clue what they really are for.

And also gives hint about which arguments you are describing in any documentaion.
[easier than "un-named arg 1, un-named arg 2" etc]

Also, If giving compulsory args optional names, then each filter would need additional code to detect where compulsory args were omitted,
and throw error - for each and every compulsory arg. As it is, Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing.

Where "Invalid arguments to function " error is given, it aint that much bother to check your supplied arguments against
a function prototype, whether it be style

BilinearResize(clip clip, int target_width, int target_height [,float src_left, float src_top, float src_width, float src_height ] )

or

BilinearResize(clip clip, int target_width, int target_height ,float "src_left", float "src_top", float "src_width", float "src_height" )

Where RED are compulsory and BLUE are optional, and in above clip args are compulsory but can use Special Last clip.
[ (Compulsory or Special Last) clip has no defined way of specifying it as such in function/filter prototype].

EDIT: I guess could use something like [where clip in "clip=Last" is not in double quotes and so not optional, but default to Last if not supplied]

BilinearResize(clip clip=Last, int target_width, int target_height ,float "src_left" = 0.0,  ... )

[DTL]

" Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing."

In the syntax BilinearResize(target_width=width, target_height=height) compulsory arguments do supplied. But this syntax looks like not compatible with built-in Avisynth+ filters. But works for external filters. May be external jpsdr's plugin was designed much time after the beginning of Avisynth, so it uses newer API (or extended) that allow to have names for compulsory arguments too ? Or it is just 'special processing' of arguments list in jpsdr's plugins so it works ? I think plugin uses common API for function calls so it may work equally - either both works or both not works.

I stil not read all documentation on Avisynth+ but may be in some page about function calling and parameters naming there is a restriction to use names for compulsory arguments ?

The provided with current install engine for version 3.7.0 documentation at docs\English\avisynthdoc\syntax\syntax_ref.html only says:
"AviSynth functions can take named arguments. The named arguments can be specified in any order, and the filter will choose default values for any that you leave off."

So it is still undocumented feature that only optional function arguments for built-in functions can be provided in 'named' form ? Or it will raise error about Invalid arguments. And for other (external) functions it depends on exact arguments processing code in the plugin.

Also typically if function actually do not have named argument (or user make error in argument name) it is usually throwed error: Script error: <function name> does not have named argument "__"

So if BilinearResize actually do not have named argument 'targed_width' it is expected to have more pointed to error source message like: Script error: BilinearResize does not have named argument "target_width"

[StainlessS]

jpsdr's plugin must use this stuff

Also, If giving compulsory args optional names, then each filter would need additional code to detect where compulsory args were omitted,
and throw error, for each and every compulsory arg. As it is, Avisynth itself throws an error if compulsory arguments are not supplied, with the
"Script error: Invalid arguments to function ..." thing.

So, external to the plugin (ie as far as Avisynth is concerned) they are optional, but internal to the plugin, they are detected if missing
and then throws error, and as the plugin knows [well the author knows] the now optional names, so can throw error using those optional names
(although and because, they are actually compulsory).

You can do that for a one-off plugin, so long as author knows he is fully responsible for all errror processing, and avisynth
argument error checking will do pretty much nothing [although it will still check syntax].

I doubt if any special case will be given to any resizers just because jpsdr's did it with a few of his.
EDIT: Additionally, if in future any app [eg AvsPMod] was wanting to scan function prototype
exported/extracted from CPP/C plugin, then jpsdr's plugs compulsory args would be wrongly ascribed as being optional
and perhaps displayed to user as if so.

EDIT:

BlankClip
#Return test(2,3)             # 6, OK
#Return test(arg2=2,arg3=3)   # 6, OK
#Return test(arg2=2)          # 6, OK, arg3 defaults
#Return test(2)               # 6, OK, arg3 defaults
#Return test(3)               # 9, arg2=3, arg3 = defaults 3, if given arg was intended to be for arg3, then result is wrong.
Return test(arg3=3)           # ERR, arg2 not specified, & no default (ie internal compulsory)
                              #   Error either:-
                              #     "Evaluate: operands of '*' must be numeric"
                              #   or
                              #     "Test: arg2 Undefined", if the Assert() is uncommented.
return last

Function Test(clip c, int "arg2", int "arg3") { # Externally, both arg2 and arg3 are specified optional (surrounded by double quotes).
# arg2 is compulsory although externally specified as optional. So looking at prototype, you have NO IDEA AT ALL that arg2 is actually compulsory.
# Bucket loads of new and exciting bugs to experience and fix.
    arg3 = default(arg3 , 3)                     # arg3 is optional both internal (has default) and external.

#   Function author must detect missing arg2, Otherwise ::: "Evaluate: operands of '*' must be numeric"
#   Assert(arg2.defined,"Test: arg2 Undefined")  # Is internal compulsory. ::: UnComment to fix where gives error if missing.

    x = arg2 * arg3                              # arg2 no default value, is undefined if not supplied.
    return c.Subtitle(String(x),size=48)
}

EDIT:

Originally Posted by DTL

So if BilinearResize actually do not have named argument 'targed_width' it is expected to have more pointed to error source message like: Script error: BilinearResize does not have named argument "target_width"

OK, I accept that as a good observation, and could be (dare I say "easily") implemented within avisyhth
main code for both internal and external plugs

I stil not read all documentation on Avisynth+ but may be in some page about function calling and parameters naming there is a restriction to use names for compulsory arguments ?

So far as I know (maybe it changed recently), compulsory args never have a name in CPP/C spec [just a type]
eg "ci" for clip, int, both un-named.
Optional as in "ci[boolarg]b[floatarg]f", where Function (clip, int, bool "boolarg", float "floatarg") sort of in script speak.
Un-named optional arg as in ""ci[]b" where bool arg is un-named optional.
As far as new arrays and such are concerned, I got no idea at all how that works.

From an old RT_stats script that extracts function prototypes from C style specifiers.
The script will only extract a single specifier string where there are multiple alternate specifiers strings, multiples are not exposed for extraction.
There should be 2 versions of Abs() below, ie Abs "f" and Abs "i". The script actually extracts 2 identical copies of Avs "f", I removed one by hand.

        AviSynth+_3.5.2_(r3218,_neo,_i386)_ORDERED_Function_List

There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
 c - Video Clip
 i - Integer number
 f - Float number
 s - String
 b - boolean
 . - Any type (dot)
# Array Specifiers
 i* - Integer Array, zero or more
 i+ - Integer Array, one or more
 .* - Any type Array, zero or more
 .+ - Any type Array, one or more
#    Etc


abs                       "f"
acos                      "f"
AddAlphaPlane             "c[mask]."
AddAutoloadDir            "s[toFront]b"
AddBorders                "ciiii[color]i[color_yuv]i"
AlignedSplice             "cci"
Amplify                   "cf+"
AmplifydB                 "cf+"
Animate                   "ciis.*"
Apply                     "s.*"
ApplyRange                "ciis.*"
Array                     ".*"
ArrayGet                  "a.+"
ArraySize                 "a"
asin                      "f"
Assert                    "s"
AssumeBFF                 "c"
AssumeFieldBased          "c"
AssumeFPS                 "cc[sync_audio]b"
AssumeFrameBased          "c"
AssumeSampleRate          "ci"
AssumeScaledFPS           "c[multiplier]i[divisor]i[sync_audio]b"
AssumeTFF                 "c"
atan                      "f"
atan2                     "ff"
audiobits                 "c"
audiochannels             "c"
AudioDub                  "cc"
AudioDubEx                "cc"
audioduration             "c"
audiolengthf              "c"
audiolengthhi             "c[]i"
audiolengthlo             "c[]i"
audiolengths              "c"
audiorate                 "c"
AudioTrim                 "cf[end]f"
AutoloadPlugins           ""
AverageB                  "c[offset]i"
AverageChromaU            "c[offset]i"
AverageChromaV            "c[offset]i"
AverageG                  "c[offset]i"
AverageLuma               "c[offset]i"
AverageR                  "c[offset]i"
AVIFileSource             "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"
AVISource                 "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"
BDifference               "cc"
BDifferenceFromPrevious   "c"
BDifferenceToNext         "c[offset]i"
BicubicResize             "cii[b]f[c]f[src_left]f[src_top]f[src_width]f[src_height]f"
BilinearResize            "cii[src_left]f[src_top]f[src_width]f[src_height]f"

# ...

EDIT: In above extraction, ArrayGet "a.+", the 'a' is new array specifier.
Looks something like, an array of any type of 1 or more elements, or maybe its an array of arrays or something,
as ".+" = any type Array, one or more.
EDIT: "a.+" Probably an array of arrays where each of the 2nd dim arrays has one or more elements of any type,
no idea what to call it, dont think "sparse array".
I still got no real idea, but wondering if "a.+" should be "a.*" where 2nd dim arrays could be 0 or more elements,
v3.7.0 (r3382) still uses ArrayGet "a.+".
EDIT: Or maybe I got it back-to-front and ".+" specifies 1st dimension of 1 or more. [no spec minimum els for 2nd dim].

EDIT: Nah, musta been half asleep, "a" is maybe single variable holding array, and ".+" one of more variables of any type", maybe.


EDIT: Also note un-named optional, audiolengthhi "c[]i"

[wonkey_monkey]

AVSValue's AsFloat(...) returns a double, but if you try and pass a double as the default value the compiler warns that there'll be a conversion to float. If it returns a double, shouldn't it accept a double as a default value?

[pinterf]

Originally Posted by wonkey_monkey

AVSValue's AsFloat(...) returns a double, but if you try and pass a double as the default value the compiler warns that there'll be a conversion to float. If it returns a double, shouldn't it accept a double as a default value?

There is an AsFloatf version of AsFloat that should be used to avoid warnings. This function exists for this very reason.
EDIT: maybe I explained the opposite: to avoid return value warning. You can use AsDblDef, but since there is no double in AVSValue there is no point of doing that.

Side note: internally there is no double type in Avisynth. Double and 64 bit integer types are impossible to implement. Reason: AVSValue defined in avisynth.h has its maximum value size dependent of the size of pointer - pointer type is 4 bytes on a 32 bit system - so only a 32 bit float can be held there, no 64 bit double. 64 bit systems would easily support them - of course this needs an interface update - I had plans for that but there are always more important stuffs in the development queue. With the extinction of 32 bit Avisynth versions nobody will care if interface would change.

[pinterf]

Originally Posted by StainlessS

EDIT: In above extraction, ArrayGet "a.+", the 'a' is new array specifier.
Looks something like, an array of any type of 1 or more elements, or maybe its an array of arrays or something,
as ".+" = any type Array, one or more.
EDIT: "a.+" Probably an array of arrays where each of the 2nd dim arrays has one or more elements of any type,
no idea what to call it, dont think "sparse array".
I still got no real idea, but wondering if "a.+" should be "a.*" where 2nd dim arrays could be 0 or more elements,
v3.7.0 (r3382) still uses ArrayGet "a.+".
EDIT: Or maybe I got it back-to-front and ".+" specifies 1st dimension of 1 or more. [no spec minimum els for 2nd dim].

EDIT: Nah, musta been half asleep, "a" is maybe single variable holding array, and ".+" one of more variables of any type", maybe.


EDIT: Also note un-named optional, audiolengthhi "c[]i"

The new array specifier "a" expects a real array at its parameter position. Such arrays can be more-than 1D, and their elements are not restricted to have the same type.

In classic Avisynth arrays were always used behind the scenes (.+ one or more anything, .* zero or more anything). Script parser logic was grouping the comma delimited parameters into the given array variable. Only 1D arrays were supported, and array elements must have of the same type.
This kind of array element collection logic thus needs to know where the array elements are ended. This is easy for array of specific types. Comma separated list has an end where the value type gets changed. E.g. Avisynth parser can easily read and populate a string list into array when it has a specific end.
For this function signature:

[paramname_s]s*[anotherparam]i

the script parameters given

"Item1", "Item2", "Item3", 123

Parser will stop collecting string array when it encounters a non-string type.
paramname_s: array[3] : ("Item1", "Item2", "Item3")
anotherparam: integer : 123

What about the ".*" type? These mean array of zero-or-more any-type.
Avisynth can only detect the end of such arrays in a comma delimited list when a named parameter is explicitely given (thanks for StainlessS for the explanation).
Unnamed parameters cannot follow a ".*" array.

Edit: with Stain"EagleEye"LessS' corrections

[StainlessS]

Thanks P, it all seems very complicookered

EDIT: Removed some stuff.
I'll leave below in-situ as it maybe helps show practical usage example of
Explicitly given named param to terminate data list ('.*' or '.+' , zero/one or more, of any type).

Some of my plugs use eg "Append=True/False" following a pseudo array of zero/one or more items of any type,
user must explicitly use optional name to terminate pseudo data array early eg

".*", Any type, zero or more, if wanting to supply Append=true, then must explicitly use "Append=true" after final data arg, even if zero data args.

env->AddFunction("RT_WriteFile",  "ss.*[Append]b",RT_WriteFile, 0);

Script doc style prototype (and doc), compulsory arg names FileName and format are only for docs, they cannot have names supplied.
Unnamed dat1 to datn, also cannot have names supplied, are only for docs.

RT_WriteFile(String FileName, string format, dat1, ... , datn, bool "Append"=False)

 Writes  a formatted string to FileName file. The unnamed 'format' string and optional unnamed 'dat' args are used to construct the
 text string that is written, uses C/CPP printf() style formatting.
 Format: compulsory string controlling format and describing the datn type args that are expected.
 datn: Variable number of data args of any type (excluding clip).
 Append, Default False, optional and MUST be supplied with name (eg Append=True) as we do not know where optional data args end,
 Appends to file if already exists, else opens new FileName.

NOTE, Above, dat1 ... datn, are described as optional because of the zero or more spec [although they have no optional names].

Example script usage

RT_WriteFile(".\Fred.log", "%d] %s", current_frame, "Hello Sexy", Append=True)  # Two Data Args are required as specified in format string(Int, String)
RT_WriteFile(".\Fred.log", "Some Text", Append=True)    # Zero Data args in Pseudo Array (Format string has no '%' data insertion markers)

NOTE, above format string %d and %s describes only the C printf() style expected data args and is only to do with file output formatting,
it is not part of or related to the ".*" spec, we used only because its the easiest and only example that we thought of.

Dont think above has ever been documented anywhere, is result of testing to see what happens, ie 'suck-it-and-see' tactics.

EDIT: https://dictionary.cambridge.org/dic...uck-it-and-see

suck it and see
UK informal

to try something to find out if it will be successful:
I'm not sure whether this paint is the right colour for the bedroom - we'll just have to suck it and see.

If you've got a bag of identical looking (but multiple flavour) chocolates, you may implement a Suck It And See policy.

[pinterf]

Thank you SssS. You know the language so much better than me. Fixed the lines but I'm sure I put other stupid declarations there.

[real.finder]

Originally Posted by real.finder

is https://publishwith.me/ep/pad/view/r...cdWn4k9/latest locked?
edit: I think I know why, I note there were some CCP writing spam text
I was trying to add
SetFilterMTMode("IT", MT_SERIALIZED)

anyway, here my MtModes.avsi https://pastebin.com/tmw7J2mj

uptodate one here https://github.com/realfinder/Univer...B/MtModes.avsi

[mp3dom]

I have a question about ImageSource from AVS+.
Is it supposed to support 16bpc image input natively? Because I have a 16bpc PNG images sequence that by default is opened as RGB32 (with or without Devil library). If I force the pixel_type to RGB48 I get 16bpc but the difference (with subtract command) from this image and the same decoded as 8bit is zero. On the other side, if I open the image with LWLibavVideoSource, and doing the same subtraction, the results is a visible difference.
Maybe I'm doing something wrong somewhere?

[poisondeathray]

Originally Posted by mp3dom

I have a question about ImageSource from AVS+.
Is it supposed to support 16bpc image input natively? Because I have a 16bpc PNG images sequence that by default is opened as RGB32 (with or without Devil library). If I force the pixel_type to RGB48 I get 16bpc but the difference (with subtract command) from this image and the same decoded as 8bit is zero. On the other side, if I open the image with LWLibavVideoSource, and doing the same subtraction, the results is a visible difference.
Maybe I'm doing something wrong somewhere?

Works ok for me (difference detected with subtract)

Are you converting 8bit up to 16bit, or 16bit down to 8bit to compare?

There is a difference for me when I convert 8bit to 16bit to compare vs. original 16bit; or 16 down to 8 to compare with imagesource default 8bit

(But if you downconvert 16 to 8, then the dithering algo choice can also make other difference)


a=imagesource("16bitpng.png")
b=imagesource("16bitpng.png", pixel_type="RGB48")

subtract(a.convertbits(16), b) => difference
#subtract(a, b.convertbits(8, dither=-1)) => difference


Another way to confirm this is write out the imagesource pixel_type="RGB48" png (e.g. pipe to ffmpeg) , then check in vapoursynth. Since vsedit can display >8bit values with the color picker (x=, y=, and R,G,B values) , you can check if it works. eg. You can use a known 16bit RGB test ramp such as x=0, RGB4096, to x=1919, RGB6015. And yes, imagesource pixel_type="RGB48" works correctly.

[mp3dom]

I tried both ways (16 to 8 and 8 to 16). There were slighty differences, while with LWLibav the differences were higher.
Anyway thanks for the check, I'll investigate further on my side.

[poisondeathray]

Originally Posted by mp3dom

I tried both ways (16 to 8 and 8 to 16). There were slighty differences, while with LWLibav the differences were higher.
Anyway thanks for the check, I'll investigate further on my side.

No difference for me between ImageSource pixel_type="RGB48" and LSmash

b=ImageSource("16bit.png", pixel_type="RGB48")
l=LWLibavVideoSource("16bit.png")

subtract(b,l)

avs 3.7 x64 r3382
Maybe something peculiar about your png ?

[LigH]

Maybe one of the methods respects the Gamma flag in the PNG?

[poisondeathray]

Originally Posted by LigH

Maybe one of the methods respects the Gamma flag in the PNG?

Yes, this can explain a difference in handling of PNG's in avisynth

ImageSource will adjust the image according to the cHRM and gAMA tags. LSmash will ignore.

You can examine png's with tweakpng

[wonkey_monkey]

http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API

On this page it states:

MakeWritable only copies the active part of the frame to a completely new frame with a default pitch. You need this to recieve a valid write pointer to an existing frame.

a) What is meant by "active part"?
b) Does MakeWriteable make a new copy even if the frame is already writeable? (IsWritable() == true)

PS The section on IsWriteable() has a typo:

if (src->IsWritetable()) {...}

[pinterf]

Originally Posted by wonkey_monkey

http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API

a) What is meant by "active part"?

MakeWritable makes a NewVideoFrame (NewVideoFrameP for avs+) and BitBlt for all planes.

Active part means that when a frame was created by the quick SubFrame method (e.g. ExtractY, Crop) if won't copy the whole memory content of the original framebuffer, only those which are really take part of the specific colorspace and frame.

Originally Posted by wonkey_monkey

b) Does MakeWriteable make a new copy even if the frame is already writeable? (IsWritable() == true)

No. It then copies nothing, returns immediately and leaves PVideoFrame pointer in its original state.