AviSynth+ thread Vol.2

[real.finder]

scalef/scaleb should be as fast as ymax, ymin etc... anyway pinterf should give the right answer

anyway, I will try add new constants for full range ymaxf, yminf etc... and do PR

[Dogway]

That would lead to lots of string if else's or ReplaceStr() to change ie. ymax to ymaxf. Wouldn't be easier an argument for it? I don't see how one would want to mix full scale with stretched constants.

Anyway, thanks for looking into it, this thing was affecting my code progress.

[real.finder]

try https://www.solidfiles.com/v/ZZvV2ezjvvnQn

it has new yfmin, yfmax, cfmin and cfmax keywords

[Dogway]

Thank you. I think that nonef was a good idea except for displacing the option to use FloatUV for 32-bit chroma processing. I'm currently rebasing all my scripts.

[zorr]

New build, primarily for zorr, propAdd allows Clip type. Not tested at all, I had time only for adding the possibility.
Avisynth 3.7.1 20210618 test5

Wow thanks! I'll conduct some testing after my current MVTools test run is finished.

[GMJCZP]

Patience, please, I'm not a live L3 support line.

Thanks for your efforts.
I solved my technical problems, I hope.

[FranceBB]

The new build works fine on XP x86, Ferenc, thanks! :)
About the fact that Visual Studio 2022 won't support v141_xp as target, well... I'm just gonna say that the disastrous day in which Avisynth won't work on XP anymore is gonna be the day in which I'll shut down forever the Windows XP Virtual Machine and I'll fire up the Sucksdown 10 one... :'(

(or if by that time we'll have everything working on Linux, then I'll just stick with Fedora eheheheh)

[zorr]

Test results: I think I was able to store a clip into frame properties, at least there was no error and the clip displays fine after that. This works:

clip = propSet(clip, "test", function[store_this](clip c) { return store_this } )

and I think it can be turned into an array of clips by adding

clip = propSet(clip, "test", function[store_this](clip c) { return store_this }, mode=1 )

However I can't get the clip out. There's no propGetClip() -function. Doing

return ScriptClip(clip, """ return propGetAny(clip, "test") """)

returns Error getting frame property "test": type 'c' not supported

and if I try to read a clip from an array with

return ScriptClip(clip, """ return propGetAsArray(clip, "test")[0] """)

it returns ScriptClip: Function did not return a video clip! (Was the undefined value)

So looks like there needs to be some additional support for reading the clip typed frame properties. :)

Oh, and for some reason the plugins in x64 directory were actually 32bit versions. I just replaced them with my previous x64 versions.

[tormento]

I'll fire up the Sucksdown 10 one... :'(
Or 11 directly. :)
(or if by that time we'll have everything working on Linux, then I'll just stick with Fedora eheheheh)
Picture that I am currently using Windows 10 + WSLg with Debian. They introduced graphic and CUDA support too. In many instances it can get better scores than pure Linux.

[MysteryX]

Levels function isn't working in 16-bit. Output is completely black.

ConvertBits(16)
#ConvertToRGB64(matrix="Rec601")
ConvertToPlanarRGB(matrix="Rec601")
Levels(0, 1/2.2, 255, 0, 255)
ConvertToY(matrix="Rec601")
ConvertToYUV420()

[feisty2]

because "white" in int16 is 65535 not 255:rolleyes:

[pinterf]

Levels function isn't working in 16-bit. Output is completely black.

http://avisynth.nl/index.php/Levels
There is no automatic scaling.

[pinterf]

However I can't get the clip out. There's no propGetClip() -function. Doing

return ScriptClip(clip, """ return propGetAny(clip, "test") """)

returns Error getting frame property "test": type 'c' not supported


Thanks, then I'll arrange a next turn soon.

[pinterf]

Yes, "{n} scalef" is almost as fast as "none". The problem is we are still using 8-bit constants which is a bit misleading. I thought ymax, ymin... constants were there to replace 8-bit expression syntax and make it cleaner.
The zillion options (both commandline arguments and internal helper keywords) of autoscaling or using 8 bit values which are converted automatically were created for help. Because when Avisynth got 10+ bits, expressions supported only 8 bits. To help the transition to translate the scripts to HBD aware (which was and is mainly done by the huge work of real.finder) these various options appeared, first in masktools then later in Expr.

I have to mention (not for you, Dogway, because you experienced a lot with Expr), using 8 bit constants are safe, they are internally treated as 32 bit floats so e.g. 16/255 does not become 0 inside.

[pinterf]

scalef/scaleb should be as fast as ymax, ymin etc... anyway pinterf should give the right answer

anyway, I will try add new constants for full range ymaxf, yminf etc... and do PR

Expressions with operation on constants are optimized. E.g. 2 2 * is precalculated to 4. I have to check but for example the expression '235 scalef' is optimized as well during the parsing time to a single constant.

Other optimizations exists, e.g. x Power of 2 is optimized to x*x (powers -1, 0, 1, 2, 3 and 4 are handled)

[pinterf]

I found something strange. Using the next expression in 16-bit to convert to TV levels yields a byte white level of 234:
"x ymax ymin - range_max / * ymin +"
That would correspond to (n*256):
"x 60160 4096 - 65535 / * 4096 +"

This is fixed if I multiply 235*257 (= 60395) instead to get the correct ymax 16-bit value.
Shouldn't this be fixed internally? I can set scale_inputs to "allf" and it fixes, but I'm not sure that's the original intention of the option (scale expression to 8-bit). Also by doing so I lose the option to use "FloatUV" for 32-bit chroma, since there's no "FloatUVf".
What is your script? This one returns 235.
ColorBarsHD(pixel_type = "YUV444P16")
Expr("65535","65535","65535")
Expr("x ymax ymin - range_max / * ymin +")
ConvertBits(8)
ScriptClip("""
Subtitle(String(expr("x").AverageLuma()))
""")



EDIT:
I got it where you got 234. This happens only when you mix the 8 bit inputs with 16 bit ranges.
(235 - 16) / 255 is not the same conversion factor as (60160 - 4096) / 65535

Calculations:

255.0f * (235.f - 16.f) / 255.f + 16.0f;
Result = 235.0

255.0f * (60160.f - 4096.f) / 65535.f + 16.0f)
Result = 234.1478

65535 * (60160.f - 4096.f) / 65535.f + 4096.0f;
Result: 60160.0

[pinterf]

['Clip' type frame property read]
Next test iteration:
AviSynth+ 3.7.1-test6 20210621 (https://drive.google.com/uc?export=download&id=1xlNwp3XH7RUaRmUMdakcR4x3LdKoTYVT)

[pinterf]

For conversions you need to full scale stretch if working in PC levels. Read here (https://forum.doom9.org/showthread.php?p=1685118#post1685118).

In any case, I don't care anymore what avisynth+ does, using auto-scaling is very slow, "allf" is about 30% slower than "none" because the constants (ymax, range_max, etc) are computed at runtime. So I'm bulding a look up table which will speed things up quite a bit. Thought pinterf wanted to fix it but he doesn't seem very interested on the topic from lack of feedback.

# 8-bit 10-bit 12-bit 14-bit 16-bit 32-bit
range_min = Select (bits, [ 0, 0], [ 0, 0], [ 0, 0], [ 0, 0], [ 0, 0], [ 0, 0])
ymin = Select (bits, [ 16, 16], [ 64, 80], [ 256, 272], [ 1024, 1040], [ 4096, 4112], [ 16/255., 16/255.])
cmin = Select (bits, [ 16, 16], [ 64, 80], [ 256, 272], [ 1024, 1040], [ 4096, 4112], [-112/255.,-112/255.])
range_half = Select (bits, [128,128], [ 512, 640], [2048,2176], [ 8192, 8320], [32768,32896], [ 128/255., 128/255.])
yrange = Select (bits, [219,219], [ 876,1095], [3504,3723], [14016,14235], [56064,56283], [ 219/255., 219/255.])
crange = Select (bits, [224,224], [ 896,1120], [3584,3808], [14336,14560], [57344,57568], [ 224/255., 224/255.])
ymax = Select (bits, [235,235], [ 940,1175], [3760,3995], [15040,15275], [60160,60395], [ 235/255., 235/255.])
cmax = Select (bits, [240,240], [ 960,1200], [3840,4080], [15360,15600], [61440,61680], [ 107/255., 107/255.])
range_max = Select (bits, [255,255], [1020,1023], [4080,4095], [16320,16383], [65280,65535], [1.0,1.0])
range_size = Select (bits, [256,256], [1023,1023], [4096,4096], [16384,16384], [65536,65536], [1.0,1.0])
Let's see only a single example.
How did you get the constant of 80 for 10 bit ymin instead of 64?
Min values must keep the *rule of 8_bit_min * 2^(N-8) where N is the bit depth.
As for limited range maximum values there was a decision of keeping the same 8_bit_max * 2^(N-8) calculation, against the other choice of (8_bit_max + 1) * 2^(N-8) - 1.
Limited range ConvertBits() conversions are simple bit-shifts (upwards) and round-then-bitshift (downwards)

(note: Expr is always rounding and does not truncate before converting back to the integer domain)

EDIT: see calculations in my previous answer (#1116) where I put it where your calculation went astray in my opinion.

[Dogway]

Even if the ex_dlut() function might seem overdone to simply "fix" an issue in Expr() I will keep it to save some operations (ie. "ymax ymin - range_max /") and for reference.

You are referencing an old table which was wrong. You can look my table 4 posts later (https://forum.doom9.org/showthread.php?p=1945324#post1945324). Or simply check the updated function (https://github.com/Dogway/Avisynth-Scripts/blob/c1bbb41ab15128a192b5d7506c9a07c5aa127208/ExTools.avsi#L845) in ExTools 2.0 with float precision. It works on my tests but if you spot something wrong let me know.

Over the development of Transforms Pack, where I need bit perfect conversions I noticed something was off and that led me to this conclusion.

Your sample script is crafted to output the result you look for. A real world scenario is more like the following (no body uses fulls=true to be honest).

ColorBarsHD(pixel_type = "YUV444P8")
Expr("255","255","255")
ConvertBits(16)
Expr("x ymax ymin - range_max / * ymin +")
ConvertBits(8)
ScriptClip("""
Subtitle(String(expr("x").AverageLuma()))
""")


EDIT: To answer your #1116 EDIT. Yes, range_max is scaling in full stretch fashion whereas everything else does in bitshift, disparity that leads to that error.

255.0f * (60160.f - 4096.f) / 65280.f + 16.0f)
Result = 235.0

65280 * (60160.f - 4096.f) / 65280.f + 4096.0f;
Result: 60160.0

[pinterf]

Your sample script is crafted to output the result you look for. A real world scenario is more like the following (no body uses fulls=true to be honest).

Ah, that's the problem then. Wrong use of ConvertBits makes 255 to 255*256 instead of 65535.
Well, if people are not telling the conversion type if it should use full or limited range but still expect perfectly guessed results, I can't help with it. I'm somehow reluctant to support Avisynth Expr with new bad-habit workaround constants.

[Dogway]

ConvertBits(16) # Default bitshift scaling. fulls=false for YUV

Expr("range_max") # Default full stretch scaling.


If you don't see the problem I can't help anymore.

[pinterf]

Side note:

Avisynth supports frame properties, but only provides the internal framework for it. Many external plugins are actively using them, z_xxxxx resizers/format converter for example.

But - due to lack of development resources - there is zero usage of them internally. Color matrix, full-limited, others. ConvertBits would automatically know the proper input format (full scale) and voilá, no more user error.

It is on the roadmap.

[Dogway]

Still need to get into frame properties, see if they impact performance, reliability and do implementation.

I'm somehow reluctant to support Avisynth Expr with new bad-habit workaround constants.

I'm super intrigued in doing a research of how many current HBD aware scripts/plugins work correctly as you expect. I will try to find some time and report if my "bad-habit workaround" works better or not.

[pinterf]

ConvertBits(16) # Default bitshift scaling. fulls=false for YUV

Expr("range_max") # Default full stretch scaling.


If you don't see the problem I can't help anymore.
What problem. It's how it is defined.
Range_max is _not_ representing a scaled 255 maximum, but the maximum value of the actual bit depth.

[zorr]

['Clip' type frame property read]
Next test iteration:
AviSynth+ 3.7.1-test6 20210621 (https://drive.google.com/uc?export=download&id=1xlNwp3XH7RUaRmUMdakcR4x3LdKoTYVT)

Thanks again. I'm running MVTools tests again and looks like it could take a couple of days until they're finished, I'll test after that.

[tormento]

AviSynth+ 3.7.1-test6 20210621
Internal version 3.7.1·3413, such as test5. Is it correct? The two dlls are anyway different in content.

[wonkey_monkey]

Could Expr be updated to treat newlines and tabs (\r, \n, \t, and any other character less than 32 for that matter) inside expressions exactly the same as spaces? It does odd and slightly unpredictable things at the moment - it seems to work okay if a space is put before the newline and if the first thing on the next line is a number, but otherwise it complains about being unable to convert to float.

[StainlessS]

and any other character less than 32 for that matter
Maybe only those considered white space, [EDIT: else, non Parse] ie

Function IsWhite(String s) { s.RT_Ord==32||(s.RT_Ord>=8&&s.RT_Ord<=13) }


EDIT:

32 = SPACE
8 = BACKSPACE
9 = TAB
10 = LINEFEED
11 = VERTICAL TAB
12 = FORMFEED
13 = CARRIAGE RETURN


So eg Chr(7) [BELL, would make a printer go "Ding!"] should maybe produce error abort.
Maybe not good idea to just ignore stuff that defo should not be there.

[gispos]

A small (big?) Wish.
The C interface has problems with Utf-8 and with Delphi Ansi strings.
Utf-8 and Delphi Ansi strings only work with AviSource. 'Eval' or 'Import' does not work.
Frame properties can only be read indirectly.

An update of the C interface would be nice.

[qyot27]

A small (big?) Wish.
The C interface has problems with Utf-8 and with Delphi Ansi strings.
Utf-8 and Delphi Ansi strings only work with AviSource. 'Eval' or 'Import' does not work.
Frame properties can only be read indirectly.

An update of the C interface would be nice.
And do you have the Windows system codepage set to UTF-8?

[kedautinh12]

Yeah, i had

[gispos]

And do you have the Windows system codepage set to UTF-8?
I am using Win7.
Earlier (a long time ago) the Delphi Ansi strings with 'Eval' and 'Import' worked. With the newer Avisynth versions, these strings are sometimes read incorrectly.
If I use e.g. MCTemporalDenoise() there is an error message division by 0.

With AvsPmod I can only open scripts containing Utf-8 characters when I import them with AviSource.

[pinterf]

Internal version 3.7.1·3413, such as test5. Is it correct? The two dlls are anyway different in content.
Yes, same, did not commit the changes until the test succeeds. build number is changed after commits.

[pinterf]

A small (big?) Wish.
The C interface has problems with Utf-8 and with Delphi Ansi strings.
Utf-8 and Delphi Ansi strings only work with AviSource. 'Eval' or 'Import' does not work.
Frame properties can only be read indirectly.

An update of the C interface would be nice.
AnsiString stuff: internally you can use String and not AnsiString.
Then it can be converted to utf8 if needed.
var unistring: String := ...
var Bytes: TBytes;
Bytes := TEncoding.UTF8.GetBytes(unistring);


Import has also an alternative form for utf8 filenames (if windows codepage is not utf8 natively): Import(filename [, ...] [, bool utf8])
then pass this buffer to Eval if Windows system codepage is set to UTF-8.

As for frame properties: there is a fix in these post-3.7 version which does not crash (yes, there was a bug) when using frame property related functions from C.

[pinterf]

Frame properties from C interface
(quick test; I just put all relevant cases meaninglessly into assrender C plugin code)
AVS_VideoFrame* AVSC_CC assrender_get_frame(AVS_FilterInfo* p, int n)
{
udata* ud = (udata*)p->user_data;
ASS_Image* img;

int64_t ts;
int changed;

// AVS_FilterInfo* p from get_frame
AVS_VideoFrame* src = avs_get_frame(p->child, n);

avs_make_writable(p->env, &src);

// src is an AVS_VideoFrame*
AVS_Map* avsmap;
avsmap = avs_get_frame_props_rw(p->env, src);
int error; // needed for error report, for now we'll ignore it
// read existing propery. For test, we set it by to 77 by propSet("TestIntKey", 77) in Avisynth script
int64_t testvalue = avs_prop_get_int(p->env, avsmap, "TestIntKey", 0, &error);

// set new frame properties (by using the just-read integer property)
avs_prop_set_int(p->env, avsmap, "TestIntKey2", testvalue * 2, AVS_PROPAPPENDMODE_REPLACE);
avs_prop_set_float(p->env, avsmap, "TestFloatKey2", (testvalue * 2.0f), AVS_PROPAPPENDMODE_REPLACE);
// store string (in general: any data), by specifying length = -1 we'll notify set_data to have strlen for getting its real size
avs_prop_set_data(p->env, avsmap, "TestStringKey2", "testStringvalue", -1, AVS_PROPAPPENDMODE_REPLACE);

// array test (double). Note: we can have double here, contrary to the fact that Avisynth scripts can handle only floats.
const double test_d_array[] = { 0.5, 1.1 };
avs_prop_set_float_array(p->env, avsmap, "TestFloatArray", test_d_array, 2);

// array test (integer). Note: we can have int64 here, contrary to the fact that Avisynth scripts can handle only 32 bit integers.
const int64_t test_i_array[] = { -1, 0, 1 };
avs_prop_set_int_array(p->env, avsmap, "TestIntArray", test_i_array, 3);

// read back the array size of a property (single properties are an 1-element arrays)
int numElementsOfIntArray = avs_prop_num_elements(p->env, avsmap, "TestIntArray");
avs_prop_set_int(p->env, avsmap, "TestNumElementsOfIntArray", numElementsOfIntArray, AVS_PROPAPPENDMODE_REPLACE);

// Int property array: read back one-by-one, mul by 2, and put into another array
int64_t test_i_array_clone[3];
for (auto i = 0; i < numElementsOfIntArray; i++) {
test_i_array_clone[i] = avs_prop_get_int(p->env, avsmap, "TestIntArray", i, &error) * 2;
}
avs_prop_set_int_array(p->env, avsmap, "TestIntArrayCloneMul2", test_i_array_clone, 3);

// double property array read back as a whole, div by 3, and put into another array
int numElementsOfFloatArray = avs_prop_num_elements(p->env, avsmap, "TestFloatArray");
const double * tmpdarray = avs_prop_get_float_array(p->env, avsmap, "TestFloatArray", &error);
for (auto i = 0; i < numElementsOfFloatArray; i++) {
double tmp_d = tmpdarray[i] / 3.0;
// first element: replace frameprop data, next ones: append new element one by one
avs_prop_set_float(p->env, avsmap, "TestFloatArrayCloneDiv3", tmp_d, i == 0 ? AVS_PROPAPPENDMODE_REPLACE : AVS_PROPAPPENDMODE_APPEND);
}

// delete the key, we defined in Avisynth script
avs_prop_delete_key(p->env, avsmap, "TestIntKey");

// count all keys (frame property count) and put it into another frame property
int numOfKeys = avs_prop_num_keys(p->env, avsmap);
avs_prop_set_int(p->env, avsmap, "TestNumKeysWithoutThisOne", numOfKeys, AVS_PROPAPPENDMODE_REPLACE);

// [... code part left out intentionally]

return src;
}

[pinterf]

Could Expr be updated to treat newlines and tabs (\r, \n, \t, and any other character less than 32 for that matter) inside expressions exactly the same as spaces? It does odd and slightly unpredictable things at the moment - it seems to work okay if a space is put before the newline and if the first thing on the next line is a number, but otherwise it complains about being unable to convert to float.
Probably yes. If it does not collide with existing Avisynth syntax. I can imagine that it can work like e.g. atoi
which discards whitespace (whitespace = detected by isspace (https://www.cplusplus.com/reference/cctype/isspace/)) as well.

Can you explicitely specify a string that has problems?
You can use the 'e' syntax for string literals which can be seen here: http://avisynth.nl/index.php/The_full_AviSynth_grammar
escaped_string = e"Hello \n"
with e prefix right before the quotation mark will store actual control character into the string
Converted literals:
\n to LF-Chr(10)
\r to CR-Chr(13)
\t to TAB-Chr(9)
\0 to NUL-Chr(0)
\a to Chr(1)-alert/beep
\f to FF-Chr(6)
\\ (double \) to Backslash
\" to " (double-quotation mark)

[pinterf]

@Reel.Deel:
An Avisynth wiki request: could you please put a proper internal link into the section http://avisynth.nl/index.php/Script_variables | Variable types | string
to link to http://avisynth.nl/index.php/The_full_AviSynth_grammar | Literals | escaped_string example.
(I was not able to figure out how to do it in a nice way)

[wonkey_monkey]

Can you explicitely specify a string that has problems?


All of the following fail (no trailing spaces):

expr("
x")

expr("100
x +")

expr("x
100 +")


The last one (and only the last one) can be made to work if a space is added after the 'x'.

[pinterf]

All of the following fail (no trailing spaces):

expr("
x")

expr("100
x +")

expr("x
100 +")


The last one (and only the last one) can be made to work if a space is added after the 'x'.
Thanks for the examples, request registered.

[wonkey_monkey]

Something else I find odd about expr2 is that (optSSE2 = false, optAVX2 = true) does not use AVX2. I assume the two options are somewhat mutually exclusive, in that it never uses both at the same time, in which case maybe a single parameter to specify a level of optimisation - 0 for none, 1 for SSE2, 2 for AVX2 - would make more sense.

[pinterf]

Something else I find odd about expr2 is that (optSSE2 = false, optAVX2 = true) does not use AVX2. I assume the two options are somewhat mutually exclusive, in that it never uses both at the same time, in which case maybe a single parameter to specify a level of optimisation - 0 for none, 1 for SSE2, 2 for AVX2 - would make more sense.
optXXXXX-like parameters are primarily debug parameters, they can appear, disappear, change meaning, etc. In this specific case this is how it works, when I was simply put optSSE2 = false then I wanted to test plain C code.

[StainlessS]

escaped_string = e"Hello \n"
with e prefix right before the quotation mark will store actual control character into the string
Converted literals:
\n to LF-Chr(10)
\r to CR-Chr(13)
\t to TAB-Chr(9)
\0 to NUL-Chr(0)
\a to Chr(1)-alert/beep
\f to FF-Chr(6)
\\ (double \) to Backslash
\" to " (double-quotation mark)


P, above looks odd to me, the two in red show,
"\a" converted to Chr(1) [ie SOH, Start Of Header] instead of Chr(7) [ie BEL, aka alert or beep, make a printer go "ding!"]
"\f" converted to Chr(6) [ie ACK, Acknowledge] instead of Chr(12) [ie FF or FORMFEED, feed printer to next page].
[EDIT: Looks like youve used '\a' = CTRL/1, '\f' = CTRL/6, where 'a' is first letter of alphabet and 'f' is 6th.]
[EDIT: Above in RED is wrong on wiki, see 3 posts after this one. Some of below assumes that AVS works as on wiki.]

Is there some reason for this ?

Also, I've personally found another that should maybe be intercepted, ie single '\' at end of line, where I personally copy it ('\') explicitly,
ie end the line with a backslash [but maybe it should be swallowed, ie removed from output line].

[EDIT:
Reason for copy rather than omit, is to show user that maybe erroneous backslash is in the source string, rather than hide it,
I also copy any other non reconised escaped chars verbatim including preceding '\'.
I also process '\v' and '\b' where not mentioned on wiki

while(c=*r) {
if(c=='\\') {
++r;
c=*r;
// abfnrtv
switch (c) {
case '\0' : *p++='\\'; break; // copy single backslash at end of string
case '\\' : *p++=*r++; break; // replace double backslash with single backslash
case 'n' : ++r; *p++='\n'; break; // '\n' = chr(10)
case 'r' : ++r; *p++='\r'; break; // '\r' = chr(13)
case 't' : ++r; *p++='\t'; break; // '\t' = chr(9)
case 'v' : ++r; *p++='\v'; break; // '\v' = chr(11)
case 'f' : ++r; *p++='\f'; break; // '\f' = chr(12)
case 'b' : ++r; *p++='\b'; break; // '\b' = chr(8)
case 'a' : ++r; *p++='\a'; break; // '\a' = chr(7)
default : *p++='\\'; *p++=*r++; break; // anything else we copy backslash and whatever follows
}
} else {
*p++=*r++;
}
}
*p=0; // nul term

END EDIT:]

In my given script function, I also considered BACKSPACE ['\b', Chr(8)] as whitespace, maybe I was wrong on that [was done from memory, and mine dont have parity/ECC :) ].

Also, "\0 to NUL-Chr(0)", will presumably end the string prematurely if there are following chars in string, which maybe should also have warning on Wiki.

EDIT: I personally know nothing about locales and the like, makes me feel sick just to think that, that stuff exists.

EDIT: In RT_String, RT_Subtitle, RT_WriteFile, format string, I convert substring "\a" to BEL Chr(7), so I could not use AVS escaped strings to do the same,
in RT_Subtitle, I use single code '\a' Chr(7) BEL character as a color control code switch, eg substring "\a!" = switch to Hi-lited text, and "\a-" = normal text, + others for different colors. [Single char code '\a' Chr(7) BEL, is a color switch introducer or preamble code, with actual color switched by single char code eg '!' being hilite, and '-' being normal text
(and other color codes any one of these "0123456789ABCDEFGHIJKLMNOPQRSTUV" + a few more)].

EDIT:
A bit O.T.
[EDIT: Looks like youve used '\a' = CTRL/1, '\f' = CTRL/6, where 'a' is first letter of alphabet and 'f' is 6th.]
MI5, Stands for Military Intelligence England {well UK}, 5 = "E" = 5th letter of alphabet.
MI6, Stands for Military Intelligence Foreign {not UK}, 6 = "F" = 6th letter of alphabet. [James Bond works for MI6]
Combat18, Stands for Combat A.H. = Combat Adolf Hitler. {I'm not a member - membership refused for being too radical}
End OT.

[gispos]

AnsiString stuff: internally you can use String and not AnsiString.
Then it can be converted to utf8 if needed.
var unistring: String := ...
var Bytes: TBytes;
Bytes := TEncoding.UTF8.GetBytes(unistring);


Import has also an alternative form for utf8 filenames (if windows codepage is not utf8 natively): Import(filename [, ...] [, bool utf8])
then pass this buffer to Eval if Windows system codepage is set to UTF-8.

As for frame properties: there is a fix in these post-3.7 version which does not crash (yes, there was a bug) when using frame property related functions from C.
Thanks for the answer.
I've already tried various things, with and without a buffer.
As a string with a pointer with @ as PByte as an Array as PChar with and without EncodeUTf8 and none of that worked.
As soon as MCTemporalDenoise() is present in the script, the error message division through 0 appears, I don't know why.
At the moment I don't have any energy to test the whole thing again, someday...

What about the AvsPmod Utf-8 problem, do you have a solution for it?
The script is Utf-8 encoded and is passed with 'Eval', but Avisynth may not accept that.
If I save the script and open the script in a new script with AviSource, there are no problems.

[pinterf]

What about the AvsPmod Utf-8 problem, do you have a solution for it?
The script is Utf-8 encoded and is passed with 'Eval', but Avisynth may not accept that.
What does it mean 'may not accept'?.
If the script text itself is converted to utf8, you have to ensure that it is saved _without_ BOM.
If
- the script is accepted
- win10 codepage is set to utf8
then it will show utf8-encoded strings in Subtitle, open utf8-encoded filenames without specifying utf8=true for methods which accept such parameters.

[zorr]

Thanks again. I'm running MVTools tests again and looks like it could take a couple of days until they're finished, I'll test after that.

Those tests took a bit longer than I expected... but I have now tested the clip type frame property read functionality. IT WORKS! :D

I made myself little helper functions to store and restore clips into/from other clips.

function storeClip(clip c, clip stored, string name) {
return propSetClip(c, name, function[stored](clip c) { return stored } )
}

function restoreClip(clip c, string name) {
return ScriptClip(c, function[name]() { return propGetClip(name) })
}


With these you can do for example

clipA = clipA.storeClip(clipB, "storedB")
and later read the stored clip with

clipB = clipA.restoreClip("storedB")

I wasn't able to make clips with with arrays though. Perhaps I didn't get the syntax right but this

return ScriptClip(clipA, function[]() { return propGetAsArray("storedB")[0] })

returns ScriptClip: Function did not return a video clip! (Was the undefined value) if I store an array of clips and ScriptClip: Function did not return a video clip! (Was a float) if I store an array of floats (this just to demonstrate that I'm able to store something into the array).

I stored two clips using

clipA = propSet(clipA, "storedB", function[clipB](clip c) { return clipB } )
clipA = propSet(clipA, "storedB", function[clipB](clip c) { return clipB }, mode=1 )


Trying to do the same using

clipA = ScriptClip(clipA, function[](clip c) { propSetArray("storedB",function[](clip c) { return [clipB, clipB] } ) })
results in AddProperties: Error in Function: defined at ... This same syntax works for storing floats though:

clipA = ScriptClip(clipA, function[](clip c) { propSetArray("storedB",function[](clip c) { return [1.0, 1.1] } ) })

[StainlessS]

OK, in post #1142 [2 previous : EDIT: 3 previous] the wiki is in error.

escaped_string = e"Hello \n"
with e prefix right before the quotation mark will store actual control character into the string
Converted literals:
\n to LF-Chr(10)
\r to CR-Chr(13)
\t to TAB-Chr(9)
\0 to NUL-Chr(0)
\a to Chr(1)-alert/beep
\f to FF-Chr(6)
\\ (double \) to Backslash
\" to " (double-quotation mark)

'\a' should map to Chr(7), BEL, aka ALERT, BEEP, and '\f' to Chr(12), FF, FORMFEED.


BlankClip(width=320,height=240)

s=e"\a\t\n\f\r" # OK conversions
#s=e"\b\v\" # Not OK conversion, \b an \v not supported/converted : NOTE Final LONE BackSlash

Z=""
For(i=1,strlen(s)) {
c = MidStr(s,i,1)
n = ord(c)
q = qfn(n)
Z = RT_string("%s%d ] %d '%s'\\n",Z, i,n, q) # This appends to existing Z [a bit less string mem usage than Z=Z+String]
}
Subtitle(Z,lsp=0,font="Courier New")

Return Last

Function qfn(int n) {
if(7 <= n <= 13) { return Select(n-7,"\a","\b","\t","\\n","\v","\f","\r") } # '\n' -> '\\n' avoid subtitle prob
else { return chr(n) }
}


s=e"\a\t\n\f\r" # OK conversions
https://i.postimg.cc/9MczcJdh/q-01.jpg (https://postimages.org/)


Also, I've found another that should maybe be intercepted, ie single '\' at end of line, where I personally copy it ('\') explicitly,
ie end the line with a backslash [but maybe it should be swallowed, ie removed from output line].

Uncommenting this line

s=e"\b\v\" # Not OK conversion, \b an \v not supported/converted : NOTE Final LONE BackSlash

s=e"\b\v\"
https://i.postimg.cc/X7rqNZCp/q-01.jpg (https://postimages.org/)

Note, in above image, the final '\' BackSlash in line has actually escaped the closing double quote, and made it part of result string,
which it really should not.
EDIT:
\" to " (double-quotation mark)
It surely cannot mean that the double quote which marks extent of the string can be made part of the string ???
\" to double quote, should only work inside triple quoted strings to escape a single double quote which does not belong
to end triple quotes.

EDIT:
s=e"\b\v\"z" # NOTE, produces syntax error in script (hence triple quote requirement, or parser fix)

But this works
s=e"""\b\v\"z""" # Escaped double quote, must enclose in triple double quotes
https://i.postimg.cc/3wfJHYxg/q-02.jpg (https://postimages.org/)

EDIT: and this, premature end of string [needs mention on wiki for "\0"].
s=e"\t\0something missing"
https://i.postimg.cc/NjBg9bJC/q-03.jpg (https://postimages.org/)

The "\b" and "\v" conversions are I guess not necessary, only to match and complete those available in C,
In RT_Stats, I do convert "\b" and "\v", but only actually use Chr(8) ["\b"] in RT_Subtitle, Chr(11) ["\v"] being as yet the last spare code.

Also, not really sure that you need """\"""", as if it passes script syntax, you probably dont need to escape it (double quote) to begin with.
And "\0", is of dubious use [unless has some purpose for UTF8 or something like that]

[gispos]

What does it mean 'may not accept'?.
If the script text itself is converted to utf8, you have to ensure that it is saved _without_ BOM.
If
- the script is accepted
- win10 codepage is set to utf8
then it will show utf8-encoded strings in Subtitle, open utf8-encoded filenames without specifying utf8=true for methods which accept such parameters.
A video file with Utf-8 characters in the file name is opened with AvsPmod. AvsPmod has no problem with that. It is now written there
LWLibavVideoSource ("Это тестовый Video.mkv")
As I wrote, with 'Eval' I get an error message, I save this script and open it with AviSource there are no problems

[wonkey_monkey]

I'd like to compile Expr as a standalone filter (with a new name) DLL for my own education/amusement. Is there a simple (or even not-so-simple) way to do this? I've used cmake to make a Visual Studio project for the complete 3.7.0 and managed to compile it (the whole of Avisynth into one DLL) without any problems but I don't really know what to do next. Any hints?

[pinterf]

OK, in post #1142 [2 previous : EDIT: 3 previous] the wiki is in error.

Thanks, fixed in wiki (\a and \f byte code)
EDIT and added \b \v and \'

[pinterf]

AviSynth+ 3.7.1-test7 20210630 (https://drive.google.com/uc?export=download&id=1naR4I4tm-EifZIdbkS9M1zhtS9_2wL19)
Changes since test6
- Recognize \' and \b and \v in escaped (e"somethg") string literals (see http://avisynth.nl/index.php/The_full_AviSynth_grammar#Literals)
- Expr: allow TAB, CR and LF characters as whitespace in expression strings
- Clip content support for propGetAsArray and propGetAll


(no propSetArray changes in this version)