AviSynth+ thread Vol.2

[Boulder]

My MaskTools version is mt_masktools-26.dll, this is what Didée recommends. My usual sources are half HD (1280x720), YUV 4:2:0, nothing special.

This is the latest one: https://github.com/pinterf/masktools/releases/tag/2.2.30

[manolito]

Thanks a lot Boulder, your tip saved the day for me... :D

First after copying the file from your link to the plugins folder I still got the same error as before. I just had not realized that the old mt_masktools-26.dll was still present in my plugin folder, and it took precedence over the new masktools2.dll. After deleting this file everything worked fine.

So thanks again...

Cheers
manolito

[Boulder]

Thanks a lot Boulder, your tip saved the day for me... :D

First after copying the file from your link to the plugins folder I still got the same error as before. I just had not realized that the old mt_masktools-26.dll was still present in my plugin folder, and it took precedence over the new masktools2.dll. After deleting this file everything worked fine.

So thanks again...

Cheers
manolito

No worries, just happened to remember that masktools2 was one of the plugins pinterf had kept updated :)

Good to see you back.

[wonkey_monkey]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).

[qyot27]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).
Wasn't this the same or similar reason for https://forum.doom9.org/showthread.php?p=2016078#post2016078 ?

[wonkey_monkey]

Some previous "skip" conditions were removed, so I would have thought this one should be too: https://forum.doom9.org/showthread.php?t=175681

I hadn't noticed, or had forgotten, about "force", but it seems like a kludge to me. The default behaviour falls under the category of "surprising (https://en.wikipedia.org/wiki/Principle_of_least_astonishment)", for me (perhaps more surprising than a resizer defaulting to parameters which amount to a blur).

[LigH]

I was in contact with several text editor developers related to supporting syntax highlighting.

In the case of "Far manager", support for block comments, even the nested type with brackets, could be added. In the case of "PSPad", it seems that this requires the introduction of a new symbol pair class.

So while I am at it: Are there simple but complete lists of identifiers available which are supported by the current version of the AviSynth+ core (reserved words, core functions, etc.)? I guess a list of core functions can be provided by AVSMeter.

[DTL]

BicubicResize is bypassing itself when target width/height is the same as source width/height (and there is no offset). It should only do so if b = 0 (which it is not, by default).

All resizers (really single resizing engine calls with different kernel setup) skip dimension processing if no size changed and no shift requested (src_left and src_top == 0) and force=0 (default).

To force convolution processing with selected kernel in any resizer you need either change size or shift or set force param to > 0 (to force H or V or H+V processing).

2D resize in AVS+ core is really sequence of H+V runtime configurable 1D resize filters and if some dimension is not processed - the filter for this is not created and not included into the filtergraph at all.

[wonkey_monkey]

All resizers (really single resizing engine calls with different kernel setup) skip dimension processing if no size changed and no shift requested (src_left and src_top == 0) and force=0 (default).


Which is fine, and always gives the correct result anyway - except when you're using BicubicResize with b != 0 (it defaults to 1/3).

If BicubicResize checked for b != 0 before skipping, then I don't think force would be needed at all.

[VoodooFX]

In the case of "PSPad...

Be careful with that one, it has critical random bug damaging a file you edit.

[LeXXuz]

Anyone else having problems with special characters in file names again? Haven't had this with previous versions.

[wonkey_monkey]

There's a bug in Reverse() when called on a clip with 24-bit audio:

void Reverse::GetAudio(void* buf, int64_t start, int64_t count, IScriptEnvironment* env)
{
child->GetAudio(buf, vi.num_audio_samples - start - count, count, env);
int x = vi.BytesPerAudioSample() - 1;
char* buf2 = (char*)buf;
const int count_bytes = (int)vi.BytesFromAudioSamples(count);
for (int i=0; i<(count_bytes>>1); ++i) {
char temp = buf2[i]; buf2[i] = buf2[count_bytes-1-(i^x)]; buf2[count_bytes-1-(i^x)] = temp;
}
}

The problem is here. The bits in red - which to me looks like a case of too-clever-for-its-own-good - rely on vi.BytesPerAudioSample() being a power of 2, which is not the case for 24-bit audio.

[wonkey_monkey]

I opened MSVC and opened my local Avisynth 3.7.5 folder to make a build. But I got this error:

CMake Error at CMakeLists.txt:155 (message):
MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).

3.7.4 is doing the same, but I'm sure I didn't used to get this error - I could pretty much just open the local folder, wait for MSVC to do its thing, and then build. Has there been some update to MSVC which is causing something to fail?

I changed line 155 of CMakeLists.txt to:

message(FATAL_ERROR "MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).${PLATFORMID}xxx")


and this was the output:

1> CMake generation started for configuration: 'x64-Release'.
1> Command line: "C:\Windows\system32\cmd.exe" /c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"
1> Working directory: C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\build\x64-Release
1> [CMake] -- Detected target processor as: AMD64
1> [CMake] -- Build type: RelWithDebInfo
1> [CMake] CMake Error at C:\Projects\Avisynth\AviSynthPlus-3.7.5\CMakeLists.txt:155 (message):
1> [CMake] MSVC/ClangCL only supported on x86(-64). Use MinGW (llvm-mingw or gcc).xxx
1> [CMake]
1> [CMake]
1> [CMake] -- Configuring incomplete, errors occurred!
1> 'C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"' execution failed with error: ''C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING="RelWithDebInfo" -DCMAKE_INSTALL_PREFIX:PATH="C:\Projects\Avisynth\AviSynthPlus-3.7.5\out\install\x64-Release" -DCMAKE_C_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_CXX_COMPILER:FILEPATH="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.44.35207/bin/Hostx64/x64/cl.exe" -DCMAKE_MAKE_PROGRAM="C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\Ninja\ninja.exe" "C:\Projects\Avisynth\AviSynthPlus-3.7.5" 2>&1"' returned with exit code: 1'.

which seems to suggest ${PLATFORMID} is an empty string...?

[LigH]

That looks like the CPU architecture got misdetected...

[wonkey_monkey]

It detects the processor okay - AMD64 - but ${CMAKE_VS_PLATFORM_NAME}, which is what ${PLATFORMID} is based on, seems to be empty. A Google search only suggests a possible issue with it not getting filled in until project(...) is set, but that's done on line 79.

[StvG]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.

[qyot27]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.
Honestly, since I couldn't get Ninja and MSVC to ever play nice with one another, it makes sense why that wasn't caught.

[StvG]

Honestly, since I couldn't get Ninja and MSVC to ever play nice with one another, it makes sense why that wasn't caught.

The biggest pain for me using Ninja+MSVC to build AVS+ is that the version script doesn't work. Binary built with Ninja doesn't show the version when right click, properties, details.

[qyot27]

The biggest pain for me using Ninja+MSVC to build AVS+ is that the version script doesn't work. Binary built with Ninja doesn't show the version when right click, properties, details.
Only MSVC_IDE adds the .rc file, yes. Files.cmake, line 89. I can't remember what precisely about .rc files Ninja had issues with (it was six years ago), so it's hard to say whether it might have been fixed by now.

[wonkey_monkey]

Change this snippet (https://github.com/AviSynth/AviSynthPlus/blame/master/CMakeLists.txt#L146-L152) with:
if(CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

I had to change it to from "amd64" to "AMD64", but that seems to have worked, thanks. Building like this should result in a fairly optimal DLL, right? I changed CMakeSettings.json to x64-Release.

@qyot27 the original snippet doesn't work for other generator than Visual Studio one.

I'm using Visual Studio :confused: and I'm sure it worked without alteration a few months ago...

[StvG]

I had to change it to from "amd64" to "AMD64", but that seems to have worked, thanks. Building like this should result in a fairly optimal DLL, right? I changed CMakeSettings.json to x64-Release.

Right. This is the case-insensitive version:
string(TOLOWER "${CMAKE_SYSTEM_PROCESSOR}" PROCESSOR_ID_LOWER)
if(PROCESSOR_ID_LOWER MATCHES "^(x86_64|amd64|x64|i[3-6]86|x86)$")
set(NON_X86_PLATFORM "OFF")
else()
set(NON_X86_PLATFORM "ON")
endif()

Yes, building like this will result in fairly optimal DLL. You built RelWithDebInfo version.

I'm using Visual Studio :confused: and I'm sure it worked without alteration a few months ago...

You use the Visual Studio environment but you're using Ninja building system not the native Visual Studio one (solution files).

From one of the your previous posts:
1> 'C:\Windows\system32\cmd.exe' '/c "%SYSTEMROOT%\System32\chcp.com 65001 >NUL && "C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\2022\COMMUNITY\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\CMAKE\CMake\bin\cmake.exe" -G "Ninja" -DCMAKE_BUILD_TYPE:STRING=...

[wonkey_monkey]

I can't work out whether this is because I've added ninja.exe to MSVC at some point... I certainly can't see an obvious way to remove it again, or make it not the default, if I did. Anyway, alternative fix is to go into CMake settings and change the generator there.

[StvG]

Open your CMakeSettings.json, locate "generator" and change it from "Ninja" to "Visual Studio 17 2022" (or your VS version if it's not 2022). Check if you have "architecture"->"strategy" : "external", if so change "strategy" to "set". This way you will use the native VS generator (solution files).

[jpsdr]

Hi.

If i want to change chromaplacement property of a frame.

How do i do
avs_prop_set_int(env, avs_get_frame_props_rw(env, dst), "_ChromaLocation", 2, 0);
but using "avisynth.h" ?

And do i need to call MakePropertyWritable somewhere ?
If yes, where ?

[StvG]

The C++ API equivalent is:
env->propSetInt(env->getFramePropsRW(dst), "_ChromaLocation", 2, 0);

You don't need MakePropertyWritable in this case.

[jpsdr]

Thanks !

[jpsdr]

Using r4339.

How AddAlphaPlane is working ?

I tried the following:

ColorBars(pixel_type="yv24")
AddAlphaPlane(255)

Virtualdub2 throw me a decompressing error on frame 0, data is too short.

I tried:

a=ColorBars(pixel_type="yv24")
a.AddAlphaPlane(255)
a

The video output is YV24...

How do i get an YUVA video ?

An exemple in the wiki show a script using a not existing function (AToY8).

[Music Fan]

Shouldn't it be AddAlphaPlane ? If it comes from the function CombinePlanes.

[LigH]

"AddAlphaPlane()" would be the correct function name.

And I also tested it with pixel_type names (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/blankclip.html) explicitly supporting alpha channels: "YUVA444" and "YUVA444P8". Same issue.

PS: VirtualDub2 reports such errors. AvsMeter64 does not.

Unfortunately, this kind of errors does not appear in the "Log" window [F8]. How else do I get the exact error message out of VirtualDub2?

[TR-9970X]

Using r4337.

I have to ask, is this the latest build of Avisynth ??

[jpsdr]

It's the problem when testing on a PC, and posting on another. Some typo mistake happens... :D (corrected).
It was r4339, and there was some update since i think, but not related to features i'm using, so i didn't make a new build.

[TR-9970X]

It's the problem when testing on a PC, and posting on another. Some typo mistake happens... :D (corrected).
It was r4339, and there was some update since i think, but not related to features i'm using, so i didn't make a new build.

That's interesting, so are these builds available, somewhere ?

[jpsdr]

Is it normal that Virtualdub2 throw "Unknow [0][0][0][0] video format" for planarRGB (or RGBA) 32bits ? No issue with YUV 32bits.
I've checked out, and Virtualdub2 support 32bits planar RGB.
And i'm almost sure that when (a long time ago now) i was creating my HDR tools, i was able to open AVS script outputing 32bits planar RGB.

@TR-7970X
No, sorry, i'm juste making builds for myself, i don't have a repo or anything for it, there is already enough people sharing their AVS+ builds.

[Music Fan]

Did you open your script in Virtualdub2 32 bit ? Because it generally fails when openend in Virtualdub2 64 bit.

[poisondeathray]

Is it normal that Virtualdub2 throw "Unknow [0][0][0][0] video format" for planarRGB (or RGBA) 32bits ?

Did you mean 8bit per channel planar RGBAP ? (not 32bit per channel RGBAPS)

Works for me (vdub x64 44282 , the last shekh version)

info() reports RGBAP

[jpsdr]

No, i mean 32bit per channel.

Edit:
I forgot... I as indeed with Virtualdub2 64 bits. I'll try with 32 bits.

[jpsdr]

I begin to wonder finaly if Virtualdub2 is able to handle planar RGBPS (or RGBAPS). Because if i output 32bits YUV444, it opens, but file info said it's Y416. So, finaly, it's not float.
Is Virtualdub converting it, or is avisynth converting before outputing ?

But if i ouput RGBPS ou RGBAPS, i have the error i described (with both x86 or x64 Virtualdub2 versions).
Even if in Virtualdub2 it exists nsVDXPixmap::kPixFormat_RGB_Planar32F and nsVDXPixmap::kPixFormat_RGBA_Planar32F, i begin to wonder if they are realy fully implemented.

[DTL]

Typically most safe format for VirtualDub to monitor output is RGB24. All others may not work.

[v0lt]

Some time ago I wrote about problems with Unicode (https://forum.doom9.org/showpost.php?p=2019715&postcount=3366).

I found another one.
Avisinth+ writes errors to AvisynthError::msg in UTF-8 format. However, Avisinth+ receives system error text in ANSI (CP_ACP) format and stores it in AvisynthError::msg. The result is an error text with two encodings for different lines.

A simple example:
Create a script file named "Duck_Утка_Πάπια_오리.avs" and add one line to it:
LoadPlugin ("filename")
The file "filename" won't be found, and we'll see the following error message:
Cannot load file 'C:/TEMP/filename'. Platform returned code 126:
�� ������ ��������� ������.

(C:\TEMP\Duck_Утка_Πάπια_오리.avs, line 1)

PS: Pull request #457 (https://github.com/AviSynth/AviSynthPlus/pull/457).

[Emulgator]

Good find !

[mcjordan]

I have a dumb problem with compiling latest AviSynth from github repo with VS2022:
The problem is in lines from 505 onward of ../avs_core/filters/source.cpp (error C2665):

PClip Create_MessageClip(const char* message, int width, int height, int pixel_type, bool shrink,
int textcolor, int halocolor, int bgcolor,
int fps_numerator, int fps_denominator, int num_frames,
bool utf8,
IScriptEnvironment* env) {
...
that pointed to line 2155 and below:

return Create_MessageClip(
AVS_FULLVERSION AVS_DEVELOPMENT_BUILD AVS_DEVELOPMENT_BUILD_GIT AVS_COPYRIGHT_UTF8,
w, h, i_pixel_type, shrink, textcolor, halocolor, bgcolor, fps_numerator, fps_denominator, num_frames,
true, // utf8
env);

Please help me to resolve this. I'm not heavy experienced in modern programing and this simple problem really bothers me at 2 am... ;-)

[v0lt]

I'm not heavy experienced in modern programing and this simple problem really bothers me at 2 am... ;-)
Did you use CMake to generate the correct project files?

[mcjordan]

v0lt
Yes, latest from their site - 4.2.0-rc1.
Project files are OК, I have compiled AVS many times with VS2022 and VS2019, but two last commits...
As far as I can understand the situation there is some kind of discrepancy of this type:
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c2665?view=msvc-170

P.S. LLVM and pure clang builds (via VS - not via Intel compiler) are problems-free.

[v0lt]

Visual Studio 2022 v17.14.18. I have no problems building and rebuilding the main repository.

PS: I can't build my forked repository (https://github.com/v0lt/AviSynthPlus) due to a version.h generation error.

[mcjordan]

v0lt
Thank you for collaboration. I use the same build of VS.
I'll try your fork later today and if there is anything new I will write.

[mcjordan]

v0lt
The mystery of error C2665 is solved.
In Configuration Properties/General I've set C++ Language Standard at ISO C++20 (/std:c++20).
In my quest to compile a "slightly" optimized version of AviSynth I've clearly gone too far.
With C++17 compatibility there are no compilation problems

[LigH]

Woohoo!

I remember several problems in the history of the media-autobuild suite caused by C++ language standards in different projects... :o

[tormento]

I someone can share some newer builds of AVS+ is welcome. I am stuck at 4313 (https://gitlab.com/uvz/AviSynthPlus-Builds).

[Emulgator]

The last commits are around UTF-8 in GetLastErrorText, so probably you won't miss a thing here.

[mcjordan]

tormento
I sent you a message.