Avisynth+

[StainlessS]

Dont know if below is bugged, or misleading error message, or both.


# OK
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").PointResize(256,256)

# Resize: source image too small for this resize method. Width=1, Support=1.
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").BilinearResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV12").BicubicResize(256,256) # NOTE, YV12, Presumably error for chroma

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").BicubicResize(256,256) # NOTE, YV24

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").Lanczos4Resize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").GaussResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").BlackmanResize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").LanczosResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").sincResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").Spline16Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

Return Last

For eg YV24, width=2, height=2, Says width = 2, Support=2 (when it clearly produces an error message, ie seems not to support 2).

Think its been like this 4E4 (believe it exists as above in avs standard).

EDIT: Presume similar on height, untried.

[raffriff42]

>Dont know if below is bugged, or misleading error message, or both.
misleading I'd say
avs_core\filters\resample_functions.cpp(247)
if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Support=%d", source_size, int(ceil(filter_support)));
}
EDIT one quick fix if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Minimum=%d", source_size, int(ceil(filter_support))+1 );
}
So instead ofsource image too small for this resize method. Width=1, Support=1.

you would seesource image too small for this resize method. Width=1, Minimum=2.

[qyot27]

Maybe it's because I'm tired, but if a filter is supposed to support value X (as per filter_support in the code there), it shouldn't be erroring out when equal to the value of filter_support. It only should in the less than case. Unless filter_support is not actually the minimum supported value, but the maximum unsupported value (in which case it being named 'filter_support' in the code is also misleading or incorrect).

In other words, either the operator in the code is wrong (it should be just <, not <=) or the naming of both 'filter_support' and the 'Support' field in the error message are wrong.

[raffriff42]

I'm getting access violations when downsizing inside an Animate call. Maybe it's just my system.
It does not happen in AVS 2.6.1, and it does not happen when "z_" avsresize (https://forum.doom9.org/showthread.php?t=173986) filters are substituted.ColorbarsHD(width=640, height=400)

## optional - these do not change the test result
KillAudio
ConvertToYV12
Trim(0, length=150)

Animate(0, 120, "_MyBlur", 0.0, 60.0)

## optional - make the clip longer so AvsMeter can chew on it
R=Reverse
Last+Reverse
Loop(100)

return Last

function _MyBlur(clip C, float rad)
{
##
## HEART OF THE TEST:
## BilinearResize causes intermittent...
## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
## | Module: C:\Windows\system32\KERNELBASE.dll
## | Address: 0x00007FFF071D92FC
## (64-bit)
## or...
## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
## | Module: C:\Windows\SysWOW64\avisynth.DLL
## | Address: 0x618064ED
## (32-bit)
## but avsresize "z_BilinearResize" is OK
##
return (rad<0.1) ? C
\ : C.BilinearResize(
\ m4(Float(C.Width)/(rad+1.0)),
\ m4(FLoat(C.Height)/(rad+1.0)))
\ .GaussResize(
\ C.Width, C.Height, p=19)
}

### MOD-4-and-at-least-16 helper function
## @ Didée
function m4(float f)
{
(f<16) ? 16 : Int(Round(f/4.0)*4)
}

[StainlessS]

Did not try z_lib resizers, but your script (as supplied, running for 3 mins) does OK on XP32 bit.

EDIT: OK after redo at 6 mins.

Why this, (Round produces an Int already, you can answer for Didee if you like [did it change in more recent version of Avs])

(f<16) ? 16 : Int(Round(f/4.0)*4)


EDIT: Only relevant mention of round I could find,
Changes from 2.06
Fixed ceil, floor and round functions.


Avs+ thread 1 Million and 25 thousand views since Sept 2013, WOW ! [cookies seem to track if user viewed already].

[pinterf]

I'm getting access violations when downsizing inside an Animate call. Maybe it's just my system.
It does not happen in AVS 2.6.1, and it does not happen when "z_" avsresize (https://forum.doom9.org/showthread.php?t=173986) filters are substituted.
Thanks, reproduced.
EDIT: and fixed on git.

[`Orum]

I'm curious, is it still best practice not to cache frames ever, for any purpose, as this post (https://forum.doom9.org/showthread.php?p=1649886#post1649886) suggests? I'm still running into a few performance issues and I think they may be, at least in part, due to hammering the PCIe bus constantly when moving frames between the CPU and GPU.

[Motenai Yoda]

merge seems broken with 10 12 14 bit clip

[StainlessS]

Yoda, give some example for Pintef, please.

[Motenai Yoda]

Yoda, give some example for Pintef, please.

convertbits(10) #12 or 14
merge(last,0.33)
convertbits(8)

I also notice some memory leak since few releases, with avspmod, it will eat a lot of ram even with few previews after script modifications, but not sure is an avs+ bug or avspmod or other filter. It usually thrown an out of memory error like "can't access frame at this position" and then I get even some windows stuff not working well.

[`Orum]

I also notice some memory leak since few releases, with avspmod
I noticed something similar with ThrowError() and a lot of text, where AvsPmod (and not AviSynth+ I think--I'll have to test in another app when I have time) would essentially turn into this:
for(;;)
malloc(1000000);
In any case I would never assume leaks or bugs are in AviSynth+ by testing with only AvsPmod, considering how insanely buggy AvsPmod alone is.

[TheFluff]

I noticed something similar with ThrowError() and a lot of text, where AvsPmod (and not AviSynth+ I think--I'll have to test in another app when I have time) would essentially turn into this:
for(;;)
malloc(1000000);
In any case I would never assume leaks or bugs are in AviSynth+ by testing with only AvsPmod, considering how insanely buggy AvsPmod alone is.

If AvsPmod attempts to catch an exception thrown from inside Avisynth (for example, if a plugin raises an error using Avisynth's ThrowError), then yes, it'll most likely leak the exception object (if the catch actually works at all, which isn't certain either). Attempting to catch an exception from across a DLL boundary should in general never be done. It is only safe if both sides are built with the exact same compiler and linked with exactly the same runtime, but even then, just don't. Avisynth API calls should never be wrapped in try/catch blocks. See this (http://avisynth.nl/index.php/Avisynthplus/Developers) article on the wiki.

[`Orum]

it'll most likely leak the exception object
That still doesn't explain why it would endlessly allocate memory until it couldn't any more.

Anyway, the point was that at the very least AvsP[mod] shouldn't be a test for memory leaks from AviSynth+. It should be tested with something a lot more stable, e.g. VirtualDub, avs2yuv, AVSmeter, etc. And even then, to make sure the leak is within AviSynth+ itself one should avoid external filters.

[pinterf]

New build with important fixes and some minor tweaks. Thanks for the reports.
Download Avisynth+ r2664-MT
(https://github.com/pinterf/AviSynthPlus/releases/tag/r2664-MT)

In this changelog I left there intentionally some lines about a finally postponed modification. Read it as a preliminary info (32 bit float YUV chroma format). We could start a discussion about it.

20180328 r2664
--------------
- Fix: YUY2 Sharpen overflow artifacts - e.g. Sharpen(0.6)
- Fix: Levels: 32 bit float shift in luma
- Fix: Merge sse2 for 10-14bits (regression)
- Fix: AVX2 resizer possible access violation in extreme resizes (e.g. 600->20)
- Fix: 32bit float PlanarRGB<->YUV conversion matrix
- Fix: VfW: fix b64a output for OPT_Enable_b64a=true
- Enhanced: VfW output P010 and P016 conversion to SSE2 (VfW output is used by VirtualDub for example)
- Enhanced: ColorYUV: recalculate 8-16 bit LUT in GetFrame only when changed frame-by-frame (e.g. in autowhite)
- Enhanced: ConvertBits 32->8 sse2/avx2 and 32->10..16 sse41/avx2 (8-15x speed)

Not included, preliminary for the near future:
- Big change: 32 bit float YUV formats, U and V are now zero based.
Internally YUV 32 bit float chroma center became 0.0 (the neutral value which is 128 in the 8-bit world)
Like in VapourSynth or in avsresizer using z.lib image library.
'Expr' changes are affecting built-in constants/operators when used in chroma plane of a 32bit clip.
- 'cmin', 'cmax' return the zero-based shifted versions of the 16 and 240 (8 bit) values
- For U and V planes, constant 'range_half' results in 0.0 instead of the old 0.5
- 'scaleb' will also give zero-based result when found in an expression for chroma plane
(e.g. for a 32 bit float clip the '128 scaleb' will result in 0.0 instead of 128/255 for U and V planes)
But 'scalef' when the target or source of the constant conversion is 32bits, remains independent from the plane type.
- 'range_max' is 0.5 for 32 bit float chroma
- new constant 'range_min', which is -0.5 for 32 bit float chroma, (0 otherwise)

Additional warning: when you move 32bit float U or V plane to Y using CombinePlane, you have to be sure
that your filters do not rely on this new Y plane being in 0..1 range. Or else convert it by using Expr("x 0.5 +") to the 0..1 range
Similarly: ExtractU and ExtractV will simply return the unaltered chroma planes, which are now zero-centered

[GMJCZP]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

[`Orum]

Are variables not cached along with frames? For example (forgive the obvious assumptions made, it's just to illustrate the problem):
#define MAX_DELTA 1

for(int f = 0; f < 100; f++) {
PVideoFrame vf = clip->GetFrame(f, env);

strstream dbg;
dbg << env->GetVarDef("FFPICT_TYPE", AVSValue('?')).AsInt() << ends;
OutputDebugStringA(dbg.str());
dbg.freeze(false);

for(int n = 1, n <= MAX_DELTA; n++)
foo(vf, clip->GetFrame(f + n, env)); // What foo() does isn't really relevant here, just know that it doesn't request any frames
}
If you raise MAX_DELTA, you suddenly get different output for your FFPICT_TYPE vars! This could also be a bug in FFVideoSource() but it seems more likely (to me, anyway) that the variables set when a frame is retrieved are not cached and restored when that frame is requested again and returned from AviSynth+'s cache later on. So, is that the case?

Edit: I can write my own filter in order to rule out (or in) FFVideoSource() as the problem if you'd like.

[pinterf]

Avisynth has no frame properties like Vapoursynth has. The method of filling the variable is a workaround hack which probably works only when the variable is constant.
You can define a filter to NonCachedGenericVideoFilter, like Reverse or Loop (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/edit.h#L220) works internally.

[`Orum]

The method of filling the variable is a workaround hack which probably works only when the variable is constant.
Ah, that's unfortunate. I don't suppose there's any chance this will change in the future?
You can define a filter to NonCachedGenericVideoFilter
Correct me if I'm wrong but this won't fix the issue if, for example, you have a script like this:
FFVideoSource("foo.mkv")
bar()
myfilter()
If bar() is someone else's filter that's cached and does frame requests outside of the current frame, my filter would still have issues getting the correct FFPICT_TYPE, right?

Edit: Now that I think about it, even if AviSynth+ cached these it would still require the earlier filter to do the request for any non-offset frames last. For instance, if you think about a filter that does a temporal blend of frame 'f' with radius 'x' (forward and backward), it would still have to request frame 'f' last and not frame 'f + x' to get the variable correct. It seems like a better solution is to either parse the the FFVideoSource() cache (if that even contains the picture types), or the source file itself, but neither is friendly if there's a simple Trim() in the script before it hits myfilter(). :( In any case, there's no general solution, as even the idea of a picture type disappears with any temporal filtering.

[GMJCZP]

I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

Someone?

[poisondeathray]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

Someone?

No problems here.

[LigH]

Nope. Via Deutsche Telekom, immediate appearance of avisynth.nl and github.com; possibly your provider?

[GMJCZP]

And how are you doing with the download speed by GitHub, LigH?

[LigH]

70 KB (MABS) go quickly ... do you know any with a large package?

OK, MPC-HC (14 MB): faster than I can confirm the target directory.

[GMJCZP]

It must be my provider, thanks.

[tormento]

@pinterf

Would you please add to ConvertBits the same dithering modes Ditherpost has? At least the most significative ones, i.e. 0 (ordered+noise),6,7,8.

[magiblot]

Thanks for the update.
I do not know if someone happens to me but the downloads by GitHub are very slow, and I have problems entering to avisynth.nl.

I can't enter AviSynth.nl from Spain. Server does not reply. I have to use Google's cached version or a free proxy. There are periods of time where it works again for me, but not currently.

[Motenai Yoda]

@pinterf

Would you please add to ConvertBits the same dithering modes Ditherpost has? At least the most significative ones, i.e. 0 (ordered+noise),6,7,8.

actually:
dither=-1 (default) -> mode=-1 aka round to int (or truncate?)
dither=0 -> mode=0 aka ordered dithering
dither=1 -> mode=6 aka Floyd-Steinberg

[StainlessS]

Magiblot,

Test DNS servers and settings for a domain name

http://dnscheck.pingdom.com/?domain=avisynth.nl

Test finished successfully, no errors or warnings.

Must be something wrong between you and Avisynth.nl (works just fine for me).

EDIT: IsItDownRightNow (OK)
https://www.isitdownrightnow.com/avisynth.nl.html

[tormento]

actually:

dither=-1 (default) -> mode=-1 aka round to int (or truncate?)

dither=0 -> mode=0 aka ordered dithering

dither=1 -> mode=6 aka Floyd-Steinberg

From Wiki:
int dither
If 0, add ordered dither; if -1 (default), do not add dither

Is it outdated?

[raffriff42]

From Wiki: [...] Is it outdated?Yes, it was outdated... thx, fixed now.
https://www.dropbox.com/s/xl6nzwst0ioso65/dither-2018-03-01.png?raw=1

https://www.dropbox.com/s/s3ameoyc8dytt8e/dither-2018-03-02.png?raw=1

https://www.dropbox.com/s/zcx7twt1bea78t8/dither-2018-03-03.png?raw=1

ColorBarsHD(pixel_type="YUV444P16")
Crop(300, 440, 816, 80)
ColorYUV(cont_y=0.1, cont_u=0.1, cont_v=0.1, f2c=true)
Interleave(
\ ConvertBits(8, dither=-1).Subtitle("dither=-1") [* no dither *]
\ , ConvertBits(8, dither=0).Subtitle("dither=0") [* ordered dither *]
\ , ConvertBits(8, dither=1).Subtitle("dither=1") [* Floyd-S *]
\ )
ColorYUV(cont_y=10.0, cont_u=10.0, cont_v=10.0, f2c=true)
return Last

[Motenai Yoda]

maybe pinterf account it still as experimental as IIRC floyd returns 2^N +1 shades, 0 + 2^N shades up to range_max

[magiblot]

Magiblot,

Test DNS servers and settings for a domain name

http://dnscheck.pingdom.com/?domain=avisynth.nl



Must be something wrong between you and Avisynth.nl (works just fine for me).

EDIT: IsItDownRightNow (OK)
https://www.isitdownrightnow.com/avisynth.nl.html

Here's my traceroute to avisynth.nl (tracert command on Windows):
traceroute to avisynth.nl (82.150.137.175), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.607 ms 5.277 ms 5.131 ms
2 168.red-81-46-38.customer.static.ccgg.telefonica.net (81.46.38.168) 5.098 ms 5.079 ms 5.031 ms
3 221.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.221) 5.005 ms 225.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.225) 4.997 ms 221.red-81-46-34.customer.static.ccgg.telefonica.net (81.46.34.221) 26.302 ms
4 * * *
5 50.red-80-58-81.staticip.rima-tde.net (80.58.81.50) 26.251 ms 26.179 ms 26.173 ms
6 et-4-0-0-400-grtbcnes1.net.telefonicaglobalsolutions.com (213.140.50.244) 4.795 ms 21.423 ms 3.039 ms
7 176.52.251.237 (176.52.251.237) 12.692 ms 12.694 ms 12.526 ms
8 176.52.251.213 (176.52.251.213) 12.623 ms 213.140.33.252 (213.140.33.252) 14.049 ms 213.140.33.249 (213.140.33.249) 13.141 ms
9 94.142.107.37 (94.142.107.37) 13.955 ms 11.986 ms 5.53.5.74 (5.53.5.74) 12.586 ms
10 94.142.97.138 (94.142.97.138) 11.507 ms xe-9-3-3.cr2-ams1.ip4.gtt.net (89.149.180.117) 51.350 ms 94.142.97.138 (94.142.97.138) 12.498 ms
11 atom86-gw.ip4.gtt.net (77.67.72.67) 43.810 ms 40.651 ms 94.142.107.37 (94.142.107.37) 12.848 ms
12 xe-9-3-3.cr2-ams1.ip4.gtt.net (89.149.180.117) 46.916 ms a572.datact.atom86.net (95.142.96.179) 42.362 ms 41.976 ms
13 atom86-gw.ip4.gtt.net (77.67.72.67) 40.117 ms * 39.640 ms
14 a572.datact.atom86.net (95.142.96.179) 41.511 ms * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

The IP packets die at a572.datact.atom86.net (95.142.96.179). I obtained the same result by using online traceroute tools (http://www.monitis.com/traceroute/, https://www.ultratools.com/tools/traceRoute). We should open a separate thread for this or contact the webmaster of avisynth.nl (I don't know who they are).

[StainlessS]

Tracing route to avisynth.nl [82.150.137.175]
over a maximum of 30 hops:

1 1 ms 1 ms 6 ms 192.168.100.1
2 * * * Request timed out.
3 60 ms 66 ms 76 ms 172.23.192.145
4 75 ms 40 ms 58 ms 172.30.146.163
5 48 ms 59 ms 59 ms 188.31.255.42.threembb.co.uk [188.31.255.42]
6 47 ms 56 ms 61 ms 188.31.255.85.threembb.co.uk [188.31.255.85]
7 57 ms 59 ms 59 ms 188.31.255.117.threembb.co.uk [188.31.255.117]
8 57 ms 61 ms 59 ms 188.31.255.154.threembb.co.uk [188.31.255.154]
9 66 ms 65 ms 57 ms 188.31.255.170.threembb.co.uk [188.31.255.170]
10 55 ms 61 ms 54 ms ae26-65.cr0-lon1.ip4.gtt.net [46.33.78.5]
11 59 ms 66 ms 80 ms et-2-1-0.cr2-ams1.ip4.gtt.net [141.136.105.89]
12 80 ms 79 ms 79 ms atom86-gw.ip4.gtt.net [77.67.72.67]
13 51 ms 39 ms 71 ms a572.datact.atom86.net [95.142.96.179]
14 74 ms 77 ms 79 ms mysmt175.mysmt.net [82.150.137.175]

Trace complete.


Tracert on mine is pretty slow, but I get straight to site via browser (even after IpConfig/flushdns).

EDIT: Above using OpenDNS resolver.

EDIT: Depending upon how your Firewall is set up, you may need to provide filewall access to multiple DNS servers (I allow about
6), and I use Nirsoft QuickDNS to switch DNS via hotkey (easy peasy):- https://www.nirsoft.net/utils/quick_set_dns.html

[raffriff42]

This browser stuff is way off topic, but I had a similar problem which I solved by manually adding a new DNS server (https://iihelp.iinet.net.au/Manually_Setting_DNS_Server). There is a selection of free DNS servers here (https://www.lifewire.com/free-and-public-dns-servers-2626062).

[`Orum]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).

[poisondeathray]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).


"Video white" or legal range white, no longer becomes legal range white if you use fulls=true. In 10bit video, legal Y should be 64 to 940 . ie. the 8bit "235" should "map" to 10bit "940" . You could argue that "legal range" video usage case is more common

[foxyshadis]

I'm curious, what's the rationale behind fulls=false as the default for YUV when using ConvertBits()?

Edit: I ask mainly for up-converting, as e.g. white in 8 bit (255) is no longer truly white when in 10+ bit without fulls=true, it's just very close to true white (i.e. UCHAR_MAX << (BitsPerComponent() - 8)).

The lower bound of the upsampled white point is always white in video standards. For 10-bit full range, that means 1020 and 1023 are the same full white, as are 940+ in limited range. BT.2020 defines the hard peak as 940. Engineers worried about that exact problem and decided that a simple bitshift would always be correct.

This isn't true for HDR, but that's an entirely different ballgame.

[`Orum]

The lower bound of the upsampled white point is always white in video standards.
Interesting. It seems a bit counter-intuitive that different values would have the same output, outside of limited-range clips
This isn't true for HDR, but that's an entirely different ballgame.
...but how can a decoder possibly differentiate between a 10-bit HDR clip and a 10-bit clip from the video standards? I seems to me like the standards conflict; e.g. a HDR clip would assume 1023 != 1020 but if decoded as a "standards compliant" clip the white point would be clippped to 1020.

Edit: Granted, none of this matters if you're only using 10-bit to reduce quant error, but it's interesting nonetheless.

[foxyshadis]

...but how can a decoder possibly differentiate between a 10-bit HDR clip and a 10-bit clip from the video standards? I seems to me like the standards conflict; e.g. a HDR clip would assume 1023 != 1020 but if decoded as a "standards compliant" clip the white point would be clippped to 1020.

Edit: Granted, none of this matters if you're only using 10-bit to reduce quant error, but it's interesting nonetheless.

The decoder is only producing those 941 or 1023 values, it has no input on what's done afterward. The metadata tells the YUV->RGB converter what formula to use and where to saturate. If the converter sees YUV 990,512,512 (assuming BT.709), it'll still output 255,255,255 or 1023,1023,1023. We call that a blown-out highlight.

HDR is different because now 990,512,512 can actually mean something useful; it's often converted to a floating point value that's scaled against the display's actual white point before being converted into raw RGB to display. 900 may convert to only 600 if a display can produce blinding enough whites. That's why it has to be signaled, there's no way to infer what white point was meant out of raw pixel values other than assuming. Some HDR schemes still saturate at limited range, and simply rescale everything within it; some place the rec.709 white point at the end of the TV range and everything outside of it is special. The former is more common.

[`Orum]

The metadata tells the YUV->RGB converter what formula to use and where to saturate.
Ah, I didn't realize there was a flag in the format to indicate it had been upsampled instead of a native/HDR clip.
:thanks:

[bxyhxyh]

I found a bug, when I was trying to minimize rounding errors of resize.blur.blur.blur.resize.sharpen.sharpen.sharpen.sharpen kind of script.

source
https://i.imgur.com/3ZWGafM.png

source.Spline16Resize(512,384)
https://i.imgur.com/cMSAK4G.png

source.ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()
https://i.imgur.com/7ZUX4ee.png

All resizers and all target resolutions are the same.

[poisondeathray]

source.ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()



I get different results than you. They are the same (or very similar) for me. What version of avisynth+?

[bxyhxyh]

Avisynth+ 0.1 r2636.
Ok I checked the release page. It was 2664.
I'm gonna see that.

[poisondeathray]

Try updating?
I'm using r2664 x64

[bxyhxyh]

Ok. Checked it, it was the same for r2664 x86. Maybe something might be wrong with my end.
I'll try full installer.

[poisondeathray]

The other difference is x86 vs x64 ?

[bxyhxyh]

Switched to x64 version, still same.
Updated all in one microsoft redistributable, no change.

[poisondeathray]

Switched to x64 version, still same.
Updated all in one microsoft redistributable, no change.

can you confirm with version() ?

[Groucho2004]

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

[poisondeathray]

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

But that's a problem...

I used ImageSource() too , and it returns RGB24 on the source PNG (as expected)

And I can't reproduce it in RGB24, or YV12, or YV16, or YV24

[bxyhxyh]

can you confirm with version() ?
https://i.imgur.com/E8M6DXP.png

I can reproduce it. Adding a simple "ConvertToYV12()" (or YV16/YV24) after the source filter (I used "ImageSource()") fixes it.

Same for me too.
But I need to convert it to YV24/YV12 after the resizing, so it's really problematic for me.

Well, I can live with converting the source to the YV24 for now I guess.
BTW I'm on Windows 8.1

[poisondeathray]

I'm on Win8.1 too . Haswell (only AVX2) ; maybe some instruction issue ? what CPU ?

What about ConvertTo16Bit only ? or ConvertTo16Bit and the resize only (RGB48) ?

[poisondeathray]

Or use avsresize (zimg/z.lib) as a workaround

But I'm curious why I can't reproduce bug


ConvertToPlanarRGB()
z_ConvertFormat(512,384,resample_filter="spline16",pixel_type="RGBP16")

[bxyhxyh]

I'm on Win8.1 too . Haswell (only AVX2) ; maybe some instruction issue ? what CPU ?

What about ConvertTo16Bit only ? or ConvertTo16Bit and the resize only (RGB48) ?

ConvertTo16Bit and the resize only. Even if I insert some filters before resize, it still is the same.
CPU is Ivy Bridge

[pinterf]

I'll check it soon

EDIT: cannot reproduce. Tested with AVX2, AVX-only, SSE4.1 only builds. (Win10)

Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}
source=ImageSource("test.png").Info().trim(0, 100) # 256x224 RGB24
c8=source.Spline16Resize(512,384)
c16=source.ConvertTo16Bit().Spline16Resize(512,384).ConvertTo8Bit()
StackVertical(c8,c16,Diff(c8,c16))

[Groucho2004]

But that's a problem...

I used ImageSource() too , and it returns RGB24 on the source PNG (as expected)

And I can't reproduce it in RGB24, or YV12, or YV16, or YV24
I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).

[tormento]

pinterf's test build r2671
Can we play with it too? :cool:

[Groucho2004]

Can we play with it too? :cool:I suppose pinterf won't object:
http://www.mediafire.com/file/kmq3po2cw2b3inw/AvisynthPlus_r2671tst.7z

[pinterf]

I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).
Ahh, RGB32. Reproduced.
EDIT: RGB64 Turnleft / Turnright issue (which is used in RGB64 resize)
EDIT2: Bug found and fixed. I'll prepare a release in the near future.

[pinterf]

x86 test (mediafire link) (not a release)
(see also readme_history.txt for other interesting changes)
http://www.mediafire.com/file/een9bfx66sigzlr/AvisynthPlus_r2671_test2.7z

[Groucho2004]

x86 test (mediafire link) (not a release)
(see also readme_history.txt for other interesting changes)
http://www.mediafire.com/file/een9bfx66sigzlr/AvisynthPlus_r2671_test2.7zWorks now for me with all RGB colour spaces. :)

[pinterf]

Thanks for testing. This rgb64 bug must have been there since the beginnings.

[bxyhxyh]

I tested again with this script:
imagesource("3ZWGafM.png", pixel_type = "RGBXX") #XX to be substituted with 24/32/48/64
ConvertTo16bit().Spline16Resize(512,384).ConvertTo8bit()

The resulting image is corrupted for RGB32 and RGB64 but looks fine for RGB24 and RGB48, tested with r2664 and pinterf's test build r2671 on XP32 (no AVX optimization).
Double checked this. Result is same.
Test build 2 fixes it.

Sorry guys, I should have provided a sample so problem would be found faster.

[tormento]

I suppose pinterf won't object:
http://www.mediafire.com/file/kmq3po2cw2b3inw/AvisynthPlus_r2671tst.7z
Need x64 :p

[Stereodude]

Can I put in a feature request for Avisynth+ to add ConditionalReader capability to the internal RGBAdjust filter (like ColorYUV has)?

[pinterf]

Need x64 :p
I am planning to put together a proper release in the near future (but probably "near" <> 1-2 days)

[pinterf]

Unofficial test build (x86/x64 installer w/o VC2017 redistributables)
https://drive.google.com/open?id=1sjNKaukrz51RiCtHd88nwIRavOU0PqmF

I hope some of you will find some new exiting features in this build. (And report bugs if they are found)


- AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.

[MysteryX]

What is the format code for 32-bit YUV420?

Also, is VapourSynth 32-bit based around .5 or around 0?

[shekh]

- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)


Amazing.

[MysteryX]

- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
Next step will be porting this updated VirtualDub interface to VapourSynth, which should be easy -- EXCEPT that VapourSynth doesn't have any stacked format...

[MysteryX]

Would it be a good idea to add an option for VirtualDubFilter to pass YUV data in RGB format without converting it? This would be useful for filters that support only RGB format but if YUV was sent in that format it would work as well.

[jpsdr]

Nice !!!

[poisondeathray]

What is the format code for 32-bit YUV420?


YUV420PS

http://avisynth.nl/index.php/Avisynthplus_color_formats

[MysteryX]

YUV420PS

http://avisynth.nl/index.php/Avisynthplus_color_formats

It's not in the list above

[poisondeathray]

It's not in the list above

It's in the list under pixel type. Or were you asking for something else like fourcc code ? It doesn't have a fourcc

Or did you mean the *new* list posted by pinterf above ?


YUV420 YUV420PS 32


Maybe it was dropped ? Vapoursynth doesn't have support for this either, the 32bit YUV float formats are not subsampled

[lansing]

Good and long-waited fix for the virtualdub filter, now I can call multiple instances of the same vd filter without the program crashing.

[pinterf]

Would it be a good idea to add an option for VirtualDubFilter to pass YUV data in RGB format without converting it? This would be useful for filters that support only RGB format but if YUV was sent in that format it would work as well.
See CombinePlanes example and adapt to RGBA
http://avisynth.nl/index.php/CombinePlanes

[StainlessS]

I'm trying to access Pinterf upload,
Getting blocked by SonicWall, for reason 'radicalism and extremism', (something you aint tellin' us Pinterf)

Second time this has happened, currently on Cloud network wifi in pub, last time got an apology, but still now reblocked.

EDIT: Problem seems to be with MediaFire, rather than Pinterf upload.

[pinterf]

I'll try to arrange something instead of mediafire.
EDIT: Done. Link in original post edited.

[StainlessS]

Thanx P, but you should be more careful about the types of terrorist you associate yourself with. :)

[MysteryX]

For 32-bit, VapourSynth, UV is in the -.5 to .5 range. Everything else is 0 to 1.

Is it now the same with Avisynth?

[pinterf]

Yes.

I also had to update some external filters, most of their sub-filters are o.k., will work as-is, but some filters need to be updated for the new 32bit float UV ranges.
For example:
masktools2: mt_diff, predefined constants in lut expressions (finished, not released yet)
fft3dfilter: chroma center

[pinterf]

New test build
Avisynth+ r2696
https://drive.google.com/open?id=1yUiuTTTY3yGGf-7iNkbDpSdEbR6yugUm

Compared to last test build (r2693):
- ConvertBits from/to 32 bits assume full source/destination range only for RGB. Additional fix was in limited range conversion when source is 32 bits
- Avisource: Greyscale 10, 12, 14, 16 bits for Y1[0][10] .. Y1[0][16] (not tested)

Full list since last official release (r2664)
- AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Planned: include current header files and def/exp file in installer

[pinterf]

Another test build, r2700, installer w/o Visual C++ Redistributables
https://drive.google.com/open?id=1LPlP8My94_aRNQHmyqNo3Bi6--2NtdzF

Change since r2696: RGBAdjust fix and enhancements

Full change since last official release (r2664):

- Fix: RGBAdjust memory leak when used in ScriptClip
- Enhanced: RGBAdjust new parameter: conditional (like in ColorYUV)
The global variables "rgbadjust_xxx" with xxx = r, g, b, a, rb, gb, bb, ab, rg, gg, bg, ag are read each frame, and applied.
It is possible to modify these variables using FrameEvaluate or ConditionalReader.
- Enhanced: RGBAdjust: support 32 bit float ('analyze' not supported, 'dither' silently ignored)
- Enhanced: AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Planned: include current header files and def/exp file in installer

[`Orum]

As I understand it, when using GetFrame(), pitch can vary on a per-frame basis for all planes. Is it possible to get the maximum possible pitch for each plane?

The reason I ask is I'd like to avoid painful reallocations, so if I can simply allocate the maximum pitch * vi.height (right shifted by GetPlaneHeightSubsampling()) for each plane, then I don't have to worry about it exceeding my initial allocation later on.

[StainlessS]

As I understand it, when using GetFrame(), pitch can vary on a per-frame basis for all planes. Is it possible to get the maximum possible pitch for each plane?


I would say NO, unless you can find the maximum possible size of a frame.
Pitch can change because of interleaving of cropped clips, I forget what the new rules are on avs+ concerning crop and Align arg, but on v2.6 standard, Align is False by default, and so is much more likely to do a Soft Crop, ie Subframe() and SubframePlanar(), so pitch could be pretty much any size.
(I take it that you would like it to work on avs standard too).
Output frame pitch is guaranteed identical. [EDIT: When calling NewVideoFrame, ie not simply passing though a frame like in ClipClop or ReplaceFramesSimple.]

IanB Torture Test

....
A=SelectEvery(3, 0).AddBorders(0,0, 16,0).Crop(0,0, -16,0)
B=SelectEvery(3, 1).AddBorders(0,0, 32,0).Crop(0,0, -32,0)
C=SelectEvery(3, 2).AddBorders(0,0, 64,0).Crop(0,0, -64,0)
Interleave(A, B, C)
....


https://forum.doom9.org/showthread.php?p=1613005&highlight=torture#post1613005
https://forum.doom9.org/showthread.php?p=1603626&highlight=torture#post1603626
https://forum.doom9.org/showthread.php?p=1628159&highlight=torture#post1628159

[pinterf]

Alignment:
Plane pointers and pitches are 64 bytes aligned in recent Avisynth+ versions (but it was 32 bytes before - avx and avx2-safe), this is the minimum.
It can be larger, when NewVideoFrame is called with a larger align value, e.g. 128
But there is no guarantee that a pitch is simply an up-aligned value of the plane width, framebuffers are mostly re-used internally to avoid reallocation.
Plus, as StainlessS mentioned, a Crop (in avs+ always producing an aligned output, the alignment rule can never be broken), or SeparateRows can simply change the pitch value internally w/o making a frame copy.

[StainlessS]

Made edit in my previous post, I should have caught that.

Presumably, MakeWritable can change Pitch from original input too.
EDIT: On frame like this for instance:
SeparateRows can simply change the pitch value internally w/o making a frame copy.

[`Orum]

Okay, so I'm guessing the best bet here is to get the per plane pitches for the first frame, and for every later frame check if they're increased. If so, recreate my buffer with a larger size. Unless there is some better option I'm not thinking of...

[shekh]

I guess you don't have to repeat any pitch for your own buffer, just allocate whatever is sufficient?

[`Orum]

I guess you don't have to repeat any pitch for your own buffer, just allocate whatever is sufficient?
You bring up a good point. As I'm using OpenCL, that probably makes sense in some circumstances; namely, when copying a frame to a discrete GPU for processing. The trick is probably going to be figuring out the best way to perform the copy efficiently, as you either have to map the buffer and memcpy() row-by-row into the mapped buffer and then unmap, or queue each row via separate calls to clEnqueueWriteBuffer(). Neither is pretty, but may still be faster than what I'm doing now (which is copying the memory including the pitch bytes), and would at the very least avoid any reallocation.

However, if processing is done on a CPU or integrated GPU (or really anything with unified memory between host and device), this incurs an additional copy operation, which I'd like to avoid. Fortunately, this can be avoided in these circumstances (and already is in my current code), as when you create a buffer with CL_MEM_USE_HOST_PTR no copying is done anyway—or so I assume. It certainly is faster than an explicit copying of the buffer.

[`Orum]

On another note, I've noticed what I think is some color shift toward Cb-/Cr- with the ColorYUV(levels="TV->PC") / ColorYUV(levels="PC->TV"). The results look different from what I see with the conversion filters within MPC-HC, and while that means that problem could be in either MPC-HC or AviSynth+, I suspect it's in AviSynth+. Why? Consider the following script:
function s(clip c) {
return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV")
}

ColorBars(pixel_type="YV12")
Interleave(last.s(), last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s()) # Initial clip calls s() once because ColorBars() has some strange levels
ColorYUV(analyze=true)
Yes, it's an extreme example, and while this only proves that the functions are not reciprocal, it shows a clear trend toward green. If someone knows of another way to perform the conversion (I know "levels" is not accurate for chroma planes) to compare it against instead, let me know.

Edit: Animated for those too lazy or unable to run the script on their devices
https://my.mixtape.moe/gnfyur.png

[StainlessS]

Is it (in the main) perhaps down to a part of the 'pluge' (think thats what its called) being @ luma value 7 [EDIT: and 242] (ie non TV range).


A=ColorBars(pixel_type="YV12").BicubicResize(480,360)
B=A.ColorYUV(levels="TV->PC")
C=B.ColorYUV(levels="PC->TV")
A=A.ColorYUV(analyze=true)
B=B.ColorYUV(analyze=true)
C=C.ColorYUV(analyze=true)
StackVertical(A,B,C)


First image minimum luma is 7.
https://s20.postimg.cc/rt0cxbbx9/cyuv.jpg (https://postimg.cc/image/uzuwgxwd5/)



EDIT: Did not notice this line,
because ColorBars() has some strange levels
that would be the pluge 7 [EDIT: and 242] thing I think.
But even with pluge fixed with eg limiter, does exhibit strange behaviour as pin pointed by Orum.

ie like this

function s(clip c) {
return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV")
}

# Initial clip calls s() once because ColorBars() has some strange levels

ColorBars(pixel_type="YV12").Limiter
Interleave(last, last.s().s().s().s().s().s().s().s().s().s().s().s().s().s().s().s())
ColorYUV(analyze=true)

Still flickers a helluva lot.

EDIT:
Limiter dont work as required, mod to Levels [EDIT: This is rubbish, dont know why I thought Limiter did not work, it does]

function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

https://s20.postimg.cc/qs0480uvx/cyuv.jpg (https://postimages.org/)



EDIT: Only 1 iteration

function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s #.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

https://s20.postimg.cc/5wdtwp6dp/cyuv.jpg (https://postimages.org/)

[Motenai Yoda]

maybe it's caused by coloryuv levels work as levels(16,1,235,0,255)~levels(0,1,255,16,235)
without maintain chroma planes centered on 128, like a
mergechorma(levels(16,1,235,0,255),levels(16,1,240,0,255)) will do

[Stereodude]

What if you run the test script in 16-bits dithering back to 8-bits at the end instead of running it multiple times in 8-bits? That should point to either rounding errors or perhaps a rounding bias vs. an error in the calculations.

[poisondeathray]

Alternatively, you can use smoothlevels and set the chroma processing to zero

By default, lato set it at 100 (from 0-200) or intermediate

e.g using stainlesss's (enough sssss's :D ? )test


ColorBars(pixel_type="YV12").Bicubicresize(480,360)
Levels(16,1.0,235,16,235,coring=false) # Limiter dont work as required, results in luma Min = 10, not 16, so use Levels
A=Last
B=last.s.s.s.s.s.s.s.s.s.s.s.s.s.s.s
StackVertical(A.ColorYUV(analyze=true),B.ColorYUV(analyze=true))

#function s(clip c) { return c.ColorYUV(levels="TV->PC").ColorYUV(levels="PC->TV") }

function s(clip c) { return c.smoothlevels(preset="tv2pc", chroma=0).smoothlevels(preset="pc2tv",chroma=0) }


https://s33.postimg.cc/9bb07h99r/smoothlevels.png (https://postimages.org/)

[`Orum]

What if you run the test script in 16-bits dithering back to 8-bits at the end instead of running it multiple times in 8-bits? That should point to either rounding errors or perhaps a rounding bias vs. an error in the calculations.
The crux of the issue is I think it happens on a single instance of ColorYUV(levels="TV->PC"), at 8-bit and possibly other depths. I originally noticed it when comparing it to MPC-HC's conversion which I think is accurate.

When you add dithering, I think if anything that would only muddy the waters (as then you wouldn't be sure if the source of any shift was ColorYUV() or ConvertBits()). It would be interesting to know if it affects HBD clips, though I suspect if it does it may take more instances of conversion to get the same amount of error (in terms of relative distance).

Alternatively, you can use smoothlevels and set the chroma processing to zero
Sure you can do that, but aren't chroma planes supposed to be changed when doing TV->PC level conversion? If not one could simply do a MergeChroma() as well...

[StainlessS]

but aren't chroma planes supposed to be ...
Yes, avoid color shift.

[poisondeathray]

Sure you can do that, but aren't chroma planes supposed to be changed when doing TV->PC level conversion? If not one could simply do a MergeChroma() as well...

Maybe. I think that was the reason he chose intermediate as the default setting (chroma is processed intermediate strength). You can leave it default 100, or increase it to 200 , or 0 for YLevels like behaviour. Eitherway, you don't get contamination of greyscale patches with smoothlevels (you can disable dithering too as well) . ie. U=V . So it is a problem with coloryuv

[poisondeathray]

I took RGB test pattern (0-255), greyscale, R,G,B . ConvertToYV24(matrix="pc.709") , then PC->TV, PC->TV eight times , then back to TV. Dithering is disabled for all . The RGB screenshot used "PC" levels for the original, "REC" for the others (because they were scaled to TV)

"TV" levels means U,V should be limited 16-240, so chroma=100 looks correct at least for the max U,V value


Not only is there a green shift for coloryuv, there are more weird patterns

https://s33.postimg.cc/3ku0l75qj/smoothlevels_vs_coloryuv.png (https://postimg.cc/image/3ku0l75qj/)

[poisondeathray]

Here is a similar test on a 0-255, Y,U,V pattern (0-255 Y just copied to the U,V planes), and again 8x back and forth, and then to TV range

You end up with Y 16-235 , U,V 16-240 hard limits (so chroma=100 for smooth levels is probably correct value for typical usage scenarios), but the average is skewed with coloryuv , resulting in the colorization of greyscale values. Also see the line artifacts again with coloryuv (smoothlevels had dither disabled)
https://s33.postimg.cc/uze76ln27/0-255_YUV_pattern_compare.png (https://postimages.org/)

[pinterf]

I have noticed and commented a line in color.cpp, this is the final step in lut creation, so far calculation was done in double precision:

// Convert back to int
int iValue = int(value); // hmm P.F. 20180226 no rounding?

[`Orum]

I have noticed and commented a line in color.cpp
Ah, that might be it. Do you have a test build with rounding? Otherwise I'll probably monkey with it and build one myself.
:thanks:

[pinterf]

I'll build one then

[pinterf]

EDIT:
Limiter dont work as required, mod to Levels

Are you sure?

[pinterf]

Avisynth+ r2710 test build: installer w/o C++ redistributables.
https://drive.google.com/open?id=1tMwuXOCx47jf5SpY4VW4v99uCUtwwemj

New things since last test:
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips. 'show' option still not supported
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExists(String variable_name)
Checks if a variable exists
Returns true if variable exists, false otherwise

[LigH]

So AviSynth+ "VarExists" is comparable to PHP "isset"?

[wonkey_monkey]

So AviSynth+ "VarExists" is comparable to PHP "isset"?

Hopefully it doesn't return "false" when the variable exists but is null, which is what isset does...

[LigH]

I believe AviSynth has no "null" value/type.

[pinterf]

They can hold an 'undefined' value. But in this case the variable still exists and the function returns true.

[StainlessS]

BlankClip
#Fred=Undefined # Uncomment to show True
Ex=RT_VarExist("FRED") # Edit or r2710 VarExists
Subtitle("VarExist for fred="+String(ex))

False unless assigned Undefined [EDIT: or some variable type]
Will show true in Script function where Fred is an un-supplied optional arg, ie UnDefined. (exists but not defined as anything in particular)

[StainlessS]

Are you sure?

Went all the way back to v2.57 and could not get Limiter to fail as posted, sorry, I have not explanation, other than senility.

[StainlessS]

@P,
Note, the builtin file existing function is named Exist(), ie no ending 's', so I used RT_VarExist() and RT_FunctionExist() both without ending 's',
(I initially did RT_VarExists with ending s and changed to be compatible style with builtin Exist).

EDIT: I see that you have already implemented FunctionExists() with trailing 's', maybe too late to change


Function Fred() {return True}
BlankClip
Ex=FunctionExists("FRED")
Subtitle("FunctionExists for fred="+String(ex))


EDIT: To below,
... because of senility

Yeh, sometimes I miss out the odd 's', and sometime I add way too many, hence the usernamesssss.

[pinterf]

Good advice, thanks, unless 's' is missing from there because of senility :)

[pinterf]

Ok, VarExist name is fixed and 'show' is supported in 32bit float, here is r2713
Avisynth+ r2713 test build: installer w/o C++ redistributables.

EDIT: link refreshed (I have messed up the 32/64 bit files)
https://drive.google.com/open?id=1GCgr5rCbr5HLLA9OJJwz-7LIerlDQYLn

New things for today:
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips.
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExist(String variable_name)
Checks if a variable exists
Returns true if variable exists even if it holds 'Undefined', false otherwise

[StainlessS]

P, so you decied to keep FunctionExists with the extra 's', no sweat either way :)

Sorry, but latest ver$, have included 64 bit dll's in 32 bit install.

EDIT: And just to mitigate doubts about senility,
https://s20.postimg.cc/j62balrbx/untitled.jpg (https://postimages.org/)

EDIT: Above after total uninstall, reinstall. [WinXP32]
EDIT: Not just that dll, looks like maybe all of them.

EDIT: Double check on senility [better to be sure]


C:\Documents and Settings\root>avsmeter -avsinfo

AVSMeter 2.7.7 (x86) - Copyright (c) 2012-2018, Groucho2004

Cannot load a 64 bit DLL in 32 bit Avisynth: 'C:/Program Files/AviSynth+/plugins+/ConvertStacked.dll'.

[pinterf]

EDIT: Double check on senility [better to be sure]

Senility contest: I won.
I'll upload a proper version tomorrow, until then the ColorYUV rounding issue fix can be investigated in r2710, some posts before.

[pinterf]

r2713 reuploaded

[StainlessS]

Installed, everything hunky dory here thanx https://www.cosgan.de/images/more/bigs/e250.gif

[`Orum]

r2713's ColorYUV(levels="TV->PC") still looks different from MPC-HC's conversion (MPC-HC's caucasian skin-tone colors become redder post-conversion than AviSynth+'s), but at least it no longer seems to have the green cast any more, and repeated conversions back and forth (in AviSynth+) work fine now. So, the difference may be that MPC-HC is doing it incorrectly, I'm not really sure and don't have the time to dig through their code right now. As far as I'm concerned, the issue is resolved for AviSynth+, unless someone can demonstrate otherwise.

Thanks!

Edit: I'm starting to suspect the difference now really is related to a conversion error in MPC-HC, as other colors, like orange/yellow, appear to be oversaturated after conversion.

[pinterf]

Perhaps a rec601-709 mismatch happening somewhere in the conversion chain? (red cast)

[raffriff42]

I've noticed what I think is some color shift toward Cb-/Cr- with the ColorYUV(levels="TV->PC") / ColorYUV(levels="PC->TV")...

There is an offset-by-negative-one for each round trip.
That's not a bug, it's a consequence of 8-bit math doing something (round trip) it wasn't designed to do.
Attempting to fix it results in a slightly worse one-way conversion.
Increasing the source bit depth decreases the error; with 32-bit float it's un-measureable.
Alternatively, when you know you are doing a round trip, you could add an offset manually: function s(clip c) {
return c.ColorYUV(levels="TV->PC")
\ .ColorYUV(levels="PC->TV", off_y=1, off_u=1, off_v=1)
}

[pinterf]

New build r2719
https://drive.google.com/open?id=1gAyHUSGo8A_io8btrZZn31Z8JLfZJ3yo
And a test masktools2 (2.2.15) that matches this avisynth version
https://drive.google.com/open?id=1H0OnH_ACwJXb6iT7pO0hVlXCwd2c-afI

I'm posting both test builds here, because they are tightly connected.

real.finder, who is responsible with many old scripts, asked me for these features for a long time. And I resisted because I was against such autoconversion. Anyway, you can start experimenting but you have to understand when you can use this feature safely (but maybe it's less prone to errors than mis-using scaleb and scalef)

- LUT functions in masktools2 and Expr in Avisynth+ have now two new parameters: scale_inputs and clamp_float (see below). In same cases they allow a quite a convenient way of using old 8 bit lut expressions to be used for generic bit-depth.

- The other feature in masktools2 is the new 'use_expr' parameter.
This parameter allows passing the whole expression to Avisynth+ when the lut filter would use the slow interpreted realtime way of expression calculation (for 16 bits no xy lut table exists because it is too big to fit in the memory). Try setting use_expr=1 for mt_lutxy (that will pass the expression to Avisynth for 10 or more bits) will drastically speed up a 16bit mt_lutxy.

Avisynth:
- New: Expr: implement 'clip' three operand operator like in masktools2
Description: clips (clamps) value: x minvalue maxvalue clip -> max(min(x, maxvalue), minvalue)
- New: Expr: Parameter "clamp_float"
True: clamps 32 bit float to valid ranges, which is 0..1 for Luma or for RGB color space and -0.5..0.5 for YUV chroma UV channels
Default false, ignored (treated as true) when scale_inputs scales float
- New: Expr: parameter "scale_inputs" (default "none")

Autoscale any input bit depths to 8-16 bit for internal expression use, the conversion method is either full range or limited YUV range.

Feature is similar to the one in masktools2 v2.2.15

The primary reason of this feature is the "easy" usage of formerly written expressions optimized for 8 bits.

Use
- "int" : scales limited range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "intf": scales full range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "float" or "floatf" : only scales 32 bit float format to 8 bit range (or bit depth specified by 'i8'..'i16')
- "all": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses limited_range logic (mul/div by two's power)
- "allf": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses full scale logic (stretch)
- "none": no magic

Usually limited range is for normal YUV videos, full scale is for RGB or known-to-be-fullscale YUV

By default the internal conversion target is 8 bits, so old expressions written for 8 bit videos will probably work.
This internal working bit-depth can be overwritten by the i8, i10, i12, i14, i16 specifiers.

When using autoscale mode, scaleb and scalef keywords are meaningless, because there is nothing to scale.

How it works:
- This option scales all 8-32 bit inputs to a common bit depth value, which bit depth is 8 by default and can be
set to 10, 12, 14 and 16 bits by the 'i10'..'i16' keywords
For example: scale_inputs="all" converts any inputs to 8 bit range. No truncation occurs however (no precision loss),
because even a 16 bit data is converted to 8 bit in floating point precision, using division by 256.0 (2^16/2^8).
So the conversion is _not_ a simple shift-right-8 in the integer domain, which would lose precision.
- Calculates expression (lut, lut_xy, lut_xyz, lut_xyza)
- Scales the result back to the original video bit depth.
Clamping (clipping to valid range) and converting to integer occurs here.

The predefined constants such as 'range_max', etc. will behave according to the internal working bit depth

Warning#1
This feature was created for easy porting earlier 8-bit-video-only lut expressions.
You have to understand how it works internally.

Let's see a 16bit input in "all" and "allf" mode (target is the default 8 bits)

Limited range 16->8 bits conversion has a factor of 1/256.0 (Instead of shift right 8 in integer domain, float-division is used or else it would lose presision)

Full range 16->8 bits conversion has a factor of 255.0/65535

Using bit shifts (really it's division and multiplication by 2^8=256.0):
result = calculate_lut_value(input / 256.0) * 256.0
Full scale 16-8-16 bit mode ('intf', 'allf')
result = calculate_lut_value(input / 65535.0 * 255.0 ) / 255.0 * 65535.0

Use scale_inputs = "all" ("int", "float") for YUV videos with 'limited' range e.g. in 8 bits: Y=16..235, UV=16..240).
Use scale_inputs = "allf" (intf, floatf) for RGB or YUV videos with 'full' range e.g. in 8 bits: channels 0..255.

When input is 32bit float, the 0..1.0 (luma) and -0.5..0.5 (chroma) channel is scaled
to 0..255 (8 bits), 0..1023 (i10 mode), 0..4095 (i12 mode), 0..16383(i14 mode), 0..65535(i16 mode) then back.

Warning#2
One cannot specify different conversion methods for converting before and after the expression.
Neither can you specify different methods for different input clips (e.g. x is full, y is limited is not supported).

masktools2:
- 32 bit float U and V chroma channels are now zero based (+/-0.5 for full scale). Was: 0..1, same as luma
(Following the change in Avisynth+ over r2664: use this plugin with r2996 or newer)
Affected predefined expression constants when plane is U or V:
cmin and cmax (limited range (16-128)/255 and (240-128)/255 instead of 16/255.0 and 240/255.0
range_max: 0.5 instead of 1.0
new: introduce range_min: -0.5 for float U/V chroma, 0 otherwise
range_half (0.0 instead of 0.5)
(range_size remained 1.0)
- New expression syntax for Lut expressions: autoscale any input (x,y,z,a) bit depths to 8-16 bits for internal
expression use. The primary reason of this feature is the "easy" usage of formerly written 8 bit optimized expressions.

New parameters for lut functions:
String "scale_inputs": "all","allf","int","intf","float","floatf","none", default "none"
and
Boolean "clamp_float": default false, but treated as always true (and thus ignored) when scale_inputs involves a float autoscale.
and
Boolean "use_expr": default 0, calls fast JIT-compiled "Expr" in Avisynth+ for mt_lut, lutxy, lutxyz, lutxyza
0: no Expr, use slow internal realtime calc if needed (as before)
1: call Expr for bits>8 or lutxyza
2: call Expr, when masktools would do its slow realtime calc (see 'realtime' column in the table above)

Extends and replaces experimental clamp_xxxx keywords.

[tormento]

real.finder, who is responsible with many old scripts, asked me for these features for a long time.
Can we use this builds with his older scripts or any processed video will turn into a LSD trip? :D

[pinterf]

Can we use this builds with his older scripts or any processed video will turn into a LSD trip? :D
I suppose these versions are backward compatible. But will show no gain until you specify the parameters that enable the features. Again, you have to know what you are doing. And check the results.

[real.finder]

expr scale seems work fine

but I got mt_lutXX does not have a named argument "scale_inputs" in xp I used in VM, same for use_expr

I did check the dll date and it seems very old!

[pinterf]

expr scale seems work fine

but I got mt_lutXX does not have a named argument "scale_inputs" in xp I used in VM, same for use_expr

I did check the dll date and it seems very old!
Weird, all dlls in the 7z package are from yesterday.

[real.finder]

Weird, all dlls in the 7z package are from yesterday.

https://s8.postimg.cc/jbn3o1i9h/Untitled.png

google drive maybe give the 1st test you did not the overwritten new one

[pinterf]

google drive maybe give the 1st test you did not the overwritten new one
Sorry, please check the fixed link again. Seems I have novice file copying problems nowadays.

[tormento]

And check the results.
No mushroom effect yet. :p

[real.finder]

Sorry, please check the fixed link again. Seems I have novice file copying problems nowadays.

thank you it work now, but there are some small problems check here https://forum.doom9.org/showthread.php?p=1844631

[pinterf]

Thanks, real.finder for the report. scale_inputs "float" with input bit depth integer was misinterpreted. r2721 fixes that problem.

AviSynth+ r2721 test build (hopefully one of the last tests):
https://drive.google.com/open?id=1QkyVQ0XK-DP6-HGR8JwN9QyQMK-vHhG6
Matching masktools2 2.2.15 test 5 (not changed since last version)
https://drive.google.com/open?id=1H0OnH_ACwJXb6iT7pO0hVlXCwd2c-afI

[`Orum]

Perhaps a rec601-709 mismatch happening somewhere in the conversion chain? (red cast)
Could be, I'll have to dig through their code when I have more time to investigate.

There is an offset-by-negative-one for each round trip.
That's not a bug, it's a consequence of 8-bit math doing something (round trip) it wasn't designed to do.
Attempting to fix it results in a slightly worse one-way conversion.
Well, as I said my test only proved there was an issue with reciprocal conversion, but I still noticed a greenish tint in a single conversion (e.g. just a single TV->PC conversion). There shouldn't be a tint in either direction (apart from saturation changes, I think) when a conversion is performed one-way.

Edit: I think I can cook up a better example with the Histogram() function that doesn't involve repeated conversions. I'll post back here when I have time (unless that patch has since made it into the release builds).

[pinterf]

And some test builds again.

Fixes 'scalef' and 'scaleb' for U/V chroma parts of 32bit float formats (bith in MaskTools2 lut and Avisynth+ Expr)
Thanks to real.finder for the report.

Not tightly avs+ related but since I put them here together:
Finished a new feature for masktools2, requested by real.finder a long time ago:
New masktools2 parameter: 'cplace' for mt_merge.
Parameter String 'cplace' : "mpeg1" or "mpeg2" (default) chroma placement for 4:2:0 formats when luma=true.

Avisynth+ r2722 (installer w/o VC redistributables)
https://drive.google.com/open?id=1N34BdfebCvfrt4PAQxqg_w0Ur2AxrE_n

Masktools2 2.2.15_test8
https://drive.google.com/open?id=1g-6XFMdVIoU7oln4unLIiOpzctMjKhoB

[magiblot]

I have noticed many filters have been added a bool "dither" parameter in AVS+ (Levels, Tweak, RGBAdjust...).

Wouldn't it be appropiate for ColorYUV to have one as well?

[real.finder]

I have noticed many filters have been added a bool "dither" parameter in AVS+ (Levels, Tweak, RGBAdjust...).

Wouldn't it be appropiate for ColorYUV to have one as well?

it's added in avs26 not avs+

[magiblot]

it's added in avs26 not avs+

Sorry. In that case, pinterf has nothing to do with it.

[pinterf]

New release with plenty of new features and changes.

Download Avisynth+ r2728 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2728)

Most of the changes are already documented on avisynth.nl pages.

Note:
This release will soon be followed by some updated plugins, mostly because of the 32 bit float format internal changes:
masktools2 2.2.17 (https://github.com/pinterf/masktools/releases/tag/2.2.17) updated
FFT3DFilter 2.5 (https://github.com/pinterf/fft3dfilter/releases/tag/v2.5) updated
RgTools 0.97 (https://github.com/pinterf/RgTools/releases/tag/0.97) updated

20180702 r2728
--------------
- New: Expr: implement 'clip' three operand operator like in masktools2
Description: clips (clamps) value: x minvalue maxvalue clip -> max(min(x, maxvalue), minvalue)
- New: Expr: Parameter "clamp_float"
True: clamps 32 bit float to valid ranges, which is 0..1 for Luma or for RGB color space and -0.5..0.5 for YUV chroma UV channels
Default false, ignored (treated as true) when scale_inputs scales float
- New: Expr: parameter "scale_inputs" (default "none")

Autoscale any input bit depths to 8-16 bit for internal expression use, the conversion method is either full range or limited YUV range.

Feature is similar to the one in masktools2 v2.2.15

The primary reason of this feature is the "easy" usage of formerly written expressions optimized for 8 bits.

Use
- "int" : scales limited range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "intf": scales full range videos, only integer formats (8-16bits) to 8 (or bit depth specified by 'i8'..'i16')
- "float" or "floatf" : only scales 32 bit float format to 8 bit range (or bit depth specified by 'i8'..'i16')
- "all": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses limited_range logic (mul/div by two's power)
- "allf": scales videos to 8 (or bit depth specified by 'i8'..'i16') - conversion uses full scale logic (stretch)
- "none": no magic

Usually limited range is for normal YUV videos, full scale is for RGB or known-to-be-fullscale YUV

By default the internal conversion target is 8 bits, so old expressions written for 8 bit videos will probably work.
This internal working bit-depth can be overwritten by the i8, i10, i12, i14, i16 specifiers.

When using autoscale mode, scaleb and scalef keywords are meaningless, because there is nothing to scale.

How it works:
- This option scales all 8-32 bit inputs to a common bit depth value, which bit depth is 8 by default and can be
set to 10, 12, 14 and 16 bits by the 'i10'..'i16' keywords
For example: scale_inputs="all" converts any inputs to 8 bit range. No truncation occurs however (no precision loss),
because even a 16 bit data is converted to 8 bit in floating point precision, using division by 256.0 (2^16/2^8).
So the conversion is _not_ a simple shift-right-8 in the integer domain, which would lose precision.
- Calculates expression (lut, lut_xy, lut_xyz, lut_xyza)
- Scales the result back to the original video bit depth.
Clamping (clipping to valid range) and converting to integer occurs here.

The predefined constants such as 'range_max', etc. will behave according to the internal working bit depth

Warning#1
This feature was created for easy porting earlier 8-bit-video-only lut expressions.
You have to understand how it works internally.

Let's see a 16bit input in "all" and "allf" mode (target is the default 8 bits)

Limited range 16->8 bits conversion has a factor of 1/256.0 (Instead of shift right 8 in integer domain, float-division is used or else it would lose presision)

Full range 16->8 bits conversion has a factor of 255.0/65535

Using bit shifts (really it's division and multiplication by 2^8=256.0):
result = calculate_lut_value(input / 256.0) * 256.0
Full scale 16-8-16 bit mode ('intf', 'allf')
result = calculate_lut_value(input / 65535.0 * 255.0 ) / 255.0 * 65535.0

Use scale_inputs = "all" ("int", "float") for YUV videos with 'limited' range e.g. in 8 bits: Y=16..235, UV=16..240).
Use scale_inputs = "allf" (intf, floatf) for RGB or YUV videos with 'full' range e.g. in 8 bits: channels 0..255.

When input is 32bit float, the 0..1.0 (luma) and -0.5..0.5 (chroma) channel is scaled
to 0..255 (8 bits), 0..1023 (i10 mode), 0..4095 (i12 mode), 0..16383(i14 mode), 0..65535(i16 mode) then back.

Warning#2
One cannot specify different conversion methods for converting before and after the expression.
Neither can you specify different methods for different input clips (e.g. x is full, y is limited is not supported).

- Fix: Expr: expression string order for planar RGB is properly r-g-b like in original VapourSynth version, instead of counter-intuitive g-b-r.
- Fix: Expr: check subsampling when a different output pixel format is given
- Fix: ColorYUV: round to avoid green cast on consecutive TV<>PC
- Enhanced: Limiter to work with 32 bit float clips
- Enhanced: Limiter new parameter bool 'autoscale' default false.
If set, minimum/maximum luma/chroma values are treated as they were in 8 bit range (but non-integer values are allowed), limiter will autoscale it.
Default: does not scale at all, parameters are used as-is. Parameters now are of float type to handle 32 bit float values.
- New: function bool VarExist(String variable_name)
Checks if a variable exists
Returns true if variable exists even if it holds 'Undefined', false otherwise
- Fix: RGBAdjust memory leak when used in ScriptClip
- Enhanced: RGBAdjust new parameter: conditional (like in ColorYUV)
The global variables "rgbadjust_xxx" with xxx = r, g, b, a, rb, gb, bb, ab, rg, gg, bg, ag are read each frame, and applied.
It is possible to modify these variables using FrameEvaluate or ConditionalReader.
- Enhanced: RGBAdjust: support 32 bit float ('analyze' not supported, 'dither' silently ignored)
- Enhanced: AviSource to support more formats with 10+ bit depth.
http://avisynth.nl/index.php/AviSource

When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

Full support list (* = already supported):
'pixel_type' Avs+ Format FourCC(s) for ICDecompressQuery
YV24 YV24 *YV24
YV16 YV16 *YV16
YV12 YV12 *YV12
YV411 YV411 *Y41B
YUY2 YUY2 *YUY2
RGBP10 RGBP10 G3[0][10] r210 R10k
r210 RGBP10 r210
R10k RGBP10 R10k
RGBP RGBP10 G3[0][10] r210 R10k
RGBP12 G3[0][12]
RGBP14 G3[0][14]
RGBP16 G3[0][16]
RGBAP10 G4[0][10]
RGBAP12 G4[0][12]
RGBAP14 G4[0][14]
RGBAP16 G4[0][16]
RGB32 RGB32 *BI_RGB internal constant (0) with bitcount=32
RGB24 RGB24 *BI_RGB internal constant (0) with bitcount=24
RGB48 RGB48 BGR[48] b48r
RGB64 RGB64 *BRA[64] b64a
Y8 Y8 Y800 Y8[32][32] GREY
Y Y8 Y800 Y8[32][32] GREY
Y10 Y1[0][10]
Y12 Y1[0][12]
Y14 Y1[0][14]
Y16 Y1[0][16]
YUV422P10 YUV422P10 v210 P210
v210 YUV422P10 v210
P210 YUV422P10 P210
YUV422P16 YUV422P16 P216
P216 YUV422P16 P216
YUV420P10 YUV420P10 P010
P010 YUV422P10 P010
YUV420P16 YUV420P16 P016
P016 YUV422P16 P016
YUV444P10 YUV444P10 v410
v410 YUV444P10 v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels.
U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
Note: filters that relied on having the U and V channel center as 0.5 will fail.
Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
Check function availablity with FunctionExists("IsFloatUvZeroBased").
When the function does not exists, the center value of 32 bit float U and V channel is 0.5
When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
E.g. after a 8->32 bit fulls=false fulld=true:
Y: 16..235 -> 0..1
U/V: 16..240 -> -0.5..+0.5
Note: now ConvertBits does not assume full range for YUV 32 bit float.
Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
- Update from interface V6 to V20, and Filtermod version 6 (partial)
- VirtualDub2 support with extended colorspaces
Allow RGB24, RGB48, RGB64 besides RGB32
AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
- Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
- Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
- Supports when filter changes frame count of the output clip
- Extra filter parameter added at the end of filter's (unnamed) parameter list
Imported Virtualdub filters are getting and extra named parameter to the end:
String [rangehint]
This parameter can tell the filter about a YUV-type clip colorspace info
Allowed values:
"rec601": limited range + 601
"rec709": limited range + 709
"PC.601": full range + 601
"PC.709": full range + 709
"" : not defined (same as not given)
Parameter will be ignored when clip is non-YUV
How it works: the hint will _not_ change the internal VirtualDub colorspace
constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
Filter can either use this information or not, depending on supported API version and its implementation.
E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a
template clip, from which the undefined format elements are inherited.
"[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

string family: YUV, YUVA, RGB, RGBA, Y
int bits: 8, 10, 12, 14, 16, 32
string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

Example#1: define YUV 444 P 10

family = "YUV"
bits = 10
chroma = 444
compat = false
oldformat = false
s = BuildPixelType(family, bits, chroma, compat, oldformat)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

Example#2: Change only the bit depth of the format to 16

newbits = 16
c = last
s = BuildPixelType(bits=newbits, sample_clip=c)
BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Include current avisynth header files and def/exp file in installer, when SDK is chosen

[Groucho2004]

New release with plenty of new features and changes.:thanks:

[LigH]

I already wonder if complex scripts like QTGMC can take advantage of these changes (or even need adaptions to the new plugins?)...

[jpsdr]

:thanks:

[real.finder]

I already wonder if complex scripts like QTGMC can take advantage of these changes (or even need adaptions to the new plugins?)...

it will get more speed if it use expr especially with HBD, I need some times to update QTGMC and others

[Sparktank]

Not just AVS+, but other plugins as well.

Thanks a lot for these :)

[StainlessS]

EDIT: RUBBISH POST, PLEASE IGNORE.
Seems that I generated this bit with Grunt installed, thought is was from AVS+
I investigated it with Grunt not installed, however it had already been generated some time previous.
The scan examined builtin names, but got parameters from the Grunt plugin because of same Scriptclip name, oops.

ScriptClip "cs[showx]b[after_frame]b[args]s[local]b"



I'm trying to figure out how to adapt to using AVS standard with Grunt, or AVS+ without (concerning ScriptClip).

From http://avisynth.nl/index.php/GRunT
GRunT provides extended versions of the following run-time filters:
ScriptClip, ...

ScriptClip (clip clip, string filter [, bool showx, bool after_frame, string args, bool local])
GScriptClip(clip clip, string filter [, bool show , bool after_frame, string args, bool local])

As in the AviSynth internal counterparts, show (or showx) to true will display the actual values on the screen.


Presume that show/showx can be used to force original Scriptclip or GRunt version of ScriptClip when Grunt extended args NOT used.

AVS+, I See this Auto Generated using RT_InternalFunctions from Avisynth r2728 [EDIT: Via RT_Stats Make_Avisynth_BuiltIn_FunctionList.avs]

ScriptClip "cs[showx]b[after_frame]b[args]s[local]b"


There are probably multiple function definitions in AVS+ source, but there is only a single one available via InternalFunctions().


Colorbars(Pixel_Type="YV12").ShowFrameNumber
SSS="""
x=averageluma
Subtitle("Fred Exist="+String(VarExist("fred"))+String(x," : X=%f"),Size=24,align=5)
"""
fred=true
# UnComment below lines one at a time
#####################################
##### AVS+ With GRunt Installed #####
#ScriptClip(SSS,show=true) # OK, builtin
#ScriptClip(SSS,showx=true) # OK, Grunt
#ScriptClip(SSS,args="fred") # OK, Grunt
#ScriptClip(SSS,local=true) # OK, Grunt
#
#GScriptClip(SSS,show=true) # OK
#GScriptClip(SSS,showx=true) # Script Error. GScriptclip does not have a named argument 'showx'. EDIT: So OK, expected
#GScriptClip(SSS,args="fred") # OK
#GScriptClip(SSS,local=true) # OK
#####################################
##### AVS+ With GRunt Missing #####
#ScriptClip(SSS,show=true) # OK
#ScriptClip(SSS,showx=true) # Script Error. Scriptclip does not have a named argument 'showx'.
#ScriptClip(SSS,args="fred") # Script Error. Scriptclip does not have a named argument 'args'.
#ScriptClip(SSS,local=true) # Script Error. Scriptclip does not have a named argument 'local'.
#
#GScriptClip(SSS,show=true) # All GScripClip fail with missing Grunt dll, as not supported in Avs+
#GScriptClip(SSS,showx=true) #
#GScriptClip(SSS,args="fred") #
#GScriptClip(SSS,local=true) #
#####################################


Is AVS+ ScriptClip with showx, args and local documented somewhere ? [EDIT: the func definition 2 code blocks up suggests it exists]

GScript dll:- http://avisynth.nl/index.php/GScript
GSCript in Avs+: http://avisynth.nl/index.php/AviSynth%2B#GScript

In AviSynth+ there is no need to wrap your GScript code in a string. The language extensions are native to
AviSynth+ and can be used transparently.

Might best be rewritten in docs as
In AviSynth+ you must not wrap your GScript code in a GScript(" ... ") ...

Also, should be doc'ed that as well as GScript(), GEval(), and GImport() are not supported.

EDIT: I'm using below to implement script in both AVS with GSCript and AVS+ without [needs RT_FunctionExist()]
Where InstS = a multiline string.

IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("GScript")
Assert(IsAvsPlus || HasGScript,RT_String("%sNeed either GScript or AVS+",myName))
...
HasGScript ? GScript(InstS) : Eval(InstS) # Use GSCript if installed (loaded plugs override builtin)


EDIT:
Maybe GScript, GEval, and GImport, could be implemented as script functions (with some other names) and act based on
whether GScript dll or AVS+ present, GImport equivalent though might be tricky as I think the ScriptDir() type stuff changes
to the target directory of the imported file, probably not impossible to kludge around.

EDIT: If anybody wants complete listing of AVS+ r2728 BuiltIn function definitions, see SendSpace in sig below this post, or here:
http://www.mediafire.com/file/py89853bys1y3j1/AviSynth+_0.1_%28r2728_ORDERED_Function_List.TXT.7z [~5KB]
NOTE, Only a single definition for each function is available, eg AssumeFPS has multiple definitions, using float FPS, or int numerator, int denominator.
(Not sure if its the first or last definition that is produced by Avs API.)
The actual script to produce the list is included in RT_Stats (any recentish version, last 3 or 4 years).

[FranceBB]

I've been using Avisynth since 2006 and I've got many plugins in my Avisynth plugin directory.
Unfortunately, the development of Avisynth didin't really make any step forward for a while and even thought I have been able to use some sort of "workaround" to accomplish my tasks, time has come for me to move to Avisynth+.
I downloaded AviSynthPlus-MT-r2728-with-vc_redist.exe from Github (the latest Pinterf release).
I generally compile binaries myself, but I never used Avisynth+ so I wanted to download the official binaries.
I started the installation and it asked me whether I wanted to replace Avisynth or just "upgrade" and I clicked "upgrade".
It installed itself and also the C++ Redistributable 2017.

Unfortunately, I removed my old Avisynth plugin directory 'cause some of my old plugins make Avisynth+ crash.

So, I started adding them one by one until I found out which ones were breaking Avisynth+ and now it works.

I was kinda skeptical at the very beginning, but I tested it with a few simple scripts and I got very excited!
I mean, overall I find it faster than Avisynth 2.6.1 as it reacted immediately when I tried to preview results with AVSPmod and the syntax is basically identical, so I don't have to learn things from scratch, but just new functions! :D
I started to play with colorbars and test sources...
ConvertBit() is really useful, but what I found most exciting is that many internal filters are already capable to work at 10, 12, 14, 16bit and they are blazing fast!
I mean, I can simply use ConvertBit(10) and then use... I don't know... Tweak and Spline64Resize? Really? I don't have to Dither it up to 16bit stacked, use Dither functions and Dither it down to 10bit with Dither_Quantize, but I can work directly at 10bit if I want to? I know it sounds silly and easy to you, but it sounds really cool to me.
Besides, if I use FFMpegSource2 it will index the source and output it in its native Bitdepth... this is amazing!! It really is amazing, 'cause last time I had to compile ffms2 myself to include "enable10bithack=true".
I mean, again, it may sound silly to you but it sounds cool to me.
Avisynth+ also solved some nasty bug I have been dealing with for years...! Yes, for years...! Including some I reported but never got fixed in Avisynth 2.6.1... this is amazing!

I'm far too excited...
A big fat "thank you" to pinterf and to everybody who committed changes to the developing branch.

[Groucho2004]

Unfortunately, I removed my old Avisynth plugin directory 'cause some of my old plugins make Avisynth+ crash.

So, I started adding them one by one until I found out which ones were breaking Avisynth+ and now it works.
Any chance you could tell us which plugins "break" AVS+?

[manolito]

Alright, this seems to be the time when everybody is abandoning plain vanilla AviSynth, I probably also should take a closer look at AVS+, but I am still very reluctant to make this step.

My needs are probably a little different than the needs of many other folks, especially the folks on this forum, so I'd like to ask a few questions about the advantages I would get in my usual projects by switching to AVS+.

I do not care at all about high bit depths and hi color. Most of my projects are SD, either for DVD or for AVC/AAC output (only rarely in HD resolution). The most demanding conversions I sometimes do for other folks are BD structures or AVCHD files which play on a standard hardware BD player. And all these formats are 8-bit with 4:2:0 color subsampling.

So I believe that most of the newer AVS+ features are not needed for me. I also need ALL of my old AVS plugins to continue working, this includes some VDub filters. Is this a realistic expectation?

Next question is about multithreading. Is there any speed gain in AVS+ when using old single threaded plugins and just add the "prefetch" command to the end of my scripts?

And then the question about AVS+ stability. I am very conservative here, I have not much use for software which gets bug fix updates every couple of weeks. I prefer software which is stable and has an update frequency of no less than one year. From loosely following the related threads I got the impression that AVS+ as well as some important "modernized" plugins (like MaskTools and MVTools) are still work in progress and need frequent bug fix updates.


So after considering all these aspects I wonder if I should really switch to AVS+ yet. It may be inevitable at a later time, but it seems too early right now, at least for my needs...


Cheers
manolito

[FranceBB]

Any chance you could tell us which plugins "break" AVS+?

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.

[Groucho2004]

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.I see. When someone mentions 'break' or 'crash' I wouldn't assume that it's related to a feature simply not supported.

Anyway, I'm glad you like AVS+, I also find the ConvertBits() and ConvertToStacked() functions very useful.

[StainlessS]

Manolito,
FranceBB seems quite happy, (not surprisingly).
Any problems are quite rare and fixed almost immediately (no 6 month wait till next update), Pinterf dont hang about.
Avs+ is I think definitely faster than standard, and seems to swallow less amounts of memory, although neither of those
qualities have been benchmarked by me in any way, everything just feels better. (I'm still on XP32, mostly).
Its easy enough to switch versions, Groucho even does a fast switcher, I got it but have yet to try (easy enough to just switch without it).
The only irksome difference to v2.60/2.61, is the GScript thing, but that is easily overcome just by installing GScript dll and ignoring the Avs+ built in
Gscript parsing (loaded plugs override builtin). [GScript Thing, Avs+ dont like the surrounding GScript(""" ... """) stuff.]

However, you can avoid such difficulties using code in last code block in post #4144
(a few posts previous, requires RT_Stats though, not something that I have a problem with).

Give it a try, easy enough to switch back, but I'm guessin' that you will not be doing that, ever.

EDIT: Any problems/bugs that rarely occur are usually in new functionality, if you dont use it, you will not have to be a guinea pig.
EDIT: And if you is still on the ol' Vdub, then switch that too to VD2, another recentish 'fantabulism'.
EDIT: 'GSCript thing', I think (but am not sure) that you should be able to mix GScript(""" ... """) and unwrapped gscript code
even in same script when you have the Gscript dll installed. I'm currently modding all of my script to work with either GSCript or
avs+ without Gscript.

[Gser]

Thiss is amazing!
I'm far too excited...
A big fat "thank you" to pinterf and to everybody who committed changes to the developing branch.

See I told you avs+ was nice ;)

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.

Yeah that's the only plugin I haven't found an x64 version for, but it runs perfectly with MP Pipeline.

Perhaps the most beneficial thing for me about converting to avs+ and x64 was how rock solid QTGMC runs on HD content.

[qyot27]

I do not care at all about high bit depths and hi color.
AviSynth+ was already three years old by the time high bit depth was added. Many of the differences you'd be likely to see a benefit from are actually the older ones that happened right after the fork occurred in 2013. Stuff like improved caching behavior, lower memory usage, autoloading of C plugins, 64-bit support, many filters getting faster because the old SoftWire assembly was removed and replaced by intrinsics that work much better on modern compilers (it also means that support for newer instruction sets like AVX, AVX2, and AVX512 were added much more easily as well), and so on.

I also need ALL of my old AVS plugins to continue working, this includes some VDub filters. Is this a realistic expectation?
2.0 plugins won't work, but 2.5 and 2.6 plugins are fine (with the same 'you do need to update this one' issues that classic AviSynth 2.6 is affected by as well). VDub filters should be okay, as VirtualDubFilter still exists - although it's an external plugin now. I can't personally speak to that part, since I don't use any VDub filters myself, or if I ever did, it was only one or two.

Next question is about multithreading. Is there any speed gain in AVS+ when using old single threaded plugins and just add the "prefetch" command to the end of my scripts?
It depends. It's much more dependent on how the script is written and which MT mode the plugins are marked as (you can either use SetFilterMTMode to set the mode yourself, or use MTmodes.avsi to automatically use the community consensus on the proper modes for the most widely used plugins). If all the plugins you want to use happen to be good with the MT_NICE_FILTER setting, then yes, there should be a boost.

Basically, the order of the filters matters more in MT, because the MT_SERIALIZED mode can basically negate all benefits of MT if such a filter is used late in a script. Anything that uses that mode should occur at the beginning of the script, and then I'm not sure about whether it matters where filters using MT_MULTI_INSTANCE are.

In comparison to the old MT forks (where the only thing to set was a script-wide MT mode and maybe a Distributor call), AviSynth+'s approach is a scalpel, not a hammer. The cost of that is that the process to set things correctly is a tad more complicated, but MTmodes.avsi can take care of the bulk of that for you.

And then the question about AVS+ stability. I am very conservative here, I have not much use for software which gets bug fix updates every couple of weeks. I prefer software which is stable and has an update frequency of no less than one year. From loosely following the related threads I got the impression that AVS+ as well as some important "modernized" plugins (like MaskTools and MVTools) are still work in progress and need frequent bug fix updates.
That's mostly just a different release pattern due to it being more actively maintained and going with a more x264-like setup where people mostly refer to the revision numbers. More frequent builds get released, sure, but if a particular build works for you, it's usually safe to keep using on it if you've not hit any bugs. And if you do find a bug, see if it still exists in the latest build - if it doesn't, great, if it does, report it.

There actually was going to be a '0.2' stable release somewhere around the r1830 point, but that never came to be. By now we'd probably be at a 0.3 or 0.4. Considering that, 0.1 was released in December 2013, r1825 (close to where 0.2 would have been) was early-mid 2016 and had MT but not high bit depth, and so by my estimation, 0.3 would likely have been September 2016, roughly around the time high bit depth support had gotten all of the major kinks hammered out and external support for them in FFmpeg and x264 showed up. We'd currently be inside the development cycle for 0.4, but the stuff lately hasn't been quite so dramatic, so the cycle for 0.4 could be longer (it might be when GCC and cross-platform support fully congeal, I dunno).

Stability is something of a different question. Despite new features showing up or getting improved actively (most recently it was the Expr stuff), existing features don't just disappear or change, save for users submitting bug reports and it being addressed much more quickly. From a developer point of view, the API has remained stable for years, because it has to be backward compatible with 2.6 and programs that still use 2.6.

[Groucho2004]

Nice write-up qyot27, it should make the decision to upgrade (or not) to AVS+ easier for some folks.

:goodpost:

[rco133]

Hi.

I have a question about using AVS+ multithreaded or not.

Maybe there is a simple explanation to the behaviour I see.

The source is 1920x1080 bluray with progressive video. This Means that the AVS file is quite simple.

LoadPlugin("d:\dgdecnv\x64 Binaries\DGDecodeNV.dll")
DGSource("test.dgi")
crop(0,140,1920,800)
Spline36Resize(1280,536)

Thats it.

I have been doing some tests with AVSMeter 281, and am a bit surprised by the results. The 1080 results have a bit different crop in the AVS file, and the resize command is of course gone.

All the tests have been running for 1 minute and then stopped.

-----

720p with no Prefetch.

Frames processed: 17080 (0 - 17079)
FPS (min | max | average): 76.40 | 369.2 | 282.8
Memory usage (phys | virt): 213 | 369 MiB
Thread count: 27
CPU usage (average): 6%

Time (elapsed): 00:01:00.394

-----

1080p with no Prefetch.

Frames processed: 16940 (0 - 16939)
FPS (min | max | average): 101.1 | 374.6 | 280.2
Memory usage (phys | virt): 210 | 366 MiB
Thread count: 27
CPU usage (average): 4%

Time (elapsed): 00:01:00.465

-----

720p with pefetch(4).

Frames processed: 15550 (0 - 15549)
FPS (min | max | average): 22.65 | 544.3 | 255.7
Memory usage (phys | virt): 241 | 397 MiB
Thread count: 31
CPU usage (average): 12%

Time (elapsed): 00:01:00.812

-----

1080p with prefetch(4).

Frames processed: 13550 (0 - 13549)
FPS (min | max | average): 22.81 | 412.2 | 222.8
Memory usage (phys | virt): 258 | 414 MiB
Thread count: 31
CPU usage (average): 6%

Time (elapsed): 00:01:00.816

-----

I have also done tests with

SetFilterMTMode("DGSource", 3)
DGSource("test.dgi")
SetFilterMTMode("DEFAULT_MT_MODE", 2)

in the AVS file. But it doesn't really make any difference.

What makes me wonder is the big difference in CPU useage, and also the minimum FPS which drops very low.
The resulting average is quite a bit lower as soon as I use Prefetch in the script.

Is it normal for very simple AVS files like this, that enabling MT actually hurts the performance?

For now I am of course just not using Prefetch in AVS files like this, but it made me wonder.

I have some avsi and DLL files located in the plugins64+ folder, but that shouldn't really matter or?

Thanks in advance.

rco133

[LigH]

If multithreading doesn't matter, then you have a single threaded bottleneck filter. And it's probably DGSource, because you can't multithread hardware decoding. The one decoder chip on your graphics card is as fast as it is.

And who cries about an average of >200 fps? Multithreading is the more useful the slower the video is filtered, in relation to the decoding speed. Cropping and scaling, that's quite "nothing" compared to e.g. deinterlacing and denoising.

[manolito]

Give it a try, easy enough to switch back, but I'm guessin' that you will not be doing that, ever.


Thanks for this, but I will probably hang in there with the old standard AVS for another simple reason:
I have several computers running in parallel, the main desktop machine is the old P3 Coppermine under XP SP3, and this one does not support SSE2. AVS+ does support XP, but it chokes on a CPU without SSE2 (just like all the "modernized" plugins).

Yes, I know your answer, but I am still not ready to throw this old computer away, I believe in sustainability, and I won't throw away things which still work. My newer laptops would not have any problems running AVS+, but I have no intention to maintain different AviSynth installations on my several machines.

A big thanks to qyot27 for his detailed explanation. It really makes the decision for upgrading to AVS+ or not a lot easier.


Cheers
manolito

[magiblot]

That was a great explanation, qyot27. I believe a similar summarised and easy to understand text should be added to the AviSynth Wiki, in addition to other changes to make AviSynth+ the new recommended build.

When newcomers to AviSynth enter the Wiki, the first link they see is the one under 'Official builds'. Also, searching Google for 'avisynth download' leads to downloads of the 2.6 branch in SourgeForge and VideoHelp as well.

[jpsdr]

TAVS+ does support XP, but it chokes on a CPU without SSE2 (just like all the "modernized" plugins).

A lot of devs, included me, dropped things before SSE2. Begining with SSE2 already give enough differents code branch (roughly SSE2, SSE41, AVX, AVX2). Don't want to add at least two more (MMX, SSE). Even in my own old plugins, which had at the beginig only MMX, then after SSE, after SSE2, after... I deleted some old specific code path to reduce them, otherwise, you'll finish your plugin with a dozen of specific optimised code path !:scared:

[Atak_Snajpera]

A lot of devs, included me, dropped things before SSE2. Begining with SSE2 already give enough differents code branch (roughly SSE2, SSE41, AVX, AVX2). Don't want to add at least two more (MMX, SSE). Even in my own old plugins, which had at the beginig only MMX, then after SSE, after SSE2, after... I deleted some old specific code path to reduce them, otherwise, you'll finish your plugin with a dozen of specific optimised code path !:scared:

These days you just need two versions (SSE2 and AVX2). Rest can be omitted.

[qyot27]

It's not even that. AviSynth+ dropped the MMX and some of the SSE paths with the removal of SoftWire, but re-implemented some of them that were more obvious and useful with intrinsics (meaning: on a pre-SSE2 machine, some filters may be a mixed bag of whether they're faster than AviSynth 2.6; some of the other caching and memory improvements may make up some of the lost ground, though). But that's not actually what spurred the current build restrictions. Look at CMakeLists.txt. (https://github.com/pinterf/AviSynthPlus/blob/MT/CMakeLists.txt#L74) All anyone building it needs to do to 're-enable'* pre-SSE2 support is swap the commented out ARCH line for the other one. One of these days I'll figure out how to pass a selectable ARCH option to CMake so that optimizing for any of MSVC's supported levels (or disabling it completely) can be done at configure time instead of having to edit CMakeLists.txt before building it. The issue is that to build it with MSVC 2015 or 2017, you need at least Windows 7 (I think? maybe Win8.1) and an SSE2 CPU - MSVC itself doesn't run on older machines or versions of Windows, although it can still build for them.

*Because it's not really disabled, it's just a compiler optimization switch. You could even turn it completely off by passing ARCH:IA32.

[qyot27]

Here's a build that supports Pentium III. (http://www.mediafire.com/file/vtd3wzl5ynk422u/avisynth__r2741-g0cb91abf-20180803.7z/file) The revision number is higher because it came from some work I'd done to make it compile a little bit more easily/cleanly with MinGW, so nothing markedly different from the latest build from pinterf (especially since I built it with MSVC 2017).

[manolito]

Thanks so much, this is so nice of you... :thanks:

Gives me something to play with for the next couple of days. Of course I need to stick with my old MaskTools and MVTools, and this means that I also keep my older QTGMC, LSFMod and SRestore scripts because the "modernized" scripts depend on the latest PinterF versions. I am curious if I will still get some speed gains.

Two questions:
1. I know that AVS+ can autoload C-Plugins. Do I have to make any changes in my autoload folder? Right now I autoload my C-Plugins with the help of an AVSI script which loads the C-Plugins.

2. Of cource my P3 Coppermine is single threaded. Would it still make any sense to add the "Prefetch" command to the end of my AVS scripts?


Thanks again
manolito

[Groucho2004]

Two questions:
1. I know that AVS+ can autoload C-Plugins. Do I have to make any changes in my autoload folder? Right now I autoload my C-Plugins with the help of an AVSI script which loads the C-Plugins.

2. Of cource my P3 Coppermine is single threaded. Would it still make any sense to add the "Prefetch" command to the end of my AVS scripts?
1. You simply remove that .avsi from the auto-load directory.

2. No. It would even reduce performance.

[manolito]

:thanks:

[StainlessS]

Qyot27, Top man, your efforts are always much appreciated, alas, my PIII's now all long dead.

1), I like to load C plugins via avsi (from separate sub directory of 'Plugins') as I just dont like them in my plugs (maybe in case I revert to Std
for some temp reason). [I usually enable on demand just by uncommenting a line in avsi].
{just an option to consider, at least keep a copy of original avsi in a SCRIPT sub directory of your Plugins archive}

[Groucho2004]

I like to load C plugins via avsi (from separate sub directory of 'Plugins') as I just dont like them in my plugs (maybe in case I revert to Std
for some temp reason). [I usually enable on demand just by uncommenting a line in avsi].Same here, more or less. I only have the plugins I use frequently in the autoload directory (mvtools, masktools, rgtools, f3kdb ...) and load others as needed from another location.

Of course there are people who take auto-loading to a new level:
https://forum.doom9.org/showthread.php?p=1844394#post1844394 :eek:

[manolito]

Just gave qyot27's Non-SSE2 version from this post
https://forum.doom9.org/showthread.php?p=1847975#post1847975
a whirl on my ancient computer, and I am impressed...

To avoid any installation mistakes I installed the latest pinterf version first, then replaced the files with the ones from the qyot27 build. During installation I opted for uninstalling the old AVS version and migrate the old plugins.

Worked on the first attempt. AVStoDVD issued a non-fatal warning about a wrong AviSynth version on startup, but that was it. All my standard scripts worked out of the box. I have 76 plugins in my autoload folder, and so far none of them caused a crash.

BTW is there an easy method to identify ancient 2.0 C-plugins?

Only my old and beloved DVDtoSVCD absolutely refused to work under AVS+. It needs AVS 2.57 anyways, I have to use Groucho's AVS switcher to make it work.

Next I did a few speed comparisons. The specs of this ancient machine are:
Celeron P3 Coppermine @ 1.1 GHz Non-SSE2 Single Core
576 MB system RAM
Win XP SP3 32-bit

The unmodified scripts ran a tiny bit slower than under AVS 2.61 Alpha (42 fps vs. 46 fps). Just for fun I then added Prefetch commands to the end of my scripts, and to my big surprise this was very stable and did not compromise speed. Even using "Prefetch(8)" caused no problems. And remember this is under a single core CPU with very low system RAM. Quite impressive...


So again a big thanks to qyot27 for this build. Even if it has no advantages on my old machine it will definitely make it much easier for me to maintain my AviSynth installations on my various computers because I will only have to deal with one identical installation for all of them.


Cheers
manolito

[Groucho2004]

BTW is there an easy method to identify ancient 2.0 C-plugins?

"AVSMeter avsinfo"

If you want to specify a custom plugin directory:
"AVSMeter avsinfo -c"

[StainlessS]

BTW is there an easy method to identify ancient 2.0 C-plugins?
Just AvsMeter as far as I'm aware.

Although you might be able to chop something out of this (dont know how it fares under AVs+, no idea what 'not supported' means in that case).
https://forum.doom9.org/showthread.php?p=1641795#post1641795

C v2.0 plugs I got (maybe not all of them)


avisynth_c.dll # The loader, not C v2.0

AVSCurveFlow.dll
AVSShock.dll
equlines.dll
IBob.dll
SmartDecimate.dll
Transition.dll


EDIT: Damn that Groucho, he's just too fast.

[qyot27]

Good to know that it worked; when I tried moving it over to my P3 machine to test it myself, I ran into redist problems (and couldn't resolve them because the Windows Installer service on that install is screwed up something fierce), so I was flying blind a little bit.

I did, however, whip up a patch to let the SIMD level be selected during configuration (https://github.com/qyot27/AviSynthPlus/commit/422043aef7a59c6f8554295a25ed1317cc5601af). It seemed to work, since when I told it to optimize for AVX, the .dll would no longer run on this (Apollo Lake-based (https://en.wikipedia.org/wiki/Goldmont), only has up to SSE 4.2) computer.

[manolito]

Now I am just curious how big the speed sacrifice using this non-SSE2 version vs. the standard version is. I still assume that the various filter plugins will be the bottleneck and not AviSynth itself...


Cheers
manolito

[jpsdr]

It's not impossible you may encoder speed loss with internal core avs filters. The old version you were using had internal asm MMX optimized code. The new avs+, everything has moved to intrinsics, but i think they need at least SSE2. So, it's possible that now you have only pure code C path, instead of MMX optimized code. But i don't know exactly what qyot27 has done, so it's up to him to confirm or not what i've said.

[pinterf]

In a non-SSE2 build MMX code is still there since it was also moved from the classic Avisynth or got rewritten to intrinsics.
New stuff (mostly for high bit-depth) was implemented in C-only at the beginnings and the SSE2 option gave quite a good optimization for these parts. Since then most of the things have hand-written SSE2/SSE4 optimization, some have AVX2.
I haven't stopped or removed the C implementation, all filters and function have the C version.

[jpsdr]

In a non-SSE2 build MMX code is still there since it was also moved from the classic Avisynth or got rewritten to intrinsics.

Ah, i was wrong on this part, my mistake.

[qyot27]

All the MSVC optimization flags (/arch:SSE2 vs. /arch:SSE or /arch:IA32) do is optimize the C portions to emit SIMD instructions in the compiled binary, it's not necessary to match it with the intrinsics; the intrinsics will compile to the proper SIMD-enhanced versions with or without /arch set. GCC largely works the same way with its -march/-mtune/-mCPU flags (except that GCC's handling of branched intrinsics is a complete rat's nest).

[wonkey_monkey]

I'm on r2506 and always scared of installing a new version. I've noticed that showy, showu, and showv all cause exceptions. Just thought I'd mention it in case it's still a bug. Extracty/u/v all work fine.

[StainlessS]

and showv all cause exceptions

Confirmed in r2728.
EDIT: Dont be a scaredy-cat David, recent versions of avs+ have had some nice speed improvements and I'm sure that r2728
crashes way faster than the old r2506 that you are using. :)

[mkver]

Only ancient 2.0 C plugins like InpaintFunc, a delogo I've been using for years, but there are alternatives, so I don't mind.
What exactly do you mean by "make Avisynth+ crash"? Is it the mere presence of a plugin's dll in the plugin's folder enough to make it crash? (InpaintFunc is btw. a script, not a plugin; it uses AVSInpaint internally.) This is something that I couldn't reproduce, neither with the first version of AVSInpaint (that still relied on AviSynth_C.dll) nor with the second version that is a proper 2.5 C plugin.

But I know that AVSInpaint is indeed a bit buggy. I have already asked pinterf about the different behaviour of AVSInpaint on AVS+ and AVS 2.6 (after all, it might have been a bug in AVS+) and it turned out to be a bug in AVSInpaint (as expected):

if (AlphaFrame) avs_release_video_frame(LogoFrame);
if (LogoFrame) avs_release_video_frame(LogoFrame);

The above double part of AVSInpaint.c is contained in the code path for deblending of a static logo. Inpaintfunc makes use of exactly this part of AVSInpaint.c when deblending, therefore it crashes. Thanks again to pinterf for finding this bug.

I managed to compile both x86 and x64 versions of AVSInpaint; I actually did this already in May, but back then I created the necessary x64 AviSynth.lib by using avisynth.def from github and dlltool (part of MinGW64) and "dlltool -l avisynth.lib -d avisynth.def /c/Windows/System32/AviSynth.dll" from the 2664 AVS+ dll and although the resulting plugin worked, I wanted to wait for an officially released lib file (pinterf mentioned that he would add (as he has now) them to his releases) and of course I forgot about them, but your post reminded me of this. Here (https://www.dropbox.com/s/9r3bfkqp9aimidk/AVSInpaint.rar?dl=0) are the builds. Could you confirm that you don't get any more crashes with them and that they work as intended?

I also think to have found a bug in AVS+. capi.h (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/include/avs/capi.h#L49) contains these lines:


#ifdef MSVC
#ifndef AVSC_USE_STDCALL
# define AVSC_CC __cdecl
#else
# define AVSC_CC __stdcall
#endif
#else
# define AVSC_CC
#endif

#define AVSC_INLINE static __inline

#ifdef BUILDING_AVSCORE
# define AVSC_EXPORT __declspec(dllexport)
# define AVSC_API(ret, name) EXTERN_C AVSC_EXPORT ret AVSC_CC name
#else
# define AVSC_EXPORT EXTERN_C __declspec(dllexport)
# ifndef AVSC_NO_DECLSPEC
# define AVSC_API(ret, name) EXTERN_C __declspec(dllimport) ret AVSC_CC name
# else
# define AVSC_API(ret, name) typedef ret (AVSC_CC *name##_func)
# endif
#endif

I think the "# define AVSC_CC" should be "# define AVSC_CC __stdcall" (or maybe one shouldn't test for MSVC at all here). Compiling x64 with the present capi.h worked, because there is only one calling convention for x64 Windows (so cdecl and stdcall decorations (https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html) are ignored when the target platform is x86-64). But compiling x86-32 didn't work, because the AVSC_API functions don't get declared as stdcall. After the preprocessing stage they look like this:

__attribute__((dllimport)) int avs_is_yv24(const AVS_VideoInfo * p);

when they should be this:

__attribute__((dllimport)) int __attribute__((__stdcall__)) avs_is_yv24(const AVS_VideoInfo * p);

(This is also what gets produced when one uses an old AviSynth_C.h header file from AVS 2.6.)

[qyot27]

There was a capi-related commit fairly recently messing with the dllexport/dllimport stuff (https://github.com/pinterf/AviSynthPlus/commit/42088344bbbef1faf01fd83adeedfba1d59eaa9e), but there was no description of what it was supposed to fix. It did indeed used to compile just fine with MinGW-w64 regardless of 32-bit* and 64-bit, and I'd addressed a compatibility workaround with calling convention in my branch, but it was incredibly hackish. (https://github.com/qyot27/AviSynthPlus/commit/105bf2629538fe53d32d77afe1c34476a2c3a019)

*32-bit GCC builds would not work with FFmpeg, though, due to 32-bit calling conventions. That is, unless using the regressed HEAD version of the header that allows for building AviSynth+ with GCC. But then 32-bit MSVC builds won't work. That hack above was to mitigate this and default to the program still working with 32-bit MSVC builds.

[pinterf]

I'm on r2506 and always scared of installing a new version. I've noticed that showy, showu, and showv all cause exceptions. Just thought I'd mention it in case it's still a bug. Extracty/u/v all work fine.
Fixed on git.

[ajp_anton]

When going down in bit depth, dither=-1 means round, right? Or is it floor? Because I see a tendency of everything shifting ever so slightly "down".

If you do the following on a YV24 source (repeat a few times to magnify the effect)
convertbits(16)
converttorgb(matrix="rec709")
converttoyuv444(matrix="rec601")
convertbits(8)
convertbits(16)
converttorgb(matrix="rec601")
converttoyuv444(matrix="rec709")
convertbits(8)
, interleave it with the original, and histogram("levels"), you should see that on average, Y,U and V values are all going down. If dither=-1 rounds the values, shouldn't the average stay roughly the same?


edit:
dither_bits:
- Has no effect if dither=-1 (off).
- Must be an even number from 2 to bits, inclusive.
- In addition, must be >= (clip.BitsPerComponent-8).
I don't understand why any of these restrictions exist, except for maybe for implementation reasons. Not that I need this functionality, just wondering.

[mkver]

There was a capi-related commit fairly recently messing with the dllexport/dllimport stuff (https://github.com/pinterf/AviSynthPlus/commit/42088344bbbef1faf01fd83adeedfba1d59eaa9e), but there was no description of what it was supposed to fix.
The reason seems to be a difference between GCC and MSVC regarding dllimport: If I undo pinterf's latest change to capi.h, GCC complains if the definition (in AVSInpaint.c) isn't also declared as dllimport. And apparently MSVC wants only the declaration to have the dllimport attribute, otherwise you'd get an error (https://msdn.microsoft.com/en-us/library/62688esh.aspx).
It did indeed used to compile just fine with MinGW-w64 regardless of 32-bit* and 64-bit,
You mean, it worked before pinterf's commit? Because if I use this (https://github.com/pinterf/AviSynthPlus/blob/a616181c63164d3d79f72e4a60a2d1ea40b5bbbc/avs_core/include/avs/capi.h), then the linker doesn't find a lot of symbols, because several functions are not declared as stdcall. Your new version (https://github.com/qyot27/AviSynthPlus/commit/105bf2629538fe53d32d77afe1c34476a2c3a019) meanwhile works fine.

[qyot27]

You mean, it worked before pinterf's commit? Because if I use this (https://github.com/pinterf/AviSynthPlus/blob/a616181c63164d3d79f72e4a60a2d1ea40b5bbbc/avs_core/include/avs/capi.h), then the linker doesn't find a lot of symbols, because several functions are not declared as stdcall. Your new version (https://github.com/qyot27/AviSynthPlus/commit/105bf2629538fe53d32d77afe1c34476a2c3a019) meanwhile works fine.
I mean that the last time I really checked (a few months ago - April, maybe? Possibly earlier), I could cross-compile AviSynth+ with MinGW-w64/GCC as either 32-bit or 64-bit. I can't speak for plugins, since the only one I really have anything to do with is the FFMS2 C-plugin (the capi.h there merely checks for _WIN32, not MSVC; pretty sure that's an emergency, basal version of the fix I did with the AVSC_WIN32_GCC32 define). I hadn't yet tried to see if that change breaks FFMS2, but I generally had/have a feeling that it might.

Taking a cursory look at AVSInpaint.c, though...ack. That thing needs a cleanup. I can't tell if it's even using the C interface correctly (comparing, as I mentioned above, to the FFMS2 C plugin; that might be a special case, though, and I've not taken any time thus far to see if I can get AssRender building with GCC to verify with it).

[manolito]

Now I am just curious how big the speed sacrifice using this non-SSE2 version vs. the standard version is. I still assume that the various filter plugins will be the bottleneck and not AviSynth itself...

So far nobody wanted to bite, so I did a couple of benchmarks myself... :cool:

Not representative statistically, I tried to keep it "real world" as much as I could. Interesting results, and I also have a few questions.

Test platform:
Lenovo T530, Core i5-3230M Ivy Bridge with 8 GB RAM. Pretty much middle class today (of course only entry level for Doom9 members). The CPU has 2 physical cores plus 2 virtual (Hyperthreading) cores.

AviSynth versions (32-bit only):
1: AVS 2.61 Alpha VC6 Build
2: AVS+ r2728 pinterf
3: AVS+ r2741 qyot27 Non-SSE2

Source file:
Downloaded HD clip @ 29.97 progressive.

I used 3 different scripts where the first 2 are common everday scripts, the third one uses DCT=1 with MVTools2 and is way too slow for everyday use.

Script #1:
ConvertToYV12()
DegrainMedian(mode=2)
LSFMod()
Spline36Resize(720,576)
ChangeFPS(25)

Script #2:
ConvertToYV12()
Spline36Resize(720,576)
mx_fps(25) # a modded version of FrameRateConverter by MysteryX

Script #3
Same as above except using
mx_fps(25, dct=1)


For AVS+ I tested both "Prefetch(2)" and "Prefetch(4)" at the end of the scripts. I also used "SetMTMode.avsi" which is linked at the AVS+ WIKI page.

And here comes my first question:
Do I copy this "SetMTMode.avsi" into the "plugins+" folder or into the "plugins" folder? I tried both and did not notice any difference, so I put it in the "plugins+" folder.

I deliberately did not just measure the results of the scripts in AVSMeter because I wanted fo find the overall conversion speeds. My encoder was FFmpeg which uses all 4 cores by default.


Results:

AVS 2.61 Alpha:
Script #1: 30 fps
Script #2: 15 fps
Script #3: 1.0 fps

AVS+ r2728 pinterf:
Script #1: 31 fps (no difference between Prefetch(2) and Prefetch(4))
Script #2: 24 fps (Prefetch(2)) and 28 fps (Prefetch(4))
Script #3: 1.6 fps (Prefetch(2)) and 1.5 fps (Prefetch(4))

AVS+ r2741 qyot27 Non-SSE2
Script #1: 31 fps (no difference between Prefetch(2) and Prefetch(4))
Script #2: 24 fps (Prefetch(2)) and 28 fps (Prefetch(4))
Script #3: 1.6 fps (for both Prefetch(2) and Prefetch(4))


Conclusion:
1. The difference between standard AVS and AVS+ is very obvious, mainly when a complex script like mx_fps (which uses MVTools2 and MaskTools2) gets used.

2. There is almost no difference between the official pinterf version of AVS+ and the Non-SSE2 version by qyot27. On one occasion the qyot27 version is even slightly faster.

Which leads me to my second question:
Could it be that the qyot27 version does use the SSE2 capability of the CPU if the CPU supports it? If not then I would say that using only SIMD versions up to MMX and SSE does not necessarily slow down the conversions, at least not with my tests.

Any thoughts?


Cheers
manolito

[qyot27]

Could it be that the qyot27 version does use the SSE2 capability of the CPU if the CPU supports it? If not then I would say that using only SIMD versions up to MMX and SSE does not necessarily slow down the conversions, at least not with my tests.
I said almost exactly that when talking about the how the /arch flag works.

Essentially, it works like this. Intrinsics or hand-written assembly code use SIMD instructions directly in discrete versions of a particular function (layer_sse4, layer_sse2, layer_avx, etc.). These are then included in a runtime CPU detection dispatcher which allows the program to select the appropriate one based on what the CPU supports. This always gets compiled, and the functions for the different paths are there no matter what. There are SSSE3 and SSE4 functions for some filters, there are AVX/AVX2 versions for others, all based on what can give the greatest boost/anyone bothered writing.

Most compilers, however, have the ability to optimize the plain C versions during the build process so that the final binary can emit SIMD instructions at any time. MSVC controls this through the /arch: parameter, GCC does it through -march, -mtune, or -m[SIMD] flags used together or alone. These flags make it so that said CPU or SIMD is *required*, because it will use that code even in the parts not covered by the intrinsics or assembly.

So take Mask for example. In AviSynth+, this has multiple versions of the function:
mask_sse2
mask_core_mmx (not sure if this is actually just a dependency of the mask_mmx function below)
mask_mmx
mask_c

mask_sse2 and mask_mmx are written with intrinsics. They will always be compiled to SSE2 and MMX code, respectively. The dispatcher chooses the appropriate one based on what the CPU supports. If there isn't any support for SSE2, it uses MMX. If it supports neither, it uses the plain C version.

When MSVC has /arch:IA32 set, mask_c (the entire program's plain C code, actually) will be built without any optimizations. Left at its default, though, mask_c (and all the rest of the plain C code) will be optimized by MSVC itself to emit SSE2 instructions when it gets run. Fine for CPUs that have SSE2 already, not fine for ones that don't. This auto-optimization-by-compiler is generally not as thorough or fine-tuned as you'd get from either intrinsics or hand-written assembly, which is why those are still needed to get significant boosts in speed, but for functions which haven't yet had intrinsics or asm written for them, the auto-optimization is the best you can do.

[manolito]

Thanks, I think I finally got it... :devil:

Most compilers, however, have the ability to optimize the plain C versions during the build process so that the final binary can emit SIMD instructions at any time.

So the difference is only for plain C code which gets either converted to SIMD instructions (if the CPU supports it) or not. There should be no performance hit whatsoever using your version vs. using pinterf's version.

So why doesn't pinterf implement your CPU branching routine?


Cheers
manolito

[qyot27]

So the difference is only for plain C code which gets either converted to SIMD instructions (if the CPU supports it) or not.
No. Think of it like a plain vanilla/yellow cake. You want chocolate with the cake. The SIMD instructions that come from the dedicated intrinsics functions are like chocolate frosting - it's on top, makes it taste better, but if you got a slice and didn't want any of the frosting, you could scrape it off. This is the option that's 'it gets used if the CPU supports it'.

/arch and optimizing even the C parts with SIMD is making the cake itself a marble, or straight-up chocolate, cake - if you want to avoid the chocolate, you can't. It's in there, whether you like it or not. Whether the CPU supports it or not (and if the CPU doesn't support it, it crashes with an Illegal instruction error).

I did absolutely nothing to branch AviSynth+'s CPU support. The only difference between the typical builds pinterf has been providing and the one I posted a little bit ago is that I switched /arch back to SSE before building it, the way it was on the original AviSynth+ repo before ultim went on hiatus again (as you can see, it was last updated in August 2016, which is why pinterf's repo is the current development hub everyone points to now):
https://github.com/AviSynth/AviSynthPlus/blob/MT/CMakeLists.txt#L48

vs.

https://github.com/pinterf/AviSynthPlus/blob/MT/CMakeLists.txt#L74

All I did in my working branch (https://github.com/qyot27/AviSynthPlus/blob/dss_deps/CMakeLists.txt#L74) was make it so that when I go to build AviSynth+, I don't have to open CMakeLists.txt in Notepad2-mod and change it back to SSE. Instead, I can now pass -DCPU_ARCH=SSE (or -DCPU_ARCH=IA32, -DCPU_ARCH=AVX, or -DCPU_ARCH=AVX2) to the CMake command line, like any other configuration option and avoid having to open source files in text editors first.

As for why it hasn't shown up outside of my branch, A) I just whipped up that patch earlier this week or last week, and B) I've not opened a pull request for the changes on that branch yet.

[Groucho2004]

/arch and optimizing even the C parts with SIMD is making the cake itself a marble, or straight-up chocolate, cake
Mmmmh, marble cake...
https://s33.postimg.cc/dy0uso7m7/index.png

[manolito]

/arch and optimizing even the C parts with SIMD is making the cake itself a marble, or straight-up chocolate, cake - if you want to avoid the chocolate, you can't. It's in there, whether you like it or not. Whether the CPU supports it or not (and if the CPU doesn't support it, it crashes with an Illegal instruction error).

So your build makes sure the cake itself does not become a marble cake (avoiding a crash when the CPU does not support it). By switching back /arch to SSE you avoid optimizing C parts with SIMD.

But then why the hell is your build just as fast or even a little faster on my test computer which certainly does have SSE2? :confused:

[qyot27]

So your build makes sure the cake itself does not become a marble cake (avoiding a crash when the CPU does not support it). By switching back /arch to SSE you avoid optimizing C parts with SIMD.
Roughly. It avoids using SSE2 SIMD. If you tried using that build on something older than a Pentium-III, it would crash. The only way to fully disable it is by using /arch:IA32, but how many people with a Pentium-II, Pentium Pro, or i486/i386 are going to be running at least Windows XP just to be able to run that AviSynth.dll? Much less actually be using it for anything other than academic 'because I can' points?

The point is that /arch specifies the minimum instruction set the CPU supports, and because of that, it allows the compiler to use SIMD at or below that minimum setting when optimizing the C parts of the code during the build process.

I mean, I could probably throw up a build with all the intrinsics disabled so you'd be forced to use the C versions and see directly how well MSVC optimizes stuff. I think it's just disabling a couple of defines, but I'm not sure.

But then why the hell is your build just as fast or even a little faster on my test computer which certainly does have SSE2? :confused:
MSVC might optimize for MMX/SSE a bit better in spots for a 32-bit compared to SSE2, but largely it would be because on an Ivy Bridge, you wouldn't be using the C versions of anything much/at all (for either pinterf's build or mine). It might in some non-filter areas that linger in the background, possibly. If I had to guess (based on pinterf's comment in CMakeLists.txt), it is the high bit depth stuff where you would see the biggest difference between the two builds. I'm not sure how much of it has intrinsics now, so there may be a higher proportion of it that has to rely on the compiler doing the optimization on plain C code.

[manolito]

Alright, this answers most of my questions, thanks...

Since all the high bitdepth and high colors stuff is not for me (I am just too old for all this UHD / HDR / 8K stuff, my viewing device is a 4:3 CRT TV set with natural colors I so far have never seen on an LCD. And I also refuse to converge computer (for working) and TV (for entertainment) stuff).
So all I am interested in for AVS+ is speed gain caused by MT.

Thanks again
manolito

[jpsdr]

There was plasma screen (Pioneer Kuro) which were very good for color, SED/FED died before being born, but now there is OLED, which i think will provide good color for CRT people, as i was. Like you, i've never like LCD, but my Plasma Kuro Pioneer gave me satisfaction, and the day i'll have to replace it (because it will happens, the later i hope), i think OLED will satisfy me.

[pinterf]

If I had to guess (based on pinterf's comment in CMakeLists.txt), it is the high bit depth stuff where you would see the biggest difference between the two builds. I'm not sure how much of it has intrinsics now, so there may be a higher proportion of it that has to rely on the compiler doing the optimization on plain C code.
Yeah, as I wrote, most of the 10+ bits stuff was in pure C, nowadays most of them are optimized in SIMD intrinsics. Probably 32 bit can go back to the /sse option, because who really need speed (in general and especially for 10+ bit depth option) those are already using x64 toolchain, I guess.

[Atak_Snajpera]

I'm just curious why Prefetch with value equal to number of physical cores is faster than with number of logical processors?

It does not matter if it is Xeon 8C/16T or Ryzen 8C/16T. Result is always the same.

Script
#VideoSource
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\ffms\ffms_latest\x64\ffms2.dll")
video=FFVideoSource("C:\Temp\RipBot264temp\job1\video.mkv",cachefile = "C:\Temp\RipBot264temp\job1\video.mkv.ffindex")
#Deinterlace

#Resize
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Plugins_JPSDR\Plugins_JPSDR.dll")
video=Spline36ResizeMT(video,1920,1080,SetAffinity=false).Sharpen(0.2)

#Tonemap
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\avsresize\avsresize.dll")
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\DGTonemap\x64\DGTonemap.dll")
video=z_ConvertFormat(video,pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none").DGHable
video=z_ConvertFormat(video,pixel_type="YV12",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")

#Prefetch
video=Prefetch(video,X)

#Return
return video

Prefetch(16)
AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 0.147 | 1000000 | 30.50
Memory usage (phys | virt): 2099 | 2124 MiB
Thread count: 65
CPU usage (average): 53%

Time (elapsed): 00:04:20.122



Prefetch(8)

AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 0.339 | 944590 | 33.17
Memory usage (phys | virt): 1591 | 1616 MiB
Thread count: 57
CPU usage (average): 53%

Time (elapsed): 00:03:59.189



The same happens with MDegrain2 or QMTC.

[Myrsloik]

This is a general answer that applies to most things.

You can easily saturate the total memory bandwidth with fewer than the logical number of threads. Especially (A)VS which processes full frames instead of tiles/lines quickly reach that level. And once you have more than the physical number of cores as threads you have reduced cache too... which means each thread is even more likely to have to access and wait even more for RAM.

It's possible that the default number of threads should be something like max(physical cores, min(logical threads, 8)) for x86.

[manolito]

It's possible that the default number of threads should be something like max(physical cores, min(logical threads, 8)) for x86.

Not true for my Core i5-3230M Ivy Bridge with 8 GB RAM. According to this formula I should use Prefetch(2), but my tests (latest AVS+ 32-bit) showed that in most cases Prefetch(4) is significantly faster.

[Myrsloik]

Not true for my Core i5-3230M Ivy Bridge with 8 GB RAM. According to this formula I should use Prefetch(2), but my tests showed that in most cases Prefetch(4) is significantly faster.

My formula gives 4. I don't see the problem here. The whole thing was pulled out of my butt so no guarantees thats it's optimal.

[amichaelt]

Not true for my Core i5-3230M Ivy Bridge with 8 GB RAM. According to this formula I should use Prefetch(2), but my tests (latest AVS+ 32-bit) showed that in most cases Prefetch(4) is significantly faster.

I don't think you applied the formula correctly.

The formula in your case would work through the following steps:

max(2 physical cores, min(4 logical threads, 8 threads))

Min of 4 and 8 is 4.

max(2 physical cores, 4 logical threads)

Max between 2 and 4 would be 4. So, his back-of-the-envelope formula gave you exactly what you claim was the faster number.

[Atak_Snajpera]

That formula would return 8 for 8700k/Ryzen 2600 instead of 6. I have disabled 2 cores on my Xeon E5-2690 in BIOS and again test showed that prefetch equal to number of cores is better.

Prefetch(8)
AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 0.131 | 944593 | 22.98
Memory usage (phys | virt): 1422 | 1446 MiB
Thread count: 45
CPU usage (average): 60%

Time (elapsed): 00:05:45.265

Prefetch(6)
AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 0.132 | 708445 | 25.73
Memory usage (phys | virt): 1281 | 1305 MiB
Thread count: 43
CPU usage (average): 60%

Time (elapsed): 00:05:08.385

[Atak_Snajpera]

Another test but this time disabled 6 cores leaving only 2C/4T.
Prefetch(4)
AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 0.092 | 944596 | 10.70
Memory usage (phys | virt): 784 | 808 MiB
Thread count: 17
CPU usage (average): 89%

Time (elapsed): 00:12:21.689

Prefetch(2)
AVSMeter 2.8.1 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Number of frames: 7935
Length (hh:mm:ss.ms): 00:02:12.382
Frame width: 1920
Frame height: 1080
Framerate: 59.940 (60000/1001)
Colorspace: YV12

Frames processed: 7935 (0 - 7934)
FPS (min | max | average): 3.012 | 314865 | 14.37
Memory usage (phys | virt): 620 | 644 MiB
Thread count: 15
CPU usage (average): 85%

Time (elapsed): 00:09:12.192

I've noticed that script with Prefetch value higher than number of physical cores has tendency to choke from time to time. (see min. fps)

[Myrsloik]

This is based on my observation when developing VS but it'd surprise me greatly if AVS isn't guilty as well.

At some point the frame requests end up out of order and then the source filter has to seek. This is very slow in most of them. I ended up adding logic and a flag to indicate which filters really benefit from linear access and extra logic to make requests in order more of the time. It resulted in significant speedups.

I don't understand how Avs+ multithreading works but it's most likely close to the truth...

[manolito]

Short question for the AVS+ gurus:

I am aware that the "Prefetch(x)" command should be called last in the AVS script (except for a "Return()" call). All commands after "Prefetch" will not be multithreaded.

Right now I am in the process to migrate to AVS+, and of course I want everything to be automatic. In my older 32-bit StaxRip installation I added a "Prefetch" command as the last call in the script for all my templates. But as soon as I edit out commercials in the preview, StaxRip automatically adds a "Trim()" statement as the last command (after the "Prefetch" call).

My question: Does it matter at all? Can "Trim()" even be prefetched? I did a few tests with "Trim()" before and after "Prefetch()", but the speed was identical, and the output also had no artifacts for both cases.


Cheers
manolito

[Atak_Snajpera]

In ripbot264 I do trimming after prefetch

#MT

#VideoSource

#Deinterlace

#Decimate

#Crop

#Resize

#Tonemap

#Levels

#Colours

#Denoise

#Custom

#Prefetch

#Subtitles

#AudioSource

#Triming

#ColorSpace

#Return

[LigH]

Trim() is applied once to the whole clip, therefore it cannot be parallelized frame by frame. Practically, it will probably just set a "first output frame" and a "last output frame" attribute; done.

[sausuke]

Hello, I'm back again. I just want to say thanks again especially to Groucho2004 for his AviSynth installer and AVS meter. I'm the one who has Threadripper processor. Last February I believe I fixed my problem (low fps etc). Got 70fps (happy with that to be honest). But I've decided to reformat last 2 days and my FPS is back to 50fps. I did some googling and came to this forum again and fixed my problem.

I'm using old AviSynth+ version though. The latest versions have low fps too :(

https://i.imgur.com/cx0CWfU.png

Btw why the CPU Usage is always 0. The thread ripper is default and no overclock. This is the first time that the AviSynth script gives real FPS from the avsmeter (100+ fps in software too) unlike from my previous posts wherein avsmeter report 100 fps (70 fps in the same software). Thanks again

[Groucho2004]

why the CPU Usage is always 0.
1. Post the script that gives you 0% CPU usage.
2. Update AVSMeter to the latest version, run "AVSMeter avsinfo -log" and post the log file.

What is the CPU usage in Task manager when you run the test?

[sausuke]

1. Post the script that gives you 0% CPU usage.
2. Update AVSMeter to the latest version, run "AVSMeter avsinfo -log" and post the log file.

What is the CPU usage in Task manager when you run the test?

Script
MP_Pipeline("""
### platform: win32
AVISource("E:\2Encoded Files\sss.avi", audio=false)
ConvertToYV12(matrix="PC.709")
### ###
""")

I updated it to the latest v2.8.1

Here's the cpu usage
https://i.imgur.com/BMYZDFr.png

Log:
https://pastebin.com/pLZiYyCd

[Groucho2004]

MP_Pipeline("""
### platform: win32
AVISource("E:\2Encoded Files\sss.avi", audio=false)
ConvertToYV12(matrix="PC.709")
### ###
""")
MP_Pipeline runs the script in a different process, that's why you get 0% in AVSMeter. Open the "Processes" tab in Task Manager and check the CPU usage for each process.

[sausuke]

MP_Pipeline runs the script in a different process, that's why you get 0% in AVSMeter. Open the "Processes" tab in Task Manager and check the CPU usage for each process.

oh, I see, here's my top CPU usage while using avsmeter


https://i.imgur.com/32GvUXY.png

[LigH]

Vegas is very busy, why do you run it at the same time you try to benchmark AviSynth?

What kind of AVI do you read, is it completely uncompressed, so reading from the disk consumes most of the time?

[sausuke]

Vegas is very busy, why do you run it at the same time you try to benchmark AviSynth?

What kind of AVI do you read, is it completely uncompressed, so reading from the disk consumes most of the time?

I'm frameserving after I edit my videos. That's why my issue is complicated (for me). I'm not just converting a video (e.g video to handbrake).

I think I need to move on with the software to maximize threadripper. I'm just too attached with Vegas because I'm used to it. But the 100fps from 70fps is okay for me. I've tried other NLE but it's pain to setup with frameserver and the quality to size ratio is not good compare to x264.

[Atak_Snajpera]

I'm frameserving after I edit my videos. That's why my issue is complicated (for me). I'm not just converting a video (e.g video to handbrake).

I think I need to move on with the software to maximize threadripper. I'm just too attached with Vegas because I'm used to it. But the 100fps from 70fps is okay for me. I've tried other NLE but it's pain to setup with frameserver and the quality to size ratio is not good compare to x264.

I'm curious how many fps do you get while exporting using UT Video codec (YUV420) in Vegas?

[Selur]

Is there some known problem with 'AviSynth+ 0.1 (r2728, MT, i386) (0.1.0.0)' and DeGrainMedian ?
I started with:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
and when AVSMeter crashed and reported:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\KERNELBASE.dll
Address: 0x76C7DDC2

commenting out 'CustomResize', I tried with:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

#CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
and I got the same crash, but once I also commented the other DeGrainMedian call out too and tried:
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\DGDecode.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\TMM.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\MosquitoNR.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\avisynthPlugins\degrainmedian.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\Dehalo_alpha_mt.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: VTS_01_1.VOB
# input color sampling YV12
# input luminance scale tv
MPEG2Source(d2v="E:\Temp\vob_3b6af15ddd3b19a201adf2536e9a8f23_41.d2v")
# current resolution: 720x576
# deinterlacing
TDeint(slow=2)
# cropping to 720x550
Crop(0,12,0,-14)
# current resolution: 720x550
# filtering
# deringing using MosquitoNR
MosquitoNR()
# dehaloing
DeHalo_alpha_mt()
# grain handling
#DeGrainMedian(mode=2,norow=true)

# CUSTOM SCRIPT PART - position: Resize - START
function CustomResize(clip clp) {
last=clp
DeGrainMedian(limitY=3,limitUV=5,mode=2,norow=true)
}
# CUSTOM SCRIPT PART - position: Resize - END

#CustomResize() # loading custom script content
# scaling
Spline36Resize(720,384)
# current resolution: 720x384
PreFetch(8)
return last
the script isn't crashing anymore.

Memory usage is around 220MB all the time.

So I'm wondering:
a. is there a newer verison of degrainMedian ? (using v0.8.2 from 2006 atm.)
b. is this a known problem?
c. is there a fix for this?


Cu Selur

Ps.: The script itself works fine with normal Avisynth MT 32bit. (minus the Prefetch and SetFilterMTMode call and adding distributor(), SetMTMode(),..)

[Groucho2004]

So I'm wondering:
a. is there a newer verison of degrainMedian ? (using v0.8.2 from 2006 atm.)
b. is this a known problem?
c. is there a fix for this?

a. I'm not aware of a newer version

b. I can reproduce the problem. It may be that many of the inline ASM MMX functions in DeGrainMedian are missing the EMMS instruction. See here (https://software.intel.com/en-us/node/524274) for some info.

c. I made a new build (https://www.dropbox.com/s/j6mw2yq9y6in6rz/DeGrainMedian082_Mod.7z?dl=1) with the EMMS instructions included, let me know if it works for you (it does for me).

[wonkey_monkey]

Is this thread a good place to mention errors on the Wiki? I spotted this:

If the input clip is field-based, the DoubleWeave filter operates like Weave, except that it produces double the number of frames: instead of combining fields 0 and 1 into frame 0, fields 2 and 3 into frame 1, and so on, it combines fields 0 and 1 into frame 0, fields 1 and 2 into frame 1, and so on. It does not change the [...] frame count.

http://avisynth.nl/index.php/DoubleWeave

[Groucho2004]

Is this thread a good place to mention errors on the Wiki?Probably the worst place. :)
If it's not too much hassle, why don't you create an account on avisynth.nl and fix it yourself? That's what I do (and many others) when I spot a mistake.

[wonkey_monkey]

Oh! I automatically assumed it wasn't open to registrations for some reason.

[Selur]

@Groucho2004: Thanks! Did a quick test and it seems to fix the problem, will do some more testing and report in case I run into problems. :)

[manolito]

Another (probably stupid) question from an AVS+ noob:

If MT is enabled by the "Prefetch(x)" command at the end of the script then all of the plugins before the Prefetch command will run in MT mode. Which of the 4 different MT modes gets used is specified by an explicit SetFilterMTMode() command or by a "SetMTMode.avsi" in the autoload folder. If none of the MT modes is specified then the default MT mode 2 (MT_MULTI_INSTANCE) will be used. Everybody agrees on this?

Now I found this about ColorMatrix as a comment in the current "SetMTMode.avsi":
#note2: tried multiple files, seems to corrupt video even when it is the only filter in a script.
#tried mode 1, 2, and 3, none worked. however it works fine if MT isn't enabled.

So I would like to tell AVS+ to use ColorMatrix in "Single Threaded" mode while I still have a "Prefetch(x)" command at the end of the script. How would I do this? Is there any SetFilterMTMode() command which forces ST mode for a specified filter?


Cheers
manolito

[videoh]

E.g.:

SetFilterMTMode("FFVideoSource", MT_SERIALIZED)

[manolito]

Are you serious?
MT_SERIALIZED equals Mode 3. And if I understand this correctly then Mode 3 is not single threaded. Yes I do know what parallel and serial means, but specifying Mode 3 is certainly not the same as disabling MT.
From the AVS+ Wiki:
Mode 3 (MT_SERIALIZED) is evil.
It should only be used for source filters or filters which do not have a Clip parameter.

The quoted note said that he tried mode 1, 2 and 3 and none worked. It only worked if MultiThreading was not enabled.

So my question remains:
How do I force ColorMatrix to run single threaded without removing the Prefetch(x) command which would make my whole script run single threaded?

[DJATOM]

Yeah, colormatrix is just too broken, so I'd like to suggest you dithertools instead:
Dither_convert_yuv_to_rgb (matrix="601", output="rgb48y")
r = SelectEvery (3, 0)
g = SelectEvery (3, 1)
b = SelectEvery (3, 2)
Dither_convert_rgb_to_yuv (r, g, b, matrix="709", lsb=false, mode=0)

[poisondeathray]

or another alternative to colormatrix that is prefetch(x) safe in avs+mt would be avsresize using the colorspace_op parameter

[manolito]

Yeah, colormatrix is just too broken

I have a hard time to believe that tritical has ever published something that is "just too broken"... :confused:

Anyhow, DitherTools is not an option for me. First of all I have no use for this high bitdepth stuff, and secondly DitherTools requires a SSE2 capable CPU which one of my computers does not have (and I want identical AviSynth configurations on all of my machines).

I just found that ColorMatrix has a "Threads" parameter:
threads:

Sets the number of threads Colormatrix will use for processing. Can be any value greater than 0 and, for YUY2, less than the frame height, for YV12, less than the frame height divided by 2. If set to 0, ColorMatrix will automatically detect the number of available processors and set threads equal to that value.

default - 1 (int)

Could it help for AVS+ multithreading to increase the "Threads" value to the same value which is used by "Prefetch()"?


If I really cannot get ColorMatrix to work reliably with AVS+ multithreading then I am already tempted to revert back to classic AVS 2.60. Most of my AVS scripts (HD to SD conversions) use ColorMatrix, this needs to be absolutely reliable for me. Since I do not use the expanded bit depths and color formats of AVS+ all I really care for is the speed gain from multitasking. And my tests so far (using only filters which are not too complex) only showed a very moderate speed gain. Nothing I would trade for the risk of introducing artifacts which I might only detect much later.


Cheers
manolito

[Groucho2004]

If I really cannot get ColorMatrix to work reliably with AVS+ multithreading then I am already tempted to revert back to classic AVS 2.60.
Can you post a script that shows the problem with ColorMatrix? I have never noticed any.

Anyway, I don't see the problem using MT_SERIALIZED with ColorMatrix. I just ran a few tests and the performance hit is virtually zero, even if I put the ColorMatrix call near the end of the script.

[manolito]

Can you post a script that shows the problem with ColorMatrix? I have never noticed any.


No I can't because so far I also did never see any problems with multithreading ColorMatrix. Neither with the default MT_MULTI_INSTANCE nor with MT_NICE_FILTER which gets set when using the "MTMode.avsi" from here:
http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

What really turned on the red lights for me was the note in this AVSI that modes 1, 2 and 3 all caused artifacts. What should I make of this contradicting information? Is MT_SERIALIZED really safer?

The reason I am a little touchy on this subject is that I already had some bad experiences with ColorMatrix in the past. It was an older version which caused random artifacts on random sources, no error messages. It took me a while to find out that the newer version 2.5 had fixed the issues, but it was too late. After I finally detected the artifacts I did no longer have access to the source files.


Cheers
manolito

[StainlessS]

Methinks that you squeal long before you are bitten.

[TheFluff]

I have a hard time to believe that tritical has ever published something that is "just too broken"... :confused:

No, ColorMatrix is definitely incredibly broken in several different ways and that definitely isn't unusual for tritical code. The man came up with some clever algorithms but he was definitely not someone whose code you'd ever want to read or maintain. ColorMatrix features an eclectic selection of incredibly poor programming decisions ranging from the usual inline assembler (with questionable speed benefit) that doesn't match the C implementation, to an eyewateringly awful D2V parser copypasted into the middle of the plugin, and finally to the (in this case) rather inconvenient fact that it has its own internal win32 multithreading, which is used even if you set threads=1. The actual processing is always run in a separate thread, so you can't actually make it single-threaded - it always uses at least two threads. That last fact probably broke Avs-MT's thread synchronization at some point, but I have no idea if it still does since very significant parts of the multithreading code was rewritten by ultim et al and then further modified by pinterf. I'm actually not sure if you can even entirely disable "MT" in Avs+ anymore. Writing comments in some obscure configuration file isn't a reasonable way to track and triage bug reports, in any case.

I'm pretty sure it works without issues in current Avs+ because this is the first thing I hear about artifacts and I know a lot of people use it with multithreading enabled in Avs+. However, there is really no reason to keep using ColorMatrix in 2018, since we have significantly better tools today. I'd suggest zimg (https://forum.doom9.org/showthread.php?t=173986) (also referred to as "avsresize").

[StainlessS]

Fluffy, I'm always quite amazed at the depth of understanding you have of other peoples plugs,
I'm wondering if you could find the time to correct triticals 'not so good' decisions,
I'm quite sure many people would like a more robust and well more fluffy version of same.

[TheFluff]

Fluffy, I'm always quite amazed at the depth of understanding you have of other peoples plugs,
I'm wondering if you could find the time to correct triticals 'not so good' decisions,
I'm quite sure many people would like a more robust and well more fluffy version of same.
No need, all of his useful plugins have already been ported (well, more like "reverse engineered and rewritten") to Vapoursynth by other people.

Note though that I don't have anything personal against tritical and I definitely don't deny that many of the plugins he wrote have been extremely influential and useful. As a professional software engineer though, his coding habits are deeply offensive to my sense of craftsmanship.

[StainlessS]

reverse engineered and rewritten

Did triticals plugs come with source, usually ? (I think I have some of his source).

EDIT: Not everyone uses Vapoursynth, although as I understand it, some do.

[TheFluff]

Did triticals plugs come with source, usually ? (I think I have some of his source).

Yes but it's completely unreadable and unmaintainable, and that's by far the biggest problem with all of his code. Myrsloik once referred to it as "open binary" (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/) because all the uncommented inline asm that doesn't match the C implementation and inscrutable numerical constants everywhere means that having the source code isn't really helpful at all when it comes to figuring out what the plugin is actually doing. You could have just disassembled the binary and you would've been in pretty much the same place.

If you want improved tritical plugins for Avisynth it'd be far, far easier to backport the Vapoursynth reimplementations than to try to fix the original code.

[StainlessS]

OK, got ya.
I once tried figure out the AutoCrop thing by Gary (something beginning with B), and it was hell, real nasty stuff,
and that was only C/CPP, I guess that big T's efforts could be well more cryptic, Kassandro (not sure if I spelt right)
was well clever guy but also was a bit peculiar and somewhat messy and a little too secretive (undoc'ed functions and such).
Anyways, thanx for your answer, much appreciated.

EDIT: Just saw this
If you want improved tritical plugins for Avisynth it'd be far, far easier to backport the Vapoursynth reimplementations than to try to fix the original code.
Worth considering, thank you.

EDIT: I know that I have been accused of writing "Machine Code" style C/CPP (by Feisty2), I really hope that Feisty
was/is just a little bit exaggerant in such accusation, I would hate to think that no-one at all could understand my
code, (well at least another C coder should be able to figure out what it was doing).

[manolito]

Writing comments in some obscure configuration file isn't a reasonable way to track and triage bug reports, in any case.

I'm pretty sure it works without issues in current Avs+ because this is the first thing I hear about artifacts and I know a lot of people use it with multithreading enabled in Avs+.

Well, this obscure configuration file is officially linked in the AVS+ Wiki. Among the authors and contributors you can find such "obscure" folks like Reel.Deal, tp7, Firesledge and real.finder.

Thanks for the hint that AVS+ MT was improved a lot during the last years, so Colormatrix may not be any problem today. I just saw that the note about Colormatrix was already present in this "obscure" AVSI in the first versions from 2015, so probably noone took the time to have another look at it recently.

I did comment out the line which specifies MT_NICE_FILTER for Colormatrix, so it will use the default MT_MULTI_INSTANCE now. Good idea or not?

StainlessS:
Methinks that you squeal long before you are bitten.
You are damn right... :scared:
I have been bitten by an older version of Colormatrix before, and it was painful.


Cheers
manolito

[TheFluff]

Well, this obscure configuration file is officially linked in the AVS+ Wiki. Among the authors and contributors you can find such "obscure" folks like Reel.Deal, tp7, Firesledge and real.finder.
I meant obscure in the sense that it's not a place where people would go look for documentation about known issues, or think of as a place to update when such issues are fixed. For most people it's effectively equivalent to hardcoded internals. Since its version history is spotty at best it's also hard to figure out how old that comment really is, but it seems to have been there since mid-2014 at the very least. The same question you're asking now was brought up in this thread two years ago (https://forum.doom9.org/showthread.php?p=1769237#post1769237) without any satisfactory answer. It's still there and spreading uncertainty to this day. The proper way of doing this kind of thing would be some kind of bug tracker.

I did comment out the line which specifies MT_NICE_FILTER for Colormatrix, so it will use the default MT_MULTI_INSTANCE now. Good idea or not?
It's a pretty commonly used filter and everyone else who uses it with Avs+ most likely uses the default mode from that file. If you want to avoid unexpected and subtle problems, I would not recommend going out of your way to run a configuration that few other people use and test.

All that being said, I took a brief glance at the code again and I'd bet a fair sum that the reason it misbehaves (or used to misbehave) is extensive use of env->Invoke, especially in interlaced mode where it invokes InternalCache (which Avs+ (ab)uses a lot for its multithreading IIRC). Adding to the problem, the filters it invokes are invoked from the main thread, but when Avs+ then calls GetFrame the processing is actually done in a different thread inside ColorMatrix and I bet that has potential for interesting results - as far as I can remember Avs+ utilizes thread-local storage quite a bit. Still though, pinterf has done significant improvements to the robustness of the multithreading code over the last few years, especially when it comes to this kind of runtime shenanigans, so it may very well actually work now. Who knows, though!

Really though, don't use ColorMatrix. Why on earth would you invoke Limiter() instead of tacking on a simple min/max clamp to your pixel math? In the asm version it would literally be two instructions! Jeez.

zimg/avsresize works on ARM, so it should definitely work on a CPU without SSE2 too. No excuses.

[manolito]

zimg/avsresize works on ARM, so it should definitely work on a CPU without SSE2 too. No excuses.

Lots of excuses... :devil:
The zimg library might work without SSE2, the AVS wrapper DLL certainly does not.

The other excuse would be that the avsresize download package comes without any proper documentation for AVS users who have never touched VapourSynth (or are no diehard developers).

The HD to SD AVS script I use so far goes like this:
Source Filter
ColorMatrix(mode="Rec.709->Rec.601")
ConvertToYV12()
Spline36Resize(704,396)

How would I do the same thing with avsresize?

Looks like I would need to use the VS compatible calls. From the doc:
colorspace_op: colorspace operation description
Format is
"matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"

This is something most AVS users including me will not understand. If someone wants avsresize to become more popular among AVS users then the first thing would be to write some proper documentation including usage examples (take a look at tritical's docs). I will stick with Colormatrix for the time being.


Cheers
manolito

[poisondeathray]

The HD to SD AVS script I use so far goes like this:

Source Filter
ColorMatrix(mode="Rec.709->Rec.601")
ConvertToYV12()
Spline36Resize(704,396)

How would I do the same thing with avsresize?

Looks like I would need to use the VS compatible calls. From the doc:
colorspace_op: colorspace operation description
Format is
"matS[:transS[:primS[:rangeS]]]=>matD[:transD[:primD[:rangeD]]]"



It's not that bad. Like avisynth , you can omit the other arguments and just use matrix (S is source, D is destination).
One difference in notation "170m" or "470bg" for sd matrix instead of "Rec601"; "709" instead of "Rec.709"


Source Filter
z_ConvertFormat(704,396, "YV12", colorspace_op="709=>170m", resample_filter="spline36")



Another difference Fluffy alluded to is colormatrix clips (it doesn't "clamp", which implies "squishing", not hard clipping), unless you use clamp=0 (normally in avisynth classic I would use mode="Rec.709->Rec.601", clamp=0) . zlib/avsresize doesn't clip data

[TheFluff]

colorspace_op="709=>470bg"

S and D stands for source and destination, "mat" means matrix, "trans" means transfer characteristics, "prim" means color primaries and range means range. As the short doc says, the string constants are in the Vapoursynth documentation (http://www.vapoursynth.com/doc/functions/resize.html).

e: poisondeathray got there first

[wonkey_monkey]

Is this expected/deliberate behaviour?

function _flipit(clip c) { # note the underscore
return c.flipvertical
}

function flipit(clip c) {
return c.fliphorizontal
}

version._flipit # note the underscore


The result is flipped horizontally, not vertically as you might expect. It seems that when faced with a function call with a leading _, Avisynth first matches it without the underscore, and only falls back to the underscored function (_flipit) if there is no non-underscored function (flipit).

[LigH]

It is probably related to the function syntax {DllFileName}_{FunctionName} to select a function provided by a specific DLL when several DLLs in the range of loaded plugins (especially with a full auto-load directory) provide functions of the same name. An empty DLL name may match the AviSynth core.

You may prefer a function like flipit(clip c, bool vertical) instead.

[Groucho2004]

Is this expected/deliberate behaviour?

function _flipit(clip c) { # note the underscore
return c.flipvertical
}

function flipit(clip c) {
return c.fliphorizontal
}

version._flipit # note the underscore


The result is flipped horizontally, not vertically as you might expect. It seems that when faced with a function call with a leading _, Avisynth first matches it without the underscore, and only falls back to the underscored function (_flipit) if there is no non-underscored function (flipit).
It flips vertically with classic Avisynth (2.60, 2.61).

Edit: It also flips vertically with AVS+ r1576.

[wonkey_monkey]

You may prefer a function like flipit(clip c, bool vertical) instead.

It was just an example :) I had written a script function, and was replacing it with a filter verision, and using a _ prefix to distinguish them while I worked on it.

I didn't know about the DLL specifier. That's useful to know.

[StainlessS]

It flips vertically with classic Avisynth (2.60, 2.61).

Edit: It also flips vertically with AVS+ r1576.

Agreed.

r1825 not Affected (flip vertical)
r2172 IS affected (oops)

EDIT: David, "Plugin Autoload and Conflicting Function Names"
http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Conflicting_Function_Names
EDIT: Some dll names used to cause problems for avs and AvsPMod, if they had eg a hyphen in them,
(as not valid in variable name or plugin name), think there was some kind of kludge implemented to eg
convert non valid chars to something else, maybe '_' .

[manolito]

An AVS+ noob again:

I have really gotten used to have the AVS docs installed locally as a "Docs" subfolder under the AviSynth folder on my HDD. AVS+ does not offer this option. Is it possible to download the available AVS+ online docs and store them locally in a "Docs" subfolder just like in classic AVS?

I am not always online when I do AviSynth stuff (my neighborhood beergarden refuses to install WLan because they want their guests to talk to each other instead of staring at their smartphones - which I totally agree with).


Cheers
manolito

[qyot27]

Depends on what you mean by 'docs'. To my knowledge, most of the new information on AviSynth+ has simply been added directly to the AviSynth wiki, the docs in the source tree haven't merged those changes in (partly because I'm not really sure how to keep track of the Wiki changes to know if there's something that needs it; there's also some pages that were written new for the Wiki; even the new pages I added to the docs in the source tree, mostly a primer for how to build AviSynth+, are themselves outdated now). The docs in the AviSynth+ source tree are mostly a direct port of the old AviSynth docs to Sphinx, which would have allowed/does allow much easier changes than having to wrangle directly with HTML (the .rst files used by Sphinx are mostly plaintext; Sphinx itself can then be used to generate the docs in a variety of output formats, provided you have the necessary tools for it to do so - it can do HTML by default).

If you have Python installed (with pip), you can generate the docs by doing this (in a Command Prompt):
pip install sphinx

git clone -b MT git://github.com/pinterf/AviSynthPlus.git
cd AviSynthPlus/distrib/docs/english
make html
The generated doc tree will be in the 'build' directory that gets created in the same location (distrib/docs/english). Do note, however, that the pages for External Filters were removed, on the basis that that should be the plugin's job to provide documentation, not the main project's (and the avisynth.ru mirror still exists with all those pages, and most/all of them are also documented on the Wiki). I had ported the externalfilters to rst with the rest of the docs, and the archive of that is here (https://github.com/qyot27/avisynthdoc_externalfilters). I can't remember how complete it was, though.

Fun fact: because Github uses a variant of RST for its markup, most of the docs pages can actually be viewed as-is straight from the source tree with a minimalistic amount of styling (https://github.com/qyot27/avisynthdoc_externalfilters/blob/master/externalfilters/dctfilter.rst).

[StainlessS]

V2.60 docs as compressed CHM here, including SDK stuff + Aivsynth v3 (v2.58) and v6 (v2.60) Avisynth Headers.h

AvisynthEngHelp SDK26_FINAL-2015-05-31 (~4.6MB):-
http://www.mediafire.com/file/62mphc846sdh6u0/AvisynthEngHelp%2BSDK26_FINAL-2015-05-31.zip

Sling it on a hotkey eg CTRL/ALT/H.

[LigH]

I remember there are some plugins to display reStructuredText and MarkDown documents in web browsers...

[Groucho2004]

As qyot27 mentioned above, the docs in the AviSynth+ source tree are basically equivalent to the old AviSynth docs.

If one wants documentation of all the new functionality, the wiki is the only place to go. Special credit goes to raffriff42 who spent countless hours updating the wiki for AVS+.

[manolito]

Thanks guys,

I already copied the old AVS 2.60 Docs folder under the AVS+ folder. I'll see if I can copy&paste together a short HTML from the AVS+ Wiki which points out the most important differences.


Cheers
manolito

[Reel.Deel]

If one wants documentation of all the new functionality, the wiki is the only place to go. Special credit goes to raffriff42 who spent countless hours updating the wiki for AVS+.

Cough cough :)

[Groucho2004]

Cough cough :)Of course there are others who spent a lot of their spare time maintaining the wiki. I was referring in particular to AVS+.

[pinterf]

It is probably related to the function syntax {DllFileName}_{FunctionName} to select a function provided by a specific DLL when several DLLs in the range of loaded plugins (especially with a full auto-load directory) provide functions of the same name. An empty DLL name may match the AviSynth core.

You may prefer a function like flipit(clip c, bool vertical) instead.
In general, when there is no dll then avs+ will simply use an empty dll name and "_" will appear as the first character in the "canonical" function name.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L209

Storing in the list using the original name
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L871
Storing in the list with the canonical (in this case with the _ prefix) name
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L886

This latter is overwriting the intentionally "_" prefixed _flipit function with the canonical version of flipit.

[LigH]

And I did not even read the sources... :eek: :o

[djonline]

Suggest that you change

DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

to

Import("00114.MTS-pass2-64.avs").Trim(30,0)



Trim not work after Import, only after DirectShowSource.

DirectShowSource("avisynth-stage1-with-MTS.avs") still not work with LAV splitter 0.71

[LigH]

Then write the Trim in a separate line, not after a dot.

If the imported script returns a clip, then it should be passed to the usual internal variable "last", which is then implicitly assumed where no explicit clip variable was written.

If it does not return any clip, then it can't be used as video source anyway.

[preludium975]

Why do I get a pink screen when I'm trying to dither 10bit -> 8bit? The source is 10bit, 4:2:0, bt.709. This is modded FFMS2, with ffmpeg decoder, but i tried all of the modded ffms2 decoders, but none of them work. I always get pink screen. LSMASH works fine, but i need FFMS2.

Here's the avs script:
FFVideoSource("sample.mkv", enable10bithack=true)
ConvertFromStacked(bits=10)
ConvertBits(bits=8, dither=0)

image (https://vgy.me/yFoB77.png)

[sneaker_ger]

Why don't you use the regular, non-modded ffms2? It supports >8 bit depths of AviSynth+ natively.

[preludium975]

I was read this, in the Avisynth‘s site: "(10-bit formats are supported with the 10bithack version - see alternate download above)"

[FranceBB]

I was read this, in the Avisynth‘s site: "(10-bit formats are supported with the 10bithack version - see alternate download above)"

Yes, in the past Avisynth+ didn't exist and regular Avisynth was working in 8bit, so 10bit+ videos were indexed as 16bit stacked (MSB at the top, LSB at the bottom).
Nowadays, Avisynth+ supports regular high bit depth, so does FFMpegSource2.
Get the latest official version of ffms2 or the latest test version of ffms2000 and index your file; ffms will automatically index it in its native bit-depth (i.e if a file is 10bit, it will be indexed as 10bit).

*if* you are using regular Avisynth and you wanna use 16bit stacked for whatever reason, then that's another story, but since you are replying in the Avisynth+ development topic, I assume you are using Avisynth+ ;)

[preludium975]

Yes, in the past Avisynth+ didn't exist and regular Avisynth was working in 8bit, so 10bit+ videos were indexed as 16bit stacked (MSB at the top, LSB at the bottom).
Nowadays, Avisynth+ supports regular high bit depth, so does FFMpegSource2.
Get the latest official version of ffms2 or the latest test version of ffms2000 and index your file; ffms will automatically index it in its native bit-depth (i.e if a file is 10bit, it will be indexed as 10bit).

*if* you are using regular Avisynth and you wanna use 16bit stacked for whatever reason, then that's another story, but since you are replying in the Avisynth+ development topic, I assume you are using Avisynth+ ;)
I tried it, it's working. But I don't need ConvertFromStacked(), because the new FFMS2 can load native 10bit, i just need the ConvertBits().

Thank you.

[Richard1485]

When converting from 10bit to 8bit with the following script...

LWLibavVideoSource("bla.mkv", stacked=true, format="YUV420P10")
ConvertFromStacked(bits=10)
ConvertBits(bits=8, dither=0)

... the luma range goes from looking like this...

https://i.imgur.com/bG5U4LT.png

to looking like this...

https://i.imgur.com/Iwp7rdV.png

Have I overlooked something? When previewing in VirtualDub2, the video doesn't look obviously wrong, but I've never seen a histogram look like that unless there's a problem of some kind.

[Selur]

what happens when us use: dither = -1 ?
int dither = -1
If -1 (default), do not add dither;
If 0, add ordered dither;
If 1, add error diffusion (Floyd-Steinberg) dither doom9


Cu Selur

[Richard1485]

Yeah, I tried that. The resulting histogram still looks like the second one that I posted above.

[wonkey_monkey]

At what point in the script did you call histogram to get the first image?

It looks to me like histogram has got its levels mixed up. The graph is ostensibly the same, but there are parts where it looks like the values being plotted have overflowed - the same pattern of pixels is seen as in the "correct" image but in dark grey instead of light grey.

In fact that is exactly how it looks - if you darken the image to 0-128, then add 128 to the "blacked-out" areas, it seems to take on the correct range when comparing it to the "correct" image.

So it's like a 9-bit graph output truncated to 8-bits.

[Richard1485]

I called Histogram() when returning the video. But the first one looks fine to me. It's the second one that looks messed up.

EDIT: It's working now. I'm not sure what went wrong, but there you go.

[StvG]

ConvertBits(8) gives a big difference compared to z_ConvertFormat(pixel_type="YV12") and DitherPost(mode=-1). Is that an expected behavior?

ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertToStacked()
DitherPost(mode=-1)
a=last
s
z_ConvertFormat(pixel_type="yv12")
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/5b/49/dfRSek0z_t.png (http://imgbox.com/dfRSek0z)
ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertToStacked()
DitherPost(mode=-1)
a=last
s
ConvertBits(8)
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/8b/d9/pvNS1iN6_t.png (http://imgbox.com/pvNS1iN6)
ImageSource()
Interleave(ShowRed("y8"), ShowGreen("y8"), ShowBlue("y8")).Dither_convert_8_to_16()
Dither_convert_rgb_to_yuv (
\ SelectEvery (3, 0), SelectEvery (3, 1), SelectEvery (3, 2),
\ matrix="709", noring=true, output="YV12", tv_range=true, chromak="spline36",
\ lsb=false, mode=6)
z_ConvertFormat(width/2,height/2,pixel_type="yuv420p16", resample_filter="spline36")
s=last
ConvertBits(8)
a=last
s
z_ConvertFormat(pixel_type="yv12")
Compare(a, channels="yuv")

https://thumbs2.imgbox.com/99/54/Pq5DIzXm_t.png (http://imgbox.com/Pq5DIzXm)

Image source (https://images2.imgbox.com/9c/a8/TusqdQS0_o.png).

[wonkey_monkey]

Is there any way to get a debug output of the compiled code generated when using expr()?

[pinterf]

Is there any way to get a debug output of the compiled code generated when using expr()?
No, I put a breakpoint at the entry of calling the compiled code and then changed to assembler view.

[wonkey_monkey]

Okay. Such a facility would be nice if you ever happen to be near that code again :)

[Richard1485]

I've experienced for the second time the same problem that I raised in post#4261. If I switch from the x64 version of ffms2 to the x86 one, it goes away. This must have been why the issue suddenly seemed to clear up (for which, see post#4265): both times, I switched versions (for unrelated reasons). I just didn't put two and two together. Does anyone experience this issue or is it just me?

[poisondeathray]

I've experienced for the second time the same problem that I raised in post#4261. If I switch from the x64 version of ffms2 to the x86 one, it goes away. This must have been why the issue suddenly seemed to clear up (for which, see post#4265): both times, I switched versions (for unrelated reasons). I just didn't put two and two together. Does anyone experience this issue or is it just me?

I can reproduce this.

Either ffms2 or lsmash as your earlier post

avsresize to convert bits instead of convertbits also same result

I don't have avs+ 86 installed , so I can't check that or x86 source filters . But if it "goes away" with ffms2 x86, then it suggests avisynth+ x86 histogram is not affected

vpy x64 version of histogram not affected


EDIT: I just rechecked some things and I can NOT reproduce it anymore! I have no idea what is going on but I'm sure I saw it earlier

[pinterf]

I called Histogram() when returning the video. But the first one looks fine to me. It's the second one that looks messed up.

EDIT: It's working now. I'm not sure what went wrong, but there you go.
If my assumption is right, the problem depends on special timing conditions so it's not 100% reproducible, and is inside Avisynth.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/histogram.cpp#L1600
The brigtness lookup table may not always be initialized fully by the time it is used in another thread. I could reproduce such effect by inserting an artificial sleep
std::this_thread::sleep_for(std::chrono::milliseconds(1));
inside the for-loop of lookup (here: variable exptab) generation.

Looking at the code of the Classic histogram I noticed another problem. Since there is only a single predefined lookup table, it will be calculated for whatever bit-depth is found first.
When classic histogram appears e.g. twice for different bit-depth they won’t work properly for both instance. Just check it:
...some 8-bit clip here...
x8 = last
x16 = last.ConvertBits(16)
StackVertical(x16.Histogram().ConvertBits(8),x8.Histogram())
I'll check both problems.

[StainlessS]

Hi P, hows bout an Avisynth_+_Pinterf thread, about time you had thread control.

Just point one last post pointing at new thread (with request for no new posts unless directed at Ultim original branch).

[tormento]

Strange internal filter error here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

Any hint? Latest AVS+ installed.

[LigH]

The expression "latest" is insufficient. Please tell us the exact version (e.g. via AVSMeter).

The latest release of AviSynth+ MT by pinterf (https://github.com/pinterf/AviSynthPlus/releases) is r2728-MT (20180702).

[tormento]

The expression "latest" is insufficient.
I use the latest release version. The one you quoted, x64 flavor. :D

[Groucho2004]

I use the latest release version. The one you quoted, x64 flavor. :D
Run "avsmeter64 avsinfo" and check if that throws any error(s).

[tormento]

Run "avsmeter64 avsinfo" and check if that throws any error(s).
AFAIK no error:
AVSMeter 2.8.6 (x64) - Copyright (c) 2012-2018, Groucho2004

VersionString: AviSynth+ 0.1 (r2728, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 5
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2018-07-02, 12:54:16 (UTC)
PluginDir2_5 (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64
PluginDir+ (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64+


[CPP 2.6 Plugins (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.dll [2.5.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\GamMac-1.10.dll [1.10.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\KNLMeansCL-1.1.1.dll [2018-01-29]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.18-pinterf.dll [2.2.18.0]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.dll [2.7.32.0]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.97-pinterf.dll [0.97.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\ZLlib-r1d-Savage.dll [2018-03-22]

[Scripts (AVSI)]
D:\Programmi\Media\AviSynth+\plugins64\CompTest.avsi [2010-09-05]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2·100.avsi [2018-07-11]
D:\Programmi\Media\AviSynth+\plugins64\TemporalDegrain-2.1.1-ErazorTT.avsi [2018-10-27]

[Uncategorized DLLs (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64+\libfftw3f-3.dll [2018-10-24]

[Uncategorized files]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.htm [2018-07-06]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.5-pinterf.md [2018-07-02]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter.gif [2005-04-04]
D:\Programmi\Media\AviSynth+\plugins64+\GamMac-1.10.txt [2018-06-15]
D:\Programmi\Media\AviSynth+\plugins64+\KNLMeansCL-1.1.1.htm [2018-03-10]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.0a48.htm [2010-12-31]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.18-pinterf.md [2018-09-05]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.htm [2018-10-18]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.32-pinterf.md [2018-10-18]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.97-pinterf.md [2018-07-02]
D:\Programmi\Media\AviSynth+\plugins64+\ZLib-r1d-Savage.md [2016-10-30]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2d.htm [2015-07-21]
D:\Programmi\Media\AviSynth+\plugins64\Stab-256.1.01-videoFred.7z [2018-09-04]

[StainlessS]

No help here but get rid of all the uncategorised files from plugs, they are all not needed there, ie rubbish.

No sure if ok to have libbfft3d-3.dll where it is (think some plugs were altered to also scan same dir as plugin).
(I would probably put mine in system32, although if using both 32 and 64 bit together, then I think things change,
not sure, have to check that out when I go that way)

[Groucho2004]

AFAIK no error
Weird. Run the script with avsmeter64.

[tormento]

Weird. Run the script with avsmeter64.
AVSMeter 2.8.6 (x64) - Copyright (c) 2012-2018, Groucho2004
AviSynth+ 0.1 (r2728, MT, x86_64) (0.1.0.0)

Script error: There is no function named 'ConvertToStacked'.
(D:/Programmi/Media/AviSynth+/plugins64/TemporalDegrain-2.1.1—ErazorTT.avsi, line 236)
(E:\in\2_01 sacrificio del cervo sacro, Il\sacrificio_4td.avs, line 17)

[tormento]

No help here but get rid of all the uncategorised files from plugs, they are all not needed there, ie rubbish.
Usually I have no problems. :(
No sure if ok to have libbfft3d-3.dll where it is
It's ok with Pinterf's build.

[LigH]

Does your script or any imported script explicitly load a plugin DLL from a separate directory, which might be obsolete?

[Groucho2004]

There is no function named 'ConvertToStacked'This error really has me stumped since you have the correct Avisynth version and seemingly all necessary dependencies installed. :confused:

[Groucho2004]

This error really has me stumped since you have the correct Avisynth version and seemingly all necessary dependencies installed. :confused:

Stupid me. ConvertToStacked is an external plugin function and none of the AVS+ plugins - one of which is ConvertStacked.dll - show up in the log.

tormento, put the AVS+ plugins into your auto-load directory.

[Richard1485]

I'll check both problems.

Thanks! I appreciate your looking into this.

[edcrfv94]

trim(??, ??)
#e.g trim(71152, 72152)
SelectEvery (1, -7, -6, -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7)


the 0-6 frames will come from before trim 71152 and have some unnecessary frames at end.
correct should be repeat first frames 7 times and total frames 1001*15 = 15015.

[pinterf]

Strange internal filter error here (https://forum.doom9.org/showthread.php?p=1856262#post1856262).

Any hint? Latest AVS+ installed.
There should be a ConvertStacked.dll in the plugins+ or plugins64+ folder
Edit: Groucho2004 was quicker, I should have scrolled down a bit.

[tormento]

Stupid me. ConvertToStacked
We are both. I assumed, since internal, it was incorporated into avisynth.dll code.

Thanks. Pinterf too. :)

@pinterf: is there any specific reason you keep on carrying those "internal" filters as external dll instead of incorporating them?

[pinterf]

We are both. I assumed, since internal, it was incorporated into avisynth.dll code.

Thanks. Pinterf too. :)

@pinterf: is there any specific reason you keep on carrying those "internal" filters as external dll instead of incorporating them?
It's by design which was decided by ultim and co. We put stacked conversion support in avisynth+ for convenience, even considered they exist only temporarily. I couldn't foresee that so much plugins working in stacked format will freeze in development and still exist years after the native high bit depth support.

[pinterf]

Hi P, hows bout an Avisynth_+_Pinterf thread, about time you had thread control.

Just point one last post pointing at new thread (with request for no new posts unless directed at Ultim original branch).
I guess thread control means editing the very first post. Good idea, considering.

[tormento]

It's by design which was decided by ultim and co.
AFAIK the one and only who keeps project alive is you. IMHO we don't need to walk into another cul de sac, like plain AVS did: it's better to understand that evolution is the right way to go. You did great things such as high bitdepth support, etc. It's time that, without jumping onto VS vagon, things shoud have the freedom to grow with their legs. :o There are other forums where some filters has started to share CUDA space to have some speedup. I honor the ancestors but I appreciate much more who spends time to keep the project alive.

[StainlessS]

@tormento,
:goodpost:

[tormento]

@pinterf

I wrongly addressed to LoRd_MuldeR the fault for Simple x264/265 launcher not giving Unicode log. I am aware now that is probably AviSynth the one not compliant :)

Can you tell me if it's Unicode aware or not in the error messages at least?

[pinterf]

No unicode. Utf8 is supported in Import file path and name, and Subtitle text through an extra utf8 bool parameter

[tormento]

No unicode. Utf8 is supported in Import file path and name, and Subtitle text through an extra utf8 bool parameter
Would be a nightmare to implement in error messages?

[StainlessS]

Dont know if this is a bug in avs+ or not.

https://forum.doom9.org/showthread.php?p=1857024#post1857024

[pinterf]

Dont know if this is a bug in avs+ or not.

https://forum.doom9.org/showthread.php?p=1857024#post1857024
Memory is eaten? We are going to know it in the near future.

[StainlessS]

Memory is eaten?

Yep.
With my test clip (854x480@30, 3775 Frames), memory usage max's out at about 1.73GB,
but when reaching end and then traversing backwards, we get this

https://i.postimg.cc/zyJfV6f9/OMEM.jpg (https://postimg.cc/zyJfV6f9)

EDIT: Win7 x64 with 12GB DDR3 (avs+ x86).

EDIT: If opening clip in VD2, and jumping to last frame, then traversing backwards a 1000 or so frames, all is ok,
but on swap direction and going forwards, then will OMEM again.
EDIT: Test clip is UT_Video YV12 avi.

[pinterf]

Yep.
With my test clip (854x480@30, 3775 Frames), memory usage max's out at about 1.73GB,
but when reaching end and then traversing backwards, we get this

EDIT: If opening clip in VD2, and jumping to last frame, then traversing backwards a 1000 or so frames, all is ok,
but on swap direction and going forwards, then will OMEM again.
EDIT: Test clip is UT_Video YV12 avi.
For me it was all the same whether I used classic avs or avs+. That this specific memory size of around 1700MB was making either x86-virtualdub2 itself or the frame allocation inside avisynth to crash.

E.g. when I set memory max to 64 (which is the minimum in avs+) the internal frame caches of avs+ core were more or less keeping that limit, while the total memory consumption was way larger.

Avisynth is not able to count in the actual allocation habits of the loaded dlls and filters. In this case probably the biggest memory consumer was MFlowInter in MvTools2 (which I have optimized a bit - see mvtools2 topic). And perhaps other filters were also contributing to such memory scenario that full allocation is around 1700MB but avisynth core itself used less than 200MB.

Anyway I continue investigating the issue because I do not understand why pulling the slider back and forth still makes the script in vdub2 consume more and more memory. For earlier tests memory (task manager) still seemed to grow, though the script contained a single AviSource line.

[GMJCZP]

I have a problem with ImageWriter, when using the following script, for example:

ConverttoRGB24().ImageWriter("", 5,5, "bmp").ConvertToYV12()

I get an error with the DevIL library. I am using AVS + 2728. I never had problems with the old AVS.

[LigH]

Which is "an error"? Maybe it tells about the reason.

[pinterf]

Yep.
With my test clip (854x480@30, 3775 Frames), memory usage max's out at about 1.73GB
I checked the 32 bit vdub2 process with SysInternals vmmap. It seems that we are near 2GB with this script and parameters. As the internal caches are getting filled (until the set limit) Windows suddenly cannot allocate memory. Even when I set the max cache size to the minimum of 64MB, it could not request new memory buffer from the system after a while. Either avisynth or virtualdub - whichever is unlucky - will feel deep unhappyness and crash. So I think the problem is not avisynth related.

[StainlessS]

So I think the problem is not avisynth related.

Thank you for looking in to this P, much appreciated.

[GMJCZP]

Which is "an error"? Maybe it tells about the reason.

I am using a borrowed PC because I have not had internet for several months, so I do not remember exactly how the message says, the issue is that I can not save the frame and it is something related to DevIL. I do not know if anyone can try to recreate the error using the script.

[pinterf]

Perhaps it wants to write to c: root which is not allowed?

[StainlessS]

Perhaps it wants to write to c: root which is not allowed?

Yeh[EDIT: good catch] , possibly. Maybe try,


Colorbars
ConverttoRGB24().ImageWriter(".\", 5,5, "bmp").ConvertToYV12()


".\" is current directory, and at least it works as expected here.

EDIT: With just "" here on W7x64Avs32, I got nothing, no output and no error message, perhaps reason that you could not
remember the error message :)

EDIT: "." alone did NOT work [EDIT: Same result as ""].

[StainlessS]

EDIT: "." alone did NOT work [EDIT: Same result as ""].

Actually, I was in sub directory of D:\ drive ("D:\NewFolder"), and "." actually wrote to the root of D:\.

EDIT:
So far as I remember,
"D:" should be current directory on D drive,
"D:\" should be root directory on D drive,
"." should be current directory, current drive (also think ".\" should be same).

EDIT: Damn, forum keeps swallowing '\' characters.

EDIT: Also, ".." should be parent directory to current directory, think "..\" should be same.

EDIT:
Where below script in "D:\NewFolder\NewFolder"
This writes to root directory of D: (I think should be parent directory to current directory ie D:\NewFolder\)
Colorbars ConverttoRGB24().ImageWriter("..", 5,5, "bmp").ConvertToYV12()

This writes to D:\NewFolder (I think should be parent directory to current directory ie D:\NewFolder\)
Colorbars ConverttoRGB24().ImageWriter("..\", 5,5, "bmp").ConvertToYV12()

Something seems to be messed up somewhere, dont know if ImageWriter or Windows 7.

EDIT: Also "" should be interpreted same as "." and ".\", ie current directory.
Excepting for case where eg "D:\" specifies root directory of drive D, a trailing '\' just explicitly specifies that it is a directory
rather than a file, but "." and ".." already imply a directory where trailing "\" should be superfluous unless a node is appended after
the slash (ie another directory or file name node).

[manolito]

In one of my video conversion scripts I need to remove the station logo, for this I have been using LogoAway 4.01 by Krzysztof Wojdon for a long time. After switching to AVS+ I got random crashes using this filter, and luckily I believe I solved the issue, but it took me a long time and a lot of detective work...

My hardware and software setup first:

Core i5 3rd generation with 8GB RAM
Win7 64-bit
Avisynth+ r2728-MT 32-bit
SetMTMode.avsi from this link: http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest
StaxRip v. 1.1.9.0 (last stable 32-bit version)
X264 r2935 32-bit

I use "Prefetch(4)" with this CPU (2 physical cores plus Hyperthreading). This normally runs stable. But after getting these random crashes I first made tests to find out which filter was to blame, and it was LogoAway.

It does not happen with all sources, and sometimes the crash occurs shortly after the conversion start, sometimes it happens in the middle and sometimes at the end. I get this Windows popup that X264.exe has stopped working and must be shut down.

I am quite sure that X2364 is not to blame, I tried 3 different builds of the same release without any difference. Reducing the AVS+ threads from 4 to 2 still gave me the crashes, but this time without the Windows popup. X264 just stopped working, CPU load went down to 0, no error message.

Removing the "SetMTMode.avsi" also made no difference (except slowing down encoding speed by 0.3 fps). What did fix it of course was to disable MT altogether, and forcing MT_SERIALIZED for LogoAway also worked, but speed was not any faster than without MT.

The final solution came just by trial and error, and I really do not understand why it works. If I specify MT_MULTI_INSTANCE explicitly for LogoAway either in the conversion script or in the "SetMTMode.avsi" then the crashes miraculously disappear. This is reproduceable each and every time.

How is this possible? The docs say that MT_MULTI_INSTANCE is the default MT mode which always gets used as long as no different MT mode is explicitly specified. So it should not make a difference if I specify MT_MULTI_INSTANCE in the script or not, right? But obviously it does... :devil:

Or does AVS+ treat VDub plugins differently from other filters?
:confused:

Any thoughts?

Cheers
manolito

[pinterf]

How is this possible? The docs say that MT_MULTI_INSTANCE is the default MT mode which always gets used as long as no different MT mode is explicitly specified. So it should not make a difference if I specify MT_MULTI_INSTANCE in the script or not, right? But obviously it does... :devil:

Or does AVS+ treat VDub plugins differently from other filters?
:confused:
Just looking at the code I see that no special MT mode is set for vdub filters, so I expect them to behave as MT_MULTI_INSTANCE. I'll check it.

[pinterf]

I could not reproduce, for me it works like MT_MULTI_INSTANCE. I'd need the source clip or a short fragment with that it still crashes. And a (minimized) script itself.
Maybe it's not the filter itself which fails, just when it appears in a specific sequence.
Once I had an issue when I was debugging TIVTC for weeks because it crashed x264, then it turned out that an mvtools2 function did not clear the processors's mmx state and conflicted with x264 and it was just a coincidence that tivtc seemed to be a culprit.

[manolito]

Thanks pinterf for looking into it...

The source file I used for my tests was a huge 2 hour HD captured TV file. Please give me some time to find a smaller source which reliably crashes...

Otherwise I did not use any elaborate filters in my script. I should probably mention that for FineSharp I use old and proven versions of RemoveGrain (original by Kassandro from 2005) and MaskTools v2.0a48. Upgrading to later versions is not an option because I need to use the same scripts under WinXP with a non-SSE2 CPU.

I will report back soon...

Cheers
manolito

[wonkey_monkey]

A question about expr(), if someone can answer - when the AVX/SSE optimisations are enabled, it processes four (or more) pixels at once - is that correct? Like if you were adding the values of two clips, it would load several pixels into two SSE/AVX registers and add them together in one operation?

[GMJCZP]

Thanks for the replies pinterf and TinMan, and sorry for responding late, but I still do not have internet.

On the AVS wiki page, when you talk about ImageWriter, give this example:

# Write frame 5 to "C: \ 000005.PNG"
ImageWriter ("", 5, 5, "png")

When putting the quotes "" I always worked with the old AVS, capturing the frame and saving it in the same place in the script, no matter where in the Hard Disk it is. When placing
".\"
It works for AVS +, so my question is why the difference between AVS and AVS+?

Note: the error message varies, which does not always appear, says:

ImageWriter: error 'Could not open file' in DevIL library writing file "000005.bmp"
DevIL version 0.

Until I got an error message with strange characters, the problem is the incompatibility of "" in ImageWriter with AVS+ , but not with AVS, why?

[pinterf]

A question about expr(), if someone can answer - when the AVX/SSE optimisations are enabled, it processes four (or more) pixels at once - is that correct? Like if you were adding the values of two clips, it would load several pixels into two SSE/AVX registers and add them together in one operation?

Expr handles 2x4 pixels (XMM registers) or 2x8 pixels (AVX2) at a time. Code is generated for two sets of XMM/YMM registers unless optSingleMode=true - I introduced this parameter for curiosity, if it is any faster to use only a single register set - one lane. (Looking at the generated code of a slightly more complex expression it turned out that the registers were heavily swapped to and from temporal memory variables because the code required too many physical XMM/YMM registers but we had only a limited number of them).

Note that I added AVX2 - and not AVX - code generation to Expr, though the calculations are using 32bit floats inside. Many helper asm instructions I'm using are available only from AVX2. On the other hand, old processors with AVX-only support suffer from not having real 256 bit internally, e.g. memory access would still happen in 2x128bit mode which is sometimes slower than using 2x128bit memory load manually which can use different ports in parallel. At least for my old AVX-only i7 that was the case.

See optSSE2, optAVX2 and optSingleMode in http://avisynth.nl/index.php/Expr

EDIT:
In Avisynth+ frame alignment is 64 bytes since I added AVX2 codegen to Expr to allow the two-lane (2x256 bit YMM register) operation for 32 bit float-type inputs - and as a side effect allows painless AVX512 usage for present and future filters. Why 64 bytes? For float-type pixel input in order to use 2xYMM registers we have to read and write 512bits = 64 bytes at a time, which requires 64 byte line padding.

Later when one-lane mode (optSingleMode=true option) was put in the codegen core, it became possible to have all calculations in two-lane (2x256bit = 2x8 float pixels) mode, except the last chunk of a line which could be done either for 8 pixels (one 256 bit YMM register, like in optSingleMode=true) or 2x8 pixels (2x256bit YMM registers), depending on the source clip width. Using such an adaptive treating of the last pixels it would no longer require 64 byte alignment and line padding, because the old 32 bytes padding would have been enough, anyway I left the 64 bytes frame aligment in general thinking of the plenty future filters using AVX512.

[pinterf]

On the AVS wiki page, when you talk about ImageWriter, give this example:

# Write frame 5 to "C: \ 000005.PNG"
ImageWriter ("", 5, 5, "png")

... so my question is why the difference between AVS and AVS+?

Until I got an error message with strange characters, the problem is the incompatibility of "" in ImageWriter with AVS+ , but not with AVS, why?
Yep, avs+ worked like wiki says, but that part of wiki is wrong. "c:\" is the default value of "file" parameter if it is not provided. When file parameter is given and it's empty string it should get the current directory.

Probably when it was rewritten for avs+ from the classic avs source, they missed that special case.

EDIT: fixed the example on wiki

And yes, it should work (and now the git dev version works) like classic avisynth does.

[manolito]

I will report back soon...

Finding a shorter source which still revealed the issue was unsuccessful. On two long source files I did get the crashes during the first 10 minutes into the clip, but cutting out the first 15 minutes did not bring any results. With the cut-out sources the conversions went without problems. So the source files themselves are not to blame.

Specifying MT_MULTI_INSTANCE explicitly for the LogoAway filter again seemed to make the crashes disappear first, but on a very long source file with a length of more than 2 and a half hours the crashes did return towards the end of the clip.

My conclusion is that the LogoAway filter needs MT_SERIALZED to work reliably. Sorry for the false alarm... :o


Cheers
manolito

[pinterf]

O.K. then. By seeing the source code it could be established whether it behaves well in MT environment or not but I suppose we don't have it.

[StainlessS]

but I suppose we don't have it

I found this, dont know if he has the original source (from the VirtualDub2 thread).

by b2kguga,
I´m giving a try building a new version of LogoAway. So far, the rebuild is doing well. I´m doing it in assembly and debugging it also with my own assembler. One of the things i´m having difficulties to understand is that inside my ConfigDialog it have a call to the toggle function of Vdub.


https://forum.doom9.org/showthread.php?p=1777801#post1777801

EDIT: b2kguga last activity April 2017, so maybe a bum steer.

[GMJCZP]

Yep, avs+ worked like wiki says, but that part of wiki is wrong. "c:\" is the default value of "file" parameter if it is not provided. When file parameter is given and it's empty string it should get the current directory.

Probably when it was rewritten for avs+ from the classic avs source, they missed that special case.

EDIT: fixed the example on wiki

And yes, it should work (and now the git dev version works) like classic avisynth does.

Thanks pinterf.
What you say means that the next version of avs+ will admit "" as it does the classic avs?

[pinterf]

Thanks pinterf.
What you say means that the next version of avs+ will admit "" as it does the classic avs?
Yes, in next release.

[Reel.Deel]

I found something really cool from the AviSynth+ nekopanda fork. It is a function to output the flow of filter processing as a graph. See following pictures:

QTGMC(): https://i.imgur.com/JMWKKaO.png

SMDegrain(): https://i.imgur.com/56xKzxl.png

https://github.com/nekopanda/AviSynthPlus/blob/Neo/avs_core/core/FilterGraph.cpp

Any possibility of this filter being incorporated into Avs+? There are other features in this fork as well:
https://github.com/nekopanda/AviSynthPlus/wiki/Avisynth-Neo
https://github.com/nekopanda/AviSynthPlus/wiki/Language-New-Features

[pinterf]

Yep, I know it, I was just looking into it yesterday. Good and brave modifications, Avisynth++. Also fixed some MT problems with runtime filters which I did't understand two years ago when I tried to fix it, and since then it was forgotten.
EDIT: Yesterday I was already trying to integrate the older ScriptClip related fixes. But in general the source code of the core (caching, video frame storage and allocations, frame properties (!), threading) became so much different and reworked that now it is not easy - or maybe impossible - to simply cherry-pick only one or two features. I have to mention though that as seen on QTGMC or TemporalDegrain when using CPU-only method it consumes more memory and is a bit slower than the current Avisynth+ version (x64, Win10, i7-7770). But it's the question of time when it's getting solved.

[pinterf]

Doc updated for Overlay (http://avisynth.nl/index.php/Overlay), VarExists (http://avisynth.nl/index.php/Internal_functions#VarExists), BuildPixelType (http://avisynth.nl/index.php/Internal_functions#BuildPixelType), and ColorSpaceNameToPixelType (http://avisynth.nl/index.php/Internal_functions#ColorSpaceNameToPixelType)

[wonkey_monkey]

This is probably a silly idea and probably not worth implementing even if it isn't, but is there any way for a plugin to set global AviSynths variable that can be used in the script? I'm thinking of those parameters were numbers just won't cut it, so they have to be specified as strings - like specifying a matrix for RGB->YUV conversion.

That seems really clunky, though, so I was wondering if there was a way to do something like this:

foo(clip, quality=FOO_BILINEAR)
foo(clip, quality=FOO_BICUBIC)

with FOO_BILINEAR and FOO_BICUBIC being declared somehow a bit like enums in C++ (having values of 0, 1, etc)? I'm guessing you could do it with an accompanying .avsi script, but can a DLL plugin arrange something like that by itself? By doing something with env in its Init thingy? (I still don't really know how plugins work despite the many I've written...)

[FranceBB]

Hi Ferenc.
I personally use Avisynth+ x86 32bit (both on my x64 and on my legacy x86 32bit systems) and I rely on that due to filters compatibility/consistency.
Whenever I have to allocate more than 4GB of RAM, I use MP_Pipeline (https://forum.doom9.org/showthread.php?t=163281), but it's not that fast and it doesn't support audio.
Anyway, do you think it can be modified to support audio, improved and included inside Avisynth+ x86 32bit?
Having a better and updated version of MP_Pipeline that also supports audio would be great, especially nowadays 'cause high bit depth and high resolutions require a lot of RAM.
I know that you have many things to do before even considering this one, but it's just a hint, whenever you have time. ^^

Thank you in advance and sorry if it's not 100% related to the Avisynth+ development (you are doing a great job by the way). ^_^

[StainlessS]

David,
Some Stuff (SetVar and SetGlobalVar pretty much the same usage):-

http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API#SetGlobalVar
http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API#SaveString
https://forum.doom9.org/showthread.php?p=1572321#post1572321
https://forum.doom9.org/showthread.php?p=1843591&highlight=setVar#post1843591


If setting some kind of var (Local or Global) from within eg GetFrame, then suggest that in Constructor, check for existence of the var, and if does not exist, create it with dummy value (using env->SaveString for the variable name, so you know for sure that the name already exists when in GetFrame), also, if eg var type is string and with a known max possible size, then create dummy max size string for it and also SaveString.
In GetFrame, can then assume that var name already exists (and saved with SaveString), and so can just set value in already allocated and saved buffer.

EDIT: If using preallocated buffer, then just write to that buffer, dont SetVar, assuming that you kept address of SaveString buffer,
otherwise get the used buffer via GetVar, and extract the pointer to the buffer from the AVSValue and write to that buffer.
SaveString

virtual char* SaveString(const char* s, int length = -1);

This function copies its argument to a safe "permanent" location and returns a pointer to the new location. Each ScriptEnvironment instance has a buffer set aside for storing strings, which is expanded as needed. The strings are not deleted until the ScriptEnvironment instance goes away (when the script file is closed, usually). This is usually all the permanence that is needed, since all related filter instances will already be gone by then. The returned pointer is not const-qualified, and you're welcome to write to it, as long as you don't stray beyond the bounds of the string.


If just setting with string literals, can just save var name via SaveString,and set var with address of string literal (dont need saving),
string literals are at constant address and read only.

Saving Strings, related to SetVar;
https://forum.doom9.org/showthread.php?p=1633936#post1633936

EDIT:
ApparentFPS constructor

ApparentFPS::ApparentFPS(PClip _child,double _DupeThresh,double _FrameRate,int _Samples,double _ChromaWeight,
const char*_Prefix,bool _Show,bool _Verbose,bool _Debug,
int _Mode,int _Matrix,int _BlkW,int _BlkH,int _oLapX,int _oLapY,
IScriptEnvironment* env) :
GenericVideoFilter(_child),DupeThresh(_DupeThresh),FrameRate(_FrameRate),Samples(_Samples),
ChromaWeight(_ChromaWeight),Prefix(_Prefix),Show(_Show),Verbose(_Verbose),Debug(_Debug),
Mode(_Mode),Matrix(_Matrix),BlkW(_BlkW),BlkH(_BlkH),oLapX(_oLapX),oLapY(_oLapY) {
# ifdef AVISYNTH_PLUGIN_25
if(vi.IsPlanar() && vi.pixel_type != 0xA0000008) {
// Here Planar but NOT YV12, If v2.5 Plugin Does NOT support ANY v2.6+ ColorSpaces
env->ThrowError("ApparentFPS: ColorSpace unsupported in ApparentFPS v2.5\n");
}
# endif
num_frames = vi.num_frames;
Dif = 0.0;
AppFPS = 0.0;
MaxAppFPS = 0.0;
MaxBelowDupeDif = 0.0;
MinAboveDupeDif = 255.0;
Unique = 0;
Valid = 0;
UniqMax = 0;
LftSpan = 0;
RgtSpan = 0;
Prev_n = -666;
int i;
for(i=5;--i>=0;) VarNames[i][0]='\0';
if(*Prefix != '\0') {
char *names[5]={"ApparentFPS","MaxApparentFPS","MaxBelowDupeDif","MinAboveDupeDif","CurrentDif"};
int pfixlen=int(strlen(Prefix));
if(pfixlen>128) pfixlen=128;
for(i=5;--i>=0;) {
char * p = VarNames[i];
memcpy(p,Prefix,pfixlen);
char *d=p+pfixlen;
const char *np=names[i];
for(;*d++=*np++;); // strcat variable name part
AVSValue var = GetVar(env,p);
env->SetVar(var.Defined() ? p : env->SaveString(p),(i==3)?255.0:0.0); // Make sure name exists, init with dummy value
}
}
}



GetFrame

PVideoFrame __stdcall ApparentFPS::GetFrame(int n, IScriptEnvironment* env) {

...


if(*Prefix != '\0') {
env->SetVar(VarNames[0],AppFPS);
env->SetVar(VarNames[1],MaxAppFPS);
env->SetVar(VarNames[2],MaxBelowDupeDif);
env->SetVar(VarNames[3],MinAboveDupeDif);
env->SetVar(VarNames[4],Dif);
}

...
}


EDIT: Take NOTE that GetVar() [by Gavino] is in the 3rd link.

EDIT: Again here:

AVSValue __cdecl GetVar(IScriptEnvironment* env, const char* name) {
try {return env->GetVar(name);} catch (IScriptEnvironment::NotFound) {} return AVSValue();}


If you have any probs, post again. [EDIT: Perhaps ask a mod to move your post and this one to new thread]

EDIT:
Also AtExit function, maybe to release buffers if you allocate them for strings yourself.
http://avisynth.nl/index.php/Filter_SDK/Non-clip_sample
EDIT: Not sure, think you can forget AtExit above, I seem to remember that it is called AFTER plugins are destroyed, so may not work.
EDIT: Think maybe above wrong, plugins do still exist, its the filter graph that is already destroyed (otherwise there would be no point in the AtExit function if plugins already gone, basically dont count on any avisynth structures existing during call from AtExit).


EDIT:
Return constants rather than variables, simple really.

#include <windows.h>

#ifdef AVISYNTH_PLUGIN_25
#include "avisynth25.h"
#else
#include "avisynth.h"
#endif

AVSValue __cdecl Foo_Bilinear(AVSValue args, void* user_data, IScriptEnvironment* env) {
return "12345678"; // Constant address read only, no need to SaveString
}

AVSValue __cdecl Foo_BiCubic(AVSValue args, void* user_data, IScriptEnvironment* env) {
return "87654321";
}

AVSValue __cdecl Foo_PI(AVSValue args, void* user_data, IScriptEnvironment* env) {
return 3.1415926f;
}

AVSValue __cdecl Foo_Life(AVSValue args, void* user_data, IScriptEnvironment* env) {
return 42;
}

#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
#else
const AVS_Linkage *AVS_linkage = 0;
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
#endif
env->AddFunction("FOO_BILINEAR", "", Foo_Bilinear, 0);
env->AddFunction("FOO_BICUBIC", "", Foo_BiCubic, 0);
env->AddFunction("FOO_PI", "", "", Foo_PI, 0);
env->AddFunction("FOO_Life", "", Foo_Life, 0);
return "`DHorman Presets' DHorman plugin";
}

[wonkey_monkey]

Thanks Stainless. I think env->SetGlobalVar does what I want. Whether it's a good idea or not... well, I don't know if it will suit everyone, but I like what I can do with it and I will probably use it in filters in the future, with suitable variable names that are extermely unlikely to clash with anyone's scripts.

Another thought I had, and again it's probably a bit too odd an idea to implement, is that it'd be great if plugins could provide their own short help text. Instead of having to keep looking things up, there could be an "Explain" or "Help" function that you could call with a filter name, and it would give (thrown as an exception, perhaps) a list of its known parameters, and maybe some brief text for each one. I see that AvisynthPluginInit3 expects you to return a string, but don't know of any way to call that string up in a script.

[StainlessS]

extermely unlikely to clash with anyone's scripts.
That is not the reason for SaveString, its because Avisynth memory pool is not the same as your memory pool, and so you have to hand over control
of the string for freeing via Avisynth, and leaving Avisynth in charge of it and responsible for the freeing of the memory block. (otherwise memory leaks).
[Above incase you meant that you were not gonna bother with SaveString].

I have never seen the string returned by AvisynthPluginInit2/3 used by anything (with possible exception of AvsEdit, not sure if it used it, and perhaps AvsPMod does too). [EDIT: At least one plugin (dont remember which) returns 0 where it should return that string, so a program trying to access it as a string might cause a system exception/access violation]

I guess that some kind of simple (even script) function could be knocked up to show doc text on video clip,
would need (how I see it) an RT_Stats DBase with eg string name of function, and string name of a txt file on hard drive.
Look for name of function in DBase, if not found then error.
Else read in associated string filename from DB, and read text from doc file, and RT_Subtlte as in the RT_Stats subtitle demo in the avs folder of RT_Stats.

So would use something like return Man("amp").

Demo From RT_Stats using RT_Subtitle (In the AVS directory).

RT_SCROLLDEMO.avs (will open fileselector, you choose an avi file, and then a text file and it will display that text upon the avi).

avi = RT_FSelOpen("Please select an AVI file",Filt="*.AVI|*.AVI")
Assert(avi.IsString,"RT_FSelOpen: Error="+String(avi))
AVISource(AVI)
txt = RT_FSelOpen("And now select a Text file",Filt="*.txt|*.txt")
Assert(txt.IsString,"RT_FSelOpen: Error="+String(txt))
Txt=RT_ReadTxtFromFile(txt)
Lines=RT_TxtQueryLines(Txt)
# config
DELAY=100
ALIGN=1 # As Numeric KeyPad
SCROLL=0 # 0 = Upwards : 1 = Downwards : 2 = Right to Left : 3 = Left to right : 4 = Karaoke
#
ORG=Last
Last=(SCROLL==4)? ORG.Blankclip(height=80) : Last
CMD_0 = """RT_Subtitle("%s",Txt,align=ALIGN,y=height+DELAY-current_frame,expx=true,expy=true)"""
CMD_1 = """RT_Subtitle("%s",Txt,align=ALIGN,y=-(Lines*20+DELAY) + current_frame,expx=true,expy=true)"""
CMD_2 = """RT_Subtitle("%s",Txt,align=ALIGN,x=width+DELAY-current_frame,expx=true,vcent=true)"""
CMD_3 = """RT_Subtitle("%s",Txt,align=ALIGN,x=-(width+DELAY)+current_frame,expx=true,vcent=true)"""
CMD_4 = """RT_Subtitle("%s",Txt,align=ALIGN,y=height+DELAY-current_frame,expx=true,expy=true)"""
CMD_5 = """RT_Subtitle("BAD SCROLL COMMAND (0->4)")"""
CMD = (SCROLL<0 || SCROLL>4) ? CMD_5 : Select(Scroll,CMD_0,CMD_1,CMD_2,CMD_3,CMD_4)
ScriptClip(CMD)
Return (SCROLL==4)? StackVertical(ORG,Last) : Last


EDIT: I guess that you could even eg open notepad and feed it the doc text file.
Doc files could actually be stored as string in a DB, but strings are of fixed max size and so might have to allocate eg 64KB (in DB) each, even for tiny doc files.

EDIT: Even script functions could be stored in DBase, and an Eval/GScript would implant them in current script.
EDIT: For the man thing, could even have a DBase of DBase Names, where each sub DBase record might hold eg an argument name as string, and min value, max value, and some short (eg 1KB) description of the arg. (perhaps more)

EDIT: Each DBase, also has 10 user string attributes (Max 1024 len) for whatever you wish, and 1024 Int or Float user attributes, again for whatever
you want, perhaps link to website download or whatever [for StringUserAttrib(0)], and version number for Float UserAttrib(0).

[goorawin]

Hi Ferenc.
I personally use Avisynth+ x86 32bit (both on my x64 and on my legacy x86 32bit systems) and I rely on that due to filters compatibility/consistency.
Whenever I have to allocate more than 4GB of RAM, I use MP_Pipeline (https://forum.doom9.org/showthread.php?t=163281), but it's not that fast and it doesn't support audio.
Anyway, do you think it can be modified to support audio, improved and included inside Avisynth+ x86 32bit?
Having a better and updated version of MP_Pipeline that also supports audio would be great, especially nowadays 'cause high bit depth and high resolutions require a lot of RAM.
I know that you have many things to do before even considering this one, but it's just a hint, whenever you have time. ^^

Thank you in advance and sorry if it's not 100% related to the Avisynth+ development (you are doing a great job by the way). ^_^

You can add audio to pipeline by adding it outside the pipeline script, so why would you bother including it within the script?

[manolito]

After using AVS+ for a few months on my Core i5 (two physical cores plus hyperthreading) I decided to revert back to AviSynth 2.61 Alpha.

I don't have any use for high bit depth and all the new fancy color spaces. I also cannot use the 64-bit version because I absolutely need to use some 32-bit plugins. All I wanted was a speed boost by using MT modes for my AVS plugins, but I was quite disappointed.

My main sources are captured HD files in the HEVC format. My source filters are DSS2Mod and ffms2 (I do not like LSMASH, and I cannot use DGDecNV). And for both source filters the decoding speed is unacceptable with these HEVC sources.

With DSS2Mod the speed tends to be OK at the start, but after a while the speed drops to a snail's pace. With ffms2 it is even worse, speed is about one tenth compared to disabling MT.

With AVS+ the solution is to disable MT, but why would I want to do this? Under AviSynth 2.61 Alpha I get even better speed.


Cheers
manolito

[ChaosKing]

Maybe the bottleneck is the hdd (cache is full)? How huge are the files?

You can combine 64bit with 32bit filters (and speed up things) with MP_Pipeline: https://forum.doom9.org/showthread.php?t=163281

[FranceBB]

You can add audio to pipeline by adding it outside the pipeline script, so why would you bother including it within the script?

I could, but if there's a framerate conversion in-between my filter-chain, it would be out of sync.

[wonkey_monkey]

Bug? When calling extracttoy on a Y8 clip, AviSynth+ complains that there are no chroma channels.

Edit: also minor cosmetic issue: colorbars with pixel_types YV12 and YV24 do not line up exactly. I'm guessing because the bars have to align with chroma subsampling in the YV12 case, but (if someone was so inclined) I would suggest YV24 should be forced to do the same for consistency (with 4:2:0 and 4:1:1 as well), even though it isn't subsampled.

[pinterf]

Bug? When calling extracttoy on a Y8 clip, AviSynth+ complains that there are no chroma channels.

It was fixed on git but not released yet.

[Groucho2004]

It was fixed on git but not released yet.Any chance you'd put a new release under our trees before the holidays?

[pinterf]

Any chance you'd put a new release under our trees before the holidays?
Probably yes.

[Groucho2004]

Probably yes.Cool, thanks.

[Dogway]

Try dfttest(sigma=2, lsb=true) with MT mode 2 and check if it fails. It might be dfttestMC problem.

I have some issues with your build (actually all builds but your explcitly since is the most up to date).
I get "illegal instruction" message. Using:
Setfiltermtmode("dfttest", 2)
or with/without Prefetch(4), in avs+ x64, so far the only plugin that doesn't work (well wishing SoundOut and ClipClop as well). I'm using libfftw3f-3.dll from fftw338-x64-AVX2 though.

[pinterf]

O.K., it's been a long time since I released any update here, no big things included, only a new build. A sort of a maintenance release.

Download Avisynth+ r2768-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2768-MT)

The files-only section also contains an x86 build for SSE-only processors.

This release features an interesting language extension: inline assignments, contributed by a new fellow developer addewyd.

Enjoy.

# Avisynth+ r2768 (20181218)
https://forum.doom9.org/showthread.php?t=168856

- New: Expr: allow input clips to have more planes than an implicitely specified output format
Expr(aYV12Clip, "x 255.0 /", format="Y32") # target is Y only which needs only Y plane from YV12 -> no error
- New: Expr: Y-plane-only clip(s) can be used as source planes when a non-subsampled (rgb or 444) output format implicitely specified
Expr(Y, "x", "x 2.0 /", "x 3.0 /", format="RGBPS") # r, g and b expression uses Y plane
Expr(Grey_r, Grey_g, Grey_b, "x", "y 2.0 /", "z 3.0 /", format="RGBPS") # r, g and b expression uses Y plane
- Fix: ConvertToYUY2() error message for non-8 bit sources.
- Fix: Y32 source to 32 bit 420,422,444 (introduced in the zero-chroma-center transition project)
- Fix: ShowY, ShowU, ShowV crash for YUV (non-YUVA) sources
- Speedup: ConvertToY12/16... for RGB or YUY2 sources where 4:4:4 or YV16 intermediate clip was used internally
(~1.5-2x speed, was a regression in Avs+, use intermediate cache again)
- Fix: Allow ExtractY on greyscale clips
- ImageReader/ImageSource: use cache before FreezeFrame when result is a multiframe clip (fast again, regression since an early AVS+ version)
- Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces
- Fix: Histogram 'classic': rare incomplete histogram shown in multithreading environment
- Fix: ImageReader and ImageWriter: if path is "" then it works from/to the current directory.
- GeneralConvolution: Allow 7x7 and 9x9 matrices (was: 3x3 and 5x5)
- GeneralConvolution: All 8-32 bit formats (was: RGB32 only): YUY2 is converted to/from YV16, RGB24/32/48/64 are treated as planar RGB internally
Since 32 bit float input is now possible, matrix elements and bias parameter now is of float type.
For 8-16 bit clips the matrix is converted to integer before use.
- GeneralConvolution: Allow chroma subsampled formats to have their luma _or_ chroma processed. E.g. set chroma=false for a YV12 input.
- GeneralConvolution: new parameters: boolean luma (true), boolean chroma(true), boolean alpha(true)
Default: process all planes. For RGB: luma and chroma parameters are ignored.
Unprocessed planes are copied. Using alpha=false makes RGB32 processing faster, usually A channel is not needed.
- GeneralConvolution: MT friendly parameter parsing
- New: UTF8 filename support in AviSource, AVIFileSource, WAVSource, OpenDMLSource and SegmentedAVISource
All functions above have a new bool utf8 parameter. Default value is false.
- Experimental: new syntax element (by addewyd): assignment operator ":=" which returns the assigned value itself.
(Assignment within an expression)
Examples:
w := h := 256

b := blankclip(width=w * 2, height = h * 3, length=40, pixel_type="yv12")
bm = blankclip(width=w, height = w).letterbox(2,0,2,0, color=$ff)
b

for(j = 0, 1, 1) {
for(i = 0, 1, 1) {
e = 0 + i * 16 + j * 16 * 4
ce = string(e)
c = bm.subtitle("Y = 0x" + hex(e) + " " + ce)
eval("c" + string(i) + string(j) + " := c")
b := b.overlay(c, x = i * w, y = j * h)
}
}

cx = c00.trim(0, 9) + c01.trim(0, 9) + c10.trim(0, 9) + c11.trim(0, 9)

b := overlay(cx, x = 0, y = w * 2)

/* defined NEW_AVSVALUE at build */
array = [99, 101, "303", cnt := 4]

for(j = 0, cnt - 1, 1) {
b := subtitle(string(array[ind := j]), x = 100, y=(j+1) * 20)
}

g := b.tstfunc(kf := "first", ks := "second")

g := subtitle((s := 4) > 0 ? t := "left" : t := "right", y = 100)
g := subtitle(string(s) + " " + t + " " + ks, y = 150)

eval("""h := g.subtitle("G", x=200, y = 20)""")

h.subtitle("H " + string(ind), x = 300, y = 20)


function tstfunc(c, d, e) {
if (f := 1 < 2) {
c.subtitle(string(f) + e, y = 50)
} else {
c.subtitle(d, y = 50)
}
}

[FranceBB]

Thank you very much indeed for the Christmas present! :D

[magiblot]

# Avisynth+ r2768 (20181218)
https://forum.doom9.org/showthread.php?t=168856

- New: Expr: allow input clips to have more planes than an implicitely specified output format
Expr(aYV12Clip, "x 255.0 /", format="Y32") # target is Y only which needs only Y plane from YV12 -> no error
- New: Expr: Y-plane-only clip(s) can be used as source planes when a non-subsampled (rgb or 444) output format implicitely specified
Expr(Y, "x", "x 2.0 /", "x 3.0 /", format="RGBPS") # r, g and b expression uses Y plane
Expr(Grey_r, Grey_g, Grey_b, "x", "y 2.0 /", "z 3.0 /", format="RGBPS") # r, g and b expression uses Y plane
- Fix: ConvertToYUY2() error message for non-8 bit sources.
- Fix: Y32 source to 32 bit 420,422,444 (introduced in the zero-chroma-center transition project)
- Speedup: ConvertToY12/16... for RGB or YUY2 sources where 4:4:4 or YV16 intermediate clip was used internally
(~1.5-2x speed, was a regression in Avs+, use intermediate cache again)
- ImageReader/ImageSource: use cache before FreezeFrame when result is a multiframe clip (fast again, regression since an early AVS+ version)


:thanks: :goodpost: :D

[pinterf]

Thank you for the precious (my precious :) - just have finished re-reading the lotr books) bug reports and the patience and the thanks giving.

[wonkey_monkey]

Thanks for all the work you do!

[StainlessS]

+1 on that. Yes, thank you my perfectly precious Pinterf. :)
I just watched all three Hobbits
(standard versions only, not sure if there are extended versions,
I only got extended in LOTR, me loves the Faceless & Accursed one [always brings to mind TheFluff for some reason]).

[Sparktank]

And just like that, it started to snow.
The who's in whoville started to sing!

Thanks for the update!

[LigH]

Are you a Whovian?

[Sparktank]

Are you a Whovian?

I LOVE Doctor Who!
Still need to catch up to current season and then check out the older series before the 2005 revamp.

Back on topic, loving all these updates.
It's even nicer seeing older plugins get updated for AVS+.

With all this, I can delay learning python language for VS a bit longer. :p

[pinterf]

New build, Expr fixes. I hope.

Download Avisynth+ r2772-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2772-MT)


20181220 r2772
--------------
- Fix: Expr: possible Expr x64 crash under specific memory circumstances
- Fix: Expr: safer code for internal variables "Store and pop from stack" (see: Internal variables at http://avisynth.nl/index.php/Expr)

In the x64 stack frame generation, address calculation was truncated to 32 bits when AVX2 registers were to be saved. Caused C0000005 Access Violation.

The second fix is a precaution, (generating code for the A^ syntax for 'store and pop' operation of internal variables), did not caused any troubles yet, I fixed it anyway.

[Dogway]

Does someone know if there's an alternative to SoundOut() for avs+ x64? It's a basic tool I use very oftenly (currently) to do edits/filtering to audio without having to create intermediary WAV files. I tried BatchEncoder and similar and they don't work fine.

[LigH]

IIRC, avs2pipemod has a switch to deliver the audio part instead of the video part of the AviSynth output, to feed audio encoders (e.g. QAAC) instead of video encoders.

Even several:

>avs2pipemod64.exe
avs2pipemod ver 1.1.1
built on Aug 15 2016 00:32:12

Usage: avs2pipemod [option] input.avs
e.g. avs2pipemod -wav=24bit input.avs > output.wav
avs2pipemod -y4mt=10:11 input.avs | x264 - --demuxer y4m -o tff.mkv
avs2pipemod -rawvideo -trim=1000,0 input.avs > output.yuv

-wav[=8bit|16bit|24bit|32bit|float default unset]
output wav format audio(WAVEFORMATEX) to stdout.
if optional arg is set, audio sample type of input will be converted
to specified value.

-extwav[=8bit|16bit|24bit|32bit|float default unset]
output wav extensible format audio(WAVEFORMATEXTENSIBLE) containing
channel-mask to stdout.
if optional arg is set, audio sample type of input will be converted
to specified value.

-rawaudio[=8bit|16bit|24bit|32bit|float default unset]
output raw pcm audio(without any header) to stdout.
if optional arg is set, audio sample type of input will be converted
to specified value.
...

[tebasuna51]

@Dogway
If you need some avs edits/filtering than can't be done with BatchEncoder or similar, and use avs+ 64 bits you can use avs2pipemod64 (like LigH say).

Also MeGUI (if you want a GUI instead command line) and ffmpeg (recommended to encode to AC3 directly) 64 bits can accept .avs inputs.

[Dogway]

Yes, I was already investigating that. I was getting CoreAudioToolBox errors for qaac so I had to do that crazy setup (https://forum.doom9.org/showthread.php?p=1831213#post1831213) with the makeportable.cmd, now it complains about invalid input format so it must be a problem with my avs2pipemod64 line.
avs2pipemod[info]: writing 48915.400 seconds of 44100 Hz, 2 channel audio.
ERROR: Not available input file format

"%PIPER%" -rawaudio "%INPUT%"| "%ENCODER%" --tvbr %QUALITY% --ignorelength --no-optimize - -o "%OUTPUT%"


edit: worked if I added --raw and removed --ignorelength
"%PIPER%" -rawaudio "%INPUT%"| "%ENCODER%" --raw --tvbr %QUALITY% --no-optimize - -o "%OUTPUT%"

[wonkey_monkey]

converttoy8 is broken when converting from bit depths other than 8:

version.convertbits(16).converttoy8
version.converttoyv12.convertbits(12).converttoy8


https://i.imgur.com/nZrFmoH.png

[pinterf]

Thanks. Seems that it's not guarded by an error message to allow only 8 bit sources. Based on the upside down result, it simply runs on the 8 bit packed rgb case.

[wonkey_monkey]

Me again...

colorbars returns a clip with alpha set to 255 with pixel_type="RGBAP8", but with pixel_type="RGB32", alpha is set to 0.

[tebasuna51]

@Dogway

Try:

"%PIPER%" -extwav=24bit "%INPUT%"| "%ENCODER%" --tvbr %QUALITY% --ignorelength --no-optimize -o "%OUTPUT%" -

All encoders need wav header to know samplerate, bit depth, number of channels and mask

[nu774]

qaac supports avisynth directly, so you don't have to pipe from avs2pipemod (use qaac64.exe for 64bit Avisynth+).

[LigH]

It was just an example of an encoder that always worked, even before it supported AviSynth natively.

[tebasuna51]

qaac supports avisynth directly...

Yep, seems it work ok.

But I can see nothing in qaac docs. Only a reference to Apple AudioFile services (https://github.com/nu774/qaac/wiki/About-input-format)

[wonkey_monkey]

Is there any in-depth documentation for env->AddFunction anywhere? I seem to remember there are some rules on using + to allow a variable-sized list of parameters but I can't remember what they are, and no matter what I try I either get an "Invalid parameters" error or my extra parameter gets assigned to the first unspecified named parameter.

[StainlessS]

Post what you are trying.
I had one helluva time trying to get Prune() to work (got coerced into retrying and it eventually all worked ok, still no idea what it was I was doing wrong, starting again from scratch and everything worked perfectly).

Pretty much everything known is below [NOTE, we used i*, ie zero or more ints, if using i+ then requires at least 1 arg in array else error]

// The following function is the function that actually registers the filter in AviSynth
// It is called automatically, when the plugin is loaded to see which functions this filter contains.
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
env->AddFunction("FrameSel", "ci*[SCmd]s[Cmd]s[Show]b[Ver]b[Reject]b[Ordered]b[Debug]b[Extract]i", Create_FrameSel, 0);

// The AddFunction has the following paramters:
// AddFunction(Filtername , Arguments, Function to call,0);

// Arguments is a string that defines the types and optional nicknames of the arguments for you filter.
// 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

return "`FrameSel' FrameSel plugin";
// A freeform name of the plugin.
}


Some stuff ripped from various FRAMESEL routines

// from creator function
AVSValue Frames = args[1]; // Frames, Array of frame numbers as filter arguments


// from Frames, CMD, SCMd parser
bool ProcFrames = (Frames.ArraySize()!=0);

if(ProcFrames) {
int nFrms = Frames.ArraySize();
if(Pass==0) {
OutFrameCount += nFrms;
} else {
int i;
for(i=0;i<nFrms; ++i) {
int frm=Frames[i].AsInt();
if(frm < 0 || frm >= NumFrames) {
if(fp) {fclose(fp); fp=NULL;}
if(FrameDat) {delete[] FrameDat; FrameDat = NULL;}
env->ThrowError("%s*ERROR* filter arg frames[%d]=%d, out of clip.\n",myName,i+1,frm);
}
if(RunOff < OutFrameCount) {
FrameDat[RunOff]=frm;
}
++RunOff;
}
}
} // End, ProcFrames



EDIT:
I seem to remember there are some rules on using +
Yep, you need use eg i* rather than i+, probably.
EDIT: Further args immediately following eg 'i*' must NOT be of type int (will be swallowed by the i* Array, I think,
unless using named arg, eg nextInt=NextInt where "i*[nextint]i").
If using ".*[nextint]i" (zero or more variables of any type), then MUST (I think) use named arg ie nextInt=NextInt.
I have to use eg Append=True/False in eg RT_WriteFile as all args before the Optional Append Arg are of variable type and number.

EDIT:

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



AVSValue __cdecl RT_WriteFile(AVSValue args, void* user_data, IScriptEnvironment* env) {
char *myName="RT_WriteFile: ";
const char *ofn = args[0].AsString();
const char *fmt = args[1].AsString();
AVSValue datn = args[2]; // data
const bool append = args[3].AsBool(false);

int arrsz = datn.ArraySize();

enum {
CHICKEN=64
};

// what size buffer we need ?
int i,mem=int(strlen(fmt) + 1 + CHICKEN);
for(i=0;i<arrsz;++i) {
if(datn[i].IsString()) {
const char *st=datn[i].AsString();
mem += int(strlen(st) + 1 + CHICKEN);
} else {
mem += 8 + CHICKEN; // no particular reason why so big, just chicken factor.
}
}

char *pbuf = new char[(mem+1)*2];
if(pbuf==NULL)
env->ThrowError("%sCannot allocate memory",myName);

char *ptem=pbuf+(mem+1); // temp buffer

const unsigned char* r= (const unsigned char*)fmt;
char *p=pbuf;
int c,ix=0;
int t=0;

// Parse text and insert variables
while(c=*r) {
if(c=='%') {
++r;
if(*r=='\0') {
*p++ ='%';
} else if(*r=='%') {
*p++=*r++; // replace escaped double % with single
} else {
if(ix>=arrsz) {
delete [] pbuf;
env->ThrowError("%sExpecting data arg (%d)",myName,ix+1);
}
char *tp=ptem;
*tp++='%';
if(*r=='-' || *r=='+' || *r=='0' || *r==' ' || *r=='#') // flags
*tp++=*r++;
if(*r=='*') { // int holds length
t=datn[ix].IsBool() ?1: \
datn[ix].IsString() ?2: \
datn[ix].IsInt() ?3: \
datn[ix].IsFloat() ?4: \
0;
if(t!=3) {
delete [] pbuf;
env->ThrowError("%sUnsupported data type, Expecting Width as Int (%d)",myName,ix+1);
}
tp+=sprintf(tp,"%d",datn[ix].AsInt());
++r; // skip '*'
++ix; // next data
} else {
while(*r>='0' && *r<='9') {
*tp++ = *r++;
}
}
if(*r=='.') {
*tp++ = *r++; // precision prefix
if(*r=='*') { // int holds length
t=datn[ix].IsBool() ?1: \
datn[ix].IsString() ?2: \
datn[ix].IsInt() ?3: \
datn[ix].IsFloat() ?4: \
0;
if(t!=3) {
delete [] pbuf;
env->ThrowError("%sUnsupported data type, Expecting Precision as Int (%d)",myName,ix+1);
}
tp+=sprintf(tp,"%d",datn[ix].AsInt());
++r; // skip '*'
++ix; // next data
} else {
while(*r>='0' && *r<='9') {
*tp++ = *r++;
}
}
}
t=datn[ix].IsBool() ?1: \
datn[ix].IsString() ?2: \
datn[ix].IsInt() ?3: \
datn[ix].IsFloat() ?4: \
0;
// type
if( (*r=='c' ) || (*r=='C' ) || // char as int
(*r=='d' || *r=='i') || // int
(*r=='o' || *r=='u' || *r=='x' || *r=='X')) { // unsigned int
if(t!=3) {
int tmpc=*r;
delete [] pbuf;
env->ThrowError("%sType='%c', Expecting Int data (%d)",myName,tmpc,ix+1);
}
*tp++=*r++;
*tp='\0';
p+=sprintf(p,ptem,datn[ix].AsInt());
++ix; // next data
} else if(*r=='e' || *r=='E' || *r=='f' || *r=='g' || *r=='G') { // double
if(t!=4&&t!=3) {
int tmpc=*r;
delete [] pbuf;
env->ThrowError("%sType='%c', Expecting Float (%d)",myName,tmpc,ix+1);
}
*tp++=*r++;
*tp='\0';
p+=sprintf(p,ptem,datn[ix].AsFloat());
++ix; // next data
} else if((*r=='s')||(*r=='S')) { // string
if(t!=2&&t!=1) {
delete [] pbuf;
env->ThrowError("%sType='s', Expecting String (%d)",myName,ix+1);
}
*tp++=*r++;
*tp='\0';
if(t==1) { // Bool
p+=sprintf(p,ptem,datn[ix].AsBool()?"True":"False");
} else { // String
p+=sprintf(p,ptem,datn[ix].AsString());
}
++ix; // next data
} else {
int tmpc=*r;
delete [] pbuf;
env->ThrowError("%sUnknown format type '%c' (%d)",myName,tmpc,ix+1);
}
}
} else 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;
case 'r' : ++r; *p++='\r'; break;
case 't' : ++r; *p++='\t'; break;
case 'v' : ++r; *p++='\v'; break;
case 'f' : ++r; *p++='\f'; break;
case 'b' : ++r; *p++='\b'; break;
case 'a' : ++r; *p++='\a'; break;
default : *p++='\\'; *p++=*r++; break; // anything else we copy backslash and whatever follows
}
} else {
*p++=*r++;
}
}
*p=0; // nul term

if(ix<arrsz) {
delete [] pbuf;
env->ThrowError("%sUnexpected data arg (%d)",myName,ix+1);
}

char *omode=(append)?"a+t":"wt";
FILE * fp;
// we use write in text mode, let C insert '\r'.
if((fp=fopen(ofn, omode ))==NULL) { // Cannot output file
delete [] pbuf;
return -1;
}
int lines = 0;
char *s,*is;
s=is=pbuf;;
do {
c=*s;
if(c=='\n' || c=='\r' || c == '\0') {
if(is<s) {
if(fwrite(is,s-is,1,fp)!=1) {
delete [] pbuf;
fclose(fp);
return -1; // write file error
}
}
if(c=='\n') {
++s;
if(*s=='\r')
++s;
} else if(c=='\r') {
++s;
if(*s=='\n')
++s;
}
if(is<s) {
if (fputc('\n',fp)==EOF) {
delete [] pbuf;
fclose(fp);
return -1; // write file error
}
++lines;
}
is=s;
} else {
++s;
}
} while (*is); // !!! Exit when 1st char in string is end
delete [] pbuf;
fclose(fp);
return lines;
}

[wonkey_monkey]

I think I figured it out. f* has to go before any named parameters, otherwise if you try to include the array after the use of a named parameter, it tries to assign those numbers to other, unused named parameters. Or something like that.

[gaak]

I'm looking for a 64 bit version of tritical's TBilateral. Is there a thread for this? Or to make a request for one?

[wonkey_monkey]

The source code for TBilateral includes inline assembly which isn't supported for x64 (in Visual Studio, anyway), so you might be out of luck unless someone wants to rewrite it.

[StainlessS]

I think I figured it out. f* has to go before any named parameters, otherwise if you try to include the array after the use of a named parameter, it tries to assign those numbers to other, unused named parameters. Or something like that.

Just as with avs script Functions, optional named args follow after compulsory un-named args[EDIT: un-named in plugin, obviously cannot have un-named args in script funcs], and once you have a single optional arg, then all following ones must also be optional. (otherwise weird things could happen in plugin, script function would complain about it, I think)

EDIT: David, me just got back from shop (Lidl) and trying out the Tio Nico sherry (for my damn cough), its quite lovely and unexpectedly flavoured with raisins and treacle, very dark flavour, never tasted a sherry like it I think. Less than six quid, and easily worth double that. [EDIT: In Waitrose, it is double that]

[Groucho2004]

I'm looking for a 64 bit version of tritical's TBilateral.Added to my plugin collection (https://forum.doom9.org/showthread.php?t=173259)

[wonkey_monkey]

Just curious, but what is it about info() that seems to make it really slow? Showframenumber seems similarly slow, but subtitle isn't. Is that because subtitle renders the text once and only has to composite it onto each frame? Is text rendering really that slow?

Info's speed also seems to depend greatly on video size. Is it possibly missing some optimisations to do with compositing extent?

[StainlessS]

what is it about info() that seems to make it really slow? Showframenumber seems similarly slow, but subtitle isn't. Is that because subtitle renders the text once and only has to composite it onto each frame? Is text rendering really that slow?

Info's speed also seems to depend greatly on video size. Is it possibly missing some optimisations to do with compositing extent?

Subtitle fixed text, requires prepping one time only (prior to frame serving, ie in constructor), ShowFrameNumber() or Info() (frame number and time) require prepping at each GetFrame [EDIT: Calling Subtitle Constructor in each and every frame, with big overhead].
Prepp'ing, calls some system function (probably via ApplyMessage) to find size of Subtitle for font etc, (together with eg kerning of each character), and that part is slow. Also, depending upon size of subtitle string, and size of clip, so subtitle may also have to be resized to fit clip (for eg alert error box).

For any kind of plugin metrics output, Subtitle is a slow option and best avoided, see Info.h, or perhaps even DDigit, although neither of them will work in non 8 bit colorspaces.

EDIT: Current Info.h was refactored by IanB most recently about May 2013, (may require a couple of simple warnings fixes for x64 compile).
Info.h available in ClipClop source[with any required x64 warning fixed], if you cannot find it elsewhere. [pre IanB refactored versions have several bugs]

EDIT: More bout it here:- https://forum.doom9.org/showthread.php?t=175443

Info.h and DDigit are lots faster than Subtitle [Fixed monospace font, 10x20 pixels, DDigit also uses Info.h font].
EDIT: IanB refactored Info.h is both font and code, DDigit uses Info.h font only[renamed], the code part being removed.

[wonkey_monkey]

Another development question:

Is setting the following:

vi.audio_samples_per_second
vi.nchannels
vi.sample_type
vi.num_audio_samples

sufficient and complete for setting a clip's audio properties?

[Groucho2004]

Another development question:

Is setting the following:

vi.audio_samples_per_second
vi.nchannels
vi.sample_type
vi.num_audio_samples

sufficient and complete for setting a clip's audio properties?Yes. I also use these in AVSMeter.

[wonkey_monkey]

Thanks Groucho.

[tebasuna51]

Better than nchannels is maskchannels to define a audio clip.

[StainlessS]

From Avisynth.h [version 6]

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int nchannels; // as of 2.5


For some things, is handy to have access to v2.58 avs header (AVISYNTH HEADER = 3) for the BAKED CODE rather than from function call.
(The v2.60 FINAL Compressed Help [*.chm] file available from my MediaFire Account DATA Folder, has both Avisynth v2.60 final and v2.58 baked code
headers available from the HTML table of files).
https://i.postimg.cc/k2mHvBWt/chm.png (https://postimg.cc/k2mHvBWt)

EDIT: From BAKED CODE in V2.58 header (Source Not available in Version 6 header)

// useful functions of the above
bool HasVideo() const { return (width!=0); }
bool HasAudio() const { return (audio_samples_per_second!=0); }



EDIT:
Internal functions, Global Options:- http://avisynth.nl/index.php/Internal_functions#Global_Options
OPT_dwChannelMask

global OPT_dwChannelMask(int v) v2.60
This option enables you to set ChannelMask. It overrides WAVEFORMATEXTENSIBLE.dwChannelMask[[2] which is set according to this table

0x00004, // 1 -- -- Cf
0x00003, // 2 Lf Rf
0x00007, // 3 Lf Rf Cf
0x00033, // 4 Lf Rf -- -- Lr Rr
0x00037, // 5 Lf Rf Cf -- Lr Rr
0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs

[tebasuna51]

global OPT_dwChannelMask(int v) v2.60

Is a usseless option.

Who know the ChannelMask of a audio are the decoders, do you know any decoder (ffms2.dll, LSMASHSource.dll, NicAudio.dll, ...) than set ChannelMask to the appropiate value?

There are any audio encoder/player, than accept avs input, than use that global variable if defined?

Also, if there are two, or more, audios processed at same time, how we can distinguise both?

The ChannelMask must be a property of each audio clip.

[StainlessS]

OPT_AllowFloatAudio
OPT_UseWaveExtensible
OPT_dwChannelMask

Are optionally set to signal info to eg MPC-HC and VDub2. [Not sure if VD2 supports FloatAudio, old VDub did not, but MPC-HC does]

Is a usseless option.

Makes one wonder why they were implemented then.

Also, if there are two, or more, audios processed at same time, how we can distinguise both?
Dont think AVI (and therefore AVS) generally support more than 1 audio stream, so the problem does not often arise.
[VDub does have some code connected to multiple audio streams, but I aint ever seen more than 1 used, also dont know if fully implemented in VDub].

[Groucho2004]

Another development question:

Is setting the following:

vi.audio_samples_per_second
vi.nchannels
vi.sample_type
vi.num_audio_samples

sufficient and complete for setting a clip's audio properties?
I just noticed that you wrote "setting a clip's audio properties" (as opposed to getting). The answer is still yes. "KillAudio()" for example sets all 4 to 0, effectively removing the audio from a clip.

[FranceBB]

Don't think AVI (and therefore AVS) generally support more than 1 audio stream, so the problem does not often arise.

Yep, you're right, Avisynth always outputs a single audio stream of x channels, which is why whenever I have two languages (like CH.1-2 Stereo Full Mix German - CH.3-4 Stereo Full Mix English) I index them both, then use MergeChannels to make a single audio stream with 4 channels and then I specify how to divide them and encode them separately to the encoder.

[wonkey_monkey]

Before I go ahead and do this, can anyone raise any objections to the idea of using an audio channel to pass metadata? My filter passes data through the video frame, but it also needs to send a few bytes of metadata with it, so my plan is to override GetAudio and just paste those bytes into the buffer. The other filter in the partnership will then call GetAudio to get the metadata.

Good idea? Bad idea?

[DJATOM]

Indeed it's a bad practice. In Vapoursynth we can pass external metadata with frame properties, but avisynth lacks that functionality. As workaround you probably can add external metadata as hints, like it was implemented in the TIVTC filters.

[wonkey_monkey]

In what sense is it bad practice? I mean, I'm already "abusing" the video frame by passing non-video data (although it is pixel-to-pixel related, more or less). I don't think that there being a more formal alternative which Avisynth+ doesn't have is really an objection, per se.

What are hints, and how are they implemented?

[pinterf]

Nekopanda fork (Avisynth Neo a.k.a Avs CUDA) implemented frame properties.

[StainlessS]

What are hints, and how are they implemented?

Dont know much about this (I'm sure someone will correct if wrong), but think that the hints are 64 bits encoded in LSB (Least Significant Bit) of the top LHS row of 64 pixels. [what they represent, I dont know, I guess is implementation defined (maybe in luma channel only, dont know)].

EDIT: Methinks that DGIndex embeds some hint stuff, maybe see source. (also TFM I think).

EDIT: Here from DGindex source (looks like only storing 32 bits of colorimetry data there [with additional 32 bits of magic number to signify valid hint]).

Utilities.h

bool PutHintingData(unsigned char *video, unsigned int hint);
bool GetHintingData(unsigned char *video, unsigned int *hint);

#define HINT_INVALID 0x80000000
#define PROGRESSIVE 0x00000001
#define IN_PATTERN 0x00000002
#define COLORIMETRY 0x0000001C
#define COLORIMETRY_SHIFT 2


Utilities.cpp


#include <windows.h>

#define MAGIC_NUMBER (0xdeadbeef)

bool PutHintingData(unsigned char *video, unsigned int hint)
{
unsigned char *p;
unsigned int i, magic_number = MAGIC_NUMBER;
bool error = false;

p = video;
for (i = 0; i < 32; i++)
{
*p &= ~1;
*p++ |= ((magic_number & (1 << i)) >> i); // 1st 32 bits of Magic number validity flag
}
for (i = 0; i < 32; i++)
{
*p &= ~1;
*p++ |= ((hint & (1 << i)) >> i); // 2nd 32 bits of colorimetry data
}
return error;
}

bool GetHintingData(unsigned char *video, unsigned int *hint)
{
unsigned char *p;
unsigned int i, magic_number = 0;
bool error = false;

p = video;
for (i = 0; i < 32; i++)
{
magic_number |= ((*p++ & 1) << i);
}
if (magic_number != MAGIC_NUMBER)
{
error = true;
}
else
{
*hint = 0;
for (i = 0; i < 32; i++)
{
*hint |= ((*p++ & 1) << i);
}
}
return error;
}


AvisynthAPI.cpp

PVideoFrame __stdcall MPEG2Source::GetFrame(int n, IScriptEnvironment* env)
{
int gop, pct;
char Matrix_s[40];
unsigned int raw;
unsigned int hint;

...

else if (m_decoder.info == 3)
{
hint = 0;
if (m_decoder.FrameList[raw].pf == 1) hint |= PROGRESSIVE;
hint |= ((m_decoder.GOPList[gop]->matrix & 7) << COLORIMETRY_SHIFT);
PutHintingData(frame->GetWritePtr(PLANAR_Y), hint);
}
}


EDIT: The hint encoder/decoder would be in the duplicated DGDecode.dll source.
EDIT: GetHintingData() seems not to be used in DGIndex source code, (probably some duplication in DGDecode::Mpeg2Source).

[wonkey_monkey]

Ah, then not an option in this case as changing any bits would break it. I could add another row, but that seems wrong somehow, since the video (more or less) represents pixel data. I went with the GetAudio route and it works well.

[TheFluff]

Is a usseless option.

Who know the ChannelMask of a audio are the decoders, do you know any decoder (ffms2.dll, LSMASHSource.dll, NicAudio.dll, ...) than set ChannelMask to the appropiate value?

There are any audio encoder/player, than accept avs input, than use that global variable if defined?

Also, if there are two, or more, audios processed at same time, how we can distinguise both?

The ChannelMask must be a property of each audio clip.
FFMS sets the script variable FFCHANNEL_LAYOUT which contains the dwChannelMask. You can get one variable per clip using the varprefix option if you like.

Before I go ahead and do this, can anyone raise any objections to the idea of using an audio channel to pass metadata? My filter passes data through the video frame, but it also needs to send a few bytes of metadata with it, so my plan is to override GetAudio and just paste those bytes into the buffer. The other filter in the partnership will then call GetAudio to get the metadata.

Good idea? Bad idea?

num_audio_samples is a 64-bit integer. It's like it was made to use as an arbitrary pointer! Distinguishing a valid pointer from any other arbitrary integer is left as an exercise for the reader.

Seriously though, putting arbitrary data in the audio stream is dumb but about par for the course by Avisynth plugin coding standards. I'm pretty sure it's been done before by other plugins. You could serialize the data and put it in a script variable, but it's not really worth the effort.

[Stereodude]

This script crashes for me using AVSynth+ when loading it in VD2 x64 once LEN is somewhere between 15900-16000. It will crash loading it in AVSmeter (x64) as well when LEN is a slightly lower frame number. I think there's some sort of internal overflow. I was using r2700, but I've since upgraded to r2772. Both do the same thing. There's no popup or error message. VD2x64 just disappears. AVSmeter (x64) just kicks back to the command prompt after getting to the "prescanning script..." message very briefly.

Using the x86 version of AVIsynth+ allows LEN to be larger than the x64 version, but fails by 19000.
LEN2=103848
LEN=15900
A=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$FF0000).ShowFrameNumber
B=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$00FF00).ShowFrameNumber

Z = A.BlankClip(Length=0)
frame=0

while( frame < LEN) {
for(n=2, 958, 2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}

for(n=958, 2, -2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}
}

Return Z
My computer is running Windows 10 Pro and has 32GB of RAM.

[pinterf]

This script crashes for me using AVSynth+ when loading it in VD2 x64 once LEN is somewhere between 15900-16000. It will crash loading it in AVSmeter (x64) as well when LEN is a slightly lower frame number. I think there's some sort of internal overflow. I was using r2700, but I've since upgraded to r2772. Both do the same thing. There's no popup or error message. VD2x64 just disappears. AVSmeter (x64) just kicks back to the command prompt after getting to the "prescanning script..." message very briefly.

Using the x86 version of AVIsynth+ allows LEN to be larger than the x64 version, but fails by 19000.
LEN2=103848
LEN=15900
A=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$FF0000).ShowFrameNumber
B=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$00FF00).ShowFrameNumber

Z = A.BlankClip(Length=0)
frame=0

while( frame < LEN) {
for(n=2, 958, 2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}

for(n=958, 2, -2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}
}

Return Z
My computer is running Windows 10 Pro and has 32GB of RAM.
Finally it fails in Splice::GetFrame.
0xC0000005: Access violation writing location 0x0000000001200000.
and
0xC00000FD: Stack overflow (parameters: 0x0000000000000001, 0x0000000001203FF0).

Loops in Avisynth are much like unrolled loops.

The filter chain of this huge while loop is looking like Splice calling previous Splice calling previous Splice calling...
Even the debugger is giving up showing the stack frame:
"Maximum number of stack frames supported by Visual Studio has been exceeded"

So I think the loops can help only when they are relatively short.

[TheFluff]

This script crashes for me using AVSynth+ when loading it in VD2 x64 once LEN is somewhere between 15900-16000. It will crash loading it in AVSmeter (x64) as well when LEN is a slightly lower frame number. I think there's some sort of internal overflow. I was using r2700, but I've since upgraded to r2772. Both do the same thing. There's no popup or error message. VD2x64 just disappears. AVSmeter (x64) just kicks back to the command prompt after getting to the "prescanning script..." message very briefly.

Using the x86 version of AVIsynth+ allows LEN to be larger than the x64 version, but fails by 19000.
LEN2=103848
LEN=15900
A=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$FF0000).ShowFrameNumber
B=BlankClip(Length=LEN2, height=786, width=1920, Pixel_type="YV12",COLOR=$00FF00).ShowFrameNumber

Z = A.BlankClip(Length=0)
frame=0

while( frame < LEN) {
for(n=2, 958, 2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}

for(n=958, 2, -2) {
Z = Z ++ stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0)).trim(frame,end=frame)
frame = frame + 1
if ( frame == LEN) { Return Z }
}
}

Return Z
My computer is running Windows 10 Pro and has 32GB of RAM.

Don't try to write procedural code in a functional language.

[Stereodude]

Don't try to write procedural code in a functional language.
Well, I'm not sure how to do what I want written in a functional language using the AVIsynth functions and plugins that are available. I guess I will have to play around with using ConditionalReader to replace the inner two for loops so that there aren't 10's of thousands of splices.

[wonkey_monkey]

I'd recommend rgba_rpn (https://forum.doom9.org/showthread.php?t=172601) for this kind of thing, but the learning curve is somewhat precipitous and I've pretty much rewritten the entire thing since then so even I may not be of much help...

Actually masktools or even just Avisynth+'s expr might be better.

[Stereodude]

Actually masktools or even just Avisynth+'s expr might be better.
I took a brief look at masktools the other day at it and didn't seem like I could do this sort of effect using it without having a video that's the dynamic moving mask.

I'm not familiar with expr. I'll have to look into that.

[wonkey_monkey]

You could start with a half-white, half-black clip and use animate and pointresize to shift it left and right. I think it'll still be invoking a lot of filter instances though, so expr makes a bit more sense (although it's not as efficient as it could be in this case).

In fact, consider using expr to create a 1-pixel high sliding bar clip and then pointresize it up to full height.

[Stereodude]

In fact, consider using expr to create a 1-pixel high sliding bar clip and then pointresize it up to full height.
I'll admit I've never used expr and I haven't the foggiest idea how to create that 1-pixel high sliding bar clip with it.

My original idea of replacing the for loops didn't work. Well, I should clarify that... I was able to replace the two for loops with ScriptClip + ConditionalReader (the core piece), but it seems that the use of ScriptClip + ConditionalReader multiple times in a script with the same variable names doesn't work as expected so a loop of multiple instance fails. That would only have ~109 splices instead of 103848 (presumably not crashing).

For example:
LEN=103848
mini_length=956

Asrc=BlankClip(Length=LEN, height=786, width=1920, Pixel_type="YV12",COLOR=$FF0000).ShowFrameNumber
Bsrc=BlankClip(Length=LEN, height=786, width=1920, Pixel_type="YV12",COLOR=$00FF00).ShowFrameNumber

Loop_cnt=0
A=Asrc.trim(Loop_cnt*mini_length, ((Loop_cnt+1)*mini_length-1))
B=Bsrc.trim(Loop_cnt*mini_length, ((Loop_cnt+1)*mini_length-1))
ScriptClip(A, """
stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0))
""")
ConditionalReader("slide.txt", "n", false)
Y = last

Loop_cnt = Loop_cnt + 1
A=Asrc.trim(Loop_cnt*mini_length, ((Loop_cnt+1)*mini_length-1))
B=Bsrc.trim(Loop_cnt*mini_length, ((Loop_cnt+1)*mini_length-1))
ScriptClip(A, """
stackhorizontal(stackhorizontal(A.crop(0,0,n,-0),B.crop(n,0,960,-0)),A.crop(960+n,0,-0,-0))
""")
ConditionalReader("slide.txt", "n", false)
Z = last

return Y
#return Z
I don't understand why Y and Z are identical. If either of the two code blocks are commented out Y/Z are what is expected, or if the variable names in each block are unique (like A0, B0 in the first and A1, B1 in the second) Y & Z are what is expected. But with limitation I can't use a for or while loop to do this 109 times or even do a manual unroll with copy and paste without making every iteration unique.

slide.txt:
Type int

0 2
1 4
2 6
3 8
4 10
5 12
6 14
7 16
8 18
9 20
10 22
11 24
12 26
13 28
14 30
15 32
16 34
17 36
18 38
19 40
20 42
21 44
22 46
23 48
24 50
25 52
26 54
27 56
28 58
29 60
30 62
31 64
32 66
33 68
34 70
35 72
36 74
37 76
38 78
39 80
40 82
41 84
42 86
43 88
44 90
45 92
46 94
47 96
48 98
49 100
50 102
51 104
52 106
53 108
54 110
55 112
56 114
57 116
58 118
59 120
60 122
61 124
62 126
63 128
64 130
65 132
66 134
67 136
68 138
69 140
70 142
71 144
72 146
73 148
74 150
75 152
76 154
77 156
78 158
79 160
80 162
81 164
82 166
83 168
84 170
85 172
86 174
87 176
88 178
89 180
90 182
91 184
92 186
93 188
94 190
95 192
96 194
97 196
98 198
99 200
100 202
101 204
102 206
103 208
104 210
105 212
106 214
107 216
108 218
109 220
110 222
111 224
112 226
113 228
114 230
115 232
116 234
117 236
118 238
119 240
120 242
121 244
122 246
123 248
124 250
125 252
126 254
127 256
128 258
129 260
130 262
131 264
132 266
133 268
134 270
135 272
136 274
137 276
138 278
139 280
140 282
141 284
142 286
143 288
144 290
145 292
146 294
147 296
148 298
149 300
150 302
151 304
152 306
153 308
154 310
155 312
156 314
157 316
158 318
159 320
160 322
161 324
162 326
163 328
164 330
165 332
166 334
167 336
168 338
169 340
170 342
171 344
172 346
173 348
174 350
175 352
176 354
177 356
178 358
179 360
180 362
181 364
182 366
183 368
184 370
185 372
186 374
187 376
188 378
189 380
190 382
191 384
192 386
193 388
194 390
195 392
196 394
197 396
198 398
199 400
200 402
201 404
202 406
203 408
204 410
205 412
206 414
207 416
208 418
209 420
210 422
211 424
212 426
213 428
214 430
215 432
216 434
217 436
218 438
219 440
220 442
221 444
222 446
223 448
224 450
225 452
226 454
227 456
228 458
229 460
230 462
231 464
232 466
233 468
234 470
235 472
236 474
237 476
238 478
239 480
240 482
241 484
242 486
243 488
244 490
245 492
246 494
247 496
248 498
249 500
250 502
251 504
252 506
253 508
254 510
255 512
256 514
257 516
258 518
259 520
260 522
261 524
262 526
263 528
264 530
265 532
266 534
267 536
268 538
269 540
270 542
271 544
272 546
273 548
274 550
275 552
276 554
277 556
278 558
279 560
280 562
281 564
282 566
283 568
284 570
285 572
286 574
287 576
288 578
289 580
290 582
291 584
292 586
293 588
294 590
295 592
296 594
297 596
298 598
299 600
300 602
301 604
302 606
303 608
304 610
305 612
306 614
307 616
308 618
309 620
310 622
311 624
312 626
313 628
314 630
315 632
316 634
317 636
318 638
319 640
320 642
321 644
322 646
323 648
324 650
325 652
326 654
327 656
328 658
329 660
330 662
331 664
332 666
333 668
334 670
335 672
336 674
337 676
338 678
339 680
340 682
341 684
342 686
343 688
344 690
345 692
346 694
347 696
348 698
349 700
350 702
351 704
352 706
353 708
354 710
355 712
356 714
357 716
358 718
359 720
360 722
361 724
362 726
363 728
364 730
365 732
366 734
367 736
368 738
369 740
370 742
371 744
372 746
373 748
374 750
375 752
376 754
377 756
378 758
379 760
380 762
381 764
382 766
383 768
384 770
385 772
386 774
387 776
388 778
389 780
390 782
391 784
392 786
393 788
394 790
395 792
396 794
397 796
398 798
399 800
400 802
401 804
402 806
403 808
404 810
405 812
406 814
407 816
408 818
409 820
410 822
411 824
412 826
413 828
414 830
415 832
416 834
417 836
418 838
419 840
420 842
421 844
422 846
423 848
424 850
425 852
426 854
427 856
428 858
429 860
430 862
431 864
432 866
433 868
434 870
435 872
436 874
437 876
438 878
439 880
440 882
441 884
442 886
443 888
444 890
445 892
446 894
447 896
448 898
449 900
450 902
451 904
452 906
453 908
454 910
455 912
456 914
457 916
458 918
459 920
460 922
461 924
462 926
463 928
464 930
465 932
466 934
467 936
468 938
469 940
470 942
471 944
472 946
473 948
474 950
475 952
476 954
477 956
478 958
479 956
480 954
481 952
482 950
483 948
484 946
485 944
486 942
487 940
488 938
489 936
490 934
491 932
492 930
493 928
494 926
495 924
496 922
497 920
498 918
499 916
500 914
501 912
502 910
503 908
504 906
505 904
506 902
507 900
508 898
509 896
510 894
511 892
512 890
513 888
514 886
515 884
516 882
517 880
518 878
519 876
520 874
521 872
522 870
523 868
524 866
525 864
526 862
527 860
528 858
529 856
530 854
531 852
532 850
533 848
534 846
535 844
536 842
537 840
538 838
539 836
540 834
541 832
542 830
543 828
544 826
545 824
546 822
547 820
548 818
549 816
550 814
551 812
552 810
553 808
554 806
555 804
556 802
557 800
558 798
559 796
560 794
561 792
562 790
563 788
564 786
565 784
566 782
567 780
568 778
569 776
570 774
571 772
572 770
573 768
574 766
575 764
576 762
577 760
578 758
579 756
580 754
581 752
582 750
583 748
584 746
585 744
586 742
587 740
588 738
589 736
590 734
591 732
592 730
593 728
594 726
595 724
596 722
597 720
598 718
599 716
600 714
601 712
602 710
603 708
604 706
605 704
606 702
607 700
608 698
609 696
610 694
611 692
612 690
613 688
614 686
615 684
616 682
617 680
618 678
619 676
620 674
621 672
622 670
623 668
624 666
625 664
626 662
627 660
628 658
629 656
630 654
631 652
632 650
633 648
634 646
635 644
636 642
637 640
638 638
639 636
640 634
641 632
642 630
643 628
644 626
645 624
646 622
647 620
648 618
649 616
650 614
651 612
652 610
653 608
654 606
655 604
656 602
657 600
658 598
659 596
660 594
661 592
662 590
663 588
664 586
665 584
666 582
667 580
668 578
669 576
670 574
671 572
672 570
673 568
674 566
675 564
676 562
677 560
678 558
679 556
680 554
681 552
682 550
683 548
684 546
685 544
686 542
687 540
688 538
689 536
690 534
691 532
692 530
693 528
694 526
695 524
696 522
697 520
698 518
699 516
700 514
701 512
702 510
703 508
704 506
705 504
706 502
707 500
708 498
709 496
710 494
711 492
712 490
713 488
714 486
715 484
716 482
717 480
718 478
719 476
720 474
721 472
722 470
723 468
724 466
725 464
726 462
727 460
728 458
729 456
730 454
731 452
732 450
733 448
734 446
735 444
736 442
737 440
738 438
739 436
740 434
741 432
742 430
743 428
744 426
745 424
746 422
747 420
748 418
749 416
750 414
751 412
752 410
753 408
754 406
755 404
756 402
757 400
758 398
759 396
760 394
761 392
762 390
763 388
764 386
765 384
766 382
767 380
768 378
769 376
770 374
771 372
772 370
773 368
774 366
775 364
776 362
777 360
778 358
779 356
780 354
781 352
782 350
783 348
784 346
785 344
786 342
787 340
788 338
789 336
790 334
791 332
792 330
793 328
794 326
795 324
796 322
797 320
798 318
799 316
800 314
801 312
802 310
803 308
804 306
805 304
806 302
807 300
808 298
809 296
810 294
811 292
812 290
813 288
814 286
815 284
816 282
817 280
818 278
819 276
820 274
821 272
822 270
823 268
824 266
825 264
826 262
827 260
828 258
829 256
830 254
831 252
832 250
833 248
834 246
835 244
836 242
837 240
838 238
839 236
840 234
841 232
842 230
843 228
844 226
845 224
846 222
847 220
848 218
849 216
850 214
851 212
852 210
853 208
854 206
855 204
856 202
857 200
858 198
859 196
860 194
861 192
862 190
863 188
864 186
865 184
866 182
867 180
868 178
869 176
870 174
871 172
872 170
873 168
874 166
875 164
876 162
877 160
878 158
879 156
880 154
881 152
882 150
883 148
884 146
885 144
886 142
887 140
888 138
889 136
890 134
891 132
892 130
893 128
894 126
895 124
896 122
897 120
898 118
899 116
900 114
901 112
902 110
903 108
904 106
905 104
906 102
907 100
908 98
909 96
910 94
911 92
912 90
913 88
914 86
915 84
916 82
917 80
918 78
919 76
920 74
921 72
922 70
923 68
924 66
925 64
926 62
927 60
928 58
929 56
930 54
931 52
932 50
933 48
934 46
935 44
936 42
937 40
938 38
939 36
940 34
941 32
942 30
943 28
944 26
945 24
946 22
947 20
948 18
949 16
950 14
951 12
952 10
953 8
954 6
955 4

[wonkey_monkey]

X=480
blankclip(width=960,height=1080,length=X)
stackhorizontal(last,last.invert,last)
animate(last,0,X-1,"crop",0,0,1920,0,960,0,1920,0)
mask=(last+last.reverse).loop(100)

a=colorbars(width=1920,height=1080)
b=version.pointresize(1920,1080)

overlay(a,b,mask=mask)

[Stereodude]

X=480
blankclip(width=960,height=1080,length=X)
stackhorizontal(last,last.invert,last)
animate(last,0,X-1,"crop",0,0,1920,0,960,0,1920,0)
mask=(last+last.reverse).loop(100)

a=colorbars(width=1920,height=1080)
b=version.pointresize(1920,1080)

overlay(a,b,mask=mask)
There's a few minor "mistakes" in there with the motion of the mask (I had a similar mistake in my example also) and I wanted to start the mask on the other side, but I certainly wouldn't have been able to put together that combo of filters myself. Big :thanks: !

I think this is corrected
X=480
blankclip(width=960,height=1080,length=X+1)
clip1=stackhorizontal(last,last.invert,last)
clip2=clip1.trim(0,X-2)
mask=(animate(clip1,0,X,"crop",960,0,1920,0,0,0,1920,0)+animate(clip2,0,X-1,"crop",2,0,1920,0,960,0,1920,0)).loop(100)

a=colorbars(width=1920,height=1080)
b=version.pointresize(1920,1080)

overlay(a,b,mask=mask)

[wonkey_monkey]

Another stupid question, mostly out of curiosity...

I'm writing another filter which abuses GetAudio (I have my reasons!). If I callchild->GetAudio(buffer, start, 1, env)on a clip created by filter, I get the debug output I expect (which proves that GetAudio has been called). However, if I callchild->GetAudio(buffer, start, 0, env)my GetAudio is seemingly not called.

I'm not 100% with the fine details of classes and overloading. What is it that stops Avisynth from calling my GetAudio when count=0?

[StainlessS]

Perhaps Audio Cache swallows the call, and does not call your upstream filter but returns immediately (no idea really).

EDIT: You got some [additional] source at all ?

[wonkey_monkey]

This is my GetAudio:

void __stdcall tracker::GetAudio(void* buffer, __int64 start, __int64 count, IScriptEnvironment* env) {
debug("GetAudio: %d,%d", start, count);
if (start == -0x5452414b) {
switch (count) {
case 0: {
*((int*)buffer) = 0x5452414b;
} break;
}
} else {
child->GetAudio(buffer, start, count, env);
}
}


and this is my call to GetAudio, in the constructor of another filter:

int check = 0;
child->GetAudio(&check, 0x5452414b, 0, env);
debug("%d", check);


Edit: so does this mean there's something between calling child->GetAudio and my function actually being called, which is rejecting out-of-range values? Hmm... some thinking is required.

[StainlessS]

debug("GetAudio: %d,%d", start, count);

Dont use %d for __int64, use %I64d, or results will be wrong:- https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2017

does this mean there's something between calling child->GetAudio
Well there is some stuff in source about audio cache, but no idea how it works.

enum {
CACHE_NOTHING=0,
CACHE_RANGE=1,
CACHE_ALL=2,
CACHE_AUDIO=3,
CACHE_AUDIO_NONE=4,
CACHE_AUDIO_AUTO=5
};


EDIT: Oops yep, %I64d or eg %I64X.

[wonkey_monkey]

Dont use %d for __int64, use %I64, or results will be wrong:- https://docs.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=vs-2017

%I64d - %I64 is a prefix. But it's only for debugging so truncation doesn't matter.

If I only put %I64 it crashes VirtualDub2 completely. You'd think things like (vs)printf(_s) would be a little more robust...

[StainlessS]

Fixed, sorry.

If size specifier is wrong then gets only first four bytes (half of __int64 start, bytes 0 to 3) from stack for vsprintf start arg,
vsprintf count would come from 2nd half (4 bytes, bytes 4 to 7) of start, so count on stack would NOT be accessed at all.

EDIT: for other readers, the vsprintf mentioned stuff, think Wonkey is using something like this


int __cdecl dprintf(char* fmt, ...) {
char printString[2048]="WonkeyWilly: "; // Must be nul Termed, eg "Test: " or ""
char *p=printString;
for(;*p++;);
--p; // @ null term
va_list argp;
va_start(argp, fmt);
vsprintf(p, fmt, argp);
va_end(argp);
for(;*p++;);
--p; // @ null term
if(printString == p || p[-1] != '\n') {
p[0]='\n'; // append n/l if not there already
p[1]='\0';
}
OutputDebugString(printString);
return int(p-printString); // strlen printString
}


EDIT:
This is my GetAudio:

void __stdcall tracker::GetAudio(void* buffer, __int64 start, __int64 count, IScriptEnvironment* env) {
debug("GetAudio: %d,%d", start, count);
if (start == -0x5452414b) {
switch (count) {
case 0: {
*((int*)buffer) = 0x5452414b;
} break;
}
} else {
child->GetAudio(buffer, start, count, env);
}
}


and this is my call to GetAudio, in the constructor of another filter:

int check = 0;
child->GetAudio(&check, 0x5452414b, 0, env);
debug("%d", check);



Not sure that I'm understandin' the -ve value in red [0x5452414b = 'TRAK'].

[wonkey_monkey]

It's a magic number to flip GetAudio into providing something other than audio. Negative numbers were making it crash, so I must have copied-and-pasted mid-testing. The comparison in GetAudio should be with the positive number.

I've abandoned that idea now because of the possible caching/bounds checking issue (something is intercepting the call and aborting it because the clip doesn't have that many samples). Now I'm calling it with start=0 and passing the magic number in the buffer. I'm not sure this will work either, because it's possible the returned values for a given start/count will change, and if something is caching them then it will interfere.

[StainlessS]

Avs+ Feature request:

Layer with YV24 support would be nice :) [think I requested this in avs Standard thread]

I would like to mod S_ExLogo() for YV24, currently only YUY2 [Layer also supports RGB32 & under avs+ RGB64].

S_ExLogo[YUY2 Only]:- https://forum.doom9.org/showthread.php?t=154559&highlight=S_ExLogo

# Based on Dekafka (YUY2 Only)
#
# HHHHHH s_Exlogo, samples above and below (shown left as 'H')
# VLLLLLLV and combines them into a horizontal bar.
# VLLLLLLV Samples left and right and combines them into a vertical bar (show as 'V'.
# VLLLLLLV Logo area shown as 'L'.
# VLLLLLLV These bars may or may not be blurred, and are then resized to fit
# HHHHHH the logo area. The resized bars are then mixed together based
# on arg "Spow" and the ratio of length of Vertical bars to length
# of horizontal bars. Finally, the resultant de-logo'd area is
# Layer'ed onto the clip using the Amount arg.
# Clipping can be set so as to avoid eg sampling letterboxing when
# blurring out the logo (would normally result in nasty black
# block instead of a nasty logo).
#
# Basic usage:-
# s_ExLogo(clip, int LogoX, int LogoY, int LogoW, Int LogoH)


S_ExLogo is a Mod of DeKafka:- http://avisynth.nl/index.php/DeKafka

EDIT: Despite what it says on the Wiki, Dekafka supports only YUY2, RGB32, RGB64(same as Layer).
Note this version works with any format, but there will be a RGB32 conversion. [NO THERE WILL NOT - at least not from eg YV12 or YV24]

EDIT: Only real reason for YV24 desirability, is to support ODD X coords.

[pinterf]

Good catch, Layer is somewhat retarded at the moment. YUY2 is supported so there should be no complain why it's missing other YUV formats. Nor it does support planar RGB, what a world we live in.
Problem registered, and will be solved, well before the next lunar eclipse (but not this week), thanks for the report :)

[StainlessS]

and will be solved, well before the next lunar eclipse
Terrific [EDIT: no hurry at all] , Layer is not nearly as RAM greedy and faster than Overlay, and often a better choice if colorspace supported.
Me is a happy bunny, Thanx.

EDIT: faster than Overlay
S_ExLogo may not be the best DeLogo filter, but it does a fair job and 'goes like the clappers' [real fast in comparison to most delogo'ers].

[BlockABoots]

Excuses my ignorance, but what is the latest release of avisynth (or what ever it has morphed into)?

Is there a better fork to use than standard avisynth, as i used to use AvsPmod in conjunction with avisynth is there an all in one app now a days?

[StainlessS]

BockABoots,
Here, Avisynth+ r2772, usually via pinterf sig link "My Avisynth+ repo on github", and then click Releases tab:- https://github.com/pinterf/AviSynthPlus/releases

Above (current avs+) is the only one that everybody should be using.

[BlockABoots]

Thanks

[manolito]

Above (current avs+) is the only one that everybody should be using.

Please allow me to disagree... :devil:

On an old computer with low system RAM and a single core CPU AVS+ does run, but it is way slower than plain vanilla AVS 2.60 (or 2.61 Beta). The only reason to use AVS+ on such a computer is if the user needs the high bit depth and extented color space features of AVS+.

Even on a much newer Core i5 CPU with 8 GB system RAM I found that I had to turn off multithreading completely when using ffms2 as the source filter (in the default serialized mode). Speed dropped to a crawl when the prefetch value was set to 4.

So I do see a few good reasons to prefer AVS 2.60 over AVS+.


Cheers
manolito

[wonkey_monkey]

Is it possible to have an AVSValue with an ArraySize() of 0?

[Groucho2004]

Please allow me to disagree... :devil:

On an old computer with low system RAM and a single core CPU AVS+ does run, but it is way slower than plain vanilla AVS 2.60 (or 2.61 Beta).
Can you post an example script which would show that classic Avisynth uses less memory than AVS+? My expierence is that AVS+ is much more efficient using the available memory.

[StainlessS]

My expierence is that AVS+ is much more efficient using the available memory.
Mine too.

Is it possible to have an AVSValue with an ArraySize() of 0?
Yes.

FrameSel plugin, 2nd arg is array of frame numbers,
env->AddFunction("FrameSel", "ci*[SCmd]s[Cmd]s[Show]b[Ver]b[Reject]b[Ordered]b[Debug]b[Extract]i", Create_FrameSel, 0);,

AVSValue __cdecl Create_FrameSel(AVSValue args, void* user_data, IScriptEnvironment* env) {
PClip _child = args[0].AsClip(); // Source Clip, No Default
AVSValue _Frames = args[1]; // Frames, Array of frame numbers as filter arguments
const char *_SCmd = args[2].AsString(NULL); // SCmd, Frames in string, defaults to NULL
const char *_Cmd = args[3].AsString(NULL); // Cmd, Frames Cmd File, defaults to NULL
bool _show = args[4].AsBool(false); // show, show frame numbers
bool _ver = args[5].AsBool(false); // ver, show version
bool _reject = args[6].AsBool(false); // Reject Mode
bool _ordered= args[7].AsBool(true); // ordered Mode
bool _debug = args[8].AsBool(false); // debug
int _extract = args[9].AsInt(1); // extract

if(_SCmd && *_SCmd == '\0') _SCmd=NULL; // Convert user supplied "" to NULL
if(_Cmd && *_Cmd == '\0') _Cmd=NULL; // Convert user supplied "" to NULL

// if(_Cmd==NULL && _SCmd==NULL && _Frames.ArraySize()==0)
// return _child; // No frames specified at all, return orig clip as if no filter.

return new FrameSel(_child,_Frames,_SCmd,_Cmd,_show,_ver,_reject,_ordered,_debug,_extract,env);
}
Above, is actually switched off (commented out), but still shows that you can have ArraySize==0 when no frames specified.

[wonkey_monkey]

Oh, sorry, I meant is it possible to construct an AVSValue with an ArraySize() of zero? I tried AVSValue x = AVSValue() but it had an ArraySize() of 1.

I'm using two creator functions which both instantiate the same class - one includes an i+ in its parameter definition, the other doesn't (but does have all the other variables). I also tried passing NULL but C++ wouldn't let me compare an AVSValue with NULL.

It's very easy to work around but I always try to strive for a neat solution (even if my source code doesn't suggest it).

[StainlessS]

For anything like that, I tend to look at Avisynth VERSION 3 header (v2.58) with baked code.


class AVSValue {
public:

AVSValue() { type = 'v'; }
AVSValue(IClip* c) { type = 'c'; clip = c; if (c) c->AddRef(); }
AVSValue(const PClip& c) { type = 'c'; clip = c.GetPointerWithAddRef(); }
AVSValue(bool b) { type = 'b'; boolean = b; }
AVSValue(int i) { type = 'i'; integer = i; }
// AVSValue(__int64 l) { type = 'l'; longlong = l; }
AVSValue(float f) { type = 'f'; floating_pt = f; }
AVSValue(double f) { type = 'f'; floating_pt = float(f); }
AVSValue(const char* s) { type = 's'; string = s; }
AVSValue(const AVSValue* a, int size) { type = 'a'; array = a; array_size = size; }
AVSValue(const AVSValue& v) { Assign(&v, true); }

~AVSValue() { if (IsClip() && clip) clip->Release(); }
AVSValue& operator=(const AVSValue& v) { Assign(&v, false); return *this; }

// Note that we transparently allow 'int' to be treated as 'float'.
// There are no int<->bool conversions, though.

bool Defined() const { return type != 'v'; }
bool IsClip() const { return type == 'c'; }
bool IsBool() const { return type == 'b'; }
bool IsInt() const { return type == 'i'; }
// bool IsLong() const { return (type == 'l'|| type == 'i'); }
bool IsFloat() const { return type == 'f' || type == 'i'; }
bool IsString() const { return type == 's'; }
bool IsArray() const { return type == 'a'; }

PClip AsClip() const { _ASSERTE(IsClip()); return IsClip()?clip:0; }
bool AsBool() const { _ASSERTE(IsBool()); return boolean; }
int AsInt() const { _ASSERTE(IsInt()); return integer; }
// int AsLong() const { _ASSERTE(IsLong()); return longlong; }
const char* AsString() const { _ASSERTE(IsString()); return IsString()?string:0; }
double AsFloat() const { _ASSERTE(IsFloat()); return IsInt()?integer:floating_pt; }

bool AsBool(bool def) const { _ASSERTE(IsBool()||!Defined()); return IsBool() ? boolean : def; }
int AsInt(int def) const { _ASSERTE(IsInt()||!Defined()); return IsInt() ? integer : def; }
double AsFloat(double def) const { _ASSERTE(IsFloat()||!Defined()); return IsInt() ? integer : type=='f' ? floating_pt : def; }
const char* AsString(const char* def) const { _ASSERTE(IsString()||!Defined()); return IsString() ? string : def; }

int ArraySize() const { _ASSERTE(IsArray()); return IsArray()?array_size:1; }

const AVSValue& operator[](int index) const {
_ASSERTE(IsArray() && index>=0 && index<array_size);
return (IsArray() && index>=0 && index<array_size) ? array[index] : *this;
}

private:

short type; // 'a'rray, 'c'lip, 'b'ool, 'i'nt, 'f'loat, 's'tring, 'v'oid, or 'l'ong
short array_size;
union {
IClip* clip;
bool boolean;
int integer;
float floating_pt;
const char* string;
const AVSValue* array;
// __int64 longlong;
};

void Assign(const AVSValue* src, bool init) {
if (src->IsClip() && src->clip)
src->clip->AddRef();
if (!init && IsClip() && clip)
clip->Release();
// make sure this copies the whole struct!
((__int32*)this)[0] = ((__int32*)src)[0];
((__int32*)this)[1] = ((__int32*)src)[1];
}
};


Looks like you need to give an array size.

AVSValue(const AVSValue* a, int size) { type = 'a'; array = a; array_size = size; }

int ArraySize() const { _ASSERTE(IsArray()); return IsArray()?array_size:1; }


EDIT: does this not work ?

AVSValue a[0];

Nope, error C2466: cannot allocate an array of constant size 0

EDIT: Some existing code that works,

AVSValue std1[STD_SIZE] = {child,0,0,0,0,0,0,false};
AVSValue xtra1[XTRA_SIZE];
xtra1[XTRA_RGBIX] = matrix;
std1[STD_FRAME] = n;

AVSValue std2[STD_SIZE] = {child2,0,0,0,0,0,0,false};
AVSValue xtra2[XTRA_SIZE];
xtra2[XTRA_RGBIX] = matrix;
std2[STD_FRAME] = n2;

MYLO mylo;

RT_MYstats_Lo(RTHIST_F,AVSValue(std1,STD_SIZE),AVSValue(xtra1,XTRA_SIZE),mylo,myName,env,hist1);
RT_MYstats_Lo(RTHIST_F,AVSValue(std2,STD_SIZE),AVSValue(xtra2,XTRA_SIZE),mylo,myName,env,hist2);

[wonkey_monkey]

Oh, I guess I can just use IsArray() instead then, thanks for the help. Returning 1 confused me into thinking it was being treated as an array.

[wonkey_monkey]

It's just occured to me that the "child" clip in the GenericVideoFilter constructor shouldn't really be called "child", should it? It should be "parent".

Not suggesting it should be changed, of course, just making an observation!

[manolito]

The files-only section also contains an x86 build for SSE-only processors.

Thanks for still supporting folks with non-SSE2 CPUs...

Just found out that DirectShowSource.dll from the Non-SSE2 folder seems to be broken. It sure does not work without SSE2. Using the older DirectShowSource.dll from the qyot27 build avisynth _r2741-g0cb91abf-20180803 fixes it.


Cheers
manolito

[manolito]

Can you post an example script which would show that classic Avisynth uses less memory than AVS+? My expierence is that AVS+ is much more efficient using the available memory.

Not on my ancient WinXP machine...

Specs:
https://i.postimg.cc/QxjQnyS4/specs.png (https://postimages.org/)


I tested it again using a short HD clip and converted it to DVD. I used two scripts, the first one is very basic, the second one uses jm_fps (frame rate interpolation) and is much slower. These are the scripts:

Easy.avs:
Video = DSS2("I:\test.webm", fps = 30, preroll = 15, lavs = "l0", lavd = "l0")
Audio = DirectShowSource("I:\test.webm", video=false)

Video = Video.ConvertToYV12()
Video = Video.Spline36Resize(720,576)
Video = Video.ChangeFPS(25)

AudioDub(Video, Audio)


Hard.avs:
Video = DSS2("I:\test.webm", fps = 30, preroll = 15, lavs = "l0", lavd = "l0")
Audio = DirectShowSource("I:\test.webm", video=false)

Video = Video.ConvertToYV12()
Video = Video.Spline36Resize(720,576)
Video = Video.jm_fps(25)

AudioDub(Video, Audio)


And these are the AVSMeter results for plain vanilla AVS 2.61 Alpha and for the current AVS+ version:

https://i.postimg.cc/yYwZCpTC/AVS-2-61-Easy.png (https://postimages.org/)

https://i.postimg.cc/q7pgpPhS/AVS-Easy.png (https://postimages.org/)


https://i.postimg.cc/gkRvjPj2/AVS-2-61-Hard.png (https://postimages.org/)

https://i.postimg.cc/B6kKZhGF/AVS-Hard.png (https://postimages.org/)bilder hochladen free (https://postimages.org/de/)


For me this is enough reason to not use AVS+ on this computer. It is slow enough as it is, but slowing it down even more without any additional benefit does not make sense to me.


Cheers
manolito

[qyot27]

Just found out that DirectShowSource.dll from the Non-SSE2 folder seems to be broken. It sure does not work without SSE2. Using the older DirectShowSource.dll from the qyot27 build avisynth _r2741-g0cb91abf-20180803 fixes it.
DirectShowSource.dll is the only plugin in the main source tree that actually requires linking in an external library - the baseclasses from the Windows 7 SDK. Said baseclasses library doesn't set a processor architecture, so on newer MSVC it just defaults to SSE2 unless overridden manually.

Being a system library, I'm pretty sure I always make sure to compile that piece using /ARCH:IA32 (i.e., none at all) for 32-bit.

[Groucho2004]

Not on my ancient WinXP machine...I used basically the same script as your "hard.avs" with a 720p clip and here are the results with my i5:

AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp

FPS (min | max | average): 18.57 | 198864 | 46.70
Process memory usage (max): 592 MiB
Thread count: 13
CPU usage (average): 24.9%


AviSynth+ 0.1 (r2772, MT, i386)

FPS (min | max | average): 18.64 | 137675 | 46.88
Process memory usage (max): 142 MiB
Thread count: 20
CPU usage (average): 24.6%


Edit: I just remembered that Avisynth (classic, not sure about AVS+) sets "SetMemoryMax()" according to the available memory:
MEMORYSTATUS memstatus;
GlobalMemoryStatus(&memstatus);
// Minimum 16MB
// else physical memory/4
// Maximum 0.5GB
if (memstatus.dwAvailPhys > 64*1024*1024)
memory_max = (__int64)memstatus.dwAvailPhys >> 2;
else
memory_max = 16*1024*1024;

if (memory_max <= 0 || memory_max > 512*1024*1024) // More than 0.5GB
memory_max = 512*1024*1024;

In your case this is probably 128 MiB. That would explain the rather moderate memory usage of Avisynth 2.6.1 in your test.

[TheFluff]

The reason Avs+ is slower on a 32-bit non-SSE machine might also be because IIRC a bunch of ancient MMX optimizations that were at best completely useless on any sort of reasonable hardware were removed from Avs+ pretty early on. Don't expect software that is actually maintained to keep optimization for ancient hardware forever.

If Avs+ is slower on an i5 though you're probably doing something wrong.

[Groucho2004]

If Avs+ is slower on an i5 though you're probably doing something wrong.It's not. In the example above, heavy use of mvtools mainly contributes to the speed. Simple internal operations such as resizing are much faster with AVS+.

[tormento]

Plus, if you have a x64 capable CPU, I strongly suggest to jump on x64 train, where FPS can see up to 10-25% increase. Nowadays a Windows 10 x64 Pro license can be found on Amazon for a few bucks. Nonsense to stay on ancient XP.

[manolito]

Sorry I really cannot live without a couple of older 32-bit plugins. AVS64 is definitely not for me...

[Groucho2004]

Sorry I really cannot live without a couple of older 32-bit plugins.Just curious - which ones?

[ChaosKing]

Can you give an example? I never found a non working plugin for avs+.

[manolito]

Just curious - which ones?

The most important one is LogoAway which is a 32-bit VDub plugin. Easy to use, very nice results and relatively fast. I tried most of the available logo removers, and this one did beat them all.

I just glanced over the list of available 64-bit AVS plugins, and this list has grown considerably. With a little effort I could probably find 64-bit replacements for most of my plugins. But there is another reason why I am not going to do this:

I do video conversions on at least 3 different computers. There's the notorious ancient WinXP machine, there is one Win7-32 laptop (only 2GB Ram, the 64-bit Win7 version is too slow on this laptop, constant swapping), and another Win7-64bit laptop with 8GB RAM. I have no intention to maintain 3 different AVS plugins folders, it is hard enough for me to maintain just one plugins folder. Getting working plugin versions for several scripts like QTGMC, LSFMod, Srestore or Finesharp took me a long time, and I want to keep this configuration. I know that if everything works on the WinXP machine then it will also work on the other computers. Maybe a little bit slower than it could, but no headaches for me.


Cheers
manolito

[manolito]

Can you give an example? I never found a non working plugin for avs+.

What tormento suggested is go the 64-bit route exclusively. For AVS+ the installer suggests to install both the 32-bit and the 64-bit versions in parallel (of course only if a 64-bit OS is detected).

While having both versions installed at the same time is possible, you can not mix 32-bit and 64-bit plugins in the same script. It's either one or the other, you need to keep the plugins separate.


Cheers
manolito

[lansing]

The most important one is LogoAway which is a 32-bit VDub plugin. Easy to use, very nice results and relatively fast. I tried most of the available logo removers, and this one did beat them all.

I just glanced over the list of available 64-bit AVS plugins, and this list has grown considerably. With a little effort I could probably find 64-bit replacements for most of my plugins. But there is another reason why I am not going to do this:

I do video conversions on at least 3 different computers. There's the notorious ancient WinXP machine, there is one Win7-32 laptop (only 2GB Ram, the 64-bit Win7 version is too slow on this laptop, constant swapping), and another Win7-64bit laptop with 8GB RAM. I have no intention to maintain 3 different AVS plugins folders, it is hard enough for me to maintain just one plugins folder. Getting working plugin versions for several scripts like QTGMC, LSFMod, Srestore or Finesharp took me a long time, and I want to keep this configuration. I know that if everything works on the WinXP machine then it will also work on the other computers. Maybe a little bit slower than it could, but no headaches for me.


Cheers
manolito
It might be a good time to buy new computers

https://www.newegg.com/Product/Product.aspx?Item=N82E16819113480

Ryzen 5 4-core/8 threads for $150, that will fix all your problem. Heck you can probably build three under $1000.

[real.finder]

While having both versions installed at the same time is possible, you can not mix 32-bit and 64-bit plugins in the same script. It's either one or the other, you need to keep the plugins separate.


Cheers
manolito

you can mix 32-bit and 64-bit plugins in the same script with mpp (mp_pipeline), you can even run avs+ inside it even if you have old avs installed by using "### dll:"

[Stereodude]

Just curious - which ones?
AFAIK, MCTD is 32-bit only so far. However, MP Pipeline lets you use it in an otherwise x64 process.

[poisondeathray]

MTCD works ok in avs+ x64 , just not higher bit depths (except in vapoursynth)

hdragc is one that is still x86 only (but you can get similar results with smoothcurve x64)

[wonkey_monkey]

Using multiline syntax (".\"), is there any way to comment out a line in the middle of a set of lines? For example:

version.\
fliphorizontal.\
flipvertical.\
killaudio

Is there any way to comment out the fliphorizontal line without affecting parsing of the rest of the script?

I don't know how much use multiline syntax gets, but I'm guessing it may have originally been something of an after-thought. Semi-colon termination would be so nice... :cool:

[qyot27]

C-style /* */ works (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Comments):
Version()/*.\
FlipHorizontal()*/.\
FlipVertical().\
KillAudio()

[* *] are also allowed as comment delimiters as well.

Although on something that simple (for exposition's sake) I wouldn't bother with the .\ style multiline syntax at all, and use the standard multiline form:
Version()
#FlipHorizontal()
FlipVertical()
KillAudio()
In the above, /* and */ could also be used, and would format more sanely, since they'd be contained to just the FlipHorizontal() line.

[Stereodude]

Was there an issue before with the dithering when reducing the color depth in AVIsynth+ (4:2:0 chroma formats) that was fixed? I noticed some vertical banding in the output video when dithering was enabled with SD/REC.601 previously with build 2700. I didn't see it in HD/REC.709 content. However, with the latest build 2772 AVIsynth+ I don't see it anymore.

[StainlessS]

Stereodude, see Changelog for current & prev versions via Pinterf (via his sig) on github / releases :- https://github.com/pinterf/AviSynthPlus/releases

[pinterf]

I don't remember any issues or coding activities connected to dithering.

[Stereodude]

Stereodude, see Changelog for current & prev versions via Pinterf (via his sig) on github / releases :- https://github.com/pinterf/AviSynthPlus/releases
I didn't see anything listed that would directly explain my observations. Hence the question.

I don't remember any issues or coding activities connected to dithering.
Weird... Oh well, I'm not seeing it now.

[FranceBB]

In the above, /* and */ could also be used

I use /* */ everyday to comment out multiple lines.
For the sake of coding, // would also be appreciated to have available as comment instead of using just "#" for single line commands, just to feel a bit more like C++ and C#.

I don't remember any issues or coding activities connected to dithering.

Speaking of Dithering, will other dithering algorithms be added in the near future? You know, like the Stucki error diffusion and the Atkinson error diffusion?
Don't get me wrong, I'm totally happy with the current Floyd-Steinberg error diffusion as it's one of the best dithering algorithms, but what if people need/would like to use other dithering algorithms?
After all, back when the world was 8bit stacked, 8 dithering methods were available.

[StainlessS]

// would also be appreciated

Bad idea at this late date. Too much potential to f*** up stuff, eg script scanning apps like AvsPMod, Avisynthesizer etc.
Also, adds nothing to the language.

[FranceBB]

Too much potential to f*** up stuff

Uh... I guess you are right.
After so many years it might be a problem.
Well, after all I got used to use # as comment anyway, so it's not a big deal...

Anyway, my request for the alternative dithering methods is still valid. :)

[qyot27]

# is more typical for scripting languages anyway. Bourne shell and its kin, and Python at least. It wouldn't surprise me if that was a near-universal convention.

What seems...off...about AviSynth's use of the .\ paired with # is that it seems like empty lines aren't collapsed, meaning that a # comment in the middle of a .\ multiline block will error out (which I'm pretty sure might be what prompted this particular discussion in the first place). So will removing the line's contents entirely, while leaving the blank line. In a typical AviSynth script without that line continuation syntax, empty lines are collapsed, skipped, or treated like a no-op. Moving the \ to the actual line it continues on, like this:
Version().

\FlipVertical().
\KillAudio()
works, but even then, the comment-in-the-middle (if it were there) doesn't.

[tormento]

After all, back when the world was 8bit stacked, 8 dithering methods were available.
Aren’t you confusing dither.dll from cretindesalpes?

[pinterf]

Probably most of those dithering methods were not used. You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.

[tormento]

Probably most of those dithering methods were not used. You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.
I pretty much used ordered. It's better compressed without too much washing it out.

[FranceBB]

Aren’t you confusing dither.dll from cretindesalpes?

I meant Dither Tools, that's why I said "in the 16bit stacked era".
Back then there was Dither Tools for everything about 16bit stacked and HDRCore for 16bit interleaved, but only Dither Tools had many dithering options:

Dithering method:
-1 no dither, round to the closest value
0 8-bit ordered dither + noise.
1 1-bit dither
2 2-bit dither, light
3 2-bit dither, medium
4 2-bit dither, strong
5 2-bit dither, stronger
6 Serpentine Floyd-Steinberg error diffusion + noise.
7 Stucki error diffusion + noise.
8 Atkinson error diffusion + noise.

You can always use z_ConvertFormat for both dithering and for all other size and color space conversions.

Got it.

Probably most of those dithering methods were not used.

Well, maybe yes, but some people did use them, I think, as they have their pros and cons.
For instance, tormento just said that he uses ordered dither 'cause it's better compressed by codecs (of course, since it has a regular pattern and it's better identified by the motion-compensation algorithms on the 4x4/8x8 blocks etc).
Other people might instead have a lot of bitrate to spend on the video and maybe they prefer Stucki 'cause it looks sharper and so on.

[StainlessS]

As far as comments concerned, below is demo of how handy '[* ... *]' is,

Function DropDeadGorgeous(clip c,String DB,Int "ScanAhead", Int "X",Int "Y",Int"W",Int "H",Bool "Show", Bool "Verb",
\
\ Int "Prefilter", [* Prefilter *]
\ Int "SPad", Int "SPel", Bool "SChroma", Int "SSharp", Int "SRFilter", [* MSuper *]
\ Int "ABlkSize", Int "ABlkSizeV", [* MAnalyse *]
\ Int "ASearch", Int "ASearchParam", Int "APelSearch", [* MAnalyse *]
\ Bool "AChroma", Bool "ATrueMotion", [* MAnalyse *]
\ Int "AOverlap", Int "AOverlapV", [* MAnalyse *]
\ Int "ADct", Bool "ATryMany", [* MAnalyse *]
\ Int "RthSAD", Int "RBlkSize", Int "RBlkSizeV", [* MRecalculate *]
\ Int "RSearch", Int "RSearchParam", [* MRecalculate *]
\ Bool "RChroma", Bool "RTrueMotion", [* MRecalculate *]
\ Int "ROverlap", Int "ROverlapV", Int "RDct", [* MRecalculate *]
\ Float "Iml", Bool "IBlend", Int "IthSCD1", Int "IthSCD2", [* MFlowInter *]
\
\ Int "SOSthSCD2"
\ )


Its use totally evaded me until RaffRiff42 pointed it out some time ago [I had even forgot that it existed as a comment option], the nesting comments can be very useful.

EDIT: Above is not prototype for current posted DDG, will be as above in next version.

[shekh]

@pinterf
Tried planar rgb formats, found some issues:


AviSource()
ConvertToYV12()
ConvertToPlanarRGBA()
ConvertBits(16)


Alpha plane is uninitialized, sometimes 0xCD somietimes 0x00 bytes.
Same with depth 14,12,10.

ConvertBits(8)
Resulting format is RGBA32 but is filled with something wrong.


AviSource()
ConvertToYV12()
ConvertToPlanarRGBA()
OPT_Enable_PlanarToPackedRGB = true
ConvertBits(8)


Works normally except alpha is still uninitialized.
Using AviSynthPlus-MT-r2772.exe

8BPS: according to some sources this format is rle-encoded. There is decoder in FFMpeg which does not understand simple planar packing. Is this fourcc clash?

[pinterf]

Thanks, I'll look at those uninitialized alpha issues. As for 8BPS, yes, its handling is wrong because it wants rle, and I'm not even sure why I chose it, perhaps I did not find other fourcc for 8 bit planar rgb?

[shekh]

libavcodec\raw.c includes these:
{ AV_PIX_FMT_GBRP, MKTAG('G', '3', 00 , 8 ) },
{ AV_PIX_FMT_GBRAP, MKTAG('G', '4', 00 , 8 ) },
So it at least looks similar to other G3/G4 formats, but probably there is no program to understand it.

[pinterf]

Historical moment, we could be the second and third one, spreading a new standard and increase the citation index of these formats. :)

[pinterf]

Me again...

colorbars returns a clip with alpha set to 255 with pixel_type="RGBAP8", but with pixel_type="RGB32", alpha is set to 0.
Thanks, fixed on git.

[pinterf]

libavcodec\raw.c includes these:
{ AV_PIX_FMT_GBRP, MKTAG('G', '3', 00 , 8 ) },
{ AV_PIX_FMT_GBRAP, MKTAG('G', '4', 00 , 8 ) },
So it at least looks similar to other G3/G4 formats, but probably there is no program to understand it.
Alpha on VfW was uninitialized because it wasn't filled.
Changed 8 bit planar RGB fourCCs similar to the 10-16 bit logic: G3[0][8] and G4[0][8]. I've prepared a test build for you (x64 only):
https://drive.google.com/open?id=1cmW5M2O3eEVOziWtAbxrJxmBgZMyZc-Y

[pinterf]

This test build in previous post has a working Layer filter for YUV 8-32 bit formats (except lighten/darken).
A new Layer parameter float strength (0.0 .. 1.0) optionally replaces the previous "level". This parameter is independent of bit-depth, one does not have to fiddle with it like had to with level (which was maxed with level=257 when RGB32 but level=256 for YUY2/YUV)
e.g. these pairs have similar effects

x=0
y=0
op = "add" # fast, subtract, mul
test422_1 = Layer(clip422, ovr422, op, strength=0.5, x=x, y=y, use_chroma=true)
testYuy2_1= Layer(clipYuy2, ovrYuy2, op, level=128, x=x, y=y, use_chroma=true)

test422_2 = Layer(clip422, ovr422, op, strength=1.0, x=x, y=y, use_chroma=true)
testYuy2_2= Layer(clipYuy2, ovrYuy2, op, level=256, x=x, y=y, use_chroma=true)

[shekh]

Alpha on VfW was uninitialized because it wasn't filled.
Changed 8 bit planar RGB fourCCs similar to the 10-16 bit logic: G3[0][8] and G4[0][8]. I've prepared a test build for you (x64 only):
https://drive.google.com/open?id=1cmW5M2O3eEVOziWtAbxrJxmBgZMyZc-Y

Thanks, everything looks good.

[pinterf]

Great, thanks. I'll arrange a release after having the Layer filter extension finished .

[StainlessS]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

Or does one have to inquire eg "Is420" and deduce that has same modulo requirements as YV12.

EDIT: Or extract Y plane and U plane and calculate it manually (last resort).

[Selur]

Does anyone know why SVP doesn't work with Avisynth+ (used 32bit, r2772, MT)? (https://www.svp-team.com/forum/viewtopic.php?pid=71384)
Works fine with 32bit Avisynth 2.6 MT.

[StainlessS]

Just checked converting 29.97 to 59.xxx and seems to work ok for me
InterFrame 2.8.1 by SubJunk,
svpflow1.dll File version=2.0.1.0, Product version 3.1.7 (~348KB)
svpflow2.dll File version=2.0.0.0, Product version 3.1.7 (~384KB)

avs+, r2772(32bit)

What are symptoms ?

[Selur]

Can you share those? I'd like to test whether those binaries work for me too.
(tried binaries from http://www.svp-team.com/files/gpl/svpflow-4.2.0.142.zip, also tried some other 4.x versions I found)

[StainlessS]

Yep:- http://www.mediafire.com/file/r37y2mztod68tro/SVP.zip/file
(32 bit only)

EDIT: Maybe I imagine it, but did SVP start requiring their own version of AVS+ at some point (I never really paid much attention).

[Selur]

Sadly those files also give me:
---------------------------
SVSmoothFps: unable to init GPU-based renderer
---------------------------
I used:
[code]LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\files\test.avi
# input color sampling YV12
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
# current resolution: 640x352
InterFrame(GPU=true,NewNum=60,NewDen=1,Cores=32)
# filtering
PreFetch(16)
return last
When using AvisynthMT with:
SetMemoryMax(768)
SetMTMode(5,16) # changing MT mode
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
# loading source: F:\TestClips&Co\files\test.avi
# input color sampling YV12
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
# current resolution: 640x352
SetMTMode(2) # changing MT mode
InterFrame(GPU=true,NewNum=60,NewDen=1,Cores=32)
distributor()
return last
everything works. (Side note: when using 'GPU=False' it works in both)

[StainlessS]

SubJunk has later version script (v2.8.2):- https://forum.doom9.org/showthread.php?t=160226

EDIT: And I've never used it much, and never with GPU=True.

[Selur]

Tried that one with the binaries it comes with.
Same result, GPU=True works fine with AvisynthMT, doesn't with Avisynth+.
never with GPU=True.
That explains why it works for you.

[wonkey_monkey]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

vi.GetPlaneHeightSubsampling(PLANAR_U);
vi.GetPlaneWidthSubsampling(PLANAR_V);


Is that it?

[pinterf]

Is there some clip/colorspace property that denotes X and Y granularity for cropping, eg YV12 may crop on even boundaries both x and y,
and for YV411 multiple of 4 for x and 1 for y ?

Or does one have to inquire eg "Is420" and deduce that has same modulo requirements as YV12.

EDIT: Or extract Y plane and U plane and calculate it manually (last resort).
No. I supposed that GetPlaneWidthSubSampling was available but is wasn't.

[StainlessS]

Thanks Wonkey, I know how to do that in C, was wantin' script solution.
EDIT: I usually work it out manually in C, as GetPlaneWidthSubSampling() not available in v2.58 (I think).

I have this in RT_stats


RT_ColorSpaceXMod(clip)
Return int, the natural cropping XMod for clip colorspace, eg YV411=4, YV12=2, YUY2=2, RGB=1
v2.5 plugin dll limited to v2.58 colorspaces.

***
***
***

RT_ColorSpaceYMod(clip,bool "Laced"=true)
Return int, the natural cropping YMod for clip colorspace, eg YV411=1, YV12=2, YUY2=1, RGB=1
Laced, bool. Default true. If Laced==true, returns doubled YMod.
v2.5 plugin dll limited to v2.58 colorspaces.


EDIT: Thanx Pinterf, I guess its coming :)

[pinterf]

Sadly those files also give me:
---------------------------
SVSmoothFps: unable to init GPU-based renderer [code 0x10000]
---------------------------

Setting the same SetMemoryMax(768) for the avs+ script helps?

[StainlessS]

I usually use InterFrame (seldomly) via a much larger script, and with GPU=False and cores=1, [some machines I use with same script are single core without GPU]
however, just tried

AviSource("D:\B.avi")
Interframe(GPU=True,NewNum=60000,NewDen=1001,cores=32)

works ok.
I only have quad core(Core 2 Q9550) , and crap GPU (Nvidia GT 520, my Dell Optiplex 780 limited to 6.5 inch cards, and total PSU only 300Watt, GT 520 5.5 inch, full load 29Watts).
No idea if it is actually using the GPU, or not.

EDIT: OK, we do seem to be using the GPU
https://i.postimg.cc/rzTWg2CX/nv-GT520.gif (https://postimg.cc/rzTWg2CX)

EDIT: For me, CPU is about 40% faster than GPU.
EDIT: In above graphic, shows GPU load at 8.0%, also memory controller load=11.0%, both seem a bit underused for some reason.
EDIT: And CPU usage about same whether or not GPU=True.

[wonkey_monkey]

Since we're talking about GetPlaneWidthSubsampling, it looks like there's an error on the Wiki (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#GetPlaneWidthSubsampling_.2F_GetPlaneHeightSubsampling). YV16 should be 1/1 and YV411 should be 2/0. I think there are errors in both the table and the text.

I'd create an account and fix it myself but HTTPS doesn't work (which it really should in this day and age).

[pinterf]

Since we're talking about GetPlaneWidthSubsampling, it looks like there's an error on the Wiki (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#GetPlaneWidthSubsampling_.2F_GetPlaneHeightSubsampling). YV16 should be 1/1 and YV411 should be 2/0. I think there are errors in both the table and the text.

I'd create an account and fix it myself but HTTPS doesn't work (which it really should in this day and age).
YV16 is 1/0

[StainlessS]

YV16 should be 1/1
YV16 should be 1/0 [text is back to front, but table is correct, methinks]
YV411 should be 2/0
agreed, table is wrong

EDIT:
Text is back to front

YV16: GetPlaneWidthSubsampling(PLANAR_U) = 0 // since there is no horizontal subsampling on a chroma plane
YV16: GetPlaneHeightSubsampling(PLANAR_U) = 1 // since vertically there are two times less samples on a chroma plane compared to a plane which is not subsampled

[Selur]

Setting the same SetMemoryMax(768) for the avs+ script helps?
Sadly no.
works ok.
simplifying the script to

LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
InterFrame(GPU=True,NewNum=60,NewDen=1,Cores=32)

doesn't help. Only thing that works is switching from Avisynth+ to old AvisynthMT. First thought it to be a driver issue, but threw that assumption out once I realized that it works with 32bit Avisynth MT.

[wonkey_monkey]

YV16 is 1/0

Well I blame my error on the whole stupid 4:2:2 system!

[Groucho2004]

Sadly no.

simplifying the script to

LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow1.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\svpflow2.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\InterFrame2.avsi")
FFVideoSource("F:\TESTCL~1\files\test.avi",cachefile="E:\Temp\avi_078c37f69bb356e7b5fa040c71584c40_41_1_0.ffindex",fpsnum=25)
InterFrame(GPU=True,NewNum=60,NewDen=1,Cores=32)

doesn't help. Only thing that works is switching from Avisynth+ to old AvisynthMT. First thought it to be a driver issue, but threw that assumption out once I realized that it works with 32bit Avisynth MT.I can't reproduce this problem. Can you upload the exact files you're using (ffms2.dll, svpflow*.dll, InterFrame2.avsi)?

[Selur]

here you go: https://drive.google.com/open?id=1w3aBlj3N9zdJGHrhEif5V4r8EA9goez8
using a GeForce GTX 1070 Ti with 418.81 drivers and a Amd Ryzen 7 1800X.

[pinterf]

Meanwhile a question regarding "Layer". I have the YUV stuff made ready but I experienced one little problem.

Layer mode: darken and ligthen is giving different results for RGB32 and YUY2 when Threshold>0

Even classic Avisynth 2.6.0.5 is giving different results for me.

Wiki:
http://avisynth.nl/index.php/Layer

E.g.: lighten:
"Copy overlay_clip over base_clip in areas where overlay_clip is lighter by threshold. Performs the same operation as add, but only when overlay_clip is BRIGHTER than base_clip."

And the relevant code from Avisynth+

Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0
}


YUV:

if constexpr (mode == LIGHTEN) {
alpha_mask = (thresh + ovr) > src ? level : 0;
}
else {
alpha_mask = (thresh + src) > ovr ? level : 0;
}


The variable names are different a bit but one can see the difference. Sure, they are equivalent when thresh is 0.

Which computation covers the text definition?

Script to reproduce:

x=some source
x = x.Spline16Resize(512,256)
ovr=ColorbarsHD().Spline16Resize(x.width,x.height)
clipRgb = x.ConvertToRGB32(matrix = "PC.709").ResetMask()
ovrRgb = ovr.ConvertToRGB32(matrix = "PC.709").ResetMask()
clipYuy2 = x.ConvertToYUY2()
ovrYuy2 = ovr.ConvertToYUY2()

threshold=255 # 0 is O.K.
# which one works fine?
testRgb = Layer(clipRgb, ovrRgb, "lighten", level=128, Threshold=threshold)
testYuy2= Layer(clipYuy2, ovrYuy2, "lighten", level=128, Threshold=Threshold)

StackVertical(testRgb.ConvertToYV24(matrix = "PC.709"), testYUY2.ConvertToYV24())

[Groucho2004]

here you go: https://drive.google.com/open?id=1w3aBlj3N9zdJGHrhEif5V4r8EA9goez8
using a GeForce GTX 1070 Ti with 418.81 drivers and a Amd Ryzen 7 1800X.Using your files I can reproduce the problem on Win7 (in a VM -> VMWare generic graphics driver). Also, it crashes with every (2.6) Avisynth version, not just AVS+.

It works fine on XP/XP64 (GTX750, 350.12 driver). :confused:

[Selur]

Okay, for me it doesn't crash with Avisynth MT 2.6 (https://drive.google.com/open?id=1C0G_x5A4Wylf3k1zqFY7On5-_cLCaMj4), strange it crashes for all Avisynth 2.6 for you.

Cu Selur

[StainlessS]

Which computation covers the text definition?

"Copy overlay_clip over base_clip in areas where overlay_clip is lighter by threshold.

I would say this one.


// Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0 // EDIT: Although I think this also wrong, see later.
}


EDIT:

isn't this for YUV lighten

alpha_mask = (thresh + ovr) > src ? level : 0;

equiv to this [if so then methinks obviously wrong]

alpha_mask = ovr > (src - thresh) ? level : 0;


EDIT: And is this correct for darken
Copy overlay_clip over base_clip in areas where overlay_clip is darker by threshold.

// Rgb32:

if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > thresh + luma_src ? alpha : 0;
} else {
alpha = luma_ovr < thresh + luma_src ? alpha : 0

}

Should it be

alpha = luma_ovr < (luma_src - thresh) ? alpha : 0


EDIT: Or in full as here: (3 out of the 4 original lines look messed up to me)

//RGB:
if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > (luma_src + thresh) ? alpha : 0; // As original
} else { // EDIT: DARKEN
alpha = luma_ovr < (luma_src - thresh) ? alpha : 0
}


//YUV:
if constexpr (mode == LIGHTEN) {
alpha_mask = ovr > (src + thresh) ? level : 0;
}
else { // EDIT: DARKEN
alpha_mask = ovr < (src - thresh) ? level : 0;
}


EDIT: I remember in some thread, that RaffRiff42 got some weird results from Layer, and could not figure out why, maybe this was it.

[pinterf]

EDIT: Or in full as here: (3 out of the 4 original lines look messed up to me)

//RGB:
if constexpr(mode == LIGHTEN) {
alpha = luma_ovr > (luma_src + thresh) ? alpha : 0; // As original
} else { // EDIT: DARKEN
alpha = luma_ovr < (luma_src - thresh) ? alpha : 0
}


//YUV:
if constexpr (mode == LIGHTEN) {
alpha_mask = ovr > (src + thresh) ? level : 0;
}
else { // EDIT: DARKEN
alpha_mask = ovr < (src - thresh) ? level : 0;
}



I spent too much time yesterday with not understanding what really happens and why my code produces different results than existing rgb version. I was thinking it over by a bottle of dark Staropramen :) and finally voted for this very same logic.

"Where overlay is brigher by threshold" =>
Where overlay is brigther by 10 =>
Where overlay > src + 10

and "Where overlay is darker by threshold" =>
Where overlay is darker by 10 =>
Where overlay < src - 10

[LigH]

Powered by beer™

[ajp_anton]

As far as comments concerned, below is demo of how handy '[* ... *]' is,

code...


Its use totally evaded me until RaffRiff42 pointed it out some time ago [I had even forgot that it existed as a comment option], the nesting comments can be very useful.

EDIT: Above is not prototype for current posted DDG, will be as above in next version.

But I would love to be able to do

Function DropDeadGorgeous(clip c,String DB,Int "ScanAhead", Int "X",Int "Y",Int"W",Int "H",Bool "Show", Bool "Verb",
\
\ Int "Prefilter", # Prefilter
\ Int "SPad", Int "SPel", Bool "SChroma", Int "SSharp", Int "SRFilter", # MSuper
\ Int "ABlkSize", Int "ABlkSizeV", # MAnalyse
\ Int "ASearch", Int "ASearchParam", Int "APelSearch", # MAnalyse
\ Bool "AChroma", Bool "ATrueMotion", # MAnalyse
\ Int "AOverlap", Int "AOverlapV", # MAnalyse
\ Int "ADct", Bool "ATryMany", # MAnalyse
\ Int "RthSAD", Int "RBlkSize", Int "RBlkSizeV", # MRecalculate
\ Int "RSearch", Int "RSearchParam", # MRecalculate
\ Bool "RChroma", Bool "RTrueMotion", # MRecalculate
\ Int "ROverlap", Int "ROverlapV", Int "RDct", # MRecalculate
\ Float "Iml", Bool "IBlend", Int "IthSCD1", Int "IthSCD2", # MFlowInter
\
\ Int "SOSthSCD2"
\ )


# is just a lot more handy when doing some quick coding, especially when you just want to quickly comment and un-comment a single line in the middle of a chain of \'s. And # is easier to write, with a european keyboard you need a lot of awkward keypresses with altgr for [ and shift for *.

[StainlessS]

@ajp_anton,

I imagine that your requirement would involve quite a lot of tricky work and probably at multiple places in the parser source code (with potential for lots of new and exciting bugs for the user, even in long existing scripts).
EDIT: Not sure if it would be worth the risk.

[almosely]

Hi,

after migrating from AviSynth 2.6.0 MT (SEt) (x86) to AviSynth+ 0.1.0 r2772 MT (x64) - and changing some filters - I discovered some things, that should be helpful to know for everybody else.

1) I switched from DGSource (from DGDecNV 2052) to DGSourceIM (beta 50) and discovered, that DGSourceIM is very unstable in general. Whether I used AVS 2.6.0 (x86) in ST/MT-Mode or AVS+ (x64) ST/MT, my encodings crashed (started with Simple x264 Launcher) at random times (error message something like "encodin process is not responding anymore" within Simple Launcher), but only full encodes, never compression or AVSMeter tests. So I switched back to DGSource and let my GeForce GTX 660 Ti do the decoding job. That is completely stable again.

2) I tried to save energy. That has been the reason in first place to switch to AVS+ and exchange DGSource against DGSourceIM too (I have a Core i5-3470 CPU with integrated Intel HD Graphics 2500 iGPU). To get that running, I have to enable Multi-Monitor-Support for my iGPU within my ASUS-BIOS (as the second GPU) and than enable a second imaginary screen output within Windows 7 to the HD Graphics, so that QuickSync (and the iGPU in general) became available at all. I did that becaus the GTX consumed 24 Watts extra only for decoding with DGSource and another 9 Watts extra for using FFT3DGPU. DGSourceIM is using just 1 Watt extra for the decoding job and FFT3DFilter (CPU based) is slowing down the encoding just 9%. So I was saving aprox. 30-50% of energy for the encoding task in the end. But, because of the strong unreliability of DGSourcIM I had to switch back the DGSource (and my GTX). Then I discoverd, that the GTX is switching from it's P8 Performance State (lowest) to P0 (highest) at the moment of using DGSource or FFT3DGPU, which results in that tremendously insane energy consuming. It is not switching away from P8 when decoding video-clips within Firefox, but it is also switching when using LAV-Filters within MPC-HC btw. So, I discovered a neat function of the Nvida Inspector tool, called Multi Display Power Saver (available through right-clicking the button "Show Overclocking"). Within there I restricted the GTX to the permanently use of the P8 Performance Level and let the Multi Monitor Power Saver autostart with Windows 7. That reduced the power consuming to the level of using the HD Graphics for decoding with DGSourceIM, but using DGSource of course. And there are no setbacks at all by letting the GTX running with P8 state permanently. There's also an option, to let the GTX run with either P5 or P0, when a specific .exe file is running, so just put the .exe of a game etc. as an exception there, and everythin runs fast and sound where it's needed. FFT3DGPU is running too slow with P8-State, but maybe fast enough with P5 - but, I do not use FFT3DGPU anymore, because FFT3DFilter is saving much more energy and is way better quality wise.

3) While getting used to AVS+ I discovered the mtmodes.avsi file, where a lot of MT-Modes are tested and predefined already. There's the need to change something (for everybody):

SetFilterMTMode("CompTest", MT_SERIALIZED)
SetFilterMTMode("ColorMatrix", MT_SERIALIZED)
SetFilterMTMode("RequestLinear", MT_SERIALIZED)
SetFilterMTMode("GradFun3", MT_MULTI_INSTANCE)

and remove the the following at the very end:

if (FunctionExists("avstp_set_threads")) {
# this isn't actually optimal, because it will also disable avstp threads if running
# on a single-threaded filter chain
avstp_set_threads(0, 1)

and put instead the following line within your personal .avs-script at the end, right before Prefetch(), but only when activating MT-Mode (using prefetch).

avstp_set_threads(1)

AVS+ is running faster (and still stable) when letting avstp do it's internal mt-job when using GradFun3-Filter in ST-Mode. There's no need to deactivate it in general, only for MT. And this line has to be set at the "very" end of the avs-script, as pointed out by the developer of avstp.dll. It is working - I tested it with AVSMeter by watching the amount of threads.

ColorMatrix is running absolutely fine in MT-Mode within AVS+ (x64), but only it it's placed within a bubble of sequential frame order. So, to ensure that, RequestLinear has to be used and to be defined as MT_SERIALIZED. It makes no sense to use RequestLinear as MT_MULTI_INSTANCE. Therefore the following sript is working totally fine for me (I tested it multiple times with ST and MT encodings of the same clip) - no differences within the x264 logfiles. I did encounter differences when not using RequestLinear as MT_SERIALIZED of course.

DGSource()
CompTest(5, 60)
ColorMatrix(hints=true)
RequestLinear(rlim=50, clim=50)
...
avstp_set_threads(1)
Prefetch(3)
return last

That's working just fine as an example.

[videoh]

1) I switched from DGSource (from DGDecNV 2052) to DGSourceIM (beta 50) and discovered, that DGSourceIM is very unstable in general. True. DGDecIM is deprecated due to crappy Intel support/drivers. I should withdraw it.

Thank you for your interest in DG tools!

[DJATOM]

True. DGDecIM is deprecated due to crappy Intel support/drivers. I should withdraw it.

Thank you for your interest in DG tools!

Well, I hope you'll add SW decoding in DGDecodeNV someday or implement another tool for that. We only have LWLibavSource and DGDecodeIM(..., engine=2) options for encoding on servers w/o NVidia GPU.

[manolito]

@ almosely

Thanks very much for your post about AVS+ settings and mtmodes.avsi. The settings you suggested seem to completely avoid the crashes I had with AVS+ so far... :D

I often convert my DVB-T2 TV captures from HD HEVC to SD AVC (old school like yourself, I still watch my movies on a CRT TV set). I use StaxRip (older 32-bit version), my AVS scripts are quite basic, and I was interested in AVS+ solely for some speed gains through the MT capability. High bit depth and fancy color spaces are not my thing. I also use 32-bit tools exclusively, my laptop is a ThinkPad with a Core i5 3rd generation CPU and 8GB RAM.

But up to now I could not get it stable with AVS+, I randomly got crashes just like the ones you described (Win7-64). This happened with and without the mtmodes.avsi, taking out filters one by one did not help, only way to get it stable was to disable MT. So I repeatedly reverted to good old AVS 2.61.

Last night I applied your suggested changes and did 2 long conversions, and to my surprise everything was absolutely stable. Of course I need to do more conversions to be sure, but it does look very promising. I have no idea which one of your suggestions did the trick, though. My script does contain ColorMatrix, maybe this was the culprit. The other thing which really surprised me was that avstp_set_threads made a difference. For all I know my script does not use any avstp-aware filter, still the encode got a little bit faster when I added the command before the prefetch call. Do you have an explanation?

Whatever, thanks again for your tips. You should update the mtmodes.avsi here:
http://avisynth.nl/index.php/AviSynth%2B#Help_filling_MT_modes

so others can profit from the changes, too.


Cheers
manolito


//EDIT//
Oops, I forgot one thing...
All of the above is for using DSS2Mod as my source filter. My overall speed increase by using AVS+ with these settings is about 1fps for 4 threads. With 3 threads the speed is almost the same.

But when using ffms2 as my source filter (latest stable GitHub version 2.23.1) the encoding speed drops considerably after a few minutes into the encode. About 5fps slower than with AVS 2.61. Not good, what could cause this?

[Groucho2004]

But when using ffms2 as my source filter (latest stable GitHub version 2.23.1) the encoding speed drops considerably after a few minutes into the encode. About 5fps slower than with AVS 2.61. Not good, what could cause this?Have you tried the "threads = 1" parameter with ffms2?

[almosely]

@manolito

You're welcome! Nice, I could help someone with my discoveries :-)

[GMJCZP]

I took the liberty to prepare mtmodes based on almosely's observations. I post it here and not on its corresponding page to continue the tests and subsequent discussions. Thanks almosely.

Here (https://www.filedropper.com/mtmodes02122019_1)

[manolito]

Have you tried the "threads = 1" parameter with ffms2?

Thanks for the tip, I tried it, but this parameter really backfired... :scared:

With the default "threads=-1" which uses the number of logical cores reported by Windows (4 in my case) I got a speed of 21.47 fps. Using "threads=1" the speed dropped to 15.66 fps. With DSS2Mod the speed was 24.49 fps.

After many more speed benchmark tests I can say that the AVS+ MT feature is not all that useful when using very basic AVS scripts which I usually do. The real speed difference gets obvious when using more complex scripts like the MysteryX FrameRateConverter script. This script makes extensive use of MVTools, and here I get a speed difference of almost 80%.


Cheers
manolito

[LigH]

Hint: FFMS2 and L-SMASH Works may use different splitters, which also affects the following decoder. So compare FFVideoSource with LwLibavVideoSource (and possibly even LSMASHVideoSource for ISO Media containers, like MP4 / MOV / 3GPP) too.

[manolito]

Yes, I will check this out on my next conversion later tonite...
Can you recommend a version which causes the least possible problems? (including download link) And would LSMASHVideoSource work for HEVC in an MKV and TS/MTS container?

[LigH]

1. MeGUI provides a well tested version. I won't guarantee for "the best that there is", though. Unfortunately, it is not regularly rebuilt, and the most recent version (https://forum.doom9.org/showthread.php?p=1843162#post1843162) may have some flaws (e.g. using AviSynth 2.5 headers).

2. No, LSMASHVideoSource does not support MKV or TS containers, only containers compliant to the ISO base media file format (https://en.wikipedia.org/wiki/ISO_base_media_file_format). For all other containers, you will need LwLibavVideoSource using the libavformats demultiplexers and its indexer. Decoding HEVC should be supported.

[StainlessS]

ISO base media file format


Function IsISOFileName(String s) { s=Lcase(RT_GetFileExtension(s)) Return(s==".mov"||s==".mp4"||s==".3gp"||s==".3g2"||s==".mj2"||s==".dvb"||s==".dcf"||s==".m21")}

If you dont use RT_, maybe make your own "GetFileExtension, reverse string, look for '.', chop off extension, reverse extension.

[manolito]

Thanks LigH for your LSMASH links.

I did a couple of speed benchmark tests using the usual source filters (sorry, no DG filters), and these are the results:

Source was again a captured German DVB-T2 file. 1080p HEVC at 50 fps, converting it to SD AVC using StaxRip. Very basic AVS script, it did include ColorMatrix and the VDub filter Logoaway. Everything 32-bit. Using the current AVS+ MT 32-bit build, added the almosely tweaks to the MTModes.avsi. Using 4 threads on my Core i5 3rd generation everything runs stable, no crashes.

FPS tests were done with the latest X264 build by LigH, I want to test the overall speed, just testing the script with AVSMeter is misleading for me.


DSS2Mod (preroll=15) : 25.83
ffms2 2.23.1 : 22.91
ffms2000 test 8 : 23.04
LWLibav r784 XP : 24.40
LWLibav r929 : 24.44
LWLibav r941 : 24.41

All FPS measurements were taken at 10% into the encode. The clear winner is DSS2Mod followed by LWLibav. The old XP version which does not even need SSE2 is just as fast as the later versions.


Cheers
manolito

[wonkey_monkey]

Some more errors on the Wiki?

http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API/VideoInfo#IsRGB_.2F_IsRGB24_.2F_IsRGB32

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).

That can't be right, can it? Same just below:

bool IsYUV() const;
bool IsYUY2() const;
bool IsYV24() const; // v5
bool IsYV16() const; // v5
bool IsYV12() const;
bool IsYV411() const; // v5
bool IsY8() const; // v5

All of them will return true if the colorspace is YUV (in any way). The last six return true if the clip has the specific YUV colorspace (YUY2, YV24, YV16, YV12, YV411 and Y8).

Maybe I'm missing something but I don't think that makes sense.

[Groucho2004]

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).

That can't be right, can it?
Makes sense to me (as does the YUV logic). Can you elaborate on your objection?

[wonkey_monkey]

"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.

[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

[StainlessS]

Manolito link better than mine (I did not have All In One link handy).

You would likely need all of the dll's anyways (eventually).

[a1s2d3f4]

AIO link didn't have redistributable 2015.
I used StainlessS direct link to install those.
Also, I installed Universal Avisynth Installer [2018-12-22]. It mentions having the latest AVS+

[StainlessS]

Actually, I think that VS2017, and VS2015 runtimes are exactly the same (not sure, might be 2013 and 2015 same), but it would not do any harm to install both, maybe.
Groucho AVS AOI installer is real good, I'm in never ending process of installing dll's for v2.58, v2.60, avs+ x86 and x64 (partly because I'm updating my plugins to x64).
Remember to also use Groucho2004 AvsMeter to check plugins OK, and make REGULAR backups (when modding dll's) of the Videotools\AvisynthRepository\ directory.
Avs+ defo runs smoother, when sorted out, its just that it sometimes takes a while to get to the sorted out stage, especially if you've been running 2.5x up to now.

The old AVS+ from 1st post, is under control of Ultim, and he no longer visits, you aint the first to download the wrong/old version dll, think I probably did that too.

[pinterf]

VS2017 simply replaces VS2015 redistributables.

[wonkey_monkey]

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

Anyway, to my point, which is a modest proposal.

I'm developing a filter which necessitates the passing of, for want or a better word, metadata between clips. Traditionally non-video data has been passed around as video in special clips, like MVTools's "super" clips, but this (not necessarily what MVTools does, but other filters doing similar things) is a bit of a bodge. Of course it's necessary because Avisynth has nothing for passing around data otherwise. I believe one of the DG tools uses the low bits of the first few pixels to pass data, for example.

What I'm doing with my new filter (and what I've previously done with warp (https://forum.doom9.org/showthread.php?p=1862943)) is abusing GetAudio. If it's called with start=1 and count=3, which is extremely unlikely to ever come up in the real world, and if the passed buffer starts with a special integer, then my code takes over and instead of filling the buffer with audio, it fills it with whatever information the child filter (backwards terminology from Avisynth's, don't get me started on that one) has requested by way of other data in the passed buffer.

By doing this, I can chain commands to add more and more metadata, all of which can be "bubbled up" to the ultimate descendant. Best of all it's completely transparent to VirtualDub2 (my viewer of choice) because all audio is passed through normally, so I only ever have one clip to pass to the actual "doing something" filter at the end of the chain.

But it still has some caveats, namely that audio filters can't be trusted not to destroy my metadata. And if a clip doesn't have audio to start with, it has to be added (and can't be removed until after the final filter runs).

So I was wondering if such a system could be implemented in Avisynth separate to GetAudio. GetData, perhaps. By just passing a pointer to a buffer - or maybe have one other integer parameter as well, for simplicity/flexibility - the system could be made extremely flexible but infinitely adaptable. For a start, custom clip properties would then be easy to implement as a plugin.

As far as I can tell all it would take is adding an extra member function to GenericVideoFilter which, by default, simply passes its parameter(s) down (up?) to the parent (the confusingly-named "child" in GenericVideoFilter), or, if there is no parent, does nothing. Filter writers can then override this to their heart's content.

Anyway, that's just my thought. Maybe it's a terrible idea for reasons which haven't occurred to me.

[pinterf]

I installed VS2017 alongside VS2013 recently and the resulting compiled filters were significantly (10-20% or so) slower than VS2013. Just thought I'd mention that in passing.

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.
Then, I think new projects in VS2017 are defaulting to handle spectre mitigation (https://devblogs.microsoft.com/cppblog/spectre-mitigation-changes-in-visual-studio-2017-version-15-7-preview-3/).
There can be a speed difference between MT and MD builds.
Check for possible AVX2-SSE2 transition penalties if any of your code has AVX2.

[wonkey_monkey]

I'd say it cannot be slower and there must be a reason for that. 10-20% is an enourmous difference and cannot be explained by a simple difference in optimization.
I'd look at the generated assembler code.

That's probably it. I didn't realise it had also been added to compilers.

Edit: further investigation suggests it isn't enabled by default, but also that the slowdown isn't as bad as I remembered. It's still slower with VS2017 though.

[pinterf]

That's probably it. I didn't realise it had also been added to compilers.

Edit: further investigation suggests it isn't enabled by default, but also that the slowdown isn't as bad as I remembered. It's still slower with VS2017 though.
I'm still interested in which type of code gets optimized worse in newer compilers. I suppose they are not simple simd optimized stuff.

[wonkey_monkey]

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.

[pinterf]

Maybe there are new optimisations which have slightly detrimental effects on older processors, or in certain circumstances. I expecting there are halting-problem type problems with trying to apply the best optimisations on all occasions.

The difference is slight enough that it could be any of several parts of my program. The busiest loop is full of ifs and switches and SSE.
For the busiest part of the code using templates (even for longer functions) can make wonders, avoiding thousand of ifs and switches in an inner loop has also big advantage on the optimization. Letting know the compiler to use constants (given as template parameters) instead of variables is also a big help. I don't know the actual situation but it would help a lot. Explicitely forceinlined functions can give further gain as well.

[manolito]

https://forum.doom9.org/showthread.php?p=1865439#post1865439

Sorry I spoke too soon, the joy only lasted for 3 weeks... :scared:

Last night I tried to convert a longer movie (2 and a half hours), and I got the crashes again. And it was reproduceable.

My AVS script:
DSS2("D:\Black Mass.mkv", fps=50.000, preroll=15)
Crop(0,0, -Width % 4,-Height % 4)
ColorMatrix(source=0,dest=2)
RequestLinear(rlim=50, clim=50)
ConvertToYV12()
Spline36Resize(704,396)
FDecimate(25)

# Start Remove Logo
Import("I:\Logo\Area.avs") #Defines the X and Y coordinates of the logo area
ConvertToYV12(interlaced=false)
Logo = crop(X1,Y1,X2-X1,Y2-Y1)
Above = Y1 > 0 ? crop(0,0,width(),Y1) : NOP()
Below = Y2 < height() ? crop(0,Y2,width(),height()-Y2) : NOP()
Left = X1 > 0 ? crop(0,Y1,X1,Y2-Y1) : NOP()
Right = X2 < width() ? crop(X2,Y1,width()-X2,Y2-Y1) : NOP()
ConvertToRGB32(Logo,interlaced=false)
LoadVirtualdubPlugin("E:\Programme\Virtualdub\Plugins\logoaway.vdf","VD_LogoAway")
# -----------------------------------------------------------------------------
VD_LogoAway( 3, 327685, 9895963, 0, 0, 5, 0, 66051, 131584, 10, "", "", "")
# -----------------------------------------------------------------------------
ConvertToYV12(interlaced=false)
IsClip(Left) ? StackHorizontal(Left, last) : NOP()
IsClip(Right) ? StackHorizontal(last, Right) : NOP()
IsClip(Above) ? StackVertical(Above, last) : NOP()
IsClip(Below) ? StackVertical(last, Below) : NOP()
last
# End Remove Logo

FineSharp()
avstp_set_threads(1)
Prefetch(4)
Trim(4248,161424)

This script is really not very complex. almosely's changes slowed it down quite a bit (adding Requestlinear after ColorMatrix and selecting MT_SERIALIZED for both ColorMatrix and RequestLinear), so the speed gain of MT was only about 1fps. Reducing the prefetch value to 2 did not make a difference, still I got crashes. Only disablng MT altogether made the script stable.

For my needs I do not see any advantage of using AVS+ over classic AVS 2.61. I reverted back to AVS classic, probably for good this time. (Unless someone comes up with a genius idea to use MT without crashes and still get a better speed).


Cheers
manolito

[VS_Fan]

... For my needs I do not see any advantage of using AVS+ over classic AVS 2.61. I reverted back to AVS classic, probably for good this time. (Unless someone comes up with a genius idea to use MT without crashes and still get a better speed).I remember some years ago having problems with frame decimation in a Multi-Threaded environment (old AVS-MT) and trying innumerable different configurations for ‘RequestLinear’ to no avail.

What I successfully ended doing was:

Separating only the source, decimation with any other ‘MT_SERIALIZED’ filters in one Single-Threaded AVS script, No need of of using 'requestlinear';
Then I either: ‘mounted’ that first script with AVFS; or simply read it directly with “AVIFileSource” into a second MultiThreaded AVS script where I put every other processing filters, susceptible of speed gains because of multi-threading

I don’t think this is genius idea, but I sincerely hope it helps :)

[an3k]

I have a Plugin (DGHDRtoSDR) that is not yet listed in the mtmodes.avsi and I would like to test (and add) it. I've searched but not found the info thus I asked here.

1) What is the "single-thread" mtmode in which every plugin perfectly runs at (since it's "non-MT-behavior")? Is it NICE_FILTER or SERIALIZED?

2) What is the most performant mtmode we would love to have all plugins running at? MULTI_INSTANCE?

Thanks :)

[TheFluff]

I remember some years ago having problems with frame decimation in a Multi-Threaded environment (old AVS-MT) and trying innumerable different configurations for ‘RequestLinear’ to no avail.

What I successfully ended doing was:

Separating only the source, decimation with any other ‘MT_SERIALIZED’ filters in one Single-Threaded AVS script, No need of of using 'requestlinear';
Then I either: ‘mounted’ that first script with AVFS; or simply read it directly with “AVIFileSource” into a second MultiThreaded AVS script where I put every other processing filters, susceptible of speed gains because of multi-threading

I don’t think this is genius idea, but I sincerely hope it helps :)

It's might be simpler than that. As far as I can tell FDecimate isn't in mtmodes.avsi, but since it's a m-in-n decimation filter it's almost certainly very stateful and not at all threadsafe. Setting it to MT_SERIALIZED might very well fix the crashing.

That said, the filter chain in that script is so full of ancient serialized junk so far down into the chain that the only thing of note that runs parallelized at all is FineSharp (I don't think vdub filters are MT_NICE? who knows though), so it's no wonder it's not any faster. As a reminder, inserting a MT_SERIALIZED filter into a filter chain will effectively cause every filter upstream of it all the way up to the source filter to run serialized too, at least as far as performance goes.

I have a Plugin (DGHDRtoSDR) that is not yet listed in the mtmodes.avsi and I would like to test (and add) it. I've searched but not found the info thus I asked here.

1) What is the "single-thread" mtmode in which every plugin perfectly runs at (since it's "non-MT-behavior")? Is it NICE_FILTER or SERIALIZED?

2) What is the most performant mtmode we would love to have all plugins running at? MULTI_INSTANCE?

Thanks :)

1) MT_SERIALIZED.

2) MT_NICE_FILTER.

See here (https://forum.doom9.org/showthread.php?t=174437) for more details. As mentioned above, using a MT_SERIALIZED filter late in a chain effectively disables MT (you'll be so bottlenecked that MT doesn't help you much).

If you're using Vapoursynth though you can get some degree of parallelism even with serialized Avisynth filters, which you can't do in Avs+ itself. In Avs+, calling GetFrame on a serialized filter will essentially run every filter upstream of that point single threaded too, so requesting a frame will make the entire thing block until the entire chain is finished processing that frame, one filter at a time in a single thread. In VS, you still get a single instance of the serialized filter (in its own pretend environment) and it will only ever be asked to process one frame at a time, but upstream of it can run in parallel.

[TheFluff]

I don't know who maintains the MT modes list anymore, or if the PublishWithMe pad is still the single source of truth, but colormatrix should, uh, probably not be marked as a MT_NICE_FILTER. The publishwithme pad itself notes that it seems very broken even when MT_SERIALIZED. Newer versions are internally multithreaded, and it's always done a lot of funky stuff internally (like requesting frames from the constructor and Invoke()'ing a lot of stuff).

That said, don't use colormatrix, it's always been a piece of buggy garbage.

[DJATOM]

Yeah, my friend used it in his scripts and it silently kills avs2yuv without any error. The only plugin that really piss me off...

[manolito]

...but colormatrix should, uh, probably not be marked as a MT_NICE_FILTER.

Did you have a look at this post?
https://forum.doom9.org/showthread.php?p=1865279#post1865279

ColorMatrix is running absolutely fine in MT-Mode within AVS+ (x64), but only it it's placed within a bubble of sequential frame order. So, to ensure that, RequestLinear has to be used and to be defined as MT_SERIALIZED. It makes no sense to use RequestLinear as MT_MULTI_INSTANCE. Therefore the following sript is working totally fine for me (I tested it multiple times with ST and MT encodings of the same clip) - no differences within the x264 logfiles. I did encounter differences when not using RequestLinear as MT_SERIALIZED of course.


Applying these changes made my conversions a lot more stable, until a couple of days ago I got crashes again while converting a longer movie. Now I additionally specified MT_SERIALIZED for FDecimate, the first 2 conversions went well, let's see if it lasts...

[manolito]

Did some more speed benchmark tests using a long 2:40 movie (Heat by Michael Mann). I basically used the script from a couple of posts above. I did get a small speed gain by moving the FDecimate(25) call to the top of the script right after the source filter, and so far everything was stable.

I also tested the same source using z_ConvertFormat replacing ColorMatrix, RequestLinear and the built-in resizer. It worked nicely, but even in the default MT_MULTI_INSTANCE mode it was about 0.5 fps slower than the other script (ColorMatrix and RequestLinear both in MT_SERIALIZED mode). So as long as the script with ColorMatrix is stable for me I see no reason to ditch it.

For the SetMTMode.avsi I don't know if anybody is actively maintaining it. I uploaded my modified version here:
https://www.sendspace.com/file/3pdsc8
All comments were removed, also all MT_MULTI_INSTANCE calls were deleted (not necessary, MULTI_INSTANCE is the default).


Cheers
manolito

[poisondeathray]

So as long as the script with ColorMatrix is stable for me I see no reason to ditch it.



Quality wise, ColorMatrix produces color splotches and noise compared to higher quality methods. It's more noticable on animation , gradients ; less noticable on live action, film grain sources

[manolito]

Quality wise, ColorMatrix produces color splotches and noise compared to higher quality methods.

So far I am only aware of z_ConvertFormat as a "higher quality method" under AVS. Which other methods are you talking about?

Plus your statement about ColorMatrix producing color splotches and noise is quite new to me. So far I was only aware of Fluffy's statement that ColorMatrix was not suitable for MT under AVS due to questionable coding methods which offended his professional standards. Now you are talking about quality issues even when used in single threaded scripts.

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?

[poisondeathray]

So far I am only aware of z_ConvertFormat as a "higher quality method" under AVS. Which other methods are you talking about?

Plus your statement about ColorMatrix producing color splotches and noise is quite new to me. So far I was only aware of Fluffy's statement that ColorMatrix was not suitable for MT under AVS due to questionable coding methods which offended his professional standards. Now you are talking about quality issues even when used in single threaded scripts.

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?



Yes z.lib (z_ConvertFormat in avisynth), or AviSynthShader, probably Dither tools too. Basically anything else

709<=>601 either direction. Just compare ColorMatrix , it's easier to see on anime, cartoons . I'll post something tomorrow, there were some threads about this too.

[poisondeathray]

Can you provide some proof of your statement? A source segment where a color conversion from Rec.709->Rec.601 reveals quality problems like color splotches and noise when using ColorMatrix?




@manolito - RE: colormatrix quality issues
https://forum.videohelp.com/threads/391207-Converting-rec-709-to-rec-601

(the OP only provided screenshot, and it was converted back to YV12 for the "new" source but it's quite easy to see the problems)

Observations (not just this example, but in general):
- not version dependent, I tried a few colormatrix dll's , and the "ported" to ffmpeg filter exhibits the same issue. Probably partially due to 8bit conversion
- not settings dependent in terms of colormatrix clamping values (I usually set clamp=0 anyways, but pre/post clamp doesn't help)
- more noticable with certain color combinations , certain patterns that predispose to the issue. But source noise, film grain can often cover up the problems
- can occur 601=>709 too , eg. with DVD's when upscaling to HD . There were some DVD examples in other threads, I'll try to dig them up if you're interested
- the "better" high bit depth conversions are not because of dithering only (ie. it's not solely because of "covering up"); because if you disable dithering you still get "cleaner" image without the splotches and artifacts . But you can experiment with dithering algorithms back to 8bit . fmtc in vapoursynth has several options , it's easy to compare in avspmod tabs for example, with vsimport . avs+'s default convertbits(8) will use ordered dither .

[manolito]

Thanks for digging out the VideoHelp thread, I went over it quickly, but I could not reproduce the findings.

My sources are always 8-bit with 4:2:0 chroma. And the conversion from HEVC HD to AVC SD keeps the video this way. No dithering involved, and the color space also stays the same.

Also I only convert films, no anime. I went over some of my conversions which used ColorMatrix carefully, and I could not detect any color artifacts. So my only valid reason to ditch ColorMatrix and use z_ConvertFormat instead would be a better MT speed, and right now I do not get this.


Cheers
manolito

[pinterf]

avs+'s default convertbits(8) will use ordered dither .
ConvertBits does not dither, you have to specify dither=0 or dither=1.

[TheFluff]

I guess I should point to the elephant in the room and ask why you're even converting to Rec601 at all, when metadata flagging has been the preferred solution for at least a decade. I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

[lansing]

I guess I should point to the elephant in the room and ask why you're even converting to Rec601 at all, when metadata flagging has been the preferred solution for at least a decade. I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

He wanted to playback on his CRT TV

[manolito]

I have a sneaking suspicion the answer probably involves some kind of arcane playback contraption from the late 1990's, though.

How in the world did you know that? :devil:

My playback device is an older (around 2010) Xtreamer Sidewinder connected to my CRT TV. It does not handle H.265, but it plays H.264 just fine. This means that my captured HEVC streams need to be converted to AVC anyways, and while I'm at it I can just as well reduce the resolution to SD 704x396 and decimate the framerate from 50fps to 25fps. This looks good on my TV.

My knowledge of the Rec709 and Rec601 standards is limited, but conventional wisdom says that HD is Rec709 while SD is Rec601. My captured sources are all 1080p50 and flagged as 709, so I figured that I need to convert them to 601 when I convert them to SD.

The data sheet of my Xtreamer unfortunately tells me nothing about which color it expects. The only way to check for the correct color is to switch between playback of the original stream through the DVB-T2 receiver and the converted SD stream through the Xtreamer. And this comparison does not show any color differences, so I guess I am doing it right...

[Groucho2004]

This means that my captured HEVC streams need to be converted to AVC anyways, and while I'm at it I can just as well reduce the resolution to SD 704x396 and decimate the framerate from 50fps to 25fps. This looks good on my TV.

My knowledge of the Rec709 and Rec601 standards is limited, but conventional wisdom says that HD is Rec709 while SD is Rec601. My captured sources are all 1080p50 and flagged as 709, so I figured that I need to convert them to 601 when I convert them to SD.
I'd use DitherTools for that process.

Edit - Example (https://forum.doom9.org/showthread.php?p=1769274#post1769274)

[goorawin]

Here is a script that works really well at converting 1920x1080x50p to 720x576x25i (DVD standard). You may need to change the SelectEvery, to get the field order correct. Also change the sharpen to suit the source material.

bicubicresize(1440,1152)
bicubicresize(720,1152,-.8,.6)
bicubicresize(720,576,-.8,.6)
blur(0.0,1.0)
sharpen(0.0,0.75)
assumeBff()
separatefields()
SelectEvery(4,1,2)
Weave()
Matrix(from=709, to=601)

[Groucho2004]

Matrix(from=709, to=601)[/I]
Is that pseudo code or an actual function?

[goorawin]

It's a function. It does a similar and I think, a slightly better job to
ColorMatrix(mode="Rec.709->Rec.601")

[manolito]

I think he is talking about the HDRMatrix plugin from VideoArtifact:
https://www.videoartifact.com/hdr/

[goorawin]

Yes that is correct, it uses HDRMatrix

[StainlessS]

Hi P, as you seem to have been missing for a few days (Thanks for RemoveDirt mod), thought you may have missed this:- https://forum.doom9.org/showthread.php?t=176193

See comments in script and purple subtitles for 32 bit YV16.

[pinterf]

Hi P, as you seem to have been missing for a few days (Thanks for RemoveDirt mod), thought you may have missed this:- https://forum.doom9.org/showthread.php?t=176193

See comments in script and purple subtitles for 32 bit YV16.

Thanks, noticed too and fixed on git last month.
https://github.com/pinterf/AviSynthPlus/commit/07b95934351f3b0809f62a611768aa367ffbaacb

Busy times, not released yet.

[StainlessS]

see Comment in blue here:- https://forum.doom9.org/showthread.php?p=1869006#post1869006

Quote by StainlessS

EDIT:
Looks like CR_IsReallyFloatOld(InDAR) is a missing RaffRiff42 avsi function,
and it will only work as intended on v2.58, not v2.60+,
In v2.60+, Float args where user supplied as Int, they are forcibly converted to Float by Avisynth, and so that function has no purpose in v2.60 or Avs+.
Due to this forcible conversion, you cannot tell whether or not user called with float or int arg.
[I would have been happier if had been left as it was originally]

EDIT:


Function test(float "f") {
S = (f.Defined) ? "Defined" : "NOT Defined"
f=Default(f,42)
s = S + " F="+String(f) + "\n"
Return S
}

S0=VersionString+"\n"
S1=Test()
S2=Test(1)
S3=Test(2.0)

S= S0 + S1 + S2 + S3

BlankClip(width=240,Height=100)

Subtitle(S,lsp=0)


Avs v2.58
https://i.postimg.cc/tJ5jkSLK/Avs258.jpg (https://postimages.org/)

Avs 2.60(+)
https://i.postimg.cc/mDWWsWRx/Avs260-Plus.jpg (https://postimages.org/)

EDIT: In v2.60+, if the guy that wrote the script function supplied the default arg as an int, then can still produce problems and so the original fix conversion to float arg
still dont work ideally, ie maybe should also convert Defaulted args to Float where the formal arg type (think thats what its called) is of eg type float.
If this was done, then I would be happier.

[MysteryX]

Does Avisynth+ include the audio quality improvements of TimeStretchPlugin natively? (compared to the TimeStretch of AVS 2.6)

[manolito]

Yes, I believe it does...

v2.61 Updated SoundTouch library to 1.9.2. Fixes multichannel issues

[tebasuna51]

Just to be clear, correct me if I am wrong.

- TimeStretchPlugin is a old (2015) plugin by Wilbert (https://forum.doom9.org/showthread.php?p=1722472#post1722472) to improve the TimeStretch internal function of AviSynth 2.58 to add support for multichannel audio.

- Like manolito say AviSynth v2.61 update the TimeStretch internal function to SoundTouch library 1.9.2. Then TimeStretchPlugin is not needed for v2.61, only for v2.58.

- From the begining AviSynth+ have the TimeStretch function in a external plugin TimeStretch.dll (with SoundTouch library 1.9.2) supplied with AviSynth+

- BTW the SoundTouch library version is now 2.1.1 (https://www.surina.net/soundtouch/README.html). I don't know if the the last TimeStretch.dll from Avs+ is updated.

[manolito]

TimeStretch history as far as I remember:

AVS 2.60 internal TimeStretch function (forgot the SoundTouch version) only supports stereo audio, multichannel not supported.

Next was the TimeStretch Plugin by Wilbert:
changelog:
* version: 2.5.8.0 (requires AviSynth v2.58)
* filter is named to TimeStretchPlugin
* multichannel support
* updated SoundTouch library to 1.8.0
This version did support multichannel audio sources.

Then AVS 2.61 Alpha had an even newer internal TimeStretch version:
Update to SoundTouch 1.9.0(Wilbert+IanB).


For AVS+ the docs are really not very informative. In the AVS Wiki the Timestretch version info says:
v2.61 Updated SoundTouch library to 1.9.2. Fixes multichannel issues

Since classic AVS was not updated for years I suppose that this info applies to AVS+. But I could not find any info in the AVS+ docs about the current TimeStretch version. And the DLL itself does not have any embedded version info.

[Groucho2004]

But I could not find any info in the AVS+ docs about the current TimeStretch version. And the DLL itself does not have any embedded version info.
https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/TimeStretch/SoundTouch/whence.txt

[tebasuna51]

Thanks Groucho2004, I can't remember where I read the Avs+ SoundTouch version but seems my memory still work a little.

[manolito]

ColorMatrix and alternatives under AVS+ MT

After many more tests using my Thinkpad Core i5 3rd generation (2 physical cores plus Hyperthreading) I think I know quite well what's going on here: :devil:

The good old tritical Colormatrix works well without crashes using the modifications suggested by almosely:
https://forum.doom9.org/showthread.php?p=1865279#post1865279

Colormatrix followed by RequestLinear, both in MT_SERIALIZED mode. I could not detect any artifacts of the kind described by PDR.

z_ConvertFormat uses MT_MULTI_INSTANCE through the SetMTMode.avsi (this is also the AVS+ default, no need to explicitly specify it). This might work for the z_Resizers, but if the matrix parameters are used, the script will crash. It needs MT_SERIALIZED for the matrix params.

For the HDRMatrix plugin the SetMTMode.avsi calls for MT_NICE_FILTER. This causes a crash immediately after starting the conversion. Specifying MT_MULTI_INSTANCE runs stable, but at a very low speed.

For me the old ColorMatrix plugin is the best so far. It is faster than the competition, and I did not detect any quality issues so far.

(I did not test DitherTools as suggested by Groucho. Way too complicated for me...)

Cheers
manolito

[pinterf]

https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/TimeStretch/SoundTouch/whence.txt
Changed :)
I've updated SoundTouch with current git version (2.1.3) (today's achievement, exists only on my git, not released)

[GhostAFRippEr]

i have not activeted MT how to i add .avs script ?

[LigH]

How to use multi-threading in AviSynth+?

Read: Avisynth Wiki – AviSynth+: 3. MT Notes (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes)

[qyot27]

It's been quite a while since the last time we tried this, so here's a GCC build of AviSynth+:
AviSynth+ (GCC) r2831-g316b54aa-20190321 (http://www.mediafire.com/file/s88qcoqcp108a0a/avisynth%252B-gcc_r2831-g316b54aa-20190321.7z)

And a corresponding pair of FFmpeg and mpv builds that include builds capable of handling otherwise-difficult 32-bit GCC builds of AviSynth+:
FFmpeg r93433+7 (http://www.mediafire.com/file/lj8zvwwg8mll1a2/ffmpeg_r93433%252B7.7z)
mpv r46865+11 (http://www.mediafire.com/file/7k1db8q3vxuc627/mpv_r46876.7z)

Unlike the previous GCC build of AviSynth+, it now will not interfere with your existing plugin folders. There is a separate registry entry and plugin folder path GCC builds look for, plugins+gcc. Examples below - change the path accordingly for where AviSynth+ is installed, but the point is that the plugins folder for GCC builds of AviSynth+ should be separate from the folder(s) for normal MSVC builds.

64-bit:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="E:\\Programs\\AviSynth+"
"plugindir2_5"="E:\\Programs\\AviSynth+\\plugins64"
"plugindir+"="E:\\Programs\\AviSynth+\\plugins64+"
"plugin+gcc"="E:\\Programs\\AviSynth+\\plugins64_gcc"
32-bit:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="E:\\Programs\\AviSynth+"
"plugindir2_5"="E:\\Programs\\AviSynth+\\plugins"
"plugindir+"="E:\\Programs\\AviSynth+\\plugins+"
"plugindir+gcc"="E:\\Programs\\AviSynth+\\plugins_gcc"

C-plugins should work with the GCC builds (the FFMS2 C-plugin definitely works). C++ plugins will not (excepting possibly if they were built with g++, but I've not tried this yet).

For those not wanting duplicate copies of FFMS2-C floating around, symbolic links should work fine.

[wonkey_monkey]

Help please - I'm trying to track down a bug but my lack of understanding of smart pointers is causing me a headache. The bug occurs if I use the following code in GetFrame:

PVideoFrame tmp = child2->GetFrame(n, env);
PVideoFrame src = child->GetFrame(n, env);

return src

In the constructor, the filter does something along these lines:

if ([condition]) child2 = env->Invoke(...); else child2 = child;

So child2 may, or may not, be the same clip (literally the same pointer) as child. When they are the same, I get unexpected behaviour, so I'm guessing there is something bad about calling GetFrame twice on the same clip.

So my question: is straight copying of a PClip like this an unambiguously wrong thing to do (I'm guessing it is), and if so, what's the correct thing to do?

[pinterf]

There is nothing wrong with copying PClips. In the above example, is tmp unused deliberately?

[jpsdr]

Is there MT mode used ? In that case, maybe affecting child2 in constructor is not compatible with MT_NICE ?

[tuanden0]

New version of AVS+ (2772 and older) got glitch with FFMS2 when using to encode audio.

I tried to use AVS+ to cut some scenes of video and audio to watch on my smartphone.
After encode, video is OK but audio got some "noise".

But when I tried to use "LWLibavAudioSource" instead of "FFAudioSource", It's OK.
I used FFMS2 from here: https://forum.doom9.org/showthread.php?p=1866411#post1866411
Here's my simple script:
c=FFVideoSource("E:\Download\Source\Maria Ozawa Collection Vol-02.mkv",colorspace="YV12")
c=AssumeFPS(c, 24000, 1001)
a=FFAudioSource("E:\Download\Source\Maria Ozawa Collection Vol-02.mkv")
a=AssumeFPS(a, 24000, 1001)
AudioDub(c,a)
Trim(0,718) + Trim(2872,31877) + Trim(34036,0)

[wonkey_monkey]

There is nothing wrong with copying PClips. In the above example, is tmp unused deliberately?

Yes, even if I make not further reference to tmp the problem manifests. If I comment out that line, no problem. If child and child2 are different clips, no problem. The problem is that I don't get the expected pixels (checking the pixels of tmp->GetReadPtr() and src->GetReadPtr() gives different results).

MT mode is not used. I'll try to whittle it down to a more minimal example, as currently I'm only seeing it happen with a combination of two filters.

[StainlessS]

@Wonkey
Frame Accurate source ? (although I guess frame should be cached anyways).

EDIT:
Maybe as debug assist, double frame height in constructor (vi.height), and return both frames stacked, maybe try ColorBars.ShowFrameNumber as source.

[wonkey_monkey]

Ahhh, I think I've been an idiot. It didn't occur to me that, because my first filter is incomplete, it's not being entirely deterministic (only the first few columns are being written). And then it further didn't occur to me that when I call GetFrame on it twice, it is actually getting the frame twice, and not caching or anything - on the first GetFrame it's coming back with one set of garbage data and on the second GetFrame it's coming back with different garbage data. That was the discrepancy I was seeing with the second filter.

So the first filter is faulty (due to being a work in progress) but the second filter could also be a bit smarter.

[gaak]

My apologies in advance if this is the wrong thread to make such a request, but can someone supply a 0.7 64 bit version of Variableblur to replace the 0.5 version out there now? Thanks.

[StainlessS]

I was gonna have a go at compile but requires VS2010 as per below

** As of version 0.6 the Visual Studio 2010 Service Pack 1 redistributable is required due to OpenMP multithreading.

v0.7 Zip @ SendSpace below this post in my sig, 32 bit only + source (for anybody wants to compile).

The 64 bit zip (via Wiki) on Archive.org seem not to be available.

EDIT: The source has Assembler in it, so dont know if compilable for x64 on VS2010.

[Reel.Deel]

The 64 bit zip (via Wiki) on Archive.org seem not to be available.


Some guy (Yakub2.X see here (http://avisynth.nl/index.php?title=AviSynth%2B_x64_plugins&action=history)) messed up a handful of the links on the avs+ 64-bit plugin page, I have not had time to go over and find and correct those mistakes. :mad:

Correct link is here:
http://avisynth.nl/index.php/VariableBlur#Archived_Downloads

[StainlessS]

OK thanx RD, but v0.7 seems not available anywhere(wiki or d9, or archive.org) , so maybe somebody could do compile of SendSpace in my sig zip
(the v0.5 x64 source also has Assembler, so I presume that it is actually compilable in VS2010).

EDIT: I spent some time searching web but could not find v0.7 x64, dll or source.

[Reel.Deel]

OK thanx RD, but v0.7 seems not available anywhere(wiki or d9, or archive.org).

Download link in the abstract box from wiki (http://avisynth.nl/index.php/VariableBlur) works for me, also mirror link in the archived downloads section works :confused:.


EDIT: I spent some time searching web but could not find v0.7 x64, dll or source.

There is none, v0.5 is the only x64 version available :(.

[wonkey_monkey]

Sorry if this is yet another inane and obvious question, but is there a recommended/simple way to change video clip properties/colourspace/subsampling? Like if I get an 8-bit clip, but I want my filter to output a 16-bit or float clip while keeping all other properties the same (or doing something else like changing subsampling to 444, whatever the input is), is there a simple operation that will do this, and work for all inputs, including interleaved and planar RGB? Or are there always caveats?

[ChaosKing]

http://avisynth.nl/index.php/AviSynth%2B
http://avisynth.nl/index.php/Convert

Easiest way to convert to 16bit is ConvertBits(16). But not all filters support filtering in 16bit.

[wonkey_monkey]

I meant in filter development terms. Do I just have to monkey around with vi.pixel_type? I'm guessing so but I can't any proper documentation on it.

[pinterf]

I meant in filter development terms. Do I just have to monkey around with vi.pixel_type? I'm guessing so but I can't any proper documentation on it.
Yes, monkeying around is a probably a proper definition. In Avisynth.h you can see some masks, look for words "GENERIC" or e.g. CS_Sample_Bits_Mask.
Example for bit depth change (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/convert/convert.cpp#L3118)

[LigH]

Enabling MT together with returning a clip explicitly does not work as expected.

I created a test script for a more elaborate filtering, producing different alternative clips, and I let it return one of these clips to be able to switch quickly between different versions. The AviSynth Wiki – AviSynth+: Enabling MT (http://avisynth.nl/index.php/AviSynth%2B#Enabling_MT) tells:

... You enable MT by placing a single call to Prefetch(X) at the end of your script, where X is the number of threads to use. If there is a return statement in your script it must be placed after Prefetch().

This explanation suggests that Prefetch() is somewhat independent of the clip assignment workflow. So I tried. But instead, I get a confusing error message about invalid arguments for Prefetch(). To condense the issue, I tested it with the following script:

c = ColorBarsHD(1280, 720, "YV24").KillAudio().AssumeFPS(25, 1).Trim(0, 249)
return c

Works well. Now with a Prefetch before the return:

c = ColorBarsHD(1280, 720, "YV24").KillAudio().AssumeFPS(25, 1).Trim(0, 249)
Prefetch(4)
return c

Script error: Invalid arguments to function 'Prefetch'.
(...\PrefetchTest.avs, line 2)

Did I misunderstand? Is Prefetch() a clip filter just like most functions in AviSynth+? I will probably have to use the workaround to implicitly assign the clip to last, instead of returning it explicitly:

c = ColorBarsHD(1280, 720, "YV24").KillAudio().AssumeFPS(25, 1).Trim(0, 249)
c
Prefetch(4)

Or in a completely different way, concatenated with the dot:

c = ColorBarsHD(1280, 720, "YV24").KillAudio().AssumeFPS(25, 1).Trim(0, 249)
return c.Prefetch(4)

Yes, both work well. So better assume that Prefetch() is related to the context of the active filter chain.

[Groucho2004]

Is Prefetch() a clip filter just like most functions in AviSynth+?Yes it is. Ferenc will correct me if I'm wrong. :)

[LigH]

Then I would vote for explaining that a bit better in the Wiki. IMHO, the current explanation is too ambiguous.

[StainlessS]

ProtoType extracted by RT_Stats Make_Avisynth_BuiltIn_FunctionList.avs

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

AviSynth+_0.1_(r2772,_MT,_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
###################################

Prefetch "c[threads]i"

There may be more than one prototype, only one is exposed and extractable (sadly).

[LigH]

This explains the error when called without a reference clip. In my examples, "last" was never assigned.

[Gavino]

What if the Prefetch call is followed by a return, but 'last' has been assigned somewhere earlier?
ColorBarsHD(1280, 720, "YV24") # 'last' assigned here
c = KillAudio().AssumeFPS(25, 1).Trim(0, 249)
Prefetch(4)
return c
This won't give an error, but I suspect Prefetch won't work properly (or at all) since it is not in the final filter chain - its result is not used.

Does it ever make sense to follow Prefetch() by a return statement?

Perhaps instead of
Prefetch(4)
return x

you always need to write
return x.Prefetch(4)

[StainlessS]

Yo big G, thats a long walkabout that you're on, come back when you've found youself, yeh.

you always need to write
return x.Prefetch(4)

Not a bad idea.

Here Differences between Avisynth NEO and Avisynth+ (current versions).
Seems that we are detecting multiple prototypes for builtins, but not detecting proper separate parameter strings for each, but still handy non the less.

No idea what NEO 'n' type specifiers are [perhaps array index or something].

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
###################################

Differences between Avisynth NEO and Avisynth+
##############################################


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


AddProp "csn"
AlignedSplice "cci" AlignedSplice "cc+"
AlignedSplice "cci"


AverageChromaU "c[offset]i" AverageChromaU "ci"
AverageChromaV "c[offset]i" AverageChromaV "ci"

AverageLuma "c[offset]i" AverageLuma "ci"

AVIFileSource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]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" AVISource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"

ChromaUDifference "cc" ChromaUDifference "cci"
ChromaVDifference "cc" ChromaVDifference "cci"

ConditionalFilter "cccn[show]b" ConditionalFilter "cccs[showx]b[args]s[local]b"
ConditionalFilter "cccn[show]b" ConditionalFilter "cccs[showx]b[args]s[local]b"
ConditionalFilter "cccn[show]b"

ConditionalSelect "cnc+[show]b" ConditionalSelect "csc+[show]b"
ConditionalSelect "cnc+[show]b"

DumpFilterGraph "c[outfile]s[mode]i[nframes]i[repeat]b"

FrameEvaluate "cs[show]b[after_frame]b" FrameEvaluate "cs[showx]b[after_frame]b[args]s[local]b"

Func "n"

GeneralConvolution "c[bias]i[matrix]s[divisor]f[auto]b" GeneralConvolution "c[bias]f[matrix]s[divisor]f[auto]b[luma]b[chroma]b[alpha]b"

GetProp "cs[offset]i"

IsFunction "."

LumaDifference "cc" LumaDifference "cci"

OnCPU "n"
OnCPU "n"
OnCUDA "n[device_index]i"
OnCUDA "n[device_index]i"
OpenDMLSource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i" OpenDMLSource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"

Prefetch "c[threads]i[frames]i" Prefetch "c[threads]i"

RGBDifference "cc" RGBDifference "cci"
RGBDifferenceFromPrevious "c" RGBDifferenceFromPrevious "ci"
RGBDifferenceToNext "c[offset]i" RGBDifferenceToNext "ci"

ScriptClip "cn[show]b[after_frame]b" ScriptClip "cs[showx]b[after_frame]b[args]s[local]b"
ScriptClip "cn[show]b[after_frame]b"

SegmentedAVISource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i" SegmentedAVISource "s+[audio]b[pixel_type]s[fourCC]s[vtrack]i[atrack]i[utf8]b"

SetCacheMode "[mode]i"
SetDeviceOpt "[opt]i[val]i"

SetGraphAnalysis "b"

SetMemoryMax "[]i[type]i[index]i" SetMemoryMax "[]i"

TypeName "."

UDifferenceFromPrevious "c" UDifferenceFromPrevious "ci"
UDifferenceToNext "c[offset]i" UDifferenceToNext "ci"
UnalignedSplice "cci" UnalignedSplice "cc+"
UnalignedSplice "cci"

UPlaneMax "c[threshold]f[offset]i" UPlaneMax "c[threshold]fi"
UPlaneMedian "c[offset]i" UPlaneMedian "ci"
UPlaneMin "c[threshold]f[offset]i" UPlaneMin "c[threshold]fi"
UPlaneMinMaxDifference "c[threshold]f[offset]i" UPlaneMinMaxDifference "c[threshold]fi"
UseVar "cs+"

VDifferenceFromPrevious "c" VDifferenceFromPrevious "ci"
VDifferenceToNext "c[offset]i" VDifferenceToNext "ci"

VPlaneMax "c[threshold]f[offset]i" VPlaneMax "c[threshold]fi"
VPlaneMedian "c[offset]i" VPlaneMedian "ci"
VPlaneMin "c[threshold]f[offset]i" VPlaneMin "c[threshold]fi"
VPlaneMinMaxDifference "c[threshold]f[offset]i" VPlaneMinMaxDifference "c[threshold]fi"

WAVSource "s+" WAVSource "s+[utf8]b"

WriteFile "c[filename]sn+[append]b[flush]b" WriteFile "c[filenamex]ss+[append]b[flush]b[args]s[local]b"
WriteFile "c[filename]sn+[append]b[flush]b"

WriteFileEnd "c[filename]sn+[append]b" WriteFileEnd "c[filename]ss+[append]b"
WriteFileEnd "c[filename]sn+[append]b"
WriteFileIf "c[filename]sn+[append]b[flush]b" WriteFileIf "c[filenamex]ss+[append]b[flush]b[args]s[local]b"
WriteFileIf "c[filename]sn+[append]b[flush]b"
WriteFileStart "c[filename]sn+[append]b" WriteFileStart "c[filename]ss+[append]b"
WriteFileStart "c[filename]sn+[append]b"
YDifferenceFromPrevious "c" YDifferenceFromPrevious "ci"
YDifferenceToNext "c[offset]i" YDifferenceToNext "ci"
YPlaneMax "c[threshold]f[offset]i" YPlaneMax "c[threshold]fi"
YPlaneMedian "c[offset]i" YPlaneMedian "ci"
YPlaneMin "c[threshold]f[offset]i" YPlaneMin "c[threshold]fi"
YPlaneMinMaxDifference "c[threshold]f[offset]i" YPlaneMinMaxDifference "c[threshold]fi"


Here, RT_Stats scripts for making function lists, with a few mods done today for Avs NEO(~56KB):- http://www.mediafire.com/file/mdtte1sll6yz4nf/RT_Stats_FunctionLists.zip/file
Also contains complete function lists for these versions of avisynth.

# AviSynth v2.58
AviSynth 2.58, build:Dec 22 2008 [08:46:51]

# AviSynth v2.60
AviSynth 2.60, build:Mar 31 2015 [16:38:54]

# AviSynth v2.61 Alpha
AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp

# Avisynth v2.60 ICL
AviSynth 2.60 (ICL10)

# Avisynth V2.60 MT
AviSynth 2.60, build:Feb 20 2015 [03:16:45]

# Avisynth+ v2.60
AviSynth+ 0.1 (r2772, MT, i386)
AviSynth+ 0.1 (r2772, MT, x86_64)

# Avisynth NEO
AviSynth Neo 0.1 (r2822, Neo, i386)
AviSynth Neo 0.1 (r2822, Neo, x86_64)

# Avisynth NEO Forerunner Avisynth+ CUDA
AviSynth+ 0.1 (r2533, CUDA, i386)
AviSynth+ 0.1 (r2533, CUDA, x86_64)

x86/x64 function lists for same version avs should be identical, I think [EDIT: Yes, except for the embedded name, are identical].

EDIT: Perhaps 'n' is name, ie function name, variable name, device name.

[pinterf]

EDIT: Perhaps 'n' is name, ie function name, variable name, device name.
'n' is for functioN

[StainlessS]

'n' is for functioN
Thanx.

Last one on list,

YPlaneMinMaxDifference "c[threshold]fi"

Un-named optional final arg of type int ?

Whereas NEO

YPlaneMinMaxDifference "c[threshold]f[offset]i"


EDIT: After ANY optional arg, so all following args have to be optional (standard amongst many languages) and I think that is enforced by Avisynth
even though 'i' type arg is neither specified as named optional, nor un-named optional, '[offset]i' or '[]i', however, how does it magically know that the arg name should be accepted as 'offset', when is not specified.
(I think some clever magic spell is being cast, but maybe should comply with standard prototype spec stuff, or some things will not work proper [eg AvsPMod]).
Avisynth+ may know what clever magic is involved, but as AVS exports function names in "$InternalFunctions$" (and "$PluginFunctions$"), and parameters via "$Plugin!" and "!Param$",
so would be best if software that interrogates those infos, get the un-magic'ed versions.

EDIT: From Wiki:- http://avisynth.nl/index.php/Internal_functions#Runtime_functions

Color plane median, min, max, range

YPlaneMedian(clip [, int offset = 0])
UPlaneMedian(clip [, int offset = 0])
VPlaneMedian(clip [, int offset = 0])
BPlaneMedian(clip [, int offset = 0]) AVS+
GPlaneMedian(clip [, int offset = 0]) AVS+
RPlaneMedian(clip [, int offset = 0]) AVS+

YPlaneMin(clip [, float threshold = 0, int offset = 0])
UPlaneMin(clip [, float threshold = 0, int offset = 0])
VPlaneMin(clip [, float threshold = 0, int offset = 0])
BPlaneMin(clip [, float threshold = 0, int offset = 0]) AVS+
GPlaneMin(clip [, float threshold = 0, int offset = 0]) AVS+
RPlaneMin(clip [, float threshold = 0, int offset = 0]) AVS+

YPlaneMax(clip [, float threshold = 0, int offset = 0])
UPlaneMax(clip [, float threshold = 0, int offset = 0])
VPlaneMax(clip [, float threshold = 0, int offset = 0])
BPlaneMax(clip [, float threshold = 0, int offset = 0]) AVS+
GPlaneMax(clip [, float threshold = 0, int offset = 0]) AVS+
RPlaneMax(clip [, float threshold = 0, int offset = 0]) AVS+

YPlaneMinMaxDifference(clip [, float threshold, int offset = 0])
UPlaneMinMaxDifference(clip [, float threshold, int offset = 0])
VPlaneMinMaxDifference(clip [, float threshold, int offset = 0])
BPlaneMinMaxDifference(clip [, float threshold, int offset = 0]) AVS+
GPlaneMinMaxDifference(clip [, float threshold, int offset = 0]) AVS+
RPlaneMinMaxDifference(clip [, float threshold, int offset = 0]) AVS+

[pinterf]

Thanx.

Last one on list,

YPlaneMinMaxDifference "c[threshold]fi"

Un-named optional final arg of type int ?

Whereas NEO

YPlaneMinMaxDifference "c[threshold]f[offset]i"



Avisynth+ is also OK.
Avisynth+:
{ "YPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_Y },
{ "UPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_U }, // AVS+! was before: missing offset parameter
{ "VPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_V }, // AVS+! was before: missing offset parameter
{ "RPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_R },
{ "GPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_G },
{ "BPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_B },

[StainlessS]

Not sure that I'm understanding properley, think that you are saying that it works ok.


PLG="YPlaneMinMaxDifference"
PARAM=RT_PluginParam(PLG)
RT_Debugf("PLUG=%s PARAM=%s",PLG,PARAM)
return MessageClip("DONE")


result ( '[offset]' missing )

00000011 13:16:13.462 [2900] RT_DebugF: PLUG=YPlaneMinMaxDifference PARAM=c[threshold]fi


{ "YPlaneMinMaxDifference", BUILTIN_FUNC_PREFIX, "c[threshold]f[offset]i", MinMaxPlane::Create_minmax, (void *)PLANAR_Y },
"[offset]" has gone AWOL.

Source to RT_PluginParam [ env->AddFunction("RT_PluginParam", "s",RT_PluginParam, 0); ]

AVSValue __cdecl RT_PluginParam(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_PluginParam: ";
const char *s=args[0].AsString();
int len = int(strlen(s));
char *bf = new char[len + 16];
if(bf==NULL) env->ThrowError("%sCannot allocate memory",myName);
strcpy(bf,"$Plugin!");
strcat(bf,s);
strcat(bf,"!Param$");
char *ps;
try {
AVSValue var = env->GetVar(bf);
if(!var.IsString()) {
delete [] bf;
env->ThrowError("%s Var '$Plugin!%s!Param$' is not a string",myName,s);
}
delete [] bf;
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}


Also, is there a way to extract all alterative parameter lists for a plugin name ? [there did not used to be for avs standard).

[pinterf]

When there are too many data, e.g. output is fast, OutputDebugString can lose characters.

[Groucho2004]

When there are too many data, e.g. output is fast, OutputDebugString can lose characters.
That's nasty.

[StainlessS]

When there are too many data, e.g. output is fast, OutputDebugString can lose characters.

Cannot possibly be the cause, the RT_Stats function list extractors do not use OutputDebugString at all, same problem.
I've never seen swallowed output in OutputDebugString (and I've often sent biggish text files to OutputDebugString for capture and checking)

function list extractors do not use OutputDebugString at all
At least not for extraction or processing or writing to file. [there is a problem somewhere]

EDIT: There are many others with exact same symptoms in the functionlist comparitor prev posted, YPlaneMinMaxDifference just happened to be the easiest to locate, being the last one in list.
From first few

Differences between Avisynth NEO and Avisynth+
##############################################


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


AddProp "csn"
AlignedSplice "cci" AlignedSplice "cc+"
AlignedSplice "cci"


AverageChromaU "c[offset]i" AverageChromaU "ci"
AverageChromaV "c[offset]i" AverageChromaV "ci"

AverageLuma "c[offset]i" AverageLuma "ci"


Actually, It ALWAYS seems to happen with "[offset]i", every single one of them (and there are quite a few).

EDIT:
Wiki, seems to be missing offset args

LumaDifference(clip1, clip2)
ChromaUDifference(clip1, clip2)
ChromaVDifference(clip1, clip2)
RGBDifference(clip1, clip2)

BDifference(clip1, clip2) AVS+
GDifference(clip1, clip2) AVS+
RDifference(clip1, clip2) AVS+
BDifferenceFromPrevious(clip) AVS+
GDifferenceFromPrevious(clip) AVS+
RDifferenceFromPrevious(clip) AVS+

YDifferenceFromPrevious(clip)
UDifferenceFromPrevious(clip)
VDifferenceFromPrevious(clip)
RGBDifferenceFromPrevious(clip)



Swallowed optional offset names [RHS text column, hope I got them all].

ChromaUDifference "cc" ChromaUDifference "cci"
ChromaVDifference "cc" ChromaVDifference "cci"

LumaDifference "cc" LumaDifference "cci"

RGBDifference "cc" RGBDifference "cci"
RGBDifferenceFromPrevious "c" RGBDifferenceFromPrevious "ci"
RGBDifferenceToNext "c[offset]i" RGBDifferenceToNext "ci"

UDifferenceFromPrevious "c" UDifferenceFromPrevious "ci"
UDifferenceToNext "c[offset]i" UDifferenceToNext "ci"
UPlaneMax "c[threshold]f[offset]i" UPlaneMax "c[threshold]fi"
UPlaneMedian "c[offset]i" UPlaneMedian "ci"
UPlaneMin "c[threshold]f[offset]i" UPlaneMin "c[threshold]fi"
UPlaneMinMaxDifference "c[threshold]f[offset]i" UPlaneMinMaxDifference "c[threshold]fi"

VDifferenceFromPrevious "c" VDifferenceFromPrevious "ci"
VDifferenceToNext "c[offset]i" VDifferenceToNext "ci"
VPlaneMax "c[threshold]f[offset]i" VPlaneMax "c[threshold]fi"
VPlaneMedian "c[offset]i" VPlaneMedian "ci"
VPlaneMin "c[threshold]f[offset]i" VPlaneMin "c[threshold]fi"
VPlaneMinMaxDifference "c[threshold]f[offset]i" VPlaneMinMaxDifference "c[threshold]fi"

YDifferenceFromPrevious "c" YDifferenceFromPrevious "ci"
YDifferenceToNext "c[offset]i" YDifferenceToNext "ci"
YPlaneMax "c[threshold]f[offset]i" YPlaneMax "c[threshold]fi"
YPlaneMedian "c[offset]i" YPlaneMedian "ci"
YPlaneMin "c[threshold]f[offset]i" YPlaneMin "c[threshold]fi"
YPlaneMinMaxDifference "c[threshold]f[offset]i" YPlaneMinMaxDifference "c[threshold]fi"

[pinterf]

That's nasty.
Probably the output is O.K., I experienced the missing lines in the viewer (DebugView)

[StainlessS]

Maybe old DebugView, update.

DebugView v4.81(Published: December 4, 2012):- https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

[Maybe you use Kernel mode a lot, I dont]

EDIT: I switch off option WIN32 PIDS, and always Force Carriage Returns [If you dont, some text disappears off RHS when not sending '\n' at end of lines].

[wonkey_monkey]

I use DebugView too and have never had any problem with missing lines.

Clear-output string: When DebugView sees the special debug output string "DBGVIEWCLEAR" it clears the output.

Holy cow that's going to save me a lot of trouble.

[StainlessS]

Holy cow that's going to save me a lot of trouble.

I've never seen that before, making a note of it.

I used to use a Sinclair QL via RS232 for showing debug stuff (used to just switch on/plug in and auto started showing any debug stuff on 9" green screen), I kinda forgot bout that when I gave to charity shop 2 QL's
+ £1000's of softwares, next day I thought, what the hell do I do for debugging now. Maybe I set up debugview for same type output on laptop or 10" tablet laptoppy thingy.
I got a USB to Ethernet whatsit, but wonder if USB alone could be persuaded to work.
EDIT: I also used to view Debug stuff on 2nd monitor, but have not had dual display for a few years now, guess we needs one.

[StainlessS]

Seems to be a pretty serious bug in avisynth NEO, Main avs level local variables not visible inside Scriptclip.
Works fine even in Avs v2.58, Fails in AVS NEO < "I dont know what S Means. ([Scriptclip] Line 1)" >

S=RT_TxtAddStr(S,S2) # Some String
W=1280 H=640 LINES=RT_TxtQueryLines(S)
L= LINES*20 + H + 100
RT_Debug(S)
BlankClip(Width=W,Height=H,Length=L).ScriptClip("""RT_Subtitle("%s",S,x=10,y=height+100-current_frame,expx=true,expy=true)""")


Fixes in Avs NEO

S=RT_TxtAddStr(S,S2) # Some String
W=1280 H=640 LINES=RT_TxtQueryLines(S)
L= LINES*20 + H + 100
RT_Debug(S)
Global GLB_S=S
BlankClip(Width=W,Height=H,Length=L).ScriptClip("""RT_Subtitle("%s",GLB_S,x=10,y=height+100-current_frame,expx=true,expy=true)""")


The Fix was already incorporated into the zip of FunctionLists/FunctionList_creator_scripts previously posted.

Perhaps we need a NEO thread.
Could probably be fixed using Grunt style ScriptClip(args="S") instead of Global.

EDIT: Alternative script OK in v2.58, but error in NEO [EDIT: Thanx Grouchy, its a breeze to switch avs back and forth now with Universal Avisynth Installer (https://forum.doom9.org/showthread.php?t=172124) ]

S="HELLO"
BlankClip.ScriptClip("""Subtitle(S)""")

Maybe some GitHub guy could post in Neo whotsit.

EDIT: To post #4629
Maybe old DebugView, update.

DebugView v4.81(Published: December 4, 2012):- https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

[Maybe you use Kernel mode a lot, I dont]

EDIT: I switch off option WIN32 PIDS, and always Force Carriage Returns [If you dont, some text disappears off RHS when not sending '\n' at end of lines].

EDIT: Above in BLUE why I now always use the below with auto add NewLine (rather than OutputDebugString directly).

int __cdecl dprintf(char* fmt, ...) {
char printString[2048]="Shuffle: "; // Must be nul Termed, eg "Test: " or ""
char *p=printString;
for(;*p++;);
--p; // @ null term
va_list argp;
va_start(argp, fmt);
vsprintf(p, fmt, argp);
va_end(argp);
for(;*p++;);
--p; // @ null term
if(printString == p || p[-1] != '\n') {
p[0]='\n'; // append n/l if not there already
p[1]='\0';
}
OutputDebugString(printString);
return int(p-printString); // strlen printString
}

[Stereodude]

Is it not possible to use two instances of the same filter that each use conditional reader in AVIsynth+ with unique conditional arguments for each?

This does not give the results I would expect.
LoadPlugin("C:\HDTV Tools\DGMPGDec\DGDecode-x86.dll")

MPEG2Source("YMMB_2.d2v", idct=5, moderate_h=40, moderate_v=40, cpu2="oooooo")

ConvertBits(16)

ColorYUV(conditional=true, levels="TV", analyze=false)
ConditionalReader("offu_t.txt", "coloryuv_off_u", false)
ConditionalReader("offv_t.txt", "coloryuv_off_v", false)

#some processing here

ColorYUV(conditional=true, levels="TV", analyze=false)
ConditionalReader("off_y.txt", "coloryuv_off_y", false)
ConditionalReader("gain_y.txt", "coloryuv_gain_y", false)

ConvertBits(8, dither = 1)

The output is the same as this:
LoadPlugin("C:\HDTV Tools\DGMPGDec\DGDecode-x86.dll")

MPEG2Source("YMMB_2.d2v", idct=5, moderate_h=40, moderate_v=40, cpu2="oooooo")

ConvertBits(16)

ColorYUV(conditional=true, levels="TV", analyze=false)
ConditionalReader("offu_t.txt", "coloryuv_off_u", false)
ConditionalReader("offv_t.txt", "coloryuv_off_v", false)
ConditionalReader("off_y.txt", "coloryuv_off_y", false)
ConditionalReader("gain_y.txt", "coloryuv_gain_y", false)

#some processing here

ColorYUV(conditional=true, levels="TV", analyze=false)
ConditionalReader("offu_t.txt", "coloryuv_off_u", false)
ConditionalReader("offv_t.txt", "coloryuv_off_v", false)
ConditionalReader("off_y.txt", "coloryuv_off_y", false)
ConditionalReader("gain_y.txt", "coloryuv_gain_y", false)

ConvertBits(8, dither = 1)
It seems that all 4 ConditionalReader arguments in the script are seen by each of the ColorYUV instances. Is there some way to prevent each instance of the ColorYUV filter from seeing all 4 conditional reader arguments?

[TheFluff]

Is that your actual script? To me it looks like you're reading the same files in both instances.

[Stereodude]

Is that your actual script? To me it looks like you're reading the same files in both instances.
That's a simplified version of the actual script that shows the issue without having a pile of extra stuff in it. The actual script has other filters in between the two ColorYUV instances. Hence the #some processing here line.

I'm not sure what you're trying to say about the same files. Those two scripts have the exact same output. I'm asking if that's intentional. If so, can we have some sort of additional feature to segregate conditional reader statements in Avisynth+. Like a line that will be parsed by Avisynth+ and prevent all 4 ConditionalReader lines from being seen by both instances of the ColorYUV filter. Something that will cause conditional reader statements above the line to not be seen by filters below the line and vice versa.

[wonkey_monkey]

I have a filter which takes an array of floats as one of its arguments. It's instantiated like this:

AVSValue __cdecl Create_pyramid_mul(AVSValue args, void* user_data, IScriptEnvironment* env) {
return new pyramid_mul(
args[0].AsClip(),
args[1],
args[2].AsBool(false),
env
);
}

I want to create another function which only takes a single float argument, and constructs the array itself before calling the same constructor (below is just some test code which doesn't use the parameter):

AVSValue __cdecl Create_pyramid_blur(AVSValue args, void* user_data, IScriptEnvironment* env) {
AVSValue multipliers[3] = { 0, 0, 1 };

return new pyramid_mul(
args[0].AsClip(),
AVSValue(multipliers, 3),
false,
env
);
}

But for some reason this doesn't work. Instead of receiving an array (0,0,1), the values the filter finds in the array are either 0, QNAN, or some random very large number.

Clearly my understanding of AVSValue objects and arrays is lacking. Can someone tell me the right way to do this?

---

Edit: is it because the AVSValue I'm sending to the filter - which I use in every GetFrame - is a pointer which becomes invalid after the constructor is called and the instantiator ends?

[TheFluff]

That's a simplified version of the actual script that shows the issue without having a pile of extra stuff in it. The actual script has other filters in between the two ColorYUV instances. Hence the #some processing here line.

I'm not sure what you're trying to say about the same files. Those two scripts have the exact same output. I'm asking if that's intentional. If so, can we have some sort of additional feature to segregate conditional reader statements in Avisynth+. Like a line that will be parsed by Avisynth+ and prevent all 4 ConditionalReader lines from being seen by both instances of the ColorYUV filter. Something that will cause conditional reader statements above the line to not be seen by filters below the line and vice versa.

What I mean is that both sets of calls to conditionalreader seem to be reading from the same input files. I'm asking if this is a mistake in your example script or not. If it's not a mistake, well, you would expect two function calls with the same parameters to give the same results, no?

[pinterf]

AVSValue __cdecl Create_pyramid_blur(AVSValue args, void* user_data, IScriptEnvironment* env) {
AVSValue multipliers[3] = { 0, 0, 1 };

return new pyramid_mul(
args[0].AsClip(),
AVSValue(multipliers, 3),
false,
env
);
}

What happens if you try with floats?
AVSValue multipliers[3] = { 0.0f, 0.0f, 1.0f };

[wonkey_monkey]

Same thing. It seems the object only exists during construction of the filter instance, whereas actual proper filter parameters persist. I made the filter take a copy during construction, and now it works as intended.

[Stereodude]

What I mean is that both sets of calls to conditionalreader seem to be reading from the same input files. I'm asking if this is a mistake in your example script or not. If it's not a mistake, well, you would expect two function calls with the same parameters to give the same results, no?
They're not the same in the script with two and two. They have similar names, but they're not the same.

[RainyDog]

Does anyone know of any logo removal plugin's for x64 Avisynth+ that they can point me to please?

Something that can remove a small semi-transparent logo from a TV broadcast.

Thanks.

[pinterf]

If so, can we have some sort of additional feature to segregate conditional reader statements in Avisynth+. Like a line that will be parsed by Avisynth+ and prevent all 4 ConditionalReader lines from being seen by both instances of the ColorYUV filter. Something that will cause conditional reader statements above the line to not be seen by filters below the line and vice versa.
Nice problem. This commit (https://github.com/pinterf/AviSynthPlus/commit/4e57ce9b7b04e4dc1b0d04458967d4458f728574#diff-57531bd28bca7e5a39e73c62c313e3df) will probably help you. Do someone need a fresh build from current dev state? It's faster for me than doing a proper release.

[Gser]

Does anyone know of any logo removal plugin's for x64 Avisynth+ that they can point me to please?

Something that can remove a small semi-transparent logo from a TV broadcast.

Thanks.

I use MP_Pipeline https://forum.doom9.org/showthread.php?t=163281(https://www.mediafire.com/folder/2izh9abzep52o/Video_works to pipe rm_logo to the 32-bit version of avisynth in one script, meaning you need both 32 and 64 bit versions installed

[wonkey_monkey]

Here's an oddity: if I use extracta on a YUV clip with no alpha channel, I get an error. If I use it on an RGB24 clip, which also has no alpha channel, no error - just white pixels.

[Reel.Deel]

My apologies in advance if this is the wrong thread to make such a request, but can someone supply a 0.7 64 bit version of Variableblur to replace the 0.5 version out there now? Thanks.

Thanks to Asd there is now a 64-bit VariableBlur v0.7 (among other plugins). See http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

Source code(s) available here: http://avisynth.nl/index.php/User_talk:Asd

[StainlessS]

Many thanx Reel.Deel and especially Asd (dont seem to have D9 Account) for the x64 rendition and source.

[ChaosKing]

Why not make a github organisation to keep plugins + source code organised? Like this one https://github.com/HomeOfVapourSynthEvolution

[gaak]

Many thanx Reel.Deel and especially Asd (dont seem to have D9 Account) for the x64 rendition and source.

Please add my thanks as well. My life is now complete (and so is my project):).

[Dogway]

I made a test script to understand the new syntax for expressions but I'm having a hard time getting a grasp of it.
In the below case, I have a different behavior when working in 16 or 8 bit.

blankclip(length=1,width=700,height=480, pixel_type="YV12")
ConvertBits(16)
expr(" sx width / range_max * ", "","", scale_inputs = "none" )
#~ ConvertBits(8) # comment and uncomment


strength = string(1.1)

expr( last, " x "+strength+" scalef ^ ","","", scale_inputs = "floatf" )



edit: In case anyone's interested here's the function it works but 8b and 16b give different results (strength is not scaled correctly I think)

function Vignette(clip c, float "Vignette", bool "show") {

strength = string(Default(Vignette, 0.7))
show = Default(show, false)

a=expr( c, " sx width 2 / - abs width 2 / / range_max * 1.5 "+strength+" 2 / + ^ range_max / 0 max ", "","", scale_inputs = "none" )
b=expr( c, " sy height 2 / - abs width 2 / / range_max * 1.5 "+strength+" 2 / + ^ range_max / 0 max ", "","", scale_inputs = "none" )

msk=expr(a,b,"x y + range_max - abs", "range_half","range_half", scale_inputs = "none" )

show ? msk : expr(msk,c,"x y * range_max / ", "y", "y", scale_inputs = "none" )

}


Also, is there an internal function similar to mt_merge() for YUV?
I could replicate it with expr() at some extent, only for luma, I could split planes but I don't know if there's a more elegant solution?
expr(video, msk,"x z range_size - abs * y z * + range_max / ","","",scale_inputs="none")

[Nico8583]

Hi,
What is the difference between "https://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.exe" from http://avs-plus.net/ and "https://github.com/pinterf/AviSynthPlus/releases/download/r2772-MT/AviSynthPlus-MT-r2772.exe" from https://github.com/pinterf/AviSynthPlus/releases ? Is it just one newer than the other ? Or a fork ?
Thank you.

[qyot27]

avs-plus.net was just simply not updated much after a couple years. Even ultim released newer versions than r1576 (from the MT branch). pinterf's repo and releases are the current development HEAD, yes, and it is not a fork.

[Nico8583]

Thank you, so it's better to install pinterf's releases (like r2772) ?

[StainlessS]

Yes, nobody should be using r1576, unfortunately Pinterf dont have control over the first post of this thread.

[Nico8583]

Thank you ;) I try it.

[Groucho2004]

Yes, nobody should be using r1576, unfortunately Pinterf dont have control over the first post of this thread.
Time for a new thread or a moderator to update the first post. I think the latter is a better option.

[StainlessS]

Moderator update of 1st post would be repeatedly required, (and the mods are so busy as is),
Pinterf has been deliberating whether or not to open new thread (since before XMAS I think),
Guess we just have to wait for the black smoke or the white smoke, to signal a decision.

[Groucho2004]

Moderator update of 1st post would be repeatedly requiredTrue, didn't consider that. So, a new thread then.

[FranceBB]

Moderator update of 1st post would be repeatedly required, (and the mods are so busy as is),
Pinterf has been deliberating whether or not to open new thread (since before XMAS I think),
Guess we just have to wait for the black smoke or the white smoke, to signal a decision.

Yep. Unfortunately this whole thing is very confusing, 'cause most of the people who don't actually follow Doom9 end up installing the Legacy Avisynth 2.6.1 or worse, the old version of Avisynth+, thus getting compatibility issues and facing regressions without knowing why.
I wasn't very keen to move from Avisynth 2.6.1 myself even though I do follow Doom9 and I post here quite often, only 'cause everywhere else people were commenting about the stability issues and other severe bugs and I was so afraid to break my workflow that I kept Avisynth 2.6.1 'till 2017. (Stainless probably remembers the posts about my concerns).
As a matter of fact, later on, in 2017, I found out that all these "rumors" were about the "old" Avisynth+, not the (at the time current) branch maintained by Ferenc. In fact, when I switched, it not only was faster, but it also fixed some pretty particular "bugs" (more like inconsistencies to be fair) that the legacy Avisynth had and it even allowed me to finally ditch 16bit stacked/interleaved in favor of a real 16bit, it allowed me to apply LUTs, to tone-map and to do many other things that were just not possible with the legacy Avisynth.
In a nutshell, from my experience, I think that many people are misguided and end up installing the wrong/old version of Avisynth/Avisynth+ due to the lack of proper and clear documentation, which is a shame, really, for the community, so I'm totally in favor of starting a new topic and perhaps updating the Wiki and make it clear that the Ferenc's version is the only one that is still developed and that it should really be the only one to be used.

[Dogway]

Fix according, I have no clue what scale_inputs does.

Edit:Updated code in next page.

[Groucho2004]

I have no clue what scale_inputs does.
http://avisynth.nl/index.php/Expr

[tebasuna51]

Time for a new thread or a moderator to update the first post. I think the latter is a better option.

My EDIT in first post have a link to last pinterf version (Avisynth+ r2772-MT) and to first post than begin with pinterf avs+ discussion.

I can't do anything more. I think is better a new thread by pinterf.

[videoh]

You done good, tebasuna51. Thank you.

[Dogway]

http://avisynth.nl/index.php/Expr

In fear of repeating myself...
I have no clue what scale_inputs does. ?

[pinterf]

In fear of repeating myself...
?
Use it when you don't want to bother with the different bit-depths within your Expr script. Depending on your choice, the Expr expression will always see your input clip to be 8 (or other bit depth, fine tuned with the i8, i10, etc Expr keywords)

The parameter helps converting old 8-bit-only Expr (or mt_lutxxx family) expression strings to a generic good-for-all-bit-depth string.

Since there is an automatic input conversion phase (e.g. pixel values of a 10 bit input clip will be divided by 4.0 to have them in the 8 bit range), then a back-conversion phase (result will be multiplied by 4.0 before converting the intermediate pixel result back to 10 bit integer). Using this method Expr itself is a little bit slower, but the conversion takes place only when the input bit-depth is different from the bit-depth used in Expr.

[pinterf]

Regarding the new thread, yeah, I'll start it, promise, unfortunately my draftsman is on holiday :), I wanted to write a proper intro w/o mis-spelling.
Anyway it's time for a new release but I found way too many other tasks and coding adventures for myself, so it's just a question of weeks.

[Dogway]

Thanks pinterf, I think I got it.

Float style code only works with 32bit float videos, but integer style code works with everything, unless you have uknown bitdepth variables (float, integers, clips) in which case you can use the scale_inputs setting to bring them to a common denominator (8-bit).

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)


function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
msk
w = Width()
h = Height()
Y = ConvertToY8()
U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
V = U
msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

[pinterf]

1.) You can omit abs by exchanging range_max and z in your script
(x * (range_max - z) + y * z) / range_max

(Expr uses 32 bit floats internally, regardless of the input pixel bit depth, so 255 becomes 255.0 and this floating point number is used until at the end the result is automatically rounded and converted back to integer (for 8-16 bit clips).
But in actual integer pixel-type implementations like in mt_merge or Avisynth Overlay there are simplifications:

(x * range_max - x * z + y * z) / range_max -->
x + (y - x) * z / range_max

is used, this is one less multiplication. But in real life it's a bit more difficult, as masks are stretching from 0..255 (8 bits example). E.g. for 8 bits division by range_max is replaced by division by 256 which is an easy right-bit-shift-8. In exchange the mask extremes (255) have to be treated specially: for maximum mask value we are returning always y. The * 255 right-shift-8 will not work properly for all input combinations.

-- end of popular science :) -- )

2.) You can write code, code, code as code: when an expression is not given for a plane plane, it will be copied from the previous one.

[ChaosKing]

Thanks to Asd there is now a 64-bit VariableBlur v0.7 (among other plugins). See http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

Source code(s) available here: http://avisynth.nl/index.php/User_talk:Asd

I have put it on github https://github.com/avisynth-repository/VariableBlur

[real.finder]

This is my Expr version of mt_merge(), if you pinpoint something odd or not optimized please correct me. (not working with 32bit float)


function expr_merge ( clip a, clip b, clip msk, bool "luma", string "scale_inputs") {

luma = Default(luma, true)
scale_inputs = Default(scale_inputs, "all")

luma ? Eval("""
msk
w = Width()
h = Height()
Y = ConvertToY8()
U = Y.BicubicResize(W/2,H/2,-.5,.25, src_left=0.25 - (0.25/w))
V = U
msk=CombinePlanes(Y, U, V, planes = "YUV", sample_clip=msk)""") : nop()

code="x z range_max - abs * y z * + range_size / "
expr(a,b,msk,code,code,code, scale_inputs=scale_inputs) }

why you made merge function? if it because this old bug (https://github.com/tp7/masktools/issues/12) then pinterf already fix (https://github.com/pinterf/masktools/commit/ad143a5693882c6c827dd4ff8dbfe29de843dcb2) it

and there are already MasknotCL, MaskCL and my https://pastebin.com/aLP9Mb3z and all these in avs26 nowadays is useless since the bug fixed, unless you use avs 2.5

[Dogway]

The goal was that if someone wanted to keep a 32f bit process chain they could saving on quantization processing time and error accumulation (bitdepth down conversion) on the usual heavy filtering done in the scripts, but without removing the support for integer type bitdepths. Float precision is also benefitial for less degradation in dark images or parts of them.

I understand this is currently not possible due to the right-shift mechanism (discrepancies in masks), unless we get an official expr_merge with said optimizations. For now I will apply your suggestions (a ternary op in masks) until we get an internal function. I haven't cared for cosmetics yet.

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

[real.finder]

Edit: @real.finder, because I asked a few days ago about an internal equivalent of mt_merge and nobody replied, so assumed there were none (long time out of touch) . Your script does the job perfectly although with a dependency. I will spend my time on my other tools.

Edit2: After testing smaskmerge() also didn't work for 32bit so I adapted mine and now is bitdepth agnostic.

https://i.imgur.com/BxuoWqE.png

and

https://i.imgur.com/xzhfpba.png

and

https://i.imgur.com/dsiAIIS.png

the formula seems work fine even in float, what you mean by "didn't work for 32bit"?

[Dogway]

Test with this, as pinterf explained a hack is needed when mask is range_max in float precision. I also had to remove the try catch for cl_exprxyz() in smaskmerge.avsi since it was triggering an error in the script.

16-bit integer__________32-bit float
http://i.imgur.com/aYEak4Ut.png (https://imgur.com/aYEak4U) http://i.imgur.com/vbpzRQnt.png (https://imgur.com/vbpzRQn)

blankclip(length=48,width=720,height=480, color=$00000,pixel_type="YV12")
expr("sx frameno + 32 % 16 < range_half range_max ?","sx frameno 2 / + 16 % 8 < range_half sx 15 / - range_half ?","sx frameno 2 / + 16 % 8 < range_half sx 8 / - range_half ?")

ConvertBits(32) # 32bit float vs 8-16bit integer

video=last
video2=video.trim(20,0)

x1=string(20)
x2=string(600)
y1=string(50)
y2=string(340)
msk=expr("sx "+x1+" >= sx "+x2+" <= & sy "+y1+" >= sy "+y2+" <= & & range_max range_min ?", "range_half", "range_half").trim(0,-1).FreezeFrame(0, FrameCount(last)-1, 0)

##########################

smaskmerge(video, video2, msk,3,3,3, luma=true)

ConvertBits(8)

# Debug Chroma planes
# ExtractU()

[real.finder]

so the problem only in chroma? I think this because the zero-chroma-center transition, don't know how chroma mask in float should be, let see what pinterf said and how it work in mt_edge and mt_merge

[pinterf]

Without reverse engineering the Expr itself, yep, float chroma goes -from 0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

[real.finder]

Without reverse engineering the Expr itself, yep, float chroma goes from -0.5 to 0.5, sometimes it can be tricky to apply on it a universal Expr. Perhaps with "range_size"? Anyway, masks are just weights going from 0 to 1.0.

in this case range_size not suitable for non-float, in 8 bit will be 256 not 255

maybe temporary shifting to 0-1.0 for float chroma if there are only universal (luma) Expr available? or with some parameter to set that

same for masktools lut things

[LouieChuckyMerry]

Hello, and thanks in advance for any help. About five years ago, kind, patient people here and elsewhere helped me develop a quite nice basic template for shriveling and improving my Blu-rays with 10-bit x264 using MeGUI with SEt's MT AviSynth. I'm still using MeGUI, but I've recently upgraded to pinterf's AviSynth+ and am wanting to verify that I've translated my template correctly.

The original SEt AviSynth MT template is:

SetMemoryMax(XXXX)
SetMTMode(X,X)
SOURCE INFORMATION HERE
SetMTMode(X)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
### Preview Source OR Send 16-bit Output To x264 10-bit ###
# DitherPost()
Dither_Out()

with the x264 custom command line:

--demuxer raw --input-depth 16 --sar 1:1

while my current pinterf AviSynth+ template, with the same above x264 custom command line, is:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,LSB=True,LSB_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3("Settings Depend On Source",LSB_In=True,LSB=True)
ConvertFromStacked
ConvertBits(10,Dither=0)
Prefetch(X)

which outputs normal-looking 10-bit video at ~15% higher frames per second than the SEt AviSynth MT script. Thanks pinterf :) .

Anyway, I just want to make sure that all is well before I attack further encoding. I'm using the newest .dll's-.avsi's I could find: pinterf's dual signature MaskTools2.2.18.dll, pinterf's MVTools2.7.41.dll, Dither1.27.2.avsi, SMDegrain3.1.2.93s.avsi.

And some questions:

0) Is the new AviSynth+ template truly processing in 16-bits from the beginning to the output?

1) Is the "ConvertBits(10,Dither=0")" call necessary given that I'm sending 16-bit to 10-bit x264; ie, would removing this cause a lack of proper dithering?

2) Is the:

F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod("Settings Depend On Source")
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)

block proper for AviSynth+? Or can it be improved?

3) What have I missed?

Thanks again for any help; I really appreciate it :) .

[LouieChuckyMerry]

As I was checking some test clips, I noticed that very rarely there's an error message from, I think, AviSynth+ superimposed across the top, center of single frames:

Script error: Invalid arguments to function 'IsCombedTIVTC'
([ScriptClip], line 1)

Here's a couple screenshots: S1.E1-Simpsons[NTSC]-AviSynth+ErrorMessages (http://www.mediafire.com/file/7q5sflbj55vnj26/S1.E1-Simpsons[NTSC]-AviSynth%2BErrorMessages.7z). Is there any way to stop this happening (other than not creating script errors ;) )? The script runs fine otherwise (I've used it successfully in the past with SEt's AviSynth MT and this never happened). Also, if anyone would answer my questions above from 7 May about syntax I'd be very thankful for the help :) .

EDIT: Turns out that adding "PreFetch(X)" to the end of a script for encoding interlaced video improves speed but causes errors. Sorry for the bother; a more detailed explanation is in the MeGUI: General Questions and Troubleshooting Thread (https://forum.doom9.org/showthread.php?p=1874620#post1874620).

[stax76]

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

[LouieChuckyMerry]

ConvertBits(10,Dither=0)

This outputs 10 bit, you can certainly serve 16 bit to x265, I don't know which way is better.

Thanks, stax76. Can you explain the difference between:

ConvertFromStacked.ConvertBits(10,Dither=0)

and

ConvertFromStacked

given the script? That is, does the first line dither the raw 16-bit to 10-bit then send this 10-bit output to x264 10-bit while the second would send raw 16-bit to x264 ten bit? More importantly, I guess, is there a difference in quality? Seems silly to me to dither then serve instead of just serving the 16-bit to x264 10-bit, if that's the case.

[Motenai Yoda]

If wasn't fixed, x265's --dither doesn't work other than for 8bit output, without --dither it'll do a truncate.
for x264 it should work well as it apply a sierra dithering iirc

[stax76]

Is it possible to fully automate ConvertFromDoubleWidth meaning calling it only when it is double width. When the aspect ratio is > 3.5 then it is very likely double width and that's good enough for me, my problem is I don't know what to use as bits argument, how do I know if it is 10 or 16 bit?

[DJATOM]

Isn't it better to write a patch for lsmashsource plugin and don't rely on vague heuristics?

[stax76]

It's better sure but if it was trivial somebody would have already done it. :)

[DJATOM]

It looks trivial for me, but I don't have much time to spend for coding. I'm working everyday from December.

[tyee]

Just a quick question - I am finally upgrading to avisynth+ and have done it manually and it seems to be working fine but I am wondering a couple of things -

1. I copied the 2 avisynth.dll's in my 64 bit system to the required windows folders
2. I updated the registry with the new location of my "plugins+" folder. My old folder seems to be used if I rename this new folder, which is correct according to the docs although the 2 registry entries that my original avisynth is supposed to use do not exist!
3. In my new "avisynth+" folder I have copied the two folders that came in the zipfile, these are "c_api" and "system" and the files within. "c_api" folder has "avisynth.lib" and "avisynth.exp". Is this where they should be left?

Everything seems to work ok. I can load a video and one filter I added does work.

Oh, one last question - Do I have to use any MT commands in my scripts like in the older version? I'm using pinterf's avisynth+.

Update on MT - OK, found the info on MT and it's commands. Just tried it and I see no speed increase using Prefetch(4).

[ChaosKing]

Just a quick question - I am finally upgrading to avisynth+ and have done it manually and it seems to be working fine but I am wondering a couple of things -

1. I copied the 2 avisynth.dll's in my 64 bit system to the required windows folders
2. I updated the registry with the new location of my "plugins+" folder. My old folder seems to be used if I rename this new folder, which is correct according to the docs although the 2 registry entries that my original avisynth is supposed to use do not exist!
3. In my new "avisynth+" folder I have copied the two folders that came in the zipfile, these are "c_api" and "system" and the files within. "c_api" folder has "avisynth.lib" and "avisynth.exp". Is this where they should be left?

Everything seems to work ok. I can load a video and one filter I added does work.

Oh, one last question - Do I have to use any MT commands in my scripts like in the older version? I'm using pinterf's avisynth+.

Update on MT - OK, found the info on MT and it's commands. Just tried it and I see no speed increase using Prefetch(4).

3. you don't need these files. There is a "Universal Avisynth Installer" https://forum.doom9.org/showthread.php?t=172124 which does all the work for you. You just need to set the path in the bat file.

[MysteryX]

Pinterf, just pointing out this line
https://github.com/pinterf/AviSynthPlus/blob/08146c9edd19bfb7980ff61d1c000c4194c8589a/avs_core/filters/fps.cpp#L655

// :FIXME: Use fast plane blend routine from Merge here

[pinterf]

Pinterf, just pointing out this line
https://github.com/pinterf/AviSynthPlus/blob/08146c9edd19bfb7980ff61d1c000c4194c8589a/avs_core/filters/fps.cpp#L655

// :FIXME: Use fast plane blend routine from Merge here

Done already
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/fps.cpp#L671
Up to avx2

[MysteryX]

dammit I was using the wrong source code. I always have a hard time finding the right source code version.

I'm looking at ConvertFps code. Why is it that when I debug the code and step frame by frame, in ConvertFPS::GetFrame, mix_ratio is always 1023 (out of 1024) and thus doesn't perform any blend? Then if I seek elsewhere in the file then it starts blending with other ratios.

Really something looks wrong. If I debug and put a breakpoint right after discarding based on threshold, and I play the video, blending doesn't get triggered at all because all frames have ratio of 1023!?? Then if I seek, it's a different ratio but all the frames will have that same ratio until I seek again. I'm using your version now, but something doesn't look right.

That's debugging a copy of your code I made into my project; so it's possible something got broken during copy too.

EDIT:
Never mind my source video was already a 60fps!!!

[MysteryX]

Oh. Interesting. Pinterf, your new code for ConvertFps calculates mix_ratio and mix_ratio_f but never uses them!! Thus altering those variables shows no difference whatsoever!

Seems like the function is only capable of doing a 50/50 blend?

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.

[pinterf]

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.
Thanks I'm gonna check it soon.

[pinterf]

Oh. Interesting. Pinterf, your new code for ConvertFps calculates mix_ratio and mix_ratio_f but never uses them!! Thus altering those variables shows no difference whatsoever!

Seems like the function is only capable of doing a 50/50 blend?

Edit: it's using frac_f instead of mix_ratio; but then it's ignoring the threshold calculation.
No problem there, in this section mix_ratio is used for threshold comparison, but the frac_f holds the real blending weight of the two neightbouring frames. Anyway, I have deleted some unused variables to make it a bit clearer.

[wonkey_monkey]

I'm writing a C++ program that creates its own Avisynth environment. When I compile it, I get:

error LNK2001: unresolved external symbol "struct AVS_Linkage const * const AVS_linkage" (?AVS_linkage@@3PEBUAVS_Linkage@@EB)

That goes away if I add:

#define AVS_LINKAGE_DLLIMPORT

which is what I used to do in my old plugins. Nowadays, in my plugins, I do:

const AVS_Linkage *AVS_linkage = 0;

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
...

but I don't know how to, or if I should, translate this to my standalone C++ program. So - since I have no idea what this vectors thing is about - what's the right thing to do?

[Groucho2004]

I'm writing a C++ program that creates its own Avisynth environment. When I compile it, I get:

error LNK2001: unresolved external symbol "struct AVS_Linkage const * const AVS_linkage" (?AVS_linkage@@3PEBUAVS_Linkage@@EB)

That goes away if I add:

#define AVS_LINKAGE_DLLIMPORT

which is what I used to do in my old plugins. Nowadays, in my plugins, I do:

const AVS_Linkage *AVS_linkage = 0;

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
...

but I don't know how to, or if I should, translate this to my standalone C++ program. So - since I have no idea what this vectors thing is about - what's the right thing to do?
Have a look at my avsr (https://forum.doom9.org/showthread.php?t=173259) code, "avsr.cpp" in particular.
It basically boils down to this:
//global defs
const AVS_Linkage *AVS_linkage = 0;
typedef IScriptEnvironment * __stdcall CREATE_ENV(int);

HINSTANCE hDLL;
hDLL = ::LoadLibrary("avisynth");

if (!hDLL)
{
//Error handling
return;
}

int iInterfaceVersion;
IScriptEnvironment *AVS_env = 0;

try
{
CREATE_ENV *CreateEnvironment = (CREATE_ENV *)GetProcAddress(hDLL, "CreateScriptEnvironment");
if (!CreateEnvironment)
{
::FreeLibrary(hDLL);
//Error handling
return;
}

iInterfaceVersion = 6;
while (!AVS_env)
{
if (iInterfaceVersion < 5)
{
::FreeLibrary(hDLL);
//Error handling
return;
}

AVS_env = CreateEnvironment(iInterfaceVersion);
iInterfaceVersion--;
}

AVS_linkage = AVS_env->GetAVSLinkage();

//do your stuff
...


//important!
AVS_env->DeleteScriptEnvironment();
AVS_env = 0;
AVS_linkage = 0;
}
catch (AvisynthError err)
{
//Error handling
}
catch (other error handling mechanisms)
{
//Error handling
}

::FreeLibrary(hDLL);

[MysteryX]

No problem there, in this section mix_ratio is used for threshold comparison, but the frac_f holds the real blending weight of the two neightbouring frames. Anyway, I have deleted some unused variables to make it a bit clearer.
Why isn't it calculating the threshold on the same frac_f directly?

[wonkey_monkey]

Have a look at my avsr (https://forum.doom9.org/showthread.php?t=173259) code, "avsr.cpp" in particular.
It basically boils down to this:


That's a lot of stuff! What am I missing out on if I just use #define AVS_LINKAGE_DLLIMPORT intead?

[Groucho2004]

That's a lot of stuff! What am I missing out on if I just use #define AVS_LINKAGE_DLLIMPORT intead?Don't know, never tried it. I developed this initialisation over the years, some bits are courtesy of IanB's suggestions. It's not a lot of stuff, it's the bare minimum. :p

What is your program supposed to do?

Edit: A couple of examples can also be found on avisynth.nl:
http://avisynth.nl/index.php/Filter_SDK/avs2yuv
http://avisynth.nl/index.php/Filter_SDK/avs2pcm

[MysteryX]

Hey Pinterf, I just realized that if any AVS script is running and auto-loading plugins, even if it's not using them, it's locking all those files on the hard drive. There's probably a better way of doing that.

[StainlessS]

What if eg Scriptclip() on occasion [EDIT: not every frame] uses a function/filter, you dont 100% for sure know that its never gonna use it.
[ EDIT: or do you ? - same situation with plugin, where defo cant be sure ED: or can you ? ]

Best leave alone, let user decide what he/she/it is gonna lock-n'-load.

[MysteryX]

What if eg Scriptclip() on occasion [EDIT: not every frame] uses a function/filter, you dont 100% for sure know that its never gonna use it.
[ EDIT: or do you ? - same situation with plugin, where defo cant be sure ED: or can you ? ]
No problem.
1. Do a discovery of all DLLs and what's in them
2. Once the script is loaded and started rendering, unload everything that is not in use
NOTE: We still know what functions are available and where
3. If a function is later called that is unloaded, load it.

Otherwise, while we have any script playing that uses auto-loading, we cannot update any dll files.

[wonkey_monkey]

That seems like a lot of work to solve a problem that hardly anyone will ever face, and it could introduce unforeseen problems.

[StainlessS]

That seems like a lot of work to solve a problem that hardly anyone will ever face, and it could introduce unforeseen problems.

Not really, the guy above has already foreseen these unforeseen problems.

[Myrsloik]

No problem.
1. Do a discovery of all DLLs and what's in them
2. Once the script is loaded and started rendering, unload everything that is not in use
NOTE: We still know what functions are available and where
3. If a function is later called that is unloaded, load it.

Otherwise, while we have any script playing that uses auto-loading, we cannot update any dll files.

I think this was actually the original Avisynth strategy. Mostly due to processes at the time being very limited in the number of simultaneous dlls that could be loaded so if you stuffed the autoload directory full you could actually encounter this problem.

Nowadays you can load a gazillion of dlls as long as you compile them with a shared runtime so there's really no reason to do things like that.

[Groucho2004]

I think this was actually the original Avisynth strategy. Mostly due to processes at the time being very limited in the number of simultaneous dlls that could be loaded so if you stuffed the autoload directory full you could actually encounter this problem.The limit was 50 DLLs and still is in AVS 2.6.1 Alpha.

[qyot27]

What that sounds like is akin to the plugin cache index idea I'd proposed way way back when the fork had just happened. I can't even remember what the actual reason was; I think it may have been to save resource usage by not going through the 'autoload everything->unload everything->load only what the script uses' dance when the environment starts. Certainly nothing to do with files being locked (and because it's still autoloading everything at startup, it's not saving anything resource-wise).

Found it. (https://forum.doom9.org/showpost.php?p=1646355&postcount=70) And the actual reason: it was to avoid bad plugins (the example given was one of the versions of WarpSharp) crashing the environment even when they aren't being used in the script, just because they were being autoloaded (https://forum.doom9.org/showpost.php?p=1646457&postcount=75).

[Myrsloik]

What that sounds like is akin to the plugin cache index idea I'd proposed way way back when the fork had just happened. I can't even remember what the actual reason was; I think it may have been to save resource usage by not going through the 'autoload everything->unload everything->load only what the script uses' dance when the environment starts. Certainly nothing to do with files being locked (and because it's still autoloading everything at startup, it's not saving anything resource-wise).

Found it. (https://forum.doom9.org/showpost.php?p=1646355&postcount=70) And the actual reason: it was to avoid bad plugins (the example given was one of the versions of WarpSharp) crashing the environment even when they aren't being used in the script, just because they were being autoloaded (https://forum.doom9.org/showpost.php?p=1646457&postcount=75).

As a bonus some compilers (looking at you borland) would change the FPU rounding mode so some other poor plugin would crash. Good times!

[real.finder]

well, it's still case problems https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150 and https://forum.doom9.org/showpost.php?p=1865961&postcount=4508

[StainlessS]

Dont know if any longer the case, but,
I used to have problems with Script Function Named Difference(), (probably back in either v2.58 or early v2.6 Alpha), I tracked it down to similar named plug func
in (I think) one of Kassandro's dll's. No idea why, as Script Functions are supposed to Override dll which are supposed to Override Builtin.

I just renamed Script function to something else (ClipDelta which I figured would not be chosen by anyone else).

EDIT: (Plugin_Autoload_and_Name_Precedence AND Plugin Autoload and Conflicting Function Names ):- http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Name_Precedence

[LouieChuckyMerry]

Hello. After much kind help I've finally made the switch to AviSynth+ and native 16-bit, and I'm wondering if there's any way to improve my encoding speed. My usual script, on a quad-core x64 Windows 7 setup, using x86 MeGUI with x86 AviSynth+ and the latest versions of all necessary plugins-filters is:

DGSource Information Here
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=x,ThSAD=xxx,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
ConvertToDoubleWidth()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
PreFetch(5)
# Sent To 10-bit x264

I ask because I'm achieving ~75% of the encoding speed I had with SEt's AviSynthMT and stacked 16-bit using older versions of the necessary plugins-filters, and I figure that I missed something along the way ;) . Thanks for any suggestions.

Edit: Any ideas anyone?

[wonkey_monkey]

Just out of curiosity:

VirtualDub2 can load various filetypes (MKV, MPEG2, MP4, etc) instantly, without - I assume - having to do any indexing. Is there are any reason why an AviSynth source filter couldn't work the same way, so as to do away with the slow first load? Or is there a source plugin that already does this?

[ChaosKing]

The only plugin I know of is LSMASHVideoSource. But it only supports ISO file containers, like *.mov, *.mp4, *.m4v, *.3gp, *.3g2, *.mj2, *.dvb, *.dcf, *.m21,

[poisondeathray]

DirectShowSource , DSS2 can too , but it can be unreliable

[wonkey_monkey]

The only plugin I know of is LSMASHVideoSource. But it only supports ISO file containers, like *.mov, *.mp4, *.m4v, *.3gp, *.3g2, *.mj2, *.dvb, *.dcf, *.m21,

Hmm, so it probably shouldn't say "It uses FFmpeg (libavcodec) to decode all supported audio and video formats." on the wiki, then (the bold text links to an FFmpeg page).

I'm somewhat wary of a filter which throws an exception for a missing file, as well...

[ChaosKing]

Hmm, so it probably shouldn't say "It uses FFmpeg (libavcodec) to decode all supported audio and video formats." on the wiki, then (the bold text links to an FFmpeg page).

As long the video is in a mp4 container it should be decoded. So not entirely false.:)

[qyot27]

It'd only be false if it said FFmpeg (libavformat, rather) was being used to demux it when using LSMASH[Video|Audio]Source. It isn't. LSMASH is demuxing it and passing the video and audio over to libavcodec. The LwLibav[Video|Audio]Source functions, on the other hand, do use only FFmpeg (libavformat->libavcodec).

[stax76]

@pinterf

Maybe you like this idea too:

https://forum.doom9.org/showthread.php?p=1876802#post1876802

[ryrynz]

Yeah please. 32-bit x86 can stop to stop being relevant.

[pinterf]

using x86 MeGUI with x86 AviSynth+
[...]
I ask because I'm achieving ~75% of the encoding speed I had with SEt's AviSynthMT and stacked 16-bit using older versions of the necessary plugins-filters, and I figure that I missed something along the way ;) . Thanks for any suggestions.

Edit: Any ideas anyone?
Without seeing the real memory consumption (avsmeter is a good help for that), I'd say that the default memory is too small for Prefetch(5). Try giving a larger SetMemoryMax value. Or change for x64.

[LouieChuckyMerry]

Without seeing the real memory consumption (avsmeter is a good help for that), I'd say that the default memory is too small for Prefetch(5). Try giving a larger SetMemoryMax value. Or change for x64.

Thanks for your reply, pinterf. I'll try various combinations of "SetMemoryMax()" and "PreFetch()" and see if I can improve my speed (and thanks for the AVSMeter reminder). I'm keen to try AviSynth+ x64; any suggestions for a good place to find the required x64 plugins-filters?

[Zetti]

http://avisynth.nl/index.php/AviSynth+_x64_plugins

[LouieChuckyMerry]

http://avisynth.nl/index.php/AviSynth+_x64_plugins

:thanks:

[wonkey_monkey]

converttoyv24, converttoyv16, converttoyv12, converttoy8 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)

[ChaosKing]

converttoyv24, converttoyv16, and converttoyv12 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)

You can unconfuse yourself here :D http://avisynth.nl/index.php/Convert

[pinterf]

converttoyv24, converttoyv16, and converttoyv12 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)
Perhaps once it did then from one point it didn't, when it was mapped directly to ConvertToYUV420 (and ...422, ...444). It should throw an error for non-8 bit colorspaces.

[wonkey_monkey]

You can unconfuse yourself here :D http://avisynth.nl/index.php/Convert

Nope, still just as confusing. Nothing on the page indicates whether a change in bit depth should be expected or not with those functions. I've also added converttoy8 to the list, as you really shouldn't expect this after using it:

https://i.imgur.com/8ujb2Jn.png

Perhaps once it did then from one point it didn't, when it was mapped directly to ConvertToYUV420 (and ...422, ...444). It should throw an error for non-8 bit colorspaces.

converttoyuy2 still does, presumably as it doesn't have a comparable function to be remapped to.

[ChaosKing]

There is also a table if you click on avisynth+ formats http://avisynth.nl/index.php/Avisynthplus_color_formats

As you can see YV12 is a shortcut for YUV420P8. Y10 is Luma channel in 10bit. But yes this shit is confusing and I have to look it up too. What's why I like this notation more YUV420P8.

But I guess it makes a bit more sense with this graphic:
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0d/Yuv420.svg/640px-Yuv420.svg.png
YV12 needs 12bytes for storage. (https://en.wikipedia.org/wiki/YUV)

[qyot27]

There is also a table if you click on avisynth+ formats http://avisynth.nl/index.php/Avisynthplus_color_formats

As you can see YV12 is a shortcut for YUV420P8. Y10 is Luma channel in 10bit. But yes this shit is confusing and I have to look it up too. What's why I like this notation more YUV420P8.

But I guess it makes a bit more sense with this graphic:
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0d/Yuv420.svg/640px-Yuv420.svg.png
YV12 needs 12bytes for storage. (https://en.wikipedia.org/wiki/YUV)
The point wonkey_monkey was making was that you can do:
Version()
ConvertToPlanarRGB()
ConvertBits(10)
ConvertToYV12()
and this results in YUV420P10. Which is not YV12, and trying to use ConvertToYV12 should have errored out in this case.

The reason is, as pinterf noted, the old ConvertTo[Y8|YV12|YV16|YV24] functions from 2.5 (YV12) and 2.6 (the other three) were turned into aliases for the subsampling-oriented ConvertTo[Y|YUV420|YUV422|YUV444] functions when high bit depth support was added in Summer 2016. There aren't individual functions to go directly to X color format @ specified bit depth, apart from the ones for packed RGB (ConvertToRGB[24|A32|48|A64]).

ConvertToYUY2 is still 8-bit-only because YUY2 is a packed format, and there is no support for packed YUV422 formats for >8bit. They literally don't exist in the AviSynth+ source code (the global option OPT_Enable_V210 notwithstanding, but that's a separate thing done on output through Video for Windows only).

[wonkey_monkey]

Deleted because I solved it. It was caused by a timing issue with a lookup table in my filter. Typical that I figure it out after posting about it!

[pinterf]

and this results in YUV420P10. Which is not YV12, and trying to use ConvertToYV12 should have errored out in this case.

Fixed in source on my github repo.
- Fix: ConvertToY8, ConvertToYV12, ConvertToYV16, ConvertToYV24 are now allowed only for 8 bit inputs.
Formerly these functions were allowed for 10+ bit colorspaces but were not converted to real 8 bit Y8/YV12/16/24.
Use ConvertToY, ConvertToYUV420, ConvertToYUV422, ConvertToYUV444 instead which are bit depth independent

[ChaosKing]

Maybe now it is time for a new release? :)

[pinterf]

Maybe now it is time for a new release? :)
Yep, since months, I will do it as soon as I have time. Probably soon.

And then? Since ultim recently gave us access to the original Avisynth+ repo, we'll have to think about what to do next.

[ChaosKing]

Does this mean http://avs-plus.net can be updated too?

[pinterf]

Does this mean http://avs-plus.net can be updated too?
We'll discuss the topic as well.

[wonkey_monkey]

ultim recently gave us access to the original Avisynth+ repo

What a time to be alive. Thanks for all the hard work, pinterf!

[Groucho2004]

Thanks for all the hard work, pinterf!Indeed, thanks for keeping Avisynth alive and the updates for mvtools2, masktools and many more.

:thanks:

[VoodooFX]

Any idea why InpaintFunc.avs(1.13-1.15) crash AviSynth+ r2772? "Inpaint" mode works ok, "Deblend" and "Both" modes instantly crash AviSynth+.
No problems with AviSynth 2.6.

How to quickly test it:
1) video file (short!)
2) bmp file (RGB24, same resolution as video, all solid black and small solid white "blob" at top-left corner.
3) InpaintFunc.avs and AVSInpaint.dll ( http://avisynth.nl/index.php/InpaintFunc )
4) script:
LoadCplugin("C:\AVSInpaint.dll")
Import("C:\InpaintFunc.avs")
InpaintFunc(mask="c:\test.bmp", loc="tl",mode="Inpaint",speed=1)


Report from AVSMeter:
AviSynth+ 0.1 (r2772, MT, i386) (0.1.0.0)
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\VCRUNTIME140.dll
Address: 0x72DC282E

I can reproduce this, VDub also reports an access violation. However, my culprit is avisynth.dll, not VCRUNTIME140.dll.

Works fine with classic Avisynth 2.6. You should post this in the AVS+ thread.

[pinterf]

Any idea why InpaintFunc.avs(1.13-1.15) crash AviSynth+ r2772? "Inpaint" mode works ok, "Deblend" and "Both" modes instantly crash AviSynth+.
No problems with AviSynth 2.6.

How to quickly test it:
1) video file (short!)
2) bmp file (RGB24, same resolution as video, all solid black and small solid white "blob" at top-left corner.
3) InpaintFunc.avs and AVSInpaint.dll ( http://avisynth.nl/index.php/InpaintFunc )
4) script:
LoadCplugin("C:\AVSInpaint.dll")
Import("C:\InpaintFunc.avs")
InpaintFunc(mask="c:\test.bmp", loc="tl",mode="Inpaint",speed=1)

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.

[VoodooFX]

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.

Did you changed mode="Inpaint" to mode="Deblend" to check if it crash? ("Inpaint" doesn't crash)

[pinterf]

Did you changed mode="Inpaint" to mode="Deblend" to check if it crash? ("Inpaint" doesn't crash)
It worked O.K.
But when I was trying to call it more than once
InpaintFunc(mask="test.bmp", loc="tl",mode="Deblend",speed=1)
InpaintFunc(mask="test.bmp", loc="tl",mode="Both",speed=1)

Now it crashes, we are happy now :)

EDIT: The plugin somehow clears or is overwriting an existing framebuffer pointer?
The crash itself occurs at an internal RGB24-RGB32 conversion but since the destination frame does not exist (zero pointer) it will show "access violation".
I'll have a look at the dll source.

[qyot27]

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.
They can be artificially generated:

Video:
ffmpeg -f lavfi -i testsrc -vcodec libx264 -preset ultrafast -crf 18 -t 10 test.mkv

Mask script:
v1=BlankClip(1,320,240).KillAudio()
v2=v1.Invert().PointResize(60,60)
Overlay(v1,v2,mode="blend")

Mask:
ffmpeg -i maskscript.avs test.bmp

The (not helpful, because all the binaries in the chain have been stripped) output of gdb seems to point at the cause of the Deblend and Both modes segfaulting being within DevIL, but some of the build warnings when compiling AVSInpaint itself may point more to internal API usage not being correct in those modes when used with modern AviSynth.

This is what happens when building it with only the minimal amount of fixes (avsplus r2883/7c334a0/HEAD (https://github.com/AviSynth/AviSynthPlus/commits/MT) header/lib, adjusting the Makefile to use 32-bit lib and -m32 flag, fix typo in AVSInpaint.c avs_is_yuy->avs_is_yuv):
$ make
gcc -m32 -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=i386 -c -o AVSInpaint.obj AVSInpaint.c
In file included from AVSInpaint.c:94:
AviSynth_C.h:99:21: warning: enumerator value for 'AVS_CS_PLANAR' is not an integer constant expression [-Wpedantic]
99 | AVS_CS_PLANAR = 1 << 31,
| ^
In file included from AVSInpaint.c:94:
AviSynth_C.h:690:1: warning: missing initializer for field 'array_size' of 'AVS_Value' {aka 'const struct AVS_Value'} [-Wmissing-field-initializers]
690 | static const AVS_Value avs_void = {'v'};
| ^~~~~~
AviSynth_C.h:675:9: note: 'array_size' declared here
675 | short array_size;
| ^~~~~~~~~~
AVSInpaint.c: In function 'Inpaint_Create':
AVSInpaint.c:254:93: warning: unused parameter 'Data' [-Wunused-parameter]
254 | AVS_Value AVSC_CC Inpaint_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Deblend_Create':
AVSInpaint.c:929:93: warning: unused parameter 'Data' [-Wunused-parameter]
929 | AVS_Value AVSC_CC Deblend_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Analyze_Create':
AVSInpaint.c:1245:93: warning: unused parameter 'Data' [-Wunused-parameter]
1245 | AVS_Value AVSC_CC Analyze_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Analyze_GetFrame':
AVSInpaint.c:1432:81: warning: unused parameter 'FrameNo' [-Wunused-parameter]
1432 | AVS_VideoFrame * AVSC_CC Analyze_GetFrame(AVS_FilterInfo * FilterInfo, int FrameNo)
| ~~~~~^~~~~~~
AVSInpaint.c: In function 'DistanceFunction_Create':
AVSInpaint.c:1449:102: warning: unused parameter 'Data' [-Wunused-parameter]
1449 | AVS_Value AVSC_CC DistanceFunction_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'CreateGaussKernel':
AVSInpaint.c:2415:49: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
2415 | for (k=-Size ; k<=Size ; k++) Kernel[k] = (abs(Center-k)<1.0)?(1.0-abs(Center-k)):0.0;
| ^~~
AVSInpaint.c:2415:73: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
2415 | for (k=-Size ; k<=Size ; k++) Kernel[k] = (abs(Center-k)<1.0)?(1.0-abs(Center-k)):0.0;
| ^~~
gcc -m32 -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=i386 -shared -o AVSInpaint.dll AVSInpaint.obj AviSynth32.lib


In one build test a day or two ago, I did notice a warning emitted concerning avs_is_same_colorspace, which given what pinterf just noted about the RGB24/32 conversion, might be where this is coming from.

[VoodooFX]

It worked O.K.
But when I was trying to call it more than once
InpaintFunc(mask="test.bmp", loc="tl",mode="Deblend",speed=1)
InpaintFunc(mask="test.bmp", loc="tl",mode="Both",speed=1)

Now it crashes, we are happy now :)

EDIT: The plugin somehow clears or is overwriting an existing framebuffer pointer?
The crash itself occurs at an internal RGB24-RGB32 conversion but since the destination frame does not exist (zero pointer) it will show "access violation".
I'll have a look at the dll source.

It should crash with one call (InpaintFunc is not meant to work in two instances).

Here I prepared example (should work extracted to "C:"): https://drive.google.com/open?id=1fKu1PIr3oDQdiUN5eu0cezjsVcIL5iHb

[pinterf]

Please test this build
https://drive.google.com/open?id=1AQ1ZmRvVbGhXuL_xxuGX2ukXE4Uy7nWV

[VoodooFX]

I tested new build, and both 32 & 64 bits doesn't crash. Thank you.

[hello_hello]

I also posted in the other thread, but the new AVSInPaint build is fine on XP too.

Thank you!

[wonkey_monkey]

It is stated in the Wiki that:

In AviSynth each frame is most of the time aligned to an address divideable by 16. The exception for this rule is when crop() has been used.

But when I use crop it seems like I always get an aligned address from GetReadPtr(). Is frame alignment now always enforced?

Follow up question: what is GetOffset() for?

[StainlessS]

Default crop align for Avs+ is now (I think) True, wheareas False for Std Avs [EDIT: if not aligned via eg RoboCrop, then produces an error alert from AVS+, on return].

from Avs v2.58 Version Header 3 [the compressed help with SDK has both Version 6 (avs+) and v2.58 version 3 headers, for easy perusal],

// generally you shouldn't use these three
VideoFrameBuffer* GetFrameBuffer() const { return vfb; }
int GetOffset() const { return offset; }
int GetOffset(int plane) const { switch (plane) {case PLANAR_U: return offsetU;case PLANAR_V: return offsetV;default: return offset;}; }

For Planar, is usual to allocate single buffer, where Y plane is aligned at start of buffer, and U, and V somewhat later, GetOffset returns the offset from buffer base (methinks).

EDIT: When you swap U and V, all it probably does is swap offsets.
EDIT: Above also (I think) mirrors official standards for file based layout of raw YUV streams [with some alignment padding for offsets and also each individual raster line].

[wonkey_monkey]

Oh okay, phew, I thought I'd be going wrong all these years.

After aligned cropping it seems that Offset ends up non-zero (e.g. 16). Not sure why, probably doesn't matter.

[StainlessS]

I think current AVS+ alignement is 32 [EDIT: Actually 64] (avs std 16) (probably thinking about 64 next, or whatever eg AVX2/later requires).

EDIT: As shown above, having v2.58 Version 3 header Baked Code, is quite handy to have [the raw cookie dough code tells you very little].

EDIT: Below some meanderings, no idea why I just wrote it.


malloc/new

Library writers long ago found that it is inefficient to allocate small blocks of memory, as that produces memory fragmentation, and so slower finding of suitable sized mem block.
So, was usual in C library, when user requested block size of eg 1 bytes, to carve off 8 bytes, and hand pointer back to user. Only 1 byte of this block belonged to the user,
but there would be no error encountered if user used up to 8 bytes as carved out from free memory lists.
Memory size returned was rounded up to a multiple of 8 bytes, so requesting 1 to 8, would carve out 8 bytes, 9 to 16, 16 bytes etc.
An additional bonus of this round up to 8 bytes, was that the memory block when free'ed, there was always enough room in that block to create a link in a linked list, for use in the
free memory list arrangement. The free memory block kept track of 'itself', without any additional overhead, and mem fragmentation was much less and also faster to find block of
sufficient size. [link list struct would hold 32 bit int size of mem block, and 32 bit pointer to next link in list, both 4 byte values on 32 bit system].
Above round up to 8 bytes also enabled the ANSI spec that malloc() returns a pointer to mem bock that is castable to a memory block structure of any type [or words something like that],
ie, some structures need be located on a memory boundary of maybe 2 bytes, 4 bytes or 8 bytes. If the initial heap base pointer is rounded to multiple of 8 bytes, and all mem blocks are a multiple
of 8 bytes, so all malloc blocks will return a mem bufer on 8 byte boundary.

Unfortunately, above used to cause novice C proggers to cock up when allocating string buffers, for small strings (less than 8 chars), as there were no problems produced when forgetting
to add 1 bytes for the nul term sentinel (zero byte) at end of string. This due to habit of writing C examples using "fred" and "ted" sized strings.
Novice C proggers would get the impression that it was unnecessary to add that 1 extra byte for the nul term because they never experienced any errors,
but of course this is bad, and perhaps the hardest of all bugs to track down.

Imagine you created a DBase for some project, and that it held Name field, and Title field, and Address etc, but that in the title field, you forgot to add the 1 byte for nul term.
Your DBase might go on seemingly OK for 5 or more years without any trouble at all, then one day you get new accound created for title "Princess", exactly 8 bytes in length, but
requiring 9 bytes in total for the buffer. you ask for 8 bytes, and this time you actually need 9, kaboom!!!, you blast a byte that does not belong to you, belongs to some other
structure or maybe even a link in the free memory list. As you repeatedly save and load (at day end/start) the DBase, each and every time, the problem is likely to move about, causing
corruption in differeing parts of your DBase, and eventually it will be noticed and become a problem.
Where do you start to look for the problem ???, you got 5 years spare to keep tabs on your next newly created DBase?

Because of the C libs malloc/calloc/new etc optimisation stuff, you have to be paranoid about that 1 extra byte, and suggest always allocate string buffers via a single function
which auto adds the required extra nul term byte. [look up the non ANSI function 'strdup()' and knock it up yourself if not supplied with your compiler
[STRICT_ANSI (or whatever the define is) will exclude it even if it does exist in your compiler].

For x64, it is most likely [ie definite] that the 8 byte fragment size mentioned above will be 16 bytes, so if you request 1 bytes from malloc, you will actually get 16, making the
above mentioned failure to add 1 byte for nul term on string buffer, an even bigger problem for string buffer bug hunting.

Also, a little aside,
Some C docs for calloc() seem to have ommitted the fact that calloc will auto zero memory [where malloc does not], think maybe MicroSoft (or someone, forgot about this more than insignificant
fact and just missed it out), and everybody else copied the erroneous docs. Perhaps your compiler mentions this clearing of memory by calloc, perhaps not [somewhere about year 1992->2000, they all/many
[cross platform] seemed to have forgotten about it].

[pinterf]

Avs+ alignment is 64. Crop parameter align=false does nothing. Avx2 needs 32, but it's only the present (probably processors from the last five years all support Avx2) Avx512 is the future which likes 64. However Avx2 code in Expr likes 64 byte alignment as well.
Plugin writers would safely omit pre-Avx2 optimization nowadays. C, Avx2, avx512 (at least for avs+ plugins)

[StainlessS]

Avs+ alignment is 64
Is that a recent change in avs+ ?

EDIT:- https://github.com/pinterf/AviSynthPlus/releases

Avisynth+ r2542 (20171114)
Fixes
...
modification, additions

Add: Expr filter
Add: Levels: 32 bit float format support
Optimized: Faster RGB (full scale) 10-16 bits to 8 bits conversion when dithering
Other: Default frame alignment is 64 bytes (was: 32 bytes). (independently of AVX512 support)
Built with Visual Studio 2017, v141_xp toolset
some fixes in avisynth_c.h (C interface header file)
experimental x64 build with size_t frame offsets for testing more properly written C interfaces

[wonkey_monkey]

Excellent, I shall optimise to my heart's content. I only have AVX though :(

[StainlessS]

Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)


Colorbars(pixel_type="YV12")
ConvertBits(10) # return this looks ok
return ConvertToY8 # EDIT: ConvertToY() Same

https://i.postimg.cc/4yGRxYNP/zzz-00.jpg (https://postimages.cc/)

EDIT: With info added
https://i.postimg.cc/0yXfkh2H/zzz-02.jpg (https://postimages.cc/)

Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.php?p=1868592#post1868592
2nd code block


ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411 # ConvertBits Will Fail
#ConvertToY8 # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.


Think was also reported in Avs+ thread, but cannot find it.

Please ignore this post.

EDIT: Dec 2018, Wonkey_Monkey already reported problem here:- https://forum.doom9.org/showthread.php?p=1860916#post1860916

Pinterf response
Thanks. Seems that it's not guarded by an error message to allow only 8 bit sources. Based on the upside down result, it simply runs on the 8 bit packed rgb case.

[wonkey_monkey]

pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.

[pinterf]

pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.
Are you missing the 4:2:2 colorspaces such as YV16? The others seem to be supported (source: online documentation)

[wonkey_monkey]

Those, and RGB24/48. I'm trying to be more inconclusive these days and to make sure my filter is fast for every colour space :)

The YUV float colour spaces seem to be wrong (unbiased chroma?):

https://i.imgur.com/kNz0QbQ.png

[pinterf]

The YUV float colour spaces seem to be wrong (unbiased chroma?):


Yeah, unbiased chroma. I have fixed it in both ColorBars version, those were hopefully the last ones in connection with zero-based chroma thing.

[real.finder]

Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)


Colorbars(pixel_type="YV12")
ConvertBits(10) # return this looks ok
return ConvertToY8 # EDIT: ConvertToY() Same

https://i.postimg.cc/4yGRxYNP/zzz-00.jpg (https://postimages.org/)

EDIT: With info added
https://i.postimg.cc/0yXfkh2H/zzz-02.jpg (https://postimages.org/)

Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.php?p=1868592#post1868592
2nd code block


ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411 # ConvertBits Will Fail
#ConvertToY8 # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.



I just test this with ConvertToY (which should be ok)

Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY


yes there are bug here

edit: it seems mpc problem
Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY
ConvertBits(8)

work ok

[pinterf]

Test build r2888
https://drive.google.com/open?id=1nfbYGSHFtxfDfkgT7Pnn7KziYTf0BO_Q

For new features and fixes since r2772 see readme_history.txt or the shorter readme.txt.

[Wilbert]

Yep, since months, I will do it as soon as I have time. Probably soon.

And then? Since ultim recently gave us access to the original Avisynth+ repo, we'll have to think about what to do next.
I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.

[qyot27]

I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.
If we were going to go with 0.x versioning, IMO it would be 0.4. 0.2 was very nearly officially released around the r1828 mark, and 0.3 would very likely have been the addition of high bit depth pixfmts and GCC compliancy, with 0.4 being where we'd be now.

That said, I've been leaning more toward jumping the major version too (https://github.com/qyot27/AviSynthPlus/commit/cd0189a28de97da6655e74ac58f29117c00a7235) (that's still in a development branch; I won't push it upstream unless/until there's discussion about it). Namely because there are programs that check for version numbers and got confused by AviSynth+ starting over at 0.x (sure, the proper way would have been to check AVISYNTH_INTERFACE_VERSION, but there's also user confusion over the versioning, and the inadequacy of using sequential revisions on the idea of integrating with pkg-config).

[pinterf]

Meanwhile a question that emerged over another topic, since I wasn't able to compile a C plugin with Visual C++ which was recognized as a C plugin in both Avisynth+ and classic Avisynth 2.6

The code inside the different Avisynth versions is trying to identify a DLL as a C plugin by searching the following entries:

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)

The common solution would be using avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6.
Unfortunately this kind of semi-decorated name is not supported in VC++ (at least I was not able to do it)

The other choice: the non-decorated avisynth_c_plugin_init is not recognized by Avisynth+.

Question (if somebody remembers):
- why are C plugins identified differently in Avisynth+
- does it have any drawback if I put back the support for the nondecorated name?

[pinterf]

@Wilbert: yes, changing version number makes sense.


That said, I've been leaning more toward jumping the major version too (https://github.com/qyot27/AviSynthPlus/commit/cd0189a28de97da6655e74ac58f29117c00a7235) (that's still in a development branch; I won't push it upstream unless/until there's discussion about it). Namely because there are programs that check for version numbers and got confused by AviSynth+ starting over at 0.x (sure, the proper way would have been to check AVISYNTH_INTERFACE_VERSION, but there's also user confusion over the versioning, and the inadequacy of using sequential revisions on the idea of integrating with pkg-config).
Seems logical. You mentioned pkg-config in your comment it's only for your linux environment?
I wonder how many programs or scripts rely on checking "0.1" or "MT" in version string?

[Groucho2004]

I wonder how many programs or scripts rely on checking "0.1" or "MT" in version string?I wouldn't worry about that. Whatever scripts and/or programs rely on this will be updated. After all, making AVS+ clearly distinguishable without script acrobatics should be the target.

[StainlessS]

making AVS+ clearly distinguishable without script acrobatics should be the target.
++1.

small prob,(tested only on current test version r2890) [confusing at the very least],


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)

https://i.postimg.cc/FRm4wX4C/test-00.jpg (https://postimages.org/)

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]

[pinterf]

small prob,(tested only on current test version r2890) [confusing at the very least],


ORG.BilinearResize(2,1) # Dest height of 1 problem
...
ORG.BilinearResize(1,2) # Dest width of 1 problem


Resizer algorithms all have a minimum width/height requirement which is not fulfilled here. Regarding the error message: yep, not really human understandable. "Don't do that next time please" would be more than enough.

[qyot27]

Seems logical. You mentioned pkg-config in your comment it's only for your linux environment?
Not entirely. pkg-config can be used on Windows (particularly inside MSys2, Cygwin, etc.) or in cross-compile environments, and programs that want to link to AviSynth can refer to the pkg-config file to make sure things like the library location, includes, and any other required libraries and flags are passed to the configuration. It does generally favor the GCC or Clang-mimicking-GCC side, though, since CMakeLists.txt doesn't use the normal *nix FHS conventions when using MSBuild (although it will if using MSVC with either NMake Makefiles or Ninja).

I also use it to get the Version information parsed for the checkinstall step in the cross-compile guide (https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L4340), as pulling the version from the .pc file is generally easier than wrangling with other means of getting it.

[qyot27]

Meanwhile a question that emerged over another topic, since I wasn't able to compile a C plugin with Visual C++ which was recognized as a C plugin in both Avisynth+ and classic Avisynth 2.6

The code inside the different Avisynth versions is trying to identify a DLL as a C plugin by searching the following entries:

AVS+ x64:
avisynth_c_plugin_init
_avisynth_c_plugin_init@4

AVS+ Win32
_avisynth_c_plugin_init@4
avisynth_c_plugin_init@4

AVS 2.6 Win32
avisynth_c_plugin_init@4
avisynth_c_plugin_init

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)

The common solution would be using avisynth_c_plugin_init@4 that works for both Avs+ and Avs 2.6.
Unfortunately this kind of semi-decorated name is not supported in VC++ (at least I was not able to do it)

The other choice: the non-decorated avisynth_c_plugin_init is not recognized by Avisynth+.

Question (if somebody remembers):
- why are C plugins identified differently in Avisynth+
- does it have any drawback if I put back the support for the nondecorated name?

The different styles it looks for are one used by MSVC and one by GCC, based on what bittage the binary is. On MSVC's side,
https://docs.microsoft.com/en-us/cpp/build/reference/decorated-names?view=vs-2019#FormatC:
The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. This is also the decoration format that is used
when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. Note that in a 64-bit environment, functions are not decorated.
Calling convention Decoration
__cdecl Leading underscore (_)
__stdcall Leading underscore (_) and a trailing at sign (@) followed by the number of bytes in the parameter list in decimal
_cdecl and _stdcall are the only relevant ones here. The Win32 decorations as provided by MSVC would be _function@X if left alone. __declspec(dllexport) also causes effects on this.

In GCC, however, the result of _stdcall is function@X and _cdecl is function. The C interface was initially designed to allow plugins that could be built with GCC, so 2.6 looks explicitly for GCC's conventions (it would appear).

http://www.willus.com/mingw/yongweiwu_stdcall.html

Essentially, when using _cdecl, MSVC agrees with GCC in only two instances: __declspec(dllexport) and using a .def file. With _stdcall, MSVC and GCC never match (although this is mostly the fault of GCC or MinGW not prefixing the _stdcall functions with a leading underscore; I remember this being difficult to manuever in regard to the FFMS2 C-plugin and external programs using it as a substitute for the normal C++ plugin, not sure if it was ever satisfactorily resolved).

On 64-bit, thankfully, there is only one valid decorating scheme, function. MSVC and GCC both agree on this, and this is why 64-bit programs can use either MSVC or GCC builds of AviSynth+, but 32-bit programs cannot (leading to the need for that rat's nest in avs/capi.h with the AVSC_WIN32_GCC32 define).

What's true of the AviSynth library itself interacting with a host program like FFmpeg is just as true of plugins interacting with the AviSynth library itself.

My guess is that AVSInpaint is not utilizing any sort of dllexport mechanics, so it's falling back onto the default behavior based on the compiler. A Github search seems to agree here:
https://github.com/pinterf/AvsInpaint/search?q=dllexport&unscoped_q=dllexport
vs FFMS2 (where the dllexport stuff is common to both C++ and C interfaces):
https://github.com/FFMS/ffms2/blob/master/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.

[wonkey_monkey]

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.

[Wilbert]

Visual C++ supports:
_avisynth_c_plugin_init@4
avisynth_c_plugin_init (through .def file)
It also supports avisynth_c_plugin_init@4 through a definition file right?

LIBRARY InvertNeg.dll
EXPORTS
avisynth_c_plugin_init@4=_avisynth_c_plugin_init@4

Or do i miss something?

[Wilbert]

Making this more headache-inducing, the C plugin tutorial on the AviSynth Wiki and docs don't even mention the dllexport approach with _stdcall, so there's probably a greater-than-average chance a random C plugin won't be using that, and instead will just be using _cdecl (fine for 64-bit, not fine for 32-bit). Like I said in the other thread, it's a nightmare.
Feel free to add this.

A long time ago i added the following

AVSC_CC stands for Avisynth calling convention. Right now it is stdcall (it used to be cdecl when the C interface was exposes through seperate plugin). By using AVSC_CC you should be able to maintain source code compatibility when the calling convention changes.

to http://avisynth.nl/index.php/Filter_SDK/CInvertNeg

But i forgot to add what happens if you use cdecl despite this. If you do, is the issue that you can't compile the plugin with MSVC then? Are there more issues?

[qyot27]

Feel free to add this.
I feel like I need to fully understand the intricacies of it first before trying to do so. As I describe below, my grasp on it is pretty shaky. Even my last post about it I was really uncertain if I was confusing things.

A long time ago i added the following

to http://avisynth.nl/index.php/Filter_SDK/CInvertNeg

But i forgot to add what happens if you use cdecl despite this. If you do, is the issue that you can't compile the plugin with MSVC then? Are there more issues?
It makes my head hurt every time I try thinking about it. I think I figure it out, then test it to find it's completely wrong, go back to what I thought I was doing before, and it's wrong too. And then I try to cool off for a couple days and approach it later, only to completely forget what I did a couple days ago. I suppose what it needs is a thorough, case-by-case test of the different possible configurations to see which instances are valid under which compiler (and which fail to build at all), and under which build of AviSynth+.

Not to mention the possible incompatibilities that might arise if the dev library of AviSynth is from a MSVC or GCC build, and then attempting to use that sort of plugin build with the AviSynth+ host built by the other. Because I think that might have been where I was hitting a snag when I was playing around with AVSInpaint before pinterf updated it.

[pinterf]

It also supports avisynth_c_plugin_init@4 through a definition file right?

Or do i miss something?

Thanks! I didn't try this one.

[pinterf]

YV16 is said to be the planar equivalent of YUY2, but chroma placement seems to be treated differently when converting each of those to RGB32. Is that correct? Or at least, not wrong?

PS converttoyuy2 from a YUVA colourspace appears to be faulty.
Thanks, I'll check it. Meanwhile you can try ColorBars with 4:2:2 and 4:1:1 color spaces, though latest test build is still w/o rgb24/48 support, but since then I've done it, see git source.

[StainlessS]

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
ResetMask

Applies an opaque (white) alpha channel to a clip. The alpha channel of an RGB32 clip is not always well-defined, depending on the source (it may contain random data); this filter is a fast way to apply an all-white mask.

ResetMask(clip clip)

ResetMask(clip clip, float mask) AVS+

clip clip =

Source clip. Alpha channel will be set to opaque. Color format must be RGB32.
AVS+ also supports RGB64, PlanarRGBA and YUVA.

mask float =

AVS+ Optional mask value to set. No bit-depth scaling occurs, but value is clipped to be between 0 and maximum_pixel_value.
Maximum opacity is 1.0 for 32 bit float formats, and (1^bit_depth) - 1 for 8-16 bit formats

[StainlessS]

Dont think this posted as yet (results from r2890 test build).


# E_1
W=100 H=100
Colorbars(Pixel_Type="RGBAP16")
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA)
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)
Return last

Seem to be using rubbish plane (results different every time).
https://i.postimg.cc/8jMhhnGF/E-1-00.jpg (https://postimg.cc/8jMhhnGF)


This one produces Access Violation [EDIT: x86/x64].

# E_2
W=100 H=100
Colorbars
ConvertToPlanarRGBA
ConvertBits(16)
# EDIT: Below, same as above E_1 code block
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Maybe the Alpha plane is rubbish (main clip or blankclip. EDIT: As main clip alpha not really used on layer, probably BlankClip Overlay Alpha).
EDIT: Below extract Alpha looks ok for both Main and Overlay clips ??? [EDIT: Also main and Overlay clips both look alright]

# E_2
W=400 H=400
Colorbars
ConvertToPlanarRGBA
ConvertBits(16)
#Return Last.ExtractA.info # Solid black 16 Bit
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF) # Presume specify color as 8 bit values. All Alpha bits set, fine BLUE.
#Return O.ExtractA.info # Solid white 16 bit
Lev = BitLShift(1,Last.BitsPerComponent)-1 # All bits set eg 16 bit = $FFFF (Presume for Layer Level max, should use $10000 for YUV & RGB and $10001 for YUVA & RGBA
Layer(O,op="add", Level=Lev,x=(Width-O.width)/2,y=(Height-O.Height)/2)

EDIT: Outputting x and y Layer coords and also Lev for above code block to debugView produce x=120 y=40 Lev=$FFFF, so nothing weird there.
EDIT: Maybe some bad intermediate clip/buffer is used during Layer.
EDIT: ConvertBits(8) as last step still crash PotPlayer and VDub2, so problem not external to Avs+.
EDIT: Layer with Lev=0, still crash.
EDIT: Source as John Meyer Parade clip YV12, Resized to 640x480, instead of colorbars source, same result, still crashes, seems unrelated to colorbars.
EDIT: Remove ConvertBits(16), still crashing on 8 bit planar [convinced I tried that before posting and it did not crash].

# E_3
W=400 H=400
Colorbars
ConvertToPlanarRGBA # 8 bit Planar
O=Last.BlankClip(width=W,height=H,Color=$FF0000FF)
Layer(O,op="add", Level=0,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Change "add" to Layer(op="fast"), looks OK when W and H = 400, but a bit screwey when 100 ??? ... No Crash, but surely Level=0 should be no change to colorbars.
EDIT: No, 'fast' is just average of the two and does not use level, so should look different, but still a bit screwy when W and H = 100.

# 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)

https://i.postimg.cc/jwkJ4qSs/E-4-01.jpg (https://postimg.cc/jwkJ4qSs)


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.

W=400 H=W
Colorbars
convertToPLanarRGB # RGB 8 bit planar no alpha
O=Last.BlankClip(width=W,height=H,Color=$000000FF) # blue, no alpha
Layer(O,op="add", Level=$7F,x=(Width-O.width)/2,y=(Height-O.Height)/2)


EDIT: Thus far, I aint found any problems with YUV/A, but I'll be playing a lot with Layer over next few days, and if there are probs, I'm just the one to find em'. :)

EDIT: Nuther prob with float RGB/RGBA, access violation.

W=400 H=W
Colorbars
convertToPlanarRGBA
ConvertBits(32) # RGB Float Alpha OR no alpha, both crash
BCol = (Last.HasAlpha) ? $FF0000FF : $000000FF
O=Last.BlankClip(width=W,height=H,Color=BCol)
Layer(O,op="add", Opacity=0.5,x=(Width-O.width)/2,y=(Height-O.Height)/2) # Using secret Opacity arg instead of int Level
ConvertBits(8)


EDIT: Hi again P, you must be getting a bit sick of me by now, well I'm not yet done :)
Nuther Layer prob, slightly different.
Set X=20, and no probs, layers blankclip all the way to RHS and bottom.
Set X=18, and leaves a two pixel gap at RHS and bottom of frame, only works correctly when X multiple of 4. [If YUY2 then bottom OK, only RHS green line]

BlankClip(width=640,height=480,Pixel_type="YV12",Color=$00FF00)
X=18
Y=X
W=Width-X
H=Height-Y
Q=Last.BlankClip(Width=W,Height=H,color=$FFFF00FF)
#Return Q.Info
Layer(Q,op="add",Level=255,x=X,y=Y)
Subtitle(String(X,"X=%.0f"))
return last

First, X=20
https://i.postimg.cc/BQ7xhRfT/X-20.jpg (https://postimages.org/)
X=18
https://i.postimg.cc/L65PZvgn/X-18.jpg (https://postimages.org/)

EDIT: YV411: X=20
https://i.postimg.cc/q7swZQLp/YV411-20.jpg (https://postimages.org/)

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

[pinterf]

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=1FCby_dSxnpPmMkCnEhr22zsCtnWiEo9W

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

[real.finder]

new Avisynth+ r2894 test build


will the next stable update will have MT runtime (https://forum.doom9.org/showthread.php?p=1876610#post1876610) fix and this (https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150) and this (https://forum.doom9.org/showthread.php?p=1873360#post1873360)? :)

[pinterf]

will the next stable update will have MT runtime (https://forum.doom9.org/showthread.php?p=1876610#post1876610) fix and this (https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150) and this (https://forum.doom9.org/showthread.php?p=1873360#post1873360)? :)
1.) MT runtime: yes I'd like to do it (but probably not in next release - if the "next" means very near future)
2.) First "this" (unload plugin DLLs and reload only which needed): probably not.
3.) What's wrong with the second "this"?

[StainlessS]

New test build, ..., you dont get rid of me that easily.


Function StringRepeater(String BaseS, String RepS, int n) { # https://forum.doom9.org/showthread.php?p=1878193#post1878193
# Add n instances of repeat string RepS, to base string BaseS.
return (n>=1) ? StringRepeater(BaseS+RepS,RepS,n-1):BaseS
}

Blankclip(color=$FFFFFF)
ConvertToRGB24
#ConvertToRGB48
#ConvertToRGB64
S=StringRepeater("Last",".Blur(1.58)",500)
Eval(S)
return last.Info


RGB24 [RGB32 & RGB48 similar]
https://i.postimg.cc/FKBWLvpw/SRep24.jpg (https://postimages.org/)

RGB64
https://i.postimg.cc/XY873HLr/SRep64.jpg (https://postimages.org/)

"Nobody expects the Spanish Inquisition". :)

[pinterf]

New test build, ..., you dont get rid of me that easily.

Nice catch. Fixed on git: RGB64 Blur leftmost column artifact

No new build, you'll probably find more glitches.

[real.finder]

3.) What's wrong with the second "this"?

it can't has "universal Expr" https://forum.doom9.org/showthread.php?p=1873444#post1873444

[StainlessS]

you'll probably find more glitches.
Hope not but you never can tell.
Getting there step by step, looking quite good.
Looks like S_ExLogo may support all colorspaces that layer supports. [wonder if we have to support YAxx at some point (internally, dont think exists externally, <maybe just strip alpha>)]
https://i.postimg.cc/dLMSNk4b/test-zz.jpg (https://postimg.cc/dLMSNk4b)
Thanks muchly for all of the nice new Layer() stuff, we is gettin' there. :)

[pinterf]

it can't has "universal Expr" https://forum.doom9.org/showthread.php?p=1873444#post1873444

Universal (lut or Expr) expressions make us lazy. I have already put thousands of hacks into the lut and Expr expression syntax.
But sometimes we have to use "IF float ELSE ".

32 bit float expressions can be tricky, using a generic expression would be sub-optimal for lower bit depths.

Anyway, this one seems to work properly for me (I'm using different y and u/v expression) for both 16 and 32 bits:

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)

I'd rather use Expr for high bit depth (speed)

[real.finder]

Universal (lut or Expr) expressions make us lazy. I have already put thousands of hacks into the lut and Expr expression syntax.
But sometimes we have to use "IF float ELSE ".

32 bit float expressions can be tricky, using a generic expression would be sub-optimal for lower bit depths.

Anyway, this one seems to work properly for me (I'm using different y and u/v expression) for both 16 and 32 bits:

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)

I'd rather use Expr for high bit depth (speed)

I am with you here, but sometimes these lazy friendly things help even for none lazy people in testing purpose

I will use "IF float ELSE" only if the lazy method slower :)

[pinterf]

I am with you here, but sometimes these lazy friendly things help even for none lazy people in testing purpose

I will use "IF float ELSE" only if the lazy method slower :)
Passing a differently assembled expression can affect performance and sometimes worth doing it.

Unlike the lut family, Expr can use constant folding internally when it pre-scans an expression. The expression e.g. range_max - range_min (RPN: "range_max range_min -") is a constant expression known before JIT compilation is done, so it'll be replaced with a single constant. (Other optimizations exist in Expr preprocessor such as eliminating "*1" and "+0", replacing "x power 2" with a much faster x*x, etc...)

Since lutxyz is not using JIT (Just In Time) compilation, the subtraction is done as a separate step. In lut versions where the lookup table is precalculated (e.g. lutxyz in 8 bits) this does not affect performance much because the actual expression evaluation is done once during filter creation (unless it's working in a runtime evaluated function, because the size of this lut is 256*256*256 = 16777216 which takes significant time if expression is complex).

[GillesH]

Quick test with the latest AVS+ r2895.
With a active RunTime Function in MT Mode, I no longer have the error message reported to the first post of this topic.
https://forum.doom9.org/showthread.php?t=176502
But, total freezing of the script with active MT (Prefetch).

RunTime Functions works, always, normally WITHOUT MT.

[LouieChuckyMerry]

Hello. I'm attempting to graduate from AviSynth+ x86 to AviSynth+ x64 but I'm encountering difficulty. With Win 7 x64 and MeGUI, my standard script:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
ConvertToDoubleWidth()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
ConvertFromDoubleWidth()
PreFetch(X)

runs fine with MeGUI x86-AviSynth+ x86. When I try to run the same script with MeGUI x64-AviSynth+ x64, I can index, load, and start the script without a problem, but receive the error message "H.264 (MPEG-4 AVC) encoder has stopped working" within a few seconds of starting it. However, if I hash-out the "F3KDB" lines thusly:

SOURCE INFORMATION HERE
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=X,ThSAD=XXX,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
# ConvertToDoubleWidth()
# F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
# ConvertFromDoubleWidth()
PreFetch(X)

the script runs without a problem. I've the minimum plugins necessary for x86 and x64: Dither(_64bit).dll, F3KDB(_64bit).dll, FastLineDarkenMTMod1_44.avsi, MaskTools2_2_18_0MTDualSignatureMod_pinterf(_64bit).dll, MVTools2_7_41_0MTMod_pinterf(_64bit).dll, and SMDegrainMod_rf_3.1.2.101s.dll.

I realize this possibly (probably) isn't an AviSynth+ issue but I couldn't come up with a better place to post a question given the number of geniuses frequenting this thread. Thanks for any redirection or help :) .

[Natty]

try adding input and output depth parameters in f3kdb

[qyot27]

Don't try to use MeGUI to debug anything. Pass the script to AVSMeter or FFmpeg (or mpv) or x264 itself and see what error gets thrown there. Because I can almost guarantee you it's because you're using the new AviSynth+ high bit depth-compatible build of f3kdb and yet still using the input_mode and output_mode parameters, which were removed (technically also the DoubleWidth conversions, but that's mostly because they're irrelevant now, not because they'd actually cause an error).

[FranceBB]

Because I can almost guarantee you it's because you're using the new AviSynth+ high bit depth-compatible build of f3kdb and yet still using the input_mode and output_mode parameters, which were removed (technically also the DoubleWidth conversions, but that's mostly because they're irrelevant now, not because they'd actually cause an error).

This is exactly the reason why I expressed my reluctance in removing 16bit stacked and interleaved in f3kdb here https://forum.doom9.org/showthread.php?t=176553&page=2

And this is just a script that calls f3kdb directly.
Think about how many other plugins/filters are there, who requires f3kdb as a dependency and who call it using those parameters!

[Groucho2004]

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+.

Why don't you just enumerate all plugin export functions and look for "avisynth_c_plugin_init"? That works for all C-plugins (32 & 64 bit). That way you can also identify all C++ plugs and determine if a plugin is 32 or 64 bit. If you're interested I can put together (and comment :o) the code bits from AVSMeter that you need.

[pinterf]

Isn't it slow?

[Groucho2004]

Isn't it slow?No. I think the current method is slow, just count the number of times you run "GetProcAddress(plugin.Library, "....") on each plugin.
Almost all plugins just have one export so the enumeration is going to be fast. Also, within the same call to "MapAndLoad()" you get the bitness info.
Have a look, the relevant function in AVSMeter is "CAvisynthInfo::GetPluginType" in "AvisynthInfo.h". As I mentioned, I can strip the stuff you don't need and put some comments.

[pinterf]

Sounds interesting. I don't want (= there are other things in my queue) to touch that section right now, but yes, your idea can work.

[real.finder]

In smaskmerge:
mt_lutxyz(src,overlay,mask,\
"x range_max z - * y z * + range_max /",\
uexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
vexpr="x range_max range_min - z - * y z * + range_max range_min - /",\
y=y,u=u,v=v)


I did some test with https://pastebin.com/ade3wBBV (has pmaskmerge and fixed smaskmerge by shifting)


blankclip(length=48,width=720,height=480, color=$00000,pixel_type="YV12")
expr("sx frameno + 32 % 16 < range_half range_max ?","sx frameno 2 / + 16 % 8 < range_half sx 15 / - range_half ?","sx frameno 2 / + 16 % 8 < range_half sx 8 / - range_half ?")
o=last
setbits=32
ConvertBits(setbits) # 32bit float vs 8-16bit integer

video=last
video2=video.trim(20,0)

x1=string(20)
x2=string(600)
y1=string(50)
y2=string(340)
msk=o.expr("sx "+x1+" >= sx "+x2+" <= & sy "+y1+" >= sy "+y2+" <= & & range_max range_min ?", "range_half", "range_half").trim(0,-1).FreezeFrame(0, FrameCount(last)-1, 0)
msk=msk.ConvertBits(setbits) # 32bit float vs 8-16bit integer
##########################

pmaskmerge(video, video2, msk,3,3,3, true).StackVertical(smaskmerge(video, video2, msk,3,3,3, true).Subtitle("smaskmerge"))

ConvertBits(8)

pmaskmerge don't do it, and even if the fixed smaskmerge has many workarounds it's not much slower than pmaskmerge (I think it's because pmaskmerge has additional multiplication in expr)

[Groucho2004]

Sounds interesting. I don't want (= there are other things in my queue) to touch that section right now, but yes, your idea can work.For your reference, below is the latest "GetPluginType()". Every plugin I have thrown at it is correctly detected.

BOOL GetPluginType(std::string sPlugin)
{
BOOL PROCESS_64 = (sizeof(void*) == 8) ? TRUE : FALSE;
BOOL bIs64BitDLL = FALSE;

//The MapAndLoad function maps an image and preloads data from the mapped file.
LOADED_IMAGE li;
BOOL bLoaded = MapAndLoad((LPSTR)sPlugin.c_str(), NULL, &li, TRUE, TRUE);

if (!bLoaded)
{
//error handling, check GetLastError() why the DLL could not be loaded
return FALSE;
}

if (li.FileHeader->FileHeader.Machine != IMAGE_FILE_MACHINE_I386) //check the PE header for bitness
{
bIs64BitDLL = TRUE; //it's a 64 bit DLL
if (!PROCESS_64) //if running a 32 bit process, throw error and return
{
//"Trying to load 64 bit DLL in 32 bit Avisynth"
UnMapAndLoad(&li);
return FALSE;
}
}
else //it's a 32 bit DLL
{
if (PROCESS_64) //if running a 64 bit process, throw error and return
{
//"Trying to load 32 bit DLL in 64 bit Avisynth"
UnMapAndLoad(&li);
return FALSE;
}
}

DWORD expVA = li.FileHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress;
if (expVA == 0)
{
//error handling -> "Cannot retrieve PE header data"
UnMapAndLoad(&li);
return FALSE;
}

PIMAGE_EXPORT_DIRECTORY pExp = (PIMAGE_EXPORT_DIRECTORY)ImageRvaToVa(li.FileHeader, li.MappedAddress, expVA, NULL);
if (pExp == 0)
{
//error handling -> "Cannot retrieve PE header data", check GetLastError()
UnMapAndLoad(&li);
return FALSE;
}

DWORD rvaNames = pExp->AddressOfNames;
DWORD *prvaNames = (DWORD*)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaNames, NULL);
if (prvaNames == 0)
{
//error handling -> "Cannot retrieve PE header data", check GetLastError()
UnMapAndLoad(&li);
return FALSE;
}


//enumerate DLL exports
DWORD dwName = 0;
std::string sPluginType = "";
for (dwName = 0; dwName < pExp->NumberOfNames; ++dwName)
{
DWORD rvaName = prvaNames[dwName];
std::string sExportFunc((char *)ImageRvaToVa(li.FileHeader, li.MappedAddress, rvaName, NULL));
std::transform(sExportFunc.begin(), sExportFunc.end(), sExportFunc.begin(), ::tolower); //convert to lower case for comparison

if (sExportFunc.find("avisynthplugininit3") != string::npos) //CPP 2.6, 32 or 64 bit
{
sPluginType = "AVSCPP26";
break;
}

if (sExportFunc.find("avisynthplugininit2") != string::npos) //CPP 2.5, 32 or 64 bit
{
sPluginType = "AVSCPP25";
break;
}

if ((sExportFunc.find("avisynthplugininit") != string::npos) && !bIs64BitDLL) //CPP 2.0 (these are 32 bit only)
sPluginType = "AVSCPP20"; //don't break here, keep looping

if ((sExportFunc.find("avisynth_c_plugin_init@4") != string::npos) && !bIs64BitDLL) //32 bit C 2.5
{
sPluginType = "AVSC25";
break;
}

if ((sExportFunc.find("avisynth_c_plugin_init") != string::npos) && bIs64BitDLL) //64 bit C 2.5
{
sPluginType = "AVSC25";
break;
}

if ((sExportFunc == "avisynth_c_plugin_init") && !bIs64BitDLL) //C 2.0 (these are 32 bit only)
sPluginType = "AVSC20"; //don't break here, keep looping
}

UnMapAndLoad(&li);

return TRUE;
}

[wonkey_monkey]

converttorgb32 from a 32-bit (float) YUV source results in black, if one of the following matrices is used:

pc.601
pc.709
average

The other matrices and other bit-depths seem to be okay.

[LouieChuckyMerry]

Natty, qyot27, and FranceBB: Thank you for leading me to a solution; updating my F3KDB.dll fixed the problem :) .

[pinterf]

converttorgb32 from a 32-bit (float) YUV source results in black, if one of the following matrices is used:

pc.601
pc.709
average

The other matrices and other bit-depths seem to be okay.
Thank you for the report.
New test build Avisynth+ r2900
https://drive.google.com/open?id=14DJyF9NFPtwU9almef3LX9jCssDt3VeF
Changes since last test build:
- Fix: ConvertToRGB from 32bit float YUV w/ full scale matrixes (pc.601, pc.709, average)
- Fix: FlipHorizontal RGB48/64 artifacts
- Enhanced: a bit quicker FlipHorizontal
- Fix: RGB64 Blur leftmost column artifact

[StainlessS]

Ooooo lovely, thanx P.

[LouieChuckyMerry]

Back for more. After receiving enough help here to upgrade from 32 bit AviSynth+ to 64 bit--thanks again for all the help :) --for my usual Blu-ray sources, I'm now trying to learn how to use 64 bit AviSynth+ for my DVD sources. I've found all the required 64 bit .dll's for my upscale scripts except ColorMatrix (to convert from Rec.601 to Rec.709). After much searching and reading, it seems that I can simply replace the 32 bit line:

ColorMatrix(Mode="Rec.601->Rec.709")

with:

ConvertTo(Proper Symbols Here)

in 64 bit AviSynth+, but I can't figure out just what the proper symbols are. In case it matters, my script is something like:

DGSource Here
### Deinterlace ###
TFM(Mode=7,UBSCO=False)
### Color Conversion ###
ColorMatrix(Mode="Rec.601->Rec.709")
### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=16))
### Crop ###
Crop(8,1,-8,0)
### Gibbs Noise Block ###
Edge=MT_Edge("prewitt",ThY1=20,ThY2=40).RemoveGrain(17)
Mask=MT_Logic(Edge.MT_Expand().MT_Expand().MT_Expand().MT_Expand(),Edge.MT_Inflate().MT_Inpand(),"xor").Blur(1.0)
MT_Merge(Minblur(),Mask,Luma=True)
### Overall Temporal Denoise ###
SMDegrain(TR=3,ThSAD=200,ContraSharp=True,RefineMotion=True,Plane=0,PreFilter=2,Chroma=False,n16=True,n16_Out=True)
### Resize ###
EDI_RPow2(CShift="Spline64",FWidth=960,FHeight=720)
aWarpSharp4xx(Depth=5)
### Darken-Thin Lines ###
FastLineDarkenMod4(Strength=24,Prot=6)
aWarpSharp4xx(Blur=4,Type=1,Depth=8,Chroma=2)
### Deband ###
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)

As always, thanks for any help.

Edit: Happy Saturday! After banging my (obviously thick) head against the wall for a while longer I realized that MeGUI has a copy of ColorMatrix.dll in its AviSynth_Plugins folder, so I borrowed a copy from the 64 bit version and all is well. I'd still be curious if "ConvertTo(Something)" would do the same job...

[real.finder]

bug in expr? in float(32)

mt_lut( "x range_half - 0.1 * range_half +", scale_inputs="floatf", U=3,V=3 )

not same as

expr( "x range_half - 0.1 * range_half +" ,scale_inputs="floatf")

without scale_inputs="floatf" they are same

[pinterf]

bug in expr? in float(32)

mt_lut( "x range_half - 0.1 * range_half +", scale_inputs="floatf", U=3,V=3 )

not same as

expr( "x range_half - 0.1 * range_half +" ,scale_inputs="floatf")

without scale_inputs="floatf" they are same

Do you know which one is correct?

[real.finder]

Do you know which one is correct?

the mt_lut one is correct

[pinterf]

the mt_lut one is correct
O.k. thanks, I check them both and found no problem for a quick five-minute investigation, so I need more time.

[pinterf]

the mt_lut one is correct
This issue was fixed, it's on git already, I'll make a build next week.

[real.finder]

This issue was fixed, it's on git already, I'll make a build next week.

thank you

[djonline]

Trim not work after Import, only after DirectShowSource.

DirectShowSource("avisynth-stage1-with-MTS.avs") still not work with LAV splitter 0.71

Then write the Trim in a separate line, not after a dot.

If the imported script returns a clip, then it should be passed to the usual internal variable "last", which is then implicitly assumed where no explicit clip variable was written.

If it does not return any clip, then it can't be used as video source anyway.
Still not work with Deshaker, video is shaked when using Import

"00425.MTS-pass2.avs"
vid="00425.MTS"
o=DirectShowSource(vid)
o+o.Trim(0,29)
ConvertToRGB32
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub64\plugins64\Deshaker_64.vdf", "deshaker",0) deshaker ("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|6|2|8|30|300|3|f:\\00425.MTS.1.1000.1000.2000.2000.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|1|20|30000|100|20|1")

00425.MTS-loader.avs
#DirectShowSource("00425.MTS-pass2.avs").Trim(30,0)
Import("00425.MTS-pass2.avs")
Trim(30,0) #video is shaked with this

[StainlessS]

# "00425.MTS-pass2.avs"
vid="00425.MTS"
o=DirectShowSource(vid)
# o+o.Trim(0,29) # Join o.trim(0,29) to END OF o
o.Trim(0,29) # presume this is required
#o.Trim(29,0) # EDIT: Or, is it this
ConvertToRGB32
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub64\plugins64\Deshaker_64.vdf", "deshaker",0)
deshaker ("19|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|6|2|8|30|300|3|f:\\00425.MTS.1.1000.1000.2000.2000.log"
\ + "|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|1|20|30000|100|20|1")

[Stereodude]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.

[real.finder]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.

avisynth+ version of DitherTools? no, it's still avs25/avs26

some DitherTools functions for avs+? yes, like the one I post here (https://forum.doom9.org/showthread.php?p=1880226#post1880226) maybe there are others by another persons

[qyot27]

Is there an avisynth+ version of DitherTools by any chance (I searched but came up empty)? If not, is there a way to get dithertool's rgb48y output into RGBP16 which AVIsynth+ handles? I think rgb48y and RGBP16 are basically the same thing just stored differently.
From the Dither tools wiki page:
"rgb48y" 48-bit RGB. The components R, G and B are conveyed on three YV12 or Y8 (if supported) stack16 clips interleaved on a frame basis.
I don't truly know how to interpret that description. Because from what it sounds like, you'd have to treat a Y8 frame (assuming it would default to Y8 on 2.6 and Plus) as an individual RGB plane, but you *also* have to apply ConvertFromStacked() and Select every third frame into individual variables to try then stitching them back together into a real RGBP16 stream with CombinePlanes (http://avisynth.nl/index.php/CombinePlanes). That's just my best guess, assuming the 'interleaved on a frame basis' means something like 6 frames being R1-B1-G1-R2-B2-G2, and not 'interleaved' in the sense that Stack16 format's counterpart Interleaved16 was for doing high bit depth.

IMO, I think it'd be easier to see if other Plus-compatible plugins (or its native HBD and dither functionality) can do what you want without bringing DitherTools into it at all.

[stax76]

I would like to request scaling for Info() because with 4K it's barely readable.

A player such as mpv shows always the same OSD font size regardless of the video resolution.

[qyot27]

I would like to request scaling for Info() because with 4K it's barely readable.

A player such as mpv shows always the same OSD font size regardless of the video resolution.
Just set the font size to 72. Or higher. Whatever you want; it's been customizable for three years now (https://github.com/AviSynth/AviSynthPlus/issues/99) (AviSynth Wiki (http://avisynth.nl/index.php/Info)).

http://i.imgur.com/i9nIFfCh.jpg (https://imgur.com/i9nIFfC)

[wonkey_monkey]

May I recommend Info2 (https://forum.doom9.org/showthread.php?t=176563), which is much easier to read and much much faster (it's missing a couple of not-that-useful things from Info).

https://i.imgur.com/c4rDblj.png

[VoodooFX]

What AVS+ vs AVS 2.6 does differently at initial script load? I noticed that one of my script loads ~hundred times slower in AVS+.
Most slowness I localized to this pseudo code below, AVS loads it in milliseconds or a second when AVS+ takes ~few minutes. (I don't want to publish script atm).

Trim1 = clip.Trim(22,-30)+clip.Trim(22222,-30)
a = Trim1.Loop(200)

a.PseudoParse()
Trim(0,-1)
setA = PseudoSetting(last)
aClip = clip.PseudoJob(setA)

Trim2 = aClip.Trim(22,-30)+aClip.Trim(22222,-30)
b = Trim2.Loop(200)

b.PseudoParse()
Trim(0,-1)
setB = PseudoSetting(last)
bClip = aClip.PseudoJob(setB)

Trim3 = bClip.Trim(22,-30)+bClip.Trim(22222,-30)
c = Trim3.Loop(200)

c.PseudoParse()
Trim(0,-1)
setC = PseudoSetting(last)
cClip = bClip.PseudoJob(setC)

return cClip

[wonkey_monkey]

Hard to say if we don't know what all the Pseudo functions do. Is there still a speed difference if you take those blocks out (replacing them aClip = a, etc), leaving just all the splices?

[VoodooFX]

It goes slower in some geometric progression with every xClip block, AVS 2.6 loads it in a second, when AVS+ runs script faster than AVS (I think). If it helps: PseudoParse() is AnalyzeLogo(), PseudoSetting() is ImageWriter(), PseudoJob() is DeblendLogo() from AVSInpaint.

Actual script will be more confusing without manual(yet), and I want to solve few other issues before publishing it.

PS:
Replacing to: aClip = Clip, bClip = Clip - just makes script 3 times faster to load. Remove all those "inception" blocks and AVS+ still is significantly slower at loading.

[LigH]

May I recommend Info2 (https://forum.doom9.org/showthread.php?p=1878265)

Pretty pretty!
:goodpost:

[magiblot]

What is the range of expected pixel values for floating-point formats? [0..1], [0..255/256], or the former for RGB and the latter for YUV?

[FranceBB]

What is the range of expected pixel values for floating-point formats? [0..1], [0..255/256], or the former for RGB and the latter for YUV?

8bit:
Full Range 0-255 / Limited TV Range: 16-235

10bit:
Full Range 0-1023 / Limited TV Range: 64-940

12bit:
Full Range 0-4080 / Limited TV Range: 256-3760

14bit:
Full Range 0-16320 / Limited TV Range: 1024-15040

16bit:
Full Range 0-65280 / Limited TV Range: 4096-60160

32bit float:
Full Range 0.0-0.99609375 / Limited TV Range: 0.0625-0.91796875


This simulates clipping a 32bit signal:


ColorBars(848, 480, pixel_type="YV12")

ConvertBits(32, truerange=true)

Limiter(min_luma=0.0625, max_luma=0.91796875)


https://i.imgur.com/nA9fNXE.png


Wrongly clipping 8bit values from a 32bit float clip:


ColorBars(848, 480, pixel_type="YV12")

ConvertBits(32, truerange=true)

Limiter(min_luma=16, max_luma=235)


https://i.imgur.com/hoftSfc.png


I personally work with 16bit precision which I think it's enough when my output is gonna be dithered down to 8bit for SD, HD and FULL HD footages, 10bit for UHD broadcast footages and 12bit for UHD Masterfiles.
So far I haven't used 32bit precision in a real world scenario, but still, it's kinda cool to have such an high bit depth. :)

[jpsdr]

12bit:
Full Range 0-4080
14bit:
Full Range 0-16320
16bit:
Full Range 0-65280
32bit float:
Full Range 0.0-0.99609375

What...:confused::eek:

Is this only YUV, or is it also RGB (mostly for 16bits for the last one). I didn't expect remaining gap between theorical max for full range.

[wonkey_monkey]

What...:confused::eek:

Is this only YUV, or is it also RGB (mostly for 16bits for the last one). I didn't expect remaining gap between theorical max for full range.

I assumt it's because it's done as bit-shifts. 255<<4 = 4080, 255<<6 = 16320, 255<<16 = 65280.

10-bit wasn't on the list but I assume it's 0-1020.

It's possibly a way to make all up-conversions consistent/transitive (and fast), but I wonder if down-conversions are more complicated. By a simple bit-shift, only one value in 16-bit would map to 255 in 8-bit (62580), whereas 256 values (0-255) would map to 0.

[magiblot]

32bit float:
Full Range 0.0-0.99609375 / Limited TV Range: 0.0625-0.91796875

This is what theory says, as explained in http://avisynth.nl/index.php/Autoscale_parameter, http://avisynth.nl/index.php/Convert and other places:

* The special-purpose matrices PC.601 and PC.709 keep the range unchanged, instead of converting between 0d-255d RGB and 16d-235d YUV, as is the normal practice.

Which implies that these ranges apply to RGB as well. And this makes sense to me as using multiples of 1/256 should help avoid rounding errors.

However, the question is: do filters actually expect pixel values to be in that range?

ConvertBits, for instance, seems not to:

Conversion from and to float is always full-scale.

Practical examples show different behaviours:

BlankClip(height=240).ConvertToPlanarRGB()
Expr(String(255.0/256.0), format="RGBPS") # 255d
StackVertical( Expr("x 256 *", format="RGBP8").ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("'D notation'-compliant conversion"),
\ ConvertToRGB32().RGBAdjust(analyze=true).Subtitle("Default conversion") )

https://i.imgur.com/JoL8Xs8.png

BlankClip(pixel_type="YV24")
Expr("0.0", format="YUV444PS")
ColorYUV(levels="PC->TV") # Bug in ColorYUV? Picture turns green
ColorYUV(analyze=true) # OK: luma is 0.6250 == 16/256

Expr("1.0", format="YUV444PS")
ColorYUV(levels="PC->TV")
ColorYUV(analyze=true) # Confusing: luma is 0.91796875 == 235/256, but input expected to be 1.0 rather than 255/256

Expr(String(235.0/256.0), format="YUV444PS")
ColorYUV(levels="TV->PC")
ColorYUV(analyze=true) # Same as before: 235/256 translates into 1.0 instead of 255/256

BlankClip(color_yuv=$108080, pixel_type="YV24") # Plain black in limited range
ConvertBits(32)
ColorYUV(analyze=true) # Inconsistent: 16d represented as 16/255 == 0.062745... (periodic number)

From ColorYUV's behaviour, one could assume that [16d..235d] is used for limited range and [0..1] for full range. But, by looking at ConvertBits, one would deduce that [16/255..235/255] and [0..1] are to be used instead. Documentation, conversely, speaks of [16d..235d] and [0d..255d].

In addition, RGBAdjust and Compare are unable to analyze floating-point pixel types, which makes it more difficult to see what's going on.

[jpsdr]

10-bit wasn't on the list but I assume it's 0-1020.

10-bit wasn't in my list, but was on original post with, for this one, expected value of 1023.

[StainlessS]

My natural inclination when using up shift would be to fill the 'nullified' least signifcant bits in destination number with the most significant bits from source number.

eg 8->10 bit,
7654321076 src bit indexes
9876543210 dst bit indexes

or eg 8->16
7654321076543210
fedcba9876543210 # hexified

But, that aint right, apparently.

EDIT: I think Knuth, TAOCP, Vol 1, Fundamental Algorithms, would suggest same for fast accurate upscale using shift only. [I left my copy on a train many years ago].

[poisondeathray]

Why is this horizontal line shifted ? (You can see it if you return a vs. b)

YV24 (and using ConvertToYUV444) works as expected, so is it some chroma resizing issue in 32bit? I tried different chromainplacement/chromaoutplacement settings as well

r2772 MT x64 ; or is it already fixed in one of the beta releases ?


a=colorbars(pixel_type="YV12").trim(0,-1)

a
ConvertBits(32)
ConvertToPlanarRGB(matrix="rec601", chromaresample="point")
ConvertToYUV420(matrix="rec601", chromaresample="point")
ConvertBits(8)
b=last

interleave(a,b)

[StainlessS]

Dont know but,

a=colorbars(pixel_type="YV12")

a
ConvertBits(32)
ConvertToPlanarRGB(matrix="rec601", chromaresample="point")
ConvertToYUV420(matrix="rec601", chromaresample="point")
ConvertBits(8)
b=last

#a
#b
b.subtract(a).stackHorizontal(a) # EDITED

https://i.postimg.cc/RZQNmMYx/a-02.jpg (https://postimages.org/)
ver$ r2900

EDIT: changed order from a.subtract(b) to b.subract(a) and reposted image.
So, eg where subtracted is yellow, then output is more yellow than input.
EDIT: Added in blue, b.subtract(a).stackHorizontal(a)

Dont know if as expected or not.

[poisondeathray]

Dont know if as expected or not.




It's supposed to be lossless ; it is with vapoursynth

32bit float "expected" range is 0-1 , but negative values , and values than 1 should are kept. They are in other programs too. That's one of the main reasons for using float. It's commonly used with raw processing, and high end effects/compositing

You can read off the values in vapoursynth editor for different bit depths , and for float (<0 , >1 ), but I cannot "read" values in avspmod besides 8bit, I don't know what avs+ is doing

I think this issue has something to do with chroma resampling, because if you do colorbars(pixel_type="YV24"), and ConvertToYUV444 after the RGB step, it works as expected (equivalent)

If you do 8bit or 16bit (instead of 32), you got not equivalent (as expected) .

Float is required for the lossless round trip, but if it was a problem with float processing in general then the YV24 should have errors too

[wonkey_monkey]

My natural inclination when using up shift would be to fill the 'nullified' least signifcant bits in destination number with the most significant bits from source number.

But, that aint right, apparently.


The problem with that - mathematically speaking, anyway - is that it would make 8 bit->16 bit different from 8-bit->12 bit->16 bit, for example.

10111111 -> 1011111110111111

10111111 -> 101111111011 -> 1011111110111011

[StainlessS]

Taken to extreme,
1 bit to 16 bit

1
1111111111111111 # same as before but with the repeated downshift of most signiicant bits (recurring stuff).

Shift only
1 # 1=max poss
1000000000000000 # half max poss

It is an imperfect universe that we live in, guess we just gotta put up with it. [thank goodness that its not forever]

[jpsdr]

@FranceBB
Is there any spec (REC-BT, ...) where these full range data are described/explained ? And especialy if they also report to RGB.
Because i'm almost sure (but maybe i'm wrong...), and mine included, the avs filters use for full range max value (2^nBits)-1 and not 255 << (nBits-8) (with exception of 10 bits).
Seems a new value for the range parameter of my filter may be needed.

[TheFluff]

http://www.vapoursynth.com/doc/functions/resize.html

See "pixel range" at the bottom

[jpsdr]

It says that full range is (2^nBits)-1 and not 255 << (nBits-8), so, it's different from what FranceBB says.
But it's what T-REC-H.265-201802-S!!PDF-E says in page 409.

[hello_hello]

I noticed an oddity in the way negative zero variables are converted to string when they're float. The variables in the script are never negative, but I want them to display that way, unless they're zero. The upshot is....

This displays as 0
subtitle(string(float(-0), "%.0f"))

While this displays as -0
subtitle(string(-float(0), "%.0f"))

As does this
xxx = float(0)
subtitle(string(-xxx, "%.0f"))

And this
xxx = -float(0)
subtitle(string(xxx, "%.0f"))

But not for a double negative.
xxx = -float(0)
subtitle(string(-xxx, "%.0f"))

Avisynth 2.6 doesn't display the negative sign for any of them.

Cheers.

[VoodooFX]

Continuation from this post (https://forum.doom9.org/showthread.php?p=1882432#post1882432).

This script is 71 times faster in AVS v2.6 vs AVS+ :
clip = LWLibavVideoSource("C:\LagarithYV12.avi.lwi")
clp = clip.ConvertToRGB24
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
a = a+a+a+a+a+a+a+a+a+a
a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a
return a

https://i.imgur.com/bDnMHrA.png

[StainlessS]

See here:- https://forum.doom9.org/showthread.php?p=1883127#post1883127

[ajp_anton]

This might be a very odd and niche feature request, but here goes...

In ConditionalReader, the OFFSET command offsets all lines below it a fixed number of frames, but it can be overwritten by another OFFSET command. My request is to add a new command, something like ADDOFFSET (or if you can think of a better name), where it doesn't overwrite previous offsets, but adds its offset to the previous one.

For example:
# This is for frame 0, obviously
0 value0
OFFSET 2
# This is for frame 3: 1 + offset 2
1 value1
# This adds 4 to the previous offset of 2
ADDOFFSET 4
# So this is now for frame 8: 2 + offsets 2+4
2 value2
# And this will overwrite the previous offset(s), as before
OFFSET 10
# So this is for frame 13: 3 + offset 10
3 value3


edit: Or maybe you could call it by
OFFSET+=4
# and of course also
OFFSET-=4
# while maybe even adding the possibility to write
OFFSET=2

edit2:
And for the motivation of this... say you have a long list of values for sequential frames, but then you need to add gaps here and there. With the current implementation of OFFSET, you can't change one gap without having to also change every OFFSET after it, and you can't directly read what the gap is without having to subtract the previous OFFSET.

[TheFluff]

Continuation from this post (https://forum.doom9.org/showthread.php?p=1882432#post1882432).

This script is 71 times faster in AVS v2.6 vs AVS+ :


https://i.imgur.com/bDnMHrA.png

is there any difference if you replace all the splices with loop()?

[StainlessS]

is there any difference if you replace all the splices with loop()?
still a significant difference with blankclip.

BlankClip(length=1000000000)
return Last

https://i.postimg.cc/c1RZsH7r/Untitled-00.jpg (https://postimages.org/)


EDIT: and with mostly loop()s

#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4")
clip=BlankClip(length=3000)
clp = clip.ConvertToRGB24
a = clp.Trim(20,-30) + clp.Trim(2000,-30)

#a = a+a+a+a+a+a+a+a+a+a # *10
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000

a=a.loop(1600000,0,59)

return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000

avs+ capped at about same time as v2.6 std had completed, and with still lots of time yet to expend.
https://i.postimg.cc/C16XsTHW/Untitled-01.jpg (https://postimages.org/)


EDIT: Avs+ a bit faster if no ConvertToRGB24 [EDIT: Avs 2.6 std takes about 2:45.00 for same script, unlike previous, quite a bit longer than avs+]

#clip=LSMashvideoSource("1941 Flint Michigan Parade [Low, 360p].mp4")
clip=BlankClip(length=3000).Killaudio
#clp = clip.ConvertToRGB24
clp=clip
a = clp.Trim(20,-30) + clp.Trim(2000,-30)

#a = a+a+a+a+a+a+a+a+a+a # *10
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20
#a = a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a+a # *20, = * 1600000 ::: 1600000 * 60 = 96,000,000

a=a.loop(1600000,0,59)

return a #.info # 96,000,000 frames ### Max possible frames = $7FFFFFFF, ~= 2,000,000,000

https://i.postimg.cc/NFXWbC0b/Untitled-00.jpg (https://postimages.org/)

[LigH]

See here:- https://forum.doom9.org/showthread.php?t=174797&page=10

Links with page numbers are a bit unreliable. People could have customized their "posts per page". Best use the "Link".

https://www.ligh.de/tmp/Link.png

[StainlessS]

Thanks, not intentional, fixed.

[Groucho2004]

This script is 71 times faster in AVS v2.6 vs AVS+ :
https://i.imgur.com/bDnMHrA.png
Classic Avisynth caches these 60 frames:
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
and re-uses that block of memory for all loop and/or splice operations. Setting setmemorymax() to 128 or 64 shows what's happening.

AVS+ seems to read from the source every time in this scenario.

[pinterf]

For historical reasons (https://github.com/pinterf/AvisynthPlus/commit/50a1e569) Trim - along with other filters - is declared internally as a NonCachedGenericVideoFilter.
Changing that back to GenericVideoFilter yields significant speed increase.

Such filters are: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop

[VoodooFX]

For historical reasons (https://github.com/pinterf/AvisynthPlus/commit/50a1e569) Trim - along with other filters - is declared internally as a NonCachedGenericVideoFilter.
Changing that back to GenericVideoFilter yields significant speed increase.

Such filters are: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop

If it is only historical reason can you change them back to cached GenericVideoFilter?

[filler56789]

If it is only historical reason can you change them back to cached GenericVideoFilter?

I second that. "History" should be no excuse for bugs /design_flaws /bad_performance.

[Groucho2004]

I'm sure pylorak had a good reason for that commit, if I recall correctly it was related to MT functionality.

[Myrsloik]

I second that. "History" should be no excuse for bugs /design_flaws /bad_performance.

The reason for not adding caches is simple: avoid insane amounts of useless cache instances from being created. This is a very reasonable tradeoff since the max depth of sane uncached operations is about 10 or so. Not many millions. In typical cases the reduced cache overhead will provide a speedup. That's right! It goes faster for everybody except you!

What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort (https://en.wikipedia.org/wiki/Bubble_sort) and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.

[real.finder]

maybe as compromise and neutral Solution, trim can has cache parameter (false by default) if FrameCache() or RequestLinear() can't fix the slowdown

[VoodooFX]

I understand that such code doesn't make sense, until you know that it is the only way to get desirable result from external plugin.

[qyot27]

I'm sure pylorak had a good reason for that commit, if I recall correctly it was related to MT functionality.
Early 2014 was when the MT functionality was being implemented and the caching behavior was refactored in tandem with it. That's almost certainly the reason, even if just tangentially.

I mean, the other thing to point out is that the tests are being run single-threaded, and some of that syntax is wonky (probably minuscule in any possible performance detriment, but whatever). Actually using MT shows how artificial this test is in the first place, because it scales with # of cores in virtually 1:1 fashion.

Script (with the cruft trimmed out and clarified (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Identifiers)):
clp = FFVideoSource("test.avi").ConvertToRGB24()
a = clp.Trim(20,-30)+clp.Trim(2000,-30)
a1 = a+a+a+a+a+a+a+a+a+a
a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1
Prefetch(4)

Without Prefetch:
>avsmeter test.avs

AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 381.3 | 2361 | 1977
Process memory usage (max): 44 MiB
Thread count: 16
CPU usage (average): 35.7%

Time (elapsed): 00:00:06.070

With Prefetch(4):
>avsmeter test.avs

AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 2164 | 12104 | 10044
Process memory usage (max): 51 MiB
Thread count: 20
CPU usage (average): 57.5%

Time (elapsed): 00:00:01.195

64-bit results, for good measure:
Without Prefetch:
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 948.1 | 2770 | 2303
Process memory usage (max): 25 MiB
Thread count: 16
CPU usage (average): 39.1%

Time (elapsed): 00:00:05.211

With Prefetch(4):
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 1767 | 13659 | 11223
Process memory usage (max): 32 MiB
Thread count: 20
CPU usage (average): 55.7%

Time (elapsed): 00:00:01.069

With Prefetch(5):
>avsmeter64 test.avs

AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004
AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0)

Number of frames: 12000
Length (hh:mm:ss.ms): 00:08:20.500
Frame width: 196
Frame height: 88
Framerate: 23.976 (24000/1001)
Colorspace: RGB24

Frames processed: 12000 (0 - 11999)
FPS (min | max | average): 1692 | 139899 | 23581
Process memory usage (max): 33 MiB
Thread count: 21
CPU usage (average): 34.1%

Time (elapsed): 00:00:00.509

If I up the Prefetch value on the 32-bit test to 5 (one higher than the number of cores in this J3455), avsmeter then reports that it's too short to measure. 64-bit hits the same barrier at Prefetch(6). Of course, that's for 12000 frames at a frame size of 196x88; who knows how much more you can abuse the frame threading beyond n cores with frames at a normal size and runtime length.

[filler56789]

The reason for not adding caches is simple: avoid insane amounts of useless cache instances from being created. This is a very reasonable tradeoff since the max depth of sane uncached operations is about 10 or so. Not many millions. In typical cases the reduced cache overhead will provide a speedup. That's right! It goes faster for everybody except you!

What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort (https://en.wikipedia.org/wiki/Bubble_sort) and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.

1) Thanks for the useful information. Then I stand corrected, sir.

2) And then I don't know why pinterf wrote ""historical" reasons" instead of giving a straight-to-the-point answer like yours. Perhaps that was a misplaced joke or/and his "sense of humor" is broken......

P.S.:

3) I am not VoodooFX alright ;)

[wonkey_monkey]

What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort (https://en.wikipedia.org/wiki/Bubble_sort) and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.

So - and I'm probably being dim here, or missing some MT thing because I've never really dug into that - how do you implement a loop of a small clip section, in Avisynth+, so you can get the same performance as seen in 2.6?

[VoodooFX]

Actually using MT shows how artificial this test is in the first place, because it scales with # of cores in virtually 1:1 fashion.

Loading time of the real script (link to - pseudo script (https://forum.doom9.org/showthread.php?p=1882432#post1882432), the part where the real script is parsing loops when loading):
2s - AVS Standard 2.6
61s - AVS+
304s - AVS+ with Prefetch(4)

Trims, loops replaced with SelectRangeEvery (~3600 frames from clip):
41s - AVS Standard 2.6
46s - AVS+
247s - AVS+ with Prefetch(4)

[pinterf]

Early 2014 was when the MT functionality was being implemented and the caching behavior was refactored in tandem with it. That's almost certainly the reason, even if just tangentially.

Setting the non-caching behaviour for zero-op filters in general seemed to be a good idea at that time in 2014, but as this use case shows the idea does not work for Trim and the probably for the other functions mentioned above. In the past few years I have already put back some deleted invoking of InternalCache to Avisynth+ since some real world (and not synthetic) scripts were slow in specific scenarios. Non-caching Trim probably has no penalty only when it appears alone and right after a source filter (? this has to be tested).

[Zetti]

Is there a ETA for a new stable build?

[ajp_anton]

Bug?

I don't know if this is supposed to be "expected behavior", but at least I didn't expect anything like this.

When a resizer is fed cropping coordinates from outside of the picure, what exactly is supposed to happen? I expected it to simply repeat the last line of the image, but that doesn't seem to be the case.

function blackborder(clip c,int pix)
{
return c.crop(0,pix,0,-pix).addborders(0,pix,0,pix)
}

blankclip(width=100, height=100, length=20, pixel_type="y8", color=$ffffff)

animate(0,19,"blackborder", 0, 19)

lanczos4resize(width,height, 0, -height/2, width, height*2)
histogram
This creates a white image, but with a black border the same size as the framenumber. It then "zooms out", but keeps the overall dimensions the same, by taking a larger area around the frame and resizing it to the original size.

On frame 0, the expected behavior happens, where it just repeats the white border indefinitely and the zoomed-out image is also 100% white. On frame 1 and onwards, I was expecting it to treat the outside world as being black, however that's not what happens.

Depending on how thick the black border is and what resizer is used, the outside color oscillates around gray/black, mimicking the wave-like nature and the sampling area of the resizer. For complete blackness, a 6 pixel border is needed for spline36, 2 for bilinear, etc.

[ajp_anton]

ConvertBits(8,dither=1)
doesn't seem to work for 8-bit sources.

Wiki says:
"Dithering is allowed only for 10-16bit (not 32bit float) sources."
You can dither from 16bits to 16bits so why not from 8bits to 8bits? I'm assuming those will just pass through the video untouched anyway. Life gets easier when I can just slap on a convert to 8bits at the end without worrying about what the input bitdepth is.

[LigH]

Dithering is a technique to spread quality loss while reducing the precision. Converting from 8 bits per color component to 8 bits, there is no reduction, thus no loss to be spread.

[ajp_anton]

Dithering is a technique to spread quality loss while reducing the precision. Converting from 8 bits per color component to 8 bits, there is no reduction, thus no loss to be spread.Yes, I know. So why is 16bits to 16bits allowed?
edit: I'm not saying 16b->16b actually does anything. I'm just confused over the fact that it's allowed, while 8b->8b isn't. I'm advocating for allowing also 8b->8b for when you can just add it to the end of a script or a function, without adding a check to see if it's allowed... (I feel like I'm repeating myself here, everything is already in the original post).

[ajp_anton]

Another bug?

ConditionalReader:

TYPE string
DEFAULT this_is_the_default

1 test
2 string
5
8 testing
This throws an error that it doesn't understand line 6 (the one with frame 5). Note that there's just one space after 5. The space is there to separate the frame number from the value. In this case I want the value to be an empty string.
Note that setting the default string to empty *does* in fact work (with just the one space after "DEFAULT"), but the exact same thing *does not* work for the individual frames.

edit:
This example script goes with the above "test.txt" text file, for testing purposes:
ColorBars
Trim(0,500)
ScriptClip("Subtitle(String(myvar))")
ConditionalReader("test.txt", "myvar", false)

[pinterf]

ConvertBits(8,dither=1)
doesn't seem to work for 8-bit sources.
You can dither from 16bits to 16bits so why not from 8bits to 8bits?
Because I didn't have additional weeks to implement it like it works for 10-16 bit sources (where you can specify dither_bits)

[pinterf]

Another bug?

ConditionalReader:

TYPE string
DEFAULT this_is_the_default

1 test
2 string
5
8 testing
This throws an error that it doesn't understand line 6 (the one with frame 5). Note that there's just one space after 5. The space is there to separate the frame number from the value. In this case I want the value to be an empty string.
Note that setting the default string to empty *does* in fact work (with just the one space after "DEFAULT"), but the exact same thing *does not* work for the individual frames.

Good catch, fixed.

[pinterf]

Test build again, files only.
Avisynth+ r2915 (https://drive.google.com/open?id=1fD3icmCBr3x3tHjFzxsr5h8Rw6nO4uZV)
Changes since last r2900 test in July (for all changes since r2772 see readmes):
- Changed: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop are using frame cache again (similar to classic Avs 2.6)
- Enhanced: Expr: faster exp, log, pow for AVX2 (sekrit-twc)
- ConditionalReader: allow empty value in text file when TYPE string
- Fix: Expr: fix non-mod-8 issues for forced RGB output and YUV inputs
- New: AviSource support v308 and v408 format (packed 8 bit 444 and 4444)
- Fix: AviSource v410 source garbage (YUV444P10)
- Fix: Expr: when using parameter "scale_inputs" and the source bit depth conversion occured, predefined constants
(ymin/max, cmin/max, range_min/max/half) would not follow the new bit depth

[StainlessS]

OOOoooh lovely https://www.cosgan.de/images/smilie/froehlich/k020.gif

[VoodooFX]

Thank you. Now trims/loops are fast. :cool:

2s - AVS Standard 2.6
61s - AVS+ r2772
2s - AVS+ r2915

[manolito]

After confirming speed issues when using FFVideoSource or LWLibavVideoSource under AVS+ 32-bit in MT mode:
https://forum.doom9.org/showthread.php?p=1883664#post1883664
I just want to know if it is feasible to add some kind of workaround to AVS+ to ensure linear frame requests to these source filters.


Cheers
manolito

[poisondeathray]

More evidence of the ConvertToXX (chromaresample="point") bug with shifting chroma, as pointed out in post 4287

avsresize does not exhibit the bug (nor does vapoursynth)

https://forum.doom9.org/showthread.php?p=1884351#post1884351

[pinterf]

More evidence of the ConvertToXX (chromaresample="point") bug with shifting chroma, as pointed out in post 4287

avsresize does not exhibit the bug (nor does vapoursynth)

https://forum.doom9.org/showthread.php?p=1884351#post1884351
Is classic Avisynth 2.6 affected as well?

[pinterf]

After confirming speed issues when using FFVideoSource or LWLibavVideoSource under AVS+ 32-bit in MT mode:
https://forum.doom9.org/showthread.php?p=1883664#post1883664
I just want to know if it is feasible to add some kind of workaround to AVS+ to ensure linear frame requests to these source filters.

Unfortunately not.

[poisondeathray]

Is classic Avisynth 2.6 affected as well?

Yes

I forgot that Gavino explained this a long time ago

https://forum.doom9.org/showthread.php?p=1571315#post1571315

[wonkey_monkey]

I just made this image to compare chroma resampling in converttoXXX:

https://i.imgur.com/xxQu7KV.png

It shows the result of repeat conversions between YV12 and RGB24. Does it indicate a problem with "sinc"?

If nothing else, it shows a downward shift which none of the others (except "point", for reasons already discussed) exhibits.

[poisondeathray]

I just made this image to compare chroma resampling in converttoXXX:

https://i.imgur.com/xxQu7KV.png

It shows the result of repeat conversions between YV12 and RGB24. Does it indicate a problem with "sinc"?

If nothing else, it shows a downward shift which none of the others (except "point", for reasons already discussed) exhibits.

Yes the ConvertToXX "sinc" implementation has issues too . Looks to be more than just down direction. Also occurs with avs classic

avsresize shows expected result with sinc

https://i.postimg.cc/kg7MjBk4/sinc.png

[StainlessS]

Just curious, what is the purpose of

Null "c[copy]s" # Function Null(clip c,String "Copy")


Is it some temp debug thing for test version avs+ r2915


colorbars(pixel_type="YV12")
#NULL("YV24")
NULL()
info

Error reading source frame 0: Avisynth read error: bug found

EDIT: Also, I found a script from some time ago, (about june/july)

Colorbars
x=GetPlaneWidthSubSampling
return last

Dont know if it was implemented back then or whether or not I was just testing for the function existing, but it aint supported in r2915,
perhaps that is part reason I gave up s_ExLogo modding, is pretty fundamental function and easily added, can next issue of avs+ have it (GetPlaneWidthSubSampling) and
also GetPlaneHeigthSubSampling too please.
I can use RT_ColorSpaceXMod(clip) and RT_ColorSpaceYMod(clip,Laced) but not for avs+ colorspaces. https://forum.doom9.org/showthread.php?p=1864802#post1864802

EDIT: Below maybe handy for Wiki/Docs (where ColorSpaceXMod and ColorSpaceYMod cropping granularity of colorspace due to U and V)
where ColorSpaceYMod would be as BitLShift(1,Last.GetPlaneHeightSubSampling) OR Last.RT_ColorSpaceYMod() in Avs Std.

H=5 # Test height
CS="YV24"
ColorSpaceYMod = 1 # ColorSpaceYMod = 1 : Can crop vertically in multiples of 1 for YV24 : ColorSpaceYMod = BitLShift(1,Last.GetPlaneHeightSubSampling)
# ColorSpaceYMod = 1 : if eg Y8, GetPlaneHeightSubSampling() would produce error if no chroma.
Colorbars(Pixel_type=CS)
O=Last
crop(0,0,0,H*ColorSpaceYMod)

# MINIMUM CROPPED INPUT SIZE PER RESIZER
# Resizer Name # Minimum (cropped) input size that succeeds (eg ColorSpaceYMod=2 for YV12, 1 for YV24 : ColorSpaceXMod for horizontal same sort of thing for width)
#PointResize(O.Width,O.Height) # 1*ColorSpaceYMod
#BilinearResize(O.Width,O.Height) # 2*ColorSpaceYMod
#BiCubicResize(O.Width,O.Height) # 3*ColorSpaceYMod
#Spline16Resize(O.Width,O.Height) # 3*ColorSpaceYMod
#Spline36Resize(O.Width,O.Height) # 4*ColorSpaceYMod
#Spline64Resize(O.Width,O.Height) # 5*ColorSpaceYMod
#GaussResize(O.Width,O.Height,p=30.0) # 5*ColorSpaceYMod
#Lanczos4Resize(O.Width,O.Height) # 5*ColorSpaceYMod (taps=4)
#LanczosResize(O.Width,O.Height,taps=3) # (taps+1)*ColorSpaceYMod
#BlackmanResize(O.Width,O.Height,taps=4) # (taps+1)*ColorSpaceYMod
#SincResize(O.Width,O.Height,taps=4) # (taps+1)*ColorSpaceYMod

# Uncomment one of above

return Info

EDIT: Maybe ColorSpaceXMod/YMod would actually be more useful [than GetPlane-Height/Width-SubSampling], and avoid special cases [in script] where no chroma or RGB.

[pinterf]

Just curious, what is the purpose of

Null "c[copy]s" # Function Null(clip c,String "Copy")


Is it some temp debug thing for test version avs+ r2915


I was not aware of such function, it probably served debug purposes from the beginnings.

[pinterf]

Yes the ConvertToXX "sinc" implementation has issues too . Looks to be more than just down direction. Also occurs with avs classic

avsresize shows expected result with sinc

https://i.postimg.cc/kg7MjBk4/sinc.png

In Avsresize sinc is a (legacy) lanczos with taps=4.
While "sinc" in Avisynth+ has different core from Lanczos.

Which can be a bug or not.

Lanczos and Sinc are different in avisynth+ because
"sinc" does not have the extra calculation of sinc(value) * sinc(value/taps) like Lanczos has.

avs+ Lanczos:

double LanczosFilter::sinc(double value) {
if (value > 0.000001) {
value *= M_PI;
return sin(value) / value;
} else {
return 1.0;
}
}

double LanczosFilter::f(double value) {
value = fabs(value);

if (value < taps) {
return (sinc(value) * sinc(value / taps));
} else {
return 0.0;
}
}


avs+ sinc filter
/***********************
*** Sinc filter ***
***********************/
double SincFilter::f(double value) {
value = fabs(value);

if (value > 0.000001) {
value *= M_PI;
return sin(value)/value;
} else {
return 1.0;
}
}

[StainlessS]

I was not aware of such function, it probably served debug purposes from the beginnings.

Dang!, you are correct.
Also present in v2.58, seen the function lists for v2.58, v2.60,
v2.61, avs+ many times and never noticed it before.
EDIT: Ideal for April Fool jokes, make AVS+/Plugin coders think they have serious bug in avs+ or plugs. https://www.cosgan.de/images/smilie/froehlich/a065.gif

[LigH]

I believe a Null() transform filter is useful for the ternary conditional statement (if ? then : else) when one alternative is not supposed to change the clip. But there was also a NOP statement, IIRC?

[StainlessS]

Null() not useful to replace NOP.

Null(clip c, string "Copy"="none"), is not intended to be used from script.
from v2.60 std source, debug.h

class Null : public GenericVideoFilter
/**
* Class for debugging Avisynth internals.
**/


As it is in avs v2.60 std source, seems to always produce error
debug.cpp

/*******************************
******* Null Filter *******
******* for debugging *******
******************************/

Null::Null(PClip _child, const char * _copy, IScriptEnvironment* env)
: GenericVideoFilter(_child), copy(_copy)
{
}

Null::~Null()
{
}


PVideoFrame __stdcall Null::GetFrame(int n, IScriptEnvironment* env)
{
PVideoFrame src = child->GetFrame(n, env);

BYTE * foo = new BYTE[256];
BYTE * bar = new BYTE[256];
MemDebug md;

md.randomFill(foo, 8, 8, 8);
env->BitBlt(bar, 8, foo, 8, 8, 8);

md.reset();
int i = md.randomCheck(bar, 9, 8, 8); // ssS: Looks like always forces error (9 instead of 8)

if (i)
env->ThrowError("bug found"); // ssS: OUR SHOWN ERROR "Error reading source frame 0: Avisynth read error: bug found"

delete [] foo;
delete [] bar;

if (!lstrcmpi(copy, "makewritable"))
{
env->MakeWritable(&src);
return src;
}

// TODO: no support for planar formats!
if (!lstrcmpi(copy, "memcopy"))
{
PVideoFrame dst = env->NewVideoFrame(child->GetVideoInfo(), 16);
if (dst->IsWritable() == false)
env->ThrowError("new frame not writable"); // honestly don't know whether to expect this condition

memcpy( dst->GetWritePtr(), src->GetReadPtr(), src->GetPitch() * src->GetHeight() );
return dst;
}

if (!lstrcmpi(copy, "bitblt"))
{
PVideoFrame dst = env->NewVideoFrame(child->GetVideoInfo(), 16);
if (dst->IsWritable() == false)
env->ThrowError("new frame not writable"); // honestly don't know whether to expect this condition

env->BitBlt( dst->GetWritePtr(), src->GetPitch(), src->GetReadPtr(), src->GetPitch(),
src->GetRowSize(), src->GetHeight() );
return dst;
}

//if (!lstrcmpi(copy, "none"))
// do nothing
return src;
}

AVSValue __cdecl Null::Create(AVSValue args, void*, IScriptEnvironment* env)
{
return new Null(args[0].AsClip(), args[1].AsString("none"), env);
}


Cant say that I understand whats happening there, seems a bit weird.
EDIT: Dont know where this bit is coming from "Error reading source frame 0: Avisynth read error".

EDIT: Although this dont throw error (As no GetFrame called, only Null() constructor called)

# this just returns the info whatsit, no error thrown
colorbars(pixel_type="YV12")
O=Last

Last.Null(Copy="What the hell ! ") # always do the Null thingy

return O.Info


EDIT: Maybe that particular code is intended to be "hacked as required", and above is just how it was left after last use.

[wonkey_monkey]

I'm writing a C++ program which creates an IScriptEnvironment2 for the purposes of displaying clips. It also lets the user modify the filter chain by changing conversion matrix, interlacing settings, bobbing, etc. If I invoke a filter, is there any way to absolutely forbid the environment from ever caching frames from that filter? And would this/could this propagate to downstream filters, so that every single request for an output frame (even if it was the same frame that had just been requested) would go back up the chain to the uncached filter?

[Myrsloik]

I'm writing a C++ program which creates an IScriptEnvironment2 for the purposes of displaying clips. It also lets the user modify the filter chain by changing conversion matrix, interlacing settings, bobbing, etc. If I invoke a filter, is there any way to absolutely forbid the environment from ever caching frames from that filter? And would this/could this propagate to downstream filters, so that every single request for an output frame (even if it was the same frame that had just been requested) would go back up the chain to the uncached filter?

The short answer is no. Simply recreate the filter chain from the point where the settings are changed. Generally only source filters are slow to create and destroy anyway so it works just fine (that's how YMC's preview works in case anyone remembers that)

[wonkey_monkey]

I may have mentioned this before - I couldn't find anything in my history, but the forum search is not the greatest.

converttoyv12 throws an error on construction if the input clip isn't mod2, as it should - except when the input is Y8, in which case it fails to do so and leaves it to NewVideoFrame() to throw the error. May happen in other cases too.

[StainlessS]

@P, see here:- http://forum.doom9.org/showthread.php?p=1886177#post1886177

Note to Pinterf, ConditionalFilter Fails where uses Length=1 in BlankClip, dont think it should.
InC = Last.BlankClip(Length=1,Color_YUV= InColor) OutC= Last.BlankClip(Length=1,Color_YUV=OutColor)



ROW = True
LIMITLO = 74.0 # >= is Target
LIMITHI = 100.0 # <= is Target
INCOLOR = $008080 # Set where in target range
OUTCOLOR = $FF8080 # Not in target range
SHOW = false # Return StackHorizontal, original as Y8, and mask.
###############
Colorbars.Trim(0,-100).convertToY8
MskByRowAveY(Row=ROW,LimitLo=LIMITLO,LimitHi=LIMITHI,InColor=INCOLOR,OutColor=OUTCOLOR,Show=SHOW)
Return Last

Function MskByRowAveY(clip c, Bool "Row", Float "LimitLo", Float "LimitHi", Int "InColor", Int "OutColor", Bool "Show") { # http://forum.doom9.org/showthread.php?p=1886177#post1886177
# Where AveLuma of pixel Row/Coloumn is between LimitLo<===>LimitHi, then set to Incolor, else OutColor. Colors Specified as YUV, where only Y8 returned.
c myName="MskByRowAveY: "
Row=Default(Row,true) LimitLo=Default(LimitLo, 0.0) LimitHi=Default(LimitHi,127.5)
InColor =Default(InColor ,$000000) OutColor=Default(OutColor,$FF8080) Show=Default(Show,False)
Assert(0.0 <= LimitLo <= LimitHi,myName+String(LimitLo,"0.0 <= LimitLo(%f)") + String(LimitHi," <= LimitHi(%f)"))
Assert(LimitHi <= 255.0,myName+String(LimitHi,"LimitHi(%f) <= 255.0"))
ConvertToY8.KillAudio O=Last
(Row) ? SeparateRows(O.Height) : SeparateColumns(O.Width)
InC = Last.BlankClip(Color_YUV= InColor) OutC= Last.BlankClip(Color_YUV=OutColor)
Last.ConditionalFilter(InC,OutC,String(LimitLo,"(%f<=AverageLuma<=")+String(LimitHi,"%f)"))
(Row) ? WeaveRows(O.Height) : WeaveColumns(O.width)
Return (SHOW) ? StackHorizontal(O,Last) : Last
}


EDIT: Easier for testing (Without SeperateRows)

FAIL = False # Force Falure ?
C=0
For(i=0,255) {
C2=BlankClip(Pixel_Type="Y8",Length=1,Color_YUV=(i*256+$80)*256+$80)
C=(!c.IsClip) ? C2 : C ++ C2
}
C # 256 frames, Y ascending

Len = (FAIL) ? 1 : FrameCount

K=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$008080).Subtitle("[FAIL=" + String(FAIL) + "] Is NOT greater than 100.0",Align=5)
W=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$FF8080).Subtitle("[FAIL=" + String(FAIL) + "] Is greater than 100.0",Align=5)

ConditionalFilter(W,K,"averageLuma >= 100.0 ",Show=true)
C=C.Scriptclip("""Subtitle(String(current_frame,"%.0f] Y=") + String(AverageLuma,"%.2f"))""")
StackHorizontal(C,Last)

#Trim(255,-1) # Only show last frame where result should be WHITE.


With FAIL=False (on last frame 255 where input frame Y is 255.0)
https://i.postimg.cc/w7TgT2Bz/Fail-False.jpg (https://postimg.cc/w7TgT2Bz)

With FAIL=True (on last frame 255 where input frame Y is 255.0)
https://i.postimg.cc/vgzkJRfV/FailTrue.jpg (https://postimg.cc/vgzkJRfV)

EDIT: Only Fails when BOTH W and K clips are of single frame length, otherwise succeeds. [have not tried 0 length clips]
EDIT: Over the years I've had problems trying to use Conditional filters [maybe always this one and because of Length thing], and is the reason that I tend to use Scriptclip for nearly everything.

EDIT: And v2.60 Std does not have optional arg Show, whereas v2.61 does. [for Wiki Editor, not mentioned when Show was added]

For above Easier for testing (Without SeperateRows),
With v2.60 std, if you wrap for/next in GScript wrappers, and remove optional Show from conditionalFilter call, then it works as posted, but still has the Length error as in avs+.
Strangly, v2.61 std shows some kind of "Invalid arguments to conditionalFilter" type message where v2.60 standard works ok, Odd.

EDIT: Above in BLUE, I had Grunt in both v2.58 and v2.60Std plugins, but not in v2.61std, and as Grunt allows for differing args(string expression), v2.61 failed on single string expression without
the Operator and Expression2 strings.

Grunt docs

ConditionalFilter

ConditionalFilter(clip testclip, clip source1, clip source2, string expression1, string operator, string expression2
[, bool showx, string args, bool local])
GConditionalFilter(clip testclip, clip source1, clip source2, string expression1, string operator, string expression2
[, bool show, string args, bool local])

ConditionalFilter(clip testclip, clip source1, clip source2, string expression
[, bool showx, string args, bool local])
GConditionalFilter(clip testclip, clip source1, clip source2, string expression
[, bool show, string args, bool local])

cf. AviSynth internal function ConditionalFilter

[LouieChuckyMerry]

Hello. Some months ago with help here I was able to transition from AviSynth+ 32 bit with LSB high bit depth to AviSynth+ 64 bit with native high bit depth processing, almost doubling my encoding speed. Thanks again to all who helped :thanks: . Also with help I translated my old script for upscaling 480p to 720p in native high bit depth using EDI_PRow2. I'm now trying to figure out how to downscale 1080p to 720p in native high bit depth but am having trouble, as it seems EDI_PRow2 isn't designed for downscaling. Does anyone have a suggestion for a downscaling resizer that works in native high bit depth? I've searched about but can't find anything. Here's the script:

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
EDI_RPow2(CShift="Spline64",FWidth=1280,FHeight=720)
aWarpSharp4xx(Depth=5)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

If I run the above script it's actually 8x slower than my old script using the LSB hack (and tests have determined that EDI_PRow2 is the reason for the slowdown). Thanks in advance for any help.

[FranceBB]

Does anyone have a suggestion for a downscaling resizer that works in native high bit depth? I've searched about but can't find anything.

If you mean a simple resizing kernel, Avisynth+ built in resizing kernel work with high bit depth, however I suggest you to use the MT version made by Jean-Philippe.
You can find them here: https://forum.doom9.org/showthread.php?t=174248

For instance, this works absolutely fine in 4:4:4 16bit planar:


ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

Spline64ResizeMT(848, 480)


You can use other resizing kernel like Bilinear, Bicubic, Lanczos etc.
I actually suggest to use Lanczos for downscale and Spline36 or Spline64 to upscale.

Anyway, since in your script you were using EDI, you may wanna check out NNEDI which also works in 16bit planar:


ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=848, fheight=480, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)


as well as 16bit stacked:


ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

nnedi3_resize16(target_width=848, target_height=480, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)


Another resizer that works in 16bit stacked is LinearResize which lets you choose your desired resizing kernel and upscale or downscale with 16bit stacked precision:


ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

LinearResize(848, 480, kernel="spline64", mode=0, lsb_in=true, lsb_out=true, TVrange=true, matrix="709", matrix_out="709", cplace_in="mpeg2", cplace_out="mpeg2", NoRing=false, interlaced=false)


LinearResize is part of the ResizerPack that you can find here: http://www.mediafire.com/file/w8sayuutsbgbmvd/ResizersPack4.5.zip/file


I hope it helps.

Cheers,
Frank.

[StainlessS]

NNEDI3_RPow2 intended for UPSCALE ONLY, it can eg double (x2, x4, x8, power of 2, etc) the dimensions of input clip with good-ish neural net type stuff upsize, and then
using the 'CShift="Spline64"' bit, downsize to the exact required size, and fix center shift imposed by the NNEDI3_RPow2 upsizing.

Is likely slower than LSB high bit depth when down sizing, because you upsize with NNEDI3_RPow2 (probably 4x the area of source), and then downsize to target size.
Only use NNEDI3_RPow2 if UPSIZE.

I usually use NNedi3_RPow2, but assume EDI_RPow2 works the same-ish.

EDIT: Intended for NNedi3_RPow2, but I assume will work with Edi_RPow2
Estimate_Nnedi3_Rpow2() :- https://forum.doom9.org/showthread.php?t=176437

Rough usage

ColorBars(Width=400,Height=400,Pixel_type="YV12")
InW=Width
InH=Height

SCALE = 3.3
TH = 1.5
TH2 = TH
TAPS = 5

RND = 4 # Rounding to multiple of RND
OutW = (InW * SCALE + RND-1).Int / RND * RND # Round UP
OutH = (InH * SCALE + RND-1).Int / RND * RND # Round UP
#OutW = (InW * SCALE + RND/2).Int / RND * RND # Round Nearest
#OutH = (InH * SCALE + RND/2).Int / RND * RND # Round Nearest

rFactor=Last.Estimate_Nnedi3_Rpow2(OutW,OutH,th=TH,th2=TH2)
(rFactor>1)
\ ? nnedi3_rpow2(rfactor=rfactor,cshift="LanczosResize",fwidth=OutW,fheight=OutH,ep0=TAPS) [* Upsizing *]
\ : LanczosResize(OutW, OUTH, src_left=-0.5, src_top=-0.5, taps=TAPS) [* NOT Upsizing *]

S=String(InW,"InW=%.0f")+String(InH," : InH=%.0f")+String(OutW,"\nOutW=%.0f")+String(OutH," : OutH=%.0f")+String(rFactor,"\nrFactor=%.0f\n") + ((rFactor>1) ? "Using RPOW2" : "Not Using RPOW2")

Return Subtitle(S,Size=Height/16.0,lsp=0)

Change the stuff above in BLUE

EDIT: Nnedi3 resize16() script has ratiothr [instead of above TH and TH2] to do similar:- http://avisynth.nl/index.php/Nnedi3_resize16#Scaling_Ratio_Calculation
Scaling Ratio Calculation
float ratiothr = 1.125

When scale ratio is larger than ratiothr, use nnedi3+Dither_resize16 upscale method instead of pure Dither_resize16.
When horizontal/vertical scale ratio > "ratiothr", we assume it's upscaling
When horizontal/vertical scale ratio <= "ratiothr", we assume it's downscaling

[LouieChuckyMerry]

FranceBB: As always thank you for your help :) .


If you mean a simple resizing kernel, Avisynth+ built in resizing kernel work with high bit depth, however I suggest you to use the MT version made by Jean-Philippe.

You can find them here: https://forum.doom9.org/showthread.php?t=174248

For instance, this works absolutely fine in 4:4:4 16bit planar:


ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

Spline64ResizeMT(848, 480)


You can use other resizing kernel like Bilinear, Bicubic, Lanczos etc.
I actually suggest to use Lanczos for downscale and Spline36 or Spline64 to upscale.

Thank you very much. I've run a few tests and LanzcosResizeMT seems to work fine. What's the difference between Lanzcos and Lanzcos4?


Anyway, since in your script you were using EDI, you may wanna check out NNEDI which also works in 16bit planar:


ColorBars(3840, 2160, pixel_type="YV24")
ConvertBits(16)

nnedi3_rpow2(cshift="Spline64ResizeMT", rfactor=2, fwidth=848, fheight=480, nsize=4, nns=4, qual=1, etype=0, pscrn=2, threads=0, csresize=true, mpeg2=true, threads_rs=0, logicalCores_rs=true, MaxPhysCore_rs=true, SetAffinity_rs=false, opt=3)


as well as 16bit stacked:


ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

nnedi3_resize16(target_width=848, target_height=480, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=true)


Another resizer that works in 16bit stacked is LinearResize which lets you choose your desired resizing kernel and upscale or downscale with 16bit stacked precision:


ColorBars(3840, 2160, pixel_type="YV24")
Dither_convert_8_to_16()

LinearResize(848, 480, kernel="spline64", mode=0, lsb_in=true, lsb_out=true, TVrange=true, matrix="709", matrix_out="709", cplace_in="mpeg2", cplace_out="mpeg2", NoRing=false, interlaced=false)


LinearResize is part of the ResizerPack that you can find here: http://www.mediafire.com/file/w8sayuutsbgbmvd/ResizersPack4.5.zip/file

I was using EDI_PRow2 to upscale because of its native 16 bit support. I've used NNEDI in the past but stopped when I upgraded to native 16 bit, and the same for LinearResize (thanks dogway!), so your XXXResizeMT suggestion is great. With this script:

LoadPlugin("Path\LSMASHSource.dll")
LWLibavVideoSource("SourcePath")
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=1,ThSAD=100,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
LanczosResizeMT(1280,720)
aWarpSharp4xx(Depth=5)
FastLineDarkenMod4(Strength=24)
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0)
PreFetch(3)

do you see any way to improve downscaling 1080p?


I hope it helps.

Cheers,
Frank.

It truly does, danke!

[StainlessS]

What's the difference between Lanzcos and Lanzcos4?


Form docs
LanczosResize / Lanczos4Resize
LanczosResize is an alternative to BicubicResize with high values of c about 0.6 ... 0.75 which produces quite strong sharpening. It usually offers better quality (fewer artifacts) and a sharp image.

Lanczos was created for AviSynth because it retained so much detail, more so even than BicubicResize(x,y,0,0.75). As you might know, the more detail a frame has, the more difficult it is to compress it. This means that Lanczos is NOT suited for low bitrate video, the various Bicubic flavours are much better for this. If however you have enough bitrate then using Lanczos will give you a better picture, but in general I do not recommend using it for 1 CD rips because the bitrate is usually too low (there are exceptions of course).

The input parameter taps (default 3, 1<=taps<=100) is equal to the number of lobes (ignoring mirroring around the origin).

Lanczos4Resize (added in v2.55) is a short hand for LanczosResize(taps=4). It produces sharper images than LanczosResize with the default taps=3, especially useful when upsizing a clip.

Warning: the input argument named taps should really be lobes. When discussing resizers, taps has a different meaning, as described below (the first paragraph concerns LanczosResize(taps=2)):

"For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 2*4=8 input samples, and thus 8 taps. For 3x downsampling, you need 3*4=12 taps, and so forth.

Thus the effective number of taps you get for downsampling is the downsampling ratio times the number of filter input taps (thus Tx downsampling and LanczoskResize results in T*2*k taps), this is rounded up to the next even integer. For upsampling, it's always just 2*k taps." Source: [avsforum post].


EDIT: From what I've read elsewhere, NNEDI3_RPow2() does not handle native 16 bit, but EDI_RPPow2() does, however, what I said in post #4886
about NNedi3_RPow2() still holds for EDI_RPow2(), do not DOWNSCALE using EDI_RPow2(), just use your chosen Spline64Resize() instead of the EDI_RPow2() line.

Only use NNEDI3_RPow2 or EDI_RPow2() if UPSIZE.

[real.finder]

the problem with Spline64Resize and others naked avs resizes except dither_resize and avsresize (z_ConvertFormat) always centred chroma placement and that problem with mpeg2 420 and 422 subsampling

resizex use MT version that made by Jean-Philippe if it present

[jpsdr]

BTW, the version i've made of nnedi3 (and nnedi3_rpow2) supports native 16 bits, and also nnedi3_rpow2 doesn't have the centred chroma placement issue that also has the original.

[LouieChuckyMerry]

Form docs

EDIT: From what I've read elsewhere, NNEDI3_RPow2() does not handle native 16 bit, but EDI_RPPow2() does, however, what I said in post #4886
about NNedi3_RPow2() still holds for EDI_RPow2(), do not DOWNSCALE using EDI_RPow2(), just use your chosen Spline64Resize() instead of the EDI_RPow2() line.

Only use NNEDI3_RPow2 or EDI_RPow2() if UPSIZE.

Thanks again :) . I'll hopefully run some upscale-downscale tests this weekend with EDI, NNEDI, Spline, Lanczos, Bicubic, and others.


the problem with Spline64Resize and others naked avs resizes except dither_resize and avsresize (z_ConvertFormat) always centred chroma placement and that problem with mpeg2 420 and 422 subsampling resizex use MT version that made by Jean-Philippe if it present

Thank you :) . I've downloaded ResizeX and will run some tests hopefully this weekend.


BTW, the version i've made of nnedi3 (and nnedi3_rpow2) supports native 16 bits, and also nnedi3_rpow2 doesn't have the centred chroma placement issue that also has the original.

Merci :) . I'll hopefully run some tests this weekend.

[jpsdr]

If you use my ResizexxxMT and also my NNEDI version, you'd better get my plugin package with all my filters in one dll instead of several filters in several dll.

[LouieChuckyMerry]

If you use my ResizexxxMT and also my NNEDI version, you'd better get my plugin package with all my filters in one dll instead of several filters in several dll.

Thanks for the advice, jpsdr. It's here in case someone finds it useful: JPSDRPluginsPack (https://forum.doom9.org/showthread.php?t=174248). Several questions:

1) When you typed "ResizexxxMT" did you mean "ResampleMT/Desample"? I didn't find anything named "ResizexxxMT".

2) I'm running Win 7 x64 with an Intel Core i5-3320M CPU--Speccy states "MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, Intel 64, NX, VMX, AES, AVX"--so which version would I use, the "Release_Intel_W7_Core2_SSE4.2"? Apologies for my ignorance.

Edit: Trial and error has taught me that my laptop is old, and W7_AVX is my best option.

3) Would you have a suggestion, or personal preference, for which resize plugin to use for upscaling animation DVD's (eg, The Simpsons and Futurama) and downscaling animation Blu-rays (eg, Adventure Time).

Thank you very much.

[FranceBB]

1) When you typed "ResizexxxMT" did you mean "ResampleMT/Desample"? I didn't find anything named "ResizexxxMT".

He means his set of resizers, like BilinearResizeMT, BicubicResizeMT, LanczosResizeMT ecc.

2) I'm running Win 7 x64 with an Intel Core i5-3320M CPU--Speccy states "MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, Intel 64, NX, VMX, AES, AVX"--so which version would I use, the "Release_Intel_W7_Core2_SSE4.2"? Apologies for my ignorance.

Those are CPU Instruction sets which in terms of a program refer to how the program has been compiled. A program can have manually written intrinsics (e.g parts written in assembly) or it can be written using C++ and then compiled.
To clarify this, there are low-level programming languages like Assembly and high-level programming languages like C++. When you write a program and then you compile it, it's up to the compiler to produce a code that the machine understands.
If you write it using a low-level programming language like Assembly, the code is gonna be very optimized as it's gonna be as close as possible to what the machine understands, however writing a full program in a low-level language is a nightmare, especially for complicated things, where it's easy to lose track of what you are doing and why you are doing it. As opposite, a high level programming language like C++ is easier to use, however it will be less optimized 'cause the compiler has to "guess" about what you wanted to do and "bring" your code to something that a machine can understand. Generally, the idea is to use a high level programming language and then optimize the key parts by manually writing intrinsics, (which is not easy and it's far too advanced for me as I'm not able to do that and I only code using a high level programming language).
Now, in the case of Jean-Philippe plugins, I believe that they were written in C++ only and then compiled using different assembly optimizations. (It's been a while since I last checked the code, though, so I might be wrong).
This way, it's gonna be the compiler that will try to understand what the programmer wanted to do and will try to optimize it for different assembly instructions, which won't be as fast as manually written intrinsics, but it will be faster than using no assembly optimizations at all.
Now, I know what you are thinking... you are basically thinking "fair enough, Frank, but what are those SSE, SSE2, SSE3 SSSE3, SSE4.1, SSE4.2, AVX ecc things?".
Well, one way I use to explain this to non-programmers is to think about two CPUs, an old one with SSE2 and a recent one with AVX2.
Think about the SSE2 CPU as a "dumb child" who can only do addition and the AVX2 one as a "smart child" who can do multiplication.
Of course, as long as the teacher assigns those children additions, both are gonna be fine, however, if the teacher assigns those children multiplications, the second child (the smart one) will do them, while the first one (the dumb one) will have to split them into additions and then will get to the same result.
The teacher is like the program you are trying to execute.
Additions is like a program compiled with SSE2.
Multiplication is like a program compiled with AVX2.
If you try to assign multiplications to the dumb child without splitting them into additions, the dumb child won't be able to do them, which means that if you compile a program with AVX2 and you try to open it with an SSE2 capable CPU it won't be able to run it and will fail, however if you split them in sums and you assign them to the dumb child, he will be able to do them, but it will take longer (i.e if you compile the program with SSE2, the CPU will be able to run the program but it will be slower).

And... that's it. :)
I know that it's a very simple way to see it and there is more behind this, but I'm not gonna explain it any further as it would take pages to get into details of what each and every instruction set does, but you can check Wikipedia for them as they are all documented.
One little note at the end: remember that I told you that sometimes programs are written in C++ only and then compiled with assembly optimizations by the compiler which has to guess what the compiler is doing? Well, it may not guess right and, as a matter of fact, there are times in which an AVX2 compiled code is not faster than an SSE4.2 compiled one (I'm sure there are topics about it on Doom9 but I can't think about them, I just know that I've been over this other times in the past). :)

[jpsdr]

@LouieChuckyMerry
You can use either Release_Intel_W7_Core2_AVX or Release_W7_AVX.
After, check the readme also.

There is a lot of ASM optimized, CPU path is made internaly for these parts, but for the other C++ code, compiler optimize.

[LouieChuckyMerry]

FranceBB: I had to read your last post three times but I finally understand: I'm a "dumb child" :D . Seriously, thanks for the, er, dumbed down explanation. As a computer noob I found it quite informative and am very appreciative :) .

jpsdr: Thanks for your help, and for all your awesome plugins :) .

Happy Friday!

[qyot27]

https://github.com/AviSynth/AviSynthPlus/releases

AviSynth+ 3.4.0 has been released. I debated whether to post a new thread in order to make sure it was visible, but I figured that even if a dedicated release post gets made, it should also be posted here too.

Back in June there was a somewhat-short discussion about the versioning and a new release. Since there weren't any objections brought up about the commit I'd mentioned as having done a version bump, and nearly four months went by, I simply went ahead and did it. Another big reason is that there's a MAJOR patchset I've been working on in manic bursts over the last month, and since it changes a good amount of things I wanted to make sure there was a solid official release to point to before a lot of the work hammering that patchset into shape really gets going.

3.4 is pretty boring, all told. As the big changes from pull request #101 were already committed to MT several months ago, 3.4 basically catches up with pinterf's development branch (r2915 from late August) and has a small number of additional patches to smooth over the packaging process and officially roll over to the new versioning.

Some other highlights:
MT was finally merged back into the master branch.
A new '3.4' branch was created to [hopefully] track releases in the 3.4 series from this point forward.
How to do third-number version releases is still an open question; should it be vital bugfixes only? A generic X number of months rolling forward? Really open to suggestion here.
Part of the release is actually a GCC build of 3.4. Installation notes included (and packaged in a 7zip archive instead of an installer) because I haven't added the requisite logic to the InnoSetup script to handle FHS-style install paths yet.
Due to the version bump, don't be surprised if some curmudgeonly software that didn't like using AviSynth+ suddenly starts working with it.

[markfilipak]

Hello Folks!

I went here: http://www.avs-plus.net/
and downloaded this: https://github.com/AviSynth/AviSynthPlus/releases/download/Rel-r1576/AviSynthPlus-r1576.zip
and unzipped it.
Now I have these:
\AviSynth.dll
\system\DevIL.dll
\plugins\DirectShowSource.dll
\plugins\ImageSeq.dll
\plugins\Shibatch.dll
\plugins\TimeStretch.dll
\plugins\VDubFilter.dll
I checked them at VirusTotal.

I understand what avisynth is.
What do I do with the DLLs?

The documentation begins with writing a 1st script.
There appears to be nothing that outlines how to set up the frameserver, how to get started, how to bootstrap the process.
I know there's a Windows installer. It's by Inno. I lost the magic formula for opening Inno Setups to check the internals for viruses and it's unclear whether VirusTotal actually does that when it analyzes a wrapper executable.
I already have Python 3.7 (64-bit) installed.
What more do I need and how do I proceed?

I have 2 objectives:
1, Retire HandBrake, and
2, try some interframe field blending ideas that should improve on 2-3 pull-down.

Thanks.

[StainlessS]

markfilipak,
Avoid r1576, is from several years ago [4 or 5].
Get This one AviSynthPlus_3.4.0_20191020.exe from here:- https://github.com/AviSynth/AviSynthPlus/releases

[filler56789]

http://www.avs-plus.net/ should be shut down for good.

[ryrynz]

I already had the minimum and additional 2019 runtimes installed (x86 and x64), did I really need this to install 2015-2019 Redistributable?

[StainlessS]

If your already had all required installed then probably not, Pinterf provides exe both with and without runtimes.
[you would likely have found out pretty quiickly whether you needed runtime updates or not].

[LigH]

You may need one or another Visual C++ Runtime for one or another plugin, too ...

[Groucho2004]

EDIT: Two problems revealed already for avs+ 3.4.0,
Problems apps,
Groucho2004 Universal Avisynth Installer, and
Shekh The Magnificent's VirtualDub2.
EDIT: Breaks Potplayer [Freezes],
script

Version

As I mentioned in the other two threads, install the non-GCC version.

[pinterf]

https://github.com/AviSynth/AviSynthPlus/releases

AviSynth+ 3.4.0 has been released. I debated whether to post a new thread in order to make sure it was visible, but I figured that even if a dedicated release post gets made, it should also be posted here too.


What a day! An Avisynth version from the original master branch, great. I still hope I'm returing here soon, my schedule is too busy since August to allow doing free-time projects.

[StainlessS]

So, is this now considered a continuation of the fabled and abandoned v3.0 Avisynth ?

EDIT: Avisynth v3.0 on Wiki:- http://avisynth.nl/index.php/AviSynth_v3

[Groucho2004]

Sorry Stainless, I deleted my post to which you replied. Anyway, this seems to confirm that it is indeed basically pinterf's r2915:
3.4 is pretty boring, all told. As the big changes from pull request #101 were already committed to MT several months ago, 3.4 basically catches up with pinterf's development branch (r2915 from late August) and has a small number of additional patches to smooth over the packaging process and officially roll over to the new versioning.

[real.finder]

So, is this now considered a continuation of the fabled and abandoned v3.0 Avisynth ?

EDIT: Avisynth v3.0 on Wiki:- http://avisynth.nl/index.php/AviSynth_v3

I think it's not, avs 3.X is not avs+ 3.X :)

but anyway the goals of avs 3.X is similar to avs+

[StainlessS]

It portrays itself like so :-
https://i.postimg.cc/cLvxnfjc/3-4.jpg (https://postimages.org/)

https://i.postimg.cc/qMdDnr5D/3-4x64.jpg (https://postimages.org/)

EDIT: This posted here:- https://forum.doom9.org/showthread.php?p=1886179#post1886179

Is still an issue in v3.4,
when Length=1, (for both BlankClips) it dont work, (ConditionalFilter fails)

Failing script


ROW = True
LIMITLO = 74.0 # >= is Target
LIMITHI = 100.0 # <= is Target
INCOLOR = $008080 # Set where in target range
OUTCOLOR = $FF8080 # Not in target range
SHOW = false # Return StackHorizontal, original as Y8, and mask.
###############
Colorbars.Trim(0,-100).convertToY8
MskByRowAveY(Row=ROW,LimitLo=LIMITLO,LimitHi=LIMITHI,InColor=INCOLOR,OutColor=OUTCOLOR,Show=SHOW)
Return Last

Function MskByRowAveY(clip c, Bool "Row", Float "LimitLo", Float "LimitHi", Int "InColor", Int "OutColor", Bool "Show") {
# Where AveLuma of pixel Row/Coloumn is between LimitLo<===>LimitHi, then set to Incolor, else OutColor. Colors Specified as YUV, where only Y8 returned.
c myName="MskByRowAveY: "
Row=Default(Row,true) LimitLo=Default(LimitLo, 0.0) LimitHi=Default(LimitHi,127.5)
InColor =Default(InColor ,$000000) OutColor=Default(OutColor,$FF8080) Show=Default(Show,False)
Assert(0.0 <= LimitLo <= LimitHi,myName+String(LimitLo,"0.0 <= LimitLo(%f)") + String(LimitHi," <= LimitHi(%f)"))
Assert(LimitHi <= 255.0,myName+String(LimitHi,"LimitHi(%f) <= 255.0"))
ConvertToY8.KillAudio O=Last
(Row) ? SeparateRows(O.Height) : SeparateColumns(O.Width)

FAIL=false # toggle to fail

len = (FAIL) ? 1 : Last.Framecount

InC = Last.BlankClip(Length=Len,Color_YUV= InColor) OutC= Last.BlankClip(Length=Len,Color_YUV=OutColor)
Last.ConditionalFilter(InC,OutC,String(LimitLo,"(%f<=AverageLuma<=")+String(LimitHi,"%f)"))
(Row) ? WeaveRows(O.Height) : WeaveColumns(O.width)
Return (SHOW) ? StackHorizontal(O,Last) : Last
}

[pinterf]

when Length=1, (for both BlankClips) it dont work, (ConditionalFilter fails)

Failing script


ROW = True
LIMITLO = 74.0 # >= is Target
LIMITHI = 100.0 # <= is Target
INCOLOR = $008080 # Set where in target range
OUTCOLOR = $FF8080 # Not in target range
SHOW = false # Return StackHorizontal, original as Y8, and mask.
###############
Colorbars.Trim(0,-100).convertToY8
MskByRowAveY(Row=ROW,LimitLo=LIMITLO,LimitHi=LIMITHI,InColor=INCOLOR,OutColor=OUTCOLOR,Show=SHOW)
Return Last

Function MskByRowAveY(clip c, Bool "Row", Float "LimitLo", Float "LimitHi", Int "InColor", Int "OutColor", Bool "Show") {
# Where AveLuma of pixel Row/Coloumn is between LimitLo<===>LimitHi, then set to Incolor, else OutColor. Colors Specified as YUV, where only Y8 returned.
c myName="MskByRowAveY: "
Row=Default(Row,true) LimitLo=Default(LimitLo, 0.0) LimitHi=Default(LimitHi,127.5)
InColor =Default(InColor ,$000000) OutColor=Default(OutColor,$FF8080) Show=Default(Show,False)
Assert(0.0 <= LimitLo <= LimitHi,myName+String(LimitLo,"0.0 <= LimitLo(%f)") + String(LimitHi," <= LimitHi(%f)"))
Assert(LimitHi <= 255.0,myName+String(LimitHi,"LimitHi(%f) <= 255.0"))
ConvertToY8.KillAudio O=Last
(Row) ? SeparateRows(O.Height) : SeparateColumns(O.Width)

FAIL=false # toggle to fail

len = (FAIL) ? 1 : Last.Framecount

InC = Last.BlankClip(Length=Len,Color_YUV= InColor) OutC= Last.BlankClip(Length=Len,Color_YUV=OutColor)
Last.ConditionalFilter(InC,OutC,String(LimitLo,"(%f<=AverageLuma<=")+String(LimitHi,"%f)"))
(Row) ? WeaveRows(O.Height) : WeaveColumns(O.width)
Return (SHOW) ? StackHorizontal(O,Last) : Last
}


Output frame count of ConditionalFilter will be max(InC.FrameCount, OutC.FrameCount). When you set it to 1 (FAIL=true case), ConditionalFilter output will be a single frame result. Which is then fed into WeaveRows, which needs at least O.Height of clip length to work properly.

[StainlessS]

Nice theory P :)

But, what about this one then [no SeparateRows]


FAIL = False # Force Falure ?
C=0
For(i=0,255) {
C2=BlankClip(Pixel_Type="Y8",Length=1,Color_YUV=(i*256+$80)*256+$80)
C=(!c.IsClip) ? C2 : C ++ C2
}
C # 256 frames, Y ascending

Len = (FAIL) ? 1 : FrameCount

K=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$008080).Subtitle("[FAIL=" + String(FAIL) + "] Is NOT greater than 100.0",Align=5)
W=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$FF8080).Subtitle("[FAIL=" + String(FAIL) + "] Is greater than 100.0",Align=5)

ConditionalFilter(W,K,"averageLuma >= 100.0 ",Show=true)
C=C.Scriptclip("""Subtitle(String(current_frame,"%.0f] Y=") + String(AverageLuma,"%.2f"))""")
StackHorizontal(C,Last)

#Trim(255,-1) # Only show last frame where result should be WHITE.


I had posted this earlier in this thread [as EDIT] but forgot, here:- http://forum.doom9.org/showthread.php?p=1886179#post1886179

EDIT: both W and K have to be single frame to fail, I cant re-check as I'm in middle of system restore from image.
EDIT: I would expect it to behave like the other runtime filters, it is commonplace to return a single frame in eg Scriptclip, makes no difference to length of outut
clip, which is guaranteed same as input.

[markfilipak]

markfilipak,
Avoid r1576, is from several years ago [4 or 5].
Get This one AviSynthPlus_3.4.0_20191020.exe from here:- https://github.com/AviSynth/AviSynthPlus/releases

Now I have the latest installed. Thanks for the link. And I found the example AVS scripts.

I have crawled through what documentation I could find. I apparently missed some [1].

I was hoping avisynth could serve video files, starting with something simple, like this:

return read('d:\path\movie.mkv')

I see how to create a blank clip or color bars, but I can't find anything like the above. A link to info would be fine of course.

Thanks.

[1]
I can't find a link between this:
http://avisynth.nl/index.php/Internal_functions
and this:
http://avisynth.nl/index.php/AviSynth_Syntax
so it appears I'm missing some crucial info.

[poisondeathray]

Now I have the latest installed. Thanks for the link. And I found the example AVS scripts.

I have crawled through what documentation I could find. I apparently missed some [1].

I was hoping avisynth could serve video files, starting with something simple, like this:

return read('d:\path\movie.mkv')

I see how to create a blank clip or color bars, but I can't find anything like the above. A link to info would be fine of course.

Thanks.

[1]
I can't find a link between this:
http://avisynth.nl/index.php/Internal_functions
and this:
http://avisynth.nl/index.php/AviSynth_Syntax
so it appears I'm missing some crucial info.



You need a source filter to load videos. Common ones are ffms2 and lsmash. They are separate .dll's which will autoload if placed into the plugins directory, or you can explicitly load them with LoadPlugin . Certain source filters have various pros/cons in different situations and for different types of video

FFVideoSource("d:\path\movie.mkv")

or

LWLibavVideoSource("d:\path\movie.mkv")


avisynth is a bit different in that there is an "implied last" , so you don't have to return an output node such as in vapoursynth, you can omit it entirely

If you omit it, it really means
return last

[markfilipak]

You need a source filter to load videos. Common ones are ffms2 and lsmash. They are separate .dll's ...
There are no DLLs there (https://github.com/FFMS/ffms2). A search for 'ffms2.dll' fails.

[poisondeathray]

There are no DLLs there (https://github.com/FFMS/ffms2). A search for 'ffms2.dll' fails.



For Github, usually there are compiled releases under "releases" (click on "releases") for all types of projects listed on Github

But for ffms2 , those are old . (You actually might want even older if you were dealing with MPEG2 / DVD, but I would avoid it completely and use MPEG2Source, hence the pros/cons warning earlier . There are many "gotchas" and quirks for various source filters)

You can find latest in the development threads . Go to the end of each and work your way backwards . You might want to download the old "official" ones , because they have the documentation. Some of the "new" releases are just the .dll's without source or documentation

https://forum.doom9.org/showthread.php?t=167435
https://forum.doom9.org/showthread.php?t=127037

It's not a great way of organizing things, it's just they way it is. Sometimes you have to search quite a bit for matching or proper .dlls for certain plugins. There is a project similar to vapoursynth repo called avsrepogui from CK too that might be helpful for some people
https://forum.doom9.org/showthread.php?t=176443

[ChaosKing]

I would say this is currently the safest ffms2 dll with the latest codec support like av1 https://forum.doom9.org/showthread.php?p=1886890#post1886890

With safe I mean frame accurate. See table here https://forum.doom9.org/showthread.php?t=176231

Or you can lsmash via the avsrepogui tool :P

[wonkey_monkey]

Just so I've got this straight, pinterf forked the "official" Avisynth+ to update it, and now the "official" Avisynth+ has incorporated his work into itself?

[StainlessS]

Just so I've got this straight, pinterf forked the "official" Avisynth+ to update it, and now the "official" Avisynth+ has incorporated his work into itself?

Perhaps I'm old and tired, but I think that the chances of finding out what's actually going on are so absurdly remote that the only thing to do is to say, "Hang the sense of it," and keep yourself busy. I'd much rather be happy than right any day.

EDIT: And you can quote me on that [and I feel that somebody defo will]. :)

[wonkey_monkey]

I'd much rather be happy than right any day.

And are you?

[StainlessS]

Truth be told, I'm always right, I've never been happy, hang the sense of it, lets get pissed instead.

[qyot27]

Just so I've got this straight, pinterf forked the "official" Avisynth+ to update it, and now the "official" Avisynth+ has incorporated his work into itself?
Yes and no. The nuance is a bit specific to how Git works.

Git itself is a very decentralized development platform, so 'fork' can carry a much less confrontational connotation than it did in the earlier days of FOSS development (https://help.github.com/en/github/getting-started-with-github/fork-a-repo).

pinterf had opened pull requests for upstream to merge several times before ultim went on hiatus in 2016 (https://github.com/AviSynth/AviSynthPlus/pulls?q=is%3Apr+author%3Apinterf+is%3Aclosed). That most recent one, #101 (https://github.com/AviSynth/AviSynthPlus/pull/101), wasn't merged before ultim left, so pinterf's personal repo those PRs were opened from became the de facto development HEAD. If we needed to get something merged, the PRs were submitted to pinterf, and became part of pull request #101.

In June, ultim came back for a moment and granted pinterf and myself commit rights to the main repository so that it could stay up-to-date. Basically, the development HEAD of the project is back at its original location.

[LigH]

Then I guess I can move to https://github.com/AviSynth/AviSynthPlus/releases as default download source now, assuming that all the developers will contribute there now.

[pinterf]

Yep, now I can work directly into the master branch of the original AvisynthPlus repo, thanks qyot27 to make this step.

I met ultim in the summer, he told he was willing to give access to http://avs-plus.net . But at that time (and since then as well) I was engaged in office work and other activities so I postponed the decision whether I wanted to deal with it or not.

[pinterf]

Nice theory P :)

But, what about this one then [no SeparateRows]


FAIL = False # Force Falure ?
C=0
For(i=0,255) {
C2=BlankClip(Pixel_Type="Y8",Length=1,Color_YUV=(i*256+$80)*256+$80)
C=(!c.IsClip) ? C2 : C ++ C2
}
C # 256 frames, Y ascending

Len = (FAIL) ? 1 : FrameCount

K=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$008080).Subtitle("[FAIL=" + String(FAIL) + "] Is NOT greater than 100.0",Align=5)
W=Last.BlankClip(Length=Len,Pixel_Type="Y8",Color_YUV=$FF8080).Subtitle("[FAIL=" + String(FAIL) + "] Is greater than 100.0",Align=5)

ConditionalFilter(W,K,"averageLuma >= 100.0 ",Show=true)
C=C.Scriptclip("""Subtitle(String(current_frame,"%.0f] Y=") + String(AverageLuma,"%.2f"))""")
StackHorizontal(C,Last)

#Trim(255,-1) # Only show last frame where result should be WHITE.


I had posted this earlier in this thread [as EDIT] but forgot, here:- http://forum.doom9.org/showthread.php?p=1886179#post1886179

EDIT: both W and K have to be single frame to fail, I cant re-check as I'm in middle of system restore from image.
EDIT: I would expect it to behave like the other runtime filters, it is commonplace to return a single frame in eg Scriptclip, makes no difference to length of outut
clip, which is guaranteed same as input.
Works as expected. The frame count of ConditionalFilter depends only on W and K, namely max(K.FrameCount, W.FrameCount).
See https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L233

So the output contains exactly 1 frames and when you do StackHorizontal with the original 256-frame clip, it will show the same single frame on the right.

[StainlessS]

Thanks P,
I guess that I have generally misunderstood the operation of that filter, also explains why I usually avoid it altogether.
I am now questioning my entire mental model of the Universe.

EDIT: OT
There was a TV series in the UK called "Baby Its you" :- https://www.walltowall.co.uk/program/baby-its-you-a-babys-world_26.aspx
(Google search to avoid song of same name, "Baby Its you" TV -song")
EDIT: aka "A Baby’s World", narrated by Bill Paterson. [Ally Frazer in "Auf Wiedersehen Pet"]

They had a ~6 month old strapped into a chair, blank room with nothing of interest to distract infant.
In front of baby, a table and an up/down sliding wall.

From the side, out comes a little wooden doll and goes behind the wall. Wall goes down and there is the single wooden doll.
Doll exits stage right, back behind curtain from whence it came, wall goes up.

Operation repeats with two individual dolls going behind all, wall drops, two dolls revealed, both exit stage right, wall goes up.

Operation repeats again with two individual dolls going behind wall, wall drops,
but this time there are three dolls revealed.
Baby in chair throws up its arms and with look look of total horror on its face,
you could read its thoughts, "Damn, sometimes 1 + 1 = 3 ???".

That baby is probably now a theoretical mathematician, or total math dunce.

The above award winning TV program is available on DVD, (Think I'll get it, it was most compelling viewing).

[pinterf]

As I mentioned in the other two threads, install the non-GCC version.
I see that the Avisynth+ link was updated on videohelp, pointing on the GCC release build as the "portable" version. But it won't work properly?
Also, the changelog is also much shorter there than it appears in the readme.txt. I don't know who is maintaining the links there.

Note, that my earlier releases with suffix filesonly.7z were containing the same dlls as the main installer, in this 3.4 release there is no such option yet.

And a question: in which environment should someone use the GCC build?

[tormento]

I am finding AviSynth+ 3.4.0–20191020 bit slower than previous 2915 (x64 environment).

First script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV_x64\DGDecodeNV.dll")
DGSource("E:\in\2_23 Shining (remastered extended)\01222.dgi")
CompTest(1)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)

2915: encoded 2072 frames, 10.49 fps, 2432.63 kb/s
3.4.0–20191020: encoded 2072 frames, 10.05 fps, 2432.63 kb/s

Same script but with tr=6:

2915: encoded 2072 frames, 7.91 fps, 2312.11 kb/s
3.4.0–20191020: encoded 2072 frames, 7.42 fps, 2312.09 kb/s

Can you confirm this?

[Groucho2004]

I am finding AviSynth+ 3.4.0–20191020 bit slower than previous 2915 (x64 environment).
Can you confirm this?Why are you adding useless complexity to this comparison by bringing an encoder into it? Measure the speed of the script and report memory usage, fps, etc.

[tormento]

Why are you adding useless complexity to this comparison by bringing an encoder into it? Measure the speed of the script and report memory usage, fps, etc.
Results:

AviSynth+ 0.1 (r2900, MT, x86_64)
Frames processed: 2072 (0 - 2071)
FPS (min | max | average): 1.548 | 500000 | 12.84
Process memory usage (max): 1444 MiB
Thread count: 74
CPU usage (average): 69.6%
GPU usage (average): 31%
VPU usage (average): 8%
GPU memory usage: 1811 MiB
Time (elapsed): 00:02:41.330

AviSynth+ 0.1 (r2915, MT, x86_64)
Frames processed: 2072 (0 - 2071)
FPS (min | max | average): 1.546 | 588235 | 12.86
Process memory usage (max): 1442 MiB
Thread count: 74
CPU usage (average): 69.5%
GPU usage (average): 30%
VPU usage (average): 9%
GPU memory usage: 1788 MiB
Time (elapsed): 00:02:41.072

AviSynth+ 3.4 (r2923, 3.4, x86_64)
Frames processed: 2072 (0 - 2071)
FPS (min | max | average): 1.627 | 500000 | 12.80
Process memory usage (max): 1445 MiB
Thread count: 74
CPU usage (average): 69.5%
GPU usage (average): 30%
VPU usage (average): 8%
GPU memory usage: 1810 MiB
Time (elapsed): 00:02:41.868

Not so different indeed. But, using Simple x264 launcher:

AviSynth+ 0.1 (r2900, MT, x86_64)
10.18 fps, 2432.64 kb/s

AviSynth+ 0.1 (r2915, MT, x86_64)
10.50 fps, 2432.63 kb/s

AviSynth+ 3.4 (r2923, 3.4, x86_64)
9.72 fps, 2432.63 kb/s

Strange, uh?

[qyot27]

I see that the Avisynth+ link was updated on videohelp, pointing on the GCC release build as the "portable" version. But it won't work properly?
Also, the changelog is also much shorter there than it appears in the readme.txt. I don't know who is maintaining the links there.

Note, that my earlier releases with suffix filesonly.7z were containing the same dlls as the main installer, in this 3.4 release there is no such option yet.

I noticed that too. I *think* it might be a script that just automatically thinks .7z archive = portable.

I mean, there is Installation_Instructions.txt in the archive that says exactly what you need to do with it, and the .dlls being in typical FHS-style directories (x86_64-w64-mingw32/[bin|include|lib] and i686-w64-mingw32/[bin|include|lib]) rather than the way they're organized for DLL-only MSVC builds should be another point making it obvious.

And a question: in which environment should someone use the GCC build?
I could say 'to test with', but that's only somewhat true because the build does work just fine on its own and with the plugins included with it (and C plugins). It can be used to test whether your C++ plugin can work correctly when built with GCC, though (or to run speed tests, or to be able to use gdb to debug, I suppose, although that's not a debug build).

64-bit builds of FFmpeg and VirtualDub2 are fine with the GCC builds. The 32-bit ones need separate builds to work correctly with it (at least in FFmpeg's case).

[tebasuna51]

I mean, there is Installation_Instructions.txt in the archive that says exactly what you need to do with it...

"However, GCC-built C++ plugins cannot reside in the same directories as MSVC-built C++ plugins, and AviSynth+GCC cannot use MSVC-built C++ plugins. Mixing C++ plugins built by MSVC and GCC in a single directory will cause AviSynth+ (MSVC or GCC) to crash."

Really?!

Another set of plugins?

Please some pity with the users.

[manolito]

Please some pity with the users.

+1 :p

If even a guru like StainlessS downloads the wrong version just because it is at the top of the list then something is wrong with the download page.

No "normal" AVS user knows the difference between an MSVC build and a GCC build, and nobody has a clue about the restrictions of the GCC build.

So at least the GCC version should be slightly hidden, and there should be a clear warning (in red bold letters) that this version is not meant for the average user.


Cheers
manolito

[wonkey_monkey]

What is the GCC version for?

[qyot27]

Really?!

Another set of plugins?

Please some pity with the users.
Unless you're fine completely abandoning the use of C++ plugins, there's no way around that problem. C++ implementations are compiler-specific, and C++ plugins must be built with the same compiler that built the program core. The things that might have been able to partially smooth over this problem would have the effect of completely breaking existing 2.5, 2.6, and Plus plugins and would have had to have been done years before AviSynth+ even existed.

The C API is the easiest way to avoid that problem, because it sidesteps the issue entirely. But there's not a whole lot of C plugins, and only two or three I'd consider to be of major importance (the C-plugin variant of FFMS2, AssRender, and maybe yadif).

So at least the GCC version should be slightly hidden, and there should be a clear warning (in red bold letters) that this version is not meant for the average user.
I had to rename it in order for it not to be first in the list anymore (the order is down to Github's own sorting), and I added a warning to the release post.

What is the GCC version for?
Under Windows? Speed tests, compiler compliance tests, and debugging with gdb (although as I noted before, the available GCC build is not a debug build and has its symbols stripped). Cross-compiling with MinGW-w64 under MSys2, Cygwin, or from Linux distros.

GCC support is paramount for cross-platform development, though. GCC (or compilers that stay compatible with GCC's output) is dominant on pretty much everything that's not Windows. At present in one of the development branches, nearly all of the AviSynth+ core and filters can compile natively on Linux. The missing bits are critical for it actually working on there, but basically, that leap to being fully cross-platform is tantalizingly close now - and a significant reason is because GCC compliance was added 3 years ago.

[Myrsloik]

The previous post is mostly false. There's clang-cl which does support the visual studio c++ ABI on windows. Thin api wrapper layers are also an option. För some reason you chose to produce a mostly unusable build configuration on windows.

[manolito]

Thanks qyot27 for the clarifications and for editing the GitHub download page... :)

About the speed issues which were reported by tormento:

I tried to replicate the issues under a 32-bit environment, and I couldn't. The script speeds reported by AvsMeter were always identical, and measuring the speeds for a real conversion using X264 was also uneventful. I always got the same speed with AVS+ 3.40 and AVS+ r2915, no matter how simple or complex my script was.

Could this issue be a 64-bit thing?


Cheers
manolito

[qyot27]

There's clang-cl which does support the visual studio c++ ABI on windows.
I didn't mention clang-cl mostly because my point was that VC++ and MinGW/GCC have incompatible ABIs and avisynth.h and related bits don't try to reconcile them. I could have been more precise, or just pointed to this post by JEEB from several years ago (https://forum.doom9.org/showthread.php?p=1653392#post1653392).

Thin api wrapper layers are also an option.
A C++ wrapper over a standard C API (tp7 mentioned this as the goal for AviSynth+'s future API development, but it obviously never happened), or a C++ wrapper around an incompatible C++ ABI? The former is what I usually see suggested, not the latter.

[manolito]

The AviSynth main page at avisynth.nl still points to the latest GitHub pinterf Avisynth+ r2772 version instead of the current page for version 3.40.

Could someone please consolidate the links?

[r0lZ]

The AviSynth main page at avisynth.nl still points to the latest GitHub pinterf Avisynth+ r2772 version instead of the current page for version 3.40.

Could someone please consolidate the links?
I agree. Currently, it is a nightmare for the newbie to find the correct version to install. The first result when you google Avisynth+ is avs-plus.net, and finding this thread is not obvious for many peoples.

avs-plus.net should be closed, and a similar site with clear links to download the latest stable version should be created.

[tormento]

Could this issue be a 64-bit thing?
Can't you do a try with x64?

[manolito]

Sorry, no, I can't...

Since I do not use any 64-bit software which uses AviSynth, I only have the 32-bit version of AVS+ installed. I also have no desire to maintain additional plugin folders for the 64-bit plugins. My 32-bit plugins are good and fast enough for me, 2 plugin folders (plugins and plugins+) are enough for me.

And last but not least 1 of my computers has a 32-bit only CPU, and I want identical AVS setups on all my machines.

[Reel.Deel]

The AviSynth main page at avisynth.nl still points to the latest GitHub pinterf Avisynth+ r2772 version instead of the current page for version 3.40.

Could someone please consolidate the links?

Done.

-----------

1st post on this thread also needs to be updated.

[manolito]

:thanks:

[filler56789]

1st post on this thread also needs to be updated.

Yes, a moderator should do that, because ultim's last Activity = 3rd July 2019 09:11 :–/

[tebasuna51]

1st post on this thread also needs to be updated.

A temporal EDIT is done.

[stax76]

I would like to request AviSynth+ 3.4.0 without vcredist, it's too big to distribute with staxrip.

[qyot27]

I've uploaded a plain 7z portable for 3.4.0 (well, technically, r2925 built from master, but the extra commit* only touched the READMEs, it's still otherwise-identical to 3.4). I also removed the GCC archive since videohelp still was (or, is at this time of writing) pointing at it as a 'portable' even when that was not the intention.

*the other's just the merge commit for that one change

[stax76]

staxrip requires the install version of avisynth (and vapoursynth).

[real.finder]

A C++ wrapper over a standard C API (tp7 mentioned this as the goal for AviSynth+'s future API development, but it obviously never happened), or a C++ wrapper around an incompatible C++ ABI? The former is what I usually see suggested, not the latter.

why not both? or for now C++ wrapper around an incompatible C++

[Stereodude]

A temporal EDIT is done.
IMHO, your edit could be clearer. Someone is going to click on the first link inside your edit and think that's what they need when those are actually the old ones.

My opinion is it should be something like this:

[MODERATOR EDIT:]
Current branch as of November 2019:
The pinterf fork was integrated (https://forum.doom9.org/showthread.php?p=1888102#post1888102) in main line like AviSynth+ 3.4.0
Download and sources: From GitHub (https://github.com/AviSynth/AviSynthPlus/releases)


Older superseded branch/fork:
[Download: From GitHub (https://github.com/pinterf/AviSynthPlus/releases) (use version with vc_redist when installing for the first time)
Sources: https://github.com/pinterf/AviSynthPlus]
[END MODERATOR EDIT]

[pinterf]

I still have to work on the documentation. Unfortunately the bundled one generated from the rst files is hopelessly behind the actual changes which was done in Avisynth+. At least the content in avisynth.nl is more or less correct and up-to-date, but the latest changes I have made since december 2018, which appeared in 3.4.0, so there changes and additions are not refreshed there. E.g. the new Layer syntax and parameters.

[Atak_Snajpera]

Can somebody upload AviSynthPlus_3.4.0_Portable.7z somewhere outside those terrible github servers? I can't even download it. It just stops at random point.
https://i.postimg.cc/BQ68vwnS/Untitled-1.png

[LigH]

Interesting. I had similar issues with AdoptOpenJDK. But github releases are hosted in the Amazon cloud, they can push. If it doesn't go through, maybe your ISP throttles to blackmail Amazon to pay for better throughput? At least that's what they thought about Deutsche Telekom (https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-552195893).

So, for statistics: What's your route?

And try to download at a different daytime. Late night in US / early morning in EU still got me 2 MB/s when they throttled. Then, another day, the throttling was not active, and I got 8 MB/s in the early EU evening which used to be the worst time with throttling.

[Atak_Snajpera]

Interesting. I had similar issues with AdoptOpenJDK. But github releases are hosted in the Amazon cloud, they can push. If it doesn't go through, maybe your ISP throttles to blackmail Amazon to pay for better throughput? At least that's what they thought about Deutsche Telekom (https://github.com/AdoptOpenJDK/openjdk-build/issues/1349#issuecomment-552195893).

So, for statistics: What's your route?

And try to download at a different daytime. Late night in US / early morning in EU still got me 2 MB/s when they throttled. Then, another day, the throttling was not active, and I got 8 MB/s in the early EU evening which used to be the worst time with throttling.

You might be right because downloading through my smartphone using LTE works super fast. If I switch to my wi-fi and use my cable ISP then everything just stops. I have no issues with other servers. Just that bloody github...

[real.finder]

happen to me also but you have to download them one by one to give all speed to only one since there are no Resume-able Downloads, and also you can try JDownloader which can Resume Downloads in most cases

[Atak_Snajpera]

Next attempt... aaaaaaaaaand it stopped!
https://i.postimg.cc/G2DJhFvQ/Untitled-1.png
I almost feel like in 99 when I had that 56k modem...

[StainlessS]

I've uploaded a plain 7z portable for 3.4.0 (well, technically, r2925 built from master, but the extra commit* only touched the READMEs, it's still otherwise-identical to 3.4). I also removed the GCC archive since videohelp still was (or, is at this time of writing) pointing at it as a 'portable' even when that was not the intention.

*the other's just the merge commit for that one change

VideoHelp is actually providing a zip file GCC version as portable version, here [DO NOT DOWNLOAD Portable version]:- https://www.videohelp.com/software/AviSynth-Plus

I reported the post with this message (limited in length), so hopefully it will be removed as an option from the VH post.
Link to AviSynth+ 3.4.0 Portable, NOT portable version, is GCC compiled version & cause major probs for most users.
The target zip has been removed/moved on github because videohelp pointing to it but you provide the actual zip so still a prob.

EDIT: Damn, I also just posted this post as a review in VH thread, unfortunately different bulletin board type code required, and it swallowed some of the quote,
ie the message I reported, and I cannot edit it. :(

[LigH]

@Atak_Snajpera: Your ISP is to be blamed here, or the one which controls a backbone yours depends on. Further down in your route, on a regional or national range. So complain to your ISP, and register issues in public issue portals. Also notify github about it, but remember, they don't take the blame.

[StainlessS]

VideoHelp is actually providing a zip file GCC version as portable version

I reported the post with this message (limited in length), so hopefully it will be removed as an option from the VH post.
Link to AviSynth+ 3.4.0 Portable, NOT portable version, is GCC compiled version & cause major probs for most users.
The target zip has been removed/moved on github because videohelp pointing to it but you provide the actual zip so still a prob.

Just checked, VideoHelp now hosting current AviSynth+ 3.4.0 Portable 7z file. [SHA-1 matches that on Github].

[jpsdr]

Tested with VDub2 (x86 & x64) 43943 and avs 3.40.
This works :

a0=colorbars(width=1920,height=1080,pixel_type="yv12").trim(0,9).ConvertBits(16).ConverttoYUV444()
a1=a0
StackVertical(a0,a1)
ConvertBits(8)

this doesn't :

a0=colorbars(width=1920,height=1080,pixel_type="yv12").trim(0,9).ConvertBits(16).ConverttoYUV444()
a1=a0
StackVertical(a0,a1)
#ConvertBits(8)

[StainlessS]

BITS=10
colorbars(pixel_type="YV12")
ConvertBits(BITS)
ConverttoYUV444 # When loaded in VD2, Bits 10,12,14,16 YUV444, Access Violation in Avisynth
StackVertical(Last,Last)
#ConvertBits(8) # OK


https://i.postimg.cc/FYT8NJQT/Untitled-01.jpg (https://postimg.cc/FYT8NJQT)

EDIT: Play OK in PotPlayer, but avisynth access violation when loaded into Vd2.
When 8 bit, or not converted to 444, then OK loaded in Vd2.

EDIT: Same

BITS=10
colorbars(pixel_type="YV24")
ConvertBits(BITS)
#ConvertBits(8) # OK

[pinterf]

Checking. Something wrong happens in my YUV444Y16 to Y416 conversion which is used when feeding vdub with this format.

EDIT: fixed in my repo, there are other things under work, PM if a build is needed for someone with this fix. (no immediate release yet).

[wonkey_monkey]

Here's my latest terrible/brilliant idea for AviSynth:

I write a lot of complicated scripts, and possibly the biggest hindrance is the fact that AviSynth doesn't automatically parse multi-line statements. I would absolutely love it if AviSynth had an alternative parsing mode (triggered by a first-line comment or something, like a shebang in a Bash script) where statements had to be ended with a semi-colon (;), like C, PHP, Javascript etc, to avoid needing backslashes to write multi-line statements. It'd make commenting out lines in the middle of statements simpler, too.

Anyway, on the basis that if you don't ask you won't get, that is my ask :) More of a suggestion, really, that it may percolate inside pinterf's brain until one fateful day when it leaks out into the code.

[StainlessS]

If the choices are "brilliant" or "terrible", I'll go with terrible.
Would be 100.0% for sure non backwards compatible, lots of exciting new bugs to contend with, and not really necessary.

Dont string gazillions of oop style whatsits together [just because you can, dont make it a good idea].
Suggest break your complicated lines into multiple lines, perhaps assigning temp value to temp variable, then can comment out entire lines.

EDIT: You might like to string lots of oop stuff together when all debugged and stuff, but whilst developing better to have separate lines of code.
In runtime code [eg scriptclip] separate lines may be a little slower [due to temp vars or implicit Last], but in non runtime, then should
have only small consequence [milliseconds] prior to first frame delivered [ie during graph building].

EDIT: By the way, VDub2 has multiline comment/uncomment, cant say I've ever used it. [CTRL/ALT/SHFT/C --- CTRL/ALT/SHFT/U]

[wonkey_monkey]

It'd be backwards compatible if it's only enabled by a specific string at the start of the script, e.g. #!multiline or something equally unlikely.

I was thinking more of individual calls with many parameters, which can't be broken up, but assigning to temp variables again and again for long strings of calls seems equally messy to me.

How much neater to be able to write like this and quickly comment out/rejoin single lines without having to worry about all the backslahes (which, I'd argue, only make it harder to read):


processed = source.
qtgmc.
flipvertical.
filter_with_many_parameters(
10,
20,
"mode", # you can even put a comment here if you want to
reverse = true
).
trim(50, 99).
selecteven;

[StainlessS]

source
qtgmc
flipvertical
filter_with_many_parameters(
\ 10,
\ 20,
\ "mode", [* you can even put a comment here if you want to *]
\ reverse = true
\ )
trim(50, 99)
selecteven
processed=Last # Or processed=selecteven




OK, but there are many issues of greater importance, leave this for when dev has a couple of weeks spare, nuttin' to do, and is a bit bored.

EDIT:
Further to above,
I get the impression that some apps parse the Avs script [at least to some degree], and if so then changes might break lots of apps,
not sure the devs of those apps would be over-the-moon bout it, eg AvsPMod, PotPlayer, VD2 ++.
[Maybe I is totally wrong]

[wonkey_monkey]

Bug report: it seems that the standard resizers (spline16, bicubic, and bilinear, at least) don't process the alpha planes of YUVA clips.

Reduceby2 does, though.

Edit: also, not a bug report as such, but addborders really should have the option not to convert the background to TV Range when adding borders to a YUV clip. Maybe it could be updated to adopt the color_yuv parameter of blankclip?

[pinterf]

I've added them as issues in order not to forget them
https://github.com/pinterf/AviSynthPlus/issues/43 and
https://github.com/pinterf/AviSynthPlus/issues/44

[wonkey_monkey]

Thanks pinterf.

[StainlessS]

This seems not to be true:- http://avisynth.nl/index.php/Layer
int level = (maximum)

The strength of the performed operation:

0 – no effect: base_clip is returned unchanged
257 (256 for YUY2) – maximum strength

AVS+ autoscaled – works without changes at all bit depths.

ie MAX at 8 bit RGB requires eg 257, $101, at 16 bit req 65537, $10001.


Question, how do you add the secret Opacity arg to Layer ? [AddFunction]
It dont seem to exist in the code.

extern const AVSFunction Layer_filters[] = {
{ "Mask", BUILTIN_FUNC_PREFIX, "cc", Mask::Create }, // clip, mask
{ "ColorKeyMask", BUILTIN_FUNC_PREFIX, "ci[]i[]i[]i", ColorKeyMask::Create }, // clip, color, tolerance[B, toleranceG, toleranceR]
{ "ResetMask", BUILTIN_FUNC_PREFIX, "c[mask]f", ResetMask::Create },
{ "Invert", BUILTIN_FUNC_PREFIX, "c[channels]s", Invert::Create },
{ "ShowAlpha", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)3 }, // AVS+ also for YUVA, PRGBA
{ "ShowRed", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)2 },
{ "ShowGreen", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)1 },
{ "ShowBlue", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)0 },
{ "ShowY", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)4 }, // AVS+
{ "ShowU", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)5 }, // AVS+
{ "ShowV", BUILTIN_FUNC_PREFIX, "c[pixel_type]s", ShowChannel::Create, (void*)6 }, // AVS+
{ "MergeRGB", BUILTIN_FUNC_PREFIX, "ccc[pixel_type]s", MergeRGB::Create, (void*)0 },
{ "MergeARGB", BUILTIN_FUNC_PREFIX, "cccc", MergeRGB::Create, (void*)1 },
{ "Layer", BUILTIN_FUNC_PREFIX, "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b", Layer::Create },
/**
* Layer(clip, overlayclip, operation, amount, xpos, ypos, [threshold=0], [use_chroma=true])
**/
{ "Subtract", BUILTIN_FUNC_PREFIX, "cc", Subtract::Create },
{ NULL }
};


Any chance that there could be a means of accessing the multiple alternative plugin Parameter Lists ?
"$PluginFunctions$" or "$InternalFunctions$" extract same function name multiple times [for eg AssumeFPS] where multiple alternatvie parameter lists, but can
only extract a single parameter list for any one function name.
Need some way to 'get at' parameter lists using "$Plugin!" + "function name" + "!Param$".
Any chance ?

EDIT: Here v3.4.0 Layer param list with secret Opacity arg [and placement] :)
Layer "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b[opacity]f[placement]s"

[pinterf]

This seems not to be true:- http://avisynth.nl/index.php/Layer

You are right, not true.


Question, how do you add the secret Opacity arg to Layer ? [AddFunction]
It dont seem to exist in the code.

It exists

{ "Layer", BUILTIN_FUNC_PREFIX, "cc[op]s[level]i[x]i[y]i[threshold]i[use_chroma]b[opacity]f[placement]s", Layer::Create },

You have to check the master branch.
Either at my repo or the central avs+ repo (which is now a bit behind my repo, since I have some open work on my side)

I have to edit Layer wiki pages.

[pinterf]

O.K. here are the changes of 3.4 since my last public 2772 release

20191127 (dev 3.4.?)
--------------------------
- Fix: crash when outputting VfW (e.g. VirtualDub) for YUV444P16, other fixes for r210 and R10k formats
- WavSource: really use "utf8" parameter, fix some debug asserts
- TimeStrech: pass internal errors as Avisynth exception text (e.g. proper "Excessive sample rate!" instead of "unhandled C++ error")

20191021 3.4.0
--------------

- Merges in the MT branch, the current state of pinterf/MT, and packaging fixes
- Development HEAD is the master repo again in https://github.com/AviSynth/AviSynthPlus
- Bumps version to 3.4

20190829 r2915
--------------
- Changed: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop are using frame cache again (similar to classic Avs 2.6)
- Enhanced: Expr: faster exp, log, pow for AVX2 (sekrit-twc)
- ConditionalReader: allow empty value in text file when TYPE string
- Fix: Expr: fix non-mod-8 issues for forced RGB output and YUV inputs
- New: AviSource support v308 and v408 format (packed 8 bit 444 and 4444)
- Fix: AviSource v410 source garbage (YUV444P10)
- Fix: Expr: when using parameter "scale_inputs" and the source bit depth conversion occured, predefined constants
(ymin/max, cmin/max, range_min/max/half) would not follow the new bit depth
- Fix: ConvertToRGB from 32bit float YUV w/ full scale matrixes (pc.601, pc.709, average)
- Fix: FlipHorizontal RGB48/64 artifacts
- Enhanced: a bit quicker FlipHorizontal
- Fix: RGB64 Blur leftmost column artifact
- Enhanced: quicker RGB24/48 to Planar RGB for AVX2 capable processors
- Fix: Strip alpha channel when origin is YUVA and using ConvertToYV12/ConvertToYV16/ConvertToYV24 funtions
- Fix: garbage with ConvertToYUY2 from 8 bit YUVA colorspaces
- Enhanced: Colorbars to accept RGB24, RGB48, YV411 and 4:2:2 formats for pixel_type (now all colorspaces are supported)
- Fix: shifted chroma in ColorBars and ColorBarsHD for YUV444PS
- Fix: ConvertToY8, ConvertToYV12, ConvertToYV16, ConvertToYV24 are now allowed only for 8 bit inputs.
Formerly these functions were allowed for 10+ bit colorspaces but were not converted to real 8 bit Y8/YV12/16/24.
Use ConvertToY, ConvertToYUV420, ConvertToYUV422, ConvertToYUV444 instead which are bit depth independent
- New parameter in ColorYUV, RGBAdjust, Overlay, ConditionalReader: string "condvarsuffix"
Allows multiple filter instances to use differently named conditional parameters.
- Fix: ColorBars: pixel_type planar RGB will set alpha to 0 instead of 255, consistent with RGB32 Alpha channel
- Fix: text colors for YUV422PS - regression since r2728 (zero-centered chroma)
- New: VirtualDub2 to display 8 bit planar RGB (needs up-to-date VirtualDub2 as well)
VfW interface to negotiate 8 bit Planar RGB(A) with FourCCs: G3[0][8] and G4[0][8], similar to the 10-16 bit logic
- Fix: planar RGBA Alpha on VfW was uninitialized because it wasn't filled.
- Layer: big update
- Support for all 8-32 bit Y and planar YUV/YUVA and planar RGB/RGBA formats
- New parameter: float "opacity" (0.0 .. 1.0) optionally replaces the previous "level". Similar to "opacity" in "Overlay"
- 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
- Avisynth C interface header (avisynth_c.h):
- cosmetics: functions regrouped to mix less AVSC_API and AVSC_INLINE, put together Avisynth+ specific stuff
- cosmetics: remove unused form of avs_get_rowsize and avs_get_height (kept earlier for reference)
- use #ifndef AVSC_NO_DECLSPEC for AVSC_INLINE functions which are calling API functions
- define alias AVS_FRAME_ALIGN as FRAME_ALIGN (keep the AVS_xxxx naming convention)
- dynamic loader (avs_load_library) uses fallback mechanism for non-existant Avisynth+ specific functions, functions are usable for classic avisynth
- filter "Version": update year, removed avs-plus.net link
- Updated: TimeStretch plugin with SoundTouch 2.1.3 (as of 07.Jan 2019)
- Source/Build system
- rst documentation update (qyot27) in distrib\docs\english\source\avisynthdoc\contributing\compiling_avsplus.rst
- GCC-MinGW build, GCC 8.3 support
- CMake: Visual Studio 2019 generator support
- Clang (LLVM) support

[StainlessS]

Thanks P, was driving me nuts trying to find it in the v3.4.0 posted source.

EDIT:
filter "Version": update year, removed avs-plus.net link
Gonna need update year again soooon.

[pinterf]

Specifically for Layer:
See on github "distrib" folder: readme.txt and readme_history.txt (latter is a bit more verbose)
- Layer: big update
Previously Layer was working only for RGB32 and YUY2. Overlay was used primarily for YUV. Now Layer accepts 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 fiddle with it like had to 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)

[Atak_Snajpera]

I have a question about multithreading. Why avisynth plus does not support tiled based Mt like old avisynth.
If i'm not mistaken there was a MT function which was dividing frame in tiles and each tile was processed simultanously.

[pinterf]

I'm not aware that classic avisynth did such things. It's like what avstp used for mvtools and like jpsdr's _MT resizer and other plugin variants work.

[Atak_Snajpera]

I'm not aware that classic avisynth did such things. It's like what avstp used for mvtools and like jpsdr's _MT resizer and other plugin variants work.

I mean this http://avisynth.nl/index.php/MT

[pinterf]

Meanwhile Layer wiki is updated. I hope I included everything I have done with this filter.
http://avisynth.nl/index.php/Layer#Layer

[real.finder]

I have a question about multithreading. Why avisynth plus does not support tiled based Mt like old avisynth.
If i'm not mistaken there was a MT function which was dividing frame in tiles and each tile was processed simultanously.

cuz avs+ mt base on SEt changes, which see dividing frame for mt is bad idea, avstp and jpsdr's _MT in other hand did same thing as pinterf said but better and work in any avs, there are other method for MT that used in sorathread and ThreadRequest (https://forum.doom9.org/showthread.php?t=169714) but IIRC it's not work with avs+ well

[StainlessS]

All looks good to me, thanks muchly P.

[pinterf]

Bug report: it seems that the standard resizers (spline16, bicubic, and bilinear, at least) don't process the alpha planes of YUVA clips.

Fixed in source, available on my repo, no release yet.

(@jpsdr, this fix probably affects your _MT resizer versions because they are using this source)

[dREV]

Hi, I briefly wanted to ask about SetFilterMTMode("",) + Prefetch(1) if this is still relevant or not reading the previous earlier threads about this but wasn't sure if this has changed or not and if it is still relevant if this is linked with the amount of RAM one has on their PC which I only got 8 gigs or and the amount of (weak and heavy) filters in the chain.

It crashes when I go Prefetch(2) and I'm also on a Ryzen 5 2nd generation 2600 CPU if that helps.

[StainlessS]

I cant answer this, but you might want to provide a little more info for those that can.

Your script, & is it x86 or x64 Avs+.

[LigH]

Especially if you try to multi-thread QTGMC, be aware that it first will use as many EDI threads as cores, so using a higher prefetch value will multiply their threads even further; you may want to restrict that parameter in QTGMC when you have a CPU with many logical cores.

[jpsdr]

(@jpsdr, this fix probably affects your _MT resizer versions because they are using this source)

Thanks for the warning, i've checked, but in fact my getframe is very different, and i allready processed the alpha planes.

[StainlessS]

also, not a bug report as such, but addborders really should have the option not to convert the background to TV Range when adding borders to a YUV clip. Maybe it could be updated to adopt the color_yuv parameter of blankclip?

I've added them as issues in order not to forget them


Same for Letterbox too please P. [long time I've been a bit miffed with both Addborders and Letterbox for TV range only borders]

[wonkey_monkey]

Suppose I have two scripts, one of which imports the other. The first script gets a source:

source = AviSource("myfile.avi")

The second file returns a clip based on this source, but I'd also like the second file to be openable stand by itself. Is there a way to call AviSource and assign the the result to source at the top of the second file, but only if source has not already been defined? I tried VarExist like this:

source = VarExist(source) ? source : avisource("myfile.avi")

But I just get errors.

[StainlessS]

Maybe try [quotes around source in VarExist]

source = VarExist("source") ? source : avisource("myfile.avi")

[wonkey_monkey]

Ah, of course, that makes sense. Thanks.

[dREV]

I cant answer this, but you might want to provide a little more info for those that can.

Your script, & is it x86 or x64 Avs+.

Alright, for those that can answer

It's AviSynth+ 0.1.0 r2772 using the 32 bit version with the 10 bit hack pipeline for HEVC in MeGUI 2525.

Script plugins and import address
#rgtools
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode("clense", MT_NICE_FILTER)

#medianblur
SetFilterMTMode("medianblur", MT_MULTI_INSTANCE)
SetFilterMTMode("medianblurtemporal", MT_MULTI_INSTANCE)
SetFilterMTMode("average", MT_NICE_FILTER)
SetFilterMTMode("TMaskCleaner", MT_MULTI_INSTANCE)
SetFilterMTMode("checkmate", MT_NICE_FILTER)
SetFilterMTMode("Deblock", MT_NICE_FILTER)
SetFilterMTMode("msharpen", MT_MULTI_INSTANCE)
SetFilterMTMode("TColorMask", MT_NICE_FILTER)
SetFilterMTMode("Vinverse", MT_MULTI_INSTANCE)
SetFilterMTMode("Vinverse2", MT_MULTI_INSTANCE)

#masktools
SetFilterMTMode("mt_invert", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_binarize", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_inflate", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_deflate", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_inpand", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_expand", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lut", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutxy", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutxyz", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutf", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutsx", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_lutspa", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_merge", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_logic", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_convolution", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_mappedblur", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_makediff", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_average", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_adddiff", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_clamp", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_motion", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_edge", MT_MULTI_INSTANCE)
SetFilterMTMode("mt_hysteresis", MT_MULTI_INSTANCE)
SetFilterMTMode("AddGrainC", MT_MULTI_INSTANCE)

# Source plugins
SetFilterMTMode("DGDecode_mpeg2source",MT_NICE_FILTER) #seems to work fine as 1
SetFilterMTMode("TFM", MT_MULTI_INSTANCE) #2 is faster. 1 crashes randomly.
SetFilterMTMode("TDecimate", MT_SERIALIZED) #1 gave error, 2 was slower than 3
SetFilterMTMode("TDeint", MT_MULTI_INSTANCE) # Mode 1 creates artifacts
SetFilterMTMode("SmoothLevels", MT_MULTI_INSTANCE) # Mode 1 freezes

# Filters from Dither 1.25.0. Tested by Firesledge (not extensively though)
SetFilterMTMode ("DitherPost", MT_NICE_FILTER)
SetFilterMTMode ("SmoothGrad", MT_NICE_FILTER)
SetFilterMTMode ("Dither_box_filter16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_bilateral16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_limit_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_resize16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_out", MT_NICE_FILTER)
SetFilterMTMode ("Dither_removegrain16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_repair16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_median16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_add16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_sub16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_max_dif16", MT_NICE_FILTER)
SetFilterMTMode ("Dither_merge16", MT_NICE_FILTER)
SetFilterMTMode("NNEDI3", MT_MULTI_INSTANCE)

SetFilterMTMode("FTurnLeft", MT_NICE_FILTER)
SetFilterMTMode("FTurnRight", MT_NICE_FILTER)

SetFilterMTMode("yadifmod", MT_NICE_FILTER)
SetFilterMTMode("ContinuityFixer", MT_NICE_FILTER)

ConvertBits(bits=8)

#filter varies here, crop, continuityfix

dither_convert_8_to_16()
#deband filter with mask=0 banding, only when no choice
f3kdbmod16()
s16 = last
DitherPost()

ConvertBits(bits=8)
FTurnRight()
##line darkening (Hysteria) filter sometimes here - 8 bit?
#Anti-Aliasing filter, maa2 usually - 8 bit?
FTurnLeft()

dither_convert_8_to_16()
s16.Dither_limit_dif16 (last, thr=0.25, elast=4.0)
SmoothGrad()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=6)

ConvertBits(bits=16)
ConvertToStacked()
#grain filter
ConvertFromStacked().ConvertToDoubleWidth()

Prefetch(1)

Not sure if needed but some HEVC settings are sea, qcomp ranges from 60 to 80, veryslow speed, rc lookahead 40 and tune animation (majority of times then film) rest are almost max or max settings and a couple turned off like no sao, no amp, --no-strong-intra-smoothing, limit-refs=0, --no-limit-modes, and has both --fades and -dither

I've also tried it using the 64 bit version with filters and did not see much difference tho I only did a few tests.

Not sure why but when I use real.finder's maa2 anti-aliasing script https://forum.doom9.org/showthread.php?t=174121 when indexing the source it doesn't like each other and tend to get Access Violation. I have to use the script as Prefetch(0) to go thru then I have to edit the script back to Prefetch(1) to encode in MeGUI. Using older versions doesn't do this. If somebody can inform me on why this maybe occurring.

Especially if you try to multi-thread QTGMC, be aware that it first will use as many EDI threads as cores, so using a higher prefetch value will multiply their threads even further; you may want to restrict that parameter in QTGMC when you have a CPU with many logical cores.

OK, I haven't tried using that yet but I will keep your words down and note it on the read me file for that filter. Thanks for the info. :thanks:

[pinterf]

Same for Letterbox too please P. [long time I've been a bit miffed with both Addborders and Letterbox for TV range only borders]
New parameter color_yuv is done for AddBorders and LetterBox. Works exactly like in BlankClip.

[StainlessS]

New parameter color_yuv is done
Splendid :)

[StainlessS]

Wonkey,


processed = source.
qtgmc.
flipvertical.
filter_with_many_parameters(
10,
20,
"mode", # you can even put a comment here if you want to
reverse = true
).
trim(50, 99).
selecteven;


Just a bit of nit-pickin',
above script would not work in Avs [you is mixin' avs script and C].

[wonkey_monkey]

Wonkey,


Just a bit of nit-pickin',
above script would not work in Avs [you is mixin' avs script and C].

That was the point of my post - suggesting an alternate format that's more amenable to multi-lining.

[StainlessS]

I was suggesting that the trailing semi-colon would prevent it from working at full capacity, or at all :)
[even with auto appended lines]
EDIT: perhaps the semi-colon was deliberate ?, to show where appended lines thing is force ended, is that it ?

[wonkey_monkey]

Exactly, like C/C++.

[StainlessS]

So, guess that if implemented as suggested, then to avoid massive parsing, we will have to have statement terminators like everywhere, all of the time,
is that the suggestion ? (henceforth all avs script needs statement terminators, tis a change that might prevent adoption, do you have any other ideas ?).

[FranceBB]

Alright, for those that can answer

It's AviSynth+ 0.1.0 r2772 using the 32 bit version with the 10 bit hack pipeline for HEVC in MeGUI 2525.

Not related to the Access Violation, but to the quality instead.
You are bringing everything to 16bit stacked, filtering with f3kdb with 16bit precision, then you are using DitherPost as default to bring everything to 8bit to filter with maa2, lastly you're using DitherPost(mode=6) which is dithering with the Floyd Steinberg error diffusion, then you're converting it again from 8bit dithered to 16bit planar, then you're bringing it to stacked MSB and LSB again, you apply your denoise and then you convert from 16bit stacked to 16bit interleaved and you output it as interleaved.

Why?


Doesn't this make more sense?


#Here we're telling f3kdb to take your 8bit source, filter it with 16bit precision and output 16bit stacked

#Debanding 16bit stacked

f3kdb(input_depth=8, output_mode=1, output_depth=16)

#Now we're gonna truncate everything to 8bit,
#apply anti-aliasing with maa2 and then use the original 16bit stacked we received from f3kdb
#and apply only the changes made by maa2 thus retaining 16bit precision

#antialiasing 8bit, 16bit stacked output
s16 = last
DitherPost (mode=-1)
maa2()
Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

#16bit stacked resize and debanding

ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)


#your 16bit stacked degrain filter

Something()

#16bit planar output (your target is x265 which will handle 16bit planar just fine; just remember to add --dither to the command line)

ConvertFromStacked()

[wonkey_monkey]

So, guess that if implemented as suggested, then to avoid massive parsing, we will have to have statement terminators like everywhere, all of the time,
is that the suggestion ? (henceforth all avs script needs statement terminators

Only those that start with the magic code to switch to the alternative parsing.

[LigH]

In Pascal it's exactly the opposite syntax: Semicola closing each line, a dot finishing "the sentence" (the program).