AviSynth+ thread Vol.2 [Archive]

pinterf

29th April 2020, 13:46

Since active developers has been changed during the past couple of years, AviSynth+ finally got a new topic after a super-fast decision.

AviSynth is still alive, thanks to all earlier and present core, filter and documentation contributors. And to the users of course who trust us.

Online documentation: Avisynth+ online documentation (https://avisynthplus.readthedocs.io/en/latest/)

Latest Tests:

Latest test build (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.6pre-r4604)
Avisynth+ v3.7.6pre-r4604 test build (20260518)

Current (https://github.com/AviSynth/AviSynthPlus/releases)
Avisynth 3.7.5 (20250420)

Avisynth 3.7.5
Avisynth 3.7.5 (20250420) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.5)

Avisynth 3.7.4 final
Avisynth 3.7.4 (20250324) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.4)

New in Avisynth wiki
Partially translations from Neo wiki (https://github.com/nekopanda/AviSynthPlus/wiki)
http://avisynth.nl/index.php/SetGraphAnalysis
http://avisynth.nl/index.php/Function_objects
http://avisynth.nl/index.php/SetFilterMTMode
http://avisynth.nl/index.php/User_defined_script_functions#Array_examples
http://avisynth.nl/index.php/Internal_functions#Functions_for_frame_properties

Avisynth+ 3.6.0 release
https://forum.doom9.org/showthread.php?p=1912834#post1912834

Avisynth+ 3.6.1 release
https://forum.doom9.org/showthread.php?p=1916176#post1916176

Test builds - 3.6.2 work in progress
AviSynth+ 3.6.2-test6 20201210 (https://drive.google.com/uc?export=download&id=1ZdSd_TAPRmdkFGerLaIrDVrsIE8pUBGx)
AviSynth+ 3.6.2-test4 20201112 (https://drive.google.com/uc?export=download&id=1L6dC0JdSIM5uSOUsuZOI6UcpfPycG0VK)
AviSynth+ 3.6.2-test3 (https://drive.google.com/uc?export=download&id=1Ow2g4H16B3PvXWiD9VGXkJSQk7mBaxb5)
AviSynth+ 3.6.2-test2b (https://docs.google.com/uc?export=download&id=17ezMUI42I_0vpTlHzd_TzWHXfkUlYXh6)
AviSynth+ 3.6.2-test1 (https://drive.google.com/file/d/1_IwlcyDiv-0gnV4vPttLWV4urEaDAdMH/view?usp=sharing)

Avisynth+ 3.7.0 release
https://forum.doom9.org/showthread.php?p=1933223#post1933223

Avisynth+ 3.7.1 tests
https://drive.google.com/uc?export=download&id=1CpFdkqbNRDwtuHCtWiQ4x49ZCt8W2jkS
Avisynth+ 3.7.1 - 20210610 (https://drive.google.com/uc?export=download&id=1SRnFC53zrctCcHCbLF8hQ5AlEKud7-Sx) including XP and CUDA-aware builds
AviSynth+ 3.7.1-test6 20210621 (https://drive.google.com/uc?export=download&id=1xlNwp3XH7RUaRmUMdakcR4x3LdKoTYVT)
AviSynth+ 3.7.1-test7 20210630 (https://drive.google.com/uc?export=download&id=1naR4I4tm-EifZIdbkS9M1zhtS9_2wL19)
Avisynth+ 3.7.1 test build 8 (20210705) (https://drive.google.com/uc?export=download&id=1NK_XRbelWytZYOl7KLDb4JgLGvaYEFjV)
Avisynth+ 3.7.1 test build 9 (20210706) (https://drive.google.com/uc?export=download&id=1lbiMMPsSFTKoKhUKdNl0NdcKiv0bgLKY)
Avisynth+ 3.7.1 test build 12 (20210911) (https://drive.google.com/uc?export=download&id=1tZKYyQEaru1K_QyD_Q4CFiW8arze6aWl)
Avisynth+ 3.7.1 test build 14 (20210914) (https://drive.google.com/uc?export=download&id=1f1tfB40Ny0rZcmBApSiulFl6ndfpta4z)
Avisynth+ 3.7.1 test build 15 (20210917) (https://drive.google.com/uc?export=download&id=11Ye6RHYCu99hTZwl2bTyWdvnjObC-K4c)
Avisynth+ 3.7.1 test build 16 (20210920) (https://drive.google.com/uc?export=download&id=14b4Zl0HYeRGj2E_0nA0t_IYYWvZuITsP)
Avisynth+ 3.7.1 test build 17 (20210924) (https://drive.google.com/uc?export=download&id=1XUtEI5qL0NPy85v3gDYHHh75w828G7dq)
Avisynth+ 3.7.1 test build 18 (20210927) (https://drive.google.com/uc?export=download&id=13-lNFkFHkRg4-mwE2uCI16UbpyrE_REp)
Avisynth+ 3.7.1 test build 19 (20210928) (https://drive.google.com/uc?export=download&id=1PjSi1wK1ChTpLvvSv42xdufCQe5fTqml)
Avisynth+ 3.7.1 test build 20 (20210930) (https://drive.google.com/uc?export=download&id=1b-sTu_IsnxalIp5QNI1ugW1DYcGUhl05)
Avisynth+ 3.7.1 test build 21 (20211021) (https://drive.google.com/uc?export=download&id=1eExZZoR17JCx8G0wfp49Vfha9awz-6I9)
Avisynth+ 3.7.1 test build 22 (20211022) (https://drive.google.com/uc?export=download&id=1M36wJoTtk15o_D3ihkhEx7FHk0DoQMaS)
Avisynth+ 3.7.1 test build 23 (20211103) (https://drive.google.com/uc?export=download&id=1UfjtV3FMqzCjI8s-A864KzWUO_dAdaAR)
Avisynth+ 3.7.1 test build 24 (20211104) (https://drive.google.com/uc?export=download&id=1LtBvg0gR6KLtdwzO1lquZvLzszL0_sFS)
Avisynth+ 3.7.1 test build 25 (20211105) (https://drive.google.com/uc?export=download&id=1xQGN9i3ecJqzwZTfDFNCQ_F1efZfekc-)
Avisynth+ 3.7.1 test build 26 (20211116) (https://drive.google.com/uc?export=download&id=13_UFB4KL_KKFi4pC_G5HBVCRixeEvBqL)
Avisynth+ 3.7.1 test build 27 (20211117) (https://drive.google.com/uc?export=download&id=1tyZCCC96arWeXaZ0EKMSiKkS6My9LxRR)
Avisynth+ 3.7.1 test build 28 (20211124) (https://drive.google.com/uc?export=download&id=1Syz8js7R3_8376WAyYKzmwKP40gu3wHy)
Avisynth+ 3.7.1 test build 29 (20211126) (https://drive.google.com/uc?export=download&id=1gxEaQDQYoLBiZdFc1HOJKWgh8o7zVLf5)
Avisynth+ 3.7.1 test build 32 (20211202) (https://drive.google.com/uc?export=download&id=1xv8zwctgJ16XThopha4TBsU-aw_FTUUP)
Avisynth+ 3.7.1 test build 33 (20211205)
Avisynth+ 3.7.1 test build 34 (20211208) (https://drive.google.com/uc?export=download&id=1nVYll8WKoHBYOjh53AxPWnZLXxkeIpzi)
Links to official installers for last XP compatible Microsoft Visual C++ 2015-2019 Redistributable (version 14.28.29213):
x64 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/B75590149FA14B37997C35724BC93776F67E08BFF9BD5A69FACBF41B3846D084/VC_redist.x64.exe
x86 - https://download.visualstudio.microsoft.com/download/pr/566435ac-4e1c-434b-b93f-aecc71e8cffc/0D59EC7FDBF05DE813736BF875CEA5C894FFF4769F60E32E87BD48406BBF0A3A/VC_redist.x86.exe

[B]Avisynth 3.7.1 final
Avisynth+ 3.7.1 (20211231) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.1)

Avisynth 3.7.2 tests
Avisynth+ 3.7.2 test 1 (20220113) (https://drive.google.com/uc?export=download&id=1A2Jb2OSYzGI0tBFEmvlT0RxxLwVoCiP_)
Avisynth+ 3.7.2 test 2 (20220201) (https://drive.google.com/uc?export=download&id=1QpctWEKU1Mg9O5AEyK41iQ4fIuJAbktc)
Avisynth+ 3.7.2 test 3 (20220208) (https://drive.google.com/uc?export=download&id=1jyqttklu67ehTLnWlsHYHexMdbs2lfCq)
Avisynth+ 3.7.2 test 12 (20220303) (https://drive.google.com/uc?export=download&id=1PMdVp0U0Jq9b88ahg20SBotU_UB-w3oP)

Avisynth 3.7.2 final
Avisynth+ 3.7.2 (20220317) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.2)

Avisynth 3.7.3 tests
Avisynth+ 3.7.3 test 2 (20221114) (https://drive.google.com/uc?export=download&id=1fCPbb4n1-nuR_mAaLG_4o1Zxfciwr2A4)
Avisynth+ 3.7.3 test 3 (20230118) (https://drive.google.com/uc?export=download&id=1FEww_BfRMY63D2NCg4h860ofxqfflRhu)
Avisynth+ 3.7.3 test 5 (20230217) (https://drive.google.com/uc?export=download&id=1WoLyY55YqfvB3PPP-pIs0GuDlbN6-zBm)
Avisynth+ 3.7.3 test 6 (20230218) (https://drive.google.com/uc?export=download&id=1MwIRCk65Gtto7qdWjaD1zlc47G0gRACD)
Avisynth+ 3.7.3 test 7 (20230223) (https://drive.google.com/uc?export=download&id=1dKBH5DM6RwNSBBwdEoB-weg50I_whTEm)
Avisynth+ 3.7.3 test 8 (20230315 - r3958) (https://drive.google.com/uc?export=download&id=1BvFA3vNePZVLgtnQ4FiugcHddkricK2m)
Avisynth+ 3.7.3 test 9 (20230316 - r3961) (https://drive.google.com/uc?export=download&id=1xFMgLh5lh6kmKPxT5lYGZbpVVBkLyxiK)
Avisynth+ 3.7.3 test 11 (20230608 - r3996) (https://drive.google.com/uc?export=download&id=1ZmFSUZ3ndDzfPYuVWp9MQpZ_YqHCoSEO)

Avisynth 3.7.3 final
Avisynth+ 3.7.3 (20230715) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.3)

Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013) (https://drive.google.com/uc?export=download&id=1xQ9EmT2LG5Ouqz-Je7rvDTP01Sc4Ve5i)
Avisynth+ 3.7.3post test 5 (20231026 - r4017) (https://drive.google.com/uc?export=download&id=1gFcu3Wp3jRiT7lAi7WzrV3Rym7y9jcPO)
Avisynth+ 3.7.3post test 6b (20231031 - r4018) (https://drive.google.com/uc?export=download&id=1ONJtxKUXh4L-eQi3j7_RoSbVJUdvfg3f) (fixed content)
Avisynth+ 3.7.3post test 8 (20231103 - r4021) (https://drive.google.com/uc?export=download&id=1ZGt6F7pLnMj6lo_n-gwjl4S6PtOYHD35)
Avisynth+ 3.7.3post test 9 (20231105 - r4022) (https://drive.google.com/uc?export=download&id=1ZsU6x-ttYJxUugYAAw_4eTSe5bpc4F2L)
Avisynth+ 3.7.3post test 10 (20231202 - r4035) (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX)
Avisynth+ 3.7.3post test 11 (20240118 - r4059) (https://drive.google.com/uc?export=download&id=199YthQlcKrvBkBU-btd0k40Yyzvbo24K)
Avisynth+ 3.7.3post test 12 (20240124 - r4062) (https://drive.google.com/uc?export=download&id=1CKYoQSCHDDbMFH14j8rYNT2TI5S3aCbJ)
Avisynth+ 3.7.3post test 14 (20240131 - r4066) (https://drive.google.com/uc?export=download&id=1nrdoQgzzYJh7RwkkrPZwW9OGpmI53A9-)
Avisynth+ 3.7.3 (20250214 - r4193) (https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4193)

Avisynth 3.7.4 final
Avisynth+ 3.7.4 (20240324) (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.4)

Rebuild list
- KNLMeansCL 1.1.1b - pfmod (https://github.com/pinterf/KNLMeansCL/releases) (fails because using env2->SetFilterMTMode instead of cache hints - see my mods in source)
- KNLMeansCL 1.1.1c - pfmod (https://github.com/pinterf/KNLMeansCL/releases/tag/v1.1.1c) Avisynth multithreading fixes
- KNLMeansCL 1.1.1e - pfmod (https://github.com/pinterf/KNLMeansCL/releases/tag/v1.1.1e) Support 9-15 bits (10-14 in Avs) - also for VapourSynth

- chikuzen's plugins rebuilt by Asd-g
https://github.com/Asd-g?tab=repositories

- GScript
See download link in Groucho2004's topic (https://forum.doom9.org/showthread.php?t=173259)

- MeGUI AvisynthWrapper (until the "official" one)
https://forum.doom9.org/showthread.php?p=1913117#post1913117

Project webpage
https://avs-plus.net/

Releases
https://github.com/AviSynth/AviSynthPlus/releases/

Doom9 forum: Avisynth+ topic Vol.1 - the original
https://forum.doom9.org/showthread.php?t=168856

Avisynth+ Linux/MacOS/BSD/Haiku thread
Threads for non-Windows versions by qyot27:
https://forum.doom9.org/showthread.php?t=180436
AviSynth+ plugins and utilities for other OSes and CPUs (https://forum.doom9.org/showthread.php?p=1927689)

Project github page
https://github.com/AviSynth/AviSynthPlus

real.finder

29th April 2020, 14:41

StainlessS

29th April 2020, 14:53

New version Avs+, gazilions of new functions, new Avs+ thread, A truly great day indeed.

May all your gods look with favour upon you :)

tormento

29th April 2020, 18:27

I was thinking about additional script extension exclusive for avs+ like .avsp
The letter after s is t: .avt and .avti

I have googled and there are no programs AFAIK that already use that.

qyot27

29th April 2020, 18:56

I honestly don't see the point of Plus-specific extension(s). It would make sense if we were completely overhauling the AviSynth scripting language into a properly versioned one with in-script controls and a CLI interpreter for that sort of compatibility (think of the hashbang in Unix shell scripts), in the sense that the wholly-different language was Plus-specific and absolutely needed to be shielded from 2.6 and prior, but we aren't. UTF-8 is transparent to the host on everything that's not Windows, and even is transparent on Windows if you've actually set the system locale to UTF-8 (which is possible on Win10, it's just not the default like it is on nearly every other OS out there). Even 2.6 is fine with UTF-8 in that situation.

Groucho2004

29th April 2020, 19:07

I was thinking about additional script extension exclusive for avs+ like .avsp (maybe it's not good since there are program named AVSP) or .pavs, and for autoload script .avsip or .avspi /.pavsiYeah, lets complicate the hell out of it and scare away casual users and noobs. :D

I honestly don't see the point of Plus-specific extension(s).Indeed.

MeteorRain

29th April 2020, 21:13

I'd like to re-raise the problem -- array idea seems to be incompatible with previous versions.

real.finder

29th April 2020, 22:51

the point is to make sure that non plus avs not load these scripts since they will be utf-8 and has another new things that unavailable in normal avs, so it should be more casual users and noobs friendly

qyot27

29th April 2020, 23:49

AviSynth 2.5, 2.6, any version of Plus, etc. honors the system locale. UTF-8 causes problems for AviSynth in one scenario, and only one scenario: the user has left Windows set at its regional default codepage (whether that's Windows-1252, -1251, -932, -936, -949, -950, etc.).

On Linux, macOS, and BSD, the system locale is UTF-8. AviSynth+ has no issues with it, without us having had to change any code at all to accommodate it. Text files created on these systems also usually default to UTF-8 without BOM anyway.

On Windows 10, Microsoft finally allows users to set the system codepage (locale) to 65001, which is UTF-8. If you do this, none of the versions of AviSynth, classic or Plus, have issues with it. Notepad in Windows 10, regardless of the locale, was switched to defaulting to save in UTF-8 without BOM a while ago.

Proving that this isn't something Plus-related, here's 2.6.1 running a UTF-8 encoded script with a UTF-8 filename, opening a video with FFMS2 with a UTF-8 filename (without passing any kind of special parameter to allow it), in a directory with a UTF-8 name:
http://i.imgur.com/1p5osrEh.jpg (https://i.imgur.com/1p5osrE.jpg)

pinterf

30th April 2020, 05:53

I'd like to re-raise the problem -- array idea seems to be incompatible with previous versions.
Good question, sorry, I have read it but could not deal with it because this topic needed a whole attention which I did not have.

I was looking for a way to keep existing 'type' and '+' format, but I could not find a convenient and compatible way to do that.

At the moment "a" type in function signatures are for ".+" and requires [] syntax on the script side. Nor can it specifiy that you want a float-only array for example. On the bright side, new-style dedicated array parameters can appear anywhere in the list and can have names, can follow each other even with specifying zero elements in them.

Another big difference that new-style script arrays can be of multiple levels, not only an 1-D array, like they are treated in parameter list (btw - you are dealing with dual AVS-VS interfaces, does VapourSynth allows multilevel array as function parameters?). They can be of 0 or 1 elements and they still preserve their type as array.
There are more differences: unlike old arrays they are deep-copied and deep-deleted on deallocation (except on C interface which is treated specially)

I think I have to look at that in internal "Invoke_" as well. In "Invoke_" the array-typed arguments are totally 'flattened' back before calling function-match checking (thus their arrayness is removed). This is a reason why array arguments cannot follow each other as an unnamed parameters. The array parameters (if they are of mixed type or zero sized) cannot be separated again any more.

MeteorRain

30th April 2020, 09:53

pinterf

30th April 2020, 10:04

tormento

30th April 2020, 10:23

On Windows 10, Microsoft finally allows users to set the system codepage (locale) to 65001, which is UTF-8.
Are you talking about the very well hidden Unicode beta support?

gispos

30th April 2020, 16:52

Avisynth 3.52 x64 with arrays.
Access Violation Shader_x64.dll, no problems with the previous Avisynth version

function SuperResXBR

shader.avsi line 218
ExecuteShader(last, Input, Precision=3, Clip1Precision=PrecisionIn, OutputPrecision=PrecisionOut, PlanarOut=PlanarOut, Engines=Engines, Resource=true)

Groucho2004

30th April 2020, 16:58

gispos

30th April 2020, 17:08

Any chance you can post a script to reproduce?

A normal script
Even with the version without arrays, it pops.:)

SourceFile = ScriptDir() + "Your source"

video=LWLibavVideoSource(SourceFile, cache=False)
audio=LWLibavAudioSource(SourceFile, cache=False)
audioDub(video, audio)
#SelectEven()

MCTemporalDenoise(settings="low", sigma=4, strength=150, tovershoot=1, GPU=true)
prefetch(4)

#Spline36Resize(1920, 1080)
SuperResXBR(Passes=1, Soft=0.0, XbrSharp=1.0, fWidth=1920, fHeight=1080)

UnsharpMask(strength=60, radius=3, threshold=8)

Groucho2004

30th April 2020, 17:10

OK, I can reproduce it.

pinterf

30th April 2020, 17:12

AviSynthShader plugin is using the Avs+ specific IScriptEnvironment2.

e.g.
b = static_cast<IScriptEnvironment2*>(env)->Allocate(floatBufferPitch, 32, AVS_POOLED_ALLOC);

EDIT: changed link, master became finalized
This plugin will work again if rebuilt with V8 headers and use env->Allocate (IScriptEnvironment instead of IScriptEnvironment2).
https://github.com/AviSynth/AviSynthPlus/tree/master/

(Similarly to KNLMeansCL and chikuzen's plugins)

EDIT:
For more info, see 1st post

Groucho2004

30th April 2020, 17:23

This plugin will work again if rebuilt with headers from current neo branch and use env->Allocate (IScriptEnvironment instead of IScriptEnvironment2).
https://github.com/AviSynth/AviSynthPlus/tree/neoSo, these are the headers we should be using from now on?

gispos

30th April 2020, 17:58

AviSynthShader plugin is using the Avs+ specific IScriptEnvironment2.

e.g.
b = static_cast<IScriptEnvironment2*>(env)->Allocate(floatBufferPitch, 32, AVS_POOLED_ALLOC);

This plugin will work again if rebuilt with headers from current neo branch and use env->Allocate (IScriptEnvironment instead of IScriptEnvironment2).
https://github.com/AviSynth/AviSynthPlus/tree/neo

(Similarly to KNLMeansCL and chikuzen's plugins)

OK, all plugins that use IScriptEnvironment2 are not running.
I haven't compared the two in code and return values, but no chance to turn it in avisynth?

I think that some plugin developers are no longer available (free, without money).

EDIT:
Just checked, the shader.dll is from mysteryx93 on github. It will probably still be reachable.:)

Have already panicked, I used the SuperResXBR very often at the beginning (approx. 3xx, to many scripts on my hard drives):)

almosely

30th April 2020, 19:41

Hideho,

I just stumbled upon a new AVS+ release (my installed version is 3.4.0) while cleaning up my ff-bookmarks and found some confusing things. The following files are downloadable here (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.1):

1. AviSynthPlus-3.5.1_20200402.exe
2. AviSynthPlus-3.5.1_20200402_vcredist.exe
3. AviSynthPlus-3.5.1_20200402_vcredist_xp.exe
4. AviSynthPlus-3.5.1_20200402_xp.exe
5. AviSynthPlus_3.5.1_20200402_filesonly.7z

I guess #1 is the regular installer. The place to go if nothing is installed? Is it possible, to use this file to update the current avs-version without loosing any custum made configs too?

Do I need the file #2 (vcredist) when I choose to use file #5 (filesonly) or are there no differences between avs+ 3.4.0 and avs+ 3.5.1 regarding that?

What is "_xp" for (files #3 and #4) ? Windows XP?

So, and finally file #5 (filesonly). Within that .7z-archive are several folders:

- x64
- x64-xp
- x86
- x86-xp

I guess, the "-xp" is regarding Windows XP?

Then, within the "x64"-Folder there are some more folders:

- c_api
- plugins

What do I do with the "c_api"-folder? There are two files within:

- AviSynth.exp
- AviSynth.lib

Are they only needed in an SDK-environment and totally not needed for the running version (= just users)?

Then the "plugins"-folder; I guess the content of that folder has to be copied into the "plugins64+"-folder of my installed avs+ version?

And there are two files, outside the two folders:

- AviSynth.dll
- DevIL.dll

So, I guess, both are to be copied to "Windows\System32"?

... and regarding the "x86"-content ... The files within "plugins" has to be copied to "plugins+" and "AviSynth.dll" and "DevIL.dll" are to be copied to "Windows\SysWOW64"?

There's no documentation regarding that at all, sadly.

gispos

30th April 2020, 20:54

almosely your assumptions are all correct.
Copy the avisynth.dll and DevIL.dll into the correct system directory and the update is finished.
If you feel like it, you can also copy the plugins into the plugin directories.
I never do that, I just move the avisynth.dll. into the system directory.

qyot27

30th April 2020, 20:57

Yes, it can be installed over the previous install. Stuff suffixed with -xp are still WinXP compatible (but are not exclusively for XP). Installers suffixed with vcredist include the Visual C++ 2015-2019 Redistributable installer and runs it during the install process.

If you don't know which one to use, use #2.

almosely

30th April 2020, 22:56

Oh, thank you both! :-)

Therefore I manually switched the corresponding files (avisynth.dlls, devil.dlls and the plugins-folders), disposed the c_api- and xp-folders and downloaded up-to-date-versions of the already installed VC++ redists 15-19.

pinterf

1st May 2020, 09:31

So, these are the headers we should be using from now on?
Yes, but it IScriptEnvironment will still extend a bit.
My intention that these future extensions do not affect already defined elements.

Groucho2004

1st May 2020, 09:35

My intention that these future extensions do not affect already defined elements.That's good to know. :)

gispos

1st May 2020, 17:03

My intention that these future extensions do not affect already defined elements.
also CUDA doesn't that ;)
Do you also have CUDA in your sights? You're welcome.:D

tormento

2nd May 2020, 10:54

also CUDA doesn't that ;)
Do you also have CUDA in your sights? You're welcome.:D
OpenCL is a much better future aware way to go.

It's not platform dependent and have lot of manifacturers supporting it.

Nonetheless CUDA has direct C++ and Fortran compiler support from at least Intel.

tormento

2nd May 2020, 10:56

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

StainlessS

2nd May 2020, 12:52

Post #5103 in original Avisynth+ thread updated[AvsVersion.avsi]:- https://forum.doom9.org/showthread.php?p=1897680#post1897680

MeteorRain

2nd May 2020, 12:55

tormento: Agree.

Or having a table for each plugin indicating the support of HBD and x64, better if also indicating GPU version and Internal MT version.

Also would like to know if there's anything missing from famous scripts such as MCTD or QTGMC etc. (Especially HBD and x64.)

pinterf

2nd May 2020, 12:56

I believe you have to specify "type[]" as type in VS. So it's 1D array of specific type. -- hopefully my memory serves right.

The main problem is "a" type will cause the filter to not run on non-array avs -- even same avs version that compiles without array support.

That's why I proposed a compatible way of annotating array. Again it's a premature idea, I haven't checked Invoke() and I'm not sure if it would work.

The most compatible way is to specify "." instead of "a" and you check the arrayness and throw a possible error in filter creation.

Anyway I'm now on eliminating the "a" and if possible I'm using ".*" or ".+" instead of that.

But I won't discriminate and will recognize arrays as named parameters using the "*" and "+" array-modifiers. I can use this internally. Such as new BlankClip has a parameter with signature "[colors]a"; direct color values can be specified. Now it became "[colors]f+" so it has to be an array of one or more floats.

This way I could even specify that the function requires float numbers in the array (which are converted to integer inside for integer color spaces) while the old version with "[colors]a" needed more checking (no zero size, no strings inside, etc.) in the filter creation.

So work in progress.

As I said using "." instead of array is working right now, compatible with anything.

Internally [paramname]f+ style is working as well but your external plugin will fail to load into older AviSynth versions if this parameter-list syntax is used.

If this concept works, I can try the proposed "()" modifier in the name of the parameter, which is expected to get your plugin loaded into any Avisynth version but still you can use the named parameter array concept if parameter is given when used in future Avisynth+. Thus a filter definition syntax [colors]f+ would become into [colors()]f or similar, but it's not too nice.

The incompatibility lies in (among other things) that named parameters should be followed by exactly one 'type' character

MeteorRain

2nd May 2020, 13:07

In the example of c[sstring]s[ssx]s[sstring()]f[ssx()]f

The good thing is -- in old version it interprets it as
sstring: string
ssx: string
sstring(): float -- which can only be read by _args[3]
ssx(): float -- which can only be read by _args[4]

Because the plugin should not read anything beyond 2, all it could read are 1 clip and 2 strings.

In new version it interprets it as
sstring: string or float[]
ssx: string or float[]

so user can pass either string or array, and the plugin should detect if _args[1] and [2] is a string or an array. If it reads a string, it parses string to array. If it reads an array, it loops through it to get values.

Any non-identifier non [] characters can be used to indicate arrays. So for example, [colors()], [color*], [(colors)], [{colors}] should all work.

MeteorRain

2nd May 2020, 13:18

And it's also possible to completely use a new syntax for argument list. Plugins can send the new version of argument type list instead of using the old one, if it's called by a new version of AVS. I'm never a fan of old syntax, so I think after more than 15 years, it's OK to remove some technical debt and move on. (And backward compatibility is also maintained.)

A very quick way is to use the same / similar format from VapourSynth.

c[sstring]s[ssx]s[sstring()]f[ssx()]f
becomes
clip:clip;sstring:float[]:opt;ssx:float[]:opt

Of course when called from old AVS, a plugin still returns old argument string. New AVS should also be able to parse the old syntax.

Just my $0.02.

pinterf

2nd May 2020, 14:36

In what aspect is VS syntax more elegant aside from using [] for arrays?

videoh

2nd May 2020, 15:11

Anyway, "elegant" is very subjective.

wonkey_monkey

2nd May 2020, 15:29

Personally I can never remember whether the type comes first or the name comes first. VS syntax seems slightly more explicit in that regard.

pinterf

2nd May 2020, 17:02

Personally I can never remember whether the type comes first or the name comes first. VS syntax seems slightly more explicit in that regard.
In case you'd forget just remember to clip:clip :)

Reel.Deel

2nd May 2020, 20:28

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

Feel free to get the ball rolling. A spreadsheet would be a good start :)

qyot27

2nd May 2020, 20:53

Having a spot in the table for which OSes the plugins support would also be beneficial, as more of them begin to get ported to at least Linux, if not the other two.

Myrsloik

2nd May 2020, 23:57

In what aspect is VS syntax more elegant aside from using [] for arrays?

Pascal order (name: type) is obviously always the most elegant!

MeteorRain

3rd May 2020, 01:51

In what aspect is VS syntax more elegant aside from using [] for arrays?

IMHO anything that is easier to read, to parse, to extend, is more elegant. If this is done in a more dynamic / higher level language I would simply use a hash map, or a JSON string because it's more readable, have standard library to parse, and can easily be extended should there be extra information adding to the content.

Now this is an ancient C/C++ project, so I don't want to add too many 3rd party things and too many modern things to it. That's why I didn't propose JSON (adding a JSON library to the dependencies). One (and probably the only one) that is both familiar to plugin authors and more readable, would be VS syntax. Again, I'm brainstorming various ways of doing things. One simple way would be what I said, use non-conflicting annotation to indicate arrays. Ugly, not nice, but is a workaround to support a little more thing. The other simple way would be switching to a more elegant syntax and completely solve this problem.

AVS was an ancient project, and lots of things were done in the way that would have been done differently if today's technologies and concepts are provided. But at the end of the day, it's still your discretion whether to move on from an old decision to a modern-er thing.

real.finder

4th May 2020, 05:17

I just note that Asd did backport SmoothUV and DeDot and DeCross from VS, cool :goodpost:
edit: and MatchHistogram, MSharpen

more about Asd https://forum.doom9.org/showthread.php?p=1871719#post1871719 and https://forum.doom9.org/showpost.php?p=1873049&postcount=4668

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

ok, so I will mention what not has HBD yet

1st is plugins that has VS ports with HBD:-
1 - EEDI3
2 - Dither_resize16/fmtconv
3 - SangNom2/SangNomMod
4 - TTempSmooth
5 - EEDI2
6 - TCanny (there are TCannymod by chikuzen but I think with no HBD)
7 - Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD)
8 - DeblockPP7
9 - median
10 - tbilateral
11 - tedgemask
12 - MSmooth
13 - ASharp
14 - degrainmedian
15 - TDeint

plugins that has VS ports but no HBD:-
1 - scxvid (there are no x64 in avs yet)
2 - hqdn3d (there are avs port but with 16bit hack)
3 - ssiq (there are no x64 in avs yet)

pinterf

4th May 2020, 07:57

Pascal order (name: type) is obviously always the most elegant!
I'm working with Delphi at my proper office work, sometimes I'm mixing up the C the variable-type order (not to mention the assignment ':=' vs. '=' and the comparison operators as well :) )

real.finder

5th May 2020, 22:26

ok, so I will mention what not has HBD yet

1st is plugins that has VS ports with HBD:-
1 - EEDI3
2 - Dither_resize16/fmtconv
3 - SangNom2/SangNomMod
4 - TTempSmooth
5 - EEDI2
6 - TCanny (there are TCannymod by chikuzen but I think with no HBD)
7 - Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD)
8 - DeblockPP7
9 - median
10 - tbilateral
11 - tedgemask
12 - MSmooth
13 - ASharp
14 - degrainmedian
15 - TDeint

plugins that has VS ports but no HBD:-
1 - scxvid (there are no x64 in avs yet)
2 - hqdn3d (there are avs port but with 16bit hack)
3 - ssiq (there are no x64 in avs yet)

and there are some filters seems has no VS ports

1 - VariableBlur (it was planed by tp7 (https://forum.doom9.org/showthread.php?p=1658610&highlight=VariableBlur#post1658610))
2 - frfun7 (useful for Dot Crawl Removal, used in DDComb)
3 - GradFun2db (maybe it can be replaced with f3kdb?)
4 - LGhost

feisty2

6th May 2020, 10:37

I tried to port frfun7 and found it was closed source

real.finder

6th May 2020, 11:28

I tried to port frfun7 and found it was closed source

did you tried ask Prunedtree in IRC for the source code?

Reel.Deel

6th May 2020, 17:02

did you tried ask Prunedtree in IRC for the source code?

I emailed pruned sometime ago and asked him if he would release the source code but no reply. :(

First time I contacted him was thru IRC then email, that is how FRFun7 (2013) came about.

real.finder

6th May 2020, 17:45

I emailed pruned sometime ago and asked him if he would release the source code but no reply. :(

First time I contacted him was thru IRC then email, that is how FRFun7 (2013) came about.

maybe you are not a Developer so he didn't, since he previously was parole that the code should be cleaned and developed before publication (as tp7 said for Checkmate plugin)

anyway, there are always reverse engineering option

feisty2

6th May 2020, 18:22

anyway, there are always reverse engineering option

dude, deciphering assembly is HARD

real.finder

6th May 2020, 18:33

dude, deciphering assembly is HARD

how SEt, tp7 and jackoneill did it then?

anyway even if you got the source code I think it don't has C code just like most old plugins

feisty2

6th May 2020, 18:40

deciphering a few clearly outlined functions written in assembly with possibly also comments is not the same as blind-deciphering an executable... especially if the binary has been heavily optimized or involves some weird shit like C++ name mangling

videoh

6th May 2020, 18:42

Instead of all that reversing nonsense, you have to re-implement the algorithms. What's the big deal?

FranceBB

6th May 2020, 21:12

Instead of all that reversing nonsense, you have to re-implement the algorithms.

Re-implementing the algorithm, makes sense.

there are always reverse engineering option

Out of pure curiosity, you meant using things like IDA Pro and start from there? I'm not an avs developer, but I can tell you that staring at several lines of disassembled code totally undocumented is way beyond my understanding. (And I believe it would be a pain in the b... for many experienced developers as well).

dude, deciphering assembly is HARD

I'm always surprised by how people in the past used to rely on assembly for everything and were so good in it while I can't really wrap my mind around that as I generally lose track of the main picture after just a few lines (i.e I might understand what a single block of code is doing, but I fail to understand what the program as a whole is doing... :( )

(I still remember people of the David Brailsford (https://www.nottingham.ac.uk/news/expertiseguide/computer-science-/professor-david-brailsford-.aspx) era carrying mugs with "Real man code in Assembler" before retiring :( )

feisty2

7th May 2020, 09:43

"Real man code in Assembler"

(certain) engineers code in assembly, mathematicians code in lisp, scientists code in... who knows

anyways, it has nothing to do with "real man"

real.finder

7th May 2020, 16:27

Out of pure curiosity, you meant using things like IDA Pro and start from there? I'm not an avs developer, but I can tell you that staring at several lines of disassembled code totally undocumented is way beyond my understanding. (And I believe it would be a pain in the b... for many experienced developers as well).

I am not a programmer, but I see tp7 said this back then in IRC (about sangnom2)

also it's what SEt did in awarpsharp2

anyway, tp7 got the source code of Checkmate from Prunedtree as I said, so I think any developer can do ask Prunedtree for the code like https://forum.doom9.org/showthread.php?p=1792960#post1792960 and https://forum.doom9.org/showthread.php?p=1825279#post1825279

Groucho2004

7th May 2020, 16:58

(certain) engineers code in assembly, mathematicians code in lisp, scientists code in... who knows

anyways, it has nothing to do with "real man"It used to be a joke a long time ago (or maybe still is?), particularly when C# was introduced (as far as I recall).

Real men code in C++
No, real men code in C
No, real men code in assembler
No, real men punch in hex code on numeric keyboards
etc...

By the way, this is a piece of art:

https://i.postimg.cc/90sdNdR8/Dvrm3be-Uw-AAMCpg.jpg

FranceBB

7th May 2020, 18:57

By the way, this is a piece of art

Uhhh! Hexadecimal with a 7 Segments display! :D
I studied those in my Digital Electronics class!
This is what I came up with to count in Hex (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F) in a 7 Segments Display:

https://scontent-lhr8-1.xx.fbcdn.net/v/t1.0-9/s960x960/89858123_3065862253445594_4431349507128557568_o.jpg?_nc_cat=102&_nc_sid=e007fa&_nc_ohc=3rIGxBUhJ6kAX_cSlds&_nc_ht=scontent-lhr8-1.xx&_nc_tp=7&oh=d5f5e6f724292570533ae45ebc24f162&oe=5EDB51E6
https://scontent-lht6-1.xx.fbcdn.net/v/t1.0-9/s960x960/89872085_3065861016779051_1406615868342796288_o.jpg?_nc_cat=105&_nc_sid=e007fa&_nc_ohc=ZnwebgBMjEIAX-jEwla&_nc_ht=scontent-lht6-1.xx&_nc_tp=7&oh=9194f7524d44e3566ec534a14ef87d84&oe=5EDB9DC5

I studied a lot for that exam and I was sure I was going to kill it, but unfortunately things didn't go as planned I've got 23 out of 30 :(
I was so upset that day... :(
(but I accepted the grade of course, I have never refused one, that's my "mantra" xD)
That was back when I was studying for my bachelor degree...
Will I ever get my master degree? Who knows...

Groucho2004

7th May 2020, 19:02

Uhhh! Hexadecimal with a 7 Segments display! :D
I studied those in my Digital Electronics class!Cool, a fellow electronics engineer. How old are you, if I may ask?

feisty2

7th May 2020, 19:09

Will I ever get my master degree? Who knows...

masters are mostly cash-cow programs, go for a PhD program instead if ur interested in grad schools

Groucho2004

7th May 2020, 19:13

feisty, I only just noticed that you moved from CA to RI, how are you handling the temperature difference?

feisty2

7th May 2020, 19:35

I haven't, I changed my location in advance cuz I will begin my graduate study at one of the institutions on college hill, I ain't tellin which one

Rumbah

7th May 2020, 21:36

masters are mostly cash-cow programs, go for a PhD program instead if ur interested in grad schools

There is no PhD without a master first in Germany.

FranceBB

7th May 2020, 22:10

Cool, a fellow electronics engineer.

Actually, it was supposed to be Computer Science Engineering but when I got there I found out that we had many exams in common with those studying Electrical Engineering. I asked one of the professors why and he said "You see, Computer Science Engineering didn't exist years ago and it was Electrical Engineering" so years passed but some universities are very conservative in their courses and they kept Electrical Engineering and Computer Science Engineering closely bonded together. I had exams on the whole analog electronic part of which the first exam was huge as it covered everything from where physics II left with Induction Motors, Solar Panels etc, then I had the whole Control System part with Bode Plots and an introduction to Digital Electronics, then the whole part about Digital Electronics from the basics up to FPGA. The idea behind that was to teach us how components like CPUs, RAM etc work at a very deep level from an electrical point of view so that we could design a system. The thing is that although I learned many interesting things from linear algebra to multivariable calculus, to fluid dynamics and a lot of electrical engineering stuff, I never learned how to code properly; as a matter of fact, professors were very keen to make us code using programming languages that I'll never use in real life ('cause I'm an encoder) like Verilog and VHDL for hardware-programming or MATLAB for other kind of things. When I enrolled at University in a Computer Science Engineering class I thought things were going to be very different...

How old are you, if I may ask?

My age has never been a secret, in fact it's also in my profile here on Doom9. :) (I'm 26 by the way; I'm probably younger than you think).

masters are mostly cash-cow programs, go for a PhD program instead if ur interested in grad schools

I know but I can't get a PhD without a master degree; Anyway, I've seen the cost of university in the U.S and it's insane... luckily in Europe they cost way less as most of them are public.

CA

I've been in California in 2013 and I stayed there for three months, during summer. I was in Claremont, close to LA, in a University Campus where I improved my English a lot. Years later I tried to go back there to work in the U.S but VISA are a nightmare and I only got a student visa which they were willing to renew if I wanted as they said that if I went to university there I had many more chances to get a working visa and eventually a Green Card, however I had no money to pay for my education without working and I didn't really want to get a student loan as I know that some people are still paying their debs years after leaving university, so I flew to the UK ('cause I thought "what's the closest English-speaking country I can move to without a Visa? - thank you EU -") but then I heard of a company that was looking for an encoder in Berlin, I applied and I've got the job, so I moved to Röntgental (which is close to Berlin, but smaller and cheaper). After some time, I got transferred to Sky and "the rest is history". :)

MeteorRain

7th May 2020, 22:39

I hate schooling so I abandoned the idea to go for a PhD.

(Should a real man be coding on a mechanical computer?)

StainlessS

7th May 2020, 22:51

They had (some years back) the finally completed analytical engine in the sciece museum, London, Kennsington I think.
Apparently it works.

As mechanical a computer as you are likely to find. [The Charlie Babage thiing]

EDIT:
Whatever happened to the old mechanical 'sliderule' calculator type thing, where you stuck pegs in holes [or similar]
and turned a handle and got an answer, handheld devices, probably not too disimilar to the Babage thiing.
[I think I had one as a child, or at least seen one]

EDIT: "or similar", actually a metal slide thing, rather than peg, I think.

EDIT:
I remembered. My auntie [bout 18 months older than me] had one of these when I was about 10 YO.
Put the pen like nib in saw tooth slider thing, and dial in the numbers.
Pull UP/OUT, the cross bar whatsit on top of device, and hey presto, the answer.
https://i.postimg.cc/KRf246vs/Vintage-Fedtro-Precision-Mechanical-Pocket-Calculator-Made-In-Japan-Sold-For-69-Cents-Circa-1966.jpg (https://postimg.cc/KRf246vs)
https://i.postimg.cc/v1dkzXB6/calc.jpg (https://postimg.cc/v1dkzXB6)

LigH

8th May 2020, 08:01

I remember how I entertained my college class by tracing the self-modifying code of the EICAR test virus in DEBUG.COM ... okay. Back to AviSynth+ please?

tormento

8th May 2020, 09:47

Real men code AVS+ plugins.

So go back to work. :)

Dogway

8th May 2020, 11:17

and there are some filters seems has no VS ports

1 - VariableBlur (it was planed by tp7 (https://forum.doom9.org/showthread.php?p=1658610&highlight=VariableBlur#post1658610))
2 - frfun7 (useful for Dot Crawl Removal, used in DDComb)
3 - GradFun2db (maybe it can be replaced with f3kdb?)
4 - LGhost

Fortunately recently some of the plugins I used more frequently were updated (SSIM, SubtitleEx, AvsInpaint), still miss a few of them, maybe you can add them to a spreadsheet:
JpegSource
SoundOut
VScope

pinterf

12th May 2020, 21:33

Things that happened lately.

AviSynth+

Last week I have successfully applied the 'old' type+ and type* syntax on _named_ array function definitions. e.g. [colors]f+
It was not straightforward because there are user defined functions, function objects, parameter type and name matching logic. So it was much harder task than I have anticipated.
Future plugins using this parameter syntax will fail to load on older Avisynth hosts, but if someone would use array and this syntax then they must use AddFunction dynamically.

There are problems with those CPP v2.5 'baked code' interface plugins which are using "Invoke", latest example was GRunT for avs 2.58. I was trying to find a solution if providing a special ancient ScriptEnvironment for them is feasible. But I failed, way too difficult and messes up the internals of the current core.

I was experimenting with putting 1D and 2D lut into the core - using Expr - but unfortunately it won't be a couple of hours' work. I postponed the project.

Still considering on what other things would be nice to appear in the extended IScriptEnvironment but I think I'll make a feature freeze on it soon. Not to mention of documenting all new features.

Plugins

TDeint.
You know how angry I am at all 2.5 plugins. So I met TDeint again some weeks ago.
TDeint did not have a proper stable x64 port and it was a 2.5 CPP plugin. I started to work on it and sorry, I cannot stop the project now. I'm getting into deeper and deeper in the modifications which are all have to be done to have a proper source again.
TDeint and TIVTC have many-many common parts in source, which are not easy to detect. Piles of hundred line copy pastes with a minor difference (a part of them is because there existed no templates in C++ at that time tritical authored it), thousand lines of inline hand optimized asm code without C.

I worked many labour-weeks on TIVTC three years ago and had fed up a bit for this reason:) It's a never-ending story.
Three years ago I was optimistic and put up the actual TDeint on github together with TIVTC (iin case of I feel like working on it) but I didn't touch it.
Until last week.

Haha, you mentioned a week ago that TDeint has no high bit depth port? It didn't even support Avisynth 2.6 basic colorspaces. So all these issues (plus a ping on github) forced me to look at it again.
Lately YV16-YV24-YV411 was added. Today - not released but you can see it on git - I have finished the 10-16 bit port plus greyscale. I'm seeing the end of the tunnel and turned to TIVTC again and I think I won't stop until it's ready 16 bits.

This is a much better entertainment then solving crossword puzzles isn't it, but is a bit time consuming. RescueMyTime reported 300+ hours for the last three months (plus my official work), I'm so glad that I'm saving two hours per day on commute :) thanks to this stupid covid.

(Out of couriosity, do other developers watch films, videos or read books?

Nevertheless I'm just moaning :) So what about chikuzen's plugins (which have to be rebuilt for next Avs+?) Will they be maintained in the future by him? If not, what is order of their importance?

real.finder

12th May 2020, 21:42

Nevertheless I'm just moaning :) So what about chikuzen's plugins (which have to be rebuilt for next Avs+?) Will they be maintained in the future by him? If not, what is order of their importance?

he didn't show up for days so I don't think he will back soon

https://github.com/chikuzen/TMM2 since you work on TDeint

https://github.com/chikuzen/MPEG2DecPlus (this one also need HBD deblock update from https://github.com/mysteryx93/Avisynth-Deblock)

https://github.com/chikuzen/yadifmod2

https://github.com/chikuzen/DCTFilter

https://github.com/chikuzen/TEMmod

https://github.com/chikuzen/TCannyMod (I have fork for names changes https://github.com/realfinder/TCannyMod)

https://github.com/chikuzen/CombMask (also I have fork for names changes https://github.com/realfinder/CombMask)

https://github.com/chikuzen/ReduceFlicker

https://github.com/chikuzen/PlanarTools

FranceBB

12th May 2020, 23:00

RescueMyTime reported 300+ hours for the last three months (plus my official work), I'm so glad that I'm saving two hours per day on commute :) thanks to this stupid covid.

(Out of couriosity, do other developers watch films, videos or read books?)

First of all, thank you for all the time you spent on Avisynth for this community.
If it wasn't for you we would have been in a way worse situation right now.
If Avisynth is used across a wide range of users (both individuals and companies) today is thanks to all the developers but in particular thanks to you.
You not only kept the core, the frameserver itself, updated, but you also modernized a lot of plugins.
And... sure, you could have just been sitting on the couch watching TV all day like many people are doing during this pandemic, but thanks God you didn't; instead, you spent a lot of hours of your own spare time on Avisynth and we're really thanking you for this.
Every evening, in the UK, people are clapping for healthcare workers and their efforts; well, Ferenc, Doom9 is clapping for you.
Thank you for everything you've done.
Keep up the good work,
Frank.

Groucho2004

13th May 2020, 01:17

First of all, thank you for all the time you spent on Avisynth for this community.
...
If Avisynth is used across a wide range of users (both individuals and companies) today is thanks to all the developers but in particular thanks to you.
...
And... sure, you could have just been sitting on the couch watching TV all day like many people are doing during this pandemic, but thanks God you didn'tYou have to make up your mind, either thank Ferenc or your imaginary friend.

MeteorRain

13th May 2020, 03:05

Chikuzen is active on twitter though. But haven't seen him talking on slack or here.

https://twitter.com/AviSynthPlus/status/1260366139500007424?s=19

zambelli

13th May 2020, 03:15

I'm running into some strange colorspace/bitdepth conversion issues in AviSynth+ 3.5 r3106.

For example, this script works fine, returns RGB64:
ColorBars(1920,1080, "YV12")
ConvertBits(16)
ConvertToRGB64(matrix="Rec709")

This script also works fine, also returns RGB64:
ColorBars(1920,1080, "YV12")
ConvertToRGB64(matrix="Rec709", chromaresample="spline36")

However, this script throws a "ConvertToRGB: ChromePlacement and ChromeResample options are not supported" error:
ColorBars(1920,1080, "YV12")
ConvertBits(16)
ConvertToRGB64(matrix="Rec709", chromaresample="spline36")
I don't see why it wouldn't be supported though - U and V in YUV420P16 are quarter resolution, so chroma would need to be resampled to produce RGB64.

Finally, this script crashes both VirtualDub2 and FFmpeg:
ColorBars(1920,1080, "YV12")
ConvertToRGB64(matrix="Rec709")
ConvertBits(8, dither=1)

Bugs or user error?

Reel.Deel

13th May 2020, 05:43

So what about chikuzen's plugins (which have to be rebuilt for next Avs+?) Will they be maintained in the future by him? If not, what is order of their importance?

asd posted some updated plugins with the v8 interface on the AviSynth+ x64 plugins page on the wiki: (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins)

(Added CombMask v8 interface)
(Added DCTFilter v8 interface)
(Added RawSourcePlus with fixed 10/12/14-bit input, v8 interface)
(Added ReduceFlicker v8 interface)
(Added TMM2 v8 interface)

I would be nice to have chikuzen's updated plugins on GitHub, much more reliable then random download links as they are now. Also, some of the plugins have additional commits and there was never a formal release.

pinterf

13th May 2020, 07:51

asd posted some updated plugins with the v8 interface on the AviSynth+ x64 plugins page on the wiki: (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins)

(Added CombMask v8 interface)
(Added DCTFilter v8 interface)
(Added RawSourcePlus with fixed 10/12/14-bit input, v8 interface)
(Added ReduceFlicker v8 interface)
(Added TMM2 v8 interface)

I would be nice to have chikuzen's updated plugins on GitHub, much more reliable then random download links as they are now. Also, some of the plugins have additional commits and there was never a formal release.
I wonder if they are simply recompiled or adaptively using the frame-property preserving NewVideoFrameP as well. So are they are good only for the new v8 or can work with any former avs versions?

Yes, git is a must have. On one hand now we have to download them and make manual source-code comparison to see what has been changed.

When they are getting new features (such as 10+ bits) in the future the sources have to be put back to git. And because of the credits and source history they have to be forked from the original repository and the new developer must either forget or reinvent these "offline" changes.

I'd encourage everyone to use github in order not to break development history.

Fork, modify, commit, document, release.

kedautinh12

13th May 2020, 10:37

I find out a fork from maki's MPEG2DecPlus 0.1.1 on github, is it added v8 interface or not??
https://github.com/299792458m/DGIndex_mod

tormento

13th May 2020, 12:57

I'd encourage everyone to use github in order not to break development history.
Perhaps who maintains wiki x64 plugin page could use GitHub for "lost" authors or not willing to.

tormento

13th May 2020, 14:07

Developers, look at Intel Parallel C++ (https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/dpc-compiler.html).

It promises to reuse code across hardware targets (CPUs and accelerators such as GPUs and FPGAs) and also perform custom tuning for a specific accelerator.

I have access to Intel Resources from University but I am not a programmer. Perhaps someone could get a look and start to think about moving AVS+ plugins to next stage?

MeteorRain

13th May 2020, 14:11

There was already C++AMP. I used that a few years ago but it's still not popular till today.

pinterf

13th May 2020, 15:00

I find out a fork from maki's MPEG2DecPlus 0.1.1 on github, is it added v8 interface or not??
https://github.com/299792458m/DGIndex_mod

Note that v8 update will only be necessary if plugin is using the non-finalized IScriptEnvironment2 Avisynth+ interface calls.

Plugins which were not relying on IScriptEnvironment2 will be working fine.

jpsdr

13th May 2020, 16:46

And... sure, you could have just been sitting on the couch watching TV all day like many people are doing during this pandemic...
Yes i did... A lot of animes, some old 80's SF/Heroic Fantasy cheaped movies, and also reading manga and comics...:D

pinterf

13th May 2020, 17:23

My today's recommendation: The Plague by Albert Camus. I've read it in last November, pandemic started in December.

StainlessS

13th May 2020, 18:48

Dont blame your self P, you can in no way be held responsible for this bloody lockdown, coincidence only, really.

EDIT: to below.
David Attenborough, yep, on much safer ground there :)

pinterf

13th May 2020, 19:44

Dont blame your self P, you can in no way be held responsible for this bloody lockdown, coincidence only, really.
Yep, though my currently finished book is neutral, I hope (Zoo Quest by David Attenborough)

Reel.Deel

14th May 2020, 02:54

I wonder if they are simply recompiled or adaptively using the frame-property preserving NewVideoFrameP as well. So are they are good only for the new v8 or can work with any former avs versions?

Yes, git is a must have. On one hand now we have to download them and make manual source-code comparison to see what has been changed.

When they are getting new features (such as 10+ bits) in the future the sources have to be put back to git. And because of the credits and source history they have to be forked from the original repository and the new developer must either forget or reinvent these "offline" changes.

I'd encourage everyone to use github in order not to break development history.

Fork, modify, commit, document, release.

Ask, and you shall receive: https://github.com/Asd-g?tab=repositories

asd created a GitHub account, the modified plugins from chickuzen are there. by looking at the commits I don't think they are just recompiled, then again I am no programmer :).

******
asd: if you are reading this, I just want to say thank you for all of the plugins you've uploaded on the wiki. Please check the wiki talk page in the coming days, I have a question for you. Thanks again

pinterf

14th May 2020, 07:14

Ask, and you shall receive: https://github.com/Asd-g?tab=repositories

asd created a GitHub account, the modified plugins from chickuzen are there. by looking at the commits I don't think they are just recompiled, then again I am no programmer :).

Great, thank you, Asd-g, you spent quite a few hours with the updates.

kedautinh12

14th May 2020, 07:20

Asd-g, if you are reading this post, can port back there plugins from vapoursynth
https://forum.doom9.org/showpost.php?p=1909447&postcount=841

tormento

14th May 2020, 09:44

I find out a fork from maki's MPEG2DecPlus 0.1.1 on github, is it added v8 interface or not??
https://github.com/299792458m/DGIndex_mod
This (https://github.com/Asd-g/MPEG2DecPlus) for sure is, looking at sources.

videoh

14th May 2020, 10:18

What is this "v8 interface" you are talking about?

pinterf

14th May 2020, 10:37

What is this "v8 interface" you are talking about?

It's still in a development branch called neo.

IScriptEnvironment has been extended with some new functions which broke those plugins which were using avs+ specific IScriptEnvironment2. So such plugins have to be rebuilt with adaptively using new IScriptEnvironment functions.

The biggest change is the frame property support.
Just like in VS.
It is only the framework. Interface support and fp passing throughout all internal Avisynth+ plugins.

Ideally every filter in the filter chain has to able to pass frame properties on. Such plugins should use a V8 interface NewVideoFrameP instead of NewVideoFrame. But only if V8 host is detected.

Like this:

Technique is very simple.

Read about the changes:
https://github.com/AviSynth/AviSynthPlus/blob/neo/distrib/Readme/readme_history.txt

Grab new Avisynth headers (at the moment from here):
https://github.com/AviSynth/AviSynthPlus/tree/neo

Check V8 availability on create:
https://github.com/pinterf/TIVTC/blob/master/src/TDeint/TDeinterlace.cpp#L261

Use the new feature adaptively
https://github.com/pinterf/TIVTC/blob/master/src/TDeint/TDeinterlacePlanar.cpp#L169

Or when you have a source filter you can add frame properties just like in VapourSynth.

Obviously it is just a framework it will require many more steps later to use this feature properly and along with specific convertions and rules.

Myrsloik

14th May 2020, 10:43

Interesting and familiar looking stuff. What happens with plugins that don't pass along properties? They all just disappear or you use some simple rule to try to pass them along anyway?

kedautinh12

14th May 2020, 10:44

This (https://github.com/Asd-g/MPEG2DecPlus) for sure is, looking at sources.

I already seen it, thanks

videoh

14th May 2020, 11:15

It's still in a development branch called neo.
...
Obviously it is just a framework it will require many more steps later to use this feature properly and along with specific convertions and rules.
Thank you for the explanation. I suppose then it's not something to worry about quite yet as a filter author.

pinterf

14th May 2020, 11:18

Interesting and familiar looking stuff. What happens with plugins that don't pass along properties? They all just disappear or you use some simple rule to try to pass them along anyway?
Familiar, yes. Thank you in advance, I've never thought that the concept would work in any Avisynth without breaking everything.

Plugins which do not pass properties will unfortunately break the chain.

videoh

14th May 2020, 11:53

Is there any documentation of the properties and how to use them? Couldn't make much sense out of it from looking at avisynth.h. Thank you.

tormento

14th May 2020, 13:44

asd created a GitHub account, the modified plugins from chickuzen are there. by looking at the commits I don't think they are just recompiled, then again I am no programmer :).
How I wish everybody put dll version too in the compiled build.

Myrsloik

14th May 2020, 13:55

Familiar, yes. Thank you in advance, I've never thought that the concept would work in any Avisynth without breaking everything.

Plugins which do not pass properties will unfortunately break the chain.

You can't do something like my avisynth compatibility layer? Copy the properties from the input frame in secret?

(of course this in some cases need plugin parameter parsing and a deep knowledge of framerate modifications for plugins that do such things)

pinterf

14th May 2020, 14:18

You can't do something like my avisynth compatibility layer? Copy the properties from the input frame in secret?

(of course this in some cases need plugin parameter parsing and a deep knowledge of framerate modifications for plugins that do such things)
At the moment I cannot imagine how could I do that in a consistent way with parameter parsing.

Anyway when things are settling down I'd like to reproduce an issue with VapourSynth with which I had troubles and had to fix.

But probably you can answer it right now.

I added property "X" to a frame.
Then later (in another "ScriptClip") I added property "X" index #1 (2nd array element).

This array addition was not thread safe, second addition appeared multiple times in propShow when used in an MT environment. So the container was not detached in this case.

The fix was in this commit
https://github.com/AviSynth/AviSynthPlus/commit/f38951eb978def978a35ea210148e05c60117290

Probably this one has no proper use case but I encountered the issue during my mt stress tests.

Myrsloik

14th May 2020, 14:32

At the moment I cannot imagine how could I do that in a consistent way with parameter parsing.

Anyway when things are settling down I'd like to reproduce an issue with VapourSynth with which I had troubles and had to fix.

But probably you can answer it right now.

I added property "X" to a frame.
Then later (in another "ScriptClip") I added property "X" index #1 (2nd array element).

This array addition was not thread safe, second addition appeared multiple times in propShow when used in an MT environment. So the container was not detached in this case.

The fix was in this commit
https://github.com/AviSynth/AviSynthPlus/commit/f38951eb978def978a35ea210148e05c60117290

Probably this one has no proper use case but I encountered the issue during my mt stress tests.

Doh, will have to fix that one. I'm surprised nobody noticed it for so many years.

And a bit of a warning: I consider VSMap/VSVariant and such to be some of the absolutely worst bits of code that I want to redo some day soon so don't copy it too much.

Random scribbles on things I also think are suboptimal in general before you copy something even worse: https://github.com/vapoursynth/vapoursynth/issues/59

Groucho2004

14th May 2020, 14:39

Grab new Avisynth headers (at the moment from here):
https://github.com/AviSynth/AviSynthPlus/tree/neoI see you added CS_RGBP8 and CS_RGBAP8 which are the same as CS_RGBP and CS_RGBAP. I guess we don't need the latter ones any more, right? I'm asking because if I check the colorspaces in a switch statement the compiler blurts out an error about duplicate definition (or something to that effect).

pinterf

14th May 2020, 14:42

I see you added CS_RGBP8 and CS_RGBAP8 which are the same as CS_RGBP and CS_RGBAP. I guess we don't need the latter ones any more, right? I'm asking because if I check the colorspaces in a switch statement the compiler blurts out an error about duplicate definition (or something to that effect).
Yes, you don't need the non-8 version.

Groucho2004

14th May 2020, 14:47

Yes, you don't need the non-8 version.Thanks.

pinterf

14th May 2020, 14:57

Random scribbles on things I also think are suboptimal in general before you copy something even worse: https://github.com/vapoursynth/vapoursynth/issues/59
Thanks the warning I won't be hyperactive. :)

feisty2

18th May 2020, 18:38

Boulder

19th May 2020, 14:29

Is there something like ResampleHQ in Avisynth+, that could be used to downscale HDR sources properly and get 16bit output? I think the original RHQ only outputs 8bit and probably only works well with non-HDR sources.

feisty2

19th May 2020, 14:33

it's simply gamma aware resampling, many alternatives.
also resampling under linear light introduces way more ringing and I don't actually consider it "HQ"

Boulder

19th May 2020, 14:37

also resampling under linear light introduces way more ringing and I don't actually consider it "HQ"

What would you suggest for downscaling HDR sources?

feisty2

19th May 2020, 14:44

https://github.com/WolframRhodium/VapourSynth-dpid

Boulder

20th May 2020, 20:41

videoh

20th May 2020, 20:47

Source filters automatically use MT_SERIALIZED. What makes you think it is using more than one thread?

Boulder

20th May 2020, 21:03

Source filters automatically use MT_SERIALIZED. What makes you think it is using more than one thread?

At least the thread count increases along with Prefetch, so I gathered it will actually use them all.

I need to test the MVTools stuff to see what happens - my larger denoiser function stalls quite bad with a high Prefetch value and GPU usage is over 90% while the frameserver should have enough to do instead of requesting new frames from DGSource.

Groucho2004

20th May 2020, 21:30

Is it possible to force the source filter, DGSource in this case, to use only one thread? If I use a high value with Prefetch, GPU usage shoots through the roof and seems to slow things down considerably (tested with AVSMeter). With Vapoursynth, I usually get 3-5% GPU usage with a very similar processing chain (denoise and resize, UHD source).Do you have other GPU filters in the chain?

Edit: Ran a test with this simple script:
DGSource("src.dgi")
#prefetch(8)

Without prefetch:
Frames processed: 3810 (0 - 3809)
FPS (min | max | average): 200.9 | 849.4 | 789.9
Process memory usage (max): 121 MiB
Thread count: 9
CPU usage (average): 26.6%

GPU usage (average): 27%
VPU usage (average): 71%
GPU memory usage: 417 MiB
GPU Power Consumption (average): 39.5 W

With prefetch(8):
Frames processed: 3810 (0 - 3809)
FPS (min | max | average): 1.731 | 537125 | 57.77
Process memory usage (max): 191 MiB
Thread count: 17
CPU usage (average): 17.4%

GPU usage (average): 26%
VPU usage (average): 77%
GPU memory usage: 417 MiB
GPU Power Consumption (average): 39.5 W

As you can see, GPU usage and GPU memory do not change proving that there's only one GPU thread in both scenarios. Speed and efficiency however take a serious hit.

Boulder

20th May 2020, 22:19

No, just the source decoding. I just tested an MVTools based denoising function (basically MCDegrainsharp with some chained MRecalculate etc.) I created in Avisynth and Vapoursynth, doing pretty much the same thing in both. In AVS+, the GPU usage is over 90% and AVSMeter proceeds very slowly, like 2-3 fps. In Vapoursynth, the GPU usage is under 10% and CPU usage over 95%. Speed in vspipe is 11-12 fps.

I'll have to strip down the function part by part to see what happens. I just find it strange that GPU decoding is being done so much compared to Vapoursynth.

qyot27

20th May 2020, 23:32

AviSynth+ 3.6.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Added predefined macros for ARM processors. Tested on Raspberry Pi 4B with the aarch64 image of Ubuntu 20.04.
Added support for disabling the Intel SIMD intrinsics. Gets automatically disabled on non-x86 targets.
Added submodule to allow macOS 10.13 and 10.14 to build AviSynth+ with the native Clang compiler
Fixed some warnings on GCC (wangqr)
Implemented GetNumPhysicalCPUs on Linux and macOS (wangqr)
New function:

SetMaxCPU(string feature)

string "feature"

"" or "none" for zero SIMD support, no processor flags are reported
"mmx", "sse", "sse2", "sse3", "ssse3", "sse4" or "sse4.1", "sse4.2", "avx, "avx2"

parameter is case insensitive.
Note: "avx2" triggers FMA3 flag as well.

Processor options w/o any modifier will limit the CPU flag report to at most the processor level.
When "feature" is ended by '+', relevant processor feature flag will be switched on
When "feature" is ended by '-', relevant processor feature flag will be removed
Multiple options can be put in a comma separated list. They will evaluated in that order.

Examples:
SetMaxCPU("SSE2") reports at most SSE2 processor (even if AVX2 is available)
SetMaxCPU("avx,sse4.1-") limits to avx2 but explicitely removes reporting sse4.1 support
SetMaxCPU("C,avx2+") limits to plain C, then switches on AVX2-only support
Script array for NEW_AVSVALUE define are working again. (default in Linux build experimental)
Fix: Mix/Max Runtime function 32bit float chroma: return -0.5..0.5 range (was: 0..1 range)
AviSynth+ enhancements by Nekopanda (Neo fork)
Allow multiple prefetchers (MT) (mentioned earlier)
Multithreading and deadlock fixes for ScriptClip
(originally I intended to pull only Neo changes which were fixing an old AVS+ bug,
namely ScriptClip and multithreading. But I was not able to do that without pulling
nearly everything from Neo)
Caching enhancements.
SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment
ScriptClip and variable stability in multithreading.
UseVar, special filter, opens a clean variable environment in which only the
variables in the parameter list can be seen.
"escaped" string constants: with e prefix right before the quotation mask
n"Hello \n" will store actual LF (10) control character into the string
\n \r \t \0 \a \f \\ and " are converted
Introduce function objects into scripts
Functions can appear as standard Avisynth variables and parameters (AVSValue type='n')
https://github.com/nekopanda/AviSynthPlus/wiki/Language-New-Features
Even with variable capture [] (like in GRuntT args)
Filter graph. Switch it on by putting SetGraphAnalysis(true) at the beginning of the script.
Dump to text file with DumpFilterGraph. E.g. DumpFilterGraph("graph.txt", mode=2)
Frame properties (still from Neo!)
(experimental, we have planned it in Avs+, probably we'll try to follow the VapourSynth methods(?))
Fix: Multithreading enhancements and fixes (Nekopanda, from Neo fork)
Fix old ScriptClip (runtime filters) issue
In this example "current_frame" variable was not seen by YDifferenceFromPrevious scripted within SubTitle
resulting in "ERROR: Plane Difference: This filter can only be used within run-time filters" message
Now this script finally works:

SetLogParams("log.txt", LOG_DEBUG)
ColorBars(width=640, height=480, pixel_type="yv12")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious))")
Prefetch(4)
Fix deadlock of ScriptClip on MT
MT improvement
Allow multiple Prefetchers
Add argument to Prefetch to change # of prefetch frames without changing # of threads( ex. Prefetch (clip c, int threads, int "frames") )
In the original Plus, you could use only one Prefetch, but you can use any number of CUDA versions.
Also, an argument has been added to specify the number of frames to prefetch.
Prefetch (1,4) # Make 1 thread stand and prefetch 4 frames
By doing so, flexible parallelization configuration is possible, such as pipeline parallelization.

*threads*
Number of threads. If it is 0, it passes without doing anything.

*frames*
Number of frames to prefetch.
Again, if it is 0, it passes without doing anything.
Fix: BuildPixelType: chroma subsampling of sample clip was ignored.
POSIX: better behaviour under non-Windows because of having multiple sized fixed fonts, not only a single size=20 one.
e.g. MessageClip(), Info(), Version(), ColorYUV "show", internal ApplyMessage
Text filter:
font types with
"Terminus" fixed fonts added (12-14-16-18-20-22-24-28-32, regular + bold)
"Info_h" good old 10x20 fixed font kept under this name
much more international unicode characters (1354), use utf8=true under Windows
use fontname parameter (default "Terminus", other choice is "info_h")
use font_filename parameter (accepts BDF fonts at the moment import is probably not too smart but worked for Terminus)
use size parameter (12 to 32, if no size is available, a smaller one is chosen but at least the smallest one)
new parameter: bold (default false)
Info() filter: when parameter "size" < 0, font is automatically enlarged over 640x480
(POSIX limit: minimum size is 12, maximum size is 32 limited by available fixed fonts)")
SIL OPEN FONT LICENSE added because of usage of Terminus fonts)
able to build w/o GDI and font rendering engine under Windows, so that text-overlay filters
work like in POSIX version of AviSynth+ (mainly for my development test)
Use with NO_WIN_GDI define.
Fix: ReplaceStr when the pattern string to be replaced is empty
New:
Exist() to have bool utf8 parameter
This is another function to have utf8 option:
Usage: b = Exist("Здравствуй.mkv",utf8=true). Avs file is saved as utf8 w/o BOM
Fix: broken Exist for directories (regression appeared in 3.5.0)
Fix: ColorYUV: really disable variable search when parameter "conditional" is false
Development:
ScriptEnvironment::VSprintf: parameter (void *) is changed back to va_list.
May affect C interface (avs_vsprintf) and CPP interface (ScriptEnvironment::VSprintf)
Enhanced: Planar RGB to YUV 444 10-14 bits: more precision (32 bit float internally)
Enhanced: Planar RGB to YUV 444 10-16 bits: AVX2 (speed improvement)

magnetite

21st May 2020, 00:24

Upgrading Avisynth+ from 3.5.1 to 3.6.0 gives MeGUI an access violation error. Uninstalling it and reverting back to Avisynth+ 3.5.1 fixes it.

Avisynth:
-Reverted from 3.6.0 to 3.5.1
-Take ownership of folder, as well as the DLL in system32 folder
-When installing Avisynth+ with the VC++ redistributables exe, I right clicked and ran as admin.

MeGUI:
-Downloaded and installed a fresh 2913 64-bit zip file.
-Updated it, turned off the included Avisynth.
-Took ownership of the folder.
-When re-installing, I right clicked and ran as admin.

Faulting application name: MeGUI.exe, version: 1.0.2913.0, time stamp: 0x5d962e5b
Faulting module name: avisynth.dll, version: 3.6.0.0, time stamp: 0x5ec59d7e
Exception code: 0xc0000005
Fault offset: 0x0000000000095020
Faulting process id: 0x1424
Faulting application start time: 0x01d62efcf2d9fcf1
Faulting application path: C:\MeGUI 64-bit\MeGUI.exe
Faulting module path: C:\WINDOWS\SYSTEM32\avisynth.dll
Report Id: da2e7f88-bfbd-4fd7-b1ff-729d933d58d6
Faulting package full name:
Faulting package-relative application ID:

Had similar issues when trying out the 3.5.2 install of Avisynth+.

qyot27

21st May 2020, 01:32

Post the output of (https://forum.doom9.org/showthread.php?t=174797)
avsmeter64 avsinfo

magnetite

21st May 2020, 02:01

Here's the log.

Groucho2004

21st May 2020, 02:13

Here's the log.
Approval of that attachment could take a loooong time. Post to pastebin.

magnetite

21st May 2020, 02:27

Okay, here's the avsinfo (https://pastebin.com/yXWP2494) log and the Avisynth+ 3.6.0 (https://pastebin.com/M0wY17ui) setup log.

qyot27

21st May 2020, 04:25

Had similar issues when trying out the 3.5.2 install of Avisynth+.
The problem is on MeGUI's side. They hardcode each individual AVISYNTH_INTERFACE_VERSION to specific routines in their homespun AviSynthWrapper.dll thing and any substantive version bumps to the AviSynth API will therefore make MeGUI choke on itself.

This is what gdb tells us about what MeGUI is doing:
(gdb) r
Starting program: /e/Documents/MeGUI-2913-64/MeGUI.exe
[New Thread 10080.0x15f0]
[New Thread 10080.0x1a0c]
[New Thread 10080.0x2e14]
[New Thread 10080.0x1b8c]
[New Thread 10080.0x2884]
[New Thread 10080.0x2944]
[New Thread 10080.0x2b1c]
[New Thread 10080.0x1ca0]
[New Thread 10080.0x6bc]
[New Thread 10080.0x228c]
[Thread 10080.0x228c exited with code 0]
[New Thread 10080.0x93c]
[New Thread 10080.0x1518]
[New Thread 10080.0x720]
[New Thread 10080.0x2964]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00007ffc08765020 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
(gdb) bt
#0 0x00007ffc08765020 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#1 0x00007ffc0876542e in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#2 0x00007ffc08765b39 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#3 0x00007ffc08a26efe in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#4 0x00007ffc08765494 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#5 0x00007ffc08765b39 in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#6 0x00007ffc0872ce1b in avs_get_read_ptr_p () from /e/Programs/AviSynth+/AviSynth64.dll
#7 0x0000000180002543 in dimzon_avs_init_2 () from /e/Documents/MeGUI-2913-64/AvisynthWrapper.DLL
#8 0x00007ffbacc8ea90 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

The exact part of avisynth_c.cpp it's choking on (at line 314):
https://github.com/AviSynth/AviSynthPlus/blame/e08d7c84179eb9a50b58736c78aeb1a4f41467ec/avs_core/core/avisynth_c.cpp#L311

pinterf

21st May 2020, 06:46

I was randomly browsing avisynth's filter sdk and the invoke API doesn't seem very elegant, it is currently

auto args = std::array{ AVSValue{ arg1 }, AVSValue{ arg2 }, ... };
auto result = env->Invoke("Filter", AVSValue{ args.data(), args.size() });

it could be much prettier using the following syntax

auto result = env["Filter"](arg1, arg2, ...);

or even better with named function call

auto result = env["Filter"]("param1", arg1, "param2", arg2, ...);

function call with arbitrary arguments could be implemented by variadic templates, simple example (https://godbolt.org/z/4ugXdE).
also see its implementation in vsfilterscript (https://github.com/IFeelBloated/vsFilterScript/blob/master/include/Plugin.vxx#L11)
Interesting ideas, they are a bit abstract for our present thinking.
I wish that was the only task to simplify. Instead there are many other opportunities to make the code a bit cleaner. E.g. removing all checks for 16 byte frame aligment in Avisynth (no unaligned frames allowed), and there are still other ancient techniques there which are sometimes workarounds for a VS2005 behaviour.

pinterf

21st May 2020, 06:59

AviSynth+ 3.6.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Thanks, it's a milestone.

Known issues
- Due to interface extensions, some plugins relying on old IScriptEnvironment2 no longer work (=crash)
- CPP 2.5 plugins which are using "Invoke" will probably have problems.
- MEGUI (?)

Rebuild list
- KNLMeansCL (https://github.com/pinterf/KNLMeansCL/releases) (fails because using env2->SetFilterMTMode instead of cache hints - see my mods in source)
I hope this link is temporary, I don't want to hijack this project.

- chikuzen's plugins rebuilt by Asd-g
https://github.com/Asd-g?tab=repositories

- GScript
See download link in Groucho2004's topic (https://forum.doom9.org/showthread.php?t=173259)

pinterf

21st May 2020, 07:30

I'd like to say a big thanks to Nekopanda. Some years ago he started an independent fork of Avisynth+ for his needs (you may know it as CUDA fork), which I wasn't even aware of for a long time, how serious changes were incorporated in that version.

He made many fixes and enhancements to the core.

- Multithreading fixes (the infamous ScriptClip issues)
(originally I only wanted to cherry-pick from Nekopanda fork to solve this problem, but the changes were not independent from the core changes he made as well so after spending weeks on resolving conflicts with our existing stuff, finally I had to integrate almost everything from there)
- language extension: function objects and variables. In interface: PFunction
- fine tune cache system, set optional caching strategy
- multiple Prefetch with new parameters
- 'escaped' string literals starting with e prefix e.g. e"Hello world\r\n"
- filter graph export

Boulder

21st May 2020, 08:25

Here's an example of a script which starts pounding on the GPU at 100%. I've tried changing the prefetch value, but I've not found a good value which would put the CPU (12c/24t) to work at 90-100%. In Vapoursynth, a very similar script uses 95-100% of the CPU and is much faster. GPU usage stays below 10% almost all the time.

DGSource("potter_stone.dgi", ct=280, cb=280, cl=0, cr=0) # UHD source

c2 = convertbits(bits=16)
c2blur = c2.blur(0.2)
prefilt = convertbits(bits=10)

w = prefilt.width()
h = prefilt.height()
prefilt = prefilt.removegrain(12, 12).gaussresize(w, h, 0, 0, w+0.0001, h+0.0001, p=2).mergeluma(prefilt, 0.1)

sharp_luma = c2.sharpen(0.6)
sharp_chroma = c2.sharpen(0.2)
sharp = sharp_luma.mergechroma(sharp_chroma)

superanalyse = prefilt.msuper(pel=2, hpad=16, vpad=16, sharp=2, rfilter=4)
supermdg = sharp.msuper(pel=2, hpad=16, vpad=16, levels=1, sharp=2, rfilter=4)

fv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
bv1 = manalyse(superanalyse, isb=false, delta=1, blksize=64, overlap=32, search=5, searchparam=8, pelsearch=8, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=32, overlap=16, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
fv1 = mrecalculate(superanalyse, fv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)
bv1 = mrecalculate(superanalyse, bv1, thsad=100, blksize=16, overlap=8, search=5, searchparam=6, truemotion=false, dct=5, mt=false)

fv1scaled = fv1.mscalevect(bits=16)
bv1scaled = bv1.mscalevect(bits=16)

c2blur.mdegrain1(supermdg, bv1scaled, fv1scaled, thsad=200, thsadc=200, plane=4, limit=255, limitc=255, thscd1=200, thscd2=70)

Prefetch(24)

pinterf

21st May 2020, 08:52

And a list about changes that affect future plugins.
Both serious and not so serious plugin writers have to keep in mind.

So just some thoughts.

[Frame properties]
AviSynth+ now have frame property support which was imported from VapourSynth. Thanks to Myrsloik.

Note that this is only the framework, a possibility, the 0th step.
We'll write on it later, documentation is lagging here - but it should appear on a refreshed Filter SDK.

Until then, even if you don't use them, you have to know some facts.

Frame properties are passed along and inherited with the frames in the filter graph.

Inheritance is broken if a filter does not behave in a frame-property friendly way. There is not problem when a plugin is using MakeWriteable. But when using NewVideoFrame which accepts only a format input (VideoInfo) the chain is broken. There is no frame property source for this empty frame. Avisynth core cannot guess it. But now we have a new IScriptEnvironment function "NewVideoFrameP" with the option of specifying the property source which will be copied to the newly created frame as well.

[AviSynth+ headers]

https://github.com/AviSynth/AviSynthPlus/tree/master/avs_core/include

cpp: avisynth.h (and the affected items under /avs)
c: avisynth_c.h

Avisynth+ Interface V8
- cpp interface: IScriptEnvironment was extended
- c interface: functions added to IScriptEnvironment are available as well
- former IScriptEnvironment2 items were moved to IScriptEnvironment (memory pool allocation, free, query of internal core properties, etc..)
- frame property support

[OS, compiler and architecture dependency]
This topic will probably require years.

Firstly you have a little help from Avisynth headers

#include "avs/config.h"

will set you some useful defines you can work with and act upon them (compiler flavours: MSVC, clang, GCC; OS flavours, Windows, POSIX, BSD; machine architectures: Intel, ARM)

At the present state most Avisynth plugins were coded with Microsoft Visual C++. Sometimes it's even difficult to port old sources to the actual MSVC syntax (and I'm not talking about C++17, but even having a valid C++11 syntax).
Then it will fail to build with clang, then it fails with gcc. And we are still on Windows.

Moving to POSIX introduces newer problems (case sensitivity, loading external DLLs such as fftw3, file system usage)

And when all this works you'll recognize that there are ARM machines and your code is full with Intel SIMD parts mixed into the C.

So it will require a big change in coding style and thinking.

VapourSynth is a "bit" ahead of us.

magnetite

21st May 2020, 09:01

I passed a note along to the MeGUI developers at Sourceforge about the issue, as well as I posted something in the MeGUI bug thread here.

tebasuna51

21st May 2020, 09:34

If MeGUI is broken I think also BeHappy, because use also a special AviSynthWrapper.dll

I read than also many plugins can't work with the new version.

When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.

If you plan to do that big changes remember my old suggestion of change the audio property NumChannels with MaskChannels (the NumChannels can be obtained from MaskChannels and the audio are now well defined).

pinterf

21st May 2020, 10:20

I read than also many plugins can't work with the new version.

List them here, we'll try to solve their problems.

When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.

Some of the (temporarily) broken plugins violated this remark placed in avisynth.h:
" Note to plugin authors: The interface in IScriptEnvironment2 is
preliminary / under construction / only for testing / non-final etc.!
As long as you see this note here, IScriptEnvironment2 might still change,
in which case your plugin WILL break. This also means that you are welcome
to test it and give your feedback about any ideas, improvements, or issues
you might have."

tebasuna51

21st May 2020, 10:34

List them here, we'll try to solve their problems.

The problems must be solved before launch a new version.

We need another set of plugins?

EDIT: maybe a new set called Avs* instead Avs+

pinterf

21st May 2020, 10:45

In general you'll need no new set of plugins.

But when you find a plugin which fails, post here or report the issue on github or report to the maintainer of the specific plugin.

qyot27

21st May 2020, 12:50

If MeGUI is broken I think also BeHappy, because use also a special AviSynthWrapper.dll
AFAICT, it just re-uses the same .dll from MeGUI. Which from the SVN history also previously had to be updated to support interface version 6. And for when AviSynth+ added high bit depth (eventually counted as interface version 7 for all of about a month and half).

From a cursory glance at the sources of the wrapper (https://sourceforge.net/p/megui/code/HEAD/tree/AvisynthWrapper/trunk/), I can't even tell why it would be throwing errors on avs_get_read_ptr_p specifically - it doesn't even seem to use the C interface at all. It also seems to be trying to use the init function intended for 2.5.7 instead of the one that was extended for interface version 6 and the high bit depth and MT features Plus introduced.

So all that needs to happen is that AviSynthWrapper.dll needs to be updated to be aware that version 8 exists. If there are any particulars in the API it has to compensate for, then it can do so at the same time in the version 8 loading function.

I read than also many plugins can't work with the new version.
Like pinterf pointed out, it should be only plugins that ignored the warning that the new-to-avsplus IScriptEnvironment2 wasn't stable and was subject to change that got hit by that particular issue.

Unless you were referring to the frame property support, which is simply that old plugins that don't support it will probably interfere with new plugins that do support it, not that the plugins break or cause the script to fail (well, unless the script was relying on the frame properties, maybe? But that's still the new feature ceasing to work, not the old stuff failing). To be honest, the new frame property and in-script array stuff is a little over my head.

When make a new version must be backward compatible, please begin with AviSynth 4.0, or a new fork, because the changes are too big.
That's precisely why it was bumped to 3.6 instead of continuing the 3.5.x series. Remember, AviSynth 2.6 was not perfectly backward compatible with 2.5, either. Plugins broke during the development of 2.6 and client programs (read: FFmpeg, x264) that depended on 2.5 having code baked into its headers broke when it was cleaned up in 2.6 and moved out of the headers, forcing them to either awkwardly try to support both, or to drop support of 2.5 outright.

The major.minor versions in AviSynth (in total, not just Plus) have always been mostly just symbolic. They aren't semantic versions (https://semver.org/), although since we now support more than just Windows, I am trying to ensure that the third version indicates just bugfixes or changes that don't impact any kind of compatibility. The version that really matters for compatibility checking is AVISYNTH_INTERFACE_VERSION, which was bumped when it changed to signal as much.

Note: the essential information that one actually needs to get and use from the AviSynth(+) API actually did not change here, as evidenced by the fact that a build of FFmpeg from December 30th, using headers that predate native Linux support¹ and still referred to themselves as interface version 6, can still load 3.6.0 and operate correctly.

¹predated 3.4.0, actually; the last time the compat/ headers in FFmpeg were updated (before getting removed in the wake of 3.5.0 being available on more than just Windows) was in May of 2019.

Kurtnoise

21st May 2020, 13:34

Hi,

I can concur about AvisynthWrapper stuff. It just needs to be recompiled using #8 as interface.

btw, Im trying to compile ffmpeg w/ avisynth support but I'm getting this error :
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h: In function 'avs_load_library':
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1450 | AVSC_LOAD_FUNC(avs_is_444, avs_is_yv24);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:3: error: 'AVSC_LOAD_FUNC' undeclared (first use in this function)
1450 | AVSC_LOAD_FUNC(avs_is_444, avs_is_yv24);
| ^~~~~~~~~~~~~~
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1450:3: note: each undeclared identifier is reported only once for each function it appears in
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1451:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1451 | AVSC_LOAD_FUNC(avs_is_422, avs_is_yv16);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1452:41: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1452 | AVSC_LOAD_FUNC(avs_is_420, avs_is_yv12);
| ^
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1325: note: macro "AVSC_LOAD_FUNC" defined here
1325 | #define AVSC_LOAD_FUNC(name) {\
|
C:/Users/Lionel/Downloads/mabs-master/local/include/avisynth/avisynth_c.h:1453:37: error: macro "AVSC_LOAD_FUNC" passed 2 arguments, but takes just 1
1453 | AVSC_LOAD_FUNC(avs_is_y, avs_is_y8);

something wrong within headers ?

Groucho2004

21st May 2020, 14:23

pinterf

21st May 2020, 14:45

Boulder

21st May 2020, 15:32

No idea why your GPU load is so high, I can't reproduce that. Have you tried L-Smash source filter with GPU support?

Just tried with LWLibavVideoSource, dead slow too. GPU usage is around 40-50% and the whole process less than 1 fps as CPU usage was in the low 20s. This was without cropping so the frame size was 3840x2160.

manolito

21st May 2020, 15:34

Not happy with AVS+ 3.6...

(I use the 32-bit version exclusively)

So far all my old plugins from the pre-modernization effort times seem to work, which is a welcome surprise. But the new MT process handling does not play nice with my older 32-bit StaxRip version (last 32-bit stable version 1.1.90).

Whenever an AVS filter in Staxrip is added or modified, the filter will be called to test it, and after a successful test the process will be terminated and released from memory. With AVS+ 3.6.0 this does not work any more. My source filter is DSS2Mod with LAV Filters, and now I get at least 3 instances of the LAV splitter and LAV Video source filter. This slows down the encoding by about 1 fps, and I think that it is unnecessary.

This is the script created by StaxRip:
LoadPlugin("C:\Program Files (x86)\StaxRip\Applications\AviSynth plugins\Decomb\Decomb.dll")
DSS2("D:\Jurassic World.mkv", preroll=15)
FDecimate(25)
Crop(0,0, -Width % 4,-Height % 4)
ColorMatrix(source=0,dest=2)
RequestLinear(rlim=50, clim=50)
ConvertToYV12()
Spline36Resize(704,396)
# Insert Loc parameter here:
Loc="20,14,-588,-330"
InpaintDelogo(mask="d:\logomask.bmp", Loc=Loc, Mode="Inpaint", Turbo=0)
RequestLinear(rlim=50, clim=50)
FineSharp()
avstp_set_threads(1)
Prefetch(4)
Trim(6151,172368)

For my needs this latest version 3.6 has nothing to offer, I am going back to 3.51. And generally I agree with Tebasuna:

If you want to push new versions without much testing compatibility with established and popular encoder GUIs then please create a new fork. You can make more radical changes then like drop 32-bit support and reject older plugins. And maybe some dev will agree to make a few bugfix updates to the older (traditional, maybe retro) 3.5x fork.

Just my 2 cents...
manolito

pinterf

21st May 2020, 15:44

If you want to push new versions without much testing compatibility with established and popular encoder GUIs then please create a new fork.
??? Are you aware how many developers are working on Avisynth+ and how many remains when they make a new fork?

real.finder

21st May 2020, 15:50

manolito

21st May 2020, 15:56

Personally I do not use MEGui, but just looking at the MEGui threads at Doom9 and seeing how active they are I can only assume that a lot of folks do use MEGui.

AviSynth is not a software which is used by itself, it is a frame server which is used in conjunction with other software. So I believe that the AVS devs always must keep an eye on this other software which depends on AviSynth.

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing. Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?

Stereodude

21st May 2020, 16:00

Why are you AVS+ devs in such a hurry to push out your latest and coolest achievements? Can't you just leave this turf to VS?
Perhaps a better question that should be answered first is what tangible problems are they trying to fix/improve that even warrant these dramatic changes (that break things)?

Groucho2004

21st May 2020, 16:04

Releasing a new AviSynth version without even having tested it with MEGui and some other encoder GUIs is simply embarrassing.That's a matter of opinion, I suppose. I think the "GUI" guys should keep up with current developments and update their Avisynth interfaces accordingly. Hard-coded interface versions such as found in the megui wrapper are ridiculous.

pinterf

21st May 2020, 16:15

Not happy with AVS+ 3.6...

[...]
Whenever an AVS filter in Staxrip is added or modified, the filter will be called to test it, and after a successful test the process will be terminated and released from memory. With AVS+ 3.6.0 this does not work any more. My source filter is DSS2Mod with LAV Filters, and now I get at least 3 instances of the LAV splitter and LAV Video source filter.

When something is kept in the memory it's not normal, and it means the resource if not freed up properly.

Question 1:
I have found DSS2mod on an Internet wayback machine linked from Avisynth.nl, is it the latest one?
Question 2:
Are you using the avss_26.dll?

manolito

21st May 2020, 16:33

1. I believe it is.
2. Yes, I do use avss_26.dll, dated from 2014-10-05

Right now I am in the middle of a long encode, I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

MeteorRain

21st May 2020, 17:05

It is very arguable. MeGUI is coded to work with a specific range of avisynth versions. It's the author of MeGUI's responsibility to support new versions. If you use a toolkit package like MeGUI where it maintains its own tool sets, use that, use whatever version it tested with.

If MeGUI was tested with 2.5, use 2.5 and not 2.6 2.7 3.0 3.6 3.7 4.0 or anything else, or it's your risk of having things broken, or your work to get it fixed.

Groucho2004

21st May 2020, 17:29

MeGUI is coded to work with a specific range of avisynth versions.I have never used megui so I wonder what that means. As I understand it, megui is just a frontend for various encoders and uses Avisynth to gather information about the source file/script. So, if I'm correct it just has to load the script and extract the information from it, right?

manolito

21st May 2020, 18:57

I will test how ffms2 and LSMASH behave under AVS+ 3.6 ASAP and report back.

ffms2 behaved nicely under AVS+ 3.6, but LWLibavVideoSource did not. I used the latest STVG and Holywu versions. So I still will go back to AVS+ 3.51

StainlessS

21st May 2020, 18:58

As time goes on relentlessly, so some apps get stuck in time warp, not sure, think MeGUI devs have been abscent now for some time (I aint updated
MeGUI for maybe 9 months [actually stable XP build for maybe 2+ years], as some things just dont work for XP, and if it dont work for that, then is of little use to me).
I have never used megui so I wonder what that means.
As various whotsits change, so args etc [EDIT: or even OS version compatibility] change and so no longer comply with MeGUI expectation of function arguments etc, ie no longer work proper/at all.

EDIT: And if one thing dont work proper, the whole shabang can/will fail.
EDIT: Just like Smaug's missing scale, one small imperfection and that damn iron arrow killed the cute cuddly little critter.

StainlessS

21st May 2020, 19:26

MeGUI is a Windows soft and don't need the Avs+ 3.6.0 new version. Also there are plugins than don't work with this new version.

Use the Options -> Main -> Always use the included AviSynth

Above good advise. [Above from one of the MeGUI threads]

Also, maybe about time that Avisynth(+) had a thread in Avisynth Usage forum, where current stable build should be posted, not really right that
users have to visit devs forum for what might be a stable version.
(this has always been a problem, and not just Avisynth, several other culprits [among many] being ffms2 and LSMash, mvtools, masktools and more)
(devs dont like dirtying their hands talking to users, I can appreciate that, I dont likem' either, nothing but trouble).

videoh

21st May 2020, 19:45

devs dont like dirtying their hands talking to users What a load.

StainlessS

21st May 2020, 19:47

What a load of bullcrap.

Agreed, really sad, time for Usage forum threads.

EDIT: Usage forum thread originator need not be constantly present, others would probably be more than happy to give advice there,
its just somewhere where users can ask a simple question without feeling that they are intruding into the devs area,
it scares the hell out of me just reading stuff in devs forum.

EDIT: JohnMeyer [somebody some devs may / or may not have heard of] said some time ago that he
did not visit devs forum often / at all, so could be a mistake to think that lesser mortals visit devs forum at every opportunity

qyot27

22nd May 2020, 01:01

since I am not with or against new fork but if it will be new fork in the end, then maybe better call it AvxSynth+ (since there are old AvxSynth (https://github.com/avxsynth/avxsynth/wiki)) because it work in Linux and so :)
There's no need to fork anything (and let AvxSynth rest in peace; the only reason it even had a different name was because it was not a 1:1 extension of AviSynth onto Linux - it was a separate port based on a not-even-current-at-the-time version of AviSynth, and it lost the ability to build on Windows at all, never mind all the other things that were idiosyncratic to it). If there are important fixes that users want applied to an older release series, they can be either backported from the master branch or written explicitly for the older branch. Look at many other projects out there that have periodic bugfix releases for older branches in parallel with releases from the current stable branch.

We've not had to do so yet, but the means to facilitate it already exists: every time a new release series happens, I create a branch for it. 3.4 has one, 3.5 has one, 3.6 has one. Since 3.4 had only one release, and 3.5 had two, those branches basically just tracked the current state of the master branch at the time. All someone needs to do is request something to be backported, and after a certain amount of time/number of commits have accumulated in the older release branch, a new bugfix release from that branch could be made. But that requires actually notifying us of changes that should be backported, and for the user to know it was fixed in a later version to be able to ask in the first place (meaning: we will ask you if it works in the current release or git version; if you can supply the commit hash itself, even better). I would generally consider the 3.4 branch as end-of-life unless there's some catastrophic reason to issue a bugfix for it, not least because having support for more OSes means more eyes potentially looking at the code and finding issues to fix. And 3.5 is the baseline for the other OSes because it's the first one that supports them. 3.6 would be a similar baseline for non-x86 processors, although the ability to do so would be a candidate for backporting to 3.5 (it was originally developed against 3.5.1, but I don't think I have the old 3.5.1-based branch around anymore).

And, for that matter, anyone that wants to actively contribute can help us by assisting with that backporting effort and then opening a pull request so that it gets applied to the upstream repository. Because of the fact that we do support Linux now, this division of labor between development branch/current stable/old stable is part-and-parcel of the way many Linux distributions or FOSS projects in general operate, and I'd expect that something like this will end up happening anyway as any hypothetical maintainers of AviSynth+ packages in various repositories find things that need bugfixes for what their distro ships¹. There still comes a point where old branches are just left alone, but a new release series does not mean the automatic end of the old one, git allows them to be maintained in parallel, albeit probably with reduced frequency for the older branches unless we suddenly get a flood of new contributors that accelerate the main branch's development and can simultaneously identify all the things that can be backported to older releases.

¹because distros that operate on point release versions themselves will often prefer to stick to a particular release series for one or several iterations of the main distro, before finally making the switch some time later. For instance, if AviSynth+ had miraculously gotten an upstream package in the repositories for Ubuntu 20.04 LTS, it would have frozen 3.5.x and only possibly package subsequent bugfix releases from the 3.5 branch. 20.10, 21.04, or 21.10 might also stick to shipping 3.5.x, only moving to 3.6.x during the cycle for 22.04 LTS (and by that time, who knows if we'll still be actively on the 3.6 branch or have moved up to some other milestone). The cycles are long and that means probably having to field support questions on a particular release.

FranceBB

22nd May 2020, 01:44

Oh boy, it broke everything here on XP x86 (SSE4.2 capable CPU).

https://i.imgur.com/CPgl5jF.png
https://i.imgur.com/snyaueD.png

ColorBars(848, 480)

Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.

SetMaxCPU("C")
ColorBars(848, 480)

Access violation in AVSMeter 2.9.9.3, total freeze followed by a crash without any report in VirtualDub2 build 44282.
3 errors one after the other on avs2yuv.exe

https://i.imgur.com/x5AwSgF.png
https://i.imgur.com/i9UouR2.png
https://i.imgur.com/j0883zN.png

ffmpeg instead complains about my SetMaxCPU("C"):

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

so I removed it and tried again with just ColorBars(848, 480):

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

I thought it was going to work as it correctly received both the audio and video stream, however it quickly stopped encoding and it generated a completely empty (0 byte) output file:

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

avs4x264mod.exe:

https://i.imgur.com/7HYPog7.png

AVSEditPlus 1.25 crashes without any error.
Avisynth_ProxyGUI:

https://i.imgur.com/H7WcDAr.png
https://i.imgur.com/YCJxr3w.png
https://i.imgur.com/g0k63id.png

Potplayer version 1.7.21212 (latest):

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

but then, when I was going to abandon every hope, I found out that MPC-BE was working just fine! It's really weird!

https://i.imgur.com/GTYX2O8.png
https://i.imgur.com/IEQjz1o.png

"It cannot be!" I though, so I tried with a different script which involves at least an external filter such as ffms2:

FFVideoSource("Analog_bad_source.avi")

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

And there it was, working as expected.

So I tried a few filters like:

FFVideoSource("Analog_bad_source.avi")

neo_dfttest(sigma=64, tbsize=1, Y=3, U=3, V=3, dither=0, opt=0)

and suddenly it became black. No error, it did allocate RAM, but the window was completely black:

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

So I thought: "I got it! It must be some incompatible plugin!"
So I removed every plugin from plugins and plugins+ and I ran AVSMeter again, but... nothing. Still access violation.
I even checked Avisynth.dll with Dependency Walker just to make sure, but everything was fine and of course I have all the C++ Redistributable and .NET Framework installed, so... what's going on?

Setup Log: https://pastebin.com/M5LizfCW

poisondeathray

22nd May 2020, 02:04

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64

colorbars(pixel_type="YV12")
qtgmc()

error message

Script error: expected `)'
((null), line1, column 4)
(SMDegrain 3.1.2.104s.avi, line 879)
(QTGMC_3.364.avsi, line 186)

smdegrain line 879

IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0

qtgmc line186

sisphbd = AvsPlusVersionNumber > 2294

Reverting back to 2.5.1 works ok

StainlessS

22nd May 2020, 02:27

I am reluctant to class avs+neo, same as, the Nekopanda Avs Neo, cant really compare them, dont know what to do with either
but they are not similar.
EDIT: The script writer has to make some sense of it, but there aint any.

EDIT: Above rant related to "IsAvsNeo".

stax76

22nd May 2020, 02:45

I had to do some updates and minor tweaks but after that everything works.

real.finder

22nd May 2020, 03:11

I got some weirdness with AviSynth+_3.6.0 (files only install), tested in avspmod x64 and vdub x64

colorbars(pixel_type="YV12")
qtgmc()

error message

smdegrain line 879

IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0

qtgmc line186

sisphbd = AvsPlusVersionNumber > 2294

Reverting back to 2.5.1 works ok

update qtgmc and smdegrain

poisondeathray

22nd May 2020, 03:17

update qtgmc and smdegrain

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

real.finder

22nd May 2020, 03:22

I did today already; is there anything newer than these ?

(SMDegrain 3.1.2.104s.avsi, line 879)
(QTGMC_3.364.avsi, line 186)

Check the Thread in my signature

poisondeathray

22nd May 2020, 03:41

Check the Thread in my signature
Thanks, it's ok now

It needed Zs_RF_Shared.avs as well

feisty2

22nd May 2020, 04:09

Interesting ideas, they are a bit abstract for our present thinking.
I wish that was the only task to simplify. Instead there are many other opportunities to make the code a bit cleaner. E.g. removing all checks for 16 byte frame aligment in Avisynth (no unaligned frames allowed), and there are still other ancient techniques there which are sometimes workarounds for a VS2005 behaviour.

cool, and if ur ever gonna design a new API for new plugins, feel free to take a look at vsfilterscript and see how coding c++ plugins could be easy as scripting with a modern API. it might attract more developers since writing filters is a cinch. a few rules to make things simple,

1) there must be no base class/interface and inheritance, and thus no virtual functions, polymorphism should be implemented by duck typing (or more precisely, structural typing)

2) there should be no type declaration unless it's a type cast, everything should be of type "auto". this is essential to structural typing since we differentiate types by their behaviors rather than their names, use a concept if the type must be constrained.

template<typename T>
concept string_alike = requires(T x) { std::string{ x }; };

auto f(string_alike auto&& str) {
...
}

auto x = "aaa";
f(x); // OK, str instantiates to const char*
f("aaa"); // OK, str instantiates to const char[4]
f("aaa"s); // OK, str instantiates to std::string
f("aaa"sv); // OK, str instantiates to std::string_view
f(123); // Error

this is vastly different from manually defining a bunch of interfaces (base classes) and subtypes, note that there is no common base type for const char*, const char[4], std::string and std::string_view, yet they all satisfy the "string_alike" concept since they share the same behavior (convertible to std::string), there is also no type erasure so the type precision is fully preserved.

3) constexpr if and requires expressions are your friend, these are extremely powerful tools and let you go even beyond structural typing, you can detect if a certain behavior is legal to a certain type and specialize your code based on that information.

auto print(auto&& stuff) {
// see if stuff is a container by detecting if it has the "begin()" member
if constexpr (requires { stuff.begin(); })
for (auto x : stuff)
std::cout << x << " ";
else
std::cout << stuff;
}

print(std::array{ 1, 2, 3 }); // prints "1 2 3"
print(std::vector{ "hello", "world" }); // prints "hello world"
print(3.14); // prints "3.14"

functions may return different types like in dynamically typed languages as long as the type can be determined at compile time with a little help from constexpr if

// consteval parameter is planned as a C++23 core language feature
auto f(consteval auto x) {
if constexpr (x == "a"sv)
return 123;
else
return 3.14;
}

auto x = f("a"); // x == 123, x is of type int
auto y = f("b"); // y == 3.14, y is of type double

nominal typing (type declaration) is evil and is the root cause of highly coupled, inflexible, unmaintainable code and all the ugliness out there

qyot27

22nd May 2020, 04:51

ffmpeg instead complains about my SetMaxCPU("C"):

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

The message is from SetMaxCPU, not FFmpeg. It passes through the clip messages from AviSynth to stdout.

I had just copied the Changelog entries as-is out of readme.txt, which still contained the old invocation syntax. readme_history.txt shows it correctly: "" or "none". I've edited the post and release summary to reflect that.

so I removed it and tried again with just ColorBars(848, 480):

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

I thought it was going to work as it correctly received both the audio and video stream, however it quickly stopped encoding and it generated a completely empty (0 byte) output file:

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

I couldn't grab that exact build of ffmpeg, probably because Zeranoe's forum is dead, but with the one from ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z, that command works and produces a valid output on Win10.

I also started up my old WinXP/Coppermine-128 machine and tested it on there (with 3.6.0 and ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z). ffmpeg.exe with the exact same command is cool with it, and ffplay.exe can play back the result of the encode.

pinterf

22nd May 2020, 11:03

Download MeGUI AviSynth Wrapper test (https://drive.google.com/open?id=1FAkgwYQ0IipKiiYGgiOGST4sx8xU4RU7).

I think it works not only for AviSynth+ but for avs2.6 or newer in general.

Copy over the existing one.

Probably the old one bundled with MEGUI was compiled with an AviSynth CPP 2.5 header.

The bundled DLL set is a "bit" old as well.
The x64 CPP 2.5 plugins are especially outdated.

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\ColorMatrix.dll [2.5.0.0, 2010-03-18]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb.dll [n/a, 2013-12-01]
C:\Download\MeGUI-64\tools\avisynth_plugin\FluxSmooth.dll [n/a, 2010-11-30]
C:\Download\MeGUI-64\tools\avisynth_plugin\leakkerneldeint.dll [1.5.4.0, 2010-03-14]
C:\Download\MeGUI-64\tools\avisynth_plugin\NicAudio.dll [n/a, 2012-01-02]
C:\Download\MeGUI-64\tools\avisynth_plugin\TDeint.dll [1.1.0.0, 2010-03-14]
C:\Download\MeGUI-64\tools\avisynth_plugin\undot.dll [0.0.1.1, 2006-09-19]

[C++ 2.6 Plugins (64 Bit)] [Version, Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\EEDI2.dll [0.9.2.0, 2017-11-17]
C:\Download\MeGUI-64\tools\avisynth_plugin\TimeStretch.dll [n/a, 2016-10-20]
C:\Download\MeGUI-64\tools\avisynth_plugin\TIVTC.dll [1.0.11.0, 2018-03-23]
C:\Download\MeGUI-64\tools\avisynth_plugin\VSFilter.dll [3.1.0.801, 2018-09-04]
C:\Download\MeGUI-64\tools\avisynth_plugin\yadifmod2.dll [0.0.2.0, 2017-02-21]

[Uncategorized files] [Time stamp]
C:\Download\MeGUI-64\tools\avisynth_plugin\_versions.txt [2018-09-08]
C:\Download\MeGUI-64\tools\avisynth_plugin\ColorMatrix.htm [2009-01-25]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_Copying [1995-10-18]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_FAQ.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\Decomb_ReferenceManual.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\DecombTutorial.html [2013-02-26]
C:\Download\MeGUI-64\tools\avisynth_plugin\EEDI2_README.txt [2006-06-07]
C:\Download\MeGUI-64\tools\avisynth_plugin\LeakKernelDeintHelp.html [2005-01-19]

Zetti

22nd May 2020, 11:29

Many Thanks pinterf

The wrapper test works fine for my needs.

tormento

22nd May 2020, 12:04

Download MeGUI AviSynth Wrapper test[/URL].
Don't know if a coincidence but after replacing file, MeGUI_x64 asked me to update AVS+ to 3.5 r3106 with release date 01/05/2020. :D

pinterf

22nd May 2020, 12:42

Don't know if a coincidence but after replacing file, MeGUI_x64 asked me to update AVS+ to 3.5 r3106 with release date 01/05/2020. :D
Dunno, it wasn't me :) Did they update the plugin set as well?

FranceBB

22nd May 2020, 12:48

The message is from SetMaxCPU, not FFmpeg. It passes through the clip messages from AviSynth to stdout.

I had just copied the Changelog entries as-is out of readme.txt, which still contained the old invocation syntax. readme_history.txt shows it correctly: "" or "none". I've edited the post and release summary to reflect that.

I couldn't grab that exact build of ffmpeg, probably because Zeranoe's forum is dead, but with the one from ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z, that command works and produces a valid output on Win10.

I also started up my old WinXP/Coppermine-128 machine and tested it on there (with 3.6.0 and ffmpeg-N-93674-g1e01f66-win32-static_legacy.7z). ffmpeg.exe with the exact same command is cool with it, and ffplay.exe can play back the result of the encode.

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D

kalehrl

22nd May 2020, 12:50

Too bad Zathor stopped developing MeGUI.

tormento

22nd May 2020, 13:20

Dunno, it wasn't me :) Did they update the plugin set as well?

Nope. It sorta triggered something...

pinterf

22nd May 2020, 13:49

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D
Have you tried both the xp installer and the fileonly versions (just to exclude a wrongly packaged dll version)?

Zathor

22nd May 2020, 15:42

qyot27

22nd May 2020, 16:11

Well, the thing is that on Win10 x64 on the very same machine I didn't have any issues, so it must be something with XP even though it works fine on your end. Is there something else I can use to debug to find a better answer other than "ACCESS VIOLATION"?
I don't know. My experience using a debugger is restricted to gdb, which won't work with the MSVC builds.

By the way, here's the complete list of XP-Compatible ffmpeg builds made by Reino: https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D
I know; that's where I downloaded it from.

tormento

22nd May 2020, 16:15

Thank you very much. Sadly it does not work for me with AVS+ r3106 installed. The internal check in AviSynthWrapper.cpp:468 returns NULL and therefore MeGUI assumes that the DLL and/or the installed AviSynth version are outdated.
I had the same problem and found that not all the 7Z file was unpacked and the AviSynth was missing in the internal folders. Just unpack the file in the update manually.

pinterf

22nd May 2020, 16:21

Thank you very much. Sadly it does not work for me with AVS+ r3106 installed. The internal check in AviSynthWrapper.cpp:468 returns NULL and therefore MeGUI assumes that the DLL and/or the installed AviSynth version are outdated. Do you mind to share the source code?

And yes, the wrapper is/was still using the interface 3 as the interface 6 from AVS+ does have the issue that in MeGUI the FFMS filter cannot show the input preview - it is black (lsmash does work). You need to refresh the preview again to show it properly (and yes, using 8bit input files). I was too lazy to rewrite the preview to trigger a new input bitmap when the first one is completly black.
Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.
In any case I am not very much familiar with C++ so I did not had the chance to improve the wrapper much. Likely there are way better methods to serve the data to MeGUI.

Hi, now that thing is interesting, I wonder why 3106 does not work.

btw is there any chance that the project move from sourceforge to github?

The source is here. Header files copy, a new ifdef and build.
Source:
https://drive.google.com/open?id=1zWDRGB_4wpYRwiMVTunLf8I4SHctdsrc

Are you using the C interface as well?

pinterf

22nd May 2020, 16:27

Ahh got it!
You can use the header file but please use
pstr->env = CreateScriptEnvironment(AVISYNTH_CLASSIC_INTERFACE_VERSION)
instead of
pstr->env = CreateScriptEnvironment(AVISYNTH_INTERFACE_VERSION);

This AVISYNTH_INTERFACE_VERSION comes from the actual avisynth.h but since this avisynth.h is "universal" and defines the actual IF version, you should use a former one.
I put the enum AVISYNTH_CLASSIC_INTERFACE_VERSION in the header for this very reason.

With this technique both former Avs 2.6 and Avs+ and current 3.6 will work and you'll get the environment properly.

EDIT: there are another places, altogether 4.
EDIT2:
I saw you are using v141_xp toolset, this only may not be enough for XP, this is usually needed:
/Zc:threadSafeInit-
to be put into the additional compiler flags

EDIT3:
Avisynth wrapper binaries (using only V6 restriction + WinXP additional safety flag)
https://drive.google.com/open?id=1JfiokTy2IOqOn1VTXN0eXQEDCC3vUdN4
Source
https://drive.google.com/open?id=18tjLGgdhgrHjjKRsgr-7hv5qMqDojYXp

tormento

22nd May 2020, 17:18

@pinterf
@Zathor

After some testing I confirm that older AVS+ doesn't work.

To stop the update request, do it once and copy AviSynth.dll from the update_cache\avisynthplus-3.5.1-64.7z to MeGUI\tools\avs and set it read only or MeGUI will delete it at every run (strange...).

Problem is when you add AVS script, it will tell you AviSynth 2.6 required as error.

With latest external AviSynth, no problems at all (you have anyway to put the read only AVS the same).

pinterf

22nd May 2020, 17:20

@pinterf
@Zathor

After some testing I confirm that older AVS+ doesn't work.

To stop the update request, do it once and copy AviSynth.dll from the update_cache\avisynthplus-3.5.1-64.7z to MeGUI\tools\avs and put it read only or MeGUI will delete it at every run (strange...).

Problem is when you add AVS script, it will tell you AviSynth 2.6 required as error.

With latest external AviSynth, no problems at all.
Have you tried the binaries in my previous post?

stax76

22nd May 2020, 18:24

Maybe somebody can help with some errors I get with the new headers.

Severity Code Description Project File Line Suppression State
Error C1083 Cannot open include file: 'avs/cpuid.h': No such file or directory FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1337
Error C2365 'paAppend': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1163
Error C2365 'paReplace': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1162
Error C2365 'paTouch': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1164
Error C2365 'peIndex': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1158
Error C2365 'peType': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1157
Error C2365 'peUnset': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1156
Error C2365 'ptData': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1149
Error C2365 'ptFloat': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1148
Error C2365 'ptFrame': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1151
Error C2365 'ptInt': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1147
Error C2365 'ptUnset': redefinition; previous definition was 'enumerator' FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1146
Error C1083 Cannot open include file: 'avs/cpuid.h': No such file or directory FrameServer D:\Projekte\VB\staxrip\FrameServer\avisynth.h 1337

https://github.com/staxrip/staxrip

pinterf

22nd May 2020, 18:32

Replace "avs/cpuid.h" instead of <avs/cpuid.h>

pinterf

22nd May 2020, 18:33

The others may conflict with vapoursynth definitions?

stax76

22nd May 2020, 18:34

Thank you, unfortunately Error C2365 remains.

tormento

22nd May 2020, 18:38

Have you tried the binaries in my previous post?
Nope, I am using the v8 interface wrapper.

pinterf

22nd May 2020, 18:44

Nope, I am using the v8 interface wrapper.

This latter is good for both v6 and v8, I hope.

stax76

22nd May 2020, 18:46

The others may conflict with vapoursynth definitions?

I think so, will try to workaround it tomorrow.

Morku

22nd May 2020, 18:49

Btw. the wrapper is only used for some internal functions (preview, deint check, audio encoding) but not when encoding the video.

Uh, this must be the reason, why the AVS Script Creator window turns black now.

https://i.imgur.com/E14i11E.gif

I have updated to AviSynth 3.6 and replaced the Wrapper from pinterf.
When I load a avs in the AVS Script Creator (I have tried ffmpegsource and dgsource, so it is unrelated) the preview turns black after 1 second. Also the Input DAR changes? You see in gif.

But when I load in Input and click Reopen Video Preview, the preview stays open fine.
No errors in the log when I reproduce the issue.

And thank you for all the time and support of MeGUI :)

tormento

22nd May 2020, 18:54

This latter is good for both v6 and v8, I hope.

It works both enabling and disablint "Always use the included AviSynth", however I always get the following log:
--[Information] [22/05/2020 19:50:31] No package requires an update
-[Information] AviSynth Wrapper
-[Information] File Version: 3.5
-[Information] File Date: 02-04-2020
-[Information] File Name: AviSynth+ 3.5 (r3106, 3.5, x86_64)
-[Information] File Path: d:\eseguibili\media\megui\avisynth.dll
-[Information] AviSynth Version: AviSynth+ 3.5 (r3106, 3.5, x86_64)

It seems like MeGUI is ignoring that setting or there is something wrong in the logging.

stax76

22nd May 2020, 20:27

I'm not using these enums so just out comment them.

Maybe there is still time to rename these things?

pinterf

22nd May 2020, 21:28

Yep or I'll define them as class enums. I do not think that many of you around the world is using them presently :)

FranceBB

23rd May 2020, 01:13

I don't know. My experience using a debugger is restricted to gdb, which won't work with the MSVC builds.

I see...

Have you tried both the xp installer and the fileonly versions (just to exclude a wrongly packaged dll version)?

I installed the vcredist one and it didn't work on XP, so then I installed the xp installer (without vcredist) and I still got an access violation.

I even tried with

SetMaxCPU("none")
ColorBars(848, 480)

Still access violation everywhere (AVSPmod, AVSMeter, VirtualDub, avs4x264mod, avs2yuv, empty file in ffmpeg - although it recognizes the A/V stream) but on MPC-BE.
On MPC-BE it works with its internal functions and ffms2 but as soon as I try to use some filters it doesn't...

I then installed the normal non-xp version and I've still got the same ACCESS VIOLATION error.
I re-installed again the XP version, I uninstalled 0patch (it provides security patches past Microsoft EoS in July 2019) and I also uninstalled the Antivirus (Avast Premier) and ran it again: same ACCESS VIOLATION.

I then downloaded the files only version, I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 from the x86-xp folder, I tried to run AVS and I've got an ACCESS VIOLATION.

Then I finally tried the x86 non XP one files only version and I manually substituted Avisynth.dll and DevIL.dll in Windows\System32 once again.
Guess what? ACCESS VIOLATION.

On Windows 10 the normal installer x86 works like a charm on the same computer with the very same hardware.

At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...

Of course, reverting to Avisynth+ 3.5.1 works and everything works again.
As I said, I have no idea about how to debug it other than saying that it doesn't have any missing dependencies when
I look at it with Dependency Walker and it's supposed to work fine, but it doesn't. I generally rely on AVSMeter but it just shows ACCESS VIOLATION just like any other program this time, so I don't know.
Any idea?
I don't know if you have an XP VM to test, but if you want something to test, I would happily let you login in mine via Anydesk or Team Viewer or RDP or whatever you want if you wanna take a look at how it behaves on XP.

qyot27

23rd May 2020, 01:59

Test this one (32-bit only):
http://www.mediafire.com/file/we5m234xrxbxjd6/AviSynth%252B_3.6.0_i686-xp-nosimd.7z/file

pinterf

23rd May 2020, 05:21

This is weird, - I'm using cmakegui, checked the XP support checkbox, generated the solution file and it listed that v141_xp toolset is forced, OK.
Went into VS2019 GUI, opened project properties and there was no sign of XP toolset settings, only the /Zc:threadSafeInit- option. It still listed the non-XP v142 toolset.
EDIT: When I pressed the "Generate" once again then it created the proper xp targeted solution

manolito

23rd May 2020, 15:17

This is a follow-up to this post:
https://forum.doom9.org/showthread.php?p=1912913#post1912913

At this point I said: "It must be something forked from Avisynth Neo!"
so I installed Avisynth Neo x86 r2827 and it gave me ACCESS VIOLATION. The very same behavior of Avisynth 3.6.0!
"Aha!"
It seems that they share the same behavior...
and I do agree with FranceBB on his conclusion.

My issues occur under Win7-64 on a Core i5 CPU with 8GB of RAM.

I made some more tests with StaxRip v. 1.1.9.0 (the last stable 32-bit version from 2013). I have no idea how StaxRip interfaces with AviSynth. All I can say is that for all the very long time I am using StaxRip, it never gave me any issues with AVS versions starting from early 2.5x versions through 2.6x up to AVS+ 3.5.1.

The weird behavior with LAV filters was only revealed because I had enabled the tray icons for LAV. So it is very easy to see that multiple instances are still running.

For ffvideosource and LWLibavVideoSource it is hard to tell if they have the same problem. They do not have tray icons, and in Task Manager I did not find a way to tell if there are several processes for the same DLL active.

So all I can be sure of is that LAV filters are not released from memory after the script which invokes them has finished and is terminated by StaxRip. The only way to release these filter instances from memory is to terminate StaxRip.

This behavior has nothing to do with the AVS+ MT feature. It does not matter if the Prefetch call is present or commented out, the behavior is identical.

The next thing I tried was to use DirectShowSource instead of DSS2Mod. Not good at all. The LAV filters behavior was the same, but in addition StaxRip would crash after 30 to 50 seconds after opening the source. This is reproduceable each and every time regardless of the source file format.

Since I almost never use DirectShowSource for video I became curious. I went back to AVS+ 3.5.1 (identical scripts and settings) and loaded a source using DirectShowSource. LAV filters behaved normally, and there were no crashes. But I only got one third of the conversion speed compared to other source filters (including DSS2Mod). Again regardless if Prefetch was used or not. Very weird.

To be absolutely sure I removed AVS+ and went back to classic AVS 2.6.1 Alpha. And here DirectShowSource was only a tad slower than the other source filters (about 0.5 fps).

Does not make any sense to me... :confused:

In any case I feel that AVS+ 3.6 is not ready for prime time yet. Please implement a more thorough quality control before publishing "stable" builds which turn out to be not that stable at all.

Cheers
manolito

stax76

23rd May 2020, 16:41

Boulder

23rd May 2020, 16:42

manolito

23rd May 2020, 17:31

@manolito

The StaxRip version you use is very old, it's using VFW, new versions use AviSynth and VapourSynth directly in portable mode, everything is included and works without installing or configuring anything, if AviSynth is installed then the installed version is used and the portable version cannot be used due to how AviSynth and tools are designed, StaxRip includes about ten tools that read avs and vpy. For VapourSynth both modes can be used, at least for what I could test (cannot test hw encoders). The beta from today uses AviSynth 3.6, works fine.

I see your point, but this will not work for me... :devil:

This old version 1.1.9.0 is very stable, it was at a time when you took a long break from StaxRip development. When you resumed the development, one of the first things you did was dropping XP support, and shortly after this you abandoned 32-bit completely.

I use StaxRip on at least 3 computers, and one of them is the ancient WinXP machine with a Coppermine CPU (no SSE2 support) and very low system RAM. I really do not want to maintain different StaxRip versions and different AVS plugins on these machines, they all use the "least common denominator" principle. Which means 32-bit and XP compatible.

There are also a couple of 32-bit only AVS plugins I want to keep on using, so I have no intention to ditch this old StaxRip version. Looking at your current StaxRip versions I can see that there are tons of new features which I do not care for (Hi Bit Depth, Hi Color, X265 support, VS support), but some things I do care for are missing (like XviD VFW support). And with all these new features also tons of new bugs were introduced.

So being a "Retro" person I will stick with this old StaxRip version, and if newer versions of AVS+ no longer support it then I will stop using these AVS+ versions. Newer is not always better...

pinterf

23rd May 2020, 17:43

I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.

A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.

I suppose, you get those numbers with older avisynth versions as well?
Last year (or before that) I investigated a similar source which behaved sub-optimally, to say at least. I could reach e.g. 60% CPU max. Could not solve it.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

Does your source filter have a debug or more verbose logging mode?

Boulder

23rd May 2020, 18:24

I suppose, you get those numbers with older avisynth versions as well?At least with v3.5.1 as I started my experiments with that version.

Vapoursynth has a rather different strategy on requesting frames. An Avisynth filter which requires e.g. 6 input clips (2-2 vector clips, super and the source clip itself) is requesting them in a serial ways inside a GetFrame. Caching helps a lot but not always. Contrary to this, Vapoursynth start requesting all 6 inputs _parallel_ and waits until they are all ready.

Maybe your case is a different one, which is only showing that the source filter (which is usually automatically set as MT_SERIALIZED mode) is getting more out of order (random) requests than it can cope with or cache.

So the frames + threads parameter is not like "process m frames with n threads simultaneously"? Has the multithreading functionality changed a lot since SEt's Avisynth MT? Of course, it could be that it's much harder to utilize all the 24 threads the CPU has.

Does your source filter have a debug or more verbose logging mode?
As far as I know DGSource doesn't have one, but I also tested LWLibavVideoSource with SW decoding and it doesn't resolve the issue.

Would you like me to test something specific? I also tried a BD source but it has the same problem, I cannot get CPU utilization past 40-45% or so.

pinterf

23rd May 2020, 19:41

I'm still quite confused with these tests of mine.
Running the script with Prefetch(frames=1, threads=24) ends up in CPU usage which looks like it's using only one thread. AVSMeter tells me that the thread count is increased but CPU utilization is still around 4%. GPU usage stays low.

I thought that would emulate the old behaviour of SetMTMode(x, 24)?

I've tried various frames and threads combinations, but at best I've been able to get around 40-45% of CPU load. The source decoding becomes a bottleneck sooner or later as the amount of frames increases.
How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.

All you can do is experimenting and share your findings

1.) You can have now multiple Prefetchers (new in 3.6)
2.) At the moment, forget "frames" parameter
3.) Try another cache mode (new in 3.6) default is 0.
- SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment

pinterf

23rd May 2020, 19:46

BTW your script is using isb=false for both forward and backward vectors, which seems to be wrong.

Boulder

23rd May 2020, 19:51

How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.
Pinterf, I thank you :) It was the default cache, which was not enough.. I raised it to 10000 and CPU usage jumped substantially to 90-100% with much less GPU usage than earlier.

I owe you one good pörkölt :)

pinterf

23rd May 2020, 19:54

Could you pls do a test: keep the original default 4GB memory and set the other cache mode, I wrote about above. What are your numbers now?

pinterf

23rd May 2020, 20:28

This is a follow-up to this post:
https://forum.doom9.org/showthread.php?p=1912913#post1912913

and I do agree with FranceBB on his conclusion.

My issues occur under Win7-64 on a Core i5 CPU with 8GB of RAM.

In any case I feel that AVS+ 3.6 is not ready for prime time yet. Please implement a more thorough quality control before publishing "stable" builds which turn out to be not that stable at all.

Cheers
manolito
Out of couriosity what happens when you remove _all_ CPP2.5 plugins then put them back one by one, which is the culprit?

Secondly
You can agree with FranceBB but you don't know what happened with his environment, nor do we know, but we'll solve it, maybe it was a mis-compiled version as I have written my example.

We can solve his problem with a much larger possibility that issues like why does not work properly and old tool which was tested and used when probably not even Avisynth 2.6 was final-released with plugins which I have to chase all around then finally download from Internet-wayback machine.

Boulder

23rd May 2020, 21:55

BTW your script is using isb=false for both forward and backward vectors, which seems to be wrong.
Gah, a silly copy-paste mistake by me there in the example :)

Could you pls do a test: keep the original default 4GB memory and set the other cache mode, I wrote about above. What are your numbers now?

The default took about 5100 MB, SetCacheMode(1) went to ~4700 when the first frames of actual content (first 50 frames or so were just black) were being processed.

With max at 10000, the usage is almost 9300 MB with SetCacheMode(1).

I haven't done any real-life tests with encoding yet so I don't know what the optimal prefetch value is.

tormento

24th May 2020, 08:13

A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.
Out of curiosity, I am bit confused about how the HBD plugins treat the images.

AFAIK the most used bit depths nowadays are 8 and 10 (12 on some specialized streams only).

How does it work when you set HBD or a plugin receives a HBD?

Doest it switch to 16 bits (or more) regardless of true bit depth or does it work with the same bit depth of the source?

Because if it goes straight to 16 bit to work on a 10 bit stream, it seems to me really a waste of power and it would need a dedicated algorithm to process 10 bit only, as they are the second most common after 8, and get faster.

tormento

24th May 2020, 08:20

1.) You can have now multiple Prefetchers (new in 3.6)
What is a good ratio to determine the number of frames to be prefetched? Now I am using Prefetch(6) because I am GPU memory bound. What effect has the frame parameter? Is it a sort of caching or what? Would set Prefetch (1,6) has the same effects on speed? :confused:

pinterf

24th May 2020, 08:32

For internal calculations the bits used are usually more than that, 16-32 bits (15-16 bit is used even for most 8 bit filters) Only very simple filters, where no precise calculation happens, keep the bit depth internally (e.g. mt_binarize). Imagine, when you multiply two 8 bit data you'll have 16 bit result.
Processing 10 bits can be faster that 16 bits however, in mvtools I had differently optimized - quicker - SAD routines for 10 bits because summing up sixteen 10 bit numbers still fit in a 16bit register, while summing up 16bit numbers require 32 bit processing already.
But such optimization specialization is tricky, increases internal complexity and in general it is the very last step when developer have inifinite free time and cannot do other meaningful stuff :)
Plus: as it requires extra programming resources it has to be done when it has real benefits and the task to optimize is the bottleneck in a process.

tormento

24th May 2020, 08:36

as it requires extra programming resources it has to be done when it has real benefits and the task to optimize is the bottleneck in a process.
I asked because I was planning to always use SMDegrain in HBD precision and then go back to 8 or 10 bit but sometimes the overhead is just too much to be of any use. Is there any optimization I could apply?

pinterf

24th May 2020, 08:38

What is a good ratio to determine the number of frames to be prefetched? Now I am using Prefetch(6) because I am GPU memory bound. What effect has the frame parameter? Is it a sort of caching or what? Would set Prefetch (1,6) has the same effects on speed? :confused:
This parameter exists for your individual fine tuning and experiments. Probably when you find a number for a specific script or filter, you have to re-test it for another one. When you don't know if you need it, do not specify it.

But since we do not have knowledge base on the real value of this parameter, always share your findings.

tormento

24th May 2020, 08:40

But since we do not have knowledge base on the real value of this parameter, always share your findings.
Can I have a wider explanation of what happens when I prefetch frames instead of threads? I have read 3.6.0 release notes but it did not clarify things a lot to me.

pinterf

24th May 2020, 08:40

I asked because I was planning to always use SMDegrain in HBD precision and then go back to 8 or 10 bit but sometimes the overhead is just too much to be of any use. Is there any optimization I could apply?
Reduce your input to 320x200 :)

tormento

24th May 2020, 08:42

Reduce your input to 320x200 :)
I deeply hate you with all my heart. :D

pinterf

24th May 2020, 09:52

Can I have a wider explanation of what happens when I prefetch frames instead of threads? I have read 3.6.0 release notes but it did not clarify things a lot to me.
You are always specifying threads, then you can further specify the frame numbers to look ahead. Default value of frames is threads*2.

gispos

24th May 2020, 12:48

...Default value of frames is threads*2.
Thank you, I had already asked myself that.
Then my prefetch (4, 8) doesn't do anything for frame caching. :D

Boulder

24th May 2020, 14:54

The new cache mode has quite an impact at least in my case where I have that MVTools stuff + downscaling in linear light and debanding with neo_f3kdb. I tested with AVSMeter with an insanely high SetMemoryMax(16384) to make sure cache size will not restrict anything. The default cache mode ran at 9.495 fps and SetCacheMode(1) at 12.36 fps. Memory usage was almost the same, both around 11000 MB.

I'll continue testing to see if lowering the prefetch value from 24 makes any difference.

Boulder

24th May 2020, 16:41

Some tests of x265 encodes with different prefetch values and the abovementioned script structure:

threads=24, frames default 2.53 fps
threads=24, frames 12 2.57 fps
threads=24, frames 24 2.51 fps
threads=24, frames 8 2.56 fps
threads=24, frames 10 2.57 fps
threads=24, frames 16 2.55 fps
threads=22, frames 16 2.55 fps
threads=20, frames 12 2.58 fps
threads=16, frames 12 2.57 fps
threads=12, frames 12 2.55 fps

It's quite easy to see that most of the time is spent inside x265 instead of frameserving. At least in my case, lowering the amount of frames was slightly beneficial.

stax76

24th May 2020, 16:52

In the staxrip tracker the most active power user posted when avisynth 3.5 is installed staxrip produces errors, it's fine if avisynth is not installed because then staxrip uses the included portable version 3.6 and it's also fine if 3.6 is installed. I had to explain this, maybe some devs can give some advice, my answer:

I changed it to don't allow old versions like currently done for Visual C++ 2019, it shows:

The currently used version of is not compatible (too old).

And it doesn't allow to edit the version except editing Versions.txt directly instead of using the GUI to do it.

Ideally it should not allow defining a custom path in this case but I'm not sure it's worth the trouble writing this code.

Here is the situation:

Most tools like StaxRip.exe or avs2pipemod.exe just load AviSynth with code like this:

LoadLibrary("AviSynth.dll")

This is however not a full path and what now is happening is the OS will search this DLL, for that it uses a strict order, first it will search it in the startup folder so next to staxrip.exe or next to avs2pipemod.exe or whatever tool is loading the avs file. Next it searches in the system folder, which is where avisynth is installed. I have tried to create soft links for avisynth.dll next to staxrip.exe but this did not work for unknown reason and then I gave up.

One issue was if avisynth is not installed then ffmpeg does not work because it does not use default DLL loading which searches in the path env var which staxrip sets. To fix that a soft link is working, qyot27 and stainless did help me to make this work.

In staxrip I could use a full path to load avisynth.dll and avs2pipemod has an option for that too, for the other tools an option could be requested, I can image some authors like rigaya would help, for some tools a mod could be created but for some tools it would be very difficult like ffmpeg.

Maybe it's not worth the trouble and just leave it as is, it's many avs tools like 10.

For vapoursynth it's working that a user can decide via setting if portable or installed version should be used, it can be defined in the settings dialog of staxrip and it worked for all tools I have tested, staxrip, ffmpeg, vspipe, mpv.net, only problem was mpc-be, not particular important since mpv.net is the primary player in staxrip and it supports portable mode for avisynth and vapoursynth. I have reported it and volt has a new avs vpy source filter in development which is awesome. Maybe somebody can try nvenc and qsvenc for which I don't have hardware or driver.

FranceBB

24th May 2020, 17:00

Test this one (32-bit only):
http://www.mediafire.com/file/we5m234xrxbxjd6/AviSynth%252B_3.6.0_i686-xp-nosimd.7z/file

Still access violation.

This is weird, - I'm using cmakegui, checked the XP support checkbox, generated the solution file and it listed that v141_xp toolset is forced, OK.
Went into VS2019 GUI, opened project properties and there was no sign of XP toolset settings, only the /Zc:threadSafeInit- option. It still listed the non-XP v142 toolset.
EDIT: When I pressed the "Generate" once again then it created the proper xp targeted solution

I see! Would you mind uploading the newly created build?
Or is it the AviSynth+_3.6.0_i686-xp-nosimd uploaded by qyot27?

You can agree with FranceBB but you don't know what happened with his environment, nor do we know, but we'll solve it, maybe it was a mis-compiled version as I have written my example.

We can solve his problem with a much larger possibility

Well I'm not sure what happened with my environment either, but thank you for being confident that you can solve the issue. I really appreciate that. :)

manolito

24th May 2020, 19:27

Out of couriosity what happens when you remove _all_ CPP2.5 plugins then put them back one by one, which is the culprit?

Thanks for this suggestion, it helped me to narrow it down to the latest Manao MaskTools2 version 2.0a48. I use mt_masktools-26.dll in my AVS plugins folder, but for some reason AVSMeter recognized it as an AVS 2.5 plugin. Removing this DLL and replacing it with a current PinterF version solved the LAV Filters problem, but this is something I can't and do not want to do. (Replacing the DLL with the TP7 version 2.0 b1 made no difference.)

The problem is that several older AVSI scripts in my plugins folder rely on MaskTools2, and just replacing Maskools with the latest High Bit Depth versions will not work. A while ago I asked Real.Finder explicitly if I could use his latest Srestore version with an older version of MaskTools2, and his answer was NO. I guess the same is true for QTGMC or LFSMod or FineSharp. I do not need and do not want Hi Bit Depth or Hi Color, so I will stay away from such plugins. I installed AVS+ solely in the hope for better speed from multitasking, everything else has no relevance for me.

And if AVS+ 3.6 now gives me issues using older AVS 2.5 plugins then I will stop using it.

Cheers
manolito

pinterf

25th May 2020, 05:31

Thanks for this suggestion, it helped me to narrow it down to the latest Manao MaskTools2 version 2.0a48. I use mt_masktools-26.dll in my AVS plugins folder, but for some reason AVSMeter recognized it as an AVS 2.5 plugin. Cheers
manolito
Hi,
I checked it, and AvsMeter recognizes mt_masktools-2.6.dll a CPP2.5 DLL, probably because it is using the non-final AVS 2.6 header file, which has AVISYNTH_INTERFACE_VERSION = 5
instead of 6. So this is a pre-2.6 DLL.

EDIT: even if it used a pre-avs 2.6 DLL, the plugin doesn't have AvisynthPluginInit3, only AvisynthPluginInit2
EDIT: test-test-test Retro masktools 2.0.48 as an Avisynth 2.6 dll. https://drive.google.com/open?id=1xPzwTtIHOwvnmNAlJvbT0JkffmEUQA67
Do _NOT_ mix it with masktools2!

pinterf

25th May 2020, 11:52

Still access violation.
I see! Would you mind uploading the newly created build?
Or is it the AviSynth+_3.6.0_i686-xp-nosimd uploaded by qyot27?

No, I just started to build one for XP then I made a sanitiy check before the actual build and was a bit surprised that this build would not be for XP contrary to the choice in cmake gui.

pinterf

25th May 2020, 14:07

Did you know?
New Format function in 3.6
http://avisynth.nl/index.php/Internal_functions#String_functions
and scroll down a bit

pinterf

25th May 2020, 14:25

Did you know (#2)?
New "SetMaxCPU" function in 3.6
http://avisynth.nl/index.php/Internal_functions#Global_Options

pinterf

25th May 2020, 14:46

Did you know (#3)?
Escaped string literals (from Nekopanda's fork)
http://avisynth.nl/index.php/The_full_AviSynth_grammar#Literals

manolito

25th May 2020, 15:53

EDIT: test-test-test Retro masktools 2.0.48 as an Avisynth 2.6 dll. https://drive.google.com/open?id=1xPzwTtIHOwvnmNAlJvbT0JkffmEUQA67
Do _NOT_ mix it with masktools2!

Thanks for this test build...

It does work on my Win7 computer with a CORE i5, but on my old XP machine (no SSE2) I get an access violation.

Anyways, it does not make much of a difference. The vast majority of my plugins are CPP 2.5 plugins, and I do want to keep using them.

The StaxRip version I use interfaces with AviSynth through the VFW interface, and this seems to cause my issues with AVS+ 3.6. Other host applications for AviSynth (like AVStoDVD) do not have these problems with LAV Filters not being released from memory, it is only StaxRip. And after more tests I found out that a lot of the CPP 2.5 plugins trigger this issue.

So some of the changes between AVS+ 3.5.1 and 3.6 must have broken the VFW interface with the effect that old 2.5 plugins no longer work correctly.

Now you might want to get rid of the VFW interface altogether in the near future, or you might want to drop support for 2.5 plugins, I don't know. Since I am unwilling to give up my StaxRip version or replace my 2.5 plugins with newer 2.6 versions, I only can decide to stick with AVS+ 3.5.1. All the new features are nothing I am interested in, so I do not miss out on anything.

Cheers
manolito

pinterf

25th May 2020, 15:57

On the output side, VfW interface is used e.g. for VirtualDub2, I had no problems on that side however.

pinterf

25th May 2020, 16:08

Thanks for this test build...

It does work on my Win7 computer with a CORE i5, but on my old XP machine (no SSE2) I get an access violation.

It's important because it was created with XP settings on the DLL side.

This masktools project consists of two parts, the other - non DLL part - was not flagged with this XP special option.
Test 2: (ThreadSafeInit- flag set to all modules)
https://drive.google.com/open?id=12dmNGCuxy-QD2bKh2XqZhI3CquBDXKGD

manolito

25th May 2020, 17:22

Alright, the new test build now runs on my XP machine without any problems...

For the VfW interface I had not even thougt about VDub, thanks for mentioning it.

And yes, I can easily reproduce the issue under VDub. I use an older version by FCCHandler with integrated MPEG2 support (VDub2 does nothing for me), but this should not make a difference.

This is the source script:
movie = "d:\test.mp4"
a = DirectShowSource(movie, video = false)
v = DSS2(movie)
AudioDub(v, a)
Crop(0,0,-Width % 4,-Height % 4)
FineSharp()

DSS2Mod plus the latest stable LAV Filters installed.

The FineSharp script relies on MT_MaskTools-26 and RemoveGrain and Repair. All of them are CPP 2.5 plugins.

If you comment out the FineSharp call in the above script and open it with VDub, everything works fine. But if you activate FineSharp, things change. Opening the script just once is no problem, but if you reopen the script you will see that the previous LAV Filter instances stay in memory. Reopen the script a couple of times, and you will see your taskbar populated with many LAV instances (if you have enabled the tray icons in the LAV settings).

So I believe that it really is the VfW interface which is broken in AVS+ 3.6. Are we getting somewhere?

jpsdr

25th May 2020, 18:12

pinterf

25th May 2020, 18:19

I assume SetMaxCPU will have effect on this kind of code:

SSE2_Enable=((env->GetCPUFlags()&CPUF_SSE2)!=0);
AVX_Enable=((env->GetCPUFlags()&CPUF_AVX)!=0);
AVX2_Enable=((env->GetCPUFlags()&CPUF_AVX2)!=0);

It's working for the code on the constructor ?
Interesting for debuging.

BTW, there is still no possibility to know the prefecth value used in the script within the Create function or the constructor ?
For experiments check env->GetEnvProperty(prop_id), which function is now is part of IScriptEnvironment, their constant are also in avisynth.h. Don't know when and what it returns, but you can even ask it in every GetFrame. And do your thread count adjustment on-the-fly?

jpsdr

26th May 2020, 11:58

And do your thread count adjustment on-the-fly?
For my needs... Not...
It's like... wanting to change the tires of a car while driving...

I need the information when i create the threapools
if (!poolInterface->CreatePool(prefetch)) env->ThrowError("...") in the Create function.
Then i create for one (or more) pool the number of threads (in each pool) in the constructor (with each step a check to be sure everything went fine), and in the GetFrame the creation part is allready done, everything is ready to use, and used.

Anyway, it's not critical, as the parameter can be set.

real.finder

26th May 2020, 14:02

the output of GeneralConvolution seems different from AviSynth 2.6, is it bug?

using

ConvertTorgb32
GeneralConvolution(Matrix="-1 2 -1 2 0 2 -1 2 -1")

vcmohan

26th May 2020, 14:13

And a list about changes that affect future plugins.
Both serious and not so serious plugin writers have to keep in mind............................................

Inheritance is broken if a filter does not behave in a frame-property friendly way. There is not problem when a plugin is using MakeWriteable. But when using NewVideoFrame which accepts only a format input (VideoInfo) the chain is broken. There is no frame property source for this empty frame. Avisynth core cannot guess it. But now we have a new IScriptEnvironment function "NewVideoFrameP" with the option of specifying the property source which will be copied to the newly created frame as well..
After a long time I am going through this thread and got alarmed. In the initial years of Avisynth 2.5 plugin creators were advised not to use MakeWritable function but use NewVideoFrame(vi) and copy the input frame. I have been using that advice meticulously since then and modified my old sources.
Now it appears MakeWritable may be the way to go. Also it appears NewVideoFrame(vi) will break.
Do I need to alter all my avisynth+ plugins with this new environment? True when using IscriptEnvironment2 we were warned that it may change. But for keeping thread safety getting buffers from avisynth became possible and convenient.
I request to please advise me on these aspects.

real.finder

26th May 2020, 14:31

FranceBB

26th May 2020, 19:56

No, I just started to build one for XP then I made a sanitiy check before the actual build and was a bit surprised that this build would not be for XP contrary to the choice in cmake gui.

Ok so the build that you generated, although it was supposed to be for XP when you selected it with CMake, but it wasn't.
By the way, I connected my GitHub account and selected the project on my computer and when I have time I'll take a look at it and I'll try to make a /Zc:threadSafeInit debug x86 build to see whether it works or not, however I'm not really familiar with CMake... Image (https://i.imgur.com/7za3JSk.png)
If you or someone else has time to make a /Zc:threadSafeInit x86 debug test build in the meantime, I'll test it.

pinterf

26th May 2020, 20:42

Ok so the build that you generated, although it was supposed to be for XP when you selected it with CMake, but it wasn't.
By the way, I connected my GitHub account and selected the project on my computer and when I have time I'll take a look at it and I'll try to make a /Zc:threadSafeInit debug x86 build to see whether it works or not, however I'm not really familiar with CMake... Image (https://i.imgur.com/7za3JSk.png)
If you or someone else has time to make a /Zc:threadSafeInit x86 debug test build in the meantime, I'll test it.
With minus at the end.
/Zc:threadSafeInit-
Sorry, I had zero time, need a few days even for this simple task.

mastrboy

27th May 2020, 12:08

Is there a similar function to Histogram("luma") that works with > 8 bit content in Avisynth+ 3.6?

pinterf

27th May 2020, 16:05

Dear volunteers, please test this version with as much CPP-2.5 plugins as you can (including those which were crashing with 3.6)
Avisynth+ 3.6.1-20200527 test (https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing)

Files only, *XP-compatible version, 32 bit version runs on SSE
*cannot guarantee until you are reporting that is really works.

Features: a bit (much) more friendly to Avisynth 2.5 style plugins

- AvisynthPluginInit2 passes a separate ScriptEnvironment for CPP2.5 plugins, so Avisynth+ can catch their AddFunction and Invoke methods
- since Avs2.5-ness is registered during plugin loading and AddFunction, calling such plugins from Avisynth+ core can happen in a compatible way without memory leaks.

This results in stopping memory leak (on e.g. "last" clip would not freed up on destroying ScriptEnvironment) resulted in increasing memory consumption when doing consecutive script reloads in VirtualDub or probably in other editors.

pinterf

27th May 2020, 16:24

After a long time I am going through this thread and got alarmed. In the initial years of Avisynth 2.5 plugin creators were advised not to use MakeWritable function but use NewVideoFrame(vi) and copy the input frame. I have been using that advice meticulously since then and modified my old sources.
Now it appears MakeWritable may be the way to go. Also it appears NewVideoFrame(vi) will break.
Do I need to alter all my avisynth+ plugins with this new environment? True when using IscriptEnvironment2 we were warned that it may change. But for keeping thread safety getting buffers from avisynth became possible and convenient.
I request to please advise me on these aspects.

In Interface V8 the buffer pool has been moved to the standard IScriptEnvironment.

As for MakeWritable, I don't know why it was on the blacklist.

You can use NewVideoFrame in the future, it will take a long time until plugins are starting to use frame properties and the rules and conventions are defined and handled properly. All we have now that you can define, read and write frame properties.
You can tell on creating a new empty frame which previous frame you want to be the parent of the frame properties.
MakeWritable will do this copy instead of you automatically.

This was my transition in mvtools to apply proper passing of those theoretical frame properties:
https://github.com/pinterf/mvtools/commit/6537322da866392d82cce226160a3bfbb318a8f8
You can see there different techniques:
- no source given at all (mask),
- using NewVideoFrameP passing the source of fp immediately
- using NewVideoFrame, then set fp's later by copyFrameProps.

Plus it is done adaptively, only when filter detects a V8 interface.

manolito

27th May 2020, 16:53

pinterf

27th May 2020, 16:56

Thanks for the test build, but Google won't let me download it without logging in. You can call me a bit paranoid, but I refuse to open accounts with Google, Microsoft and other collectors of personal data.

So can you or someone else please upload the file somewhere else?

Thanks
manolito
I didn't know that. Sad, because the other sites which are frequently used here are much worse with their ads and malicious redirects.
Edit: changed the link above, please try this one https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing
They have changed the default behaviour.

ChaosKing

27th May 2020, 17:00

pinterf

27th May 2020, 17:01

Works here without login. I had a similar issue once with one drive links. Try in private tab.
Yep, I modified, I have edited my post

tormento

27th May 2020, 17:14

Files only, *XP-compatible version, 32 bit version runs on SSE
Does it change something for non xp?

Inside I can see xp-ish directories only.

real.finder

27th May 2020, 17:20

the output of GeneralConvolution seems different from AviSynth 2.6, is it bug?

using

ConvertTorgb32
GeneralConvolution(Matrix="-1 2 -1 2 0 2 -1 2 -1")

with avs+ it look more blur

manolito

27th May 2020, 17:22

Edit: changed the link above, please try this one https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing

Yes, this link works without logging in, thanks...

manolito

27th May 2020, 17:45

Yes, whatever you changed in this version, it did solve all the previous problems... :D:D

Tested with the old StaxRip 32-bit version (which uses the VfW interface) and with VDub. No more memory leaks, the LAV Filter instances are always correctly released from memory when the AVS script is closed.

As tormento already asked, will you apply these changes also to the Non-XP versions? I found these issues under Win7-64. Or do the XP versions which you uploaded check the CPU capabilities and use them if present?

Whatever, I am really glad that I now can keep using my old CPP 2.5 plugins without issues under AVS+.

Thanks again
manolito

manolito

27th May 2020, 18:28

Or do the XP versions which you uploaded check the CPU capabilities and use them if present?

I did a short speed benchmark comparing the x86-XP files from the test version to the x86 standard files from the previous AVS+ version 3.5.1.

I used a HD AVC clip and converted it to an SD clip with X264. Prefetch set to 4.

Result: (taken at 10% into the encode)
3.5.1 : 43.98 fps
3.6 test : 44.05 fps

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.

pinterf

27th May 2020, 18:49

Nothing is disabled. Xp as an os does not support avx and up but that's all

StainlessS

27th May 2020, 19:56

As for MakeWritable, I don't know why it was on the blacklist.

Not sure but I think MakeWritable was originally referred to as the "MakeWritable hack" [and was used via a MACRO/define, probably some time prior to v2.58],
it was later officially incorporated as env->MakeWritable(&src);

So nothing wrong now using MakeWritable.

EDIT: DG would probably remember exactly, it was before my time with avs.

FranceBB

27th May 2020, 20:52

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.

Yep, the only drawback on XP is if just like me you have an AVX, AVX2 capable CPU 'cause it will stick with SSE4.2 at best 'cause Microsoft never implemented AVX/AVX2 on XP.
In other words, it's gonna use SSE, SSE2, SSSE3, SSE4.1, SSE4.2 only.
If, however, you use an xp compatible build on - let's say - Windows 10, it should use AVX and AVX2 (I can't say for AVX512 as I never tried: I don't have an AVX512 capable CPU).

Yes, whatever you changed in this version, it did solve all the previous problems... :D:D

Tested with the old StaxRip 32-bit version (which uses the VfW interface) and with VDub.

I can happily confirm that it does work with the VfW interface on Virtual Dub, in fact I was able to run pretty much every test script (and I tried several external filters as well).
Ferenc, whatever you changed, it worked, however... (yes, there's an "however") AVSMeter 3.0.0.4 still reports an ACCESS VIOLATION, AVSPmod says that there's been an error loading Avisynth and avs4x264mod shows this:

avs [error]: Exception while processing ScriptEnvironment::ThrowError().
(AVS Script.avs, line 1)

followed by:

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

and then it just hangs there...
ffmpeg shows the very same message:

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

Please note that none of them was working before, so now at least Virtual Dub works.
We're making progress.

pinterf

27th May 2020, 21:48

Groucho2004

27th May 2020, 21:53

Result: (taken at 10% into the encode)
3.5.1 : 43.98 fps
3.6 test : 44.05 fps

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.These results are well within the margin of error. Windows is not a real-time OS.

stax76

27th May 2020, 22:09

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users? Almost everybody else gave up XP support long before.

Unicode support could be improved and a setup option to phase out VFW support, VirtaulDub2 is maybe the last tool that uses VFW and it's actively maintained, so the maintainer could access avisynth and vapoursynth directly, avisynth being in system32 blocks portable mode in staxrip.

On the long run avisynth will just die a slow death like other tools that were never modernized, like for instance megui.

FranceBB could easily fix it himself.

http://www.vapoursynth.com/2014/11/r25-death-to-windows-xp/

real.finder

27th May 2020, 22:17

FranceBB

can you try with this script?

ClearAutoloadDirs()
Version()

Groucho2004

27th May 2020, 22:27

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users? Almost everybody else gave up XP support long before.Funny, usually it's the XP promoting posts that are not popular.
To be honest, I'm surprised pinterf and qyot27 go through so much trouble keeping XP users happy.

manolito

27th May 2020, 22:53

I think you guys did not read my posts about this issue... :devil:

It had absolutely NOTHING to do with Win XP. This memory leak was under Win7-64 on a CORE i5 CPU. What it was about was a host software interfacing with AviSynth through the VfW interface AND at the same time loading a CPP 2.5 plugin in an AVS script.

If these two conditions are met then AVS+ 3.6 cannot release plugins from scripts which were terminated from memory. Reproduceable each and every time with VDub and StaxRip 1.1.9.0. And just any CPP 2.5 plugin. Only eliminating ALL 2.5 plugins OR not using the VfW interface would prevent this issue.

Now of course the AVS+ devs could prevent this issue by just dropping support for VfW and CPP 2.5 plugins. Maybe even raise the OS requirement to Win10 and ditch 32-bit. This is what folks like stax76 would like to see. I just hate this school of thinking to no end.

Anyways, I am very grateful to pinterf and this fellow devs for taking the time to fix this problem. To me it did not look like something which was necessary for the sake of progress. There was no such problem in AVS+ 3.5.1, and the new test version proves that it does not have to be a problem in 3.6.

manolito

27th May 2020, 22:59

These results are well within the margin of error. Windows is not a real-time OS.

Yes, this is exactly what I was saying. Using the XP compatible version under Win7-64 does not come with any speed penalty.

FranceBB

27th May 2020, 23:29

Avspmod, ffmpeg and avs4x64mod are using C interface. Probably their problems have the same root. Not really important but 32 or 64 bit versions? Then Avsmeter crash how? With a script? Or avsmeter avsinfo?

Yep, they're probably having all the same issue.
The version is 32bit (I have 32 GB DDR4 with PAE, but I'm planning to upgrade to 64 GB DDR4 for Christmas. Hilariously 64GB is the maximum amount of RAM that XP x86 can recognize as it was seen as something enormous back then).

As for AVSMeter:

AvsMeter.exe Avsinfo -lf -log

pause

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

I thought I could get some more info by making it write a log file but despite the flag it didn't really write one, probably because of the ACCESS VIOLATION error.

AvsMeter.exe "test.avs"

pause

test.avs

ColorBars(848, 480)

also has the same error, however VirtualDub works 'cause it's using the VfW interface:

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

And just to make sure that the VfW interface is working correctly with both internal and external plugins both new and old from 2003 to 2020, I made the "stupid_useless_test_filterchain.avs" with random filters and a list of gibberish values for the only purpose of trying to find incompatibilities:

ColorBars(848, 480, pixel_type="YV12")

maa2(mask=1, chroma=true, ss=2.0, aa=70, show=0)

ColorMatrix(mode="Rec.601->Rec.709", interlaced=false, threads=0, thrdmthd=0)

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false,
opt=3, mt=true, keep_tv_range=true, input_depth=8, output_depth=8)

gradfun3(thr=2.00, thrc=2.00, radius=68, smode=2, staticnoise=false, lsb_in=false, lsb=false)

Deblock_QED(quant1=30, quant2=36, aOff1=1, aOff2=1, bOff1=10, bOff2=10, uv=3)

FFT3DFilter(sigma=3.0, beta=1.0, plane=4, bw=16, bh=16, ow=8, oh=8, bt=3, kratio=3.0, sharpen=1.0, scutoff=0.3, svr=1.0,
smin=4.0, smax=30.0, measure=true, interlaced=false, wintype=0, degrid=1.0, dehalo=1.0, hr=2.0, ht=50.0)

dfttest(sigma=64, tbsize=1, lsb_in=false, lsb=false, Y=true, U=true, V=true, opt=0, dither=0)

super = MSuper(pel=2, sharp=1)
bv1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
fv1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
bv2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
fv2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super,bv1,fv1,bv2,fv2,thSADC=800, thSAD=800)

ConvertBits(16)

ConverttoDoubleWidth()

hqdn3d(ls=8.0, cs=8.0, lt=6.0, ct=4.5, restart=7)

ConvertFromDoubleWidth()

ConvertBits(bits=8, dither=1)

AddGrainC(var=5.0, uvar=0.0, constant=true)

Spline64ResizeMT(704, 396)

HighlightLimiter(gblur=5.0, threshold=150, twopass=false)

LCE(brightness=80, correction=false, gblur=0.1, mode=1, contrast=1.5)

ContrastMask(enhance=10.0, tvcolor=true, gblur=20.0)

ConverttoRGB()

GamMac(dither=true, LockChan=-3, Scale=2, RedMul=1.0, GrnMul=1.0, BluMul=1.0, loTh=0.0, hiTh=0.0,
LockVal=128, RngLim=12, GamMax=10.0, omin=16, omax=235, Show=false, Coords=false)

ConverttoYUY2()
Declick(lthresh=35, cthresh=15, map=false)

Converttoyv12()

LUTDeCrawl(ythresh=10, cthresh=10, maxdiff=80, scnchg=100, usemaxdiff=true, mask=false)

checkmate(thr=12, max=18, tthr2=10)

tdeint(mode=2, order=-1, field=-1, mthreshL=6, mthreshC=6, map=0, type=2, debug=false, mtnmode=1,
sharp=true, cthresh=6, blockx=16, blocky=16, chroma=true, MI=64, tryWeave=true, link=1, denoise=true, slow=2, opt=4)

ChubbyRain2(th=10, radius=10, show=false, sft=10, interlaced=false)

DeScratch(mindif=5, asym=10, maxgap=3, maxwidth=3, minlen=90, maxlen=2048, maxangle=5, blurlen=15, keep=30,
border=2, modeY=3, modeU=3, modeV=3, mindifUV=0, mark=false, minwidth=1)

DeSpot(mthres=16, mwidth=7, mheight=5, merode=33, interlaced=false, show=0, show_chroma=false)

LGhost()

Levels(16, 1, 235, 0, 255, coring=false)

FastLineDarkenmod()

InterFrame(GPU=false, Preset="Medium", Tuning="Animation", NewNum=60000, NewDen=1001, InputType="2D", OverrideAlgo=13, Cores=1, FrameDouble=false)

ConvertBits(16)

ConverttoStacked()

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)

ConvertFromStacked()

ConvertBits(bits=8, dither=1)

asharp(T=2, D=4, B=-1, hqbf=false)

aWarpSharp2(thresh=180, blur=3, type=0, depth=35, depthC=10, chroma=4)

ConverttoYV12()

and it worked just fine:

https://i.imgur.com/4HwvuSV.png

So we can say that VfW works fine and Avisynth 3.6.1 is correctly recognizing old and new plugins.
All is left is to understand why the C interface is producing an ACCESS VIOLATION, then...

FranceBB

can you try with this script?

ClearAutoloadDirs()
Version()

Works fine in VirtualDub, ACCESS VIOLATION on everything else:

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

On the long run avisynth will just die a slow death like other tools that were never modernized, like for instance megui.

Never modernized? Modern indexers allow to deal with pretty much every new codec, new plugins allow to deal with HDR sources and apply tone-mapping or linear transformations like from HLG to PQ and so on. I think that looks pretty modern to me. I don't think Avisynth will die as long as people like Ferenc keep updating the core and developers like Jean Philippe Scotto di Rinaldi, StainlessSs, Groucho, Real.Finder, MeteorRain, Donald Graft and others keep working on plugins.
In the past there were people like Didee, WarpEnterprise, Tritical and other who left, but did Avisynth die? Oh no, it's more alive than ever and this community proves it. :)

Sorry this won't be a very popular post. There is a lot of effort to support legacy XP and x86 software, what about all the Windows 10 x64 users?

I'm sure Win10 x64 users voices will be heard as well.
For the records, it's not like I bury my head in the sand, I have Win10 x64 with a modern Xeon CPU at work as well as at home as dual boot, so I enjoy efforts to modernize things like GPU acceleration in indexers like LSMASH or DGIndexNV as well. (This is from this evening, just saying: Link (https://i.imgur.com/WJD6iVH.png) I'm on Win10 x64 as you can see)

setup option to phase out VFW support, VirtaulDub2 is maybe the last tool that uses VFW and it's actively maintained, so the maintainer could access avisynth and vapoursynth directly

Why phasing that out? It's been around for so long that there could be other things relying on it.

avisynth being in system32 blocks portable mode in staxrip.

What do you mean? It doesn't have to be in system32.
It's in system32 only if it's installed as it's the default location, however I can definitely use Avisynth without installing it as long as I know its directory. For instance, FFASTrans it's an example of how Avisynth.dll can be used without installing anything on the system.

Now of course the AVS+ devs could prevent this issue by just dropping support for VfW and CPP 2.5 plugins. Maybe even raise the OS requirement to Win10 and ditch 32-bit. This is what folks like stax76 would like to see. I just hate this school of thinking to no end.

Anyways, I am very grateful to pinterf and this fellow devs for taking the time to fix this problem.

I quote everything.
Like, I don't really take this kind of support for granted, but if Ferenc is so kind to spend time on the issues we all report (me included), then I'm really glad.
Heck, when this whole coronavirus story is over it would be fun to meet you all somewhere like at some broadcast/encoding event and if Ferenc comes I'll buy him lunch, I really will.

FranceBB could easily fix it himself.

Believe me, I would love to contribute directly to the Avisynth code on Github, but I still have to learn a lot of C++ before I will be able to contribute.
I studied Computer Science Engineering (bachelor degree) and I'm now doing a master degree while working in broadcast, so my schedule is already pretty full; it's so full that I don't watch TV anymore... I rarely watch a movie every once in a while... When I travel instead of listening to music I listen to my own recorded voice reading formulas or theorems trying to memorize them... And you know why? 'cause I can't afford to just stay at home, pay my rent with I don't even know what money, without a job and pay for my studies. So... "yes", I gotta keep working and "yes" I gotta keep studying and "no" I can't actively contribute to the Avisynth Core even if I really wanted to... :(

stax76

27th May 2020, 23:54

@manolito

I've sympathy for people that hang on to old things or not the most popular choices. I'm just trying to say that sometimes it's necessary to give something old up in order to make room for something new, for instance to correct bad decisions made in the past. If people hang on, that's fine, if people don't, that's fine too, in reality you always have and need both type of people.

What do you mean? It doesn't have to be in system32.
It's in system32 only if it's installed as it's the default location, however I can definitely use Avisynth without installing it as long as I know its directory. For instance, FFASTrans it's an example of how Avisynth.dll can be used without installing anything on the system.

staxrip supports portable mode for both avisynth and vapoursynth. The avisynth and vapoursynth SDK should clearly describe how client tools are supposed to load the DLL in order to support things like portable mode. A client tool like staxrip should be able to give the user the choice between using an included avisynth version or the installed version, right now that's difficult due to the way how avisynth and tools are designed, it works with vapoursynth much better, like a couple of other things, it's more modern and ironically Python is not modern at all.

manolito

28th May 2020, 00:26

qyot27

28th May 2020, 01:40

Funny, usually it's the XP promoting posts that are not popular.
To be honest, I'm surprised pinterf and qyot27 go through so much trouble keeping XP users happy.
Most of the time it's just certain CMake parameters/CXXFLAGS/LDFLAGS given when configuring the project, so the only time consumed is what it takes to compile. As long as it's just something like that, I don't feel a compelling reason to drop it.

It's really not a whole lot of energy at all. Oh, copy-paste line 1 instead of line 2. Go fix some coffee.

kedautinh12

28th May 2020, 02:09

FranceBB

28th May 2020, 02:25

@FranceBB

I tried to reproduce your issues using C-Plugins with the latest test build by pinterf. But I couldn't...

What is this error about ScriptEnvironment? I do not understand. I have GrunT.dll in my autoload folder, and it does not interfere with anything. Do you autoload any GScript stuff?

The only C-Plugins I use are the old original YADIF plugin and the ffms2 C-plugin. And both work just fine under this latest pinterf test build. AVS+ autoloads these C-Plugins just fine, and under AVStoDVD (which does not use the VfW interface) both work without any issues.

This is under AVS+ 32-bit, Win7-64 .

I have GrunT as well in my auto-load folder, but that's not the problem. The problem is that whenever I call Avisynth with the C interface instead of the VfW interface, it prompts me to an ACCESS VIOLATION.
You see, just like you have Win7 and WinXP and you wanna keep one version of every plugin on both to keep everything in the two machines consistent, I have the very same setup on Win10 and WinXP where I keep everything the same (except for the x64 version which is Win10 only for me), however with Avisynth 3.6.x on XP x86 I can't use programs that call the frameserver using the C interface like AVSPmod, AVSMeter etc.
On Win10 it works like a charm now, though...
So it must be something in the C interface to call Avisynth that makes XP misbehave. Solving your problem in AVS 3.6.1 actually partially solved mine too, 'cause before, with AVS 3.6.0, not even the VfW interface was working, so we made progress. I'm sure Ferenc or qyot27 will come up with a solution.

Groucho2004

28th May 2020, 08:39

..however with Avisynth 3.6.x on XP x86 I can't use programs that call the frameserver using the C interface like AVSPmod, AVSMeter etc.AVSMeter uses the C++ API to interface with Avisynth.

pinterf

28th May 2020, 08:41

AvsMeter has no C interface.

And unfortunately for me all tools are working properly (Win10 with avs+ 32 or 64 bits), Avspmod, x264 versions, AvsMeter (32 and 64 bits)
But the problem needs to be investigated. Not because of XP support but it can be a hidden bug which later can occur on other systems as well.
No crash occurs without a good reason.

pinterf

28th May 2020, 08:43

Can you make 3.6.1 for megui win 10???
Grab it and use.
XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.

Groucho2004

28th May 2020, 09:18

@FranceBB
You're testing this on a vanilla XP, not the one with modified kernel, right?

pinterf

28th May 2020, 10:37

Unicode support could be improved

As a small step, if you need, you can open scripts from an unicode path, no need for ansi conversion.

https://github.com/staxrip/staxrip/blob/master/FrameServer/AviSynthServer.cpp#L72

AVSValue args[2] = { utf8file.c_str(), true };
const char* const arg_names[2] = { 0, "utf8" };
env->Invoke("Import", AVSValue(args, 2), arg_names);

FranceBB

28th May 2020, 11:29

@FranceBB
You're testing this on a vanilla XP, not the one with modified kernel, right?

Untouched SP3 on my VirtualBox VM where I test.
SP4 with Microsoft Extended Updates 'till July 2019, custom kernel with Win Vista and a bit of 7 backported APIs, unlocked PAE, DirectX 11 on my real PC.
They both behave the same in this case.
As a matter of fact, they've always behaved the same for Avisynth.
The custom kernel did the trick by implementing kernel calls necessary to run things like Audacity, Blender, Adobe Acrobat Reader DC and other things.

tormento

28th May 2020, 11:32

Grab it and use. XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.
Any caveat about performance, AVX etc?

Groucho2004

28th May 2020, 11:41

Untouched SP3 on my VirtualBox VM where I test.OK, just checking. :)

kedautinh12

28th May 2020, 12:02

Grab it and use.
XP support means that the DLL was built in an XP friendly way but runs on any OS without limitations.

I replaced 3.5.1 but can't open megui x64, moved back work again

LigH

28th May 2020, 12:16

@tormento:

Nothing is disabled. Xp as an os does not support avx and up but that's all

pinterf

28th May 2020, 12:39

I replaced 3.5.1 but can't open megui x64, moved back work again
See Megui section in first post. And the others as well.

stax76

28th May 2020, 12:41

As a small step, if you need, you can open scripts from an unicode path, no need for ansi conversion.

I saw the discussion with v0lt, made some experiments and thought if I could work around the limitation by creating soft links but gave up the idea. In another country I might have tried changing the system code page to utf8 which is a Win 10 feature, I'm on 1252. There was a post by TheFluff that explained there is some utf8 support in ffms2 and it appeared to work but not with the cachefile parameter, in that old thread I participated without great Unicode experience, it has improved meanwhile and my apps have solid Unicode support but find the topic still rather difficult, but also very interesting and important. I opened an avs Unicode issue in the mpv tracker and wm4 didn't have much good to say about avisynth, some time later I found out why, see here (https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe).

manolito

29th May 2020, 01:15

@FranceBB

I tried to reproduce your issues using C-Plugins with the latest test build by pinterf. But I couldn't...
-------------------------------------------------------
This is under AVS+ 32-bit, Win7-64 .

I believe this was a slight misunderstanding...

My tests were under Win7-64, not under WinXP. My XP computer has a single core CPU and only 576 MB of RAM. So using AVS+ with multithreading would not make sense. I tried it with a previous AVS+ version, but soon went back to classic AVS because it was faster.

After your issues I installed the current 3.61 test version under XP, but I could not get it working at all. The version() call returned the correct version, but neither AVStoDVD nor StaxRip were able to load any source files. AVStoDVD could not even detect an installed AviSynth version and gave me a non-fatal warning at startup. No crashes, though.

I never tried AVS+ 3.5.1 on the XP machine, but I suppose that it would work.

//EDIT//
Being curious and not tired yet I just did install the 3.5.1 XP version on my WinXP machine. And just as I suspected this version works fine under XP. Overinstalling the latest test version again broke it completely. So for me this 3.6.1 test version fixes all previous 3.6 issues under Win7, but it sure does not deserve the label "XP version".

FranceBB

29th May 2020, 01:53

After your issues I installed the current 3.61 test version under XP, but I could not get it working at all. The version() call returned the correct version, but neither AVStoDVD nor StaxRip were able to load any source files. AVStoDVD could not even detect an installed AviSynth version and gave me a non-fatal warning at startup. No crashes, though.

Exactly. You didn't try virtual dub, though. After your issue with Windows 7, Ferenc released another version and managed to make virtual dub work on XP.

In other words:

3.6.0 - nothing works.
3.6.1 - Programs accessing Avisynth directly don't work, but those who use VfW like virtual dub do.

I never tried AVS+ 3.5.1 on the XP machine, but I suppose that it would work.

Yes, 3.5.1 works like a charm.

Thank you for testing it on your system, though, it makes 2 out of 2 so I'm sure it's not related to my configuration.

manolito

29th May 2020, 02:59

3.6.0 - nothing works.
3.6.1 - Programs accessing Avisynth directly don't work, but those who use VfW like virtual dub do.

Right, I did not test VDub, just forgot about it. But I did test StaxRip 1.1.9.0 which also uses the VfW interface. Not good, it was unable to open any source file regardless of the source format. All source filters (DSS2Mod, ffms2, LSmash and DirectShowSource) quit with an error.

vcmohan

29th May 2020, 07:28

hi vcmohan
since you about update your plugins, can you make your plugins look for libfftw3f-3.dll first, then fftw3.dll like https://github.com/pinterf/fft3dfilter/blob/8c47e8d371afc7d6f9dce08ecb3443761a1cea00/fft3dfilter/FFT3DFilter.cpp#L711 ?
Certainly. But I do not know what all have changed from avisynth interface version 6 to this new version. Where can I get the avisynth new version header file?
Is there a problem if I look for fftw3.dll first or is there an advantage of looking for libfftw3f-3?

There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.

real.finder

29th May 2020, 09:05

Certainly. But I do not know what all have changed from avisynth interface version 6 to this new version. Where can I get the avisynth new version header file?

I think new version header here https://github.com/AviSynth/AviSynthPlus/tree/master/avs_core/include

Is there a problem if I look for fftw3.dll first or is there an advantage of looking for libfftw3f-3?

both, fftw3.dll were used to be old one that come with FFT3DFilter, the default name for new one one is libfftw3f-3.dll

There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.

don't know about this maybe pinterf or qyot27 will answer

pinterf

29th May 2020, 10:56

I have succesfully done an XP install inside my Win10 using the MS supported Win7 VirtualBox machine and started to debug.
Debug means that I write to debug output: "Hi, I am here", "Hi, I am there", etc.. and look the latest sign of life.
Presently there seems to be the problem with thread local storage technique which was needed for fixing the infamous mt bugs.
But it seems that XP behaves badly on this aspect when DLL is loaded dynamically so I'll dig into MSDN and StackOverflow, this will be a learning weekend.

pinterf

29th May 2020, 14:28

pinterf

29th May 2020, 15:23

There is some discussion on why MakeWritable was discouraged earlier. Then it was mentioned(if I remember correctly) that for this call avisynth has to anyway create a new frame, copy old frame and change/ set some flags while if its done in plugin by calling newvideoframe and copy using BitBlt its less work.
MakeWritable is create new frame + copy from original + copy frame properties. It preserves everything. You cannot make this task in less steps.
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3681

stax76

29th May 2020, 15:34

For staxrip it's a problem that avisynth.dll is located in system32 because this does not allow portable mode. staxrip uses about 10 avisynth tools, many just call LoadLibrary("avisynth.dll") which results in the DLL from system32 is used instead of the one from PATH which staxrip sets to enable portable mode.

It's not strictly necessary I believe that avisynth is located in system32 and it's probably also not good practice, vapoursynth don't put any DLL in system32 I believe (except VC++ redist), for compatibility with existing tools it would be necessarily to put avisynth in PATH.

pinterf

29th May 2020, 16:02

And a really portable version is not using registry.

stax76

29th May 2020, 16:44

For portable mode I needed minimal changes:

1. put in PATH: AviSynth, VapourSynth/Python, FFTW

2. create avisynth soft link for ffmpeg because ffmpeg blocks default DLL loading which uses PATH

For vapoursynth to use PATH:

core.std.LoadPlugin(..., altsearchpath=True)

Registry is not needed, PATH is modified per process, needed folders are put on top.

All this only works if avisynth is not installed, that is the problem, all fine with vapoursynth as it don't use system32.

manolito

29th May 2020, 18:43

Dear volunteers, please test this build, it is working on my XP so let's hope the best.
Avisynth+ v3.6.1 test build (20200529) (https://drive.google.com/file/d/1sDlI4Kdkf5PA2NyIkQ9XsrcCDs5QwHCg/view?usp=sharing)

Thanks very much...

Tested it first under Win7 to make sure that there are no regressions compared to the previous test build. And I could not detect any... :D

Then installed it under WinXP SP3. Most of the previous problems were gone. AVStoDVD and StaxRip could open files and process them without issues.

The only problem which is still there is the script environment. One of my avsi scripts uses GrunT and calls the GScriptClip function. This still does not work, I get this error message in the preview:
Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3)
Looks like the built-in ScriptClip function in AVS+ conflicts with the GScriptClip function from GrunT.
AVS+ 3.51 for XP handles this without errors.

FranceBB, what do you think?

FranceBB

29th May 2020, 21:17

Dear volunteers, please test this build, it is working on my XP so let's hope the best.
Avisynth+ v3.6.1 test build (20200529) (https://drive.google.com/file/d/1sDlI4Kdkf5PA2NyIkQ9XsrcCDs5QwHCg/view?usp=sharing)

Today I was told by the boss of my boss of my boss to stay at home on an enforced paid leave 'till June 14th even if I didn't want to and to come back on Monday June 15th as all sport events in every nation are gonna be back.

Such a dreadful day was quickly turned into a good one as I logged off from my server, opened this tread, found this build, tried it and saw that it's working perfectly.

Thank you, Ferenc, once again.
What would we do without you... :)

AVStoDVD and StaxRip could open files and process them without issues.

The only problem which is still there is the script environment. One of my avsi scripts uses GrunT and calls the GScriptClip function. This still does not work, I get this error message in the preview:

Looks like the built-in ScriptClip function in AVS+ conflicts with the GScriptClip function from GrunT.
AVS+ 3.51 for XP handles this without errors.

FranceBB, what do you think?

Well, I don't have StaxRip but avs4x264mod, AVSMeter, AVSPmod, PotPlayer, MPC-BE, MPC-HC, ffmpeg all work.

pinterf

29th May 2020, 21:28

Well, so it's (almost) working for at least two people, thanks for the feedback. Test it over the weekend, I'll be offline for some days (if I can :) ) because of a postponed Lth bd party, be good testers.

MeteorRain

29th May 2020, 23:48

I have never used megui so I wonder what that means. As I understand it, megui is just a frontend for various encoders and uses Avisynth to gather information about the source file/script. So, if I'm correct it just has to load the script and extract the information from it, right?

That's definitely challenging. AviSynth has a vfw interface, has a C++ interface, and has a C interface. I can trust vfw interface because it hasn't changed for decades. But C/C++ interface? They are vulnerable to all kinds of compatibility issues.

Out of curiosity, I am bit confused about how the HBD plugins treat the images.

AFAIK the most used bit depths nowadays are 8 and 10 (12 on some specialized streams only).

How does it work when you set HBD or a plugin receives a HBD?

Doest it switch to 16 bits (or more) regardless of true bit depth or does it work with the same bit depth of the source?

Because if it goes straight to 16 bit to work on a 10 bit stream, it seems to me really a waste of power and it would need a dedicated algorithm to process 10 bit only, as they are the second most common after 8, and get faster.

All depends on how the author writes the plugin, and also depends on how complicated the plugin is.
For example, a simple medium filter does not need to raise bit depth because no computing is needed. However a similar average filter may need to raise bit depth because average operation gets accuracy benefit from higher bit depth.

Also for some plugins it's easier to raise 10-14 bit to 16 bit so you only need to write a 16 bit version, and a bit shifter / dither.

vcmohan

30th May 2020, 12:24

MakeWritable is create new frame + copy from original + copy frame properties. It preserves everything. You cannot make this task in less steps.
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/avisynth.cpp#L3681

Well thanks for dispelling misconception. So I will hearafter use this wherever appropriate. I have been using env2->Allocate(.......) to get required buffer for thread safety. It looks I can not get over this problem easily by testing for version. Or can I do a similar try and catch scenario? like
if (v8) env->Allocate(...); else env2->Allocate(...)

StainlessS

30th May 2020, 14:04

@ vcmohan, I had posted this previously
Not sure but I think MakeWritable was originally referred to as the "MakeWritable hack" [and was used via a MACRO/define, probably some time prior to v2.58],
it was later officially incorporated as env->MakeWritable(&src);

So nothing wrong now using MakeWritable.

EDIT: DG would probably remember exactly, it was before my time with avs.

Was a bit before my time here though.

EDIT: You still see some MakeWriteable hack references in old source code.

manolito

30th May 2020, 23:20

Well, so it's (almost) working for at least two people, thanks for the feedback. Test it over the weekend,

Did some more tests under Win7 and WinXP, but I did not find anything new. Under Win7 there are no issues whatsoever, and under XP this "GScriptClip" issue is the only problem I found.

I am not very knowledgeable about the AVS runtime stuff. But after calling "GScriptClip" this error message is a little confusing:
Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3)
I did not call ScriptClip at all. There is no text file "ScriptClip" with line numbers in my plugin folder. Does the GRunT "GScriptClip" function call the internal AVS "ScriptClip" function? Sure looks like it.

Something must have changed with the internal "ScriptClip" function of AVS+ after version 3.5.1.

It is not a big deal, though. The "GScriptClip" call can be replaced with a "ConditionalFilter" call, and this method works. The drawback is that "ConditionalFilter" does not work well in MT mode (this is what I read), but then again I cannot use MT anyways on my WinXP computer.

Cheers
manolito

StainlessS

30th May 2020, 23:58

What is your script Mani ?

manolito

31st May 2020, 00:34

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
\ (" + string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
\ (" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M",
\ args = "EMskip,M,B,BHard", Local=true)

Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.

StainlessS

31st May 2020, 03:51

GScriptClip is just an nicety to explicitly state that you are using Grunt version of Scriptclip.
The alternative (G*) names may be used if you wish, but this is optional in AviSynth version 2.58 or later
http://avisynth.nl/index.php/GRunT#ScriptClip

The fact that you use Args arg, should only use Grunt version G/Scriptclip (Avs+ ver$ dont have Args arg).

The Float thing got me stumped :(

Your ScriptClip call had me a little perplexed/confused, not easy to read, and so I started dissecting it,
and once I started could not stop, it dont look correct to me when compared to the original commented out ConditionalFilter stuff.

Hope you can figure this lot out, I'm whacked and gotta get some kip soon.

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M

# Roughly Mani script
SSS="""
Skip = EMskip.AverageLuma()
("
+ string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
(" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M
"""

# Vars with trailing '_I' are numbers directly inserted. Renamed Skip to AverageLuma_Skip.
SSS="""
AverageLuma_Skip = EMskip.AverageLuma()
(SkipOver_I > 0 && AverageLuma_Skip >= SkipOver_I ) ? BHard : (BlendOver_I > 0 && AverageLuma_Skip >= BlendOver_I) ? B : M
"""

# Dissect original Conditionalfilter stuff.
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
M2 = SkipOver <= 0 || AverageLuma_Skip < SkipOver ? B : BHard # Equivalent
M2 = SkipOver > 0 && AverageLuma_Skip >= SkipOver ? BHard : B #

# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = Blendover_I <= 0 || AverageLuma_Skip < Blendover_I ? M : M2 # Equivalent
M = Blendover_I > 0 && AverageLuma_Skip >= Blendover_I ? M2 : M #

# Only calc M2 [ie B or BHard] when we have to, ie detect where M result first. # All 4 Equivalent (Hopefully)
M = (Blendover_I <= 0 || AverageLuma_Skip < Blendover_I) ? M : (SkipOver <= 0 || AverageLuma_Skip < SkipOver) ? B : BHard
M = (Blendover_I <= 0 || AverageLuma_Skip < Blendover_I) ? M : (SkipOver > 0 && AverageLuma_Skip >= SkipOver) ? BHard : B
# I hate doing ternary conditionals this way, possibly messed these 2 up.
M = (Blendover_I > 0 && AverageLuma_Skip >= Blendover_I) ? (SkipOver <= 0 && AverageLuma_Skip < SkipOver) ? B : BHard : M
M = (Blendover_I > 0 && AverageLuma_Skip >= Blendover_I) ? (SkipOver > 0 && AverageLuma_Skip >= SkipOver) ? BHard : B : M

# Somewhat different to this (Should only be BHard or B when BlendOver > 0 && AverageLuma_Skip >= Blendover_I, Otherwise always M)
(SkipOver_I > 0 && AverageLuma_Skip >= SkipOver_I ) ? BHard : (BlendOver_I > 0 && AverageLuma_Skip >= BlendOver_I) ? B : M

Hope I aint screwed up, I'm sure somebody will delight in pointing it out if I have [and please do] :)

real.finder

31st May 2020, 14:10

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:

Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.

can you try this? https://www.solidfiles.com/v/Q4WmdaAZ3jMYn

pinterf

31st May 2020, 15:25

The script is my modded and simplified version of the MysteryX FrameRateConverter script. This is the relevant section:

Works well under AVS+ 3.5.1, but gives me this ScriptClip error under the 3.6.1 test version.

Forgot to mention in my previous post that I have to use GRunT 1.01 by Gavino. The updated pinterf version 1.02 does not run on my Non-SSE2 CPU.
Uh, I think I found another unhandled case when a 2.5 plugin function (namely ScriptClip clone in Cpp 2.5 GRunT) is created but it calles back Invoke in the filter constructor before instantiating itself.

pinterf

31st May 2020, 15:33

Selur

31st May 2020, 16:21

Having some issue with older plugins and scripts, but posted to the older thread (why isn't that one closed?) since I overlooked that this one exists.
-> https://forum.doom9.org/showthread.php?p=1914333#post1914333
in short:
Loading PlanarTools.dll and SMDegrain fails too. SMDegrain seems to rely 'VersionString' which seems to have changed,.. :/

Known issues
- Due to interface extensions, some plugins relying on old IScriptEnvironment2 no longer work (=crash)
- CPP 2.5 plugins which are using "Invoke" will probably have problems. (perhaps addressed in 3.6.1)
that explains PlanarTools and some other plugins that have problems,..

Cu Selur

manolito

31st May 2020, 18:23

New build:
Avisynth+ 3.6.1. test build 4 - 20200531 (https://drive.google.com/file/d/1EfjzGE9qSYc-ZZAakT2xbIrkpHJ_pwxI/view?usp=sharing)

@manolito: please test with your script that was giving you that strange error of
"Script error: 'Float' cannot be called. Give me a function! ([ScriptClip] Line 3) "
I wonder what message you get this time (if any)
Thanks!

Just did make a few tests using this latest test build 4, but unfortunately the error message is identical to test build 2.

I also tried to replace GRunT 1.01 with the 1.02 build which real.finder just made, but the results are the same.

manolito

31st May 2020, 18:26

can you try this? https://www.solidfiles.com/v/Q4WmdaAZ3jMYn

Thanks for this build. It does work nicely on my ancient computer, but it does not fix the GScriptClip error with the latest AVS+ 3.61 test build.

manolito

31st May 2020, 18:35

Your ScriptClip call had me a little perplexed/confused, not easy to read, and so I started dissecting it,
and once I started could not stop, it dont look correct to me when compared to the original commented out ConditionalFilter stuff.

Sorry, this GScriptClip code is over my head...

It is from MysteryX, I did not modify it in any way. He later replaced it with his own function "ConditionalFilterMT" which is included in his "framerateconverter.dll". But this DLL needs SSE2, so I had to go back to the GScriptClip version. And this works under oder AVS and AVS+ versions up to 3.5.1.

real.finder

31st May 2020, 18:36

but it does not fix the GScriptClip error with the latest AVS+ 3.61 test build.

I think no one but pinterf will fix it :) maybe it some 2.5 plugin that confused the GScriptClip, is your plugins folder in win7 is the same as the one in winxp?

pinterf

31st May 2020, 18:48

Just did make a few tests using this latest test build 4, but unfortunately the error message is identical to test build 2.

I also tried to replace GRunT 1.01 with the 1.02 build which real.finder just made, but the results are the same.
Thanks, I have to solve this because I don't like things that work here and do not work there.

pinterf

31st May 2020, 19:03

EDIT: no need for that, I've got the message now
Hi, manolito, I cannot reproduce that specific error ("float..."), I had other problems with it and the test4 fix the issue what I have experienced.
For the reproducibility I'd need your script, or better, if you are able to make a minimal version from it that still exhibits that stupid error message.
If not, I'll make it shorter myself. Thanks.
EDIT: no need for that, I've got the message now

manolito

31st May 2020, 19:22

No problem...

I already shortened the original MysteryX script considerably and modified it to run under WinXP without requiring SSE2. It also only needs the "oldfashioned" plugins without Hi Color and Hi Bitdepth.

# Frame Rate Converter
# Version: 2-June-2019
# By Etienne Charland aka MysteryX
# Based on Oleg Yushko's YFRC artifact masking,
# johnmeyer's frame interpolation code, and
# raffriff42's "weak mask" and output options.
# Pinterf is the one who spent the most time working on the core libraries, adding features and fixing bugs
# Slightly simplified user interface and code cleanup by manolito
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA, or visit
# http:#www.gnu.org/copyleft/gpl.html.

#######################################################################################
### mx_fps
### Changes the frame rate with interpolation and fine artifact removal.
##
## YV12/YUY2
## Requires: MaskTools2, MvTools2, GRunT, RemoveGrain, ConvertFpsLimit, FFTW3.dll (in the system32 or syswow64 folder) for Dct values other than 0
##
## @ fps - The new framerate.
##
## @ Preset - The speed/quality preset [slow|normal|fast]. (default=normal)
##
## @ BlkSize - The block size. Supported values are 8, 16 and 32.
## Defaults for 4/3 video of height:
## 0-359: 8
## 400-1199: 16
## 1200-2160: 32
##
## @ BlkSizeV - The vertical block size. (default = BlkSize)
##
## @ Output - Output mode [auto|flow] (default = auto)
## auto=normal artifact masking; flow=interpolation only
##
## @ Prefilter - Specified a custom prefiltered clip. (default = C.RemoveGrain(22))
##
## @ Mask - Enable artifact masking (default = true)
##
## @ MaskTrh - The treshold where a block is considered bad, between 0 and 255. Smaller = stronger.
## 0 to disable artifact masking. (default = 100)
##
## @ MaskOcc - Occlusion mask treshold, between 0 and 255. 0 to disable occlusion masking. (default = 105)
##
## @ SkipTrh - The treshold where a block is counted for the skip mask, between 0 and 255. Smaller = stronger.
## Must be smaller (stronger) than MaskTrh. (default = 55)
##
## @ BlendOver - Try fallback block size when artifacts cover more than specified treshold, or 0 to disable.
## If it fails again, it will revert to frame blending. (default = 60)
##
## @ SkipOver - Skip interpolation of frames when artifacts cover more than specified treshold,
## or 0 to disable. (default = 120)
##
## @ Dct - Overrides DCT parameter (default: Fast=0, Normal=0, Slow=1)
## Useful values are 0, 4 and 1.
##
## @ BlendRatio - Changes the blend ratio used to fill artifact zones. 0 = frame copy and 100 = full blend.
## Other values provide a result in-between to eliminate ghost effects. Default = 40.
##
## Presets
## Fast: Basic interpolation
## Normal: Fast + prefilter + MSuper on prefilter + MRecalculate
## Slow: Normal + DCT=1
##

function mx_fps(clip C, float "fps", string "Preset", int "BlkSize", int "Dct", bool "Mask")
{
Preset = Default(Preset, "normal")
P_SLOW = 1 P_NORMAL = 2 P_FAST = 3
Pset = Preset == "slow" ? P_SLOW : Preset == "normal" ? P_NORMAL : Preset == "fast" ? P_FAST : -1
Assert(Pset != -1, "mx_fps: 'Preset' must be slow, normal or fast {'" + Preset + "'}")
Mask = Default(Mask, true)
Output = Mask ? "auto" : "flow"
O_AUTO = 0 O_FLOW = 1
OPut = Output == "auto" ? O_AUTO : Output == "flow" ? O_FLOW : -1

fps = default(fps, 25.000)
NewNum = int(fps * 1000)
NewDen = 1000
DefH = Max(C.Height, C.Width/4*3)
BlkSize = Default(BlkSize, DefH<360 ? 8 : DefH<1200 ? 16 : 32)
Assert(BlkSize == 8 || BlkSize == 16 || BlkSize == 32, "mx_fps: BlkSize must be 8, 16 or 32")
BlkSizeV = BlkSize
MaskTrh = 100
SkipTrh = 55
MaskOcc = MaskTrh > 0 ? 105 : 0
BlendOver = 60
SkipOver = 120
CalcPrefilter = Pset != P_FAST
Prefilter = CalcPrefilter ? C.RemoveGrain(22) : C
Recalculate = PSET <= P_NORMAL
Dct = Default(Dct, PSET == P_SLOW ? 1 : 0)
BlendRatio = 40

## "B" - Blending, "BHard" - No blending
Try {
B = C.ConvertFpsLimit(NewNum, NewDen, ratio=BlendRatio)
}
Catch(Err_Msg) {
B = C.ChangeFps(floor(fps * 3/2)).ConvertFpsLimit(NewNum, NewDen, ratio=BlendRatio)
}
BHard = C.ChangeFps(NewNum, NewDen)
Blank = BlankClip(C.ConvertToY8(), color_yuv=$000000)

## Adjust parameters for different block sizes, causing stronger or weaker masks
blk = Max(BlkSize, BlkSizeV)
MaskTrh = MaskTrh + (blk<=8 ? -20 : blk<=16 ? 0 : blk<=32 ? 20 : 35)
SkipTrh = SkipTrh + (blk<=8 ? -18 : blk<=16 ? 0 : blk<=32 ? 16 : 30)
MaskTrh = Max(Min(MaskTrh, 255), 0)
SkipTrh = Max(Min(SkipTrh, 255), 0)
gam = blk<=8 ? .56 : blk<=16 ? .50 : blk<=32 ? .36 : .14

## jm_fps interpolation
superfilt = MSuper(prefilter, hpad=16, vpad=16, sharp=1, rfilter=4) # all levels for MAnalyse
super = CalcPrefilter ? MSuper(C, hpad=16, vpad=16, levels=1, sharp=1, rfilter=4) : superfilt # one level is enough for MRecalculate
bak = MAnalyse(superfilt, isb=true, blksize=BlkSize, blksizev=BlkSizeV, overlap = (BlkSize/4+1)/2*2, overlapv = (BlkSizeV/4+1)/2*2, search=3, dct=Dct)
fwd = MAnalyse(superfilt, isb=false, blksize=BlkSize, blksizev=BlkSizeV, overlap = (BlkSize/4+1)/2*2, search=3, dct=Dct)
fwd = Recalculate ? MRecalculate(super, fwd, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : fwd
bak = Recalculate ? MRecalculate(super, bak, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : bak
Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)

## "EM" - error or artifact mask
# Mask: SAD
EM = MaskTrh > 0 ? C.ConvertToY8().MMask(bak, ml=255, kind=1, gamma=1/gam, ysc=255, thSCD2=255) : Blank
# Mask: Temporal blending
EMfwd = MaskTrh > 0 ? C.ConvertToY8().MMask(fwd, ml=255, kind=1, gamma=1/gam, thSCD2=255) : EM
EM = MaskTrh > 0 ? EM.Overlay(EMfwd, opacity=.6, mode="lighten", pc_range=true) : EM
# Mask: Occlusion
EMocc = MaskOcc > 0 ? C.ConvertToY8().MMask(bak, ml=MaskOcc, kind=2, gamma=1/gam, ysc=255, thSCD2=255).mt_inpand() : Blank
EM = MaskOcc > 0 ? EM.Overlay(EMocc, opacity=.4, mode="lighten", pc_range=true) : EM

# Last mask frame is white. Replace with previous frame.
EM = EM.DeleteFrame(EM.Framecount-1).Loop(2, EM.Framecount-1)

# Create skip mask
EMskip = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(SkipTrh)

## Create artifact correction mask
Try {
EM = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(MaskTrh)
\ .Blur(.6)
\ .BicubicResize(C.Width, C.Height)
}
Catch(Err_Msg) {
Try {
BlkSize = BlkSize/2
EM = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(MaskTrh)
\ .Blur(.6)
\ .BicubicResize(C.Width, C.Height)
}
Catch(Err_Msg) {
BlkSize = BlkSize/2
EM = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(MaskTrh)
\ .Blur(.6)
\ .BicubicResize(C.Width, C.Height)
}
}

## "M" - Apply artifact removal
EM = EM.ChangeFPS(NewNum, NewDen)
EMskip = EMskip.ChangeFPS(NewNum, NewDen)
M = mt_merge(Flow, B, EM, luma=true, chroma="process")

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
\ (" + string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
\ (" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M",
\ args = "EMskip,M,B,BHard", Local=true)

# Output modes
R= (Oput==O_AUTO) [** auto: artifact masking *]
\ ? M
\ : (Oput==O_FLOW) [** flow: interpolation only *]
\ ? Flow
\ : nop

return R
}

pinterf

31st May 2020, 19:23

manolito

31st May 2020, 19:32

FWIW here is the All-In-One version with all the dependencies:
https://www.sendspace.com/file/l24pez

real.finder

31st May 2020, 19:41

FWIW here is the All-In-One version with all the dependencies:
https://www.sendspace.com/file/l24pez

while pinterf test, can you try make the plugins (autoload folder) in your winxp same as the one in your win7 one? then see if the win7 is ok or not, if it ok, then try in the winxp (same plugins and encoding script)

pinterf

31st May 2020, 19:51

Gee,
In manolito's example ScriptClip string parameter was assembled inline with \ and there is no other separator in the resolved string.

Minimal reproduction:

ColorBars()
x = 10 (x > 0) ? last : last

"Int cannot be called, give me a function"

It thinks that 10 (or AverageLuma's return value in the original example which is a float type) have to be treated as a function.

Note: since 3.6 you can have function variables as well (a nice addition from Nekopanda), so a function's return value can be a function object itself. (see readme_history.txt for examples)
Since the 10 (or AverageLuma()) was followed by a parenthesis, the expression preceeding the "(" is expected to be a function object. But it's not a function object, obviously.

Now I have to resolve that case.

pinterf

31st May 2020, 20:10

Or not.
The previous example is the special case of the following (stupid) script
ColorBars()
z = 0
y = 10
x = y (z > 0) ? last : last
there is no function called 'y'

So you cannot have this construction valid, because there is no newline before (SkipOver>0 && Skip>SkipOver)

M = M.GScriptClip("Skip = EMskip.AverageLuma()
\ (" + string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
\ (" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M",
\ args = "EMskip,M,B,BHard", Local=true)

What do language lovers say?

manolito

31st May 2020, 20:32

All this ScriptClip stuff is way over my head...

All I can say is that I got this GScriptClip call from an older version of FrameRateConverter which was later replaced by a ConditionalFilterMT call (which I cannot use on my XP computer).

So I am not in a position to judge the correctness of this GScriptClip syntax. But I do know that it worked on previous AVS and AVS+ versions up to 3.5.1.

StainlessS

31st May 2020, 23:55

@Mani,
Yep, but the script you were using was your own conversion of Mx script, I was just saying that the convert was not terribly good, logic ****'ed a bit,
I spent probably a couple of hours trying to understand the original, was awkwardly expressed to begin with (by MX), and was
totally understandable that you had problems doing it your own way, but point is that implementation of your scrip as is, is wrong,
not putting this up to piss you off, I am saying that your results have probably been in error, by how much, I dont know.

EDIT: Full of beer right now, I'll come back if you need assist, spent all night OUTSIDE in the street, just enjoying the feel of not being
locked up [with a good supply of beer and cider ].

EDIT: Merry, Not being locked up, day.

EDIT: I wish I could experience the feel of being incarcerated for a year or two, just so I could experience the feel of being 'let, go', must be great :)
[Mind you, afterwards I might wanna sit on top of a casino and start shooting people, so maybe not so good an idea]

EDIT: Of course the big question is, where can I shoot people for fun, without gettin' caught ? [EDIT: No Answers required, please dont PM me, and yes I'm talkin' to you DG :) ]

manolito

1st June 2020, 02:53

@Mani,
Yep, but the script you were using was your own conversion of Mx script, I was just saying that the convert was not terribly good, logic ****'ed a bit,
I spent probably a couple of hours trying to understand the original, was awkwardly expressed to begin with (by MX), and was
totally understandable that you had problems doing it your own way, but point is that implementation of your scrip as is, is wrong,
not putting this up to piss you off, I am saying that your results have probably been in error, by how much, I dont know.

Sorry, no, you got it wrong...

I did simplify the original MX script quite a bit, but I did not alter this "Apply Blendover and Skipover " section at all. All the different FrameRateConverter versions from 2017 feature exactly this code:

## Apply BlendOver and SkipOver
M2 = SkipOver > 0 ? ConditionalFilterMT(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
M = BlendOver > 0 ? ConditionalFilterMT(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
# M = M.GScriptClip("Skip = EMskip.AverageLuma()
# \ (" + string(SkipOver) + " > 0 && Skip >= " + string(SkipOver) + ") ? BHard :
# \ (" + string(BlendOver) + " > 0 && Skip >= " + string(BlendOver) + ") ? B : M",
# \ args = "EMskip,M,B,BHard", Local=true)

And since I could not use ConditionalFilterMT on my machime, I used te GScriptClip version. This code is the unmodified code by MysteryX, I did not change it in any way.

So if you determined that my script is wrong, then it means that the original MX script was wrong because I just copied and pasted it.

Selur

1st June 2020, 08:03

Reel.Deel

1st June 2020, 08:29

Does anyone know how to get:

sRestore
HDR AGC
SmoothCurve (from SmoothAdjust)
SmDeGrain (https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/SMDegrain.avsi doesn't work)
KNLMeansCL (used in TemporalDegrain2)
JincResize
YadifMod2
TMM2

working with Avisynth 3.6 (32bit) or whether there is an update for them somewhere?

sRestore: are you using all of the lastest versions from pinterf? (MaskTools2, TIVTC, RgTools, Average, GRunT) ... https://github.com/pinterf?tab=repositories
JincResize: are you using r44? http://avisynth.nl/index.php/JincResize
KNLMeansCL: https://github.com/pinterf/KNLMeansCL/releases
YadifMod2: https://github.com/Asd-g/yadifmod2/releases
TMM2: https://github.com/Asd-g/TMM2/releases
HDRAGC and SmDeGrain: what are the errors messages, if any?
SmoothAdjust: pray that LaTo still visits time to time. :)
A handful of Chikuzen's plugin had to be rebuilt, you can find many of them here: https://github.com/Asd-g?tab=repositories

Selur

1st June 2020, 09:17

@Reel.Deel:

sRestore: updated all Plugins and now I get 'I don't know what 'AvsPlusVersionNumber' means.'
JincResize: thanks accidentally used the Vapoursynth dll when updating :/
KNLMeansCL: thanks, the 'unofficial test build' works :)
YadifMod2: thanks that build works :)
TMM2: thanks that build works
SMDeGrain: reports: 'I don't know what 'AvsPlusVersionNumber' means.'
HDR AGC: simple reports: 'System exception - Access Violation'

A handful of Chikuzen's plugin had to be rebuilt, you can find many of them here: https://github.com/Asd-g?tab=repositories
Thanks a lot, I'll update my plugins. :)

Cu Selur

Reel.Deel

1st June 2020, 09:26

@Reel.Deel:

sRestore: updated all Plugins and now I get 'I don't know what 'AvsPlusVersionNumber' means.'
JincResize: thanks accidentally used the Vapoursynth dll when updating :/
KNLMeansCL: thanks, the 'unofficial test build' works :)
YadifMod2: thanks that build works :)
TMM2: thanks that build works
SMDeGrain: reports: 'I don't know what 'AvsPlusVersionNumber' means.'
HDR AGC: simple reports: 'System exception - Access Violation'

Thanks a lot, I'll update my plugins. :)

Cu Selur

sRestore and SMDeGrain: you need https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi

HDRAGC: hopefully it will be fixed in AviSynth+ 3.6.1. There is a test version posted by pinterf some days ago.

Gavino

1st June 2020, 11:35

(especially @manolito, @pinterf)

Joining this thread a bit late, and I haven't caught up with all the details yet, but ...

GScriptClip is essentially a wrapper around the built-in ScriptClip, which it calls to do most of the work - this is by design so that it will continue to work and pick up any future changes to the built-in filter.
Since it uses Invoke() to call the 'real' ScriptClip, GRunT may need to be changed if there is some incompatibility with recent changes to Invoke(). I haven't kept up with this topic, and don't have time to study it in detail, but pinterf seems to have the problem under control.

However, if I understand correctly, manolito's problem is not caused by GScriptClip itself, but by recent language changes which mean that the run-time script he passes to GScriptClip no longer works. Because expressions can now produce a value representing a function, a newline is required before a new statement that starts with an opening parenthesis (to prevent the parenthesis being interpreted as part of a function call), as in pinterf's example
x = y (z > 0) ? last : last

Since manolito's runtime script is constructed by string concatentation, the failing statement is less obvious, but (again if I understand correctly) it can be fixed by adding newlines where appropriate when constructing the string.

Is this a correct summary of the situation?

ChaosKing

1st June 2020, 12:00

@Selur have a look at AVSRepo https://forum.doom9.org/showthread.php?t=175822

Just run .\avsrepo-32.exe -t win32 install srestore tmm2 smdegrain yadifmod2 jincresize and you'll get the latest versions with all dependencies

pinterf

1st June 2020, 12:19

(especially @manolito, @pinterf)

However, if I understand correctly, manolito's problem is not caused by GScriptClip itself, but by recent language changes which mean that the run-time script he passes to GScriptClip no longer works. Because expressions can now produce a value representing a function, a newline is required before a new statement that starts with an opening parenthesis (to prevent the parenthesis being interpreted as part of a function call), as in pinterf's example
x = y (z > 0) ? last : last

Since manolito's runtime script is constructed by string concatentation, the failing statement is less obvious, but (again if I understand correctly) it can be fixed by adding newlines where appropriate when constructing the string.

Is this a correct summary of the situation?

Yes. My final example - in which 'y' is followed by () - does not need ScriptClip at all. What's more, it even does not need any new language construct or newer Avisynth+ to give error.

Gavino

1st June 2020, 13:22

Yes. My final example - in which 'y' is followed by () - does not need ScriptClip at all. What's more, it even does not need any new language construct or newer Avisynth+ to give error.
Yes, you're right.
That has always been illegal (and correctly so).
What seems to have changed is that replacing 'y' by '10' (or perhaps any expression at all?), now no longer works, when it did before.

Selur

1st June 2020, 13:23

sRestore and SMDeGrain: you need https://raw.githubusercontent.com/realfinder/AVS-Stuff/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi
Thanks,... using Avisynth scripts gets more and more arcane, more and more dependencies.

Tried with the 3.6.1 test version, didn't help with HDRAGC.

manolito

1st June 2020, 16:26

while pinterf test, can you try make the plugins (autoload folder) in your winxp same as the one in your win7 one? then see if the win7 is ok or not, if it ok, then try in the winxp (same plugins and encoding script)

That's exactly what I always do, because I want to have identical autoload folders on all my computers, no matter which AVS versions I use.

When upgrading from classic AVS 2.61 to AVS+ I overinstall AVS+ in the same folder as AVS 2.61. Then I choose the option to uninstall the previous version and merge the old plugins. This method will automatically remove DirectShowSource.dll from the plugins folder (it has a new DLL in the plugins+ folder). The only things I need to change manually are editing a few AVSI files which are there to autoload C-Plugins. This is no longer necessary under AVS+, so the LoadCPlugin() calls can be removed.

So there are only minor differences between my plugin folders for classic AVS and AVS+. And these plugin folders are identical between Win7 and WinXP. Which of course means that oftentimes I cannot use new plugin versions under Win7 because lots of them will not work under XP. And I do not want to have different plugin versions on my different computers. Least common denominator...

manolito

1st June 2020, 16:30

Thanks,... using Avisynth scripts gets more and more arcane, more and more dependencies.

Amen...

manolito

1st June 2020, 16:38

Because expressions can now produce a value representing a function, a newline is required before a new statement that starts with an opening parenthesis (to prevent the parenthesis being interpreted as part of a function call), as in pinterf's example
x = y (z > 0) ? last : last

Since manolito's runtime script is constructed by string concatentation, the failing statement is less obvious, but (again if I understand correctly) it can be fixed by adding newlines where appropriate when constructing the string.

Is this a correct summary of the situation?

Thanks Gavino for chiming in...

Yes, your summary is absolutely correct. So just adding newlines where appropriate would fix this script.

My question is if this fixed script would still work under older AVS versions. It absolutely needs to work under different AVS versions.

Reel.Deel

1st June 2020, 16:56

Thanks,... using Avisynth scripts gets more and more arcane, more and more dependencies.

I agree, keeping up with real.finder's scripts has been a daunting task. Poor beginners :D. First QTGMC needed some fuctions in SMDegrain, now those functions have been moved to Zs_RF_Shared.avsi, any script that used said functions now requires the helper script. Best thing to do is just to have a copy of the lastest Zs_RF_Shared.avsi ready anytime you use any of his scripts.

Gavino

1st June 2020, 17:06

My question is if this fixed script would still work under older AVS versions. It absolutely needs to work under different AVS versions.
Yes, it would.
A newline has always terminated a statement or expression and still does.
So, as long as your fix puts them in the right places, you should be OK. :)

I must say I share your concern at the bewildering number of changes to AviSynth, which I confess I have been unable to keep up with.
Progress is always to be welcomed, but sometimes it comes at the expense of clarity and a simple and consistent approach. (Just my two cents.)

gispos

1st June 2020, 17:58

MP Pipeline also no longer works with the new versions. And probably also a number of other plugins, I'm back on 3.5 3043
At the moment the whole thing is too complicated for me.:)

FranceBB

1st June 2020, 19:13

MP Pipeline also no longer works with the new versions.

I can reproduce that.

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

I tried with a real world script and it failed the same way it failed with:

MP_Pipeline("""

ColorBars(848, 480, pixel_type="YV12")

### ###

""")

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

Apart from that, the other plugins I tried are working.

manolito

1st June 2020, 19:20

I do not use MP_Pipeline, but I can reproduce the HDRAGC crashes under 3.61 test version 4.
BUT:
It works well under test version 2. Must be some regression in test version 4.

Reel.Deel

1st June 2020, 19:38

Are you guys using pinterf's MP_Pipeline? https://github.com/pinterf/MP_Pipeline/releases

gispos

1st June 2020, 20:07

Are you guys using pinterf's MP_Pipeline? https://github.com/pinterf/MP_Pipeline/releases
Of course yes

FranceBB

1st June 2020, 20:17

Are you guys using pinterf's MP_Pipeline? https://github.com/pinterf/MP_Pipeline/releases

Yep. That's the one.

StainlessS

1st June 2020, 20:31

Sorry, no, you got it wrong...

I did simplify the original MX script quite a bit, but I did not alter this "Apply Blendover and Skipover " section at all. All the different FrameRateConverter versions from 2017 feature exactly this code:

And since I could not use ConditionalFilterMT on my machime, I used te GScriptClip version. This code is the unmodified code by MysteryX, I did not change it in any way.

So if you determined that my script is wrong, then it means that the original MX script was wrong because I just copied and pasted it.
OK, thanks for straitening me out :)

Maybe you like to try this

The first line is same as previously given as from dissection of the ConditionalFilter versions of script.
The second line just moves both BlendOver's and SkipOver's to the left, side of comparisons, less confusing [at least for me] to have them on same side.

#M = (Blendover <= 0 || AverageLuma_Skip < Blendover) ? M : (SkipOver <= 0 || AverageLuma_Skip < SkipOver) ? B : BHard
#M = (Blendover <= 0 || Blendover > AverageLuma_Skip ) ? M : (SkipOver <= 0 || SkipOver > AverageLuma_Skip ) ? B : BHard

And the GScriptClip conversion

M = "Skip = AverageLuma" + Chr(10)
\ + "(" + string(Blendover) + " <= 0 || " + string(Blendover) + " > Skip) ? M :" + Chr(10)
\ + "(" + string(SkipOver) + " <= 0 || " + string(SkipOver) + " > Skip) ? B : BHard"

Hope it works.
Maybe MysteryX changed the Conditionalfiltering and omitted to update the gscript stuff.

Anyway, above I believe should give same result as conditionalFilter version.

EDIT: forgot the GScriptClip bit

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = AverageLuma" + Chr(10)
\ + "(" + string(Blendover) + " <= 0 || " + string(Blendover) + " > Skip) ? M :" + Chr(10)
\ + "(" + string(SkipOver) + " <= 0 || " + string(SkipOver) + " > Skip) ? B : BHard",
\ args = "EMskip,M,B,BHard", Local=true)

manolito

1st June 2020, 21:13

Thanks StainlessS,

yes, those missing newlines were exactly what Gavino had to say, and he also said that adding them in the appropriate places should fix it, and this fixed script should also work with older AVS versions.

I will test it later tonite (I got to have dinner first, I'm starving) and report back.

Another question:
In later FrameRateConverter versions MysteryX abandoned this GScriptClip version and replaced it with ConditionalFilterMT which is part of his framerateconverter.dll.
This is what he wrote about the reason why he made this MT version:
Avisynth+ MT provides great capabilities to process videos. However, conditional functions are not compatible with MT (multi-threading) due to design limitations. To work around this problem, this class provides a subset of conditional features that will work with MT mode
Now I would like to know if this is still true for the newest AVS+ versions. If not then I could just use the built-in ConditionalFilter version (without the MT) and be done with it. Maybe pinterf could shed some light on this question...

manolito

1st June 2020, 23:33

Sorry, doesn't work...
This time I get a "Script Error: Syntax Error" plus a line number.

Looks like "adding the newlines in the appropriate places" is the tricky thing here.

StainlessS

1st June 2020, 23:49

OK, I musta cocked up somewhere, still looks ok to me.
I'll embed into your script and see if I cant find the problem.

Gavino

2nd June 2020, 00:08

M = M.GScriptClip("Skip = AverageLuma" + Chr(10)
\ + "(" + string(Blendover) + " <= 0 || " + string(Blendover) + " > Skip) ? M :" + Chr(10)
\ + "(" + string(SkipOver) + " <= 0 || " + string(SkipOver) + " > Skip) ? B : BHard",
\ args = "EMskip,M,B,BHard", Local=true)

That second chr(10) should not be there as this is in the middle of an expression.
The first one is I think the only one required.

StainlessS

2nd June 2020, 00:12

Yeh, I figured it out big G [thanks], this should work

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip=AverageLuma"+Chr(10)
\ +"("+string(Blendover)+"<=0||"+string(Blendover)+">Skip)?M:"
\ +"("+string(SkipOver) +"<=0||"+string(SkipOver) +">Skip)?B:BHard",
\ args="EMskip,M,B,BHard",Local=true)

EDIT: Re-formatted a little bit.

Gavino

2nd June 2020, 09:28

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip=AverageLuma"+Chr(10)
\ +"("+string(Blendover)+"<=0||"+string(Blendover)+">Skip)?M:"
\ +"("+string(SkipOver) +"<=0||"+string(SkipOver) +">Skip)?B:BHard",
\ args="EMskip,M,B,BHard",Local=true)

EMskip isn't used in your script.
Shouldn't it be M = EMskip.GScriptClip(...) ???

But also, with GRunT, it is simpler to use 'args' instead of string concatenation to get local variables into the run-time script. So I would replace it all by
M = EMskip.GScriptClip("
Skip=AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver)<=0 || SkipOver>Skip)? B : BHard",
\ args="Blendover,SkipOver,M,B,BHard",Local=true)

StainlessS

2nd June 2020, 14:20

Yep, that does look an awful lot better G.
The M = M.... was tacked on at the end, and I could not actually test without finding a bunch of dependencies
so I just did a botch up of pretend clips. [just to test not crash]
As far as the Grunt Args=Args thing instead of string concatenation is concerned, I'm gonna pass blame for that onto MysteryX :)

manolito

2nd June 2020, 14:37

This really is a tough one... :devil:

Shouldn't it be M = EMskip.GScriptClip(...) ???
No, it produces garbage.

The streamlined Gavino version also produces exactly the same garbage.

But I could get the StainlessS version working with just 1 difference:
M = M.GScriptClip("Skip=EMskip.AverageLuma"+Chr(10)
\ +"("+string(Blendover)+"<=0||"+string(Blendover)+">Skip)?M:"
\ +"("+string(SkipOver) +"<=0||"+string(SkipOver) +">Skip)?B:BHard",
\ args="EMskip,M,B,BHard",Local=true)
The difference is the placement of EMskip. Works under classic AVS 2.61 and under AVS+ 6.1 test version 2.
Does this look right?

StainlessS

2nd June 2020, 15:15

bug in Gavino edition, remove extra closing parenthesis around 1st SkipOver.

M = EMskip.GScriptClip("
Skip=AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver)<=0 || SkipOver>Skip)? B : BHard",
\ args="Blendover,SkipOver,M,B,BHard",Local=true)

I dont know why it dont work without using EmSkip.AverageLuma, inside the Scriptclip script, Last is EmSkip.

Gavino fixed (we hope)

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = EMskip.GScriptClip("
Skip=EmSkip.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)

EDIT: Just for the hell of it try [if works, remove in red]

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = EMskip.GScriptClip("
Skip=Last.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)

Gavino

2nd June 2020, 15:53

bug in Gavino edition, remove extra closing parenthesis around 1st SkipOver.
Thanks - Good catch! It was left over when I removed all the string() stuff.
I dont know why it dont work without using EmSkip.AverageLuma, inside the Scriptclip script, Last is EmSkip.
Yup, the two versions should act the same.

pinterf

2nd June 2020, 16:09

Thanks - Good catch! It was left over when I removed all the string() stuff.

Yup, the two versions should act the same.
Even if "local=true"?
EDIT: yes of course. Last is set by ScriptClip by the child clip. But what is not working exactly?

manolito

2nd June 2020, 19:58

M = EMskip.GScriptClip("
Skip=AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip)? B : BHard",
\ args="Blendover,SkipOver,M,B,BHard",Local=true)
This one results in some black and white garbage which looks like a mask (instead of a sexy nude).

M = EMskip.GScriptClip("
Skip=EmSkip.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)
Same result for this version.

M = EMskip.GScriptClip("
Skip=Last.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)
And again the same output.

M = EMskip.GScriptClip("
Skip=Last.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="Blendover,SkipOver,M,B,BHard",Local=true)
And also the identical output

BUT:
M = M.GScriptClip("
Skip=EmSkip.AverageLuma
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)
This one DOES work. Any explanation? And are SkipOver and Blendover really applied? What made the difference was removing "EMskip" in the first line and replacing it with "M". The same goes for the other StainlessS versions of Gavino's script.

Any thoughts on this regression?
I do not use MP_Pipeline, but I can reproduce the HDRAGC crashes under 3.61 test version 4.
BUT:
It works well under test version 2. Must be some regression in test version 4.

StainlessS

2nd June 2020, 21:02

I cant make any sense out of Manolito results, they be crazy.

Test just to see which clip AverageLuma is taken from

M = BlankClip(Pixel_type="YV12",Color_YUV=$208080) # $20
EMSkip = BlankClip(Pixel_type="YV12",Color_YUV=$308080) # $30
B = BlankClip(Pixel_type="YV12",Color_YUV=$408080) # $40
BHard = BlankClip(Pixel_type="YV12",Color_YUV=$508080) # $50

BlendOver = 1.0
SkipOver = 2.0

Global G_Format="%d] EMSkip=%X Last=%X Last2=%X M=%X B=%X BHard=%X"

# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("
Skip=EmSkip.AverageLuma
LastSkip=Last.AverageLuma
Last2Skip=AverageLuma
MSkip=M.AverageLuma
BSkip=B.AverageLuma
BHardSkip=BHard.AverageLuma
RT_DebugF(G_Format,current_frame,Skip.Int,LastSkip.Int,Last2Skip.Int,MSkip.Int,BSkip.Int,BHardSkip.Int)
(Blendover<=0 || Blendover>Skip)? M : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,M,B,BHard",Local=true)

M

Results on avs+ 3.5 r3106

M = M.GScriptClip
RT_DebugF: 0] EMSkip=30 Last=20 Last2=20 M=20 B=40 BHard=50

M = EMSkip.GScriptClip
RT_DebugF: 0] EMSkip=30 Last=30 Last2=30 M=20 B=40 BHard=50

Both look ok to me

EDIT:
This is same as original Manolito script but String() stuff removed and args used instead, however is NOT same logic as in ConditionalFilter() calls

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
(SkipOver>0 && Skip>=SkipOver) ? BHard : (BlendOver>0 && Skip>=BlendOver) ? B : M",
\ args = "EMskip,Blendover,SkipOver,M,B,BHard", Local=true)

EDIT:
But what is not working exactly

Well, If we knew that, we'd all be cleverer than you :) [and whats the chances of that]

manolito

2nd June 2020, 22:57

Well, I do not pretend to understand all this AVS runtime stuff, but I do make tests and I can interprete the results.

And my test results do make a lot of sense to me. If you have "M = EMskip.GScriptClip" then you assign a mask (EMskip is not a valid video clip, it is just a mask). And whatever you do with this mask with all the GScriptClip calls, the end result will still be a mask instead of a video clip.

Using "M = M.GScriptClip" instead will apply the GScript calls to the real masked video clip M instead to just a mask. And "M" is returned as the result of MX_FPS (unless you specify otherwise).

Whatever, I tested it using a short 1 minute clip using all the different methods which came up so far, and the resulting clips were all bit identical. Speed was also the same. Of course I know that a 1 minute clip does not mean much, it could be that the thresholds for SkipOver and BlendOver were not reached, but basically it seems that all the different methods are valid.

Gavino

2nd June 2020, 23:20

EMskip is not a valid video clip, it is just a mask
Ah, does it have different properties (dimensions or colorspace) from M and the other clips?

I was assuming all the clips were similar in these respects (and StainlessS's test assumed that too). Since the clip properties of the result of ScriptClip are taken from its input, that could be the difference.

StainlessS

3rd June 2020, 00:32

Was tryin' to find "ConvertFpsLimit" dependency, and found that I did compile of non SSE2 ie C + MMX/iSSE for Mani, dont recall doing that at all :( [memories, like the corners of my mind ...]
C + MMX/iSSE version here:- https://forum.doom9.org/showthread.php?p=1876121#post1876121

OK, I've got full script working now.

Mani's/MysteryX original Scriptclip version but removed string() stuff using args, and also removed Scriptclip internal M (using Last instead)
NOTE, this is still the version that is logically different to the commented out conditionalfilter stuff.

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("Skip = EMskip.AverageLuma()
(SkipOver>0 && Skip>=SkipOver) ? BHard : (BlendOver>0 && Skip>=BlendOver) ? B : Last",
\ args = "EMskip,Blendover,SkipOver,B,BHard", Local=true)

Same but with same logic as conditionalfilter stuff

## Apply BlendOver and SkipOver
# M2 = SkipOver > 0 ? ConditionalFilter(EMskip, B, BHard, "AverageLuma", "<", string(SkipOver)) : B
# M = BlendOver > 0 ? ConditionalFilter(EMskip, M, M2, "AverageLuma", "<", string(BlendOver)) : M
M = M.GScriptClip("
Skip=EmSkip.AverageLuma
(Blendover<=0 || Blendover>Skip)? Last : (SkipOver<=0 || SkipOver>Skip) ? B : BHard",
\ args="EMskip,Blendover,SkipOver,B,BHard",Local=true)

Both work but dont know which is best (presume the conditionalFilter logic one)
Previoulsy 'M' now Last marked in blue.

EDIT:
@ Gavino,
EmSkip is (for JohnMeyer Parade clip) 32x24 pixels, so is a lot smaller than others.

Is derived from Mvtools SAD and Occlusion Masks and

# Create skip mask
EMskip = EM.BicubicResize(Round(C.Width/BlkSize/4.0)*4, Round(C.Height/BlkSizeV/4.0)*4)
\ .mt_expand(mode= mt_circle(zero=true, radius=1))
\ .mt_binarize(SkipTrh)

manolito

3rd June 2020, 01:23

Both work but dont know which is best (presume the conditionalFilter logic one)

MysteryX abandoned the GScriptClip stuff in favor of the ConditionalFilter logic some time ago, so you are probably right to assume that the ConditionalFilter logic works better.

But MysteryX used his own ConditionalFilterMT function because he determined that the internal ConditionalFilter function was not compatible with multithreading. And unfortunately this ConditionalFilterMT function does not work on my old PC because it requires SSE2.

So here my question again: (to pinterf)
Is it still true for current versions of AVS+ that ConditionalFilter is not compatible with multithreading?
Because if this is no longer true then I can easily ditch all this GScriptClip stuff and use ConditionalFilter instead. Would make my life much easier...

StainlessS

3rd June 2020, 01:28

Mani, Point out for Pinterf, where it was that MX said that [might be some clues as to reason].

manolito

3rd June 2020, 01:48

I think I posted it before, but cannot find it right now...

https://github.com/mysteryx93/FrameRateConverter

ConditionalFilterMT

Avisynth+ MT provides great capabilities to process videos. However, conditional functions are not compatible with MT (multi-threading) due to design limitations. To work around this problem, this class provides a subset of conditional features that will work with MT mode.

pinterf

3rd June 2020, 07:12

But MysteryX used his own ConditionalFilterMT function because he determined that the internal ConditionalFilter function was not compatible with multithreading. And unfortunately this ConditionalFilterMT function does not work on my old PC because it requires SSE2.

So here my question again: (to pinterf)
Is it still true for current versions of AVS+ that ConditionalFilter is not compatible with multithreading?

The multithreading issues with runtime filter family (ConditionalFilter and ScriptClip) have been fixed.

Gavino

3rd June 2020, 08:37

@ Gavino,
EmSkip is (for JohnMeyer Parade clip) 32x24 pixels, so is a lot smaller than others.
Thanks.
That explains why using EmSkip.GscriptClip() didn't work, as the result will also be 32x24.

vcmohan

3rd June 2020, 14:11

both, fftw3.dll were used to be old one that come with FFT3DFilter, the default name for new one one is libfftw3f-3.dll

Today I checked my source code and found that I have been checking first libfft3f-3.dll and then others. So that does not require change.

pinterf

3rd June 2020, 15:58

(MP pipeline and other things are being solved)

pinterf

3rd June 2020, 17:58

Groucho2004

3rd June 2020, 18:04

pinterf

3rd June 2020, 18:07

No, I can't sleep well if I know that there are unfinished stuff. And I want to close this giant modification wave as soon as possible.

Groucho2004

3rd June 2020, 18:27

No, I can't sleep well if I know that there are unfinished stuff.I know the feeling. It can be unhealthy though.

FranceBB

3rd June 2020, 20:41

Dear all, download
Avisynth+ v3.6.1 test build 5 (20200603) (https://drive.google.com/file/d/1BDHHCj_HD4fogQ4zKm5C6eQPzrm2zNJj/view?usp=sharing)
Addressing mp_pipeline and further CPP 2.5 compatibility fixes (GRunT CPP 2.5 runtime filters, AverageLuma, etc.)
New: Histogram("Levels"): add greyscale support

Well I'm really sorry to say this 'cause you need some rest, but... it doesn't work. It starts allocating RAM and it creates the processes, however instead of showing the result, it outputs this error:

MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV24")

### ###

""")

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

MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

### platform: win32
### ###

""")

Same error.

MP_Pipeline("""
DirectShowSource("I:\Production\431.avi")

### platform: win32
### ###

""")

Same error.
(DSS 'cause I'm too lazy to wait ffms2 to index a test file).

I also tried it with a real script and it didn't work.

As to the Histogram() thing, well done updating it. I wonder if Histogram("color2") will get high bit depth in the future since it's currently limited to 8bit only. :)
No pressure at all, anyway. Take your time and have proper rest, you deserve it. :)

pinterf

3rd June 2020, 21:06

And with a return last?
edit: before the last """ line

manolito

3rd June 2020, 21:46

Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP. Test version 2 has no problems with HDRAGC.

FranceBB

3rd June 2020, 23:34

And with a return last?
edit: before the last """ line

Return last did solve the problem.
I even tried it with a real-world script and it worked just fine allocating its 4.3 GB of RAM and delivering the correct output:

MP_Pipeline("""
video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\424-430\opening_ending_textless T80 2_0ch 224Kbps DELAY 0ms.ac3")
AudioDub(video1, audio1)

opening=trim(0, 2715).ConvertFPS(23.976)

ending=trim(5436, 8175).ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

video2=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421.d2v")
audio2=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421 T81 2_0ch 224Kbps DELAY -115ms.ac3")
AudioDub(video2, audio2)

### export clip: opening, ending
### platform: win32

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3))
tdecimate()
ConvertFPS(23.976)

### export clip: opening, ending
### platform: win32

opening++trim(2279, 6400)++trim(8799, 32938)++ending

### ###

Dither_convert_8_to_16()

### ###

nnedi3_resize16(target_width=1920, target_height=1080, 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)

### ###

dfttest(sigma=64, tbsize=1, lsb_in=true, lsb=true, Y=true, U=true, V=true, opt=0, dither=0)

### ###

ConvertFromStacked()

### ###

aWarpSharp2(thresh=180, blur=3, type=0, depth=35, depthC=10, chroma=4)

### ###

ConvertBits(bits=8, dither=1)

### ###

FastLineDarkenmod(strength=128)

### ###

f3kdb(range=15, Y=45, Cb=30, Cr=30, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false,
opt=3, mt=true, keep_tv_range=true, input_depth=8, output_mode=1, output_depth=16)

### ###

nnedi3_resize16(target_width=3840, target_height=2160, 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)

### ###

ConvertFromStacked()

### ###

Tweak(sat=1.51, dither=true)

### ###

ConvertToStacked()

### ###

s16 = last
DitherPost (mode=-1)

TextSub("\\VBOXSVR\Share_Windows_Linux\Production\Subs\Ep 421.ass")

Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

### ###

ConvertFromStacked()

ConvertYUVtoXYZ()

ConvertXYZtoYUV(Color=1, pColor=2)

return last

""")

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

(you can't see some of the processes in the screenshot, though, but it works).

Results for 3.6.1 test 5: (only testing the x86 version)

HDRAGC still crashing with an access violation. This is under Win7-64 as well as under WinXP.

I can reproduce that.

DirectShowSource("I:\Production\431.avi")

HDRAGC()

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

pinterf

4th June 2020, 08:45

Thanks, (and I found a buffer overflow for YUVA transfer in MP_Pipeline, but since this format is not much used yet, the priority for the fixed release is low).

pinterf

4th June 2020, 15:39

gispos

4th June 2020, 18:50

Daily test build 3.6.1-test6 (https://drive.google.com/file/d/1maXp53tQ2Vc-b91QyL8UpEYQd0a-OLY2/view?usp=sharing)
Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition
Yes, MP_Pipeline is running, but

dear pinterf, is that all because of the arrays?

I can only imagine a few things I could do with arrays (I'm just an average user).

But I don't want to exchange the loss of some plugins for it. I think I'm not the only one with this thought.
Did you really take the right path? In any case you have my sympathy.

Gavino

4th June 2020, 19:00

"return last" is not needed when script ends with a function definition
This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }

StainlessS

4th June 2020, 19:51

(or is this a bug-fix for something that crept in recently?)

Return Last requirement in mt_pipeline arose quite recently:- https://forum.doom9.org/showthread.php?p=1906156#post1906156

EDIT: Hmm, you cant quote from a previously Closed thread [eg old Avs+ thread]

By GisPos
MPP requires a 'return last' in the last section for NEO builds.
I take it MPP means mt_Pipeline. [EDIT: I mean MP_Pipeline]

gispos

4th June 2020, 19:52

Yes that related to MP_Pipeline.
I don't need a return last for this test version.
I didn't think that was bad either, you just had to know.

FranceBB

4th June 2020, 20:05

Daily test build 3.6.1-test6 (https://drive.google.com/file/d/1maXp53tQ2Vc-b91QyL8UpEYQd0a-OLY2/view?usp=sharing)
Further v2.5 things (HDRAGC issue)
"return last" is not needed when script ends with a function definition

HDRAGC() now works fine:

#crappy simple test

video1=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 1080i.d2v")
audio1=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Kyou kara Ore wa!! EP02 T80 2_0ch 224Kbps DELAY 0ms.ac3")
Spline64Resize(704, 396)
sdr=last
hdr=HDRAGC()

StackVertical(sdr, hdr)

#for those script nazi (does such a word exist? like grammar nazi but for Avisynth scripts?)
# that lurked at the name of first file I found and indexed to make this simple stupid test
#and really wanna know why it's saying 1080i but I resized it without deinterlacing,
#the reason is that it's just 29.970 progressive flagged as interlaced

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

And I tried MPPipeline with the very same script I tried before but without the return last and it works without it now! :D
Very well done, Ferenc, just in time for the weekend.
You really deserve to rest now. :)

manolito

4th June 2020, 20:09

This latest 3.6.1-test 6 version looks like a winner to me... :D

HDRAGC now works under Win7-64 as well as under WinXP. Under XP I also tested it using all my old (and very very old) CPP 2.5 plugins, and all of them did not cause any problems.

MT stability is also very good. Right now I am running an encode on the WinXP machine (which has a single core CPU) with Prefetch(2), and it is slightly faster than without MT, and it is also stable. Kudos to pinterf...

FranceBB

4th June 2020, 20:45

Actually I gotta say that I found yet another thing... (sorry).
MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...

MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

ConvertBits(16)

### ###

ConvertYUVtoXYZ()

### ###

ConvertXYZtoYUV(Color=1, pColor=2)

""")

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

It's supposed to be showing color bars in BT2020 SDR YUV but it clearly isn't...
Of course if I make the conversion inside the very same block it works, but since you were asking about MPPipeline issues... well... this is one.
Of course, XYZ isn't officially supported by Avisynth as color space, so I don't know what Jean Philippe made inside his plugin to display it in Avisynth and work inside such a wide colorspace...
Anyway, this is one of the reasons why on the 25 of June 2018 I said that it would be nice in the future to have XYZ support inside Avisynth and perhaps one day it will happen... :')

StainlessS

4th June 2020, 20:55

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }

No prob in v3.6.1 test6

EDIT:
You mean 3.6.1 test6, right?
Fixed

manolito

4th June 2020, 21:26

No prob in v2.6.1 test6

You mean 3.6.1 test6, right?

manolito

4th June 2020, 23:53

MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...

Does this work under AVS+ 3.5.1?

Because if it does then pinterf has some more work to do, but if it doesn't then I think a more radical approach would be needed.

ravewulf

5th June 2020, 00:12

PremiereAVSPlugin v1.95 (https://sourceforge.net/projects/videoeditorskit/files/PremiereAVSPlugin/1.95/) causes Premiere CS3 to crash with both 3.6.0 and 3.6.1 test6 while it was working with previous versions of AviSynth+. I'm not too skilled in C/C++ (web development is more my forte) but was able to compile a debug version of PremiereAVSPlugin to find where the crash was within the plugin. Note that compiling requires premiere_pro_cs3_r1_sdk_win.exe or similar and the project on SourceForge needed to be modified to include some existing header/cpp files that weren't loaded by default.

GetInfo.cpp Line 299

res = fi->scriptEnvironment->Invoke("Import", AVSValue(&arg, 1));

Exception thrown at 0x26E1938C (AviSynth.dll) in Adobe Premiere Pro.exe: 0xC0000005: Access violation reading location 0xC7FBC448

I'm guessing it could use updating to new interfaces but the project seems to be abandoned given it was last updated in 2009 and I'm not sure how to fix it myself. Probably a low priority issue as I can work around it by skipping the Premiere plugin and either using MakeAVIS to create a "fake" avi for Premiere to load or else rendering out an actual avi file. More of a "nice to have" if it can be fixed

pinterf

5th June 2020, 10:22

[[/code]
I'm guessing it could use updating to new interfaces but the project seems to be abandoned given it was last updated in 2009 and I'm not sure how to fix it myself. Probably a low priority issue as I can work around it by skipping the Premiere plugin and either using MakeAVIS to create a "fake" avi for Premiere to load or else rendering out an actual avi file. More of a "nice to have" if it can be fixed
I have placed you two links at the first post (https://forum.doom9.org/showthread.php?t=181351) in this thread.
I'm curious so
- first: please try your _existing_ plugin with the test7 avisynth.dll (only 32 bit version provided)
- second: try the _updated_ plugin (Avisynth version can remain)
Let me know your results after both cases.

pinterf

5th June 2020, 10:25

This has always been so, at least in 'classic' Avisynth.
(or is this a bug-fix for something that crept in recently?)

Simple test:
Version()
function f() { return 0 }
That was a recent one.
It was a regression (appearing in 3.6) after incorporating Neo-fork updates.

pinterf

5th June 2020, 10:35

Actually I gotta say that I found yet another thing... (sorry).
MPPipeline works, but if you go to XYZ and then come back to YUV it doesn't work...

MP_Pipeline("""
ColorBars(848, 480, pixel_type="YV12")

ConvertBits(16)

### ###

ConvertYUVtoXYZ()

### ###

ConvertXYZtoYUV(Color=1, pColor=2)

""")

Well, the output of ConvertYUVtoXYZ() is using RGB64 and not planar RGB, probably we could eliminate the use of 'packed' formats and prefer planar RGB instead.

And why you saw such blackness: because I prepared MP_Pipeline high bit depth for planar colorspaces only and forgot about RGB48 and RGB64. Until then use a ConvertToPlanarRGB(A) after the YUV-XYZ conversion.
edit: Check MP_Pipeline 0.21 (https://github.com/pinterf/MP_Pipeline/releases/tag/0.21)

Reel.Deel

5th June 2020, 18:44

PremiereAVSPlugin v1.95 (https://sourceforge.net/projects/videoeditorskit/files/PremiereAVSPlugin/1.95/) causes Premiere CS3 to crash with both 3.6.0 and 3.6.1 test6 while it was working with previous versions of AviSynth+.

This wont fix your problem but there is another variant of this plugin that supported CS3 and CS4, also released in 2009. I wonder if they have the same problem. I don't have any Adobe products so I can't test it myself.

csavs: Premiere CS AVS Importer for CS3 and CS4

https://web.archive.org/web/20180320124503/http://valion.net/csavs/

Later on there was an update to that plugin to support CS5 and 64-bit.

csavs64: Premiere CS AVS Importer x64 1.1 (pre CS5 plugins will not work)

setup: https://web.archive.org/web/20150324225527/http://pwolfamv.com/programs/csavs64/
source: http://pwolfamv.com/programs/csavs64/

kedautinh12

5th June 2020, 23:45

Pinterf was released PremiereAvsPlugin 1.96 for Avisynth+ and Avisynth 2.6 interface.
https://github.com/pinterf/PremiereAVSPlugin/releases

kedautinh12

5th June 2020, 23:46

Also updated MP_Pipeline
https://github.com/pinterf/MP_Pipeline

ravewulf

6th June 2020, 00:44

I have placed you two links at the first post (https://forum.doom9.org/showthread.php?t=181351) in this thread.
I'm curious so
- first: please try your _existing_ plugin with the test7 avisynth.dll (only 32 bit version provided)
- second: try the _updated_ plugin (Avisynth version can remain)
Let me know your results after both cases.

Not sure if this is expected but AvsPmod Version 2.6.2.5 gives an ignorable error with test7
Exception WindowsError: 'exception: access violation reading 0x9DE18AFD' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x03857690>> ignored

The results of the first test were a bit surprising. Using the test7 build with the existing Premiere plugin works if the script is video-only. But if the script has video and audio (or audio alone) it causes Premiere to crash. Tested with both external audio files and the built-in ColorBars function.

The new updated Premiere plugin works perfectly with video and audio for both 3.6.0 and 3.6.1 test7.

Let me know if you want me to test the old Premiere plugin with future test updates to see if the audio issue can be fixed as a test case for similar plugins. Otherwise, I'll just use the new version of the plugin you built. Thank you! :thanks:

This wont fix your problem but there is another variant of this plugin that supported CS3 and CS4, also released in 2009. I wonder if they have the same problem. I don't have any Adobe products so I can't test it myself.

csavs: Premiere CS AVS Importer for CS3 and CS4

https://web.archive.org/web/20180320124503/http://valion.net/csavs/

Later on there was an update to that plugin to support CS5 and 64-bit.

csavs64: Premiere CS AVS Importer x64 1.1 (pre CS5 plugins will not work)

setup: https://web.archive.org/web/20150324225527/http://pwolfamv.com/programs/csavs64/
source: http://pwolfamv.com/programs/csavs64/

Looks like the 32-bit version of this plugin has similar results to the first test where it crashes with 3.6.0, crashes with video+audio in 3.6.1 test7, and works for video-only clips in 3.6.1 test7.

I don't have the newer 64-bit versions of Premiere to test the 64-bit plugin though. I use CS3 to have audio playback and a zoom-able timeline while I work on cuts/timing issues then go back to 64-bit AviSynth/AvsPmod for everything else after exporting an EDL file. No need to sink a ton of money in subscription fees to Adobe for new features/encoding support I don't use ;)

MeteorRain

6th June 2020, 07:39

https://github.com/HomeOfAviSynthPlusEvolution/neo_f3kdb/issues/4

Seems like 3.6 added some enums from VapourSynth and thus directly conflicts with VapourSynth headers. Any good ways we can get around with it and include both headers in one file?

feisty2

6th June 2020, 13:06

Selur

6th June 2020, 14:37

I can confirm that HDRAGC works fine with Avisynth_3.6.1_20200604_test6. :)
And SmoothCurve also works now.
Thanks! Now I can switch to 3.6.x :)

pinterf

6th June 2020, 16:01

:stupid:you need "enum class"
https://godbolt.org/z/dKLqkB
Yes, I was planning that. But I'll guard it with ifdefs. You know it requires C++11.

StainlessS

6th June 2020, 16:11

You know it requires C++11.
Feisty, cares not a jot for compatibility.

feisty2

6th June 2020, 16:33

:stupid:
Yes, I was planning that. But I'll guard it with ifdefs. You know it requires C++11.

ancient compilers that do not even support c++11 up until this day should just die.

feisty2

6th June 2020, 16:45

besides there're many workarounds other than enums
you may use a namespace

namespace PropTypes {
constexpr auto ptUnset = 'u';
constexpr auto ptNode = 'n';
...
}

auto x = PropTypes::ptNode;

you may also place these constants in a struct as static variables

struct PropTypes final {
static constexpr auto ptUnset = 'u';
static constexpr auto ptNode = 'n';
...
};

auto x = PropTypes::ptNode;

gispos

6th June 2020, 19:58

Not sure if this is expected but AvsPmod Version 2.6.2.5 gives an ignorable error with test7
Exception WindowsError: 'exception: access violation reading 0x9DE18AFD' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x03857690>> ignored

Who wants to play with the avisynth test 7 version and AvsPmod.
This eliminates the window error message on startup.

Exchange the included library.zip with the one in the lib folder. 32bit only.

Removed. The problem is deeper

Edit: test7 seems to have a problem releasing the IScriptEnvironment

stax76

6th June 2020, 20:08

Seems like 3.6 added some enums from VapourSynth and thus directly conflicts with VapourSynth headers. Any good ways we can get around with it and include both headers in one file?

I just disabled these new definitions using comments, it's easy and for now works for me, I hope it doesn't become an issue in the future.

MeteorRain

7th June 2020, 00:06

The issue with the conflicts, for now, is that filters will include headers from system directories (/usr/include or whatever), so I can't touch that for now, unless I choose to ignore that and always use an old version of headers that I carry.

I think maybe I should just wait until the issue is resolved.

tormento

7th June 2020, 08:22

Out of curiosity: why do you keep devil.dll in a "system" directory, separate from avisynth.dll? They will go in the same windows directory, at the end.

stax76

7th June 2020, 09:54

Out of curiosity: why do you keep devil.dll in a "system" directory, separate from avisynth.dll? They will go in the same windows directory, at the end.

I wondered about that too.

pinterf

7th June 2020, 10:55

Who wants to play with the avisynth test 7 version and AvsPmod.
This eliminates the window error message on startup.

Exchange the included library.zip with the one in the lib folder. 32bit only.

Removed. The problem is deeper

Edit: test7 seems to have a problem releasing the IScriptEnvironment
For some reason AvsPMod requests ScriptEnvironment with version=3 (avs 2.5), this test7 version takes it seriously and provides you a 2.5 compatible avs_script_environment, which has _no_ avs_delete_scriptenvironment. So using a non-existant interface function will crash.

Groucho2004

7th June 2020, 11:23

this test7 version takes it seriously and provides you a 2.5 compatible avs_script_environment, which has _no_ avs_delete_scriptenvironment. So using a non-existant interface function will crash.There may be a safer method to release the IScriptEnvironment (https://forum.doom9.org/showthread.php?p=1631151#post1631151) (unless already implemented in AVSPmod) which is much better than the horrible "delete env".

pinterf

7th June 2020, 11:29

There may be a safer method to release the IScriptEnvironment (https://forum.doom9.org/showthread.php?p=1631151#post1631151) (unless already implemented in AVSPmod) which is much better than the horrible "delete env".
AVSPMod is using C interface, anyway this test7 was really a try-what-happens test for the premiere-plugin issue which accidentally shed light on this version=3 request inconsistency.

pinterf

7th June 2020, 11:46

But if the script has video and audio (or audio alone) it causes Premiere to crash. Tested with both external audio files and the built-in ColorBars function.

Thanks, the changes for the this test7 incorporated only video and I now found where your audio crashed.

Groucho2004

7th June 2020, 12:22

AVSPMod is using C interfaceAh, I see.

vcmohan

7th June 2020, 12:46

I am modifying a plugin to execute under avsynth+ 3.5 version using the avisynth.h header version 8-h. I was able to run many scripts under avisynth.dll 2xxx build. I installed x64 version of the dll using Groucho's universal installer. Now I always get an error message AVi import filter error ( unknown 80040154 ) with vdub. Even a simple script version() without trying to load any plugins gives this error. Should I go to 3.6 dll? What might have gone wrong on my system?

pinterf

7th June 2020, 13:11

The universal installer does not install the necessary redistributables, probably you need to install az up to date version?

vcmohan

7th June 2020, 13:20

The universal installer does not install the necessary redistributables, probably you need to install az up to date version?
Thanks. If you think I am not bothering you, can you name which distributables I need and the link for getting them. I am compiling with my 2013 vc++.
I have one more problem. Can I set MT mode from inside plugin as if an older version (pre 8) is detected, I disable multi thread but for later keep multi thread?

pinterf

7th June 2020, 13:31

Groucho2004

7th June 2020, 13:33

Thanks. If you think I am not bothering you, can you name which distributables I need and the link for getting them. I am compiling with my 2013 vc++.I highly recommend the All-In-One installer from here (https://github.com/abbodi1406/vcredist/releases) which covers everything from 2003 - 2019. It's frequently updated and does not install any crap such as useless installer duplicates.

pinterf

7th June 2020, 13:34

Thanks. If you think I am not bothering you, can you name which distributables I need and the link for getting them. I am compiling with my 2013 vc++.

https://visualstudio.microsoft.com/downloads/
Other Tools and Frameworks
Microsoft Visual C++ Redistributable for Visual Studio 2019

But you don't have to link for them, just use the platform toolset which your VS2013 provides.
These 2019 redistributables are needed to run Avisynth+. Independently from your plugin.

vcmohan

7th June 2020, 14:42

https://visualstudio.microsoft.com/downloads/
Other Tools and Frameworks
Microsoft Visual C++ Redistributable for Visual Studio 2019

But you don't have to link for them, just use the platform toolset which your VS2013 provides.
These 2019 redistributables are needed to run Avisynth+. Independently from your plugin.

Many thanks. It worked. I down loaded for x64 . Do I need to install X86 version also? I have requested in my previous post regarding disabling or enabling MT from within plugin. Can you clear my doubts? I can code it, but need to communicate to Avisynth by setting a flag?
Thanks again for help.

pinterf

7th June 2020, 14:55

pinterf

7th June 2020, 14:58

Many thanks. It worked. I down loaded for x64 . Do I need to install X86 version also?

If you are using 32 bit Avisynth+ (and probably other plugins which need it) for your tests then yes.

I have requested in my previous post regarding disabling or enabling MT from within plugin. Can you clear my doubts? I can code it, but need to communicate to Avisynth by setting a flag?
Thanks again for help.
You have probably missed my answer regarding setting mt mode.

real.finder

7th June 2020, 16:13

vcmohan, you mean internal MT? or setting the avs+ MT mode for the function?

btw, it will be nice if there are way for plugin to know what prefetch threads is used so it automaticly changes it internal MT settings to avoid using many threads if prefetch is equal or more than cores numbers

StainlessS

7th June 2020, 16:25

I still have trouble downloading anything from Pinterf Google drive [using FireFox, maybe self inflicted, I use Privazer Privacy thing, which disables some cookies and stuff],
I have success using Opera browser, but usually have to click Download button on first error message, then 2nd try usually works.

https://i.postimg.cc/BP6JkMZM/Untitled-00.jpg (https://postimg.cc/BP6JkMZM)

EDIT: Regarding Privazer, I dont use it under Cinnamon Mint, but still have probs using Firefox [sometimes works, sometimes dont].

EDIT: I'm wondering if problem related to 7z compression method of "LZMA2:12m BCJ, Solid +" [shown in 7z Properties, maybe G-Drive has problem reading/checking it]

DJATOM

7th June 2020, 16:40

btw, it will be nice if there are way for plugin to know what prefetch threads is used so it automaticly changes it internal MT settings to avoid using many threads if prefetch is equal or more than cores numbers

That's kinda difficult to do with current "Prefetch" design. "The filter" usually called at the end of script, so one possible workaround to pre-parse script and search for prefetch string, then on instantiation expose it's value for plugins that called before prefetch. With current design we can only adjust threads usage at "getframe" event, not on filter instantiation.

StainlessS

7th June 2020, 16:43

Beware, I'm pretty sure that there was recently a Pinterf post saying that you can now use multiple Prefetch calls in script [avs+ Neo, 3.6.x, maybe 3.5.x].

real.finder

7th June 2020, 17:34

That's kinda difficult to do with current "Prefetch" design. "The filter" usually called at the end of script, so one possible workaround to pre-parse script and search for prefetch string, then on instantiation expose it's value for plugins that called before prefetch. With current design we can only adjust threads usage at "getframe" event, not on filter instantiation.

edit: maybe adding new function called setthreads and unlike Prefetch, it need to be called in start of script (before any External filter)

addition to that, maybe Prefetch need some updates, like adding threads=0 which mean auto (like old avs mt) and make it default

StainlessS

7th June 2020, 17:52

maybe adding new function called setthreads and unlike Prefetch, it need to be called in start of script (before any External filter)

As previously noted, can be several Prefetch() calls in script,
however, if setthreads() called prior to each Prefetch call, then
would (I think) work.

NOW_PREFETCH_THREADS=x
SetThreads(NOW_PREFETCH_THREADS)
...
Prefetch(NOW_PREFETCH_THREADS)
...
NOW_PREFETCH_THREADS=y
SetThreads(NOW_PREFETCH_THREADS)
...
Prefetch(NOW_PREFETCH_THREADS)
...
NOW_PREFETCH_THREADS=z
SetThreads(NOW_PREFETCH_THREADS)
...
Prefetch(NOW_PREFETCH_THREADS)
return last

Instead of SetThreads(), could maybe just
Global GLB_NOW_PREFETCH_THREADS=x
and test if global variable exists inside filter constructor.

EDIT:
How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.

All you can do is experimenting and share your findings

1.) You can have now multiple Prefetchers (new in 3.6)
2.) At the moment, forget "frames" parameter
3.) Try another cache mode (new in 3.6) default is 0.
- SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size
Latter can do wonders especially at really low memory environment

gispos

7th June 2020, 20:29

wonkey_monkey

7th June 2020, 21:02

I've got a bug which is driving me mental, but during my investigations I've found some behaviour I can't explain and would like to know the explanation for (just to satisfy my curiosity more than anything else, but also because it's been obfuscating my search for the other bug).

I'm using this simple plugin to follow various filter events (construction, GetFrame, etc): https://pastebin.com/szEzD7hP

Here's my script:

colorbars.trim(0,3)
avs_debug("inner")
converttoyv12
avs_debug("outer")

And here's the output (with indentation by me):

[38152] avs_debug (inner): creator
[38152] avs_debug (inner): constructor
[38152] avs_debug (outer): creator
[38152] avs_debug (outer): constructor

[38152] avs_debug (outer): GetFrame in (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (outer): GetFrame out (0)

[38152] avs_debug (outer): GetFrame in (1)
[38152] avs_debug (inner): GetFrame in (1)
[38152] avs_debug (inner): GetFrame out (1)
[38152] avs_debug (outer): GetFrame out (1)

[38152] avs_debug (outer): GetFrame in (2)
[38152] avs_debug (inner): GetFrame in (2)
[38152] avs_debug (inner): GetFrame out (2)
[38152] avs_debug (outer): GetFrame out (2)

[38152] avs_debug (outer): GetFrame in (3)
[38152] avs_debug (inner): GetFrame in (3)
[38152] avs_debug (inner): GetFrame out (3)
[38152] avs_debug (outer): GetFrame out (3)

[38152] avs_debug (outer): destructor
[38152] avs_debug (inner): destructor

What I'm trying to work out is why the "inner" GetFrame for frame 0 is being called (by converttoyv12) three times (additional two calls highlighted in red), whereas for every other frame it only gets called once.

This does not happen if you use converttoyv24 or converttoy8.

Investigation with VirtualDub2 shows that it always happens to the first frame to get read, even if that's not frame 0.

StainlessS

7th June 2020, 21:11

VD2 will call GetFrame(0) when load clip, and again if start to Play. [often produces double 0 entry for any metrics]

EDIT: Media players usually do not do this, as they start playing immediately.

wonkey_monkey

7th June 2020, 21:26

Groucho2004

7th June 2020, 21:58

I used AvsMeter and my own program to avoid that (in any case it would have triggered additional calls on the "outer" avs_debug call). The extra "inner" calls don't occur when using converttoyv24 or converttoy8.
For such purposes you should use avsr. It just creates the script environment and starts reading frames.

AVSMeter creates a script environment, reads frames for 5 seconds to determine the correct frame interval for measurements and then destroys the environment. After that, it creates a new script environment for the main processing.
If you use the switch "-o" however, it behaves pretty much the same as avsr.

Groucho2004

7th June 2020, 22:00

VD2 will call GetFrame(0) when load clip, and again if start to Play.Depending on the script and filters used, this GetFrame(0) will load a bunch of frames into the cache.

wonkey_monkey

7th June 2020, 22:12

I always use -o. I also used my own program which only reads frames when required. In any case, the calling program can only trigger the outer call, and it's the inner call which is repeated.

Plus there's the fact that this issue doesn't occur with converttoyv24 or converttoy8. Maybe it has something to do with chroma subsampling, though I can't imagine what.

StainlessS

7th June 2020, 22:43

I sometimes call GetFrame(0) in constructor to calc equivalent to GetPlaneWidthSubsampling/height (or whatever they are called), because they dont exist under v2.58 avs.

pinterf

8th June 2020, 08:55

I've got a bug which is driving me mental, but during my investigations I've found some behaviour I can't explain and would like to know the explanation for (just to satisfy my curiosity more than anything else, but also because it's been obfuscating my search for the other bug).

I'm using this simple plugin to follow various filter events (construction, GetFrame, etc): https://pastebin.com/szEzD7hP

Here's my script:

colorbars.trim(0,3)
avs_debug("inner")
converttoyv12
avs_debug("outer")

And here's the output (with indentation by me):

[38152] avs_debug (outer): GetFrame in (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (inner): GetFrame in (0)
[38152] avs_debug (inner): GetFrame out (0)
[38152] avs_debug (outer): GetFrame out (0)

What I'm trying to work out is why the "inner" GetFrame for frame 0 is being called (by converttoyv12) three times (additional two calls highlighted in red), whereas for every other frame it only gets called once.

This does not happen if you use converttoyv24 or converttoy8.

ConvertToYV12 seems to be a single filter but only from outside.
Since the origin is RGB, the following internal invokes are happening
- ConvertTo444
- Separating U and V chroma
- Invoke the appropriate resizers for U and V (subpixel accuracy if needed)
- Put together the luma and the resized U and V

Maybe the cache for the first frame is not created/ready and those internal subfilters are requesting the frame multiple times.

gispos

8th June 2020, 17:01

...but I never did like sandboxie...
Why?
I've been using it for over 10 years, I think. There are only two programs on my PC that I have spent money on. Sandboxie is one of them.
Now even the full version is free.

There is only one problem, not all programs run in sandboxie.
There are also the Sandbox from Comodo, so far all programs that I have installed worked there, but there are a number of disadvantages, only one sandbox and only in the partition in which Windows is located, mostly C: \

gispos

8th June 2020, 19:20

I use Comodo Internet Security thingy, and switch off Anti-Virus, HIPS, Auto Containment, VirusScope, for most of the
time, only have FireWall on permanent, every now and then do VirusScan.
No probs really, if so then would just restore from backups, dont need any Auto Containment, Sandbox whotsits.
I guess its just whatever 'Blows your skirts up', 'Floats your boat', 'Butters your bread', 'Smokes your kipper', or whatever.

I also only use the firewall from Comodo, everything else is off.
I also use various VM's and have backups for my most important partitions, but I could never do without a sandbox.
This is not a 'block on the leg' that is like the air to breathe. :D

I think now we have loaded the thread enough with useless stuff. Sorry. :)

gispos

8th June 2020, 20:54

real.finder

8th June 2020, 23:30

With test8 I get errors at QTGMC.

QTGMC(Preset="fast", Sharpness=1.0, InputType=0, FPSDivisor=2, ShowSettings=False)

Script error: expected `)'
((null), line 1, column 4)
(D:\Tools\AviSynth\plugins64+\QTGMC\SMDegrain.avs, line 879)
(D:\Tools\AviSynth\plugins64+\QTGMC\QTGMC.avsi, line 208)
(Datei neu, line 8)

Anyone else?

you are not UpToDate in scripts case

I did many changes months ago, all shared functions moved to Zs_RF_Shared.avsi so QTGMC no longer need SMDegrain

also there were changes in pre avs+ 3.6 that break things in AvsPlusVersionNumber which I fix weeks ago using StainlessS code since the pre avs+ 3.6 test builds

manolito

9th June 2020, 01:24

With test8 I get errors at QTGMC.
Anyone else?

Just when you thought that Microsoft was the undisputed champion of Version Hell and DLL Hell... :devil:

stax76

9th June 2020, 01:27

10 year old script (MCTemporalDenoise) depends on script depends on script... :(, wasted time to make the dependency detection work and then gave up making it work with a hack...

ravewulf

9th June 2020, 03:15

Test build 8 - work in progress
Avisynth+ v3.6.1 test build 8 (20200607) (https://drive.google.com/file/d/1a5VlaM3ZVjq9KwBk5piamswc_sV5bY_j/view?usp=sharing)

This time with GeneralConvolution fixes
And with the former fixes for XP and Cpp2.5 regressions but after a bit of a code cleanup. I hope nothing got worse.

Confirmed that the older Premiere plugin (1.95) now works without crashing. As that test case is resolved, I'll use the 1.96 version going forward.

pinterf

9th June 2020, 08:49

Confirmed that the older Premiere plugin (1.95) now works without crashing. As that test case is resolved, I'll use the 1.96 version going forward.
Thank you for the test

vcmohan

9th June 2020, 13:40

The proper way of setting mt mode is returning the relevant constant (MT_SERIALIZED, MT_MULTI_INSTANCE, MT_NICE_FILTER) by using set cache hints.
You can do it adaptively: in this example the mt mode is enabled or not depending on a parameter value got from filter creation.
https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/MVAnalyse.h#L134

Many thanks once again. This way I can disable MT in pre v8 version. But I am not too happy about it. In pre v8 version I could get memory allocated with env2. Now thats lost. So I am relying on getting a newvideoFrame. However this does not work in case of 2D FFT as both width and height of frame need a padding, plus it needs to be in float. Is there a way in pre v8 to get optional size newvideoframe? In that case I can still have multi threading in place.

ravewulf

9th June 2020, 15:36

Many thanks once again. This way I can disable MT in pre v8 version. But I am not too happy about it. In pre v8 version I could get memory allocated with env2. Now thats lost. So I am relying on getting a newvideoFrame. However this does not work in case of 2D FFT as both width and height of frame need a padding, plus it needs to be in float. Is there a way in pre v8 to get optional size newvideoframe? In that case I can still have multi threading in place.

I'm probably misunderstanding the situation, so for my own clarification - isn't internal multithreading within a plugin discouraged in favor of AviSynth handling multithreading via multiple frames being processed in parallel?

#2: Parallel execution
AviSynth-MT and VapourSynth both support multithreading, and it is being implemented in AviSynth+ too. All of them require the same things from your plugin. Here is a list of what you as a plugin author can do to support execution on multiple threads. If you are the author of any AviSynth plugin, please update your filter according to these rules if needed. Doing so will make sure your plugin can execute seamlessly when multithreaded. Furthermore, following these rules will not only guarantee correct execution in multihtreaded environments, it will also provide optimal mulithreaded performance.

Unless you have the slowest filter in the world, don't start threads in your plugin
...
In general, do not slice up your frame and start multiple threads on your own. Threading has its own performance overhead, and it is only worth doing it manually if your filter takes a lot of time to execute. And even if your filter is extremely slow (like fft3dfilter), you should try to optimize its single-threaded performance (by using SIMD instructions or choosing a more efficient algorithm) rather then manually threading it. Optimize for single-threaded performance, and as long as you follow the other rules below, you will get automatic and correct multithreading from AviSynth.
...

Excerpts from http://avisynth.nl/index.php/Avisynthplus/Developers

I'm not sure if this adds clarification or was already known?

real.finder

9th June 2020, 16:19

I'm probably misunderstanding the situation, so for my own clarification - isn't internal multithreading within a plugin discouraged in favor of AviSynth handling multithreading via multiple frames being processed in parallel?

Excerpts from http://avisynth.nl/index.php/Avisynthplus/Developers

I'm not sure if this adds clarification or was already known?

Regardless that, internal multithreading still has advantage in RAM usage, that why there should some way for plugin to know what prefetch threads is used as I said https://forum.doom9.org/showthread.php?p=1914966#post1914966

and also here https://forum.doom9.org/showthread.php?p=1907473#post1907473 and https://forum.doom9.org/showthread.php?p=1776920#post1776920

so both should be life together

anyway seems vcmohan mean setting the avs+ MT mode not plugin internal multithreading

StainlessS

9th June 2020, 16:38

optional size newvideoframe?
If you change size of vi.width / vi.height in constructor, NewVideoFrame will return new sized frame.
A Trim filter, or decimation filter where output length is known, would change vi.num_frames in constructor.
Can also change colorspace in same way but I dont know the particulars for that.
[EDIT: Must in this case get original vi from child clip to ascertain source clip properties, ie child->GetVideoInfo]
Probably also need crop off padding from result of your padded filter, within the filter creator function, and return the cropped result to caller.

From Ben's Docs [not quite the same]
A filter that changes the frame size :- http://avisynth.nl/index.php/Filter_SDK/Ben_docs#A_filter_that_changes_the_frame_size

EDIT: When you change the properties of VideoInfo in constructor, you change properties of the returned clip. [and so have to return a NewVideoFrame result,
not env->MakeWritable result, (EDIT: unless no change to frame properties eg trim filter, only frame count changed)].

EDIT:
Or I guess you could have a temp_vi in your class, and copy class vi into it, and then change that for temp NewVideoFrame, then call
PVideoFrame pad = env->NewVideoFrame(temp_vi)
and at end convert/copy/blit pad frame (excluding padding) into result NewVideoFrame (created with original vi), and would not need crop off padding in creator function.

Hope at least some of that makes sense.

pinterf

9th June 2020, 18:08

Prefetch has a default value, which is number of Physical CPUs + 1.
AVSValue Prefetcher::Create(AVSValue args, void*, IScriptEnvironment* env)
{
InternalEnvironment *envi = static_cast<InternalEnvironment*>(env);
PClip child = args[0].AsClip();

int PrefetchThreads = args[1].AsInt((int)envi->GetEnvProperty(AEP_PHYSICAL_CPUS)+1);
int PrefetchFrames = args[2].AsInt(PrefetchThreads * 2);

if (PrefetchThreads > 0 && PrefetchFrames > 0)
{
return new Prefetcher(child, PrefetchThreads, PrefetchFrames, env);
}
else
return child;
}

pinterf

9th June 2020, 18:15

ravewulf

9th June 2020, 19:27

Regardless that, internal multithreading still has advantage in RAM usage, that why there should some way for plugin to know what prefetch threads is used as I said https://forum.doom9.org/showthread.php?p=1914966#post1914966

and also here https://forum.doom9.org/showthread.php?p=1907473#post1907473 and https://forum.doom9.org/showthread.php?p=1776920#post1776920

so both should be life together

anyway seems vcmohan mean setting the avs+ MT mode not plugin internal multithreading
Thanks for the clarification!

DJATOM

9th June 2020, 19:54

internal multithreading still has advantage in RAM usage

Yet it's slower on complex scripts + encoding (judging from eedi3/nnedi3), so I think internal mt should be off by default. The only useful case with internal threading is when we preview stuff in avspmod or another host, since usually there is no need in computation of 24 frames (my case) when tweaking filter.

vcmohan

10th June 2020, 06:11

Not lost, memory pool allocation is now part of IScriptEnvironment.
VideoFrame buffers (frame pointers and pitches) are 64 byte aligned in AviSynth+. I don't know what you mean under optimal size, but as said, adjusting vi.width and vi.height (and all other VideoInfo properties) in filter creation will determine the frame size and format your next NewVideoFrame will allocate.

Thanks. but sorry I could not understand fully. My goal is to code so that in either version MT is fully maintained. I am internally using disposable buffers of size larger than input video frame. My output will still remain the same VideoFrame size. So if I change vi.width and vi.height then my output frame size changes, which I do not want to happen (as per my understanding).
Or can I code like
float * buf;
Iscriptenvironment2 * env2 = (Iscriptenvironment2 *) env;
if(v8) { buf =(float *)env->Allocate(.....);}
else{ buf = (float*)env2->Allocate(....);}

I thought this will not work as env2 is broken and this was the reason why I am modifying the code..

pinterf

10th June 2020, 08:08

Or can I code like
float * buf;
Iscriptenvironment2 * env2 = (Iscriptenvironment2 *) env;
if(v8) { buf =(float *)env->Allocate(.....);}
else{ buf = (float*)env2->Allocate(....);}

I thought this will not work as env2 is broken and this was the reason why I am modifying the code..

I see. Then do env->Allocate if V8 and use _aligned_malloc for the rest.

Like asd-g did when updated chikuzen's plugins:
https://github.com/Asd-g/TMM2/commit/d79fd18b54843d9b831e37e97c131627134cc161#diff-44bf449871c471dc8dee9a12b896c307
Look, how the old allocate was split adaptively. He is using _mm_alloc/_mm_free which allocates on (at least) 16 byte aligned memory area. If you need more strict allocation, use _aligned_alloc/aligned_free and specify your alignment requirement.

vcmohan

10th June 2020, 12:51

If _mm_alloc is available then why is env->Allocate introduced? Or as I think _mm_alloc is a system call. If so if done for each frame, it will slow down and MT may be a waste. Am I correct?

DJATOM

10th June 2020, 13:12

Selur

10th June 2020, 17:48

Does anyone have a newer Planartools build which works with Avisynth 3.6.x, tried with https://github.com/chikuzen/PlanarTools/releases/download/0.3.0/PlanarTools-0.3.0.zip but that fails. (thought all my filter worked fine and then a YUV2 interlaced source came around ;))

vcmohan

11th June 2020, 07:08

https://github.com/AviSynth/AviSynthPlus/blob/9a813c1bdfec9d35252ca489e01ea059a6323783/avs_core/core/BufferPool.cpp#L105
Looks like BufferPool::Allocate does some job to don't allocate new buffers if possible, so it should be faster if you use allocation per getframe (if buffer allocation is pooled, it will not be freed but marked as reusable, see BufferPool::Free). i didn't dig too deep, but assume it's freed at destruction or on cache adjustment.

It looks like it should work. But do I need to include BufferPool.cpp in my build. Or since it is listed under core of avs+, is there a way of calling this function? Does it work with 3.5 version?

pinterf

11th June 2020, 07:52

It looks like it should work. But do I need to include BufferPool.cpp in my build. Or since it is listed under core of avs+, is there a way of calling this function? Does it work with 3.5 version?

No. BufferPool.cpp was just linked as an example where you can see how avs+ implements it and that behind env->Alloc there is really a pool.

If you have V8 (avs+ 3.6), use env->Allocate and env->Free.
If you don't have, use aligned alloc/free or _mm_alloc/free, or alloca. Since memory pools are good at frequent alloc/free, probably they are recommended only for in-GetFrame use.

The whole (thread/memory) "pool" theory is based on that creation and free of such resources can take time. But if they are allocated already and are used on-demand and they are only going idle when not used, this is more optimal and takes less time.

Myrsloik once wrote that small allocations provided by usual tools are fast enough but larger ones (like frames) are much slower to allocate.

You can benchmark your case if env->Alloc gave you any speed or memory use benefit vs. usual C++ provided allocation methods. I'd say it's fine tuning.

pinterf

11th June 2020, 08:01

If _mm_alloc is available then why is env->Allocate introduced? Or as I think _mm_alloc is a system call. If so if done for each frame, it will slow down and MT may be a waste. Am I correct?
env->Allocate is an Avisynth+ interface method.
_mm_alloc is a SIMD-like intrinsic which is provided by your C++.
Other aligned alloc and free methods are provided by your C++ as well.
I don't know what your filters do but run benchmarks how your filter's real workload compares to the allocation time itself.

MeteorRain

11th June 2020, 11:35

Yet it's slower on complex scripts + encoding (judging from eedi3/nnedi3), so I think internal mt should be off by default. The only useful case with internal threading is when we preview stuff in avspmod or another host, since usually there is no need in computation of 24 frames (my case) when tweaking filter.

I would argue that internal MT is slow because it's not used in the most efficient way. The best way to do it would be having a globally available thread pool running somewhere, then having internal MT from multiple filters sharing the same pool, and then having a light parallel frame prefetching. (Like prefetch(4) on a 32 cores.)

Yes, a thread pool just like the multiple attempts that our friends tried, but in a more elegant way. Maybe after we have C++23 executor extension we can somehow make it easier and better.

vcmohan

11th June 2020, 12:40

env->Allocate is an Avisynth+ interface method.
_mm_alloc is a SIMD-like intrinsic which is provided by your C++.
Other aligned alloc and free methods are provided by your C++ as well.
Thanks. As I am unable to get buffers from the pool in case of pre_version 8, I am weighing the option of MT_SERIALIZING for that situation. Between MT_NICE_FILTER and MT_MULTI_INSTANCE what is the difference? Does SetCacheHints get called invariably or only in case previous filters are thread safe?
I am asking because I want to set some flags if multi threaded.

pinterf

11th June 2020, 13:03

SetCacheHints (note: name is misleading, avisynth extended an existing mechanism to ask info from filters) is always asked after filter constructor so your filter can report its behaviour depending on your actual filter parameters.
Specify "nice" when your filter can be fully reentrant, practically stateless, filter does not write class variables (there are specialized cases, guarded by mutex, but I'm speaking in general)
I still cannot see your use case, the reason why you want your filter make MT_SERIALIZED when you cannot use env->Allocate? Is it really that much time or memory penalty?

vcmohan

11th June 2020, 13:38

Then what is MT_MULTI_INSTANCE ?
In case in script the function is set as MT_SERIALIZED, even though the function internally is declared as NICE, Or one of the previous filters is MT_SERIALIZED does it still run SetCacheHints on subsequent filters? It was noted that this will be propogated downward and not upward.

pinterf

11th June 2020, 14:05

vcmohan

11th June 2020, 14:35

http://avisynth.nl/index.php/AviSynth%2B#Choosing_the_correct_MT_mode
Filters do not affect each other's mt modes.
But when a slowish filter is MT_SERIALIZED it will create a bottleneck. Imagine when you drive on an eight-lane highway but there is a single-lane exit

Thanks,. It means what we declare in the script file does not matter? And what was meant by the comment in header file 'it is popogated down but not upwards'?

I have another question. libfftwf3 dll is thread safe. However it has to be informed number of threads that will be active. How can I get this info from avisynth+ ?

pinterf

11th June 2020, 15:33

Thanks,. It means what we declare in the script file does not matter? And what was meant by the comment in header file 'it is popogated down but not upwards'?

You mean by SetFilterMTMode?
Default is MT_MULTI_INSTANCE as it is the most likely one that works by default for filters. When filters are specifying their MT modes with SetCacheHint it will be used then instead. When a filter is specifying its MT mode _and_ there is a SetFilterMTmode found, it will only be used when a last "force" bool parameter is set to true.

I have another question. libfftwf3 dll is thread safe.

Note: but plan creation is _not_ threadsafe, you have to use mutex or other guards for that.
Sample:
https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/DCTFFTW.cpp#L101

However it has to be informed number of threads that will be active. How can I get this info from avisynth+ ?
You cannot query that.
I'm not familiar with that, you have to specify the number of thread each call will spawn for each call fft3w? MeteorRain is surely an expert on this.

vcmohan

12th June 2020, 07:40

Thanks. As I understand that eventhough I might have in the script
SetFilterMTMode("F1Quiver", MT_Multi_instance)
if inside F1Quiver I have returned for SetCacheHints(....) override . MT_NICE_FILTER, the script will run as if it is a nice filter.

In fft, prior to creating plans I need to declare that internally all actions to run thread safe need to be taken, but in that number of threads are to be specified. The code I use is
SYSTEM_INFO sysinfo;
GetSystemInfo(&sysinfo);

numCPU = sysinfo.dwNumberOfProcessors;

fftwf_init_threads();

fftwf_plan_with_nthreads(numCPU * t);

This I do in the constructor and so far have not come across any problem. Usually I keep t equal to. 2 is arbitrary.
As I declared the filter as NICE, I presume it will run in 8 threads on my system with 4 processors

MeteorRain

12th June 2020, 07:49

fftw3 is thread safe but I think each execution is internal-threaded. AviSynth+ is external multi threaded.

In other words, with prefetch(4), your downstream is calling 4 GetFrame() from you at the same time in 4 different threads, and for each call, you connect to fftw3 and do some transform.
Now if you set threads=2 for fftw plans, then you will end up with 4×2=8 concurrent threads, using up to 8 CPU "core"s.

There's no reliable way to find out how many threads your downstream is calling you. You can have some way to figure out but (hint: very ugly) (https://github.com/HomeOfAviSynthPlusEvolution/neo_FFT3D/blob/master/src/fft3d_engine.h#L471).

Groucho2004

12th June 2020, 08:36

The code I use is
SYSTEM_INFO sysinfo;
GetSystemInfo(&sysinfo);

numCPU = sysinfo.dwNumberOfProcessors;

fftwf_init_threads();

fftwf_plan_with_nthreads(numCPU * t);

This I do in the constructor and so far have not come across any problem. Usually I keep t equal to. 2 is arbitrary.
As I declared the filter as NICE, I presume it will run in 8 threads on my system with 4 processorsWhat purpose does the variable "t" have? Can you elaborate?

pinterf

12th June 2020, 08:56

As there is no negative feedback on 3.6.1 test8 build, I finalize the changes.

Selur

12th June 2020, 10:32

'PlanarTools.dll' (https://github.com/chikuzen/PlanarTools/releases/download/0.3.0/PlanarTools-0.3.0.zip)
give "cannot be used as a plugin for AviSynth" with 3.6.1 test8 build

pinterf

12th June 2020, 10:50

'PlanarTools.dll' (https://github.com/chikuzen/PlanarTools/releases/download/0.3.0/PlanarTools-0.3.0.zip)
give "cannot be used as a plugin for AviSynth" with 3.6.1 test8 build
Wasn't it in the plugin set which asd-g rebuild from chikuzen's repository?
Which other plugin or script requires that? I saw that you've got an interlaced YUY2 but what if you convert it to interlaced YV16? Or we face another yv12-yuy2-only plugin?

Selur

12th June 2020, 11:18

Wasn't it in the plugin set which asd-g rebuild from chikuzen's repository?
Nope, there's no PlanarTools repostitory from https://github.com/Asd-g

I saw that you've got an interlaced YUY2 but what if you convert it to interlaced YV16? Or we face another yv12-yuy2-only plugin?
PlanarTools (http://avisynth.nl/index.php/PlanarTools) supports "RGB24, RGB32, YUY2, Y8, YV12, YV16, YV24", the problem is that the LoadPlugins fails not that PlanarTools itself crashes upon usage.

Which other plugin or script requires that?
It's used in AnimeIVTC and by proxy in QTGMC (since that nowadays uses parts of AnimeIVTC).
It's not 'required', as the script can be used without it, but it gives a speed boost for YUY2 processing.
-> I could live without it (authors of AnimeIVTC should adjust its script accordingly, but thats another issue), just wanted to let you know that it's not working, since you posted 'As there is no negative feedback on 3.6.1 test8 build'. :)

Cu Selur

pinterf

12th June 2020, 11:59

What speed boost? Planartools converts YUY2 to Planar-in-fake-YUY2 but in an unofficial (but widespread at those old times) way. Because YV16 (planar 4:2:2) was introduced only in Avisynth 2.6.
Beginning from Avisynth 2.6 the YV16 format is officially supported and preferred because it is the same as YUY2+PlanarTools but in a standard Avisynth way.
I can imagine that a really old plugin is stuck with YV12 and (planarized) YUY2, I wonder which is that plugin which does not accept native YV16.

Selur

12th June 2020, 12:00

Okay, I'll simply drop PlanarTools then. :)

real.finder

12th June 2020, 12:10

It's used in AnimeIVTC and by proxy in QTGMC (since that nowadays uses parts of AnimeIVTC).
It's not 'required', as the script can be used without it, but it gives a speed boost for YUY2 processing.
-> I could live without it (authors of AnimeIVTC should adjust its script accordingly, but thats another issue), just wanted to let you know that it's not working, since you posted 'As there is no negative feedback on 3.6.1 test8 build'. :)

it's now in Zs_RF_Shared.avsi not AnimeIVTC

What speed boost? Planartools converts YUY2 to Planar-in-fake-YUY2 but in an unofficial (but widespread at those old times) way. Because YV16 (planar 4:2:2) was introduced only in Avisynth 2.6.
Beginning from Avisynth 2.6 the YV16 format is officially supported and preferred because it is the same as YUY2+PlanarTools but in a standard Avisynth way.
I can imagine that a really old plugin is stuck with YV12 and (planarized) YUY2, I wonder which is that plugin which does not accept native YV16.

the speed boost is from YUY2 to YV16 and YV16 to YUY2, Planartools don't work with Planar-in-fake-YUY2

also there are EEDI2 still not work with yv16

pinterf

12th June 2020, 12:27

it's now in Zs_RF_Shared.avsi not AnimeIVTC

the speed boost is from YUY2 to YV16 and YV16 to YUY2, Planartools don't work with Planar-in-fake-YUY2

Sorry then I was misleading. Anyway I'm checking the speed difference. (and as such, I'll have to recompile for myself)

also there are EEDI2 still not work with yv16
Does it have any quality benefit vs. the others or it is just kept because old scripts reference to it?

real.finder

12th June 2020, 12:50

Does it have any quality benefit vs. the others or it is just kept because old scripts reference to it?

https://forum.doom9.org/showthread.php?p=1909570#post1909570

that why there are VS port of it

edit: QTGMC has both EEDI2 and EEDI3

pinterf

12th June 2020, 13:05

The fix was already done at chikuzen's repo in 2016, but there was no release then.

Speedwise I tested the 64 bit version with Avisynth+ 3.6.1 test8 (but I think it's irrelevant, the YUY2<->YV16 part is not changed for years)

Note that I had to put the to-from conversion into a 30x loop in order to do meaningful measurement. So even if this part is made double-speed, it probably won't affect the speed of any script in a measurable way.

AviSynth: 436 fps
Planartools: 310 fps (compiled out-of-the-box)

BlankClip(length=10000,pixel_type="YV16")
for (i=1, 30) {
/*
ConvertToYUY2()
ConvertToYV16()
*/
PlanarToPacked()
PackedToPlanar()
}

EDIT:
Readme says:
"This plugin is a set of filters that offerd converting packed(interleaved)
formats to planar formats and vice versa.
Avisynth2.6 has these already as internal filters, but those are a little
difficult to use, and optimization is insufficient."

kedautinh12

12th June 2020, 13:19

@pinterf can you updated eedi3 for HBD??

kedautinh12

12th June 2020, 13:20

Can anyone help me how contact to asd-g??

vcmohan

12th June 2020, 13:32

fftw3 is thread safe but I think each execution is internal-threaded. AviSynth+ is external multi threaded.

In other words, with prefetch(4), your downstream is calling 4 GetFrame() from you at the same time in 4 different threads, and for each call, you connect to fftw3 and do some transform.
Now if you set threads=2 for fftw plans, then you will end up with 4×2=8 concurrent threads, using up to 8 CPU "core"s.

Thanks for clarifying. By rereading the documentation I also realized it. Therefore it looks I shoud not try planning with number of threads and leave it to avisynth for creating threads and process.

@pinterf I remember to have seen somewhere the range of float values for chroma has been changed from 0 - 1.0 to -0.5 - 0.5. Now have I to affect this change in my plugins for 3.6 + ? What happens for pre 3.6?

pinterf

12th June 2020, 13:38

Thanks for clarifying. By rereading the documentation I also realized it. Therefore it looks I shoud not try planning with number of threads and leave it to avisynth for creating threads and process.

@pinterf I remember to have seen somewhere the range of float values for chroma has been changed from 0 - 1.0 to -0.5 - 0.5. Now have I to affect this change in my plugins for 3.6 + ? What happens for pre 3.6?
Float chroma is +/- 0.5 since years.

real.finder

12th June 2020, 13:58

btw, since there are discussion about internal multi-threading, is this https://forum.doom9.org/showthread.php?p=1777021#post1777021 forgotten? maybe plugin can see if it available then use it, if not (in case of avs 2.6 or old avs+) then it use it own mt method

edit: also here https://forum.doom9.org/showthread.php?p=1778346#post1778346

stax76

13th June 2020, 14:41

There is a compatibility issue:

https://github.com/staxrip/staxrip/issues/224

https://github.com/sorayuki/VSFilterMod

real.finder

13th June 2020, 20:14

There is a compatibility issue:

https://github.com/staxrip/staxrip/issues/224

https://github.com/sorayuki/VSFilterMod

even with https://forum.doom9.org/showthread.php?p=1914950#post1914950 ?

stax76

13th June 2020, 21:08

Sorry, not really tried it, staxrip uses 3.6.0.

edit:

I confirm that 3.6.1 test 8 fixes this issue, thank you!

StainlessS

14th June 2020, 22:15

Pinterf,
Maybe 2 bugs in VirtualDub.dll [LoadVirtualDubPlugin] :- https://forum.doom9.org/showthread.php?p=1915630#post1915630

See 1st post of that thread for vdub vdf plugins.

StainlessS

15th June 2020, 13:15

Further to above,
Current path relative as below fails with error 0x7e, needs explicit full path to work eg ""D:\VDUB\ccd_32bit.vdf""

LoadVirtualdubPlugin(".\ccd_32bit.vdf", "_VD_CCD", preroll) # Change Path to VDF : fails with error 0x7e, needs full path

It might/probably work on WXP, but not W7+ (Vista unknown).

stax76

15th June 2020, 14:19

In portable mode is it possible to set a plugin auto load folder? Couldn't find anything in the wiki.

Groucho2004

15th June 2020, 14:25

In portable mode is it possible to set a plugin auto load folder? Couldn't find anything in the wiki.
What do you mean by 'portable mode'?

Edit - Have you tried AddAutoloadDir()?

stax76

15th June 2020, 14:32

What do you mean by 'portable mode'?

Edit - Have you tried AddAutoloadDir()?

That's what I was looking for but couldn't find, thanks.

Reel.Deel

15th June 2020, 14:35

Hi pinterf,

Quick question, why does ShowY/U/V default to RGB64? Should it default to the same colorspace as the input?

ColorBars(pixel_type="YUV420P16")
ShowY()
Info()

pinterf

15th June 2020, 14:49

Hi pinterf,

Quick question, why does ShowY/U/V default to RGB64? Should it default to the same colorspace as the input?

ColorBars(pixel_type="YUV420P16")
ShowY()
Info()
Probably because original ShowRed/Green/Blue ones
http://avisynth.nl/index.php/ShowAlpha
filled a mono-color RGB32 by default.
Channel extractions for this command works like this.

Or you can use then ExtractX family.

LigH

15th June 2020, 17:06

What do you mean by 'portable mode'?

Probably just having the avisynth.dll in the application's directory, without having it installed in the system (including all registry preparations for default plugin directories)...

Something similar to MeGUI using its own copy.

Selur

15th June 2020, 17:17

btw. is there a way to tell Avisynth not to autoload stuff and just use the plugins&co explicitly loaded?

qyot27

15th June 2020, 17:25

ClearAutoloadDirs()

Selur

15th June 2020, 17:28

Cool! Thanks! :)

pinterf

15th June 2020, 17:43

Meanwhile I have cleaned up the changes up to test8 and commited to the central repo.
Then I think it's documentation time, including filter SDK. Since the online docs are much more updated than existing offline one, I don't know which one would be better to start with. Backport online versions? Much time. Do rst version only from SDK docs?

Reel.Deel

15th June 2020, 17:53

Probably because original ShowRed/Green/Blue ones
http://avisynth.nl/index.php/ShowAlpha
filled a mono-color RGB32 by default.
Channel extractions for this command works like this.

Or you can use then ExtractX family.

Alright, thanks for the clarification. I'll update the wiki. I guess for that reason is that it only accepts 8 or 16 bit input. I thought it worked more like UToY/8, where the output is always Y/YUV.

***EDIT***

Meanwhile I have cleaned up the changes up to test8 and commited to the central repo.
Then I think it's documentation time, including filter SDK. Since the online docs are much more updated than existing offline one, I don't know which one would be better to start with. Backport online versions? Much time. Do rst version only from SDK docs?

I may be able to help with that, long ago I started updating some of the offline docs. But the wiki is far ahead, although it still needs much work to be up-to-date.

Personally, I think its better to bring up-to-date the online docs, and then down the road update the offline docs.

I'm actually starting on a SetFilterMTMode wiki page ATM. I have mainly maintained the external filters section, but I think its time to dedicate some time into avs+ documentation :).

qyot27

15th June 2020, 19:11

One thing for the Wiki docs: as with the list of x64 plugins, it might also be a good idea to start tracking which plugins have been ported to other OSes and CPU architectures, in order to try and stay ahead of it.

markiemarcus

16th June 2020, 04:04

Should AvisynthShader be working in test8? Or is it one for the list to be rebuilt? With test8 I'm still getting the same system exception as mentioned on the first page.

qyot27

16th June 2020, 05:22

https://forum.doom9.org/showthread.php?p=1909884&highlight=avisynthshader#post1909884

Myrsloik

16th June 2020, 11:29

StainlessS

16th June 2020, 11:40

Kludges/signals currently supported in script
http://avisynth.nl/index.php/Internal_functions#OPT_UseWaveExtensible

EDIT:

OPT_AllowFloatAudio

global OPT_AllowFloatAudio = true ## default false
Float audio is converted to 16 bit when frameserving through ACM, unless OPT_AllowFloatAudio is set to true
(this option enables WAVE_FORMAT_IEEE_FLOAT audio output[1]). In that case the audio is kept as it is.
When accessing AviSynth directly (like MeGUI, BeHappy or ffmpeg do for example), there is no automatic conversion.

The automatic conversion is done for clients that cannot handle Float audio (in the old days most of them couldn't).
Note conversion takes place after the script processing is finished. Float audio is always allowed within the script.

OPT_UseWaveExtensible

global OPT_UseWaveExtensible = true ## default false
This option enables WAVE_FORMAT_EXTENSIBLE audio output. The default is WAVE_FORMAT_EX.
Note: The default DirectShow component for .AVS files, "AVI/WAV File Source", does not correctly implement WAVE_FORMAT_EXTENSIBLE processing,
so many application may not be able to detect the audio track. There are third party DirectShow readers that do work correctly.
Intermediate work files written using the AVIFile interface for later DirectShow processing will work correctly if they use the DirectShow "File Source (async)"
component or equivalent.

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

EDIT: What I wrote in TwriteAVI docs, musta been based on experimentation

# For Float/WaveExtensible player eg MPC-HC (Else comment out below if Player not capable)
Global OPT_UseWaveExtensible = (AudioChannels>2||AudioBits>16) # If more than 2 channels or > 16 bit, set true (Also Float, ie > 16 bits).
Global OPT_AllowFloatAudio = (IsAudioFloat) # Must be set true to play in eg Media Player Classic - Home Cinema

EDIT: In avs, can use either RT_GetProcessName() or SI_ProcessName() to find name of app using Avisynth, and switch on above signals selectively for eg MPC-HC
or other player/app.

tebasuna51

16th June 2020, 12:46

Is there any way to signal that an audio track is 20 bits in the current api? If not, will some way to do so be added?

And what's the current stance on 24 bit audio. Should it be used or simply padded to 32 bits?

Of course 24 bit int can be used without problems but some functions don't support it. See Audio processing filters (http://avisynth.nl/index.php/Internal_filters), the filters than need some process works better in float format.
The precission of 24 int is, more or less, the same than 32 float (24 bits for mantissa) then I can understand "...simply padded to 32 bits" 32 bits int is not used normally.

20 bits can't be used inside AviSynth but in WAVE_FORMAT_EXTENSIBLE (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/multichaudP.pdf) header you can use the field wValidBitsPerSample (http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html), but you can't save space because the samples must have 3 bytes (24 bits).
The most common way is put the last bits to 0 (I don't know any soft than read the field wValidBitsPerSample or use it)

stax76

16th June 2020, 19:25

I created an issue:

https://github.com/mysteryx93/AviSynthShader/issues/21

ChaosKing

16th June 2020, 19:55

@stax76 btw there is a vapoursynth plugin that supports "GLSL shaders in mpv syntax" in case you want to integrate it in staxrip https://github.com/Lypheo/vs-placebo

stax76

16th June 2020, 20:49

@stax76 btw there is a vapoursynth plugin that supports "GLSL shaders in mpv syntax" in case you want to integrate it in staxrip https://github.com/Lypheo/vs-placebo

I've bookmarked it but currently there are way to many requests for staxrip and there is also mpv.net and other plans.

markiemarcus

16th June 2020, 20:54

I've bookmarked it but currently there are way to many requests for staxrip and there is also mpv.net and other plans.

The updated TMM2 works fine by the way.

Appreciate all of your efforts. Staxrip is my go-to!

MysteryX

17th June 2020, 04:23

Wow there's been a lot going on lately!

Glad to see lots of improvements and active development to Avisynth! With the MT improvements, how does AVS' multi-threading now compares to VapourSynth?

@stax76 btw there is a vapoursynth plugin that supports "GLSL shaders in mpv syntax" in case you want to integrate it in staxrip https://github.com/Lypheo/vs-placebo
That GLSL interpreter is written in C++? Perhaps it wouldn't be a bad idea to merge it with AvisynthShader -- and have it working on both Avisynth and VapourSynth.

I've bookmarked it but currently there are way to many requests for staxrip and there is also mpv.net and other plans.
Stax76, I didn't realize MPV.NET was from you! I was planning to use that at some point; perhaps add my own mods to it.

Got the notice about updating AvisynthShader. Should be quick enough to fix.

vcmohan

17th June 2020, 07:00

What purpose does the variable "t" have? Can you elaborate?
Sorry I missed out on this. In some cases even with one cpu several threads run. So here t is the number of threads per cpu. I was keeping this as 2. Now of course I deleted this entire construct.
@pinterf. You refered me to a code where SetCacheHints is used. I find that GET_CACHE_MTMODE is one of the items in long list of CachePolicy. Does it mean that this code may be called a number of times? Or with some other item in the list? The code checks whether cachehints==CACHE_GET_MTMODE and if negative, returns a zero. Thinking about I now got doubts. Request clarification.

LigH

17th June 2020, 07:10

FranceBB

17th June 2020, 14:07

Out of curiosity, is high bit depth availability going to be implemented in Histogram("color2") ?
'cause currently we have Luma that can be high bit depth, but chroma limited to 8bit planar...

markiemarcus

18th June 2020, 19:54

(@Myrsloik - 20 bit)

Special exception: 20 bit LPCM stereo audio tracks in DVD Video use an interleaved storage format, combining the least significant "nibbles" (half-bytes) of both channels to a fifth byte. This is not compliant to PCM formats supported by most operating systems...

Just as funny side note.

Thanks for that, had absolutely no idea this was ever used in DVD-Video. I have only ever come across this format once before, about 15 years ago so I'd forgotten all about it. It was used as a storage format for an in-house instrument sample library that, although dated by today's standards, was way ahead of its time. It briefly caused some confusion because it was to be ported to a much more modern interface.

pinterf

19th June 2020, 09:06

Out of curiosity, is high bit depth availability going to be implemented in Histogram("color2") ?
'cause currently we have Luma that can be high bit depth, but chroma limited to 8bit planar...
Yes, sooner or later, I have started already but have put it aside. I guess I'd need some more hours but I cannot schedule it.

qyot27

20th June 2020, 03:49

AviSynth+ 3.6.1 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Fix: proper handling of autoload directories precedence:
PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER (highest priority)
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE (lowest priority)
Plugin (dll file name) found in a lower priority folder will not load if a similarly named plugin
already existed earlier.
fix: GeneralConvolution: incorrect parse of negative integer coefficient (added +1)
Regression since r2772.
Fix: GeneralConvolution: possible crash when chroma=true for 420 and 422 formats
Fix: ScriptClip + Runtime function object (which are new in 3.6) under heavy multithreading
New: Histogram("levels") to allow greyscale
Fix 3.6 regressions
when explicit "return last" was needed when followed by legacy function definition.
Windows XP is supported again (thread local storage workaround)
Stabilize CPP 2.5 plugins
allow forced named arrays usage again from plugins (MP_PipeLine)
Frame property related constants to match existing enum style in avisynth.h.
Plus they are not colliding now with VapourSynth's definitions.

Effectively, this is the same as the test8 build, just formalized so it shows up in the tags and release tarballs.

As part of the various builds, there is also a test build for ARM64 this time around. I'm not too sure of how widely Windows 10 on ARM devices are available, but it was easy enough to build (it does lack several of the default plugins because those are strictly for x86(-64) processors). You'll probably need to make sure you have the vcredist for ARM64.

manolito

20th June 2020, 09:22

Thanks very much for the new stable build. Just running a longer conversion under the x86 version of this build, everything looks fine... :D

Two questions:

I noticed that the files from the Test8 package are much smaller than the files in the 3.6.1 final build. I could only see that DevIL.dll is packed with UPX, all other files are not. Is pinterf using a different packer for his files (if so, which one), or is there another reason for the difference in size?

Why are there still versions for WinXP and for Win7 and above? Pinterf published his test versions only for "WinXP and above", and when I asked him if there was any disadvantage in using the XP version under a newer Windows he answered that nothing was disabled in the XP version. All CPU features would be used, and I could confirm that I did not get any speed penalty when using the x86 XP version under Win7-64.
So is there any good reason to maintain two different compiles when the XP compatible build has no drawbacks at all when used under a newer Windows version?

Thanks again
manolito

pinterf

20th June 2020, 09:51

Windows XP builds are with thread safe init compiler flag switched off. It's not healthy. Once I had problems with masktools2 because of that, a perfectly fine c++ initialization structure failed when multithreading. I had debugged it for at least three days then made a workaround. So far I did not encounter such problem with Avisynth+ or anything else but since the code is always changing let's not make problems for regular users.

qyot27

20th June 2020, 12:19

I noticed that the files from the Test8 package are much smaller than the files in the 3.6.1 final build. I could only see that DevIL.dll is packed with UPX, all other files are not. Is pinterf using a different packer for his files (if so, which one), or is there another reason for the difference in size?
Most likely it's the difference between MSVC's Release and RelWithDebInfo configurations.

Groucho2004

20th June 2020, 12:52

I noticed that the files from the Test8 package are much smaller than the files in the 3.6.1 final build. I could only see that DevIL.dll is packed with UPX, all other files are not.There are no UPX packed files in the "files_only" package. I have not tried the installer. There used to be upx compression ages ago but it would surprise me if these compression commands made it into the AVS+ setup scripts. Anyhow, UPX compression is even more outdated than XP. :D

Oh yeah, thanks qyot27 and pinterf for the new release! I'll update the Universal Installer later.

FranceBB

20th June 2020, 13:38

Yes, sooner or later, I have started already but have put it aside. I guess I'd need some more hours but I cannot schedule it.

Ok, got it. :)
Thank you for the new release, by the way.
It required a lot of testing from the community, 8 test build and probably several hours on your end, but I'm glad that everything is finally working again. :)

StainlessS

20th June 2020, 13:49

Oh yeah, thanks qyot27 and pinterf for the new release!

+1 on that, great work guys, thanx very much
https://www.cosgan.de/images/midi/froehlich/p017.gif

manolito

20th June 2020, 15:10

There are no UPX packed files in the "files_only" package.

I was talking about the pinterf test 8 build. And in this build the x86 DevIL.dll is packed with UPX. And yes, being the retro person I am, I really like UPX... :devil:

manolito

20th June 2020, 15:42

Most likely it's the difference between MSVC's Release and RelWithDebInfo configurations.

I am totally ignorant about different compilers, but if I come across two releases with identical functionality, and the files in one of these builds are half the size of the other build then I know which build I will use...

After a couple of more test conversions I did get a few crashes under the 3.6.1 x86 standard build in MT mode where the pinterf test8 x86 build behaved nicely (under Win7-64). Probably needs more testing, but for now I have some real world conversions to do, so I am going back to the pinterf test8 version...

Groucho2004

20th June 2020, 15:58

I was talking about the pinterf test 8 build. And in this build the x86 DevIL.dll is packed with UPX.Right, I should have read your post thoroughly, I apologise.

And yes, being the retro person I am, I really like UPX... :devil:That makes no sense at all. UPX was helpful when hard drives had average sizes of 250-500 MB 30 years ago.

UPX just adds another layer of complexity, not to mention that virus engines love to report false positives for UPX compressed binaries.

Since you're so hell-bent on being retro you're probably still contributing to global warming by using inefficient incandescent light bulbs instead of LED bulbs that consume less 8-10 times less energy, right?

To each his own I always say but you have to get out of your retro cave eventually (or not, whatever).

StainlessS

20th June 2020, 16:12

I loved my 500MHz AMD Athlon with IronSides chipset, was faster than 640MHz Intel, but have dropped it long since,
I now only have a single P4 with hyperthreading, P4's without HT now binned. I'm a bit retro but you gotta come out
of your Bat-ty Cave at some point, otherwise the Joker's on you.

qyot27

21st June 2020, 01:11

There are no UPX packed files in the "files_only" package. I have not tried the installer. There used to be upx compression ages ago but it would surprise me if these compression commands made it into the AVS+ setup scripts. Anyhow, UPX compression is even more outdated than XP. :D
Despite best practices for git stating otherwise, both x64 and x86 DevIL.dll themselves are files in the source tree. The x86 .dll is UPX-packed, but the x64 one isn't.

This usually means I have to remember to unpack it before creating the installers. Sometimes I forget, so if you compare back to previous installers for 3.4.0, 3.5.0, 3.5.1, and 3.6.0, it might have been unpacked in a couple of them, but not in others.

Now, my actual preference would be that we really fix ImageSeq for cross-platform and use the opportunity to remove DevIL.dll from the source tree, because we switch to using the version installed to the system. On Windows this could manifest itself as DevIL.dll only getting shipped in the installers/.7z, or it no longer being necessary at all (because it's been linked in statically).

real.finder

21st June 2020, 18:56

seems dither=-1 in convertbits need fix/update

https://forum.doom9.org/showthread.php?p=1916319

pinterf

22nd June 2020, 08:50

seems dither=-1 in convertbits need fix/update

https://forum.doom9.org/showthread.php?p=1916319
ConvertBits is doing bit shift for YUV color spaces when converting up or down in either way. What fix is needed for that?

real.finder

22nd June 2020, 09:04

ConvertBits is doing bit shift for YUV color spaces when converting up or down in either way. What fix is needed for that?

what about when using it with fulls=true?

https://forum.doom9.org/showthread.php?p=1916338#post1916338

it still not ok

pinterf

22nd June 2020, 10:05

real.finder

22nd June 2020, 10:55

Define "not OK". Full range conversion is done as:
destination_pixel = round(source_pixel * range_target_max / range_source_max)
in C: truncate(source_pixel * range_target_max / range_source_max + 0.5)

Could zou compare with z_ConvertFormat behaviour?

using this code

ColorBars
converttoyv12
AddGrainC
Interleave(neo_vd.luma_histogram(),convertbits(16).neo_vd().convertbits(8,fulls=true).luma_histogram())

and seems fine if you replace convertbits(8,fulls=true) with z_ConvertFormat(pixel_type="YV12",dither_type="none")

pinterf

22nd June 2020, 11:34

fulls=fulld=true is the rule for RGB. You cannot use it for YUV.
It's not questions that downshift must be used, the question is that with or without rounding (how we define it). Logically "with rounding" is the way to go, but it may affect more like only this conversion.
Then there are places where simplified view at 8 bits is used (like Histogram), all these places have to be re-thought.

MeteorRain

22nd June 2020, 12:22

pinterf

22nd June 2020, 12:33

I think ConvertBits was among the first things when I started playing with high bit depth support many years ago. Strange that no one complained on it so far, it's so obvious. I suppose z_xxxx is using float data type inside (colorspace and bit depth conversions can be chained) which is rounded in a usual way when goint back to the integer.

real.finder

22nd June 2020, 17:36

Right. Like I said, you need rounding down from 16-bit to 8-bit. Not "fulls", not "fulld", but rounding.
One of the option is to dither down, so, use tools like f3kdb or dither tools. 8-bit operations are inaccurate, so rounding error is expected.

You get the high accuracy from high bit depth, you are supposed to take advantage of it, do more processing under high bit depth, and at the last step, dither it back to target bit depth.
Raise it to 16-bit, do some fine operation and lower it down, this whole process doesn't make much sense -- just do it in 8-bit then.

the point of using full is to not use bit shift method (for testing against other methods)

and I know about high accuracy and high bit depth, and no point from 8-bit -> 16-bit -> 8-bit but it was for test the output of VD in 16bit in first place then we note the problem in convertbits with dither=-1

Myrsloik

22nd June 2020, 19:42

Does avs+ work on big endian cpus now?

mp3dom

23rd June 2020, 23:45

asd posted some updated plugins with the v8 interface on the AviSynth+ x64 plugins page on the wiki: (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins)

(Added DCTFilter v8 interface)

I don't know if this is the right place to made a "request", but the original Tom Barry's DCTfilter had "offx" and "offy" parameters for offsets which apparently have been removed in later versions. These were useful to run this script (https://forum.doom9.org/showpost.php?p=1191009&postcount=6) that mimic a lowpass filter. Is it possible to add these offset parameters back into current DCTFilter or maybe there're other ways to get the exact same "lowpass" results?
Thanks

MeteorRain

24th June 2020, 02:40

I was refactoring convert_audio class.

The reference code ToFloat() and FromFloat() are simply bitshifting, while 8 to 16 and 16 to 8 are doing full range conversion.

That is,
0x00 => 0x8000
0x80 => 0x0080
0xFF => 0x7FFF

Now I'm trying to implement conversions between 16, 24 and 32 bits.

16=>24
0x0000 => 0x000080
0x0010 => 0x001080
0x0100 => 0x010081
0x1000 => 0x100090
0x7FFF => 0x7FFFFF
0x8000 => 0x800000
0x8010 => 0x801000
0xFFFF => 0xFFFF7F

Does that look right to you? Or should I simply bit shift?

tebasuna51

24th June 2020, 09:57

@MeteorRain
Simple bit shift.

The other option seems a fix inverted dither (the random dither must be aplied from high to low precission)
For what add a fix noise to pure silence (0x0000 => 0x000080)?

There are soft (eac3to) than read the low bits to know the exact precission.
For instance a lossless TrueHD track are always decode like 24 bits int, but eac3to can convert it to 16 bits if all the low 8 bits are 0, and can be recompressed to Flac 16 bits without lose precission.

There are also audio with 20 bits precission than need 24 bits with the last 4 bits to 0.

MeteorRain

24th June 2020, 10:04

That makes sense. Any idea why 8 to 16 code added the extra noise?
0x80 (unsigned byte center) => 0x0080

pinterf

24th June 2020, 13:16

AviSynth+ 3.6.2-test1 (https://drive.google.com/file/d/1_IwlcyDiv-0gnV4vPttLWV4urEaDAdMH/view?usp=sharing)
20200624 3.6.2-dev
------------------
- Fix: ConvertBits (YUV): proper rounding when bit depth is reduced and origin is 10-16 bits
(added rounder before bit-shift)
- New: Histogram("color2") to support 10+ bits.
Allow bits=x (x=8,9,10,11,12) parameter for this kind of histogram as well.

tebasuna51

24th June 2020, 19:32

Any idea why 8 to 16 code added the extra noise?
0x80 (unsigned byte center) => 0x0080
Nope.

But I never see audio 8 bits. Don't worry with that unused format.

feisty2

24th June 2020, 19:57

Nope.

But I never see audio 8 bits. Don't worry with that unused format.

audio from last century video games?

pinterf

24th June 2020, 19:57

(I was programming 6 bit audio on the good old PC speaker :) )

pinterf

24th June 2020, 20:11

Does avs+ work on big endian cpus now?
I would be surprised if it would work seamlessly. I'm totally uneducated on big endian CPUs other that once I was programming POS terminals with Motorola 68000.

Myrsloik

24th June 2020, 20:22

I would be surprised if it would work seamlessly. I'm totally uneducated on big endian CPUs other that once I was programming POS terminals with Motorola 68000.

If you didn't test it then the answer is definitely no with all that old code lying around...

pinterf

24th June 2020, 20:46

If you didn't test it then the answer is definitely no with all that old code lying around...
Yep, for example the tokenizer and the parser would have definitely failed a year ago until we used the _i string literal construct
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/parser/tokenizer.cpp#L196
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/parser/scriptparser.h#L98

real.finder

25th June 2020, 00:20

MeteorRain

25th June 2020, 04:06

Nope.

But I never see audio 8 bits. Don't worry with that unused format.

Alright, in that case I'm gonna leave 8-16 conversion standalone and untouched, and rewrite everything else. @pinterf @qyot how's that work for you guys?

By the way I always mistype pinterf as printf...

Sharc

25th June 2020, 06:50

Nope.

But I never see audio 8 bits. Don't worry with that unused format.
8 bit PCM audio from VHS transfers, for example.

Boulder

25th June 2020, 07:44

8 bit PCM audio from VHS transfers, for example.

Is there some capture device that uses only 8-bit audio? Personally I see no reason to use anything below 16 bits.

pinterf

25th June 2020, 07:52

Alright, in that case I'm gonna leave 8-16 conversion standalone and untouched, and rewrite everything else. @pinterf @qyot how's that work for you guys?

I don't mind, audio part was always out of my scope. I even left the inline asm there.

By the way I always mistype pinterf as printf...
s-printf (senior :) )

MeteorRain

25th June 2020, 08:08

I don't mind, audio part was always out of my scope. I even left the inline asm there.

Yea that's exactly why I want to improve it a bit.

By the way, what's the development process now? Shall I raise a PR directly to main repo, or should I raise it to your copy first? Anyone available for a code review? I notice that you are also in the process of porting to ARM, maybe that parts should be tested by someone before the merge?

pinterf

25th June 2020, 08:21

qyot27 is our merge-master, my own repo is a bit abandoned. Let's wait for qyot27 what he recommends.

MeteorRain

25th June 2020, 10:42

Also I'm hoping we'll get CI very soon. Ideally a Windows and a Linux build.

Sharc

25th June 2020, 10:44

Is there some capture device that uses only 8-bit audio? Personally I see no reason to use anything below 16 bits.
I don't know the history of those transfers (captures). They date 12 to 16 years back. Maybe it was a system limitation, or just a (default) setting.

tebasuna51

25th June 2020, 10:53

That makes sense. Any idea why 8 to 16 code added the extra noise?
0x80 (unsigned byte center) => 0x0080

I make some test and you are right, the conversion 8 -> 16 is wrong

A silence (0 value) in 8 bit unsigned is 0x80 but is converted to signed 16 bits like 0x0080 (128 value).

All values have this problem, the conversion must be:

Value_16_signed = Value_8_unsigned - 128

Nobody have detected this problem before.

MeteorRain

25th June 2020, 11:04

Boulder

25th June 2020, 11:25

I don't know the history of those transfers (captures). They date 12 to 16 years back. Maybe it was a system limitation, or just a (default) setting.

Probably due to some (incorrect) advice to use a lower bitdepth.. soundcards have supported 16-bit audio for quite a long time now. Something like since the mid 90s at least.

qyot27

25th June 2020, 12:49

Yea that's exactly why I want to improve it a bit.

By the way, what's the development process now? Shall I raise a PR directly to main repo, or should I raise it to your copy first? Anyone available for a code review? I notice that you are also in the process of porting to ARM, maybe that parts should be tested by someone before the merge?
Yep, PRs can go to the main repo.

tebasuna51

25th June 2020, 16:17

tebasuna: The code has a comment of
// 8 Bit data is stored += 128

// signed 16 bit data is composed of signed 8 bit data times 256 + (signed 8 bit data + 128)

// This make 0x7f(255-128) -> 0x7fff & 0x80(0-128) -> 0x8000

So it must have been intentional.

If we all agree it's wrong, then I'm gonna fix that.

The comment is wrong, yes.

The conversion must be:
Uns. Audio Signed
8bit dec Volume 16 bit
---- --- --- ------ ------
0xFF 255 127 32512 0x7F00
0xFE 254 126 32256 0x7E00
...
0X82 130 2 512 0x0200
0x81 129 1 256 0x0100
0x80 128 0 0 0x0000
0x7F 127 -1 -256 0xFF00
0x7E 126 -2 -512 0xFE00
...
0x01 1 -127 -32512 0x8100
0x00 0 -128 -32768 0x8000

A fast way in ASM can be invert first bit (a binary XOR with 0x80) and add 8 0' (or delete last for 16 -> 8)

MeteorRain

25th June 2020, 22:19

Sent my PR and waiting for your reviews.

real.finder

25th June 2020, 22:59

I don't know if this is the right place to made a "request", but the original Tom Barry's DCTfilter had "offx" and "offy" parameters for offsets which apparently have been removed in later versions. These were useful to run this script (https://forum.doom9.org/showpost.php?p=1191009&postcount=6) that mimic a lowpass filter. Is it possible to add these offset parameters back into current DCTFilter or maybe there're other ways to get the exact same "lowpass" results?
Thanks

I think it's better to request this here https://github.com/Asd-g/DCTFilter/issues

MeteorRain

26th June 2020, 06:26

Right now we still have the following inline asm left in the code.

MergeChannels::GetAudio [scalar]
Amplify::GetAudio [scalar]
Normalize::GetAudio [scalar]
MixAudio::GetAudio [scalar]

ResampleAudio::GetAudio & FilterUD_mmx [SIMD]

memcpy_amd
asm_BitBlt_ISSE

I think the scalar code can be safely deleted since modern compiler should produce comparable code.

SIMD code can be rewritten into intrinsics.

How about bitblt / memcpy code? They should only work faster on old CPU and only on 32-bit. std::copy should give very optimal performance.

vcmohan

26th June 2020, 08:17

I have been updating my plugins for the 3.6 version and correcting for earlier using IScriptEnvironment2.
A particular function SegAmp in my modPlus plugin I modified and tested fully in 3.5 version v6 and even had a bench mark run. I then tested in 3.6 v8. While all other functions were running OK, this particular function gave an error "error Reading Source Frame 0, Avisynth Read Error: SetLogParams. could not open file "po"for writing. I was using colorbars as input. I then converted to YV24. It ran OK. I then commented out converttoYV24(), reverting back to earlier color space. Curiously it now ran and I could even bench mark.
What could be the problem?

pinterf

26th June 2020, 10:01

memcpy_amd
asm_BitBlt_ISSE

How about bitblt / memcpy code? They should only work faster on old CPU and only on 32-bit. std::copy should give very optimal performance.
I've left them active only for pre-avx processors.

MeteorRain

26th June 2020, 11:12

Did some quick benchmark on L5506 (took me a long time to find a non-avx user).

memcpy_amd is slightly slower than system memcpy and std::copy, by about 3%. On sandy bridge it's running 15% slower. On a modern Ryzen it's running half the speed.

asm_BitBlt_ISSE is not quick either. The core code is movntq / _mm_stream_pi which uses 64 bit registers, not a modern SSE 128bit registers.

My personal opinion is there's no need to keep this ancient code. (Considering this is still called ISSE, which is probably optimized against Pentium 4 or earilier.)

tormento

26th June 2020, 15:37

Is there a reason of the AviSynth installer including colors_rgb.avsi + colors_rgb.txt and the "files only" not?

qyot27

26th June 2020, 15:42

asm_BitBlt_ISSE is not quick either. The core code is movntq / _mm_stream_pi which uses 64 bit registers, not a modern SSE 128bit registers.

My personal opinion is there's no need to keep this ancient code. (Considering this is still called ISSE, which is probably optimized against Pentium 4 or earilier.)
SSE2 introduced the 128-bit registers for integer operations. First-generation SSE (Pentium III) re-used the MMX registers.

MeteorRain

26th June 2020, 17:40

I have to say, translating those MMX code to SSE is pain nass. ResampleAudio took me hours and I'm only half done.

pinterf

27th June 2020, 07:59

Service announcement, I'll be *offline for two weeks.
*not doing any serious work other than running :) and will have limited PC access; my reactions on questions will be lagging a bit.

StainlessS

27th June 2020, 10:33

Missing you already :)

FranceBB

27th June 2020, 20:18

Service announcement, I'll be *offline for two weeks.
*not doing any serious work other than running :) and will have limited PC access; my reactions on questions will be lagging a bit.

You deserve this two weeks holiday after all you've done, Ferenc.
I'm already looking forward for you to come back. :D

ChaosKing

2nd July 2020, 18:08

Was this ported from neo avs+ ? https://forum.doom9.org/showthread.php?p=1859306#post1859306
I saw Filtergraph.cpp in https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/core/FilterGraph.cpp
but with avs+ 3.4 it says DumpFilterGraph() is unknown.

EDIT
whoops why am I still on 3.4. Installed avs 3.6 and it works now

If someone wants to test it, you need to call SetGraphAnalysis(true) at the beginning of your script and DumpFilterGraph the end.

Nuihc88

3rd July 2020, 19:34

Here's a few problems i've been encountering with v3.6.1 and later builds:

1. Some test builds are giving me occasional Access Violations and silent crashes while seeking during realtime playback; i get far more of the former with test8 than test6, test4 & test5 seem to be working most reliably for me. Seeking or pausing for extended periods of time during realtime playback seems to be the surest way to trigger it, even so it only happens about 1 out of every 50 tries. Each build handles the issue differently and gives a slightly different error, always starting with 0xC0000005, when one is given at all.
2. Sometimes realtime playback never recovers on it's own after presentation queue drops to zero, despite there being enough computational power for it. Seems to have about 50% chance of occurring.
3. After test6, playback recovery behavior has changed for the worse, if a script is too heavy, instead of just dropping interpolated frame(s), video sometimes starts lagging behind the audio.
4. Final 3.6.1 build (r3300) and later are causing hard lockups with PotPlayer.

I'm guessing that all of above is due to memory leak(s) somewhere. Perhaps someone can verify if they're getting the same ones...

There's also this older problem with Prefetch, which may warrant investigation at some point:

When using multiple instances of Prefetch (with SVPflow filters) there are times when the same frame is returned two times in a row.
In realtime playback usage this can also cause both sync-drifting and occasional jerky movements (without frame drops or glitches showing up in MadVR's OSD).
Frame repeats become more frequent with each additional Prefetch buffer, regardless of whether it's from an additional Prefetch instance or thread and rate of occurrence doesn't seem to scale with buffer size or latency.
Latencies reported by MadVR also more than double every time a new Prefetch thread is added. Thread count of other filters doesn't have nearly as much impact on latency.

I have been trying to gather more detailed information on the nature of the issue for the past month, but haven't managed to figure out a whole lot. I'm guessing that there's probably an off-by-one bug somewhere within cache management.

My test environment is 64bit Win7, running 32bit AviSynth+ through PotPlayer, ffdshow and MadVR.

manolito

3rd July 2020, 22:06

Can you reproduce all of these issues when using AVS+ 3.5.1 32-bit? I have this feeling that merging the features from the AVS+ Neo fork are responsible for most of these issues.

With the plugins I use AVS+ 3.6.1 is now just as stable as version 3.5.1, but I really see no advantage whatsoever over 3.5.1. It's all in the name of progress... :p

Nuihc88

3rd July 2020, 22:45

Can you reproduce all of these issues when using AVS+ 3.5.1 32-bit? I have this feeling that merging the features from the AVS+ Neo fork are responsible for most of these issues.

I really only started checking and testing pinterf's builds on regular basis after he started merging stuff from the Neo fork and AVS+ inherited it's realtime speed and latency benefits.

v3.5.2 builds were fairly stable for me, but i did get an occasional Access Violation at least with some of those too. Realtime usage has a tendency to highlight stability problems that are far less often encountered in 'normal' use; repeatedly seeking back on a scene to optimize script performance, even more so.
In my much earlier notes i had marked r2772 & r2923 as exceptionally stable, but even between those, some builds were far less so, which is one of the reasons i'm suspecting that there's a memory leak somewhere.

I don't think the Prefetch issues could have even been detected before the merge, as Neo was too unstable and AVS+ too slow and inflexible to test with. In any case, the new version of the Prefetch function performs far faster with one thread than the old version ever did with any value.

real.finder

4th July 2020, 05:45

this work fine for me

mp_pipeline("""
### dll: Avisynth-3.6.2_20200624_test1-filesonly\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")
Prefetch(4)
### ###
""")

it was not before https://forum.doom9.org/showthread.php?p=1904931#post1904931

admfilter is in AdvancedDenoising.avsi (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/AdvancedDenoising.avsi) and it also need this (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi)

real.finder

5th July 2020, 07:19

pinterf, if you have time, can you please check this? https://forum.doom9.org/showthread.php?p=1917585#post1917585

gispos

6th July 2020, 21:28

StainlessS

6th July 2020, 23:21

I don't know what 'color_white' means.

colors_rgb.avsi, installed along with Avisynth/+

# ...
global color_violet = $EE82EE
global color_wheat = $F5DEB3
global color_white = $FFFFFF
global color_whitesmoke = $F5F5F5
global color_yellow = $FFFF00
global color_yellowgreen = $9ACD32
# ...

EDIT: Maybe that color_white should be replaced with $FFFFFF, should not really need to install an avsi just to use an obvious definition.

gispos

7th July 2020, 04:19

colors_rgb.avsi, installed along with Avisynth/+

Thanks StainlessSS, It must have been lost. I have to google it.

tormento

7th July 2020, 07:35

colors_rgb.avsi, installed along with Avisynth/+
As I reported earlier, it's not included in the "file only" version.

LigH

7th July 2020, 08:01

:sly: May require a "supplement" files archive in addition to the "file only" archive... :o

Groucho2004

7th July 2020, 09:10

My take on this using common sense: :sly:

Anyone downloading the files-only package has Avisynth+ already installed either via regular installer or Universal Installer. Either option installs/contains the colors_rgb.avsi file. So, no need to put it in the package unless there were changes to it which I believe happens only once a decade.

StainlessS

7th July 2020, 11:18

Last change to colors_rgb.avsi was (2015) removal of a double entry for color_palegoldenrod,
https://forum.doom9.org/showthread.php?p=1711065#post1711065

EDIT: The diligent amongst you might notice two copies of "color_palegoldenrod" in the mp4,
this is a duplicate in colors_rgb.avsi as installed by v2.6RC1, you might like to delete duplicate from your copy,
reported in RC1 devs thread.

https://dl.dropboxusercontent.com/s/akrph1tq1tszmsi/hexyuv.gif

The double entry is in the image when topmost color is OrangeRed.
EDIT: Only the RGB colors are in colors_rgb.avsi, the other YUV color values are calculated from those, see linked thread.

gispos

10th July 2020, 04:28

Avisynth 3.6.2
Have not tried whether it is the same with the 3.6.x versions

If MP_Pipeline is in a script, this script can no longer be loaded with AviSource.
This is a huge problem for me, with Delphi 'AviSource' is the only way to open a script when MCTD is called in that script.

I would like to know why that is with Delphi and 'MCTD', it has been plaguing me for a few months and I just can't figure it out.

Edit:
That with Avisynt 3.6.2 and AviSource was my mistake.
There was a 3.6.1 version in one system directory, after replacement AviSource works again.

wonkey_monkey

10th July 2020, 10:25

Are we able to apply and read per-frame/per-clip property values these days (in C++)? If so is there documentation?

DJATOM

10th July 2020, 13:05

Probably that can be used as example how to use them in plugins: https://github.com/AviSynth/AviSynthPlus/blob/3b96a4feddbf67ae19c9e56320f950debdadf20f/avs_core/filters/conditional/conditional_reader.cpp#L1189

wonkey_monkey

10th July 2020, 17:13

Thanks, I'll peruse that.

I still think a true inter-filter communication system would be awesome... at least for the kind of filters I keep finding myself writing...

wonkey_monkey

11th July 2020, 11:55

This isn't really sinking very well, so... if a frame or clip is given a property, but is then passed through another filter, are all the properties lost?

StainlessS

11th July 2020, 12:46

This isn't really sinking very well, so... if a frame or clip is given a property, but is then passed through another filter, are all the properties lost?

Something here:- https://forum.doom9.org/showthread.php?p=1913860#post1913860

Suggest Search on:- keyword "Properties", Show result as Posts, user name Pinterf, search in forum(s) Capturing & Editing Video/Avisynth Developement.

LigH

13th July 2020, 07:38

There is a report in the German Gleitz forum (https://gleitz.info/forum/index.php?thread/48236-megui-stürzt-nach-audio-encode-immer-ab/) about audio issues with MeGUI (it locks up, no progress) when SuperEQ is used to upmix stereo to 6Ch. MeGUI prepares an AviSynth script and a subdirectory with SuperEQ parameter files per channel. But the conversion apparently gets stuck. This happens also when the script is fed directly into ffmpeg. I did not yet test this myself. But I guess it could be worth an investigation whether any regression was introduced in the audio part (depending on the exact AviSynth+ DLL version)...

MeGUI: 2924 x86
AviSynth+ 3.5 (r3106, 3.5, i386)

manolito

13th July 2020, 20:58

This is a follow-up to this older post:
https://forum.doom9.org/showthread.php?p=1916219#post1916219

I have no idea what to make of it, but after a few days of testing with different HD sources (only testing 32-bit AVS+) I can clearly reproduce that version 3.6.1 Test 8 is by far more stable in MT mode than the later versions 3.6.1 stable (tested only the "standard" non-XP version) and also the latest 3.6.2 Test 1 version.

Test platform:
ThinkPad T530 with a Core i5-3230M (Ivy Bridge, 3rd generation)
8 GB of RAM
Win7 Pro 64-bit
AVS+ Prefetch value was set to 4 threads

I converted HD sources (AVC or HEVC video at 50 fps, AAC, AAC-LATM or E-AC3 audio) to SD with AVC video and AAC audio. I used older 2.6 and 2.5 plugins. MT settings from the mtmodes.avsi taken from the AVS+ Wiki page, additions taken from this post by almosely:
https://forum.doom9.org/showthread.php?p=1865279#post1865279
The changes are in the 3rd paragraph of the post.

These tweaks made AVS+ 3.5.x quite stable already, but with some exceptions. After establishing a job in StaxRip (latest stable 32-version) it turned out that it was mostly necessary to save the job first, reboot and then start the job. Also Web browsing during the X264 encode was not really safe. If I did not take these precautions, X264 would crash randomly, mostly near the end of the conversion.

After experimenting with the AVS+ 3.6.1 test builds I found that the MT behavior had improved. Especially with Test 8 it was possible to browse the Web, even streaming a YouTube clip during the encode. Also a reboot before starting the actual encode was no longer required.

But the joy stopped after installing the stable version 3.6.1. The old occasional crashes were back again. I used the "standard" non-XP build.

And last I tested 3.6.2 Test 1, this build is XP-compatible again. So I hoped that the stability of 3.6.1 Test 8 would reappear, but it did not. Same random crashes as with 3.5.x and 3.6.1 stable.

The conclusion is that these differences in MT stability have nothing to do with the fact if the build is XP compatible or not. It looks more like something in the code itself has changed after 3.6.1 Test 8, and this change affects memory handling in multitasking mode. No way for a user to debug this, only pinterf or qyot27 could possibly find out what is going on here.

I am back to version 3.6.1 Test 8 for the time being...

Cheers
manolito

tebasuna51

14th July 2020, 11:37

...audio issues with MeGUI (it locks up, no progress) when SuperEQ is used to upmix stereo to 6Ch. MeGUI prepares an AviSynth script and a subdirectory with SuperEQ parameter files per channel. But the conversion apparently gets stuck.
...any regression was introduced in the audio part (depending on the exact AviSynth+ DLL version)...
AviSynth+ 3.5 (r3106, 3.5, i386)

Of course the regression is here:
SuperEQ(clip, string filename)

Audio is always converted to Float.
AVS+ no conversion is performed. Accepts Float audio only.

The script created by MeGUI must include a ConvertAudioToFloat() before call SuperEQ in Avs+

LigH

14th July 2020, 12:35

Thanks, I will report that there.

qyot27

15th July 2020, 03:16

manolito

15th July 2020, 16:23

Thanks very much for this upload, should be very helpful...
Will start testing tonight.

magnetite

15th July 2020, 23:14

So I was experimenting with the CUDA version of Avisynth+ which was merged into the main Avisynth+ branch. It seems that it results in a memory leak. While using MeGUI, it gets stuck on the pre-processing phase, then the memory usage goes through the roof (99% RAM usage with 16 GB installed) before the app locks up.

LoadPlugin("C:\MeGUI 64-bit\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("Z:\Outer Limits\Season 3\Disc 4\Dead Man's Switch.mkv", cachefile="D:\Temp\eksmcibs.nc1\Dead Man's Switch.mkv.lwi")
#crop
#resize
OnCPU(2)
KTGMC(Preset="Slow")
OnCUDA(6)

The same script run under the Nekopanda version of Avisynth (r2827) is able to run just fine. The memory usage was around 1 GB or so on average.

Nuihc88

16th July 2020, 00:47

All of the changes between test8 and the final version of 3.6.1 were on June 15th. There are seven of them to investigate.

http://www.mediafire.com/file/xzjmybvbjjeugqf/avs_stax32_bisect.7z/file

That's a pack of five of those commits (two of them don't compile on their own, but require the following commit). You can test those and see if one of them is where the issue was introduced.
Nevermind posted too quickly... These three of the problems i reported earlier appear to be gone in the build from the 'r3298f-git_82a06eee'-folder:
2. Sometimes realtime playback never recovers on it's own after presentation queue drops to zero, despite there being enough computational power for it. Seems to have about 50% chance of occurring.
3. After test6, playback recovery behavior has changed for the worse, if a script is too heavy, instead of just dropping interpolated frame(s), video sometimes starts lagging behind the audio.
4. Final 3.6.1 build (r3300) and later are causing hard lockups with PotPlayer.
I'll keep testing these builds and reporting my findings (by editing this post) as well...
...looks like the problem #3 is still there, but much harder to trigger with these new test builds compared to test8...
...nevermind, i forgot to test them without Prefetch, it was masking both problems #2 & #3, both of which are still present...
...Still haven't encountered problem #4 with any of these builds yet, however i noticed that without Prefetch both builds 'r3297f-git_0c09510f' & 'r3298f-git_82a06eee' are much slower than the rest and 'r3294f-git_7a0aa2f3' is a little bit slower than the ones before it.

qyot27

17th July 2020, 23:29

r3298f is the same as the final release of 3.6.1. There are absolutely zero code differences between them. The two commits that separate 3298 from 3300 are docs and comments only. The only practical difference is that I did update to the latest version of VS2019 before running off all these test builds.

manolito

18th July 2020, 00:48

I am still in the middle of my tests, it turned out to be a little more difficult than I anticipated... :scared:

It turned out that the random crashes only occur with long source files (duration of more than 2 hours). Makes testing very time consuming.

My results so far are that r3290 (Test 8) up to r3292 have no problems with MT, but r3294 caused crashes again. I will test r3297 later tonight and report back.

qyot27

18th July 2020, 01:42

Does avs+ work on big endian cpus now?
I would be surprised if it would work seamlessly. I'm totally uneducated on big endian CPUs other that once I was programming POS terminals with Motorola 68000.
If you didn't test it then the answer is definitely no with all that old code lying around...
"Which BE CPUs?" would be the more important question, I think. I mean, I did run a test on a qemu-system-ppc VM emulating a G4¹ and it could compile and run:

http://i.imgur.com/w8WT7HEl.png (https://i.imgur.com/w8WT7HE.png)
(Void Linux ppc glibc; musl chokes on something in AviSynth+, or something in the loader in avs2yuv or FFmpeg, probably the atexit handler)

Although I think that's a bit over-the-top; all it required was adding the predefined macros for PPC into avs/config.h. A Talos II or Blackbird setup would make more sense, but unless it's significantly trickier to do, POWER9-based CPUs supposedly can operate in ppc64le mode.

Some of the filters may produce unexpected results - Version().ConvertTo444() was okay, the resulting output from x264 played with correct colors using the media player in the live session, but ConvertToYV12().BilinearResize(640,352) caused incorrect colors (not sure if it was the conversion to YV12 or the resizer). To actually test efficiently, I'd have to do a real install so I can test FFmpeg/FFplay directly instead of piping in.

¹only because the G3 iBook I have access to didn't want to boot from either CD or USB so that I could test with a modern Linux that still supports that platform. And there's no way I was going to try to figure out how to get a suitably-modern version of GCC or Clang running on OS X 10.2.

real.finder

18th July 2020, 02:15

ppc

maybe someone will make a cell (ps3 cpu) port for avs+ some day :P

manolito

18th July 2020, 15:11

qyot27

19th July 2020, 00:29

I am finally done with my tests of the different AVS+ builds, and at least for my computer it is pretty clear that the decrease in MT stability occurs in r3294f for the first time. So it must be one of the commits which were merged after r3292.
Not just 'one of the commits which were merged after r3292', specifically r3293 and r3294f*. While there may be a pile-on effect with later commits, the ones that need to be looked at are 93fd47de (https://github.com/AviSynth/AviSynthPlus/commit/93fd47ded842916a663de0e0ac2e9077bf94ee61) and 5479b184 (https://github.com/AviSynth/AviSynthPlus/commit/5479b18401641ae517c293d8b577d1a816c123f8).

*the test builds with 'f' stuck on the end are that way due to having to move 5479b184 from its original position as r3298 back into the position of r3294 so that the source could compile. r3293 doesn't compile on its own, but it does with the fix applied in 5479b184. Hence, the moved commit is r3294f and all the others that came after it were bumped up +1 and had 'f' tacked on the end. Shuffling the position around will not happen in the upstream master branch, it was only needed so that I could get a working build that pertained to only the changes in 93fd47de (which left a couple stragglers that 5479b184 fixed).

I'm not sure if moving from a typedef to a regular enum would cause this, or if it would be due to an int cast that was removed.

manolito

19th July 2020, 22:01

Thanks qyot for the explanation...

I went through these commits, but since I do not speak CPP I don't have a clue about what these commits might do to multithreading stability. I will stick with r3292 right now and see if my next conversions all go well.

Maybe these issues only apply to the 32-bit version of AVS+, maybe the Operating System has an influence (Win7-64), or maybe it is my older ThinkPad T530 notebook, whatever...

Thanks again
manolito

real.finder

20th July 2020, 00:39

I think there are some bug here https://forum.doom9.org/showthread.php?p=1918913#post1918913

DTL

23rd July 2020, 19:12

I think there still exist some bug in resampler engine - https://forum.doom9.org/showthread.php?p=1919151#post1919151
With latest 3.6.1 trying SetMaxCPU to "none" do not helps and it looks equal in both vertical and horizontal resamplers.

wonkey_monkey

27th July 2020, 00:35

qyot27

27th July 2020, 03:08

I've got a funny feeling I may have mentioned this before, but...

Specifying a non-existant blend more for overlay, e.g.:

colorbars.overlay(colorbars, mode = "doesnotexist")

results in an unhanded exception instead of a graceful error.
I can't replicate this. I tried:
v1=Colorbars()
v2=v1.FlipHorizontal()
Overlay(v1,v2,mode="system")
and
v1=Colorbars()
v2=v1.FlipHorizontal()
Overlay(v2,mode="system")
and even a direct copy-paste:
colorbars.overlay(colorbars, mode = "doesnotexist")

and in all three cases it did throw an actual error message from AviSynth:
E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Overlay: Invalid 'Mode' specified.
(+) Video --vid=1 (rawvideo 640x480 29.970fps)
(+) Audio --aid=1 (pcm_f32le 2ch 48000Hz)
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] ...treating it as fatal error.

Exiting... (Errors when loading file)

E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Script error: Invalid arguments to function 'Overlay'.
[ffmpeg/demuxer] (test.avs, line 5)
[lavf] avformat_open_input() failed
[ffmpeg/demuxer] avisynth: Script error: Invalid arguments to function 'Overlay'.
[ffmpeg/demuxer] (test.avs, line 5)
[lavf] avformat_open_input() failed
Failed to recognize file format.

Exiting... (Errors when loading file)

E:\Documents>mpv test.avs
[ffmpeg/demuxer] avisynth: Overlay: Invalid 'Mode' specified.
(+) Video --vid=1 (rawvideo 640x480 29.970fps)
(+) Audio --aid=1 (pcm_f32le 2ch 48000Hz)
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] error reading packet: Unknown error occurred.
[lavf] ...treating it as fatal error.

Exiting... (Errors when loading file)
(although Windows Defender did not like that second one when I tried running it)

What it does seem like it's doing, though, based on the fact the video frame that gets generated matches the dimensions of Colorbars instead of the output of a simple GetMessage error clip, is that the error is getting emitted by avisynth, but it's not being written to the video itself, and the non-clip error is getting output instead (all those [lavf] error reading packet: Unknown error occurred. lines).

wonkey_monkey

27th July 2020, 09:13

Oh wait, I think I remember now. For some reason it doesn't throw the error on filter creation, as you would expect, but on GetFrame.

Boulder

30th July 2020, 18:49

poisondeathray

30th July 2020, 18:56

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur. The clip was originally created in VirtualDub2 by loading an Avisynth script and saving as old format AVI using ffv1 v1.3 at 8 bits to compress. I tried re-encoding that clip to Huffyuv but it didn't help (the sample clip is that one)

Does anyone else see the same?

FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

Here's a 5-frame snippet to test on:
https://drive.google.com/file/d/1AwNgOESljQ5-Q40-vVpqDbq3khrv8uSm/view?usp=sharing

I get green bar too.

Changing to src filter to LSmash also results in green bar

Changing blur to 1.0, or 0.5 green bar still there

You can also reproduce with colorbars or blankclip

Colorbars(720,576,"YV12")
#Blankclip(width=720,height=576,pixel_type="YV12")
ConvertBits(16)
Blur(0.65)

qyot27

30th July 2020, 21:30

I can't reproduce. What versions of AviSynth+, VirtualDub2, and FFMS2 are you using? Tested here with 3.6.1, 44282, and C-plugin r1346+131 (2020-06-05; never released, but at this point I'd do well to run off a new build anyway). Neither 32 or 64 bit had issues.

poisondeathray

30th July 2020, 21:33

I was using avs+ x64 3.6.2 (r3300) . Preview is the same in avspmod x64, mpchc x64, or vdub2 x64

I think it's unrelated to source filter.

Colorbars(720,576,"YV12")
ConvertBits(16)
Blur(0.65)

https://i.postimg.cc/qvJ6rMdQ/greenbar000000.png

wonkey_monkey

30th July 2020, 21:57

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.

qyot27

31st July 2020, 00:01

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.
AVX might be it. Does it disappear if with SetMaxCPU("none")?

The only setup I've tested thus far is an Apollo Lake, so up to SSE4.2 should be okay. But I couldn't see it on either the source sample above or Colorbars. Apollo Lake doesn't have AVX or AVX2, though.

Richard1485

31st July 2020, 00:24

poisondeathray

31st July 2020, 00:25

AVX might be it. Does it disappear if with SetMaxCPU("none")?

The only setup I've tested thus far is an Apollo Lake, so up to SSE4.2 should be okay. But I couldn't see it on either the source sample above or Colorbars. Apollo Lake doesn't have AVX or AVX2, though.

SetMaxCPU("none") fixes it for me

Boulder

31st July 2020, 08:40

It only seems to happen when (width-16) is a multiple of 32 (in other words it's (x+0.5)*32 where x is an integer). Possibly an SSE/AVX edge case gone awry.

I think the line is there even in other cases, but it's not green. It's very faint, almost transparent. Could be placebo effect as well :D

I'm running a Ryzen 3900X system with Avisynth-3.6.2_20200624_test1 installed. I've done a lot of HD and UHD stuff since installing and I have not seen the issue in those so it must be somehow related to lower resolutions. This is the first SD level work I've started for a long time.

manolito

31st July 2020, 12:35

I used to see that same green line sometimes on standard AviSynth. It came up in the context of HD-to-SD conversions, usually involving a call to ColorMatrix(). Changing the order in which I called the functions would resolve it, so I just used to work round it.

I remember a similar problem from 2015 when using an older version (pre 2.5) of ColorMatrix. Updating to v 2.5 fixed it. I suppose that you use a "modernized" version of ColorMatrix these days, but maybe a regression from the old times has sneaked back in...

See here:
https://forum.videohelp.com/threads/277852-AVStoDVD-Support-Thread?p=2416492&viewfull=1#post2416492

stax76

2nd August 2020, 10:48

@manolito

The latest staxrip beta has an experimental x86 build. It has 3 AviSynth modes to choose from, portable, installed and VFW. It misses many tools and all plugins except 2 source plugins. There is a setting under Danger Zone to disable the tool verification and there is a setting to disable plugin loading. For feedback please use the issue tracker.

Boulder

2nd August 2020, 12:02

Despot v3.6.3.0 (x64) causes an access violation error with 3.6.2-test1. I didn't test any previous releases.

wonkey_monkey

2nd August 2020, 22:43

ajp_anton

4th August 2020, 22:53

colorbars.converttoyv12

trim(0,0)

writefileif(last, "test.txt", "ydifferencefromprevious==0", "current_frame")
"Invalid arguments to function 'writeif'."

Comment out the trim, and it works. Also works with "trim(last,0,0)", but "last.trim(0,0)" fails.

Dogway

5th August 2020, 09:04

Despot v3.6.3.0 (x64) causes an access violation error with 3.6.2-test1. I didn't test any previous releases.

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.

Groucho2004

5th August 2020, 10:54

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.I've been doing some debugging but to no avail. Also, very little time ATM.

Groucho2004

6th August 2020, 04:15

It's been reported here (https://forum.doom9.org/showthread.php?p=1918829#post1918829) as well at the expect Groucho2004 replies back.I have uploaded a new version (3.6.3.1), shouldn't crash any more.

hello_hello

11th August 2020, 17:43

poisondeathray

11th August 2020, 18:29

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

You should use planar RGB for any processing
ConvertToPlanarRGB()

But maybe a better error message could be added

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

No

hello_hello

11th August 2020, 19:59

You should use planar RGB for any processing
ConvertToPlanarRGB()

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.

But maybe a better error message could be added

But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?

No

Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?

Thanks.

poisondeathray

11th August 2020, 20:23

I only put ConvertToRGB64() before ConvertBits() to imply the source was already RGB64 and I'm converting to RGB32 with
ConvertBits(8, dither=1)
I should have made the clear.

If a source is interlaced RGB, the script I'm working on converts the colorimatry with HDRTools the following way. It's probably not something there'd be a need for often, but the option is included.

ConvertToRGB64().ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

This way for planer:
ConvertBits(32).ConvertRGBtoXYZ(Color=2).ConvertXYZtoRGB(Color=3)

It makes it a little easier to convert back to the original bitdepth afterwards, but do you know if there's an advantage to always using a planar input? It needs to be RGB32, RGB64 or 32 bit planer, but RGB32 causes color banding.

But why can I down-convert with dither=0 or dither=-1?
Is there a reason dither=1 can't be used when down converting RGB64 or RGB48?

That was referring planar vs. packed (interleaved) RGB , not "bits"

It's analogous to YV16 vs. YUY2 . Planar vs. Packed

eg. "RGB64" would be "RGBAP16" . Both are 16bit per channel RGB with alpha

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

Planar processing is faster; most modern filters work with planar. Packed support is only for legacy purposes

When something doesn't work in avisynth for RGB processing , chances are you need planar RGB. That's where some better error message could be helpful

Does that mean for converting an RGB64 source to RGB32, there's no difference between these two methods?

ConvertBits(8, dither=-1)
ConvertToRGB32()

I assumed it'd be better to dither when down-converting. Is that correct?

There should be no difference. You can check with subtract or psnr or simlar methods

"Better or not" depends on the situation

hello_hello

11th August 2020, 20:44

Thanks for the info. I'll do the color conversion in 32 bit planer and convert back to RGB64 or RGB32 etc later.

pinterf

18th August 2020, 12:46

Has something changed with animate? I just dug out an old script which used animate without specifying a clip (i.e. using implicit last) but that no longer seems to work. Now I have to specify "last" or tack it directly on the end:

# this works:

colorbars.animate(0,100,"blur",0.1,1.5)

# this works:

colorbars
animate(last, 0,100,"blur",0.1,1.5)

# this DOESN'T work:

colorbars
animate(0,100,"blur",0.1,1.5)

Edit: seems to be a problem with implicit last as in the post below.
Fixed on git.
# this DOESN'T work:
colorbars
Animate(0,100,"blur",0.1,1.5)

Animate is special in the way that it has two function signatures: "iis." and "ciis."
Passing the parameters with the syntax above will find the "clipless" version. Animate is created O.K.
When its internal expression parameter "blur" is evaluated later, it turnes out that it requires a clip. But it's too late, function with the matching (clipless) function signature was already chosen and Invoking "Animate" as a whole will fail and giving a function arguments error.

When such function parameter error exception is thrown, Avisynth will try to give a second changce and find the appropriate function with a forced clip ("last") variable.

pinterf

18th August 2020, 12:51

Avisynth+ 3.5 on XP.

The following results in an access violation error message.

ConvertToRGB64().ConvertBits(8, dither=1)

As does this.

ConvertToRGB48().ConvertBits(8, dither=1)

Without dithering, or with dither=0, they're fine.

While I'm here, is there any dithering applied for this sort of down-conversion?

ConvertToRGB64().ConvertToRGB32()

Thanks.
From RGB64 and RGB48 ConvertBits failed to get its floyd converter function internally, so it crashed.

Fixed on git, result should be the same as with planar RGB formats. Indeed, in this case 16 bit packed formats are treated internally (losslessly converted to and from) as planar RGB.

pinterf

18th August 2020, 12:52

pinterf

18th August 2020, 12:55

I have a video clip, which has a green bar at the right side of the frame if I convert bitdepth to 16 bits and use Blur.
[...]
FFVideoSource("snip.avi")
convertbits(16)
Blur(0.65)

fixed on git
AVX2 issue which occurs with non mod32 width.

real.finder

18th August 2020, 14:07

Function SCDetect(clip c, string "scFile", int "thSCD1", int "thSCD2", float "mDiff", int "pel", int "search", int "searchparam", bool "preblur", bool "info"){

scFile = Default(scFile, "scFile.log")
thSCD1 = Default(thSCD1, 360)
thSCD2 = Default(thSCD2, 120)
mDiff = Default(mDiff, 2.5)
pel = Default(pel, 1)
search = Default(search, 4)
searchparam = Default(searchparam, 2)
preblur = Default(preblur, true)
info = Default(info, false)

last = preblur ? c.RemoveGrain(20, 0) : c

Assert( IsYV12 , "SCDetect needs YV12 input!" )

super = MSuper(pel=pel, chroma=false)
vector = super.MAnalyse(pelsearch=pel, search=search, searchparam=searchparam, chroma=false)
global scMask = MSCDetection(vector, thSCD1=thSCD1, thSCD2=thSCD2).Crop(0,0,16,16)

global SC_mD = mDiff
global mean = Histogram(mode="Color").Crop(width+64, 64, 128, 128)

SCTrue = c.Subtitle("Scene change: true" )
SCFalse = c.Subtitle("Scene change: false")

info ? ConditionalFilter( last, SCTrue, SCFalse, "boolSC", "==", "true" )
\ : nop
FrameEvaluate( """global boolSC =
\ (
\ ( scMask.YPlaneMax == 255 ) &&
\ (
\ (mean.YDifferenceFromPrevious > SC_mD*3) ||
\ (
\ (mean.YDifferenceFromPrevious > SC_mD) &&
\ (mean.YDifferenceFromPrevious > (mean.YDifferenceToNext+mean.loop(0, 0, -1).YDifferenceToNext+mean.loop(0, 0, 1).YDifferenceToNext)/1.2)
\ )
\ )
\ )""" )

( scFile != "nul" ) ? WriteFileStart( scFile, """ "# Scene change frame list" """ ).WriteFileIf( scFile, "boolSC==true", "current_frame" ) : nop

return last
}
ColorBars
Converttoyv12
SCDetect

still not work (https://forum.doom9.org/showthread.php?p=1918893#post1918893) with build 0bf7242 I made, but Animate now work

real.finder

20th August 2020, 00:10

StainlessS

4th September 2020, 16:42

Suspect BUG.
Prefetch(), seem to interfere with scriptclip evaluated runtime functions, optional named args, following an array of data args.

Here, and the following post:- https://forum.doom9.org/showthread.php?p=1922711#post1922711

real.finder

4th September 2020, 16:59

StainlessS

4th September 2020, 17:02

Thanks RF, no I did not yet, I always have problems downloadng Pinterf google drive stuff, I'll boot to linux and re-try download.

EDIT:
Got it under linux.
It actually downloads under Windows 7 with Opera (I forgot this time about Opera, but downloads usually only after some wait),
I have big-ish hosts file on windows blocking all kinds of ads/telemetry and stuff, Also Adblock origin, flash block and other stuff under both linux and
windows versions of firefox, so its probably my system hosts and firefox addons that cause me problems.

StainlessS

4th September 2020, 17:26

Yep, 3.6.2 test 2, removes the problem OK, thanks RF, sorry for the bother P & Q.

EDIT: I dont usually download files only test version of Avs+, until/unless there is an XP version included.

manolito

4th September 2020, 23:27

kedautinh12

5th September 2020, 00:43

StainlessS

5th September 2020, 01:45

AFAIk all the pinterf files only test versions are XP compatible.
thankx, did not know that.

kedautinh12,
Thank ked, I got it from real.finder Pinterf link via linux.

real.finder

5th September 2020, 06:17

What is going on with this 3.6.2 test 2 build???

The first post of this thread still lists test1 as the latest test version. And when using the real.finder link for test 2 Google tells me that the file is infected with a virus and can only be downloaded by the owner...

@ StainlessS
AFAIk all the pinterf files only test versions are XP compatible.

it's from https://github.com/AviSynth/AviSynthPlus/issues/186#issuecomment-683817906

edit: seems you right there are problem with google drive, anyway it's only one https://www.virustotal.com/gui/file/d12c9d105f2a3af7f5b14273064e911d3754e5b1ef5cbfb8a25672dd3bfe4610/detection so it's false positive

also seems you didn't note https://forum.doom9.org/showthread.php?p=1922691#post1922691

manolito

8th September 2020, 04:52

kedautinh12

8th September 2020, 06:23

StainlessS

8th September 2020, 09:11

VCRUNTIME140D.dl looks to be a debug version of VCRUNTIME140.dl from Visual Studio 2015.
[you will not have it without the compiler, but dont seem to cause me problem and I dont have it]

real.finder

8th September 2020, 10:21

try this one https://www.sendspace.com/file/qooa40 I made it not as debug

tormento

8th September 2020, 11:43

did you tried with test 2
Questo file è infettato da un virus

Solo il proprietario può scaricare i file contenenti virus.
I.e. Drive complains about a virus and doesn't download it.

Any mirror available, please?

real.finder

8th September 2020, 13:07

I.e. Drive complains about a virus and doesn't download it.

Any mirror available, please?

for x86 see my post in #648

for x64 see kedautinh12 #642

tormento

9th September 2020, 10:44

for x64 see kedautinh12 #642
LOL

I should open my eyes wider when reading.

10x

kedautinh12

12th September 2020, 04:50

No wonder that the unofficial 3.6.2 test2 build is not featured, because I found that it is thoroughly broken...

During a few tests with interlaced sample clips this one crashed reliably using the test2 build:
http://www.nepadigital.com/reencode/avidv.avi

First of all the SSRC audio filter seems to be missing. Plus the encode crashes because a VC++ redistributable is missing. The missing file is VCRUNTIME140D.dll, and this redistributable is not included in the very latest Abbodi VC++ AIO package. Reverting to version 3.6.2 test1 fixed the problems.
I check vcredist downloaded from there errors with some softwares only support visual c++ 2015, 2017, i checked and package from there only name visual c++ 2019 after install
https://github.com/abbodi1406/vcredist/releases
When i downloaded from there, visual c++ full name 2015-2019 after install and softwares work correctly and don't crash anymore
https://downloadly.net/2020/13/3230/03/microsoft-visual-c-redistributable/15/?#/3230-microsof-082013094212.html

kedautinh12

17th September 2020, 07:34

for x86 see my post in #648

for x64 see kedautinh12 #642

your built and pinterf can't use with megui 32bit

Edit: i know what wrong, just download this file and copy all file from library folder, after paste to windows/system32 if you use win x86 or windows/sysWow64 if you use win x64
Edit2: https://drive.google.com/file/d/13O9HsY1y93DM16Z75ZXU4G63esEHD2OE/view?usp=drivesdk

kedautinh12

18th September 2020, 13:27

Everyone can try 3.6.2 test 2b: https://github.com/AviSynth/AviSynthPlus/issues/190#issuecomment-694731296

pinterf

18th September 2020, 14:35

Previous not-so-public test2 version contained debug builds of the x86 bundled plugins so people with no VS development environment had bad luck.

real.finder

20th September 2020, 01:52

I did update those old posts with this Reply (note the colors)
ok, so I will mention what not has HBD yet

1st is plugins that has VS ports with HBD:-
1 - EEDI3 (https://github.com/pinterf/EEDI3) (no HBD yet (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-EEDI3))
2 - Dither_resize16/fmtconv (no yet) here https://github.com/EleonoreMizo/fmtconv the vs port
3 - SangNom2/SangNomMod (done by Asd (https://github.com/Asd-g/AviSynth-SangNom2))
4 - TTempSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsTTempSmooth))
5 - EEDI2 (done by Asd (https://github.com/Asd-g/AviSynth-EEDI2))
6 - TCanny (there are TCannymod by chikuzen but I think with no HBD) (done by Asd (https://github.com/Asd-g/AviSynth-vsTCanny))
7 - Yadifmod (there are Yadifmod2 by chikuzen with not completed HBD) (done by Asd (https://github.com/Asd-g/yadifmod2))
8 - DeblockPP7 (done by Asd (https://github.com/Asd-g/AviSynth-vsDeblockPP7))
9 - median (not yet) here https://github.com/dubhater/vapoursynth-median the VS port
10 - tbilateral (done by Asd (https://github.com/Asd-g/AviSynth-vsTBilateral))
11 - tedgemask (done by Asd (https://github.com/Asd-g/TEMmod) but no HBD yet) here https://github.com/dubhater/vapoursynth-tedgemask the vs port
12 - MSmooth (done by Asd (https://github.com/Asd-g/AviSynth-vsMSmooth))
13 - ASharp (no yet) here https://github.com/dubhater/vapoursynth-asharp the VS port
14 - degrainmedian (no yet) here https://github.com/dubhater/vapoursynth-degrainmedian the VS port
15 - TDeint (done by pinterf (https://github.com/pinterf/TIVTC))

plugins that has VS ports but no HBD:-
1 - scxvid (there are no x64 in avs yet)
2 - hqdn3d (there are avs port but with 16bit hack)
3 - ssiq (there are no x64 in avs yet)

and there are some filters seems has no VS ports

1 - VariableBlur (it was planed by tp7 (https://forum.doom9.org/showthread.php?p=1658610&highlight=VariableBlur#post1658610))
2 - frfun7 (useful for Dot Crawl Removal, used in DDComb)
3 - GradFun2db (maybe it can be replaced with f3kdb?)
4 - LGhost (HolyWu Recently did the VS port, avs+ done by Asd (https://github.com/Asd-g/AviSynthPlus-vsLGhost))

so a lot of those are done now by Asd here https://github.com/Asd-g?tab=repositories and there are some that I didn't mention like https://github.com/Asd-g/AviSynth-CAS and https://github.com/Asd-g/AviSynth-FillBorders and https://github.com/Asd-g/AviSynth-vsTMM and https://github.com/Asd-g/AviSynth-BWDIF and https://github.com/Asd-g/AviSynth-JincResize and https://github.com/Asd-g/RawSource_2.6x and https://github.com/Asd-g/MTCombMask and https://github.com/Asd-g/ReduceFlicker and there are many others!

note: the ones that has "vs" in their names because they are not same as old avs one (Missing things from avs old one or different parameters)

kedautinh12

20th September 2020, 02:31

I think FFT3dGPU (no HBD yet) and add more plugins work very good but only have in vapoursynth: BM3D (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-BM3D) and CUDA-accelerated implementation of BM3D image denoising method (https://github.com/DawyD/bm3d-gpu), fvsfunc (https://github.com/Irrational-Encoding-Wizardry/fvsfunc) have AutoDeblock function (trying to detect blocked frames and won’t touch non-blocked frames. It’s recommended for MPEG2 input, but also works with h264 input. You can use it on the whole clip)

real.finder

20th September 2020, 03:38

kedautinh12

20th September 2020, 06:07

seems there are AutoDeblock2 for avs but I can't find it, it will be easier for me to update it instead of read python code and back port it

I only find out here related avisynh
https://pastebin.com/JqBvNp32

Edit: Script related
vweakdeblock = Deblock_QED().dfttest(sigma=1 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=50,thsadc=25,refinemotion=true)
weakdeblock = Deblock_QED().dfttest(sigma=5 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=100,thsadc=50,refinemotion=true)
mediumdeblock = Deblock_QED().dfttest(sigma=9 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=150,thsadc=75,refinemotion=true)
strongdeblock = Deblock_QED().dfttest(sigma=13,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=200,thsadc=100,refinemotion=true)
vstrongdeblock = Deblock_QED().dfttest(sigma=17,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=200,thsadc=100,refinemotion=true)

real.finder

22nd September 2020, 02:06

I only find out here related avisynh
https://pastebin.com/JqBvNp32

Edit: Script related
vweakdeblock = Deblock_QED().dfttest(sigma=1 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=50,thsadc=25,refinemotion=true)
weakdeblock = Deblock_QED().dfttest(sigma=5 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=100,thsadc=50,refinemotion=true)
mediumdeblock = Deblock_QED().dfttest(sigma=9 ,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=150,thsadc=75,refinemotion=true)
strongdeblock = Deblock_QED().dfttest(sigma=13,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=200,thsadc=100,refinemotion=true)
vstrongdeblock = Deblock_QED().dfttest(sigma=17,y=true,u=true,v=true,tbsize=1).smdegrain(blksize=16,tr=2,pel=1,subpixel=3,prefilter=2,thsad=200,thsadc=100,refinemotion=true)

I got AutoDeblock2 from a friend, and did add HBD, you can got it from Thread in my signature

kedautinh12

22nd September 2020, 03:59

Thanks

tormento

22nd September 2020, 11:14

I did update those old posts with this
There is this thread (https://forum.doom9.org/showthread.php?p=1655989), why don't update that instead of polluting an AVS+ developement thread?

Please moderator, move all the pertinent messages there.

real.finder

22nd September 2020, 17:11

There is this thread (https://forum.doom9.org/showthread.php?p=1655989), why don't update that instead of polluting an AVS+ developement thread?

Please moderator, move all the pertinent messages there.

it was start from

To whom redact AviSynth+ Wiki: what about starting to divide plugins into AVS supported interface versions?

It could be easier for programmers to start a revision of the missing plugins.

tormento

24th September 2020, 11:38

it was start from
Nonsense. I was asking about Wiki.

real.finder

24th September 2020, 15:39

Nonsense. I was asking about Wiki.

if so, then why you didn't say so when I reply using your post https://forum.doom9.org/showthread.php?p=1910354#post1910354 ? Also there is this thread https://forum.doom9.org/showthread.php?t=168012

and this one?

Real men code AVS+ plugins.

So go back to work. :)

szabi

9th October 2020, 15:11

Hi

I tried to install AviSynthPlus_3.6.1_20200619.exe but unsuccessful due to Microsoft Defender SmartScreen deny it.
I got the same when attempt to install AviSynthPlus_3.6.1_20200619_vcredist.exe.
Any suggestion would be welcomed.

Regards
szabi

manolito

9th October 2020, 20:28

You can disable SmartScreen with this RegEdit script:

DisableSmartScreen.reg
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
"EnableSmartScreen"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer]
"SmartScreenEnabled"="Off"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\PhishingFilter]
"EnabledV9"=dword:00000000

wonkey_monkey

10th October 2020, 00:52

Or just click on "More info" and then "Run anyway."

szabi

10th October 2020, 09:41

Or just click on "More info" and then "Run anyway."

It helped, thanks.

FranceBB

12th October 2020, 13:04

I wanted to check whether input is 411 or not, but if I try "clp.is411" where "clp" is my source, it says that there's no function called "is411" however there are functions called Is420, Is422, Is444.
What about 411?

EDIT: never mind, it's clp.IsYV411, I just found out.

StainlessS

12th October 2020, 13:12

There are a range of depths for 422, 420 and 444, but only YV411 at 8 bit.
Usage of YV411 is not to be 'encouraged', and only 8 bit IsYV411() is implemented.

EDIT: OK, I see above that you got it.

FranceBB

12th October 2020, 13:49

There are a range of depths for 422, 420 and 444, but only YV411 at 8 bit.
Usage of YV411 is not to be 'encouraged', and only 8 bit IsYV411() is implemented.

EDIT: OK, I see above that you got it.

Well yeah, it's just to make a script I'm writing bullet-proof.
What about 410, though?
Is410 and IsYV410 don't seem to work...

real.finder

12th October 2020, 23:19

real.finder

13th October 2020, 11:01

is frame properties only for video? (I think) but what about the audio?

StainlessS

13th October 2020, 11:42

is frame properties only for video? (I think) but what about the audio?

I know nowt about this, but how would one attach properties to audio ?
By entire Clip only ???, Sample ??? [lots & lots of properties].

EDIT:

What about 410, though?
Is410 and IsYV410 don't seem to work...
What is 410 ? ( an Avs colorspace ??? )

FranceBB

13th October 2020, 12:02

I know nowt about this, but how would one attach properties to audio ?
By entire Clip only ???, Sample ??? [lots & lots of properties].

EDIT:

What is 410 ? ( an Avs colorspace ??? )

Well, it seems so, according to the Wiki at least: http://avisynth.nl/index.php/Avisynthplus_color_formats

Group: YUV410, Pixel Type: YUV9
although I never really heard of such a thing before

StainlessS

13th October 2020, 12:11

YUV9, Is read only, ie converted to something else on input [EDIT: by source filter].

I think is 1 chroma sample per 3 luma samples, both horizontally and vertically.
Will maybe need be mod 6 (or maybe mod 12) both H & V.
EDIT: Wrong, See Later. END EDIT:

Even more ghastly than YV411.

EDIT:
You can totally ignore YUV9, only of interest to source filter guys.

wonkey_monkey

13th October 2020, 12:16

YUV9, Is read only, ie converted to something else on input.

I think is 1 chroma sample per 3 luma samples, both horizontally and vertically.
Will maybe need be mod 6 (or maybe mod 12) both H & V.

Even more ghastly than YV411.

Isn't it 1 chroma sample per 8 (4x2) luma samples? That's what the "YUV410" notation suggests. 8+1 = 9, hence YUV9.

There are some 3:1 codecs out there as well, I think, but only in professional equipment as I recall.

StainlessS

13th October 2020, 12:22

Maybe you're right there,
all I know for sure is that its a bloody awful colorspace.

Thanks for keeping an eye on me Wankey_Monkey :)

qyot27

13th October 2020, 12:24

2.6 had a few stubbed color formats that were clearly on the roadmap to be used, but never were (this is the section (https://github.com/jeeb/avisynth/blob/master/src/core/avisynth.h#L420) of 2.6's source of avisynth.h). Some of them were implemented under a different, more standardized naming scheme in Plus (some high bit depth YUV formats were slated, as there were tags like 'YV48', 'YV96', etc.).

YUV9 is not one of these stubs, but I don't know any core filters that use it. It was added at the same time as the stubs, way back in the early CVS commits for 2.6.

StainlessS

13th October 2020, 12:25

Found this

https://www.fourcc.org/pixel-format/yuv-yuv9/

YUV9 yuv pixel format

Intel's web site states that YUV9 is "the color encoding scheme used in Indeo video technology. The YUV9 format stores information in 4x4 pixel blocks. Sixteen bytes of luminance are stored for every 1 byte of chrominance. For example, a 640x480 image will have 307,200 bytes of luminance and 19,200 bytes of chrominance." This sounds exactly the same as YVU9 to me. Anyone know if there is any difference?

Based on: YVU9

EDIT: [EDIT: Wonkey says this is in error]
And this:- https://www.linuxtv.org/downloads/v4l-dvb-apis-old/re31.html

V4L2_PIX_FMT_YVU410, V4L2_PIX_FMT_YUV410 —
Planar formats with ¼ horizontal and vertical chroma resolution, also known as YUV 4:1:0

wonkey_monkey

13th October 2020, 15:16

Found this

EDIT:
And this:- https://www.linuxtv.org/downloads/v4l-dvb-apis-old/re31.html

That page is in error. 4:1:0 is 1/4 horizontal, 1/2 vertical.

You can't express 1/4 horizontal 1/4 vertical in that format.

StainlessS

13th October 2020, 16:28

Thanks Wonkey,
I guess that the main thing to remember is that you cant use em [ie edit directly in] Avs, although that may not apply to VapourSynth.
(Myrsloik has limited tolerance, so expect not editable in VS either)

manolito

15th October 2020, 06:10

After doing more than 30 test conversions using these two AVS+ versions I think I am entitled to a conclusion:

I only use AVS+ 32-bit, my CPU is an Intel Core i5, I have 8 GB of RAM, and I am under Win7-64bit. I use Prefetch=4 in my AVS scripts.

The difference between these two versions is that AviSynth+ 3.6.2-test2b crashes in more than 3 out of 4 instances while AviSynth+ 3.6.2-test1 runs stable in all instances.

I did not find any hints in the version history about changes in the MT modes. The older AviSynth+ 3.6.2-test1 version runs a tiny bit slower than the newer version (about 0.6 FPS slower), but this is no justification for the crashes.

So if this is a regression (maybe only for 32-bit), please fix it before issuing a stable new build...

Cheers
manolito

real.finder

15th October 2020, 06:51

I am using test 2 (but with x64) and didn't find any crash, can you post a simple script using ColorBars that show the crash?

pinterf

20th October 2020, 08:59

New build, Avisynth+ 3.6.2 test3
https://drive.google.com/uc?export=download&id=1Ow2g4H16B3PvXWiD9VGXkJSQk7mBaxb5

Fixing a missing rounding in 8-16 bits GeneralConvolution, now it matches with mt_convolution, and the (8 bit converted) 32bit float version of GeneralConvolution

FranceBB

21st October 2020, 11:15

Hi Ferenc.
First of all, thank you.
Second of all, I noticed a slightly different behavior in Avisynth between bit depths.

If I try to apply Dithering from an high bit depth source to a lower bit depth source like this, it works:

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(10)
ConvertBits(bits=8, dither=1)

and that's fine.

If I try to apply dithering to 8bit starting from an 8bit source, it clearly outputs an error:

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(bits=8, dither=1)

Floyd-S dithering is allowed only for 10-16 bits sources.
And that's fine, it makes sense as we're getting an 8bit input and we're getting an 8bit output so it doesn't make sense to apply dithering and Avisynth returns the proper error.

The behavior changes, though, if I'm trying to do the same thing, like 10bit sources to 10bit sources, 12bit sources to 12bit sources etc:

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(10)
ConvertBits(bits=10, dither=1)

This one, although it's like the 8bit example, it doesn't output any error and just passes through the input.
After all, we're getting a 10bit input and we're trying to get a 10bit output, so it doesn't make sense to apply dithering.

Same goes for 12bit, 14bit, 16bit:

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(12)
ConvertBits(bits=12, dither=1)

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(14)
ConvertBits(bits=14, dither=1)

ColorBars(848, 480, pixel_type="YV12")
ConvertBits(16)
ConvertBits(bits=16, dither=1)

So, all in all, the actual stage of things is:

8bit to 8bit -> Error
10bit to 10bit -> passthrough
12bit to 12bit -> passthrough
14bit to 14bit -> passthrough
16bit to 16bit -> passthrough

16bit to 8bit -> Dithering
16bit to 10bit -> DIthering
16bit to 12bit -> Dithering
16bit to 14bit -> DIthering

14bit to 8bit -> Dithering
14bit to 10bit -> Dithering
14bit to 12bit -> Dithering

12bit to 8bit -> Dithering
12bit to 10bit -> Dithering

10bit to 8bit -> Dithering

So... shouldn't it be either passthrough or error for all the BitsPerComponent==Bits?

The thing can be worked around with something like:

Function ConvertBits_ErrorCatch(clip clp, int "mybits", int "mydither") {

Bpc = clp.BitsPerComponent

Bpc >= 10 ? ConvertBits(clp, bits=mybits, dither=mydither) : ConvertBits(clp, bits=mybits)

}

which passes through the 8bit source if 8bit dithering is specified, just like 10bit to 10bit, 12bit to 12bit, 14bit to 14bit and 16bit to 16bit.

Should we fix the default behavior in the Avisynth code itself and make it the same for all of them?

wonkey_monkey

21st October 2020, 13:04

I'd vote for getting rid of the 8-bit to 8-bit error. Specifying dithering will have no effect, but it's not intrinsically contradictory to the filter's purpose to request it.

which passes through the 8bit source if 8bit dithering is specified

Are you sure that's right? Looks to me like it passes through if the source is 8 bit, and converts to 8 bit, even if mybits = 10/12/14/16.

FranceBB

21st October 2020, 15:16

I'd vote for getting rid of the 8-bit to 8-bit error. Specifying dithering will have no effect, but it's not intrinsically contradictory to the filter's purpose to request it.

+1 for getting rid of the error.

Are you sure that's right? Looks to me like it passes through if the source is 8 bit, and converts to 8 bit, even if mybits = 10/12/14/16.

Oh crap, you're right, I only had going down in mind, but not going up. Fixed with bits=mybits. ;)

rack04

22nd October 2020, 01:20

Hoping to get some help to understand why after "upgrading" to Windows 10 I'm getting the following error with Avisynth+ 3.6.1 release.

AVI Import Filter error: (Unknown) (80040154)

The script I'm using is version() and I'm using VirtualDub64.

Here is what I get using avsmeter:

C:\Program Files (x86)\AVSMeter>avsmeter -avsinfo -log

AVSMeter 3.0.6.0 (x86), (c) Groucho2004, 2012-2020

Error: AVSMeter (x86) cannot load a 64 Bit avisynth.dll.

Reverting back to AviSynthPlus-MT-r2728 everything works.

videoh

22nd October 2020, 02:23

If you are wanting to run all 64-bit then you need Avsmeter64 and the 64-bit Avisynth.dll in system32.

If you are wanting to run all 32-bit then you need Avsmeter and the 32-bit Avisynth.dll in SysWOW64.

You may also have to check your registry paths (not sure how you installed things), as well as verify that no stray Avisynth.dll is laying about getting picked up.

I'm just a noob with this Avisynth stuff but the guys here are aces, and they will probably get you going in no time.

Avsmeter(64) is a great app. Avisynth+ too. Bravo!

rack04

22nd October 2020, 02:25

If you are wanting to run all 64-bit then you need Avsmeter64 and the 64-bit Avisynth.dll in system32.

If you are wanting to run all 32-bit then you need Avsmeter and the 32-bit Avisynth.dll in SysWOW64.

You may also have to check your registry paths, as well as verify that no stray Avisynth.dll is laying about getting picked up.

I'm just a noob with this Avisynth stuff but the guys here are aces, and they will probably get you going in no time.

Avsmeter(64) is a great app. Avisynth+ too. Bravo!

Thanks for the tips. Apparently I switched the 32-bit and 64-bit versions between system32 and SysWOW64 folders. Seems to work now.

videoh

22nd October 2020, 02:26

It's not unusual to make that mistake. Because the names make so much sense. Not!

Good to hear you are rocking and rolling.

zambelli

22nd October 2020, 07:50

I'd vote for getting rid of the 8-bit to 8-bit error. Specifying dithering will have no effect, but it's not intrinsically contradictory to the filter's purpose to request it.

I second this request. Throwing an error on a no-op parameter seems to run counter to how all other internal AviSynth functions are implemented.

pinterf

25th October 2020, 08:42

I agree that it should work in a consistent way across all type of inputs. Probably I forgot to throw an error for N to N bits dithering which was my intention.
And yes, it makes sense to ignore the dithering parameter in this case.

pinterf

25th October 2020, 09:33

There is a huge delay in the online documentation I wanted to do before any further programming.

Can someone help in making sections in Avisynth wiki for all these new 3.6 related functions and features? Or just proposing where to put them?
Let's discuss it.

- Language extensions (such as "function objects")
- Runtime function parameter extensions (ConditionalSelect, ConditionalFilter, ScriptClip, etc.. to wotk with function objects and a new "local" parameter)
- New helper functions - only some of them documented such as http://avisynth.nl/index.php/Internal_functions#SetMaxCPU
e.g. SetCacheMode, Prefetch with new parameter, SetGraphAnalysis, DumpFilterGraph
- Syntax for string constants that allow "escaped" characters (e.g. e"Hello \n")
- the new Format function
- sections for frame properties (concept, helper script functions such as propSet and propGet family, propShow, etc.
- An extension to the SDK section with the new Avisynth+ and V8 interface.

All these are documented only the readme.txt or readme_history.txt (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt) (latter is more detailed).
(Usually I put there in the files-only distribution you can find them there as well)

I would be happy even with empty placeholder sections to fill in later as we have time for that work.

gispos

7th November 2020, 16:32

AviSynth_3.6.2_20200831_test2 32bit
The DirectShowSource.dll from the archive cannot be loaded.

There are no problems with the Dll from Avisynth-3.6.2_20200624_test1

And with ImageSeq.dll there is also an error message
I haven't tested the other dll's.

VirtualDub2 says the VCRUNTIME140D.dll is missing. But VCRuntime 2015 is installed!
Have the default DLLs been changed in the 32bit version?

StainlessS

7th November 2020, 16:40

gispos

7th November 2020, 16:47

OK. But that doesn't change anything. DLL error.

Even worse. The 32bit version 'test2' is incompatible with my 32bit applications that use Avisynth.

There were never any problems with any of the previous versions.

Edit: Just swapped the avisynth.dll to 'test1' and everything works again

manolito

7th November 2020, 17:13

Version 3.6.2 test2 was a not so public debug version, don't use it. In the first post of this thread you can find links to test 2b or better yet to test3 where your issues are solved.

gispos

7th November 2020, 17:16

Version 3.6.2 test2 was a not so public debug version, don't use it. In the first post of this thread you can find links to test 2b or better yet to test3 where your issues are solved.
Yes, thank you. I have just seen, and with 'test3' everything works again.
I'm slowly losing track of things. :)

StainlessS

7th November 2020, 20:24

OK. But that doesn't change anything. DLL error.
Yeh but, if you dont got dat dem runtime debug dll's, then ist kaputski.

StainlessS

9th November 2020, 05:44

Bug in either Avisynth+ 3.6.2 r3320 or VDub2 build 44282 (latest), not sure which but suspect Avs+.

Below plays in PotPlayer OK, but grey frame error in VD2.

Error reading source frame 0: Error decompressing video frame 0: Cannot decompress video frame: the video data is too short(4084800 bytes, should be 5446400).

Looks like VD expecting alpha plane but aint getting it from AVS+. [ 4084800 * 4/3 = 5446400 ]

Demo bug

FIXBUG = False
BITS=16

ColorBars.KillAudio

ConvertToPlanarRGBA
# ConvertToYV24.AddAlphaPlane # Alternative error Src with Alpha

#ConvertBits(Bits=BITS) # Optional to error [errors at all depths]

Info # Show Src Colorspace = RGBA or YUVA444 [RGB or YUV with Alpha]

ConvertToYUV444 # We want 8 bit Planar YUV444 : EDIT: ConvertToYUV444 with alpha sources, converts to YUVA444.
(FIXBUG && HasAlpha) ? RemoveAlphaPlane : NOP # Avoid RGBAP/YUVA444P8 error in VirtualDub2 (OK in PotPlayer but grey screen in VD2 if YUVA)
ConvertBits(Bits=8)

EDIT: Oops, corrected use of BITS, corrected in my test script but forgot to update post.

Intent of last 3 lines above is to convert all colorspaces to 8 bit YUV444 or YUVA444. [RemoveAlphaPlane is just to fix above VD2 Alpha bug]

EDIT: Post prompting the bugrep:- https://forum.doom9.org/showthread.php?p=1927855#post1927855

EDIT: Above Avs+ version was v3.6.2 test2 [r3320], same bug exists with v3.6.2 test3 [r3325].

EDIT:
Lil bit of inconsistancy, there exists ConvertToPlanarRGB and ConvertToPlanarRGBA without and with target alpha channel,
irrespective of source alpha. But ConvertToYUV444 copies alpha if exists in source colorspace.
Should they not work in the same way [ie should there not also be a ConvertToYUVA444 and ConvertToYUV444 without target alpha].

VoodooFX

11th November 2020, 10:58

@pinterf when you'll have a time could you look at bug with Prefetch and Overlay -> https://forum.doom9.org/showthread.php?p=1927882#post1927882

pinterf

11th November 2020, 19:25

Bug in either Avisynth+ 3.6.2 r3320 or VDub2 build 44282 (latest), not sure which but suspect Avs+.

Below plays in PotPlayer OK, but grey frame error in VD2.

For VD it all depends on the negotiated fourCC codes over VfW.

I found that YUVA444P8 is not covered by the format negotiations.
YUVA444P10, P12 and P14 is converted to YUVA444P16 and are negotiated as "Y416" fourcc code.
There are additional formats which are not covered, either because I could not find fourcc codes for them, or could not test it.
A source code comment in main.cpp: // fixme: YUVA420P8, grey 10+ bits such as Y16 are not covered

ConvertToxxxx inconsistencies: yes, there are some. Perhaps historically ConvertToYUV444 was the first one which replaced ConvertToYV24 for all bit depths.
Then came planar RGB, and since there was already an explicite ConvertTo converters for both non-alpha RGB24 and alpha RGB32, I kept that for planar RGB as well.

pinterf

12th November 2020, 12:21

StainlessS

12th November 2020, 13:29

Thanx P, tastes good.

FranceBB

12th November 2020, 16:18

AviSynth+ 3.6.2-test4 (https://drive.google.com/uc?export=download&id=1L6dC0JdSIM5uSOUsuZOI6UcpfPycG0VK)
20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

Wow, thanks for that!
This is probably the first time in 16 years that something I suggest gets implemented in the official master.
It feels like a kinda special moment. :D

https://revpacman.files.wordpress.com/2013/06/celebration-time.jpg

VoodooFX

12th November 2020, 18:04

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment

Perfect, no more borked frames.

gispos

12th November 2020, 20:13

Wow, thanks for that!
This is probably the first time in 16 years that something I suggest gets implemented in the official master.
It feels like a kinda special moment. :D

https://revpacman.files.wordpress.com/2013/06/celebration-time.jpg
Nice. Man should never give up hope. :D

StainlessS

12th November 2020, 23:00

Its like I often hear others say, " That FranceBB, he's 'special' ". :)

manolito

29th November 2020, 08:50

This is a follow-up to this previous post:
https://forum.doom9.org/showthread.php?p=1925852#post1925852

I have to correct myself, the different AVS+ test versions have nothing to do with the random crashes I was experiencing. The magic cure to avoid such crashes is "RequestLinear". I did many many tests, and I can always reproduce these findings.

The source filters are the first filters which need the RequestLinear call (all of them, be it DSS2Mod, FFVideoSource or LWLibavVideoSource). If you experience such random crashes, just put the RequestLinear call right after the source filter.

Other AVS filters also need this. Just the other day I had a source which badly needed an AntiAliasing filter. I used daa3mod.avsi (which uses FFT3DFilter), and this caused reproduceable crashes with MT enabled. Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

Of course this will slow down the conversion speed quite a bit. But the overall speed was still faster than turning off MT altogether.

BTW I always use "RequestLinear(rlim=50, clim=50)" which was proposed by Almosely a while ago. No idea if this makes a difference.

Cheers
manolito

real.finder

29th November 2020, 09:31

Other AVS filters also need this. Just the other day I had a source which badly needed an AntiAliasing filter. I used daa3mod.avsi (which uses FFT3DFilter), and this caused reproduceable crashes with MT enabled. Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

you mean mcdaa3() in daa3mod.avsi not daa3mod() in daa3mod.avsi? since daa3mod() don't use FFT3DFilter

anyway

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="FFT3DFilter(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

https://i.postimg.cc/0z3GNGvn/Annotation-2020-11-29-112844.png (https://postimg.cc/0z3GNGvn)

so yes, FFT3DFilter has problem in mt that already fixed in neo_fft3d but neo_fft3d has it own bugs that not fixed yet, so we need pinterf fix it in old FFT3DFilter since MeteorRain seems no longer active in avs development

edit: dfttest was had same problem, it was fixed by pinterf back then https://github.com/pinterf/dfttest/commit/ebd41672b88addaff4fd2a20956cb6767ae54fb4

pinterf

30th November 2020, 10:10

you mean mcdaa3() in daa3mod.avsi not daa3mod() in daa3mod.avsi? since daa3mod() don't use FFT3DFilter

anyway

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="FFT3DFilter(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

https://i.postimg.cc/0z3GNGvn/Annotation-2020-11-29-112844.png (https://postimg.cc/0z3GNGvn)

so yes, FFT3DFilter has problem in mt that already fixed in neo_fft3d but neo_fft3d has it own bugs that not fixed yet, so we need pinterf fix it in old FFT3DFilter since MeteorRain seems no longer active in avs development

edit: dfttest was had same problem, it was fixed by pinterf back then https://github.com/pinterf/dfttest/commit/ebd41672b88addaff4fd2a20956cb6767ae54fb4
Try this one, please:
https://github.com/pinterf/fft3dfilter/releases/tag/v2.7

real.finder

30th November 2020, 11:56

Try this one, please:
https://github.com/pinterf/fft3dfilter/releases/tag/v2.7

seems work now, thanks! lets see if manolito problem fixed too

manolito

30th November 2020, 12:43

No, it is not fixed...

The new version refuses to work on my ancient WinXP computer, and this means that I will not even try it on my newer Win7 machines. I simply do not want to maintain different plugin versions on my different computers. If it does not work on my oldest WinXP machine then I refuse to use it on my newer computers. Least common denominator, and this is it for me,

If this means that when I use the old Fizick build on one of my newer Win7 machines under the the latest AVS+ version in MT mode and I need to use RequestLinear right afterwards, so be it. FFT3DFilter is slow anyways, and if using RequestLinear makes it even a little bit slower, so what...

pinterf

30th November 2020, 12:57

No, it is not fixed...

The new version refuses to work on my ancient WinXP computer, and this means that I will not even try it on my newer Win7 machines.
Too bad, it was built with the usual XP-friendly settings, I cannot do more precaution for you.

Nuihc88

30th November 2020, 12:58

The magic cure to avoid such crashes is "RequestLinear". [...] Placing a RequestLinear call right after the AntiAliasing filter fixed it for me.

Of course this will slow down the conversion speed quite a bit. But the overall speed was still faster than turning off MT altogether.

This got me curious, would adding extra 'Prefetch(1,4)' lines around problematic filters have the same effect?
Not sure if it would be faster, as i haven't used RequestLinear before; couldn't find any documentation for it either.

Another thing that could increase stability would be adding 'OnCPU(4)' at the end of your script, as it creates a very low latency caching pipeline of some kind.

I'm using OnCPU and multiple Prefetchers on all my scripts these days as both seem to boost real-time performance by reducing buffer underruns.

pinterf

30th November 2020, 13:03

...
I'm using OnCPU and multiple Prefetchers on all my scripts these days as both seem to boost real-time performance by reducing buffer underruns.
I'm not sure OnCPU is doing anything, it was an addition from nekopanda's CPU/CUDA branch which I have not removed entirely.
edit: OnCPU docs in the original repo
https://translate.google.com/translate?sl=ja&tl=en&u=https://github.com/nekopanda/AviSynthPlus/wiki/OnDevice

Groucho2004

30th November 2020, 13:06

...

If this means that when I use the old Fizick build on one of my newer Win7 machines under the the latest AVS+ version in MT mode and I need to use RequestLinear right afterwards, so be it. FFT3DFilter is slow anyways, and if using RequestLinear makes it even a little bit slower, so what...
RequestLinear(rlim=50, clim=50) should not slow down the process that much. I did quite a few tests when I made a standalone version of it.

real.finder

30th November 2020, 13:08

Too bad, it was built with the usual XP-friendly settings, I cannot do more precaution for you.

he use xp on sse (Pentium III) cpu so usual XP-friendly settings is not enough

Nuihc88

30th November 2020, 13:36

I'm not sure OnCPU is doing anything, it was an addition from nekopanda's CPU/CUDA branch which I have not removed entirely.
edit: OnCPU docs in the original repo
https://translate.google.com/translate?sl=ja&tl=en&u=https://github.com/nekopanda/AviSynthPlus/wiki/OnDevice

I can tell from my tests that it's definitely doing something. [Related info] (https://github.com/CrendKing/avisynth_filter/issues/21)

How much of a performance difference there is seems to depend on the CPU load and the difference is not always obvious, but there are times when real-time AviSynth+ filtering under high CPU load consistently causes stuttering from dropped frames without it, but replaying the same clip with OnCPU works fine every time. As to whether the ported function is operating as designed, i have no idea; i just assumed nekopanda's documentation still applies and it does appear to function consistently with what is described there.

pinterf

30th November 2020, 13:39

I can tell from my tests that it's definitely doing something. [Related info] (https://github.com/CrendKing/avisynth_filter/issues/21)

How much of a performance difference there is seems to depend on the CPU load and the difference is not always obvious, but there are times when real-time AviSynth+ filtering under high CPU load consistently causes stuttering from dropped frames without it, but replaying the same clip with OnCPU works fine every time. As to whether the ported function is operating as designed, i have no idea.
Thanks for he clarification.
edit: Have you played with SetCacheMode?
SetCacheMode(0) or SetCacheMode(CACHE_FAST_START) start up time and size balanced mode
SetCacheMode(1) or SetCacheMode(CACHE_OPTIMAL_SIZE) slow start up but optimal speed and cache size

pinterf

30th November 2020, 13:42

he use xp on sse (Pentium III) cpu so usual XP-friendly settings is not enough
True. Even 32 bit version requires sse2.

Nuihc88

30th November 2020, 13:51

edit: Have you played with SetCacheMode?

Yes, for real-time usage i always set SetCacheMode(0) as it makes seek times faster.

pinterf

30th November 2020, 13:56

Yes, for real-time usage i always set SetCacheMode(0) as it makes seek times faster.
O.K. Please keep sharing your experiments.

FranceBB

30th November 2020, 23:17

Just for the records, I tried the XP build on my XP with an SSE4.2 CPU and it works, so it is XP compatible, it's just that it can't work on CPUs that only have SSE.
Just a quick question, though.
I noticed that your new build works with all planar high bit depth, 8bit, 10bit, 12bit, 14bit, 16bit and even 32bit float and I'm really thankful for that, however I noticed an oddity.
When I just call it like this

FFT3DFilter()

on a 32bit float image, it looks ok:

https://i.imgur.com/1qAiuP2.png

however if I try to use the settings I generally use, I get this:

FFT3DFilter(sigma=3.0, beta=1.0, plane=4, bw=16, bh=16, ow=8, oh=8, bt=3, kratio=3.0, sharpen=1.0,
scutoff=0.3, svr=1.0, smin=4.0, smax=30.0, measure=true, interlaced=false, wintype=0, degrid=1.0, dehalo=1.0, hr=2.0, ht=50.0)

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

however, if I try up to 16bit planar with the very same settings, it works fine:

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

I tried to pinpoint what was the cause, and apparently plane=4 is the cause, but why? plane=4 means that it's gonna process both chroma and luma, so it's failing to process chroma correctly 'cause if I set plane=0 (only luma) it works just fine even on a 32bit float input:

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

With plane=1 (U channel of the chroma) 32bit float:

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

with plane=2 (V channel of the chroma) 32bit float:

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

Did you intend to allow users to filter with 32bit float precision so this is a bug or perhaps you didn't want us to use 32bit but you forgot to add an assert to stop us doing that? :P

Thank you in advance and as always your work is very much appreciated! ;)

pinterf

1st December 2020, 09:41

J
Did you intend to allow users to filter with 32bit float precision so this is a bug or perhaps you didn't want us to use 32bit but you forgot to add an assert to stop us doing that? :P

Thank you in advance and as always your work is very much appreciated! ;)
Of course it's a bug.
Check this one (manolito can test is as well)
https://github.com/pinterf/fft3dfilter/releases/tag/v2.8
(fixing and supporting a half-dead plugin version is always fun :) )

pinterf

1st December 2020, 12:07

Updated avisynth wiki:
http://avisynth.nl/index.php/Internal_functions#Runtime_functions_for_frame_properties
http://avisynth.nl/index.php/Internal_functions#SetCacheMode

DTL

1st December 2020, 23:34

It looks like bug in resampler if using YV12 (4:2:0 planar i think):

After performing downsize and converting to YV12 and upsize - the image buffer got buggy blue (blue-yellow) pattern from the bottom. The pattern is unstable at different script running and may changes at different frames. Sometime crash with memory access violation error (sometime display grey frame in virtualdub and write an exception string at the status line).

Script:

ImageReader("01.png")

GaussResize(width/10,height/10,p=15)
ConvertToYV12()

SincResize(width*8,height*8,taps=20)

01.png image is about 1280x720 in size. https://i3.imageban.ru/out/2020/11/25/eb7046de78d66f7e93d8766c55f37c32.png

Buggy output:
https://i1.imageban.ru/out/2020/12/02/185f4f561a2e89ff0682d75fef797d8b.png

It looks bug mostly appear is processing (upsizing) small enough image buffers.

Almost version independent - in Avisynth+ from r2777 to 3.6.1.

pinterf

2nd December 2020, 11:15

It looks like bug in resampler if using YV12 (4:2:0 planar i think):

After performing downsize and converting to YV12 and upsize - the image buffer got buggy blue (blue-yellow) pattern from the bottom. The pattern is unstable at different script running and may changes at different frames. Sometime crash with memory access violation error (sometime display grey frame in virtualdub and write an exception string at the status line).

It looks bug mostly appear is processing (upsizing) small enough image buffers.

Almost version independent - in Avisynth+ from r2777 to 3.6.1.
That blueish haze is there in classic 2.6 as well.
I have cought the crash, it's because of an internal pitch table (which is the size of the actual source height) is too small compared to the filter size

I'm using this simplified script:
SetMaxCPU("none") # crash is more reproducible
BlankClip(1000,320,36, pixel_type="YV24")
SincResize(width,height*2,taps=20) # crash when height<taps*2
#SincResize(width,height*2,taps=18) # works

Now I put there an error message, e.g.:
"Source height (36) is too small for this resizing method, must be minimum of 40"

The artifacts you were seeing at the buttom came from random memory content instead of crashing immediately.

Soulvomit

2nd December 2020, 12:05

I'm trying to load a 16-bit RGB AVI exported by VirtualDub2 but AviSynth says there's no decompressor for "b64a". What should I do? I'm using the latest build.

LigH

2nd December 2020, 13:26

How do you load it with AviSynth? Using AviSource?

Soulvomit

2nd December 2020, 14:07

Yep, just one line in the entire script opened with VirtualDub2: avisource("avi.avi")

StainlessS

2nd December 2020, 14:50

pinterf

2nd December 2020, 15:22

Based on guesswork and :- http://avisynth.nl/index.php/AviSource
(look for b64a)

maybe try
FourCC="BRA[64]" and "G4[0][16]" and "b64a" : EDIT: Not sure if "*" used in linked table should be used or not, maybe try "*BRA[64]" also.
and
Pixel_type="RGB64" and "RGBAP16" [EDIT: colorspace returned to AVS, Interleaved, and then Planar]

But I is really just guessin'.
Try 1st,

AviSource("...", FourCC= "BRA[64]", Pixel_type="RGB64")
AviSource("...", FourCC="*BRA[64]", Pixel_type="RGB64")

BRA[64] means: "BRA" + Chr(64)
For me AviSource works flawlessly for an avi exported as b64a. I have Magicyuv and possibly some other random codecs installed.

StainlessS

2nd December 2020, 15:36

BRA[64] means: "BRA" + Chr(64)
Aha, thats wot that stuff means, eh! [EDIT: I thought Avisource() would do the conversion "BRA[64]" to "BRA@"].

I tried this to create RGBA 64 bit

Colorbars.KillAudio
ConvertToRGB64
Trim(0,-100)
#Info

Then Loaded into VDub2 and saved using Direct Stream Copy [uncompressed] to "Test.avi".
[Full Processing instead of Direct Stream Copy converts to 8 bit with my default Decode Format setting]

MediaInfo (version I'm using shows no bit depth but shows Codec ID (FourCC) as "BRA@".

AviSource(".\Test.avi",FourCC="BRA@")
Info

https://i.postimg.cc/TpD6MGd1/Test2-00.jpg (https://postimg.cc/TpD6MGd1)

EDIT:
This

AviSource(".\Test.avi",FourCC="BRA@",Pixel_Type="RGBAP16")
Info

Produces same RGB64 interleaved, I was expecting planar RGBA 16 .
https://i.postimg.cc/RqQMNvrY/Test3-00.jpg (https://postimg.cc/RqQMNvrY)
EDIT: Arh, looks like Pixel_Type is just a hint to format type, I thought it was requested result colorspace.

EDIT: I've found "b64a" references associated to Apple, and ProRes. b64a "Apple 64-bit ARGB". https://wiki.multimedia.cx/index.php?title=Apple_ProRes

EDIT: https://wiki.multimedia.cx/?title=SheerVideo
Would seem to be a 10 bit (out of 16) format in Sheer Video codec [EDIT: same 10 from 16 in Apple too]
EDIT: Or 'At least 10 bit out of 16 bit', or presumably Bitdepth=Most significant bits of 16.
Pixel Formats

The generic Sheer codec and each of the 6 main specific Sheer codecs support all of the following pixel formats:

RGB[A] 10b:
b64a
b48r
F10k
R10k
S10k
F210
r210
S210

I have Magicyuv and possibly some other random codecs installed.
I dont have MagicYUV. (maybe a really old 8 bit only, somewhere).

StainlessS

2nd December 2020, 17:23

So its not possible to specify RGBP10 style "G3[0][10]" for FourCC, [when contains nul char ie [0]], yes.

blankclip
p = "G3[0][10]"
RT_Subtitle("p=%s : # RGBP10 G3[0][10] r210 R10k",p)
s= "G3" + Chr(0) + Chr(10)
L=strlen(s)
RT_Subtitle("len=%d : s='%s'",L,s,y=1*20)
for(i=1,L) {
Alp=MidStr(s,i,1)
n=Alp.Ord
RT_Subtitle("%d : '%s'",n,Alp,y=(i+2)*20)
}

Chr(10) is Newline and causes printing to move to next line.
https://i.postimg.cc/brNnWmC7/Test-00.jpg (https://postimages.org/)

EDIT: FourCC in code would normally be 32 bit int, whereas in Avs is string which interprets Chr(0) as nul or End-Of-String.
So concatenating (joining) Chr(0) to a string, joins (zero length) empty string "".

EDIT: Or 16 bit

blankclip
p = "G3[0][16]"
RT_Subtitle("p=%s : # RGBP16 G3[0][16]",p)
s= "G3" + Chr(0) + Chr(16)
L=strlen(s)
RT_Subtitle("len=%d : s='%s'",L,s,y=1*20)
for(i=1,L) {
Alp=MidStr(s,i,1)
n=Alp.Ord
RT_Subtitle("%d : '%s'",n,Alp,y=(i+2)*20)
}

Ascii 16 unprintable via RT_subtitle, prints SPACE ' '.
https://i.postimg.cc/4dZwNkNq/Test-00.jpg (https://postimages.org/)

EDIT:
So, you would use "RGBP" as Pixel_type, to retrieve FourCC type "G4[0][16]" and cannot specifiy FourCC.
(Does not seem to be an "RGBAP" Pixel_type, in Docs)

EDIT:
AviSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])
AviFileSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])
OpenDMLSource(string filename [, ...] [, bool "audio", string "pixel_type", string "fourCC", int "vtrack", int "atrack", AVS+ bool "utf8"])

Perhaps could do with variation where FourCC = arg type Int. (Or parse and convert style "G3[0][16]" or "G4[0][16]").

EDIT: To below,
you can try another source filter like ffms2 or lsmash
@Soulvomit, Sorry, I should have suggested that.

poisondeathray

2nd December 2020, 17:26

I'm trying to load a 16-bit RGB AVI exported by VirtualDub2 but AviSynth says there's no decompressor for "b64a". What should I do? I'm using the latest build.

you can try another source filter like ffms2 or lsmash

jpsdr

2nd December 2020, 19:06

Now I put there an error message, e.g.:
"Source height (36) is too small for this resizing method, must be minimum of 40"

I'll wait for the commit...:D

vcmohan

3rd December 2020, 08:00

In case of YUV data like YV12, YV16 I remember to have read that u and V pitches are guaranteed to be equal. In case of YV24 or YUV444 will all 3 planes have identical pitch value?

pinterf

3rd December 2020, 08:05

...
Perhaps could do with variation where FourCC = arg type Int. (Or parse and convert style "G3[0][16]" or "G4[0][16]").

I'm planning to implement the second one.

pinterf

3rd December 2020, 08:15

In case of YUV data like YV12, YV16 I remember to have read that u and V pitches are guaranteed to be equal. In case of YV24 or YUV444 will all 3 planes have identical pitch value?
Yes, they are equal.

StainlessS

4th December 2020, 00:02

I'm planning to implement the second one.
Nice one :)

Yes, they are equal.
Might also be worth mentioning [maybe not for V.C.M, but for others] that pitch can change at every frame, not a clip constant value.

EDIT:

ColorBars.KillAudio
ConvertToYV12

PitchTortureTest
info
Return Last

Function PitchTortureTest(clip c) { # IanB:- https://forum.doom9.org/showthread.php?p=1628159#post1628159
c
A=SelectEvery(4, 0)
B=SelectEvery(4, 1).AddBorders(0,0,8,0).Crop(0,0,-8,0)
C=SelectEvery(4, 2).AddBorders(0,0,16,0).Crop(0,0,-16,0)
D=SelectEvery(4, 3).AddBorders(2,0,22,0).Crop(2,0,-22,0)
Interleave(A,B,C,D)
}

EDIT:

You must use the GetPitch() method on each and every PVideoFrame you get.

StainlessS

4th December 2020, 00:42

# Below all nonsense.
Further to above,
Yes, they are equal.
Is it also possible that something similar to PitchTortureTest() could be applied to any of the color channels, even an alpha channel,
so maybe could argue that above quote should maybe read

they are usually but not guaranteed equal.
so pitch should be ascertained for each frame and for each every channel, or problems could arrise, however infrequently.
Above maybe true (changable) on source frames only, if using NewVideoFrame(), then all frames same channel are equal,
and if YV24 or YV444 then all frames, all channels, are equal.

I think, maybe, perhaps, ???

I usually use SrcPitchU for V channel too, so maybe I amongst many am potentially wrong too.
Discuss.
EDIT:
[Are PitchU and PitchV, internally the same variable ?]
EDIT: Seems that in v2.58 header, VideoFrame there is a variable pitchUV, so single value for both[in v2.58].

EDIT: and in v2.60

class VideoFrame {
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const int pitchUV, row_sizeUV, heightUV;

Am I talkin' crazy above, do say :)

StainlessS

4th December 2020, 01:52

Got my answer to above daft post, can create separate clips where Y clip, U clip, V clip, all have changable pitch,
but in 'merging' the channels together into single clip - we create a NewVideoFrame which guarantees fixed pitch and copies
source channels into the new fixed pitch clip. Doh!

ColorBars.KillAudio
ConvertToYV24
ShowFrameNumber
K=Last.BlankClip(Length=1)

Y=(Last).PitchTortureTest.ExtractY # differently changing pitch for each channel
U=(K+Last).PitchTortureTest.Trim(1,0).ExtractU #
V=(K+K+Last).PitchTortureTest.Trim(2,0).ExtractV #

#Return Y.Info # Y, shows pitch change
#Return U.Info # U as Y, shows pitch change
#Return V.Info # V as Y, shows pitch change

#Return YtoUV(U,V,Y).info # NO pitch change : Creates and copies into NewVideoFrame() where fixed pitch

H=StackHorizontal(Y.Info,U.Info,V.Info)
Return H.BlankClip.StackVertical(H).Info # Top shows final fixed return clip pitch, bot individual changing channel pitchs

########
Function PitchTortureTest(clip c) { # IanB:- https://forum.doom9.org/showthread.php?p=1628159#post1628159
c
A=SelectEvery(4, 0)
B=SelectEvery(4, 1).AddBorders(0,0,8,0).Crop(0,0,-8,0)
C=SelectEvery(4, 2).AddBorders(0,0,16,0).Crop(0,0,-16,0)
D=SelectEvery(4, 3).AddBorders(2,0,22,0).Crop(2,0,-22,0)
Interleave(A,B,C,D)
}

Return H.BlankClip.StackVertical(H).Info
# Top shows final fixed return clip pitch, bot individual changing channel pitchs [Y, U, V]
https://i.postimg.cc/t73wmWjg/Test-00.jpg (https://postimg.cc/t73wmWjg)

NOTE, ExtractY/U/V does not produce fixed pitch clips, it must just drop unused channels from source and not produce NewVideoFrame().
In shown image @ bottom, Y has pitch of 704, as does U, but V has pitch of 640 [before combining with Stackhorizontal].

FranceBB

5th December 2020, 15:10

Thank you, Ferenc! FFT3D is now working just fine even on 32bit float! :D

Fjord

8th December 2020, 12:57

Calling the internal runtime function AverageB() on a high-bit YUV422Pxx clip (within ScriptClip() or FrameEvaluate()) causes immediate crash of the calling app - either AvsPmod or VirtualDub2. The app just disappears without warning or error message. I assume it is an AviSynth+ bug.

I first encountered this on a ProRes 422 HQ clip, but the script below provides a minimal script below for this reproducible crash, using ColorBarsHD().

The related runtime functions AverageR() and AverageG() work fine on YUV422Pxx clips. AverageB() also works fine on YUV444Pxx clips, so this problems is specific to YUV422Pxx pixel formats. I have confirmed the crash on YUV422P10, YUV422P12, YUV422P16 and YUV422PS clips.

I am using AviSynth+ 3.5 (r3043, master, x86_64), with both AvsPmod v2.6.5.0 (Windows (x86-64) and VirtualDub2 build 44282, on Win10 x64.

Minimal reproducible script:

# This script crashes AviSynth+ 3.5 (r3043)
#
ColorBarsHD ( 1024, 576, pixel_type="YUV444P10" ) # 10-bit
ConvertToYUV422() # change clip to YUV422P10
# show the PixelType
Subtitle("PixelType=" + last.PixelType, Align=9, Size=40)
# show the average value of Blue on each frame (causes crash)
ScriptClip("""
Subtitle("AverageB=" + String(AverageB()), align=7, size=40)
""")
Return last
You can comment out the line with ConvertToYUV422() to see that AverageB() works ok on YUV444P10. I am not familiar with debugging procedures in these apps, so I hope someone can trace where the problem arises.

pinterf

8th December 2020, 13:27

pinterf

8th December 2020, 16:02

EDIT: use test6
Avisynth+ 3.6.2 test6 (20201210) (https://drive.google.com/uc?export=download&id=1ZdSd_TAPRmdkFGerLaIrDVrsIE8pUBGx)

20201210 3.6.2-test6
-----------------------
- AviSource: fix test5 regression which refused handling old formats like YV24

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

kedautinh12

8th December 2020, 16:08

Thanks

Groucho2004

8th December 2020, 16:42

Avisynth+ 3.6.2.-test5 (20201208) (https://drive.google.com/uc?export=download&id=1qQT_VV5wnuCTfClcJ57-eUO0NATHR2KD)
I added this build to the Universal Installer. Should be handy to switch between versions for testing.

StainlessS

8th December 2020, 18:42

Thankyou P & G.

Fjord

8th December 2020, 18:49

This is a bug, because this AverageX family is not checked against format mismatch errors. ... it will ... cause memory overread --> exception. If not, it's only pure luck.

Thanks. Oops. I had "luck" with AverageR and AverageG, so I "forgot" that it didn't make sense to calculate R, G & B stats on a YUV clip in the first place. :rolleyes:
I will convert YUV to RGB [ConvertToPlanarRGB()] before using AverageR/G/B.

LigH

9th December 2020, 08:49

Thankyou P & G.

Procter & Gamble?! :p

StainlessS

9th December 2020, 19:41

Parental & Guidance, or Propylene & Glycol (as opposed to V & G).

gispos

9th December 2020, 23:47

Avisynth+ 3.6.2.-test5 (20201208) (https://drive.google.com/uc?export=download&id=1qQT_VV5wnuCTfClcJ57-eUO0NATHR2KD)

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

Can't open an avisynth script with AviSource. What has changed?

https://i.postimg.cc/W1dHsFJL/Avi-Source-Error.jpg (https://postimages.org/)

StainlessS

10th December 2020, 02:56

Can't open an avisynth script with AviSource. What has changed?
https://i.postimg.cc/W1dHsFJL/Avi-Source-Error.jpg (https://postimages.org/)

Confirmed.
Worked OK in all + versions [prior to 3.6.2 test 5] in latest Groucho2004 Universal Avisynth Installer whotsit.

Import() works as it should though, was quite a surprise to me when I originally found that
AviSource loaded Avs scripts, so I'm no longer surprised any more :)

pinterf

10th December 2020, 07:30

Confirmed.
Worked OK in all + versions [prior to 3.6.2 test 5] in latest Groucho2004 Universal Avisynth Installer whotsit.

Import() works as it should though, was quite a surprise to me when I originally found that
AviSource loaded Avs scripts, so I'm no longer surprised any more :)
Checking...

pinterf

10th December 2020, 08:26

Checking...
oops, poor old formats like YV24 were forgotten in test5, fix is on the way

pinterf

10th December 2020, 08:41

New build.
Avisynth+ 3.6.2 test6 (20201210) (https://drive.google.com/uc?export=download&id=1ZdSd_TAPRmdkFGerLaIrDVrsIE8pUBGx)

20201210 3.6.2-test6
-----------------------
- AviSource: fix test5 regression which refused handling old formats like YV24

20201208 3.6.2-test5
-----------------------
- Resizers: throw error on too small dimensions vs. taps
- Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
- Overlay: allow 4:1:1 input
- Overlay: fix crash when mask is YUV411 and greymask=false
- Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
- RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
- AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
- AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
- AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
- Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
- Add: AverageA
- New: Average...: allow YUY2, RGB24/32/48/64 inputs

20201112 3.6.2-test4
--------------------
- Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
- Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case

kedautinh12

10th December 2020, 14:20

Thanks

StainlessS

10th December 2020, 19:03

Yo da' man, tanks :)

Soulvomit

12th December 2020, 21:52

@Soulvomit, Sorry, I should have suggested that.you can try another source filter like ffms2 or lsmashThanks, friends. ffms2 did it. :)

Ceppo

20th December 2020, 18:38

I was thinking it would be nice to have a block-based TemporalSoften to have an MDegrain with no motion search. Also the sum of square difference would be nice.

qyot27

11th January 2021, 23:16

AviSynth+ 3.7.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)

Haiku support
PowerPC support
Support for building the core as a static library (mcmtroffaes)
Fixes for MinGW-w64 compilation
Shibatch, TimeStretch, and ImageSeq GCC build support
Shibatch, TimeStretch, and ImageSeq non-Windows support
Fix: AddBorders did not pass frame properties
Fix: propSet, propDelete and propClearAll not to ruin visibility of variables
(property read functions are still kept being runtime only)
AviSource: fix test5 regression which refused handling old formats like YV24
Resizers: throw error on too small dimensions vs. taps
Add ShowCRC32 debug filter. Parameters are the same as in ShowFrameNumber
Overlay: allow 4:1:1 input
Overlay: fix crash when mask is YUV411 and greymask=false
Overlay: may work quicker, most input/overlay/mask/output clip format conversions moved to filter constructor
RemoveAlphaPlane: do nothing on YUY2 instead of throwing an error message
AviSource: support non-printing characters in fourCC code: allow [number] style, e.g. G3[0][16]
AviSource: add Y410 (YUVA444P10) format support. Allow 'Y410' pixel_type hints.
AviSource: decode b64a, b48r, v210, P210, P010, P016, P216, v410, Y416, r210, R10k, v308, v408, Y410 fourCCs natively.
Fix: Average...: check for valid colorspace (e.g. no AverageB for a YUV clip)
Add: AverageA
New: Average...: allow YUY2, RGB24/32/48/64 inputs
Fix: Overlay: Actual frame of a mask clip would be freed up too early in MT environment
Fix: ConvertBits to ignore dither parameter instead of throwing error, in a 8 to 8 bit case
Fix: GeneralConvolution missing internal rounding on 8-16 bit formats
support for Win10 long file path option
project: Improve inclusion of the ghc filesystem helper library
project: Add a GitHub action workflow
posix: fix crash when autoloading imports
internally refactored ConvertAudio
ConvertBits(8): fix dither=1 (floyd) for RGB48/RGB64
Fix: Blur right side garbage: 16 bit+AVX2+non mod32 width
Fix: check fn signature with implicite "last" first (3.6 regression)
Fix: function parameters provided as arrays (e.g. GrunT callback of WriteFileIf)
Fix: ConvertBits (YUV): proper rounding when bit depth is reduced and origin is 10-16 bits
(added rounder before bit-shift)
New: Histogram("color2") to support 10+ bits.
Allow bits=x (x=8,9,10,11,12) parameter for this kind of histogram as well.

Due to the addition of support for Haiku, PowerPC, and building the core as a static library, the version needed to be bumped. Otherwise, you can consider this equivalent to a final release of 3.6.2, as those things largely don't affect Windows (although another big part of this was fixing up MinGW-w64/GCC build support).

StainlessS

12th January 2021, 01:36

Awesome, thanks very much you guys, you're the best.

pinterf

12th January 2021, 07:48

Happy New Release! Thank you, qyot27.

manolito

12th January 2021, 08:16

AviSynth+ 3.7.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases)
Otherwise, you can consider this equivalent to a final release of 3.6.2, as those things largely don't affect Windows

Does this mean that there are no real differences or fixes compared to the latest pinterf 3.6.2 test 6 version?

Since I am Windows only do I loose anything if I stick to the latest pinterf test 6 version?

qyot27

12th January 2021, 09:16

r0lZ

12th January 2021, 10:44

Good job ! Huge thanks !

Losko

12th January 2021, 10:51

Great release, THANK YOU :thanks:

wonkey_monkey

12th January 2021, 12:00

[list] Haiku support

Oh, Haiku support?
I have no clue what that is
But it sounds clever

ChaosKing

12th January 2021, 12:18

It's the open source version of BeOS https://en.wikipedia.org/wiki/BeOS

FranceBB

12th January 2021, 14:29

There were a couple fixes related to passing around frame properties and SSE2, and fixing a segfault-on-exit issue with SSRC (although that *might* have only affected Linux in the first place). Most of the rest after test 6 was various build system tweaks/cleanup and the non-Windows features.

Got it. I'll update from Test 6 to the stable release anyway, just to make sure. :)

New: Histogram("color2") to support 10+ bits.

And by the way, thank for this!! :D

ryrynz

12th January 2021, 22:26

It's the open source version of BeOS https://en.wikipedia.org/wiki/BeOS

That was a Haiku, I was going to do something similar with StainlessS's post but it took too long to make something good so I didn't :P

Boulder

16th January 2021, 19:46

FranceBB has an interesting point here: https://forum.doom9.org/showthread.php?p=1933580#post1933580.

How should one handle chroma location? In UHD sources, it's type 2 but in Avisynth, you handle it as type 1 as far as I've understood. The question is: can something be done about it in Avisynth, and if not, should one tell the encoder that the source actually is type 1?

Disclaimer: I'm blind enough to never have noticed the issue. I do recall some earlier discussion regarding issues with red colour and x265 encodes, but I think it never really came to any conclusion.

FranceBB

16th January 2021, 23:23

poisondeathray

17th January 2021, 04:19

qyot27

17th January 2021, 07:41

I think ffms2 and Lwlibav convert the chroma location from Type2 to the old MPEG-2 version, so from:

X X
X X

(where the Chroma sample sits right on top of the top left Luma sample)

to

X X
c
X X

(where X is Luma and "c" is Chroma)

therefore, specifying --chromaloc 2 is wrong if your input is an Avisynth Script.
Ever since I began encoding with x265 years ago, I used FFmpeg to open the AVS Script, convert the chroma location back to Type 2 and then pipe to x265 to encode the video like so:

ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m -

Still, I'd love to see Avisynth and its plugin be able to support the "new" chroma location, just like it happened with the MPEG-1 variant and the MPEG-2 variant.
If you think about this, though, so far plugins generally assumed that the chroma location is MPEG-2 and you have to manually specify if it's MPEG-1 as they don't get it automatically, wouldn't it be better to somehow make the indexer pass this information through so that plugins will be aware of this? I know that someone has to be aware of his own source, but still, prevention is better than cure (TL;DR sometimes it's better to babysit the users a bit).

Would that be this?
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/include/avisynth.h#L745

That's been there a loooooong time; way back during the 2.6 alphas. But I can't seem to find a part of the callable API that can query it (unless that's what PlanarChromaAlignment is in avisynth.cpp, but that seems like just a placeholder). It's not there at all in avisynth_c.h/avisynth_c.cpp.

Finding and fleshing out stuff like that probably should be a priority for the next API bump. I've started a discussion on Github about it, as a brainstorming/tracker of API stuff to consider:
https://github.com/AviSynth/AviSynthPlus/discussions/206

Boulder

17th January 2021, 12:03

avsresize has chromaloc_op, so you change from one to another

- chromaloc_op (default left):
```
"left" ("mpeg2") (0),
"center" ("jpeg", "mpeg1") (1),
"top_left" (2),
"top" (3),
"bottom_left" (4),
"bottom" (5)

Format is" `"[locS]=>[locD]"`
Example JPEG to MPEG2: `"center=>left"`

Thank you, I didn't remember avsresize at all :)

So it basically means that I should use z_ConvertFormat(chromaloc_op="top_left=>mpeg2") right after loading the source with DGSource and z_ConvertFormat(chromaloc_op="mpeg2=>top_left") at the end of the filtering chain? I could change the parameter in x265 but I think it's safer to use the value that is considered standard.

StvG

17th January 2021, 19:48

I think ffms2 and Lwlibav convert the chroma location from Type2 to the old MPEG-2 version, so from:...
Source filters doesn't change the chroma location. They are aware of the different chroma locations (ffmpeg is aware of).

Thank you, I didn't remember avsresize at all :)

So it basically means that I should use z_ConvertFormat(chromaloc_op="top_left=>mpeg2") right after loading the source with DGSource and z_ConvertFormat(chromaloc_op="mpeg2=>top_left") at the end of the filtering chain? I could change the parameter in x265 but I think it's safer to use the value that is considered standard.
If you're using filters that doesn't recognize chroma location top_left you can use what you wrote.
If you're using filters that are aware of chroma location top_left (I currently know only avsresize with frame properties) then you can omit these conversions.

Kogarou

23rd January 2021, 22:35

Does avs+ 3.7 have support for the CUDA filters made for the nekopanda fork? I noticed some of the fork's code got merged into mainline avs+ almost a year ago, yet it seems it doesn't work at all.
As one guy said before:
So I was experimenting with the CUDA version of Avisynth+ which was merged into the main Avisynth+ branch. It seems that it results in a memory leak. While using MeGUI, it gets stuck on the pre-processing phase, then the memory usage goes through the roof (99% RAM usage with 16 GB installed) before the app locks up.

(...)

The same script run under the Nekopanda version of Avisynth (r2827) is able to run just fine. The memory usage was around 1 GB or so on average.

IIRC I tried to do the same thing under 3.6.1, with the same result as this guy. Is there anything that needs to be changed for these scripts to run, or is the merge still a WIP? :(

pinterf

24th January 2021, 10:20

Does avs+ 3.7 have support for the CUDA filters made for the nekopanda fork? I noticed some of the fork's code got merged into mainline avs+ almost a year ago, yet it seems it doesn't work at all.
As one guy said before:

IIRC I tried to do the same thing under 3.6.1, with the same result as this guy. Is there anything that needs to be changed for these scripts to run, or is the merge still a WIP? :(
Present Avisynth+ does not support CUDA. Since the existance of nekopanda fork was hidden (at least for me) for years, the two source base went apart and were different enough that even the integration of multithreading changes took me more than a month. Changes were so widespread that finally I was not able to import the fixes alone but I had to pull almost everything.
All I could do that I did not ruin and did not omit the existing CUDA parts from the source when I was porting back multithreading fixes and the new language elements (e.g. functions objects) from nekopanda fork.
So the code is there (I hope). But CUDA option is not enabled. I was trying to keep them behind #ifdef ENABLE_CUDA, thus never tested.
Nekopanda fork has special Avisynth interface. Avisynth+ interface was heavily changed on my side as well. Those cuda-special plugins would require complete rebuild after the necessary source changes (interface usage) as well.

EDIT: i was able to build Avisynth+ with the CUDA option, but it is only a necessary prequisite. I had a look at the supporting filters (https://github.com/nekopanda/AviSynthCUDAFilters) as well. Sources must be updated. Rebuild was not a straightforward task, starting with the easiest problem that since 2018 CUDA SDK stepped to 11.2 from 8.0, and of course using again the "classic" avisynth+ headers. Still there are filters with build errors which I'm gonna fix later this week, just for curiosity.

patul

25th January 2021, 01:55

Wow pinterf, you never cease to amaze me, I wish I have a small fraction of your skills, curiosity, adaptability and the ability to read other people's code with ease.. I was a programmer myself during my younger days, but no where near the required level even just to understand the code.

Thank you for keep doing what you do best.

pinterf

27th January 2021, 11:55

I have encountered a serious obstacle.
On my main PC I have no NVidia CUDA, only an Intel HD630. My other PC has a historical hardware. Processor-wise it is an Intel i7-860 which would be O.K. but the video card is a GeForce GTX460 which is simply too old. NVidia do not make new drivers for it, End Of Life was 2018. The latest CUDA SDK which can produce code for GTX460 is version 9.1. (now NVidia have v11.2). But unfortunately CUDA 9.1 SDK is incompatible with VS2019, neither could I make it work with a VS2017 (consistent 0xC0000005 during the build process). So this project and my curiousity is stopped here, since I do not want to invest into a GT 1030 level card which I think is a minimum even for this fun project. The other choice I was consireding was a GT 730 since it is a bit cheaper - but still over my budget - I dropped the idea since it is slower than my old 9 years old card.

wonkey_monkey

27th January 2021, 12:27

Any consideration for OpenCL? Open standard, supported on more hardware, supported by Nvidia via CUDA...

pinterf

27th January 2021, 12:31

Any consideration for OpenCL? Open standard, supported on more hardware, supported by Nvidia via CUDA...
No-no. I just want to look at what Nekopanda created some years ago. And as a side effect, to look into another new technology.

StainlessS

27th January 2021, 13:30

2nd user NVidia might be worth consideration.
Here a bunch o' guys I use all the time.
[Known in the UK as CEX, branches in several other countries, site domain Webuy.com ] https://uk.webuy.com/search?stext=NVidia&sortBy=sellprice&sortOrder=asc
Many of those are Out-Of-Stock, but give and idea of what might be out there and the gelt involved.
You can click on (RHS) In Stock Online, AND In Stock In Store - to see what is currently available.
EDIT: Above sorted in ascending order by price.

There are other Used Part sellers too of course.

Or maybe someone has a 'spare card' gathering dust.

FranceBB

27th January 2021, 13:42

Ask the community? I'm sure someone must have a spare old NVIDIA card somewhere to give you and I'm sure they'll be happy to give it to you if we're gonna have CUDA support.
I do have an old card with CUDA, but it's buried somewhere at my parents place, so more than 160 miles from where I live and I'm not planning to get there anytime soon considering that we're still in the middle of a pandemic.
Anyway, I'm sure there's gonna be someone with an NVIDIA card willing to help you (and therefore the entire community) out.
I mean, people give gamers those kind of things for silly stuff, so they might give you, the last real Avisynth developer, a card for these far more serious stuff!

StainlessS

27th January 2021, 14:00

I hear that there is a pretty good postal service in Deutschland, if only you knew where it was. [EDIT: The card, not Deutschland]

pinterf

27th January 2021, 14:05

Haha, or I'm gonna ask my son for his 1660Super OC. University tasks, Fortnite and Ethereum mining can wait :) I bought him a PC with this card in October, video card prices have almost doubled since then.
EDIT 1030 is on the way.

FranceBB

27th January 2021, 16:29

I hear that there is a pretty good postal service in Deutschland, if only you knew where it was. [EDIT: The card, not Deutschland]

The conversation would be like:

"Mum, do you know where the GPU of my old computer is?"

- What is a GPU?

And that would be the deal breaker xD

Haha, or I'm gonna ask my son for his 1660Super OC. University tasks, Fortnite and Ethereum mining can wait :)

"University tasks"... suuuuure... That's how I used to get my parents buying me stuff back in the days hahahaha
Sadly, it doesn't work anymore since I'm a "grown man with a job who lives on his own and should buy things himself" xD

Still, with a living legend as Ferenc as a father, I wonder why that young lad isn't interested in encoding... :(

1030 is on the way.

:D yay, we're gonna have CUDA!!

https://media1.tenor.com/images/7bafc4dc0036792b32a5e5aa6c5ac9ff/tenor.gif?itemid=7241283

StainlessS

27th January 2021, 16:41

yay, we're gonna have CUDA!!

"It ain't necessarily so ...":- https://www.youtube.com/watch?v=vMYM75JFrIY

No-no. I just want to look at what Nekopanda created some years ago. And as a side effect, to look into another new technology.

pinterf

27th January 2021, 17:15

Still, with a living legend as Ferenc as a father, I wonder why that young lad isn't interested in encoding... :(

Oh, there are hundreds of similarly interesting topics at Computer Science Engineering. Two of them are studying there. I wish I were young again, now the only thing I was able to help in was C/C++ (but finally I was lost there as well :) )

feisty2

28th January 2021, 08:33

now the only thing I was able to help in was C/C++

you may help with introductory programming language theory if you know C++ reasonably well. C++'s type system is powerful enough to express all 3 extensions to the simply typed lambda calculus on the lambda cube. It even allows you to play with some undecidable problems like type inference for polymorphic recursive functions since the type system itself is Turing complete.

feisty2

28th January 2021, 10:09

I wonder why that young lad isn't interested in encoding...

because writing video processing scripts is not a terminal interest. The initial interest in stuff like avisynth shifts over time, that's how curiosity works, once you get the hang of something, your interest moves on to a more fundamental topic cuz you wanna know how things work under the hood, you wanna know why. this process won't stop until your interest reaches the boundary of human knowledge.

in the case of avisynth, there're many possible paths how your interest may evolve. one may wonder why applying a certain avisynth filter produces certain "effects" -> image processing algorithms -> low level computer vision -> applied machine learning / information theory -> theoretical machine learning / information geometry -> … and the chain goes on. you may have obtained a PhD in a seemingly unrelated field long before your interest stabilizes.

pinterf

28th January 2021, 12:07

The biggest difference between me and the youngs that they learn things on courses, in didactic units. I follow a heuristic method of learning, only random fragments of the actual problem are reaching me. I'm solving these problems after seeing examples which I'm trying to understand with more or less success.

Having this new GT1030 toy made the progress a bit quicker than having no CUDA at all :) I have made Nekopanda's CUDA things work with my actual Avisynth+ (work in progress). KTGMC is 4 timer quicker than the similarly parameterized QTGMC, though their output is not identical. Note that KTGMC is not a replacement for QTGMC, it has much less working parameters. So stay tuned.

FranceBB

28th January 2021, 12:22

in the case of avisynth, there're many possible paths how your interest may evolve. one may wonder why applying a certain avisynth filter produces certain "effects" -> image processing algorithms -> low level computer vision -> applied machine learning / information theory -> theoretical machine learning / information geometry -> … and the chain goes on. you may have obtained a PhD in a seemingly unrelated field long before your interest stabilizes.

True. In my case, Avisynth led me to understand more of what was behind encoding, so working in the frequency domain, working with transforms, so Z-Transform, Laplace Transform, Fourier Transform, Discrete Cosine Transform, Wavelet Transform, Hadamard Transform, Karnhunen-Loeve Transform etc. The more I knew about this world, the more I wanted to know, so my passion shifted from merely applying filters in Avisynth to Linear Algebra to Control Systems to Digital Signal Processing, but always related to encoding. I mean, in the end, it's my day-by-day job, it's my passion and it's what I wanted to do when I began studying at university and what I'm still doing (and what I plan to keep doing in the future). I'm still doing a master degree in Computer Science Engineering while I'm working for Sky (in Europe, unlike in the U.S, you don't "pick" master degree vs PhD, you first get the master degree, THEN you get your PhD) and I'm studying lots of unrelated things which are indeed interesting and might turn out to be useful, but that I never thought I would have been studying. I mean, I'm never going to use Verilog or VHDL or design rugged devices, directly control FPGAs etc. I mean, it was interesting, but not what I wanted to see and study...

Having this new GT1030 toy made the progress a bit quicker than having no CUDA at all :) I have made Nekopanda's CUDA things work with my actual Avisynth+ (work in progress). KTGMC is 4 timer quicker than the similarly parameterized QTGMC, though their output is not identical. Note that KTGMC is not a replacement for QTGMC, it has much less working parameters. So stay tuned.

That's really cool! :D

tormento

29th January 2021, 13:24

so more than 160 miles from where I live
When a european man uses imperial units, a CUDA core of his video card core dies. :p

tormento

29th January 2021, 13:27

Any consideration for OpenCL?
OpenCL is a nice standard but benchmark shows that CUDA is way faster and there is a really strong support with compilers and from Nvidia.

wonkey_monkey

29th January 2021, 16:57

and there is a really strong support with compilers and from Nvidia.

But ONLY from Nvidia. No Nvidia? No CUDA.

videoh

29th January 2021, 17:23

Stupid post of the day. So what? No Microsoft no Windows. No Apple no iPhone. You get the drift.

wonkey_monkey

29th January 2021, 21:34

No, I don't get the drift, so maybe you didn't get the drift in the first place. If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. OpenCL, if I understand correctly is practically ubiquitous.

tormento

29th January 2021, 21:39

OpenCL, if I understand correctly is practically ubiquitous.
Then much better Vulkan than OpenCL.

FranceBB

29th January 2021, 21:55

When a european man uses imperial units, a CUDA core of his video card core dies. :p

Eheheh... Doom9, where impossible things happen. ;)
(Honestly, though, I hope all the cuda core in my Quadro P4000 are fine xD)

OpenCL is a nice standard but benchmark shows that CUDA is way faster and there is a really strong support with compilers and from Nvidia.

True. Although OpenCL is available on any GPU, including those from Intel and AMD, it's also true that the performances have not been so good. Honestly, I don't mind pushing towards cuda. The whole industry is already pushing towards it and it's the de facto standard for those kind of calculations.

If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. OpenCL, if I understand correctly is practically ubiquitous.

The thing is that OpenCL has been proven to be slow, especially on Nvidia cards, so losing a lot in performance only to make it run on different cards isn't generally something that businesses are willing to accept. I work in broadcast and I can tell you that no matter where you go, if you open up the workstations of any studio, you'll find an NVIDIA Quadro, it's just the way it is. Some very small studios may have an RTX but that's about it, it's always NVIDIA. What I'd like to see in the future for Avisynth is a widespread use of cuda with plugins that can work on the CPU for the rest of the community and on the GPU for those owning an NVIDIA card. I know it may not make some users happy, but industry-wise it makes a lot of sense. I work in the encoding department, we have servers running Avisynth automated tasks all the time for ingest and outgest (incoming and outgoing media) and I have plenty of NVIDIA Quadro cards that are used by AVID Media Composer and Davinci Resolve, but I can't use them for Avisynth (except for a very limited set of plugins - Thank you Donald ;) ) and I can't use them in encoding either due to the lower quality outcome compared to x264/x265. I am actually using them to encode with x264 + OpenCL but honestly, the speedup is so reduced that I can barely tell the difference. I would love to be able to use them for Avisynth as it would speed up things a lot!

videoh

29th January 2021, 21:56

If a user doesn't have Nvidia hardware then they're not going to be able to use anything that relies on CUDA. Same can be said about iPhones and lots of other things. So what?

It's like a joke from our youth: Why did the man jump out of the airplane? Answer: Because if he didn't jump out of the airplane he'd still be in the airplane.

You are saying nothing. Putting stuff in bold doesn't improve an argument.

wonkey_monkey

29th January 2021, 22:12

Same can be said about iPhones and lots of other things. So what?

So look at all the work pinterf and others have done to NOT keep Avisynth tied to a particular operating system. I just wondered if it might be preferable not to throw in with another proprietary system when there are open alternatives, but I appreciate that pinterf isn't starting something new from scratch here, if he's even starting anything at all.

real.finder

29th January 2021, 22:22

maybe both or all (with Vulkan) since Vulkan not work with many old gpus but OpenCL do

like this plugin do https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Waifu2x-w2xc (it even work with CPU only)

gpu: Controls the environment to use.

0 = disable GPU
1 = auto detect. It will run on the first available environment in the following order:
CUDA
Vulkan
AMD OpenCL
FMA
AVX
Intel OpenCL
SSE3
OpenCV filter2D
2 = force to use OpenCL

videoh

29th January 2021, 22:37

Note that he puts CUDA first. ;)

real.finder

29th January 2021, 22:42

Note that he puts CUDA first. ;)

it's self-evident that CUDA is better for Nvidia

videoh

29th January 2021, 22:49

Y'all can only make self-evident observations? Or maybe it was a lame joke?

DJATOM

29th January 2021, 22:59

I love CUDA. Literally I'm NVidia fanboy, I think their GPUs are great:cool:

Atak_Snajpera

29th January 2021, 23:29

I love CUDA. Literally I'm NVidia fanboy, I think their GPUs are great:cool:

True NVIDIA fanboy would buy rtx3090 instead of that rtx2070 you have now. You must upgrade NOW!!!! Sell your kidney or/and car if you can't afford IT.

DJATOM

29th January 2021, 23:33

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.

Atak_Snajpera

30th January 2021, 00:04

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.

They will dump maybe after 4000 series... But then 3080 will be outdated and new series will be again sold out directly to chinese crazy miners.

tormento

30th January 2021, 01:11

No, I'm not that insane. But I'll definitely buy 3080 once prices dumps.
Wait for TI flavor. If you want to work seriously with 4K HDR, I think you will need more than 10GB for heavy MT.

tormento

30th January 2021, 01:13

maybe both or all (with Vulkan) since Vulkan not work with many old gpus but OpenCL do
I ain't a programmer but I can see FFMPEG is following the Vulkan path for general compatibility. And, to be honest, lot of not so ancient hardware supports it.

videoh

31st January 2021, 18:30

I would buy three 3090s right now if I could find any.

DJATOM

31st January 2021, 18:42

> TI
I'll consider it based on my local prices and availability. Literally I need it for filters like eedi3/nnedi3 where 10G memory isn't really a problem. In fact, 2070 with 8G is enough for it, but eedi3 is slow.

pinterf

31st January 2021, 18:46

Slowly porting some function documention of Neo fork (from Japanese) to Avisynth wiki.
Achievement of January is: http://avisynth.nl/index.php/DumpFilterGraph

tormento

31st January 2021, 19:32

I'll consider it based on my local prices and availability. Literally I need it for filters like eedi3/nnedi3 where 10G memory isn't really a problem. In fact, 2070 with 8G is enough for it, but eedi3 is slow.
Can you process HDR 4k material within 8GB? How many threads? Which GPU based filters do you use?

DJATOM

31st January 2021, 20:01

Yes, it's enough for 4k tonemap or eedi3/nnedi3 upscaling.

tormento

31st January 2021, 20:24

Yes, it's enough for 4k tonemap or eedi3/nnedi3 upscaling.
Do you use any GPU based filter?

DJATOM

31st January 2021, 20:35

All of those filters uses GPU (tonemap is cuda-based and edi stuff is OpenCL).

tormento

1st February 2021, 19:42

Is there any way to determine thru AVS+ the apparent and real bit depth of a video stream?

With apparent I call the number of bits (8/10/12/16), with real the non zero part of the bits itself.

I am starting to play with > 8 bits scripts and sometimes I have doubts about their real effectiveness.

DJATOM

1st February 2021, 20:52

Probably ScriptClip can help with detection, but it looks obscure for me and Idk howto write proper detection with it. Vapoursynth's std.FrameEval is much easier :D.
With python modules we can check md5 or crc of every frame and compare hash values. For example, create few clips (8, 10, 12, 14, 16) and compare source frame's md5 with every modified clip's frame hashes, then append metrics into variable. At exit (https://docs.python.org/3/library/atexit.html) write log file from metric variable and check found values across entire clip.

videoh

1st February 2021, 21:34

Maybe you can source the 10-bit into a clip c1. Then source it again into c2 and apply ConvertBits(8) followed by ConvertBits(10) to it. Finally do Subtract(c1,c2).Levels(...) to visualize any difference in the two low bits. If the 10-bit source is not real (i.e., low bits all zero) then you won't be able to amp up any visible difference.

BTW, don't forget that high bit depth is not just about getting more resolution, it's also about dynamic range for HDR.

tormento

1st February 2021, 22:11

I thank you both for the reply. I find a bit strange that a frame server hasn't functions to analyze the frame properties.

pinterf

2nd February 2021, 08:39

I thank you both for the reply. I find a bit strange that a frame server hasn't functions to analyze the frame properties.
Extremely strange. Specify "analyze", specify "frame properties".
Did you expect a ready made function IsThisSourceReally8bitInFake10bitFormat()?

Anyway, you can look at the histogram. e.g. Histogram("levels", bits=10), it is not that wide yet, or else you can show only the histogram part with keepsource=false. Valid histogram resolutions are bits=8,9,10,11,12.

tormento

2nd February 2021, 09:28

Extremely strange. Specify "analyze", specify "frame properties".
Did you expect a ready made function IsThisSourceReally8bitInFake10bitFormat()?
Given a single frame or a stream, the ability to detect bit depth and the capability to show the color bit value for a reasonable amount of pixels, to understand if all the bit depth is used or only “resized” to a deeper one, adding zeros only.

pinterf

2nd February 2021, 09:36

Besides the above mentioned 10 bit Histogram you can write an expression for that in Expr.

tormento

2nd February 2021, 09:37

Besides the above mentioned 10 bit Histogram you can write an expression for that in Expr.

Will try the histogram ASAP. For Expr, unfortunately I haven’t the capabilities to do it. Thanks, anyway.

tormento

2nd February 2021, 12:57

Anyway, you can look at the histogram. e.g. Histogram("levels", bits=10)
I made a simple AVS script and, opening it in VirtualDub2, I can see that, when a video stream has a bit depth minor than the bits parameter, I can see "gaps" in the graph of levels.

Would be of much trouble to add an option for 16 bits too?

pinterf

2nd February 2021, 13:10

For practical reasons the option is disabled. I hope that no one wants to display a clip with width=65536.

tormento

2nd February 2021, 13:11

For practical reasons the option is disabled. I hope that no one wants to display a clip with width=65536.
Wait... what has bits to do with width?

pinterf

2nd February 2021, 13:25

tormento

2nd February 2021, 13:28

If we are talking about Histogram "bits": a 8 bit histogram has 2^8 (=256) horizontal columns for levels. A 10 bit histogram is shown in 1024 (2^10) columns. And a histogram with 16 bit resolution can be shown on 65536 columns.
I am talking about "bits" parameter, i.e.

Histogram("levels", bits=12,keepsource=false)

I can find the true bitdepth of a stream just looking at histograms. That works fine for 8/10/12. How can understand if a stream is 16 bits or 10 bits without bits=16?

pinterf

2nd February 2021, 13:36

I am talking about "bits" parameter, i.e.

Histogram("levels", bits=12,keepsource=false)

I can find the true bitdepth of a stream just looking at histograms. That works fine for 8/10/12. How can understand if a stream is 16 bits or 10 bits without bits=16?
Then you have to learn Avisynth, especially Expr or masktools lut expressions, or think about other techniques. Or ask your stream sources where they obtained a 16 bit master from.

FranceBB

6th February 2021, 00:21

Hi Ferenc,
I have just a thing to report.

The AviSynth+ 3.7.0 release installer for Windows XP has been shipped with the "wrong" version of C++ Redistributable.
Let me explain.

There are:

- AviSynthPlus_3.7.0_20210111_vcredist_xp.exe
- AviSynthPlus_3.7.0_20210111_xp.exe

Both builds work just fine on Windows XP and they've been compiled to run on XP targeting v141_xp correctly, so no problem, however the "_vcredist_xp.exe" version isn't shipping the XP compatible Microsoft C++ Redistributable 2015-2019 installer, so what will happen is that the C++ Redistributable that is gonna be installed won't work on XP, hence it will make impossible to use Avisynth.
In order to make it work, I've installed the "vcredist" version shipped with AviSynth+ 3.6.1 and then I installed "AviSynthPlus_3.7.0_20210111_xp.exe" without re-installing the C++ Redist and it worked like a charm.
I think you should be shipping the vcredist version from AVS 3.6.1 for XP ;)

qyot27

6th February 2021, 05:18

Then Microsoft changed the vcredist silently, because it was the standard 2015-2019 vcredist download link.

FranceBB

6th February 2021, 15:00

Yep...
I just checked and it seems that VC++ 2019 version 14.28.29213.0 (August 2020) is the last version compatible with Windows XP... :( C++ Redistributable AIO (XP Compatible) (https://github.com/abbodi1406/vcredist/releases/download/v0.35.0/VisualCppRedist_AIO_x86_x64_35.zip)
I've just archived it... For future XP releases, we should always include that one I think.

StainlessS

6th February 2021, 16:22

Tanks FBB

DTL

13th February 2021, 14:47

Suggestion to add to build-in Avisynth+ resizers:

User defined kernel resizer. It uses f(x) kernel function as:

class UserDefined2Filter : public ResamplingFunction
{
public:
UserDefined2Filter(float _b = 121.0, float _c = 19.0);
double f(double x);
double support() { return 2.0; }

private:
double sinc(double value);
float a, b, c;
};

UserDefined2Filter::UserDefined2Filter(float _b, float _c)
{
a = 1.0f; // 0 sample = 1
b = (float)clamp(_b, -50.0f, 250.0f); // 1 and -1 sample
c = (float)clamp(_c, -50.0f, 250.0f); // 2 and -2 sample
b = (b - 16.0f) / 219.0f;
c = (c - 16.0f) / 219.0f;
}

double UserDefined2Filter::sinc(double value)
{

if (value > 0.000001 || value < -0.000001)
{
value *= M_PI;
return sin(value) / value;
}
else
{
return 1.0;
}
}

double UserDefined2Filter::f(double x)
{
x = fabs(x);

if (x <= 3) // ?
{
return c * sinc(x + 2) + b * sinc(x + 1) + a * sinc(x) + b * sinc(x - 1) + c * sinc(x - 2);
}
else
return 0;

}

It can simulate wide range of resizer's kernels from Sinc to Gauss and intended to use mostly for downsize work with forming spectrum of output result being 'conditioned for channel' in term of EBU publications. It allows to use 1-pass processing at resampling time instead of pre-processing before downsampling to meet both Nyquist and Gibbs limitations of downsized moving pictures result. It allows to have better sharpness in compare with GaussResize while still keeping ringing in controlled range because of negative lobes available. It includes functionality of SinPowResize with even better precision of kernel creation but with higher number of control params. It also may be designed some iterative algorithm to adjust all (currently 2 but may be 3 or more) control params with target to lowest or maximum allowed ringing with adjustable 'sharpness' with 1 user-input param like 'sharpness'. But it is much more to program.

I read some old book about tv test signals and found simple idea how to define kernel function using very small number of control parameters. It is just sinc (or other target restoration function like jinc for 2D resamplers) interpolation. So I add one more resizer function currently named UserDefined2ResizeMT. It is copy of BicubicResize with 2 'b' and 'c' control parameters. Even with 2 control samples it is possibly do define big range of different resizer kernels with good enough precision and have use my web-render tool to visually control its behaviour. For better results there may be used more than 2 control samples - like 3 or 4. Like 'd' and 'e' additional arguments. With expanding filter 'support' value and defaulting non-used values to 16 (virtual zero ad 16..235 video coding range). I use range of control parameters in 16..235 mapped to 0..1 internally for better compatibility with typical digital video processing software. Though it may be changed to other range like 0..1 float (with valid range like -0.5 to +1) - it is not critical.
If user enter all control values as 16 it will produce SincResize kernel (internal 'a' parameter is equal to 1 or 235 in the input params range) with small number of taps defined at filter support now - may be 2 or 3. When I perform debug I see resampler asks for values outside 'support=2' up to about 3. May be it also useful for in-the-field using of this resizer to make 'support' also user-defined parameter. If user want to use >2 control values and have also a performance hit because of longer resampler processing. So user may see how kernel works far outside first defined number of samples if want.

Current full sources and supplementary documentation and tools is in the fork of jpsdr's ResampleMT at https://github.com/DTL2020/ResampleMT.

Also may be SincLin2Resize add or some other workaround for SincResize (may be control bool param to use additional weighting at the end of kernel) to fix its bugs at the end of too short truncated kernel computation.

FranceBB

14th February 2021, 09:11

Well done once again. When it's finalized, please contact Jean Philippe and ask for a push request so that he can merge everything and publish a new thread pool aware version of plugins_JPSDR.dll which is the one I use in production.

DTL

14th February 2021, 11:14

When it's finalized,

For 'complete' finalizing it need some feed-back from 'in the field' users for questions:

1. Is 2 control parameters is enough or 3 or 4 needed ?
2. Is current internally fixed 'support' value is enough or may be internally calculated as 'number of non-16 last control values (may be +1)'.

It is currently 'finalized' for control params number = 2 so pull-request at github is made.

May be for creating 'reference' higher quality test patterns like for 10-bit and 10+bit data more 2 control values will be definetly required. But with real world moving pictures material may be no any visible difference but with slower processing and harder to control by low experienced end-user.
May be it is better to add 2 named resizers like UserDefined2Resize with 2 control params (for most everyday practical work) and UserDefined4Resize with 4 control params (for advanced users).

Also for 10bit and higher precision may be it is better to set control params range to -1.0f to 1.0f. Because currently available setting like 16.01 if required may be harder for end user for re-calculation from different values range. For example in that book the samples values for test pulse for digital video workflows was defined with about 5..6 digits like:
b=0.48113 c=0.01541 d=0.00354 e=-0.00275 f=0.00194 g=0.00140 i=0.00105 k=0.00082 l=0.00065 m=-0.00053
But for practical using written it is enough to use starting 2 (already gives K-factor like <0.205% and 5 times better in compare with typical 'analog' test pulse sin^2), so current defaults in 16-235 range integers is
b=0.48113*219+16=121
c=0.01541*219+16=19
And for real content for downsize work it is very approximate values because the actual working values depends on:
1. Content source (most of sources were build and continue to build without any requirements to its spectrum in valid frequencies range).
2. Shrinking ratio (small shrinking ratios like 1/1.5 are not much change input spectrum and large shrinking ratios like 1/3..1/4+ require almost new spectrum re-forming for anti-Gibbs conditioning).
3. User's personal opinion of how output result must look.

In some/future 'perfect world' the calculation of 'b' and 'c' (and other if required) control params for getting 'standard' result may be automated based on shrinking ratio. But it also need to be applied to 'standard' source. May be some calculator of recommended values of params based on shrinking ratio may be made and released as supplementing tool as 'hint' to user to start with in the future. Or at least some short table may be faster created like 'shrinking ratio' {<2; 2..4; >4}, sharpness {low; standard; high}; b,c (d,e){ ....}.

Update for typical recommended values:
Shrinking ratio: 1/8,
-Low Sharpness: b=121 c=19;
-Medium sharpness: b=104 c=0;
-High sharpness: b=90 c=-14.

Shrinking ratio: 1/2,
-Low Sharpness: b=100 c=-5;
-Medium sharpness: b=90 c=-15;
-High sharpness: b=80 c=-20.

The highest possible 'sharpening' is about b=50, c=-50. Some 'softening': b=190, c=80.

pinterf

15th February 2021, 08:19

, so current defaults in 16-235 range integers is
b=0.48113*219+16=121
c=0.01541*219+16=19

I see those hardcoded numbers 16 and 219 there. Does it mean that this resizer is fine tuned to YUV color space luma only? U and V chroma planes have 16-240 range; RGB is full range.
EDIT:
Some notes:
This one (https://github.com/DTL2020/ResampleMT/commit/dfcfa4fc5d8cfbc17154cba463f416d2cf45cfe4#diff-dbb2fe7842c0b8cc580930915d1d7d145bccc28a9f47ca10fe7e70b1c2cbc01bR307) probably doesn't need default parameters because here (https://github.com/DTL2020/ResampleMT/commit/dfcfa4fc5d8cfbc17154cba463f416d2cf45cfe4#diff-c2f84ab50dcf4e6eadec84dd1241b6548305299189a07231fe311948d70fa2c5R4952) you are already setting the them.

DTL

15th February 2021, 14:28

I see those hardcoded numbers 16 and 219 there. Does it mean that this resizer is fine tuned to YUV color space luma only? U and V chroma planes have 16-240 range; RGB is full range.

No. It is just one of possible ways of transfer values of control params from user input to actual kernel computation function. They may be defined in range of -1.0f to about 1.0f (as I think most of real usable kernels do not have >1 values and <-1).

I think many broadcast and video data users are used to use video samples range of unsigned integers defined usually in 16..235 range for 8bit encoding. So typical users knows 16=black zero and 235 is nominal system white. The currently still active broadcast standards like ITU-R-BT.1212 also define actual samples values in 'natural' range 16..235. So user can just pick the samples of some actual impulse response and use as parameters without re-calculation to -1.0f..+1.0f range.

The kernel-output function f(x) outputs same range values as other resizer's kernels. I test it only with jpsdr's ResampleMT resampler core, not with latest Avisynth+ releases, but I hope there is no significant difference.

Using with RGB full range is also possible without any tuning but user must understand possible losses of overshoots and undershoots outside valid range for RGB resulting with later non-linear distortions at further processing like unwaited ringing and some decreasing of sharpness. Though integer 16..235 coding range also limited in its ability of handing extreme under and overshoots of course.

If it will be more comfortable to use float range about 0..1 it may be easily changed removing internal conversion from 16..235 range and limiting user input to about -1.0f.. 1.0f.
Defaults b and c will be 0.481 and 0.015. There is no any special magic in this numbers and it just placeholders giving medium sharp result if downsizing with high enough ratio like >5 and giving very low ringing with almost no under/over shoots (so it also 'more compatible' with RGB-fullrange processing defaults).

"This one probably doesn't need default parameters because here you are already setting the them."

I still very poor in programming at high level languages so put as much as possible. My todays greatest achievement is finally working using vector of vectors of C++ to do not write it manually with C and to use library 'vector->rotate' operation :) . So programming of multithreaded 'planar'/2D resampler engine is in progress and may be in some days it may be also added to main Avisynth core as alternative 'linear' resampler engine.

StainlessS

16th February 2021, 14:32

Just thought I'd point this out in case P had not seen it in Usage.
https://forum.doom9.org/showthread.php?p=1936011#post1936011

Function SpotLess2(clip c, int "RadT", int "Spot", bool "DeGrain", int "RadT", int "ThSAD", int "ThSAD2",
\ int "pel", bool "chroma", int "BlkSz", Int "Olap", bool "tm", Bool "glob") {

Strangely, it does not throw an error due to 2 different instances of the formal parameter "RadT", maybe a bit more checking needed in Avs+.

EDIT: I have not tried explicitly providing all args (un-named) to see what happens, and what value RadT=Default(RadT,42) might acquire,
where both instances of supplied RadT presented different numbers.

EDIT: OK, I could not resist it.

Function Testing123(clip c,int arg1, int "Arg2",int "Arg3", int "Arg4",int "Arg2",int "Arg5",int "Arg6") {
return Default(Arg2,-1)
}

BlankClip(Width=64,height=64,length=1,pixel_type="YV12").killaudio
z=Testing123(last,1,1001,3,4,1002,5,6)
Subtitle(string(z))

https://i.postimg.cc/P5JQXwGM/SHITE-2-00.jpg (https://postimages.org/)

EDIT: Maybe it don't matter too much, obviously not a popular script bug :)

pinterf

16th February 2021, 14:59

I've already prepared my mind for that report. All I can say: don't do that :) Bonus idea: try how many parameters are allowed in classic Avisynth and Avisynth+ :)

StainlessS

16th February 2021, 15:05

Tanks for your consideration P, "dont do dat" seems to be the way to go.

EDIT: Get my jab tomorrow. :)

EDIT: I think is unlimited parameters in Avs+, not sure bout 2.6 std.
I believe that at one time it may have been limited to 64. [think was maybe qyot27 idea to make unlimited].

stax76

18th February 2021, 16:06

Wiki page on AviSynth Unicode support on Windows 10 1903:

https://github.com/staxrip/staxrip/wiki/AviSynth-Unicode-support-on-Windows-10-1903

DTL

19th February 2021, 05:11

Can this approach - http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf be added to http://avisynth.nl/index.php/Limiter core filter ?

pinterf

22nd February 2021, 10:04

I've run through it, probably yes, but in my age a quick overview is not enough for deep understanding of the possible implementation steps. I'll return to the topic later.

DTL

23rd February 2021, 10:15

It looks some very hard long strategic question on core and plugin development:

Because of current execution hardware architecture moving to large number of processing cores with small per-core L1d cache and slow main memory access can be the new scan formats be added like blocks scan instead of full-frame line scans ?

Currently for algorithms for vertical data accessing it is require to read memory with large strides and it even 1 full line of 8K frame in float32 eats all 32 kB L1d cache.

The size of scan blocks is a new question. It looks must be < L1d cache size like 32..48 kB maximum and the ratio of V/H may be from 1:1 to may be natural for 4/3..16/9 frame.

The scan re-formatting may be made inside each plugin to and back but it will slow performance. May be also some plans in this direction exist ?

pinterf

23rd February 2021, 11:06

Given the large number of plugins and the extra complexity it introduces I think it will never happen. Filters are complex enough even without this feature. How many OpenCL or CUDA filters do we know? Only a few of them exist. Actually CUDA support** seems to be working with Avisynth+ core (do not search it in the official releases :) ) supporting native CUDA filter chain.

Like https://github.com/pinterf/AviSynthCUDAFilters . It includes
https://github.com/pinterf/NNEDI3/tree/cuda
https://github.com/pinterf/masktools/tree/cuda
I have forked them from Nekopanda's github pages and updated them to work with actual Avisynth 3.7. CUDA version build now is supported from CMake as well
https://github.com/AviSynth/AviSynthPlus/commit/891d100825c8fa5f0252d3198ba6d10e0817eef6
Other useful info:
https://github.com/pinterf/AviSynthCUDAFilters/blob/master/documentation/build_help.txt
and
http://avisynth.nl/index.php/SetFilterMTMode
(onCPU and onCUDA section)

**CUDA support = the interfaces and the framework exists. Implemented filters are in those above mentioned external plugins.

DTL

23rd February 2021, 12:23

How many OpenCL or CUDA filters do we know? Only a few of them exist. Actually CUDA support** seems to be working with Avisynth+ core (do not search it in the official releases :) ) supporting native CUDA filter chain.

So CUDA for GPU already uses some sort of small blocks scan mode instead of full line scanning also because of problems with 2D access with too large strides ?

I see current 'multi-frames' MultiThreading processing in Avisynth also limited by memory speed on many cores CPUs.

As for plugins it may be evolutional shifting to block scan formats if new formats will be added and plugin (and core) filters designers will move in time to support new scan formats.

Unfortunately no good news from hardware production industry on significant bus width increase and memory performance increase. Also sill even no progress of local on-chip cache being 'all-L1' but still divided to small L1 and larger L2/L3 with even low speed.

I think the reason of production Xeons with >10 cores for 'supercomputing' is only with software capable of process mostly data in register file or L1 cache.

Kogarou

2nd March 2021, 18:23

tormento

6th March 2021, 13:24

ok, so I will mention what not has HBD yet
Could you please update it? I think that it would be useful as sticky post.

real.finder

6th March 2021, 13:52

Could you please update it? I think that it would be useful as sticky post.

here https://forum.doom9.org/showthread.php?p=1937480#post1937480

DTL

6th March 2021, 20:39

Either I doing something wrong or some degradation happens:

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

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

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

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

This: BilinearResize(width, height, src_left=0.5, src_top=0.3, src_width=width, src_height=height) works.

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

pinterf

6th March 2021, 21:01

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

DTL

6th March 2021, 21:29

StainlessS

6th March 2021, 22:23

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

Current error message is completely mysterious about what going wrong.

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

Perhaps it aint gonna happen any time soon.

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

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

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

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

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

or

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

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

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

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

DTL

7th March 2021, 00:43

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

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

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

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

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

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

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

StainlessS

7th March 2021, 01:04

jpsdr's plugin must use this stuff

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

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

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

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

EDIT:

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

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

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

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

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

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

I stil not read all documentation on Avisynth+ but may be in some page about function calling and parameters naming there is a restriction to use names for compulsory arguments ?
So far as I know (maybe it changed recently), compulsory args never have a name in CPP/C spec [just a type]
eg "ci" for clip, int, both un-named.
Optional as in "cib[floatarg]f", where Function (clip, int, bool "boolarg", float "floatarg") sort of in script speak.
Un-named optional arg as in ""ci[]b" where bool arg is un-named optional.
As far as new arrays and such are concerned, I got no idea at all how that works.

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

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

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

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

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

# ...

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

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

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

wonkey_monkey

10th March 2021, 23:43

pinterf

11th March 2021, 07:40

AVSValue's AsFloat(...) returns a double, but if you try and pass a double as the default value the compiler warns that there'll be a conversion to float. If it returns a double, shouldn't it accept a double as a default value?
There is an AsFloatf version of AsFloat that should be used to avoid warnings. This function exists for this very reason.
EDIT: maybe I explained the opposite: to avoid return value warning. You can use AsDblDef, but since there is no double in AVSValue there is no point of doing that.

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

pinterf

11th March 2021, 08:14

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

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

EDIT: Also note un-named optional, audiolengthhi "c[]i"
The new array specifier "a" expects a real array at its parameter position. Such arrays can be more-than 1D, and their elements are not restricted to have the same type.

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

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

Edit: with Stain"EagleEye"LessS' corrections

StainlessS

11th March 2021, 12:41

Thanks P, it all seems very complicookered :)

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

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

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

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

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

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

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

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

Example script usage

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

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

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

EDIT: https://dictionary.cambridge.org/dictionary/english/suck-it-and-see
suck it and see
UK informal

to try something to find out if it will be successful:
I'm not sure whether this paint is the right colour for the bedroom - we'll just have to suck it and see.
If you've got a bag of identical looking (but multiple flavour) chocolates, you may implement a Suck It And See policy.

pinterf

11th March 2021, 14:41

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

real.finder

13th March 2021, 14:58

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

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

uptodate one here https://github.com/realfinder/UniversalPluginsFolders/blob/master/plugins64%2B/MtModes.avsi

mp3dom

15th March 2021, 00:22

poisondeathray

15th March 2021, 01:57

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

Works ok for me (difference detected with subtract)

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

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

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

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

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

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

mp3dom

15th March 2021, 02:24

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

poisondeathray

15th March 2021, 02:27

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

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

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

subtract(b,l)

avs 3.7 x64 r3382
Maybe something peculiar about your png ?

LigH

15th March 2021, 08:42

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

poisondeathray

15th March 2021, 18:06

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

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

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

You can examine png's with tweakpng

wonkey_monkey

19th March 2021, 23:14

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

On this page it states:

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

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

PS The section on IsWriteable() has a typo:

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

pinterf

20th March 2021, 11:26

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

a) What is meant by "active part"?

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

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

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

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

wonkey_monkey

20th March 2021, 18:40

Thanks pinterf!

wonkey_monkey

21st March 2021, 15:06

VideoInfo.GetPlaneWidthSubsampling and VideoInfo.GetPlaneHeightSubsampling both throw exceptions if called with a parameter of 0. Since "0" is the default parameter for GetReadPtr, etc, and so is effectively the plane ID for interleaved RGB video, could those functions be updated to return 0 if called with 0, rather than throwing an exception?

Also edit: could IsY(), IsYUV() and IsYUVA() be updated/replaced to be consistent and intuitive?

StainlessS

21st March 2021, 18:43

Maybe one of em should be VideoInfo.GetPlaneHeightSubsampling.

EDIT:

Function X_IsY(clip c) {
# True=Single Plane
# (!IsRGB)=True = Any type with Y, YUY2/YUVA/Y8 etc.
# BEWARE Y8_Clip.IsYUV returns True
c
IsAvsPlus ? IsY : IsAvs26 ? IsY8 : False
}

StainlessS

25th March 2021, 18:21

From here [Internal functions]:- http://avisynth.nl/index.php/Internal_functions#propSetInt

Not sure if this lot is correct,

propSetInt

propSetInt(clip, string key_name, function func_obj [, integer "mode"]) AVS+

propSetFloat

propSetFloat(clip, string key_name, function func_obj [, integer "mode"]) AVS+

propSetString

propSetString(clip, string key_name, function func_obj [, integer "mode"]) AVS+

propSetArray

propSetArray(clip, string key_name, function func_obj [, integer "mode"]) AVS+
these setters accept only the specific type

Should it be more like this

propSetInt

propSetInt(clip, string key_name, integer value [, integer "mode"]) AVS+

propSetFloat

propSetFloat(clip, string key_name, float value [, integer "mode"]) AVS+

propSetString

propSetString(clip, string key_name, string value [, integer "mode"]) AVS+

propSetArray

propSetArray(clip, string key_name, array value [, integer "mode"]) AVS+
these setters accept only the specific type

Also, something seems a bit messed up here,
propGetAsArray

propGetAsArray(clip, string key_name[, integer "index", integer "offset"]) AVS+
returns an array. For a single property array size will be 1. (only in array-aware AviSynth+ versions)

propGetAll

propGetAsArray(clip [, integer "offset"]) AVS+
returns an array. For a single property array size will be 1. (only in array-aware AviSynth+ versions)
Returns all frame properties in an array of [key-value] pairs. Array size will be 'numProps'
Each key-value pair is contained in a two dimensional subarray.
If the property value for a given key is an array again then "value" will be an array as well.
Once you have the array with all properties you can access them with the "associative" feature of AviSynth array access

Extracting from C prototypes I see this, [can only extract single C prototype]
propGetAsArray "cs[offset]i"

EDIT: And
propGetAll "c[offset]i"

pinterf

26th March 2021, 16:47

From here [Internal functions]:- http://avisynth.nl/index.php/Internal_functions#propSetInt

Not sure if this lot is correct,

Should it be more like this

propSetInt

propSetInt(clip, string key_name, integer value [, integer "mode"]) AVS+

propSetFloat

propSetFloat(clip, string key_name, float value [, integer "mode"]) AVS+

propSetString

propSetString(clip, string key_name, string value [, integer "mode"]) AVS+

propSetArray

propSetArray(clip, string key_name, array value [, integer "mode"]) AVS+
these setters accept only the specific type

They are O.K. These names are different only for parameter lists with function object.
Other plain propSet versions can establish the property type from the type of the provided value.

More on function objects:
http://avisynth.nl/index.php/Function_objects

EDIT: the mess with propGetAll is quick-fixed, thanks for the report.

wonkey_monkey

26th March 2021, 21:42

There's something very odd going on...

I was getting a crash with this script and version 3.6.1 (edit: also with 3.7.0):

Colorbars
ResampleAudio(48000) # any value

It would play back from any frame other than frame 0, but if played back (in VirtualDub) from frame 0, it would crash. It would also crash using AVSMeter (I wrote a simple plugin to GetAudio within GetFrame, so that I could benchmark audio using AVSMeter).

So I updated to 3.7.0. The good news is, no more crash (EDIT: scratch that: it still crashes from frame 0. Not if you add trim(1,0), though). The bad news is, when I playback a simple Colorbars clip (even without ResampleAudio) in VirtualDub2, the sound is all messed up, like it's clicking on and off at (very rough guess) 25Hz. EDIT: It seems to be almost exactly 40Hz. Here's an Audacity screenshot of a recording of VirtualDub2 playback:

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

Using my waveform plugin, the waveform looks okay, but I guess something about how VirtualDub is getting the audio is getting things messed up. Sound generated by the Tone function is similarly messed up. A Wavsource, though, is fine.

Edit: ffmpeg encoding to a file seems fine. Maybe it's a VirtualDub2 thing, but it wasn't doing it under 3.6.1.

Richard1485

26th March 2021, 22:57

Maybe it's a VirtualDub2 thing, but it wasn't doing it under 3.6.1.

It's not VirtualDub2, though I can hear it in VirtualDub2. I can also reproduce it in ffplay on the Linux build of AviSynth+ (latest version). It seems to me to be related to bit depth.
Colorbars
ConvertAudioTo16bit() # any bit depth

It's not audible in ffplay if I comment out the second line, but it is in VirtualDub2. VirtualDub never used to like playing back audio at anything other than 16-bit (though VirtualDub2 was an improvement), so maybe VirtualDub2 converts the audio as it comes in.

wonkey_monkey

27th March 2021, 00:02

Same with ffplay on Windows.

pinterf

27th March 2021, 09:24

wonkey_monkey

27th March 2021, 13:53

wonkey_monkey

27th March 2021, 14:19

Re the glitch, my previous screenshot was taken while I had my laptop's audio processing enabled which I think gave a misleading impression. Here's a closeup with processing disabled:

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

It happens at the positive peak every 11 positive peaks. I'm guessing some change in the code or perhaps floating point mode when compiling is causing the generated sample to go just over 1.0, which makes the glitch audible when it's converted to integer samples before sending to the sound card. Adding:

Amplify(0.99)

stops the playback glitch.

Richard1485

27th March 2021, 15:49

Both of these are true for 3.6.1 and 3.7.0. Garbled VirtualdDub2/ffplay audio only occurs with 3.7.0 (and on ffplay only if ConvertAudioTo16Bit() or ConvertAudioTo8Bit() is used).

On my end, it occurs in ffplay with ConvertAudioTo24Bit() and ConvertAudioTo32Bit() as well.

pinterf

29th March 2021, 09:00

I could have sworn it did yesterday, but it's not doing it now.

Rates other than 48000 are still causing it to crash on the first frame.

ColorBars
ResampleAudio(44100)

# ^ crashes

ColorBars
ResampleAudio(44100)
Trim(1,0)

# ^ does not crash

Both of these are true for 3.6.1 and 3.7.0. Garbled VirtualdDub2/ffplay audio only occurs with 3.7.0 (and on ffplay only if ConvertAudioTo16Bit() or ConvertAudioTo8Bit() is used).

I removed all plugins just in case but it didn't make any difference.

EDIT: Adding a call to Amplify - even with a value of 1 - before ResampleAudio stops the crash occuring.
No crash for me. Now to get any further: 32 or 64 bit Avisynth? Does it happen with SetMaxCPU("none") at the start of the script?
Which version of Virtualdub2 you are using (I'm at 44282). What are you exactly doing when vdub2 is crashing? Just load the script and press reload F2? Or File|Save audio.
I can see that after ResampleAudio, some samples can be more than 1.0, e.g. 1.00000023 but it cannot be a problem.

wonkey_monkey

29th March 2021, 12:29

It seems to affect 64 bit Avisynth only. SetMaxCPU("none") has no effect. I'm using 44282 as well but the crash happens with ffplay.exe, as well as avsmeter64.exe and my own AVS viewer (when using a plugin that forces the fetching of audio with video - my original Waveform plugin and a completely new purpose-written one that just calls GetAudio within GetFrame). I also added a call to GetAudio to my own viewer and that let me narrow it down a little:

With the following script:

SetMaxCPU("none")
ColorBars
ResampleAudio(44100)

, the crash occurs if I attempt

clip->GetAudio(buffer, X, 1, env);

, where X is between 0 and 41. For x=42 and above, no crash.

If I change the new sample rate to 34100, it crashes with X between 0 and 39.
If I change the new sample rate to 10000, it crashes with X between 0 and 34.

I can see that after ResampleAudio, some samples can be more than 1.0, e.g. 1.00000023 but it cannot be a problem.

I thought >1.0 samples might be the cause of the garbled playback with VirtualDub and ffplay, but may be entirely unrelated to the crash.

pinterf

29th March 2021, 13:59

It seems to affect 64 bit Avisynth only. SetMaxCPU("none") has no effect. I'm using 44282 as well but the crash happens with ffplay.exe, as well as avsmeter64.exe and my own AVS viewer (when using a plugin that forces the fetching of audio with video - my original Waveform plugin and a completely new purpose-written one that just calls GetAudio within GetFrame). I also added a call to GetAudio to my own viewer and that let me narrow it down a little:

With the following script:

SetMaxCPU("none")
ColorBars
ResampleAudio(44100)

, the crash occurs if I attempt

clip->GetAudio(buffer, X, 1, env);

, where X is between 0 and 41. For x=42 and above, no crash.

If I change the new sample rate to 34100, it crashes with X between 0 and 39.
If I change the new sample rate to 10000, it crashes with X between 0 and 34.

I thought >1.0 samples might be the cause of the garbled playback with VirtualDub and ffplay, but may be entirely unrelated to the crash.
Filter can request data for negative audio sample points in this case when we are in the very first frame. Resample is using overlapping buffers. Providing proper zeroified-samples for negative sample points is handled however when GetAudio is passing through "audio cache", so ColorBars is seeing only n>=0 audio sample requests.

EDIT: from 48000 to 44100 conversion, there is a -45 as the start parameter of GetAudio

StainlessS

30th March 2021, 16:46

Bit more audio weirdness, StackVertical audio should be from first clip.

# Stack filters should produce audio from first clip.

CHANNELS = 2 # Try with 2 and 1

V=Colorbars.KillAudio
A1=Tone (length=30.0, frequency=440, samplerate=44100, channels=2, type="Sine", level=1.0)
A2=Tone (length=30.0, frequency=440, samplerate=44100, channels=CHANNELS, type="Noise", level=1.0)
V1=AudioDub(V,A1).Trim(0,-1000)
V2=AudioDub(V,A2).Trim(0,-1000)
#S=StackHorizontal(V1,V2) # Seems OK
S=StackVertical(V1,V2) # Wrong, CHANNELS=(2)=Audio from bottom clip, CHANNELS=(1)= maybe some mix of audio from both clips

#V1
#V2
S

EDIT: Does not occur in v2.60/2.61 std.

EDIT: DOES OCCUR in avs+ v0.1 r2772.

zorr

31st March 2021, 00:16

How much support is there for array variables? My tests indicate that currently you can

create an array variable: arr = [0.1, 0.2]
read from an array: a = arr[0]
loop through an array: for (i = 0, ArraySize(arr)-1, 1) { ... }

However I wasn't able to update a value to a specific index: arr[0] = 0.1

Is there a way to create an array with a specific size without listing all the values, something like arr = float_array[10]?

Thanks!

pinterf

31st March 2021, 07:30

StainlessS

31st March 2021, 12:56

Well wadya know, I did not even think to try with non RGB interleaved when prob was audio, nice one P.

pinterf

31st March 2021, 16:16

Fixed, anyway.

jpsdr

31st March 2021, 20:41

If i do

filter 1
filter 2
SetCPUMax
filter 3
filter 4

will SetCPUMax affect only filter 3 and filter 4 or all the filters ?

wonkey_monkey

2nd April 2021, 14:23

Providing proper zeroified-samples for negative sample points is handled however when GetAudio is passing through "audio cache", so ColorBars is seeing only n>=0 audio sample requests.

Sorry, I'm not quite clear on this... is it a bug of GetAudio, or a quirk of ColorBars?

real.finder

2nd April 2021, 19:46

jpsdr

3rd April 2021, 08:51

Maybe it's a ScriptClip issue ?
Read the Warning of the 1rst post of my Internaly multi-threaded desampling functions (DeBilinear, DeBicubic,...) thread, there is maybe some clue of the "why", even if theoricaly all resources are freed in the destructor, so there souldn't be anything left... unless... Destructor is not called anymore...? (I doubt)
My guess it affects only filters allocating ressources on constructor... :D

pinterf

5th April 2021, 09:15

Sorry, I'm not quite clear on this... is it a bug of GetAudio, or a quirk of ColorBars?
Not a bug, at least not that I am aware of, because - quite annoyingly - I'm unable to reproduce your crash issue. All I can see that at the very first frame ResampleAudio can request negative sample indexes from the child clip, but it is handled in a mid-layer (audio-cache) properly, thus protecting the child filter from that. So - in theory - Colorbars will never get a negative sample request.
When I am able to see the crash I'd immediately tell you its reason.

pinterf

5th April 2021, 09:17

If i do

filter 1
filter 2
SetCPUMax
filter 3
filter 4

will SetCPUMax affect only filter 3 and filter 4 or all the filters ?
Good question, I'm unsure when it gets executed.

pinterf

5th April 2021, 09:34

at least in x64 and Spline36Resize

Spline36Resize inside ScriptClip case small memory leak https://forum.doom9.org/showthread.php?p=1939780#post1939780

jpsdr, it's also happen in Spline36ResizeMT

edit: seems happen in any kernel, also z.lib resize has the problem

ColorBars(width=640, height=480, pixel_type="yv12")
Interleave(last,last,last,last,last)
ScriptClip("""
z_BilinearResize(Width(),Height()*2).z_BilinearResize(Width(),Height())
""")

and Dither_resize16 is the worst of them! memory increases dramatically!

ColorBars(width=640, height=480, pixel_type="yv12")
ScriptClip("""
ConvertBits(16).ConvertToStacked.Dither_resize16(Width(),Height()*2).Dither_resize16(Width(),Height()).ConvertfromStacked.ConvertBits(8)
""")
I'm unsure in this as well, just a tip, but Avisynth "string" heap is a thing that can only grow and never be reset. (Avisynth have to make "static" and store string references internally. Strings which are put into an AVSValue Avisynth variable, should be saved in order to prevent them disappearing. (devs: see env->SaveString)
If it happens in a runtime environment, called multiple times, I can imagine that the memory consumption is growing.

wonkey_monkey

5th April 2021, 15:43

When I am able to see the crash I'd immediately tell you its reason.

I don't know if it helps, but adding a call to any filter between ColorsBars and ResampleAudio seems to fix it - Amplify, PointResize, Blur, FlipVertical, even my own debugging filter which does nothing but send debug messages when GetAudio or GetFrame is called.

Without an intervening filter, the error I get is

Avisynth read error: CAVIStreamSynth: System exception - Access violation at 0x00007FFCBF0982C7

I've checked another computer and still get a crash. Does anyone else out there get a crash with

ColorBars
ResampleAudio(36000)

when playing back (including audio) in VirtualDub or ffplay?

--------------------------

Regarding the glitching audio since 3.7.0, I've found no difference in the sample values generated by Tone/ColorBars between 3.6.1 and 3.7.0. Maybe something has changed with whatever the interface is to pass audio out to the playing program?

poisondeathray

5th April 2021, 17:04

Does anyone else out there get a crash with

ColorBars
ResampleAudio(36000)

when playing back (including audio) in VirtualDub or ffplay?

Crashes in both for me

avs+ 3.7 (r3382) x64

StainlessS

5th April 2021, 17:17

OK x86 [no crash] on VDub2 and PotPlayer, [nasty audio interference VD2 only, not Potplayer]
x64 VD2, on load Avs OK [not constructor prob], on play Crash " Access violation at 0x00007FFCBF0982C7".
PotPlayer x64 Freeze.
Current v3.70.

pinterf

5th April 2021, 19:49

StainlessS

5th April 2021, 20:17

VDub2 x86
Save to Crash.avi

ColorBars
ResampleAudio(36000)
Trim(0,-100)
#WaveForm_Filmstrip() # does not show any problem in waveform_filmstrip
return last

Avisource(".\crash.avi")
WaveForm_Filmstrip()
return last

result [audio spikes]
https://i.postimg.cc/QMzYcdL9/crash-Copy-00.jpg (https://postimages.org/)

EDIT: Even spikes [noise] in x86 potplayer with the avi

pinterf

5th April 2021, 20:53

I'll give it a next try then.
EDIT: yeah, with ffplay it finally crashed!
O.K. this one is fixed. Colorbars did not tolerate negative sample index requests which can happen at the very first frame of ResampleAudio.

wonkey_monkey

5th April 2021, 21:59

Thanks pinterf! Good to know it's only a ColorBars problem so not going to cause any "real" crashes.

The glitch problem is in convertFLTTo32 (avs_core/convert/convert_audio_c.cpp), convertFLTTo32_SSE2 (avs_core/convert/intel/convert_audio_sse.cpp) and convertFLTTo32_AVX2 (avs_core/convert/intel/convert_audio_avx2.cpp) which are used as the first step in conversion from float to any of the integer formats, and it's with this:

const float max32 = 2147483647.0f;

That number can't be represented by a float (they only have 7-8 decimal digits of precision, roughly an error of +/- 60 around that high value) so it's rounded up to 2147483648.0f, which is just beyond the range of a 32-bit integer. Visual Studio shows its true value:

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

Suggestion: Single-precision conversion to 24 bit integers (float can accurately represent any integer from -2^23 to +2^23) as a first step for conversion to 24, 16, or 8-bit, plus specialised double-precision routines for conversion from float to 32-bit.

StainlessS

6th April 2021, 01:46

Are RowSize, and Pitch, guaranteed the same sizes for all channels of Planar RGB ?
[EDIT: all rowsize's same, and all pitch's same]

pinterf

6th April 2021, 07:14

jpsdr

6th April 2021, 12:48

For investigating purpose, i've done the followig :

static void Warp2_8(const unsigned char *psrc,const unsigned char *pedg,unsigned char *pdst,const int32_t src_pitch,
const int32_t edg_pitch,const int32_t dst_pitch,const int32_t dst_row_size,const int32_t dst_height,int32_t depthH,
int32_t depthV)
{
const int32_t i = -((dst_row_size+3)&~3);
const int32_t c = dst_row_size + i - 1;
const int32_t src_pitch4=src_pitch<<2;

/* psrc -= (i << 2);
pedg -= i;
pdst -= i;

depthH <<= 8;
depthV <<= 8;*/

const short x_limit_min[8] = {(short)(i<<2),(short)((i-1)<<2),(short)((i-2)<<2),(short)((i-3)<<2),(short)((i-4)<<2),
(short)((i-5)<<2),(short)((i-6)<<2),(short)((i-7)<<2)};
const short x_limit_max[8] = {(short)(c<<2),(short)((c-1)<<2),(short)((c-2)<<2),(short)((c-3)<<2),(short)((c-4)<<2),
(short)((c-5)<<2),(short)((c-6)<<2),(short)((c-7)<<2)};

if (aWarpSharp_Enable_AVX)
{

psrc -= (i << 2);
pedg -= i;
pdst -= i;

depthH <<= 8;
depthV <<= 8;

for (int32_t y=0; y<dst_height; y++)
{
int32_t y_limit_min = -y * 0x80;
int32_t y_limit_max = (dst_height - y) * 0x80 - 0x81;
int32_t edg_pitchp = -(y ? edg_pitch : 0);
int32_t edg_pitchn = y != dst_height - 1 ? edg_pitch : 0;

JPSDR_Warp2_8_AVX(psrc,pedg,pdst,src_pitch,edg_pitchp,edg_pitchn,y_limit_min,y_limit_max,
x_limit_min,x_limit_max,i,depthH,depthV);

psrc += src_pitch4;
pedg += edg_pitch;
pdst += dst_pitch;
}
}
else
{
warp_c<2,uint8_t>(psrc,pedg,pdst,src_pitch,edg_pitch,dst_pitch,dst_row_size,dst_height,depthH,depthV,8);
/*
for (int32_t y=0; y<dst_height; y++)
{
int32_t y_limit_min = -y * 0x80;
int32_t y_limit_max = (dst_height - y) * 0x80 - 0x81;
int32_t edg_pitchp = -(y ? edg_pitch : 0);
int32_t edg_pitchn = y != dst_height - 1 ? edg_pitch : 0;

JPSDR_Warp2_8_SSE2(psrc,pedg,pdst,src_pitch,edg_pitchp,edg_pitchn,y_limit_min,y_limit_max,
x_limit_min,x_limit_max,i,depthH,depthV);

psrc += src_pitch4;
pedg += edg_pitch;
pdst += dst_pitch;
}*/
}
}

And using the following :

#SetMaxCPU("SSE2")
SetMaxCPU("AVX2")
ColorBars(width=640, height=480, pixel_type="yv12").PlaneToY("Y")
#convertbits(16)
awarp4(Spline36Resize(640*4,480*4),asobel(thresh=255).ablur(),depth=6,threads=1,cplace="MPEG2")
convertbits(8)

So, first, with AVX2, i have expected good display.
Then, switch to SSE2, i have different improper display. Meaning there is directly something wrong with the C code and SMALG=2 should it be 8 or 16 bits. Right now, that's not the issue.
Then, i switch back to AVX2 and... still have improper display. It's like i'm stuck to SSE2, and can't go up again to AVX2.
I think there is an issue with SetMaxCPU, or i'm doing something wrong ?
Script is loaded with VirtualDub, avs is 3.7.0.

pinterf

6th April 2021, 12:59

For investigating purpose, i've done the following :

I think there is an issue with SetMaxCPU, or i'm doing something wrong ?
Script is loaded with VirtualDub, avs is 3.7.0.
It can be that in order to take SetMaxCPU in effect, you have to exit VirtualDub to release Avisynth environment fully? I've just run into this problem today that it's not enough to F2-reload after a script edit after I changed SetMaxCPU line.

pinterf

6th April 2021, 13:06

@wonkey_monkey or others
Why is it that the float-integer conversions are using 2^N factor instead of (2^N)-1? E.g. to get a 16 bit signed integer value the original 32 bit float sample is multiplied by 32768 and not 32767? Looking around the net (WAV float-int conversions) I can see mostly (2^N) - 1 examples. The 32 bit floating point range -1.0 to 1.0 is not symmetric in a strict sense.
The other thing I found that the float-int conversions now omit the +0.5 rounding before goint into the integer domain - at least the C code
(the whole audio format conversion was rewritten last year)

wonkey_monkey

6th April 2021, 13:56

No idea I'm afraid. Whatever way you choose there will always be an argument that it's "wrong" - if you multiply by 32768 you (very slightly) clip the positive, if you multiply by 32767 you don't reach the negative maximum. If you expand to fit [-32768,32767] exactly, you move your 0 point.

The other thing I found that the float-int conversions now omit the +0.5 rounding before goint into the integer domain - at least the C code
(the whole audio format conversion was rewritten last year)

I think the SSE/AVX2 instructions do this automatically, though it may use banker's rounding (round x.5 to the nearest even number, up or down) instead of rounding up (I'm not sure if you can change the default but you can explicitly do the rounding yourself first before converting). It's another tricky one - banker's rounding is statistically fairer (no overall upward bias), but could potentially lead to aliasing, if every sample happened to fall on a 0.5 (e.g. [1.5, 2.5, 3.5, 4.5, 5.5] would round to [2.0, 2.0, 4.0, 4.0, 6.0]. I've been using it in all my video filters of late and I just treat as a sort of built-in dithering (if I'm not already doing my own dithering).

pinterf

6th April 2021, 14:03

I think the SSE/AVX2 instructions do this automatically, though it may use banker's rounding (round x.5 to the nearest even number, up or down) instead of rounding up (I'm not sure if you can change the default but you can explicitly do the rounding yourself first before converting).
SSE routines are using cvttps (double t: truncate, same as the int typecast in C). Former code was using integer_value = (int)(floating_pt + 0.5f) (after saturation check), now the plus 0.5 is gone.

wonkey_monkey

6th April 2021, 19:58

Well it certainly won't make an audible difference. Personally I'd go for cvtps - the tiny bias towards even numbers is statistically fair, and is not going to be audible (how often are two neighbouring .5 float samples likely to crop up? And even if they do, it's parts-in-billions), particularly if you're using it (as is currently done but with doubles) as the first step for converting to the lower bit-depths.

Edit: that missing 0.5 is causing a slight "visible" bias to waveforms when converting to 8-bit compared to 3.6.1. Not sure about 16-, 24-, and 32-bit yet as I'm having other problems of my own with those.

PS Does anyone know the logic behind this behaviour of Amplify():

8bit and 24bit audio is converted to float; the other audio formats are kept as they are.

?

pinterf

7th April 2021, 08:42

PS Does anyone know the logic behind this behaviour of Amplify():
"8bit and 24bit audio is converted to float; the other audio formats are kept as they are."
?
The Amplify routines were written only for int16, int32 and float. The rest two formats (8 and 24 bits) are converted to float (better than nothing)

tebasuna51

7th April 2021, 09:50

The Amplify routines were written only for int16, int32 and float. The rest two formats (8 and 24 bits) are converted to float (better than nothing)

One more time: All Avisynth audio internal or external filters than involve volume changes must operate only in float format.

It is not "better than nothing" is the correct way.

Amplify, ConvertToMono, MixAudio, MonoToStereo, Normalize, ResampleAudio, SuperEQ, SSRC and TimeStretch must work always in float format.
The user is free to use the ConvertAudioTo any int format if desired, most the times unnecesary because players or encoders accept float samples without problems.

Preserve int format is usefull for lossless manipulation, but when a volume change is done the audio is lossy now, and does not make sense preserve int format.

pinterf

7th April 2021, 10:35

Then it's the user's (bad) choice when he is using integer audio formats?

tebasuna51

7th April 2021, 11:21

Maybe the user don't know than is a bad choice (lose precission, risk of clip) manipulate the volume with int formats.

Is always better operate with float samples and recover the int format at end if is necesary ( I can't imagine for what).

wonkey_monkey

7th April 2021, 11:32

Well either they should all preserve the input format, or they should all convert to float - although the latter would, in my opinion, violate the Principle of Least Astonishment (https://en.wikipedia.org/wiki/Principle_of_least_astonishment). I spent a little while last night tracking down what I thought was a bug in my filter that only seemed to affect 8-bit and 24-bit audio, but it was actually a problem with float audio because I had used an Amplify().

After all, the levels video filter doesn't convert to high bit depth, and nor would anyone expect it to. If users want higher resolution they should convert explicitly first. Most of my recent video filters convert to float internally but always convert back to the input format (with dithering) - except for YUY2, aka the Freak Colourspace.

tebasuna51

7th April 2021, 12:53

Well either they should all preserve the input format...

In audio there are some input classes:

- lossy formats (MP3, AC3, DTS, AAC,... ). The decoders always output float samples, if aren't requested to downsample the output.
There are users than don't know that, and ask about AC3 16 bits or DTS 24 bits when lossy formats don't have bitdepth, and doesn't make sense convert that float samples to int.

- 8 bits int (PCM or equivalent, rare cases): can be converted to float, manipulate it and reconvert to 8 bits int without lose that poor quality.

- 32 bits int: I never see a real sample, only useless experiments (the human ear can distinguise only until a 20 bit precission).

- 16/24 bits int PCM or lossless encoded (FLAC,TrueHD,DTS-MA,...) only functions than remain the volume unchanged (AudioTrim,DelayAudio, Get/MergeChannels) must preserve the input format, other functions deceive the user, than can think have still a lossless audio when is already lossy or even distorted by clip.

Only that last case is relevant for the discussion, we can lie the user with the Principle of least astonishment, or follow the correct way already used in AviSynth (http://avisynth.nl/index.php/Internal_filters#Audio_processing_filters): "Audio samples will be automatically converted if any filters requires a special type of sample."

And include Amplify, ConvertToMono, MixAudio, MonoToStereo, Normalize, ResampleAudio to only manage Float samples.

My 5 cent. for Avs+ audio development.
If you want other 5 cent. include ChannelMask like audio property instead NumChannels.

Boulder

7th April 2021, 15:11

StvG

7th April 2021, 16:04

Any ideas why Asd-g's GMSD and MDSI functions don't get any benefit from multithreading? I just tested one clip with AVSMeter and without Prefetch, got avg 6.81 fps and with Prefetch(24,1), 6.66 fps. Average CPU usage 23,3% / 26,1% respectively.

https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/GMSD.avsi
https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/MDSI.avsi

EDIT: with Prefetch(threads=24, frames=10), 2.37 fps / 34,1% :(

Without prefetch:
Frames processed: 442 (0 - 441)
FPS (min | max | average): 10.76 | 50.43 | 43.85
Process memory usage (max): 321 MiB
Thread count: 66
CPU usage (average): 7.4%

Time (elapsed): 00:00:10.081

With prefetch(8):
Frames processed: 1750 (0 - 1749)
FPS (min | max | average): 47.45 | 987.9 | 172.3
Process memory usage (max): 580 MiB
Thread count: 74
CPU usage (average): 65.9%

Time (elapsed): 00:00:10.156

Boulder

7th April 2021, 16:24

Script based on my Zopti script:
SetCacheMode(0)
orig = FFVideoSource("c:\zopti\lotr_fotr.avi").AssumeFPS(24000./1001)

b = -75/100.0 # optimize b = _n_/100.0 | -150..50 | b
c = 15/100.0 # optimize c = _n_/100.0 | -100..100 | c

downscaled_width = 1920
downscaled_height = 808

alternate = BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())

GMSD(alternate, orig, show=true)

#prefetch(24)

AVSMeter 3.0.6.0 (x64), (c) Groucho2004, 2012-2020
AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Number of frames: 400
Length (hh:mm:ss.ms): 00:00:16.683
Frame width: 3840
Frame height: 1608
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P16

Frames processed: 400 (0 - 399)
FPS (min | max | average): 0.980 | 8.501 | 7.318
Process memory usage (max): 865 MiB
Thread count: 41
CPU usage (average): 25.0%

Time (elapsed): 00:00:54.661

With Prefetch(threads=24, frames=1):
AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Number of frames: 400
Length (hh:mm:ss.ms): 00:00:16.683
Frame width: 3840
Frame height: 1608
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P16

Frames processed: 400 (0 - 399)
FPS (min | max | average): 0.116 | 30.55 | 6.887
Process memory usage (max): 1044 MiB
Thread count: 65
CPU usage (average): 27.0%

Time (elapsed): 00:00:58.078

The testclip is FFV1 encoded.

StvG

7th April 2021, 16:57

To use prefetch efficiently you should start with prefetch(x) where x is 2 and increase by 2 until find the most efficient value.
Here quick example with similar to your script:

Without prefetch:
orig=ffvideosource("001.mkv").ConvertBits(16) #source is 10-bit HEVC
downscaled_width = 1920
downscaled_height = 1080
b=1/3.0
c=1/3.0
b=BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())
gmsd(b, orig)
Number of frames: 1350
Length (hh:mm:ss.ms): 00:00:56.306
Frame width: 3840
Frame height: 2160
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P16

Frames processed: 28 (0 - 27)
FPS (min | max | average): 2.269 | 3.377 | 2.797
Process memory usage (max): 1639 MiB
Thread count: 46
CPU usage (average): 5.9%

Time (elapsed): 00:00:10.009

With prefetch:

orig=ffvideosource("001.mkv").ConvertBits(16) #source is 10-bit HEVC
downscaled_width = 1920
downscaled_height = 1080
b=1/3.0
c=1/3.0
b=BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())
gmsd(b, orig)
prefetch(4)
Number of frames: 1350
Length (hh:mm:ss.ms): 00:00:56.306
Frame width: 3840
Frame height: 2160
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P16

Frames processed: 73 (0 - 72)
FPS (min | max | average): 1.091 | 256416 | 7.141
Process memory usage (max): 1961 MiB
Thread count: 50
CPU usage (average): 38.9%

Time (elapsed): 00:00:10.223

pinterf

7th April 2021, 17:26

I think with the frames=1 you have just serialized the process. Default value for frames is threads*2, see Avisynth wiki on Prefetch

Boulder

7th April 2021, 17:47

To use prefetch efficiently you should start with prefetch(x) where x is 2 and increase by 2 until find the most efficient value.
Yes, I know how it works, having tested it quite a lot when I switched back to Avisynth from VapourSynth. It works just fine in my normal encoding cases but this Zopti issue has got me baffled.

I think with the frames=1 you have just serialized the process. Default value for frames is threads*2, see Avisynth wiki on Prefetch

With my go-to settings of Prefetch(threads=24, frames=10) (fastest when encoding with x265), it gets just ridiculously slow. 2.35 fps / 32,1% this time.

Boulder

7th April 2021, 18:07

I think I may have found the problem. My test clip is produced by using these:

SelectEvery(920, 1)
Trim(3, 202)

When encoded with ffmpeg, it gives the clip a very strange framerate instead of the original one.

If the clip is decoded with orig = FFVideoSource("c:\zopti\silverado.avi"), it's slow as molasses but opens normally in VDub.
If it's decoded with orig = FFVideoSource("c:\zopti\silverado.avi",fpsnum=24000,fpsden=1001), it's very fast but it keeps on processing beyond the clip length, which is 200 frames. I checked the output in VDub, and it's actually repeating the same frame for the amount of frames that was in the original SelectEvery call :D

So where is the actual problem? I tested LWLibavVideoSource as well, same problem there.

You can find a testclip here:
https://drive.google.com/file/d/1fuVEx4bNDA6UFISaDFxAX7u0f_I0tQ2U/view?usp=sharing

StvG

7th April 2021, 18:12

Yes, I know how it works, having tested it quite a lot when I switched back to Avisynth from VapourSynth. It works just fine in my normal encoding cases but this Zopti issue has got me baffled.

You wrote in the first post:
Any ideas why Asd-g's GMSD and MDSI functions don't get any benefit from multithreading? I just tested one clip with AVSMeter and without Prefetch, got avg 6.81 fps and with Prefetch(24,1), 6.66 fps. Average CPU usage 23,3% / 26,1% respectively.

https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/GMSD.avsi
https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/MDSI.avsi

EDIT: with Prefetch(threads=24, frames=10), 2.37 fps / 34,1% :(

I was curious and tested.
Those scripts benefit of mt.
It seems you have additional filters/processing in the script?
Did you try with prefetch(4):
SetCacheMode(0)
orig = FFVideoSource("c:\zopti\lotr_fotr.avi").AssumeFPS(24000./1001)

b = -75/100.0 # optimize b = _n_/100.0 | -150..50 | b
c = 15/100.0 # optimize c = _n_/100.0 | -100..100 | c

downscaled_width = 1920
downscaled_height = 808

alternate = BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())

GMSD(alternate, orig, show=true)

prefetch(4)

Boulder

7th April 2021, 18:16

I was curious and tested.
Those scripts benefit of mt.
It seems you have additional filters/processing in the script?

Please see the previous post, it's definitely an issue caused by the source clip confusing the decoder. I don't know how it gets worse with multithreading because source decoding should be serialized anyway.

Richard1485

7th April 2021, 19:58

If you want other 5 cent. include ChannelMask like audio property instead NumChannels.

That would be very useful.

StvG

8th April 2021, 15:05

Please see the previous post, it's definitely an issue caused by the source clip confusing the decoder. I don't know how it gets worse with multithreading because source decoding should be serialized anyway.

Yes, I can reproduce the issue with your sample.

kedautinh12

12th April 2021, 01:25

New hqdn3d support HBD
https://github.com/Asd-g/hqdn3d

tebasuna51

12th April 2021, 12:16

4 post not related with Avs+ moved to why MP2 files are decoded as s16? (https://forum.doom9.org/showthread.php?t=182724)

They are related with audio decoders plugins behaviour also with standard AviSynth.

vcmohan

26th April 2021, 07:23

Fieldbased vs Framebased:-
If I go through avisynth+ documentation ( assumeFieldbased(), assumeFramebased, seperateFields() , get impression that a frame of clip will consist of 2 fields. If seperateFied() was used it becomes fieldbased. For progressive input possibly assumefieldbased need to be used. In the plugin code vi.IsFieldBased() will give true. But when I querry each frame property then _FieldBased will be 0. Some confusing notation.
I looked into code of avsresize to understand how frame properties could be accessed. Then I noticed this code:
// TODO: support interlaced video through dual filter graphs.
if (v8 && env->propNumElements(props, "_FieldBased") > 0 && env->propGetInt(props, "_FieldBased", 0, nullptr) > 0)
throw_error("clip must be frame-based");
if (vi.IsFieldBased())
throw_error("clip must be frame-based"); The message one will get is not in line with the documentation I cited above. If one uses assumeFrameBased() script call how does this change?
I have also some problem of coding for getting frame properties in GetFrame section.. I had to use following which I thought as strange
PVideoFrame src = child->GetFrame(in, env);
// did not compile
//AVSMap * srcprop = src->getProperties();
AVSMap& srcprop = src->getProperties();
if (v8 && env->propNumElements(srcprop&, "_FieldBased") > 0 && env->propGetInt(srcprop&, "_FieldBased", 0, nullptr) > 0)
env->ThrowError("clip must be frame-based");
Is it the correct way to get frame properties?
On going through the avsresize code I found the following code
for (int p = 0; p < planes; ++p)
env->BitBlt(ret->GetWritePtr(p), ret->GetPitch(p), frame->GetReadPtr(p), frame->GetPitch(p), frame->GetRowSize(p), vi.height);
As the height of a plane can also change why v.height was used?

pinterf

27th April 2021, 09:53

On going through the avsresize code I found the following code
for (int p = 0; p < planes; ++p)
env->BitBlt(ret->GetWritePtr(p), ret->GetPitch(p), frame->GetReadPtr(p), frame->GetPitch(p), frame->GetRowSize(p), vi.height);
As the height of a plane can also change why v.height was used?
Good catch. It won't work properly but fortunately in Avisynth+ the alignment is always O.K., so it will never run.

pinterf

27th April 2021, 10:05

I have also some problem of coding for getting frame properties in GetFrame section.. I had to use following which I thought as strange
PVideoFrame src = child->GetFrame(in, env);
// did not compile
//AVSMap * srcprop = src->getProperties();
AVSMap& srcprop = src->getProperties();
if (v8 && env->propNumElements(srcprop&, "_FieldBased") > 0 && env->propGetInt(srcprop&, "_FieldBased", 0, nullptr) > 0)
env->ThrowError("clip must be frame-based");
Is it the correct way to get frame properties?

Did not try but you have to implement something like this.
We are using variable 'error' which can flag success (frame property with index==0 exists)

PVideoFrame src = child->GetFrame(n, env);
if(v8) { // use frameprop calls only when supported
const AVSMap* avsmap = env->getFramePropsRO(src);
int error = 0;
int64_t result = env->propGetInt(avsmap, "_FieldBased", 0, &error);
if(error != 0 || result > 0) // not exists or >0
env->ThrowError("clip must be frame-based");
}

vcmohan

27th April 2021, 13:10

Thanks. I want a progressive or a field separated input frame. In the script I querry isfieldseparated() or use assumefieldbased(). Framebased will mean the clip has interleaved fields. The error message in script is Frame based input is not allowed. But in coding for each frame the message will be input is fieldbased not allowed, or input must be framebased. These two are contradictory. Can the property _Fieldbased be altered to _Progressive or some such?

wonkey_monkey

3rd May 2021, 22:32

Is there any way for a filter to get information about other filters, for example their AddFunction parameter strings, or the short description that is returned at the end of AvisynthPluginInit3?

It occured to me that there's no built-in help for filters. I thought about writing a "Help" filter which you could call and would then tell you - either by throwing an error or generating a clip with text - about the filter you've asked it about, e.g.:

Help("FlipVertical")

...would return the short description plus a description of its parameters.

Another idea I had is that it could check for a filter called, according to a convention, something like "_help_[filtername]" (to be implemented by filter authors) which could return longer help text.

StainlessS

4th May 2021, 02:07

AvisynthPluginInit3(), I thought that it should return some info on filter name, however, some dll's return a string, some an int (0),
and not sure but think some may return void. [so basically not of much use for anything].

The Help() thing is a real good idea.
These functions from RT_Stats,

RT_InternalFunctions()
Returns String, SPACE separated list of internal filter and function names.
Returns "", if cannot find InternalFunctions.
If you like a good read try this:-
S=RT_StrReplace(RT_InternalFunctions," ",Chr(10))
ColorBars.ScriptClip("""RT_Subtitle("%s",S,align=5,y=height+100-current_frame,expx=true,expy=true)""").killaudio

***
***
***

RT_PluginFunctions()
Returns String, SPACE separated list of external filter and function names.
Returns "", if cannot find PluginFunctions.
If you like a good read try this:-
S=RT_StrReplace(RT_PluginFunctions," ",Chr(10))
ColorBars.ScriptClip("""RT_Subtitle("%s",S,align=5,y=height+100-current_frame,expx=true,expy=true)""").killaudio

***
***
***

RT_PluginParam(String FunctionName)
FunctionName, String, name of Avisynth built-in or Plugin filter or function name.
Returns "", if FunctionName Parameter string not found.
Returns String, the Avisynth CPP Interface style argument specifier string used by Avisynth to determine 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
To show params:-
colorbars().Killaudio()
S=RT_PluginParam("RT_YStats")
S=RT_StrReplace(S,"[",Chr(10)+"[")
RT_Subtitle(s)

Also, 3 functions in RT_Stats AVS/FunctionLists/ folder for extracting
1] All builtin function prototypes,
2] All RT_Stats prototypes,
3] Prototypes for a dll in plugins directory. [dll is selected via FileSelector dialog box]

See source of RT_Stats, and the AVS scripts too.

however, where multiple alternative prototypes, we can only extract the first one, others dont seem to be exposed.
So, a Help() whotsit with mutliple alternatve prototypes extractable, would be a real good idea.
[eg AvsPMod (and others) could interogate valid prototypes to give user assistance, in them little yellow floating text box thingies. EDIT: Tooltips]

vcmohan

6th May 2021, 14:34

I think I asked about the MT nomeneclature and meanings long time back. But I am repeating as it is somewhat confusing to me. As I understand:
MT_SERIALIZED ensures that input and output from plugin is in serial order of frames. No multi threading whatsoever.
MT_MULTI_INSTANCE ensures that only one instance of plugin operates at any time. Therefore buffers created by constructor with pointers in class, can be safely used as temporary work to read and written by GetFrame method. The input and output can be in any order.
MT_NICE_FILTER input/ output can be in any order. several instances of GetFrame may be present simultaneously. Dangerous to use Class variables for writing.
My freq domain functions use FFTW dll which is not thread safe. While for those requiring visual inspection of output frame, I am using MT_SERIALIZED. For rest I am using MT_MULTI_INSTANCE. Is this correct way?
Instead of late binding of the DLL at run time, I have created the lib file using the def and dll. By including this in additional dependencies in link section of VC++ 2019, I am able to compile. Whether this can be thread safe?

vcmohan

8th May 2021, 13:42

I read through avisynth wiki on the multi threading nomeneclature. I think it needs some editing. There are comments like "a bad programmer keeps in class' for MT_SERIALIZED and "large buffer space required" for MT_MULTI_INSTANCE and not much explanation for MT_NICE_FILTER. I am forced to use MT_SERIALIZED for my freq domain functions as the fft dll does not support multi threading. In that case I use buffers created by constructor. In other cases for large memory requirements can request env->Allocate. I do not see much problem. I am sure a MT_NICE_FILTER can also use large memory through env->Allocate.

Morku

8th May 2021, 19:23

Someone experience something similiar?
When processing a videofile with AviSynth, it starts fine, but stops at a completely random moment without error. The processed frames won't rise anymore, the remaining time goes up forever, HDD usage stops, no CPU workload anymore. It just stops, without any error but going 'further'. As my PC got tired to do.

First I thought, it's maybe my HDD Dock, so I copied the file on my internal SSD, but same issue. Maybe I thought it's MeGUI, so I processed the file with VirtualDub2, but same issue...
So my best guess is the Avisynth/Plug-ins I use. I try to have anything up to date.
For example encode som BD content always works fine and finish.
LoadPlugin("D:\Sonstiges\Videotools\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
DGSource("E:\video.dgi")
ConvertBits(8)

And thats the script with the "sporadic issue":
global MeGUI_darx = 160
global MeGUI_dary = 117

AVISource("a.avi", audio=true).AssumeFPS(25,1)

AssumeTFF()
top = Crop(0,0,-0,288)
bot = Crop(0,289,-0,-0).AddBorders(0,0,0,1)

StackVertical(top,bot)

QTGMC(Denoiser="dfttest", Preset="slow", EdiMode="NNEDI3", EdiThreads=8, Sharpness=1.0)

ConvertToYV12()

__film = last
__t0 = __film.trim(134, 281048)
__t0

This is my Avisynth Info Tool Logfile:
https://pastebin.com/C3qSz3RU

Every AVSI Script should be up to date from realfinder GitHub repo.
The source file is UT video avi 720x576 25fps YUV 4:2:2, PCM 48.0kHz stereo

I don't know how to specify and analyze any further. Since I am rarely encoding this way (but update frequently), I can't tell when it started to happen. Any idea what I could do is appreciated.

FranceBB

9th May 2021, 10:25

Nope, it doesn't happen on my end.
The only time it does actually happens is if I'm encoding with an executable remotely located on the network and there's a network problem on a switch, but again that's a rare scenario.

Can you try to give your AVS Script a spin with AVSMeter and see if it happens there as well?

Morku

9th May 2021, 11:12

Yes, it also happen in AVSMeter. But instead of rising ETA, adjust FPS cur = 0 (like MeGUI, VDub2) all counters just stop. "Freeze". And pressing Esc at this step, won't cancel the process and go back to cmd start. The point (processed frames) is completely random, but for this example mostly somewhere at the beginning.
Tried now an utvideo version 20.6.1 from a year ago and shorten the QTGMC to "QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)", but still the same issue.

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

It's odd...

manolito

9th May 2021, 11:36

How many AVS+ MT threads are you using? I don't see a Prefetch command in your script.

If you use more than 8 threads then I would try to lower the thread number in the prefetch command.

Another thing which worked wonders for me is to force linear access to some filters. I would add
RequestLinear(rlim=50, clim=50)
right after the source filter and also after the QTGMC call because dfttest needs fftw3 which is not thread safe.

FranceBB

9th May 2021, 11:41

Another thing which worked wonders for me is to force linear access to some filters. I would add
RequestLinear(rlim=50, clim=50)
right after the source filter

Yep it helped me long ago for a thing, so I would recommend it too.

@Morku... let us know, but this is indeed odd. I'm trying to pinpoint whether it's a decoding issue or if one of the filters is to blame.
Out of pure curiosity, can you make some more tests?

Test 1:

AVISource("a.avi", audio=true)

just that to see if it stops.
If it doesn't, then it's not the source, but it's one of the filters and indeed RequestLinear() as suggested by Manolito can help, so make another test with it.

Test2:
AVISource("a.avi", audio=true)
RequestLinear(rlim=50, clim=50)

#rest of the script

as suggested by Manolito.
It will slow things down a bit, but it might help.

Test 3:

FFMpegSource2("a.avi", atrack=-1)

what happens if you swap the indexer? (I know that UTVideo videos are not supposed to be indexed, but again, I'm trying to pinpoint what's causing the issue).

Feel free to make all these tests in AVSMeter so that you don't have the additional nag on your CPU to actually encode a file...

Morku

9th May 2021, 17:24

@manolito
How I can find out? I am not that knowledged that way.

Test 1: Finished successfully: https://i.imgur.com/ZOSMxfp.png
Test 2: Stopped at a very late point this time. Might be coincidence? https://i.imgur.com/yOqqYvi.png
global MeGUI_darx = 160
global MeGUI_dary = 117

AVISource("3.avi", audio=true).AssumeFPS(25,1)
RequestLinear(rlim=50, clim=50)

AssumeTFF()
top = Crop(0,0,-0,288)
bot = Crop(0,289,-0,-0).AddBorders(0,0,0,1)

StackVertical(top,bot)

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

ConvertToYV12()

__film = last
__t0 = __film.trim(134, 281048)
__t0
Test 3: Stopped at a very early point... https://i.imgur.com/FpjF9Dn.png
global MeGUI_darx = 160
global MeGUI_dary = 117

FFMpegSource2("3.avi", atrack=-1).AssumeFPS(25,1)
RequestLinear(rlim=50, clim=50)

AssumeTFF()
top = Crop(0,0,-0,288)
bot = Crop(0,289,-0,-0).AddBorders(0,0,0,1)

StackVertical(top,bot)

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

ConvertToYV12()

__film = last
__t0 = __film.trim(134, 281048)
__t0

StainlessS

9th May 2021, 17:31

You could start by removing lines from the script,eg
MeGUI darx/y dont really need to be in there, and just adds extra fluff to the mix.

How bout

FFMpegSource2("3.avi", atrack=-1).AssumeFPS(25,1)

AssumeTFF()

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

ConvertToYV12()

If works ok, then start adding stuff back until problem. [EDIT: add back trims last]
EDIT: What version AVS+, and what version QTGMC.

EDIT: Is the height of the original clip ODD ?
(why add 1 to bottom, and deinterlace on originally odd height ???)
EDIT: No, I'm wrong, on bot clip you crop top scanline of bot, then add line to bottom of bot, but still a bit weird.

EDIT: Avoid RequestLinear if you are trying to find the bug [rather than hide it].

Morku

9th May 2021, 19:12

Tried now the very basic:
AVISource("3.avi", audio=true).AssumeFPS(25,1)

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

and it stopped at 12min proceed video.

Avisynth is 3.7.0_20210111 and QTGMC v3.379, Zs_RF_Shared v1.152.

Well the sourcevideo is even and odd. I have to add bottom one, because cropping 289 won't work for chroma resolution I think. But this seems not to be the reason.

I wouldn't wonder if this is just another Windows 2004 issue. This release brought other bugs. Worst release ever.
Otherwise I would expect an error. I can even eject the HDD, because it's not in use anymore. All the Avisynth programs won't notice that the source is missing when the issue occur. Can't wait to see 21H2.
I can't remeber to had an issue like that with 1909 and prior und use the script for years (since Windows 8).

I might test older AVS releases and if I can find for QTGMC.

StainlessS

9th May 2021, 20:29

I've tried MEGUI [probably not an up to date version] on W10, and every now and again it just disappears with no error in log, think there was some AVS wrapper problem or something with current AVS+].

and it stopped at 12min proceed video.
MeGUI or AvsMeter, or what
Yes, maybe try alternate version of QTGMC..

I'm currently screwing around with W10, trying to install 1909 on Linx 7 (1GB RAM, Win8.1) tablet, no memory for RAM disk error.
Can update from within W8.1, but not clean install from USB ISO.

real.finder

9th May 2021, 20:33

Tried now the very basic:
AVISource("3.avi", audio=true).AssumeFPS(25,1)

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

try with ColorBars(width=720, height=576, pixel_type="yv16").AssumeFPS(25,1)

QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

Morku

9th May 2021, 22:21

I reverted to AviSynth 3.5.1_20200402 and QTGMC 3.364 and it was looking promissing for a long time... but "failed" (stopped) again almost near the goal :( https://i.imgur.com/00NuHgZ.png

@StainlessS
All my last tests were with AVSMeter and I whish there would be error logs in MeGUI. But the Status window just stay there, Time remaining rise up, Current frames stop at a random point. Like an endless encoding.

Tomorrow I will update AVS and QTGMC to latest and test real.finder advise, but I don't have high hopes. Thanks to all.

real.finder

9th May 2021, 22:54

in general the problems come from dlls not avsi, QTGMC is avsi so update it or downgrade it probably will not do big change in this case

LigH

10th May 2021, 08:03

@Morku:

Just to add confidence in the source: VirtualDub has a "Scan for errors" command in the "Video" menu, which will decode the source quickly without any processing, useful for AVIs in doubt.

But if you say it's a random position, it is probably rather some processing issue. Does it completely stop, or is the harddisk very active (like swapping RAM), are there even noises of retrying access? Even if not the video file, maybe a swap file...

Morku

10th May 2021, 09:02

Scanning for errors says, all fine:
https://i.imgur.com/5hFOwkK.png
Yes, the avs processing (unreleated to the encoding) just directly stop. There is no slowing down, warnings etc. ahead. The processing never finish, because it stops at a random frame count. There is also no more HDD activity (to read the avi) anymore. The onliest activity on this HDD is for Avisynth/Encoding. The HDD itself is still accessible and works fine when the issue occur. I can continue working normally on HDD. There are also no related errors in Windows eventviewer when the issue occur. It's only the avisynth processing which stops. My HDD Dock will bring the HDD even in sleep mode, because there is no more activity "during the progress".
But as said, I copied the video on my internal SSD with the same result, so this should be unreleated to the dock and used HDD.

Tried with ColorBars -> same issue.
Now I started to downgrade MVTools, MaskTools, RgTools, JPSDR tools one version by one. Tried 2 previous version with... same issue :|

real.finder

10th May 2021, 09:19

Morku, I note that you have avstp.dll, delete it and try

StainlessS

10th May 2021, 12:48

It would be a good idea to remove to a BackUp folder, all plugins not required by QTGMC, and retry on Colorbars.

If bug gone, continue using Colorbars, add back some dll's until problem returns, keep log of plugins added back, remove/addback
to narrow down problem plugin.

EDIT: Remove all plugins except those requred by QTGMC(Preset="Medium", EdiMode="NNEDI3", Sharpness=1.0)

Morku

10th May 2021, 13:21

I think real.finder found the issue =)
I removed avstp.dll and it's the first time AVSMeter finished the video.

So I updated my dll files back to latest, loaded my original Script and directly run a MeGUI encoding and it finished as well!
Thank you so much!

I didn't thought the reason could be found with that odd issue. Also it never occur before.

manolito

10th May 2021, 14:50

Interesting...

I never had a problem with avstp.dll, probably because I followed a recommendation by almosely.
https://forum.doom9.org/showthread.php?p=1865279#post1865279
The relevant information is in the third paragraph of the post.

At the end of any MT enabled script I have this:
avstp_set_threads(1)
Prefetch(Min(Int(Value(GetSystemEnv("NUMBER_OF_PROCESSORS"))),8))

The prefetch command was inspired by Myrsloik, and for my Core i5 (2 physical cores plus Hyperthreading) this results in a prefetch value of 4.

real.finder

10th May 2021, 17:24

Dogway

10th May 2021, 20:07

Is this by design?
expr(" sx width / range_size * ", "range_half","range_half", scale_inputs = "none" )
Creates a PC levels ramp.

ConvertBits(16)
expr(" sx width / range_size * ", "range_half","range_half", scale_inputs = "none" )
Creates a TV levels ramp.

EDIT: Might be avspmod related (https://forum.doom9.org/showthread.php?p=1942719#post1942719).

pinterf

11th May 2021, 12:51

that mean it's mvtools bug with avstp.dll

We know nothing about the problem other than removing avstp dll from behind a complex script stopped random freezing after some hundred thousand frames.

I suppose Morku is the only one with such experiences, and would like to help solving the issue :)

You can report it for me or for anyone but if something is not reproducible then it will be unanswered for sure.

- monitor processor temperature (though using avsmeter w/o encoding doesn't seem to have much burden on the processor)
- keeping avstp there in its place (which version?), then
- start providing mt=false parameters one-by-one for the appropriate mvtools functions (I don't know what is used in the actual script, probably MAnalyze, MDegrain, MSuper? which have such mt parameter which can be disabled. See mvtools html docs)
- Run qtgmc with parameters which do less and less things inside.
- or build a script from zero until you experience the freeze

Morku

11th May 2021, 17:24

I would like to help to solve the issue, but from current perspective I think it's a waste of time.
I copied back avstp.dll (1.0.4 x64 btw.) and guess what... I run the script in AVSMeter and it finished fine again. This makes it suspicious if removing avstp.dll really was the issue. But it was the onliest I changed on my system to solve it.

Also other utvideo avi with QTGMC and shorter runtime (a 20 minutes video, 30 minutes video, 10 minutes video) directly encoded fine before I had the trouble with that longer time video (90 minutes) which stopped processing mostly after 8-15 minutes of video.

If I could see in detail whats going on in background and 'whatever part of my PC stops for no reason'... it could be helpful.

Temperature during AVSMeter was about under 60°C on my CPU (HWiNFO).

If there is anything you might think I could test, please let me know, I will do, but you might need show me in detail what to change and load.
Now, I will keep avstp.dll just to see if the issue reoccur and if deleting avstp.dll will solve it again.
In 30 minutes is Patchday. Pretty sure this time Microsoft will solve all Windows 10 bugs ;)

mp3dom

11th May 2021, 23:44

I have the same issue here, and happens with plain QTGMC() (preset medium without any other parameter) and something more complex. On VDub I get the error that it's waiting the frame without success and ask me if I want to wait more. Obviously it stays there forever. If I abort the process then Vdub crash.

I actually have avstp but I'm not calling it in any way (it's not in the autoload folder, I have nothing in autoload besides the default 4-5 plugins installed by default by Avisynth).
I'll try on my side as well and report back (I'm using QTGMC intensively lately). Didn't report earlier because no one reported similar issue, I thought it was my fault or my configuration error...

It's very difficult to "reproduce" because sometimes it happens and sometimes not, even with the same file. Sometimes 1 time every 5, and sometimes 2-3 times every 5. It seems quite "random".

real.finder

12th May 2021, 04:09

mp3dom

14th May 2021, 10:50

Indeed, without avstp at all I've batch-processed more than 20 files (at 25min each on average) without any issue... and never encounter this success-rate before.
Avstp version used was 1.0.4 (the last compile from 2020/2021)

Morku

15th May 2021, 19:25

Good to know I am not alone with that odd issue and more importantly, I am not insane :)

real.finder

15th May 2021, 20:50

ok then, since QTGMC is huge, maybe start test with

super = MSuper()

bv2 = super.MAnalyse(isb = true, delta = 2, overlap= 4)
bv1 = super.MAnalyse(isb = true, delta = 1, overlap= 4)
fv1 = super.MAnalyse(isb = false, delta = 1, overlap= 4)
fv2 = super.MAnalyse(isb = false, delta = 2, overlap= 4)

MDegrain2(super, bv1, fv1, bv2, fv2, thSAD=300, thSADC=150)

sofakng

19th May 2021, 19:54

Does AviSynth (+) support DXVA2 or D3D11 hardware decoding?

I'm confused on how my system is playing back videos...

Here is my configuration:

- Windows 10 x64 (Nvidia GTX 3080 / Intel i7-8700K @ 5.0 GHz)
- LAV Filters v0.75
- AviSynth+v3.7.0
- AviSynth Filter (https://github.com/CrendKing/avisynth_filter) v1.0 (no scripts loaded)
- MPC-HC v1.9.8.75 (with AviSynth Filter enabled with 'Preferred' but no scripts loaded)

If I select 'D3D11' (native or copy-back) with LAV then I get a black screen.
If I select 'DXVA2' (native or copy-back) it works but is extremely slow with 7K or 8K video.

The only method I can successfully play 7K or 8K is using D3D11 (native) or DXVA2 (native).

1) Does AviSynth+ support D3D11 hardware decoding in LAV Filters?
2) Does AviSynth+ force DXVA2 (native) into copy-back mode? For example, my 7K/8K videos playback perfectly with DXVA2 (native) but adding AviSynth Filter (but no scripts!) causes the playback to become extremely slow similar to copy-back methods.

LigH

19th May 2021, 20:57

Decoding is not a matter of AviSynth, but a matter of the used source plugins. AviSynth is a video filter and frame server, optimized for accuracy over speed. It is not a replacement for DirectShow decoders.

sofakng

20th May 2021, 14:26

OK - I understand that AviSynth is not a decoder (ie. I'm using LAV Filters with hardware decoding), but AviSynth needs access to the decoded frame for processing, right?

Does this mean AviSynth is NOT compatible with DXVA2 or D3D11 Native-mode? Does it require copy-back instead?

LigH

21st May 2021, 07:29

There are decoder plugins which may have access to DirectX accelerated decoders, e.g. DirectShowSource, or to decoders in specific GPU chipsets, like DGDecNV using Nvidia PureVideo. But then, AviSynth needs the frame content in main RAM. A decoder which does not return the frame content but displays it immediately (i.e. connects to a renderer directly) has no value for a frame server which is supposed to filter the frame content further.

In most cases, AviSynth is used to serve filtered video to an encoder. In your case, it seems you try to use AviSynth to filter a video in a media player in real time?

subterrestrial

28th May 2021, 15:11

Thank you for so much effort on avisynth. It really helps me a lot.
I want to report an error "0xC0000005: Access violation reading location" which occured when I was using AVS+ 3.70 with CUDA option enabled and the aWarpsharpMT or the previous aWarpsharp2 plugin.
In Nekopanda's avisynth script, there is a line " SetDeviceOpt(DEV_CUDA_PINNED_HOST) ".
According to the comment, it's for CUDA data transport optimization. When adding this line to the script, the error occurs with using aWarpsharpMT/2. If without using aWarpsharpMT/2, everything goes fine even when I add that line. I will test the efficiency diffenrence with or without the line later and report here.
Test result:encoding 2000 frames, the same script with " SetDeviceOpt " was running about 20.5fps, without " SetDeviceOpt " was about 18.7fps.
When a function using aWarpsharpMT was added to the script without " SetDeviceOpt ", it run at about 4fps, if all functions in the script were switched to CPU version to make it run completely in CPU, the result of which was about 6fps.

Another problem is the KDeblock function in KFM project doesn't work, which needs a QP_table argument passed from AMTsource function in Amatsukaze project to work properly.
(Amatsukaze.dll is included in Nekopanda's encoding GUI called Amatsukaze which also in his github repository. He applied some nice ideas to his KDeblock function. According to his description, KDeblock uses the same algorithms as SmoothD does, but it is much flexible and adaptive in using a switchable deblock intensity parameter according to the QP value of each block of the source calculated and stored in QP_table by an indexer named AMTsource. So I wonder if somebody can integrate the QP_table calculation function to the KDeblock to make it work or maybe make amatsukaze compatible with the new avisynth header file. I tried to compile the Amatsukaze project with the new avisynth header file and do some modification . But I'm just a beginner to learn programming. That job is beyond my capability for now.)

GMJCZP

28th May 2021, 17:47

I am having a serious problem with MT and Prefetch, I am using the latest version of mtmodes.avsi (although it is irrelevant since using it or not the situation does not change). Here I publish the AvsMeter reports for Prefetch (1) and Prefetch (2):

Prefetch(1):
Log file created with: AVSMeter 3.0.9.0 (x86)
Script file: Prueba.avs
Command line switches: -log

[OS/Hardware info]
Operating system: Windows 7 (x86) Service Pack 1.0 (Build 7601)

CPU: Pentium(R) Dual-Core CPU E5800 @ 3.20GHz / Wolfdale (Core 2 Duo) 2M
MMX, SSE, SSE2, SSE3, SSSE3
2 physical cores / 2 logical cores

[Avisynth info]
VersionString: AviSynth+ 3.7.0 (r3382, 3.7, i386)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 20:46:40 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files\AviSynth+\plugins+

[Clip info]
Number of frames: 162
Length (hh:mm:ss.ms): 00:00:06.757
Frame width: 640
Frame height: 480
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 162 (0 - 161)
FPS (min | max | average): 86.51 | 185.8 | 129.7
Process memory usage (max): 37 MiB
Thread count: 7
CPU usage (average): 68.3%

Time (elapsed): 00:00:01.249

[Script]
LWLibavVideoSource("Sample2.mp4")
AssumeFPS("ntsc_film")
Prefetch(1)

Prefetch(2):
Log file created with: AVSMeter 3.0.9.0 (x86)
Script file: Prueba.avs
Command line switches: -log

[OS/Hardware info]
Operating system: Windows 7 (x86) Service Pack 1.0 (Build 7601)

CPU: Pentium(R) Dual-Core CPU E5800 @ 3.20GHz / Wolfdale (Core 2 Duo) 2M
MMX, SSE, SSE2, SSE3, SSSE3
2 physical cores / 2 logical cores

[Avisynth info]
VersionString: AviSynth+ 3.7.0 (r3382, 3.7, i386)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 20:46:40 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files\AviSynth+\plugins+

[Clip info]
Number of frames: 162
Length (hh:mm:ss.ms): 00:00:06.757
Frame width: 640
Frame height: 480
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 162 (0 - 161)
FPS (min | max | average): 0.828 | 389652 | 8.301
Process memory usage (max): 41 MiB
Thread count: 8
CPU usage (average): 82.7%

Time (elapsed): 00:00:19.515

[Script]
LWLibavVideoSource("Sample2.mp4")
AssumeFPS("ntsc_film")
Prefetch(2)

Here Sample2 (http://www.filedropper.com/sample2)

I am using last version of Lsmash.

Interestingly, when I compile the script the time difference is very little.

DorianDiaconu

30th May 2021, 22:39

Hi bois,

Does it work on Mac, Fedora and other linux distros? Can I install it with wine?

Thanks!

pinterf

31st May 2021, 08:54

Thank you for so much effort on avisynth. It really helps me a lot.
I want to report an error "0xC0000005: Access violation reading location" which occured when I was using AVS+ 3.70 with CUDA option enabled and the aWarpsharpMT or the previous aWarpsharp2 plugin.
In Nekopanda's avisynth script, there is a line " SetDeviceOpt(DEV_CUDA_PINNED_HOST) ".
According to the comment, it's for CUDA data transport optimization. When adding this line to the script, the error occurs with using aWarpsharpMT/2. If without using aWarpsharpMT/2, everything goes fine even when I add that line. I will test the efficiency diffenrence with or without the line later and report here.

I'd need that script or better: if you could provide me a minimalistic script that still exhibits Access Violation.
Some words on the status of Avisynth+ and CUDA build: I was able to backport Nekopanda's changes and adjust the plugin set.
Translated the documentation and documented some of my (beginner's) experiences.
I even bought an NVidia card for future experiments. I am happy when someone (other than me :) ) is finally testing whether these backports are working or not; unfortunately I can start fixing something that I am able to reproduce.

As for the existing filters that were fitted to Neo's Avisynth headers and frame property access, I think I cannot help with them. The filters I ported required three main tasks to do: changing Avisynth+ headers, change some names in IScriptEnvironment calls, and reimplement code parts accessing frame properties - this latter is very much different.

FranceBB

31st May 2021, 10:55

pinterf

31st May 2021, 11:37

Hold on, I wanna test CUDA filters too! xD
If they work, I guess I'm gonna be in for a treat 'cause they would speed things up a lot.
What filters do we have and what should I do to make them work with CUDA?

And is everything that works internally cuda accelerated now?

Like:

ColorBars(848, 480, pixel_type="Yv12")

OnCuda()

tweak(sat=1.31, dither=true)

Spline64Resize(1280, 720)

Do I need a special build of Avisynth+?

I mean, afaik everything from the Nekopanda version has been ported, right?
Is there any kind of documentation for our normal Avisynth+ with cuda so that I don't have to use Google Translate to translate from Japanese to English? xD
CUDA-capable Avisynth+ is simply an Avisynth+ which can support CUDA-aware filters. Nothing is accelerated inside.
Due to the complexity - special knowledge, higher maintenance cost (=time, additional testing) and in general supporting only a subset of the parameters - it will probably never appear in the core.
You can use mt_lut from (a modified branch) Masktools2, KNNEDI3, Merge, Resizers, etc. from Avisynth core as an external plugin. This was done by Nekopanda and have to be built against the actual Avisynth headers.
The 3.7.0 release for example is not yet capable for accepting CUDA filters due to some leftovers at release-time which were fixed since then.

CUDA-aware Avisynth+ build is an additional option in CMake build process, I'm using CMakeGUI, there is a simple checkbox for that. When it finds up-to-date CUDA SDK, you can build your version as well. If I remember correctly, the first post in this topic links to a pack with a CUDA-aware build inside.

Again: if you have no CUDA capable filters it will do the same as an ordinary Avisynth+ does. I recommend reading the documentations at
https://github.com/pinterf/AviSynthCUDAFilters/tree/master/documentation

kedautinh12

31st May 2021, 11:39

Here had built x64 CUDA
https://drive.google.com/uc?export=download&id=1CpFdkqbNRDwtuHCtWiQ4x49ZCt8W2jkS

subterrestrial

31st May 2021, 12:40

Thanks for replying and explaining.
I use CUDA plugins to do deinterlace, MPEG2 bad field cleaning (DecombUCF), deblock, deband. To make things simple and clear, I will just write a simple script to produce the access violation error using SetDeviceOpt(DEV_CUDA_PINNED_HOST) statement and awarpsharp2/MT plugin without any CUDA plugin.
<code>
LWLibavVideoSource("L:\....mkv")
SetDeviceOpt(DEV_CUDA_PINNED_HOST)
aWarpSharp2(depth=32,blur=2,chroma=3)
</code>
I'm not sure whether the problem is caused by my compilation or not. If so, please pardon me for being amateur.
Now I guess I understand the difficulties to make Kdeblock work, so there is less wonder why Nekopanda seperate the Kdeblock code both in KFM and an indexer if QP_table is associated with frame property.
The idea of Kdeblock is somewhat like jconklin's amDCT using adaptive deblock strength. The former one lacks x64 version and need heavy computing like DCT and iDCT which I was told GPU is good at. So maybe in the future these methods might be inplemented and functioned.
Anyway, I'm really satisfied with CUDA plugins now. I can't tell the difference of the result of KTGMC and conditional QTGMC both using slow preset. Without your effort, maybe I have to switch between avisynth+ and avisynthneo if encountering compatible problems.

subterrestrial

31st May 2021, 13:24

The Nekopanda's AvisynthNeo and plugins using CUDA are components of his highly automated video processing and encoding GUI "Amatsukaze" which can do ADs cutting, delogo, video process, subtiles extracting, and merging and muxing all the things together only need you to set the parameters, drag the file in and leave it till finish.
My guess is he created all these AvisynthNeo stuff for his GUI working with high efficiency.
You can find all these in his Github repository "github.com/nekopanda". Printerf already translated his Avisynth documents in English, but I'm afraid you have to use google to translate documents other than that in his repository.
I think you are experienced in writing script for processing video, maybe you don't need further examples to show how to use these functions. But in case you need you can download the Amatsukaze software, in the Amatsukaze\avs path there is a compressed file named Â“_旧バージョンのavsファイルÂ”，it stored some example avs files to deal with different kinds of source files.

GMJCZP

31st May 2021, 14:18

pinterf

31st May 2021, 15:41

This is even slower:
LWLibavVideoSource("Sample2.mp4", threads = 1)
Prefetch(2)
Seems that LWLibavVideoSource does not like out of order frame requests (I suppose we have a such scenario). To my eyes it looked like it was slowing down in a linear way as if it would always start decoding from the very first frame whatever frame number is requested.

The frames parameter could help a bit though.
Prefetch(2, frames=2)

Looked at FFMS2 but it didn't show such problems.

FranceBB

31st May 2021, 17:16

CUDA-capable Avisynth+ is simply an Avisynth+ which can support CUDA-aware filters. Nothing is accelerated inside.
Due to the complexity - special knowledge, higher maintenance cost (=time, additional testing) and in general supporting only a subset of the parameters - it will probably never appear in the core.
You can use mt_lut from (a modified branch) Masktools2, KNNEDI3, Merge, Resizers, etc. from Avisynth core as an external plugin.
The 3.7.0 release for example is not yet capable for accepting CUDA filters due to some leftovers at release-time which were fixed since then.
https://github.com/pinterf/AviSynthCUDAFilters/tree/master/documentation

Got it, thanks for the explanation and thanks for the link to the English documentation! :D

Here had built x64 CUDA
https://drive.google.com/uc?export=download&id=1CpFdkqbNRDwtuHCtWiQ4x49ZCt8W2jkS

Great! Thanks! ;)

GMJCZP

31st May 2021, 17:28

Thanks pinterf.

With frames = 2 it improved noticeably but still doesn't even match Prefetch 1:

Log file created with: AVSMeter 3.0.9.0 (x86)
Script file: Prueba.avs
Command line switches: -log

[OS/Hardware info]
Operating system: Windows 7 (x86) Service Pack 1.0 (Build 7601)

CPU: Pentium(R) Dual-Core CPU E5800 @ 3.20GHz / Wolfdale (Core 2 Duo) 2M
MMX, SSE, SSE2, SSE3, SSSE3
2 physical cores / 2 logical cores

[Avisynth info]
VersionString: AviSynth+ 3.7.0 (r3382, 3.7, i386)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 20:46:40 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files\AviSynth+\plugins+

[Clip info]
Number of frames: 162
Length (hh:mm:ss.ms): 00:00:06.757
Frame width: 640
Frame height: 480
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 162 (0 - 161)
FPS (min | max | average): 0.971 | 107491 | 29.03
Process memory usage (max): 37 MiB
Thread count: 8
CPU usage (average): 64.9%

Time (elapsed): 00:00:05.581

[Script]

LWLibavVideoSource("Sample2.mp4")
AssumeFPS("ntsc_film")
Prefetch(2,frames=2)

I include the test with FFMS2:

Log file created with: AVSMeter 3.0.9.0 (x86)
Script file: Prueba.avs
Command line switches: -log

[OS/Hardware info]
Operating system: Windows 7 (x86) Service Pack 1.0 (Build 7601)

CPU: Pentium(R) Dual-Core CPU E5800 @ 3.20GHz / Wolfdale (Core 2 Duo) 2M
MMX, SSE, SSE2, SSE3, SSSE3
2 physical cores / 2 logical cores

[Avisynth info]
VersionString: AviSynth+ 3.7.0 (r3382, 3.7, i386)
VersionNumber: 2.60
File / Product version: 3.7.0.0 / 3.7.0.0
Interface Version: 8
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\system32\avisynth.dll
Avisynth.dll time stamp: 2021-01-11, 20:46:40 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files\AviSynth+\plugins+

[Clip info]
Number of frames: 162
Length (hh:mm:ss.ms): 00:00:06.757
Frame width: 640
Frame height: 480
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P16
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

[Runtime info]
Frames processed: 162 (0 - 161)
FPS (min | max | average): 0.756 | 239787 | 5.697
Process memory usage (max): 35 MiB
Thread count: 7
CPU usage (average): 81.5%

Time (elapsed): 00:00:28.437

[Script]
FFVideoSource("Sample2.mp4")
AssumeFPS("ntsc_film")
Prefetch(2)