AviSynth+ thread Vol.2

[wonkey_monkey]

On the page for Invoke, it says:

env->Invoke does not automatically insert a cache after the filter you invoke. That means that each time you request a frame (using GetFrame) from the invoked filter the filter will need to generate the frame.

Can I rely on this remaining true in future versions? Or can it force it to be so (guaranteed no caching) with SetCacheHints?

Edit: actually the above quote doesn't seem to be true now. I tried Invoking a debugging filter and I can see that it stops being called if I keep requesting the same frames. And SetCacheHints now seems to do nothing?

int __stdcall SetCacheHints(int cachehints, int frame_range) { AVS_UNUSED(cachehints); AVS_UNUSED(frame_range); return 0; };

So I guess my question should just be... can I completely disable caching on an Invoke-generated clip?

[Reel.Deel]

Why does ConvertBits() shift the U/V planes from 0 to 1 in the script below? I thought setting fulls/fulld to true when working with full range would keep the pixel values unchanged. When I set fulls/fulld to false, the shift does not happen :confused:.

Blankclip(width=7, height=12, pixel_type="RGB32", colors=[0,0,0,0], length=1)
Text("T", size=12, text_color=$ffffff, halo_color=$000000, x=1)
ExtractR()
YToUV(last, last, last)
fulls = true
ConvertBits(last, 16, fulls=fulls, fulld=fulls)
ConvertBits(last, 8, fulls=fulls, fulld=fulls)
ExtractU()
Pixelscope()

https://i.ibb.co/ZYh9Ld6/convertbug-maybe.png

[wonkey_monkey]

Someone uses Pixelscope! Yay! :cool:

I must get around to updating for all bit depths one day.

[Reel.Deel]

Someone uses Pixelscope! Yay! :cool:

I must get around to updating for all bit depths one day.

I actually wanted to ask you about that. I wanted to use it after converting to 16-bit to see the values but forgot is limited to 8-bit.

I would also use your Polygon filter if it were available in 64-bit :sly:.

[StainlessS]

I on occasion use PixelScope.

[Emulgator]

Pixelscope HBD: yes, please !

[gispos]

My mistake?

ColorBarsHD(width=1280, height=720, pixel_type="YV24")
ConvertBits(16)
ConvertToRGB64()

Returns other pixel values than

ColorBarsHD(width=1280, height=720, pixel_type="YV24")
ConvertToRGB64()

Had tried to compare pixel values of Planar RGB 16bit with Packet RGB 16bit and I'm almost desperate that I always got different values.

This then brought success (both the same pixel values)

ColorBarsHD(width=1280, height=720, pixel_type="YV24")
ConvertBits(bits=16)
ConvertToPlanarRGB()

ColorBarsHD(width=1280, height=720, pixel_type="YV24")
ConvertBits(16)
ConvertToRGB64()

Or would I have had to set parameters with ConvertBits?

[DTL]

YUV 8bit to RGB 16bit is 2 conversions: YUV->RGB and 8bit->16bit.

8bit->16bit integer is lossless adding 8 zeroes to 8bit data. YUV->RGB is not lossless math. So with 8bit YUV input ConvertToRGB64() can firstly convert to RGB in 8bit and secondly add 8 zeroes to RGB. With ConvertBits(16) before RGB it explicitly command first add 8 zeroes to YUV and convert 16bit YUV->RGB.

So it mostly probably shows as 8bit and 16bit YUV->RGB gives different results.

Yes - for better results it recommended to convert YUV->RGB in 16bits. It gives less errors (less banding on gradients). So if ConvertToRGB64() with 8bit YUV input makes first conversion to RGB in 8bit it may be an issue to fix. As current workaround - add ConvertBits(16) before ConvertToRGB().

[gispos]

So if ConvertToRGB64() with 8bit YUV input makes first conversion to RGB in 8bit it may be an issue to fix. As current workaround - add ConvertBits(16) before ConvertToRGB().
But still, one should think that there should be no difference 16bit is 16bit. It made me despair for 2 evenings.

You never stop learning.;)

[DTL]

The Convert* functions have 'hidden first argument' for easy of use so it is really 2 different processings:
ConvertYUV8toRGB64() and ConvertYUV16toRGB64().

Wiki says for ColorBarsHD - http://avisynth.nl/index.php/ColorBars

AVS+ "YV24" or other 4:4:4 format.

May be try YUV444P16 ? May be it can output RGB48/RGB64 directly ?

[pinterf]

Why does ConvertBits() shift the U/V planes from 0 to 1 in the script below? I thought setting fulls/fulld to true when working with full range would keep the pixel values unchanged. When I set fulls/fulld to false, the shift does not happen :confused:.

Chroma full scale has valid values from 1 to 255.

U and V chroma are signed values and one would treat them as such in operations, even when stuffed into a 8 bit container.

16-240 means +/-112 with a bias of 128.

During calculations one must subtract the bias to have zero centered values, do the operation and convert it back by adding the bias.

For consistent full scale chroma operations we chose the available maximum symmetrical boundaries; +/-112 is scaled to +/-127.

With bias 128 it turnes into 128+/-127, that is 1-255. 0 is an invalid value there.

Same applies to other integer bit depths as well: for 16 bit 32768 +/- 32767 is the valid range.

[pinterf]

On the page for Invoke, it says:



Can I rely on this remaining true in future versions? Or can it force it to be so (guaranteed no caching) with SetCacheHints?

Edit: actually the above quote doesn't seem to be true now. I tried Invoking a debugging filter and I can see that it stops being called if I keep requesting the same frames. And SetCacheHints now seems to do nothing?

int __stdcall SetCacheHints(int cachehints, int frame_range) { AVS_UNUSED(cachehints); AVS_UNUSED(frame_range); return 0; };

So I guess my question should just be... can I completely disable caching on an Invoke-generated clip?
I remember a commit from recent years.
EDIT: yes, it appeared in commit e79f82be (https://github.com/AviSynth/AviSynthPlus/commit/e79f82be5bad10f6b5974480d177ef18ae8ae8aa) the modification is here (https://github.com/AviSynth/AviSynthPlus/commit/e79f82be5bad10f6b5974480d177ef18ae8ae8aa#diff-f8057bae068be1f19fd7f1e2349931996b7989b45426a049ace0883a429bd32aR3285) after cherrypicking from Neo branch, here it is still commented out, then I made it live.

EDIT2:

Or you handle and return 1 on CACHE_DONT_CACHE_ME request, as in the Avisynth code below appears.

int __stdcall NonCachedGenericVideoFilter::SetCacheHints(int cachehints, int frame_range)
{
switch(cachehints)
{
case CACHE_DONT_CACHE_ME:
return 1;
case CACHE_GET_MTMODE:
return MT_NICE_FILTER;

case CACHE_GET_DEV_TYPE:
return (child->GetVersion() >= 5) ? child->SetCacheHints(CACHE_GET_DEV_TYPE, 0) : 0;

default:
return GenericVideoFilter::SetCacheHints(cachehints, frame_range);
}
}

[anton_foy]

XAVC should be interpreted as left type 0, but it's always nice to double check. Feel free to upload a sample. A landscape will do, although someone holding a colour palette would be better.

Here is a clip (30mb) of an IT8 color chart on the floor, it is jittery and shaky though but I did not find any other.
IT8 color chart clip (https://we.tl/t-83WtkIjgMZ)

[Wilbert]

I made some AviSynth+ threads here and in the usage forum sticky.

[StvG]

Chroma full scale has valid values from 1 to 255.

But zimg and fmtconv returns 0 in this example (meaning they have valid values from 0 to 255 for chroma full scale).

[Reel.Deel]

Chroma full scale has valid values from 1 to 255.

U and V chroma are signed values and one would treat them as such in operations, even when stuffed into a 8 bit container.

16-240 means +/-112 with a bias of 128.

During calculations one must subtract the bias to have zero centered values, do the operation and convert it back by adding the bias.

For consistent full scale chroma operations we chose the available maximum symmetrical boundaries; +/-112 is scaled to +/-127.

With bias 128 it turnes into 128+/-127, that is 1-255. 0 is an invalid value there.

Same applies to other integer bit depths as well: for 16 bit 32768 +/- 32767 is the valid range.

Thanks for the explanation pinterf. So how would one go about treating YUV masks that are expected to be [0,255]? For single plane masks there is no problem, but for YUV masks it does create a problem. I still don't understand why fulls/fulld = false does not cause the 0 to 1 shift.

But zimg and fmtconv returns 0 in this example (meaning they have valid values from 0 to 255 for chroma full scale).

Thanks for pointing that out. I had not checked their behavior.

[cretindesalpes]

For consistent full scale chroma operations we chose the available maximum symmetrical boundaries; +/-112 is scaled to +/-127.
ITU Rec H.273 specifies it slightly differently (for full range, eq. 30 p. 10):
Cb = Clip1_C ( Round( ( ( 1 << BitDepth_C ) − 1 ) * E′_PB ) + ( 1 << ( BitDepth_C − 1 ) ) )
Same thing with Cr. In 8 bits, chroma is scaled with a factor 255, meaning that -0.5 and +0.5 map to 0.5 and 255.5 respectively, before rounding and clipping. Of course this slightly truncates the chroma values which are very close to +0.5, but is this really a problem for real-world video signals? Full range already truncates ringing that naturally occurs with resizing or with other filtering operations.

[pinterf]

ITU Rec H.273 specifies it slightly differently (for full range, eq. 30 p. 10):
Cb = Clip1_C ( Round( ( ( 1 << BitDepth_C ) − 1 ) * E′_PB ) + ( 1 << ( BitDepth_C − 1 ) ) )
Same thing with Cr. In 8 bits, chroma is scaled with a factor 255, meaning that -0.5 and +0.5 map to 0.5 and 255.5 respectively, before rounding and clipping. Of course this slightly truncates the chroma values which are very close to +0.5, but is this really a problem for real-world video signals? Full range already truncates ringing that naturally occurs with resizing or with other filtering operations.
That means that instead of +/-127 (or +/-32767), it must be handled as 128+/-127.5 (or 32768 +/-32767.5) before it gets truncated back to 8 (16) bit range. Then the conversion must use factor of 112 / 127.5 (that is 224.0/255.0) instead of my present 112/127.

The formula which calculates the ratio in https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_helper.h#L180 and
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_helper.h#L183
must be corrected accordingly.
I don't know (did not calculate) whether it survives a cumulative full-limited conversion sequence throughout the range or on the extremes.

[qyot27]

The documentation in HTML-generated form is now live on Read The Docs:
https://avisynthplus.readthedocs.io/en/latest/

(the other branches are still generating)

[Balling]

That means that instead of +/-127 (or +/-32767), it must be handled as 128+/-127.5 (or 32768 +/-32767.5) before it gets truncated back to 8 (16) bit range. Then the conversion must use factor of 112 / 127.5 (that is 224.0/255.0) instead of my present 112/127.

The formula which calculates the ratio in https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_helper.h#L180 and
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_helper.h#L183
must be corrected accordingly.
I don't know (did not calculate) whether it survives a cumulative full-limited conversion sequence throughout the range or on the extremes.

Indeed we came with this insanity in chromium/chrome. But I think it only matters for 10 bit and more. Also see my comments https://bugs.chromium.org/p/chromium/issues/detail?id=1174638

and https://chromium-review.googlesource.com/c/chromium/src/+/2658149/3/ui/gfx/color_space.cc#1098

There is this merge request but it breaks too much stuff. https://chromium-review.googlesource.com/c/chromium/src/+/3077005/

[Balling]

Someone uses Pixelscope! Yay! :cool:

I must get around to updating for all bit depths one day.

Already works in YUView hex view. Sumsampled planes too and what not, up to 16 bits. It is frankly speacking nuts! The only way I know to show hex values on 10 bit! 10 bit YCbCr to 64 bit PNG is broken BTW in swscale, for example.

Big endian was recently added for rgb formats due to my request! Just chroma sample location and beter FIR chroma upsample is needed.

[Balling]

But zimg and fmtconv returns 0 in this example (meaning they have valid values from 0 to 255 for chroma full scale).

This is YCbCr. Black in full YCbCr is 0, 128, 128, okay? So Y can be 0, that is for sure. But chroma planes cannot MAYBE, because that is out of range for all values. Just like all 0, x, y where x=y= !128 is out-of-range. Seriously? See this comment in ffmpeg. https://github.com/FFmpeg/FFmpeg/blob/7247a6fed8de9c2162ed408682e095f0b7f19350/libavutil/pixfmt.h#L595

Frankly speaking I do not understood this either. You can still write it, only in limited range these values reserved for sync (0, 255). Even in limited range you can still write it in avc or hevc. Just change full range flag with -bsf hevc_metadata.

[cretindesalpes]

These conversion functions generally don’t check the range of pixel values, this is not their job. They process the planes more or less independently. Overshoots caused by various operations should not be clipped until the final filterchain output, if possible. Also dithering may make a constant signal oscillate between two values, or even more.

[Balling]

XAVC should be interpreted as left type 0, but it's always nice to double check. Feel free to upload a sample. A landscape will do, although someone holding a colour palette would be better.

x264 defaults to left if it is ommited. While x265 does not have a default, you should always tag it in VUI in bitstream.

[FranceBB]

x264 defaults to left if it is ommited. While x265 does not have a default, you should always tag it in VUI in bitstream.

We were talking about an hardware camera encoder, so not x264, but it defaulted to left (same goes for x264 indeed).
That being said, this case is closed as we realized that there's no difference between left and top left for 4:2:2 and that the ffmpeg/ffprobe guys wrote two different values that actually meant the same thing.
This went into "public vote" with Ferenc and the others and we all agreed that within Avisynth we won't care about what the indexer (LWLibav, LSMASH, ffms2 etc) report for 4:2:2 in terms of chroma placement, and we'll always assume it to be left to play safe. This way, the issue I highlighted is gonna disappear.

Ferenc will probably release 3.7.2 Test 2 soon with the fix.

Case closed. ;)

[Balling]

BTW, this should be really fixed. https://trac.ffmpeg.org/ticket/9167#comment:40

[Balling]

YUV 8bit to RGB 16bit is 2 conversions: YUV->RGB and 8bit->16bit.

8bit->16bit integer is lossless adding 8 zeroes to 8bit data. YUV->RGB is not lossless math. So with 8bit YUV input ConvertToRGB64() can firstly convert to RGB in 8bit and secondly add 8 zeroes to RGB. With ConvertBits(16) before RGB it explicitly command first add 8 zeroes to YUV and convert 16bit YUV->RGB.

So it mostly probably shows as 8bit and 16bit YUV->RGB gives different results.

Yes - for better results it recommended to convert YUV->RGB in 16bits. It gives less errors (less banding on gradients). So if ConvertToRGB64() with 8bit YUV input makes first conversion to RGB in 8bit it may be an issue to fix. As current workaround - add ConvertBits(16) before ConvertToRGB().

YUV -> RGB is less a problem than vice versa, since YUV is so much bigger and most of that is out-of-gamut for RGB and so is usually not present, be it 100 bits RGB cannot be preserved unless you will color manage it to bigger primaries. But yeah, you first add zeroes to original YCbCr values and then convert to RGB, that is what is called internal precision.

See my [accepted] answer for this here: https://stackoverflow.com/a/66926260/11173412

[Balling]

BTW, a lot of stuff from my pull request is still not addressed https://github.com/AviSynth/AviSynthPlus/pull/215 like this. https://github.com/AviSynth/AviSynthPlus/blob/1cb31ca82a1503b525809fff1ecc0816222555d0/avs_core/filters/source.cpp#L1065

[pinterf]

Avisynth+ 3.7.2 test 2 (20220201) (https://drive.google.com/uc?export=download&id=1QpctWEKU1Mg9O5AEyK41iQ4fIuJAbktc)

[Dogway]

Thanks pinterf! Could you take a look at this (https://forum.doom9.org/showthread.php?p=1960946#post1960946)? Not sure if that's to be expected but I run a few tests and got consistent performance readings.
Here's another example, again 2% with prefetch(4), with prefetch(6) performance is worse and inconsistent.
expr("x[-1,-1] x[0,-1] x[1,-1] x[-1,0] x[0,0] x[1,0] x[-1,1] x[0,1] x[1,1] + + + + + + + + 0.111111111 *") # P(6) ~360 P(4) 389
#expr("x[1,1] x[0,1] x[-1,1] x[1,0] x[0,0] x[-1,0] x[1,-1] x[0,-1] x[-1,-1] + + + + + + + + 0.111111111 *") # P(6) ~360 P(4) 381

[FranceBB]

Avisynth+ 3.7.2 test 2 (20220201) (https://drive.google.com/uc?export=download&id=1QpctWEKU1Mg9O5AEyK41iQ4fIuJAbktc)

Thanks Ferenc!
This is with the chroma location fix for 4:2:2 right?

[StainlessS]

Thanks P,

FaBB, in blue [think thats what U R talkin' bout.] In the zip, "readme_history.txt"

Avisynth Plus change log
------------------------
Source: https://github.com/AviSynth/AviSynthPlus

This file contains all change log, with detailed examples and explanations.
The "rst" version of the documentation just lists changes in brief.

20220201 3.7.2-WIP
------------------
- Allow top_left (2) and bottom_left (4) chroma placements for 422 in colorspace conversions, they act as "left" (0, "mpeg2")
in order not to give error with video sources which have _ChromaLocation set to other than "mpeg2"
See https://trac.ffmpeg.org/ticket/9598#comment:5
- Fix: Expr LUT operation Access Violation on x86 + AVX2 due to an unaligned internal buffer (<32 bytes)
- Fix: Chroma full scale as ITU Rec H.273 (e.g +/-127.5 and not +/-127) in internal converters, ColorYUV and Histogram
- Fix #257: regression in 3.7.1: GreyScale to not convert to limited range when input is RGB. Regression in 3.7.1
Accepts only matrix names of limited range as it is put in the documentation.
- Fix #256: ColorYUV(analyse=true) to not set _ColorRange property to "full" if input has no such
property and range cannot be 100% sure established. In general: when no _ColorRange for input and
no parameter which would rely on a supposed default (such as full range for gamma), then an
output frame property is not added.
When no _ColorRange for input and no other parameters to hint color range then
- gamma<>0 sets full range
- opt="coring" sets limited range
- otherwise no _ColorRange for output would be set
- Overlay (#255): "blend": using accurate formula using float calculation. 8 bit basic case is slower now when opacity=1.0.
Higher bit depths and opacity<1.0 cases are quicker.
Mask processing suffered from inaccuracy. For speed reasons mask value 0 to 255 were handled
as mask/256 instead of mask/255. Since with such calculation maximum value was not the expected 1.0 but rather 255/256 (0.996)
this case was specially treated as 1.0 to give Overlay proper results at least the the two extremes.
But for example applying mask=129 to pixel=255 resulted in result_pixel=128 instead of 129. This was valid on higher bit depths as well.
- Fix: Attempt to resolve deadlock when an Eval'd (Prefetch inside) Clip result is
used in Invoke which calls a filter with GetFrame in its constructor.
(AvsPMod use case which Invokes frame prop read / ConvertToRGB32 after having the AVS script evaluated)
Remark: problem emerged in 3.7.1test22 which is trying to read frame properties of the 0th frame in its constructor.
A similar deadlock situation was already fixed earlier in Neo branch and had been backported but it did not cover this use case.

[FranceBB]

Thanks P,

FaBB, in blue [think thats what U R talkin' bout.]

Allow top_left (2) and bottom_left (4) chroma placements for 422 in colorspace conversions, they act as "left" (0, "mpeg2")
in order not to give error with video sources which have _ChromaLocation set to other than "mpeg2"

Nice! I was on my mobile, I couldn't check.
Testing straight away now that I'm on my computer! :D

EDIT: It works. Well done, Ferenc! :D

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

https://i.imgur.com/kvjIY0b.png
https://i.imgur.com/fqTju1Y.png

[wonkey_monkey]

When I try to env->Invoke "import" on an .avs file that returns a clip with a depth other than 8-bit, it throws a ReturnExprException. I've got no idea what one of those is and can only find a couple of mentions of it in the AviSynth source code. I tried to include expression.h so ReturnExprException is defined but then that throws up other missing definitions...

I think I'm probably missing something here. Anyone got any guesses as to why an exception is being thrown - the file loads fine in VirtualDub2 - or how I'm supposed to catch the exception?

PS While I'm asking questions, is there a nice way to get the canonical colourspace name string for a clip?

[pinterf]

When I try to env->Invoke "import" on an .avs file that returns a clip with a depth other than 8-bit, it throws a ReturnExprException. I've got no idea what one of those is and can only find a couple of mentions of it in the AviSynth source code. I tried to include expression.h so ReturnExprException is defined but then that throws up other missing definitions...

I think I'm probably missing something here. Anyone got any guesses as to why an exception is being thrown - the file loads fine in VirtualDub2 - or how I'm supposed to catch the exception?

Check this part:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/main.cpp#L693

(I don't know though why you get ReturnExprException)


PS While I'm asking questions, is there a nice way to get the canonical colourspace name string for a clip?
function PixelType, parameter is a clip, returns a string.

[wonkey_monkey]

Thanks. I found my mistake - it seems that ReturnExprException is normal and handled properly during Invoke. My actual error was elsewhere, but I saw the ReturnExprExceptions in the debug output and assumed they were a problem.

[jpsdr]

If i run this kind of script :

Filter
Prefetch(2)


Filter is MT_NICE.
GetFrame can be called twice in parallel, but that's all ?
If in GetFrame i request "something" on the begining and release it at the end, i only need to have 2 of the "something" to never have a GetFrame waiting the "something" being avaible ?
Is there any reason that could result in the need of having 4 of the "something" instead of the 2 expected ?

[pinterf]

If i run this kind of script :

Filter
Prefetch(2)


Filter is MT_NICE.
GetFrame can be called twice in parallel, but that's all ?
If in GetFrame i request "something" on the begining and release it at the end, i only need to have 2 of the "something" to never have a GetFrame waiting the "something" being avaible ?
Is there any reason that could result in the need of having 4 of the "something" instead of the 2 expected ?
It can be called more than twice, the two occasion is only from Prefetch, but further GetFrames can occur at the same time, e.g. directly from the main consumer of the final clip. That's already 3. The the consumer can request directly another GetFrame through an additional Invoke (like AvsPMod does when obtaining frame properties on the evaluated clip with an additonal Invoke of ConvertToRgb - which in turn calls a GetFrame(0) in its constructor).
NICE filters must be fully reentrant and can theoretically be called arbitrary times in their specific invoke position.

[poisondeathray]

Thanks for fixing overlay mask accuracy issue
https://forum.doom9.org/showthread.php?t=183710


Some new issue with overlay opacity , 3.7.2 test 2 (r3620)

The value remains RGB 0,0,0 below opacity 0.5, and RGB 1,1,1 above opacity 0.5 . Opacity=0 and Opacity=1 gives correct result



b=blankclip(pixel_type="RGB24", colors=[0,0,0])
w=blankclip(pixel_type="RGB24", colors=[255,255,255])

overlay(b,w, opacity=0.5)



Reverting to 3.7.2 test 1 (r3600) fixes the overlay opacity parameter behaviour

I suspect it's this commit, but I don't know enough programming to narrow it down farther
https://github.com/AviSynth/AviSynthPlus/commit/ceae03c17b4095a7612dbbc7be864ca9ff0f872f

[pinterf]

Thanks for fixing overlay mask accuracy issue
https://forum.doom9.org/showthread.php?t=183710


Some new issue with overlay opacity , 3.7.2 test 2 (r3620)

The value remains RGB 0,0,0 below opacity 0.5, and RGB 1,1,1 above opacity 0.5 . Opacity=0 and Opacity=1 gives correct result



b=blankclip(pixel_type="RGB24", colors=[0,0,0])
w=blankclip(pixel_type="RGB24", colors=[255,255,255])

overlay(b,w, opacity=0.5)



Reverting to 3.7.2 test 1 (r3600) fixes the overlay opacity parameter behaviour

I suspect it's this commit, but I don't know enough programming to narrow it down farther
https://github.com/AviSynth/AviSynthPlus/commit/ceae03c17b4095a7612dbbc7be864ca9ff0f872f
Thanks for the report, fixed.

[pinterf]

Avisynth+ 3.7.2 test 3 (20220208) (https://drive.google.com/uc?export=download&id=1jyqttklu67ehTLnWlsHYHexMdbs2lfCq)
Fix Prefetch(1) + AvsPMod crash
Fix Overlay + blend + no mask (regression in 3.7.2 test 2)

[gispos]

Avisynth+ 3.7.2 test 3 (20220208) (https://drive.google.com/uc?export=download&id=1jyqttklu67ehTLnWlsHYHexMdbs2lfCq)
Fix Prefetch(1) + AvsPMod crash
Fix Overlay + blend + no mask (regression in 3.7.2 test 2)
Thank you!

Edit: Would it be easier (less problematic) if I waited 100 or 200 milliseconds between get_frame and get_properties?

[FranceBB]

Thanks Ferenc.
Every new release is always appreciated. :)

[StainlessS]

Yeah thanx P, Mucho Grassy Ass.

[tormento]

We f***ing need a Thank you button...

[pinterf]

Would it be easier (less problematic) if I waited 100 or 200 milliseconds between get_frame and get_properties?
No. It is expected to work without any timing magic. This was a hidden bug or issue on which nobody from earlier authors thought of and sooner or later there would be a similar use case by another plugin/application that would shed light on this problem.

[Raizo]

Yo Guys,

How to properly install the test version? Which files must be replaced? and where exactly?

https://i.postimg.cc/zv4SvmhV/avisynth-folder.png

Will replacing these two files be enough?

• x86-> C:\WINDOWS\SysWOW64\avisynth.dll

• x64-> C:\WINDOWS\SYSTEM32\avisynth.dll

And what about this one: "system\DevIL.dll" ?

Can I put the plugins here?
C:\Program Files (x86)\AviSynth+\plugins

[Emulgator]

Some .reg entries have to be set/reset with that.
Groucho2004's Universal Avisynth Installer will be your friend:
https://forum.doom9.org/showthread.php?t=172124
You can have multiple Avisynth versions ready to be swapped in with a batch script
and have 2 of them (x86+x64) installed side-by-side.
You swap in your desired latest test version where the Installer's 3.7.0 version sits
and maybe adapt the .bat file to reflect the name change.

[StainlessS]

Raizo,
If you want both x86 and x64 Avs+, suggest get this and set it up [reading docs]
https://forum.doom9.org/showthread.php?t=172124

Maybe copy to eg C:\VideoTools\AvisynthRepository\
Copy/replace the test version Avisynth x86 Avisynth.dll and system/devil.dll into the contained AVSPLUS370_x86,
and for x64 into AVSPLUS370_x64.
Edit the SetAvs cmd as per docs [if required, I dont bother],
and execute setavs.cmd as administrator, and select the Avs 3.7.0 one for each of x86 and x64.
The named versions will be wrong, but i guess you could change both folder names and edit setavs.cmd ,
but I personally dont bother.
Copy your plugins into each of the plugins directories in AVSPLUS370_x86/x64 folders.

Alernatively, get latest stable setup, and install, then copy from test version,
x86 avisnyth.dll and devil.dll into Windows\SysWOW64 and x64 version to Windows\system32.

sorted.

[Raizo]

Many Thanks Emulgator and StainlessS

yes, I use both version x86+x64 3.7.1 both already installed and working. I was just trying to figure out how to upgrade to the newest test version which does not come with the installer.

I'll try with this Groucho installer then. Tnx 1k again :)


EDIT:



Alernatively, get latest stable setup, and install, then copy from test version,
x86 avisnyth.dll and devil.dll into Windows\SysWOW64 and x64 version to Windows\system32.


just this seems working properly 👍🏻

Ty Guys!