AviSynth+ thread Vol.2

[FranceBB]

Out of curiosity, what about propclearall() right after indexing?

[Selur]

ClearAutoloadDirs()
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\INNOIN~1\64bit\Avisynth\AVISYN~1\MosquitoNR.dll")
LWLibavVideoSource("G:\TESTCL~1\test.avi",cache=false,dr=true,format="YUV420P8", prefer_hw=0)
propclearall()
MosquitoNR()
ConvertToRGB32(matrix="Rec601")
return last
also crashes at the initial invoke call and without the 'ConvertToRGB32' it crashes when 'ConvertToRGB32' is later called.
-> no change

[FranceBB]

Ok, so I've tried to test a bit:


ColorBars(848, 480, pixel_type="YV12")
MosquitoNR()
ConverttoRGB(matrix="Rec601")


works.
So I tried with a real video, an XDCAM-50 file and it works too:



FFVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Test9_UCN_manual_QC_SubITA_DolbyE_DolbyE_PCM_PCM.mxf")
propClearAll()
MosquitoNR()
ConverttoRGB(matrix="Rec601")


Last but not least, I've tried LWLibavVideoSource() which is the indexer you were trying to use and... it works:


LWLibavVideoSource("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\Test9_UCN_manual_QC_SubITA_DolbyE_DolbyE_PCM_PCM.mxf")
propClearAll()
MosquitoNR()
ConverttoRGB(matrix="Rec601")


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

and even your exact same command line:

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


Avisynth 3.7.2 Stable x64
Windows 11 x64

Out of curiosity, are you using this build of MosquitoNR? Link (https://www.dropbox.com/s/0dgrruxne80izus/MosquitoNR_0.10_x64.zip?dl=1)

[Selur]

I know that it works in avspmod, problem is that it does not work in my code.

Out of curiosity, are you using this build of MosquitoNR?
Yes, I do.

Cu Selur

[pinterf]

Using latest AviSynth+ 3.7.2

When I use:
...
my code crashes when loading the the file:
AVS_linkage = m_env->GetAVSLinkage();
const char* infile = m_currentInput.toLocal8Bit(); //convert input name to char*
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
m_res = m_env->Invoke("Import", AVSValue(&arg, 1)); // <- here it dies
see: https://github.com/Selur/avsViewer/blob/441500fe4f46ece0e48542a61daec95eb019ff3b/avsViewer.cpp#L142
...
-> any idea?

Cu Selur
Just a faint guess. it is the first use of m_res. Maybe the crash is related to it.
In the avsViewer::avsViewer there is an initialization of AVSValue m_res in that initialization list. Here:
https://github.com/Selur/avsViewer/blob/441500fe4f46ece0e48542a61daec95eb019ff3b/avsViewer.cpp#L28
But the global variable const AVS_Linkage *AVS_linkage which is needed as a bridge to fill/initialize an AVSValue does not exist yet. I'd try to remove m_res from the initialization list. Otherwise your code seems to be correct: toLocal8Bit is providing a safe null-terminated buffer; I guess 'm_env' exists just fine, so GetAVSLinkage should work as well.

[Selur]

Sadly, removing m_res from the initialization list doesn't help.
The strange thing is that if the .avs script doesn't include any "ConvertTo..." calls the loading of the script works fine, but then it crashes when I call ConvertToRGB32. :/
When I use:

bool avsViewer::invokeFunction(const QString& name)
{
try {
std::cout << "invoking " << qPrintable(name) << std::endl;
const char* function = name.toLocal8Bit();
if (!m_env->FunctionExists(function)) {
m_env->ThrowError(name.toLocal8Bit() + " does not exist!");
}
m_res = m_env->Invoke(function, AVSValue(&m_res, 1)); // invoking the function
std::cerr << "invoked " << qPrintable(name) << std::endl;
return true;
} catch (AvisynthError err) { //catch AvisynthErrors
std::cerr << "Avisynth error " << qPrintable(m_currentInput) << ": " << std::endl << err.msg << std::endl;
} catch (...) { //catch the rest
std::cerr << "Unknown C++ exception" << std::endl;
}
return false;
}
I see:
Initializing the avisynth script environment,..
loaded avisynth dll,..(I:/workspace/avsViewer/release/AviSynth.dll)
loaded CreateScriptEnvironment definition from dll,..
Importing c:\Users\Selur\Desktop\test.avs

Color: YV12, Resolution: 640x352, Frame rate: 25 fps, Length: 429 frames, PRO

Current color space: YV12
invoking ConvertToRGB32

so it dies in
m_res = m_env->Invoke(function, AVSValue(&m_res, 1)); // invoking the function

This is driving me nuts. :(

Cu Selur

[Ceppo]

I'm not in the right mind at the moment but:

m_res = m_env->Invoke(function, AVSValue(&m_res, 1)); // invoking the function

Is assigning a value to m_res and to use it with a reference at the same time... legit??

/I'mNotAProgrammer

[Selur]

Since the right side should be evaluated before the assignment I see no problem with it. :)

Cu Selur

Ps.: Can someone compile MosquitoNR with MVSC++ 2019?

[wonkey_monkey]

We should probably pop all this out into its own thread. But for now, I can confirm that

temp = env->Invoke("colorbars", 1280); // how do you invoke a filter with no parameters?
temp = env->Invoke("converttoyv12", AVSValue(&temp, 1));
temp = env->Invoke("mosquitonr", AVSValue(&temp, 1));
temp = env->Invoke("converttorgb32", AVSValue(&temp, 1));


crashes (MSVC2019, Avisynth+ 3.7.1), but doesn't crash if I remove the converttogrb32.

Yet putting ConvertToRGB32 directly in a script after MosquitoNR works fine. Very strange.

[Reel.Deel]

Ps.: Can someone compile MosquitoNR with MVSC++ 2019?

For x64 it would have to be with the Intel compiler since the source contains assembly.

On a side note, for anyone with the means to do it. The following plugins were all compiled with the Intel compiler as well. Downside is that they are compiled for the 2.5 interface and may be problematic as stated here: https://github.com/AviSynth/AviSynthPlus/issues/272

Not only unaware of frame props.
SmoothD2 is an AviSynth 2.5 plugin which can use hardcoded ("baked") code for frame manipulation instead of Avisynth interface calls. Behavior is uncontrolled and random.


Decomb
IT_YV12
MosquitoNR
SmoothD
SmoothD2


A 2.6 interface update for these plugins would be appreciated :).

[Selur]

But for now, I can confirm that
Man I'm happy that this does not happen to just me. :)

crashes (MSVC2019, Avisynth+ 3.7.1), but doesn't crash if I remove the converttogrb32.
hmm,.. I'm using 3.7.2 and there "putting ConvertToRGB32 directly in a script after MosquitoNR" does not work fine here. :/

A 2.6 interface update for these plugins would be appreciated
Yup, that would be cool. :)

Cu Selur

[wonkey_monkey]

I'm trying to build 3.7.2 from source with MSVC 2019. I download the source, use "Open a local folder" and it imports everything fine. I then go to Manage Configurations... which gives me a GUI to make changes to CMakeSettings.json. I take out the default Debug build and replace it with x64-Release, and I change the Configuration type to Release.

When I try to build, I get a number of unresolved externals:

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

The funny thing is I can do the exact same thing on my work computer, and it works fine. But not at home. Does anyone know what's wrong with my setup? Am I missing some required part of MSVC?

Edit: I CAN successfully build an x64-Debug version. But not Release.

[wonkey_monkey]

hmm,.. I'm using 3.7.2 and there "putting ConvertToRGB32 directly in a script after MosquitoNR" does not work fine here. :/


Does your program still invoke ConvertToRGB32 when it is already in the script?

What worked for me was putting ConvertToRGB32 in a script and then running the script with AVSMeter64. If I try to load the script in my viewer - which invokes ConvertToRGB32 a further time, regardless of what type the script produces - it crashes.

[Selur]

Does your program still invoke ConvertToRGB32 when it is already in the script?
Nope, ConvertToRGB32 is only invoked if the input isn't already RGB32.

[pinterf]

I'm trying to build 3.7.2 from source with MSVC 2019. I download the source, use "Open a local folder" and it imports everything fine. I then go to Manage Configurations... which gives me a GUI to make changes to CMakeSettings.json. I take out the default Debug build and replace it with x64-Release, and I change the Configuration type to Release.

When I try to build, I get a number of unresolved externals:

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

The funny thing is I can do the exact same thing on my work computer, and it works fine. But not at home. Does anyone know what's wrong with my setup? Am I missing some required part of MSVC?

Edit: I CAN successfully build an x64-Debug version. But not Release.
I've never used cmake from Visual Studio GUI.
I'm using CMakeGUI and using it to generate the .sln solution for all projects and dlls in Avisynth+.
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html#from-cmake-gui
Then I open the generated sln and can use both debug and release build from Visual Studio IDE.

[Ceppo]

Might be unrelated, but when I used invoke with vinverse, when passing directly the value in the invoke call I got the float converted to int for no reason, then I declared first the array and then I set the value of each index individually and the problem was gone, give it a shot, you got nothing to lose after all...

3 nights without sleeping :D

[Selur]

On my way to bed, you mean like this?

AVSValue tmp[1] = { &m_res };
m_res = m_env->Invoke(function, tmp);
(will try tomorrow after work)

[pinterf]

Is it easy and straightforward to build and use avsviewer cloned from git? Does it have any prerequisites?

[Ceppo]

On my way to bed, you mean like this?



AVSValue tmp[1];
tmp[0] = &m_res;

[Dogway]

I wonder if frame props are broken? I expect frame properties assigned to frame 0 be retrieved outside a runtime environment.

ScriptClip( function[] () {
SelectEvery(1,-current_frame)
AverageLuma() > 98 ? propSet("_TestFP", 4) : propSet("_TestFP", 1)
SelectEvery(1, current_frame)
subtitle(string(AverageLuma()),align=8,y=100)
} )

subtitle(string(propGetInt("_TestFP")),align=8)

[Selur]

Is it easy and straightforward to build and use avsviewer cloned from git? Does it have any prerequisites?
Qt + avisynth dll/inclues, nothing more. I usually build it with MSVC Community editoion, QCreator and Avisynth+ sdk installed. FilterSDK path in the .pro file "C:\Program Files (x86)\AviSynth+\FilterSDK\include" might need to be adjusted to your system. When building with mingw, you probably would need to add some additional dependencies to the .pro file.

AVSValue tmp[1];
tmp[0] = &m_res;
nope, doesn't change a thing.

[pinterf]

Qt + avisynth dll/inclues, nothing more. I usually build it with MSVC Community editoion, QCreator and Avisynth+ sdk installed.
Is this add-on enough?
https://www.qt.io/blog/2019/01/21/qt-visual-studio-tools-2-3-1-released
and following the list here: https://wiki.qt.io/Visual_Studio_Add-in and choose pre-built windows one? (3.9GB??)
https://download.qt.io/official_releases/qt/5.12/5.12.9/

[pinterf]

Qt + avisynth dll/inclues, nothing more. I usually build it with MSVC Community editoion, QCreator and Avisynth+ sdk installed.
Is this add-on enough?

These are my findings and I was able to build avsViewer under Windows and VS2019.

- Install Avisynth+ with SDK (if you want to have Avisynth headers in c:\Program Files (x86)\AviSynth+\FilterSDK\include\)
- VS2019: Clone https://github.com/Selur/avsViewer.git
- QT: Download and install pre-built package, find link at https://wiki.qt.io/Visual_Studio_Add-in. (3,9GB!)
- Start installer, you'll need to create a QT account, email-confirmation, yes-I'm individual, Choose VS2017 32 bit x86 (no VS2019 version)
- In VS2019 find Extensions|Manage Extensions, type in search Qt Visual Studio tools, Download. Exit from VS2019 to install it.
- Restart VS2019
- The Qt project file extension .pro is not for MS Visual Studio, avsViewer.pro has to be converted first:
- If you already have a .pro file but no .vcproj file:
Extensions|Qt VS Tools|Open Qt Project File (.pro) to convert .pro file to a .vcproj file.
Grrr. Error: qmake not found, specify a version
- Extensions|Qt VS Tools|Options|Qt|Versions
Browse for qmake.exe: C:\Qt\Qt5.12.9\5.12.9\msvc2017\bin\qmake.exe
version: 5.12.9_msvs2017, Host: Windows, Path: C:\Qt\Qt5.12.9\5.12.9\msvc2017 will be filled.
OK
- Again: Extensions|Qt VS Tools|Open Qt Project File (.pro) to convert .pro file to a .vcproj file.
Yeah, it works now.

EDIT:
These lines result in complete garbage (e.g. YYYYYYYYYYYYYYY) in 'infile' and 'function'.
Debugging step-by-step and watch variables: m_current_input is a valid Qt string containing the avs file with full path, and name contains "ConvertToRGB32" Qt string.
Both conversions fail.
const char* infile = m_currentInput.toLocal8Bit(); //convert input name to char*
const char* function = name.toLocal8Bit();
Replacing them with hardcoded avs file name:
e.g. const char* infile = "C:/Tape13/20220322_AvsViewer/s1.avs";
and const char* function = "ConvertToRGB32"; everything works perfectly.

I'm trying Win32 at the moment with the following script:

LoadPlugin("MosquitoNR.dll")
ColorBars(pixel_type = "YV12")
propclearall()
MosquitoNR()
#ConvertToRGB32(matrix="Rec601")
return last

[Selur]

I ususally use QCreator and thus no vcproj file is needed. :)
Win32 works fine here, only win64 fails.

[pinterf]

I ususally use QCreator and thus no vcproj file is needed. :)
Win32 works fine here, only win64 fails.
I don't know what Qcreator is; are you able to debug the DLL built with Visual Studio stepping by line and inspect variables?

[Selur]

QCreator -> https://www.qt.io/product/development-tools
It detects the installed MSVC compiler and the Windows Debugger. (if you open the projects dialog)
When debugging you can set hbreak points an go from them step-by-step and see how the variables change.
it looks like this:
https://i.ibb.co/rvq13XH/Qt-Creator.png (https://ibb.co/qxhPC2p)

[pinterf]

I could not figure out why my existing MSVC reported junk result for your Qt string converter line. And no x64 project settings were generated, probably I missed it during install?

Anyway, I updated the plugin instead of spending days on learning Qt things.

https://github.com/pinterf/MosquitoNR/releases/tag/v0.2
If something does not work or the result is not the same as it was, please report it on github (issues) (~1000 lines of assembly code was converted, I'd easily missed something in the process).
Tested with Avspmod.

I do hope it works fine and the crash in avsViewer is not Avisynth related.

[pinterf]

I wonder if frame props are broken? I expect frame properties assigned to frame 0 be retrieved outside a runtime environment.

ScriptClip( function[] () {
SelectEvery(1,-current_frame)
AverageLuma() > 98 ? propSet("_TestFP", 4) : propSet("_TestFP", 1)
SelectEvery(1, current_frame)
subtitle(string(AverageLuma()),align=8,y=100)
} )

subtitle(string(propGetInt("_TestFP")),align=8)
They are set.
Uncomment the external SubTitle and check if error message is shown by ScriptClip. Because I fed it with BlankClip() and ScriptClip failed because AverageLuma could not be done on an RGB clip.
BlankClip(pixel_type="YV12") did the job.

[wonkey_monkey]

What licence is Avisynth+ distributed under? It's got copies of the GPL in the files, but nothing that actually says that's what it's distributed under, as far as I can tell.

Also Avisynth used to have an exception:

As a special exception, the copyright holders of Avisynth give you
permission to link Avisynth with independent modules that communicate
with Avisynth solely through the interfaces defined in avisynth.h,
regardless of the license terms of these independent modules, and to
copy and distribute the resulting combined work under terms of your
choice, provided that every copy of the combined work is accompanied by
a complete copy of the source code of Avisynth (the version of Avisynth
used to produce the combined work), being distributed under the terms of
the GNU General Public License plus this exception. An independent
module is a module which is not derived from or based on Avisynth, such
as 3rd-party filters, import and export plugins, or graphical user
interfaces.


http://avisynth.org.ru/docs/english/license.htm

Does that/can that still apply to Avisynth+? I've distributed plugins without source code often - because of laziness more than anything else, because I draw on bits and pieces of code (all mine) scattered in various different projects and it's a pain to package it all up or even test that it'll compile elsewhere.

[pinterf]

https://forum.doom9.org/showthread.php?p=1645648&highlight=avisynth+license#post1645648
https://forum.doom9.org/showthread.php?p=1653152&highlight=avisynth+license#post1653152

I don't know that .ru site, but you can find the 'special exception' text in each avisynth.h and avisynth_c.h.

[wonkey_monkey]

Avisynth.h, of course! I'm an eejit. Thanks.

[Selur]

I do hope it works fine and the crash in avsViewer is not Avisynth related.
Yes! avsViewer works fine with the new version! Thanks a lot!

[pinterf]

Yes! avsViewer works fine with the new version! Thanks a lot!
You're welcome. I though it was more problematic after seeing the amount of assembler lines inside. Ten hours fun, one less 2.5 plugin to bother with. Great deal, isn't it ;)

[StainlessS]

Pinterf, Avisynth code czar and incredible geezer :)

[actually I looked up 'geezer' in my online dictionary, and it aint as flattering as I thought :) ]

[Selur]

Okay, I checked all the filters I use in Hybrid with 64bit Avisynth and I found another one which causes the same issue: Motion (http://wilbertdijkhof.com/mg262/Motion_v10.zip) which I use through SalFPS3:
ClearAutoloadDirs()
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\LSMASHSource.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\motion.dll")
LoadPlugin("I:\Hybrid\64bit\Avisynth\AVISYN~1\masktools2.dll")
Import("I:\Hybrid\64bit\Avisynth\avisynthPlugins\SalFPS3.avs")
# loading source: G:\TestClips&Co\files\test.avi
# color sampling YV12@8, matrix: bt601, scantyp: progressive, luminance scale: limited
LWLibavVideoSource("G:\TESTCL~1\files\test.avi",cache=false,dr=true,format="YUV420P8", prefer_hw=0)
# current resolution: 640x352
# adjusting frame rate
SalFPS3(50.0)
# filtering
PreFetch(16)
# setting output fps to 50.000fps
AssumeFPS(50,1)
# output: color sampling YV12@8, matrix: bt601, scantyp: progressive, luminance scale: limited
return last
-> could you also compile that? :)

Cu Selur

[Dogway]

They are set.
Uncomment the external SubTitle and check if error message is shown by ScriptClip. Because I fed it with BlankClip() and ScriptClip failed because AverageLuma could not be done on an RGB clip.
BlankClip(pixel_type="YV12") did the job.

Thanks for the reply, the external subtitle is stuck at value 0.000, try with this example:

BlankClip(pixel_type="YV12")

Expr("frameno","128")

ScriptClip( function[] () {

avg = AverageLuma()

SelectEvery(1,-current_frame)
propSet("_TestFP", avg)
SelectEvery(1, current_frame)

subtitle("IN: "+string(avg),align=8,y=100)
} )

subtitle("OUT: "+string(propGetFloat("_TestFP")),align=8)
https://i.imgur.com/LV7mopim.png

[pinterf]

Thanks for the reply, the external subtitle is stuck at value 0.000, try with this example:

BlankClip(pixel_type="YV12")

Expr("frameno","128")

ScriptClip( function[] () {

avg = AverageLuma()

SelectEvery(1,-current_frame)
propSet("_TestFP", avg)
SelectEvery(1, current_frame)

subtitle("IN: "+string(avg),align=8,y=100)
} )

subtitle("OUT: "+string(propGetFloat("_TestFP")),align=8)

Yes, outer display is stuck at a constant value. Outside ScriptClip everything is invoked and evaluated only once, at the very moment the filter (SubTitle, non-runtime propGetFloat) is invoked. Clips have known format, strings have their values ready. Constant values are assigned to all variables during script evaluation. Outer PropGetFloat calls GetFrame(0) only once in its constructor, and at that moment this will show 0 and so it will be displayed by SubTitle.

Try putting the outer SubTitle to ScriptClip to make it behave dynamically and you'll see the changing values.
ScriptClip(function[] () {
subtitle("OUT: "+string(propGetFloat("_TestFP")),align=8)
} )

[pinterf]

Okay, I checked all the filters I use in Hybrid with 64bit Avisynth and I found another one which causes the same issue: Motion (http://wilbertdijkhof.com/mg262/Motion_v10.zip) which I use through SalFPS3:

-> could you also compile that? :)

Cu Selur
Yikes! This plugin is only 15 year old. Better than a Black Label. Not nice.
Like MosquitoNR this is not a simple recompilation either; similarly to MosquitoNR all its inline assembler must be replaced/rewritten by hand. I surely don't have another 10-20 hours for it. At least not now. I'm gonna deal with it when I'm bored.

[Dogway]

Yes, outer display is stuck at a constant value. Outside ScriptClip everything is invoked and evaluated only once, at the very moment the filter (SubTitle, non-runtime propGetFloat) is invoked. Clips have known format, strings have their values ready. Constant values are assigned to all variables during script evaluation. Outer PropGetFloat calls GetFrame(0) only once in its constructor, and at that moment this will show 0 and so it will be displayed by SubTitle.

Try putting the outer SubTitle to ScriptClip to make it behave dynamically and you'll see the changing values.

Yes, the description was confusing because it said properties from frame#0 could be retrieved from outside runtime.
AviSynth 3.7.1: allow propGetXXX property getter functions called as normal functions, outside runtime.
By default frame property values are read from frame#0 which index can be overridden by the offset parameter.

If we remove subtitle from the equation it's the same (no subtitle in this case), despite frame#0 has changing values:
var = propGetFloat("_TestFP")
var > 40 ? subtitle("OUT: OK!",align=8) : last

This was an effort to make filtering lighter on the CPU.

[Reel.Deel]

Okay, I checked all the filters I use in Hybrid with 64bit Avisynth and I found another one which causes the same issue: Motion (http://wilbertdijkhof.com/mg262/Motion_v10.zip) which I use through SalFPS3:
[code]
-> could you also compile that? :)

Cu Selur

I'm curious to see an example of Motion performing better then the current alternatives. I tried out this plugin long ago and I remember getting suboptimal results compared to MVTools2 and co.

Here's the actual source for the x64 version of Motion: Motion64_src.zip (http://members.optusnet.com.au/squid_80/sources/Motion64_src.zip)

Still includes asm but with #ifdef around it, maybe it too was compiled with the Intel compiler. Edit: indeed it was:

Intel's compiler does support inline assembly, that's how I was able to do tdeint, masktools, clouded's motion.dll and awarpsharp in quick succession...

[kedautinh12]

Binary here:
http://members.optusnet.com.au/squid_80/motion64.zip

[Selur]

@kedautinh12: That's the file I use which which causes me the issues. (also tried it and it does not work)

[pinterf]

Yes, the description was confusing because it said properties from frame#0 could be retrieved from outside runtime.


If we remove subtitle from the equation it's the same (no subtitle in this case), despite frame#0 has changing values:
var = propGetFloat("_TestFP")
var > 40 ? subtitle("OUT: OK!",align=8) : last

This was an effort to make filtering lighter on the CPU.
Avisynth scripting language is not capable to do that dynamically for you this way. It's ScriptClip and other runtime filters that are capable to do that. Or write a native filter and do the frame specific task in its GetFrame function.

When filter graph is built - once during script evaluation - all variables have single constant values, all functions have fixed, known parameter values, and they all return constant values as well which can be evaluated for the rest of the script text.

[Selur]

I'm curious to see an example of Motion performing better then the current alternatives. I tried out this plugin long ago and I remember getting suboptimal results compared to MVTools2 and co.
May be you are right -> I'll drop SalFPS3 from Hybrid. :)

[Dogway]

Avisynth scripting language is not capable to do that dynamically for you this way. It's ScriptClip and other runtime filters that are capable to do that. Or write a native filter and do the frame specific task in its GetFrame function.

When filter graph is built - once during script evaluation - all variables have single constant values, all functions have fixed, known parameter values, and they all return constant values as well which can be evaluated for the rest of the script text.

I managed to get the main filter run fast enough (around 140fps) but I know it's going to go down very quickly with consecutive runtime filters. Would it be possible to add 'Average' to PlaneMinMaxStats? It would make the filter run considerably faster by streamlining all the stats figures.

[pinterf]

I managed to get the main filter run fast enough (around 140fps) but I know it's going to go down very quickly with consecutive runtime filters. Would it be possible to add 'Average' to PlaneMinMaxStats? It would make the filter run considerably faster by streamlining all the stats figures.
Request registered. Any other meaningful statistics?

[Dogway]

There's the 'mode' but I have never used it, and I personally like 'IQM' (a 'mean' without the outliers). In any case I fear that adding too many would be counterproductive forcing all the stats to be computed.

[EternalStudent]

Other than looking at video output...how do people debug Avisynth+ use? I haven't found a log file I can enable, or a debug registry key to set.

I'm an SVP4 user (Smooth Video Project) and it uses Avisynth+, but seems to have issues with newer versions. I've found the SVP event log, but not a lot is mentioned there when things go wrong.

I found a debug registry key for AvsF, but I don't know if that'll show me everything happening inside Avisynth+ or not. The AvsF dev said they build a debug Avisynth+ version themselves and set a breakpoint. That's a bit more than I was hoping to do.

I just found and downloaded a few older wrapper tools that appear to test dependencies and give resource usage for a script. I haven't tried running them yet on the SVP created AVS. I have a feeling it won't be that easy. That they use some stored value from MPC-HC to know what to play.

To be clear, I'm not writing an AVS of my own. But am trying to help debug sporadic silent failures I ran across when upgrading a package myself (3.5.1 to 3.7.2). Where SVP reported itself disabled midway through the 2nd or 3rd episode of a TV series, and the video output still plays but not changed anymore. Kind of learning about all the parts by breaking them, and hoping to help the SVP dev(s) out with my efforts (or Avisynth+ if it's their bug).

[StainlessS]

I did not know what AvsF was, its described here for those interested:- https://www.svp-team.com/wiki/Avisynth_Filter_(AVSF) ]

EDIT: EternalStudent,
Probably not many people here will have any idea about the SVP AvsF thingy.
Suggest re-install Lav filters, W10 screws things up sometimes [for no apparent reason].

EDIT: You could also install this and run it before testing your AvsF thingy[DebugView]- https://docs.microsoft.com/en-us/sysinternals/downloads/debugview
Might spit out something relevant, or might not.

Also might want to check out AvsMeter,
command (with avsmeter/avsmeter64 somewhere in environment PATH),
"AvsMeter.exe -avsinfo" OR "AvsMeter64.exe -avsinfo",
AvsMeter if using x86 avsisynth via MPC-HC x86, or AvsMeter64 if 64 bit.

[Reel.Deel]

I did not know what AvsF was, its described here for those interested:- https://www.svp-team.com/wiki/Avisynth_Filter_(AVSF)


Link got messed up somehow: https://www.svp-team.com/wiki/Avisynth_Filter_(AVSF)

And here's the direct link to the repo: https://github.com/CrendKing/avisynth_filter

I've seen it before but never used it.

[StainlessS]

Thanks RD, fixed.

@ EternalStudent, the filter (linked by Reel.Deel) was updated 10 days ago.

[Nuihc88]

Other than looking at video output...how do people debug Avisynth+ use? I haven't found a log file I can enable, or a debug registry key to set.

Only reliable way i have found to debug SVP's AviSynth-filter usage, is to write my own AVS-scripts for SVPflow filters (https://github.com/Nuihc88/SVPlite) from scratch and then edit line per line. For tracking what Avisynth+ is doing internally, you'll need to use several programs, each of which could be giving misleading output due to several interface versions being used across them. Unless you are willing to play with the source code or attach debuggers, nothing else besides AviSynth+'s built-in script-interface is likely to generate usable diagnostic output.

I'm an SVP4 user (Smooth Video Project) and it uses Avisynth+, but seems to have issues with newer versions. I've found the SVP event log, but not a lot is mentioned there when things go wrong.

If i remember correctly, there was a compatibility issue with SVP and newer AVS+ versions due to a change in interface version around v3.6.0, since SVP used AvsF built for old interface version to retain backwards compatibility with ffdshow. So you'll likely need to use newer AvsF binaries with newer AVS+ or older AVS+ binaries with the AvsF bundled with SVP. This old 3.5.2 test build (https://drive.google.com/file/d/1EY1wgsh7pQD7kqj_2suD--nSj12hILX4/view) should work well with AvsF built for either interface version, while still having a more modern feature set and being one of the best performing and most stable AVS+ builds i have tested, however it has a few use scenario specific deadlock and memory leak issues, which have since been fixed in v3.7.2 line.

I found a debug registry key for AvsF, but I don't know if that'll show me everything happening inside Avisynth+ or not. The AvsF dev said they build a debug Avisynth+ version themselves and set a breakpoint. That's a bit more than I was hoping to do.

AvsF's debug feature can sometimes provide clues as to what is going on, but you'll need to be at least somewhat familiar with inner workings of both AvsF & AVS+ to interpret it at all.

I just found and downloaded a few older wrapper tools that appear to test dependencies and give resource usage for a script. I haven't tried running them yet on the SVP created AVS. I have a feeling it won't be that easy. That they use some stored value from MPC-HC to know what to play.

If SVP is configured to use AvsF, the media file will be loaded through AvsFilterSource() function in the script-file. You won't need to point it to a specific file.

To be clear, I'm not writing an AVS of my own. But am trying to help debug sporadic silent failures I ran across when upgrading a package myself (3.5.1 to 3.7.2). Where SVP reported itself disabled midway through the 2nd or 3rd episode of a TV series, and the video output still plays but not changed anymore. Kind of learning about all the parts by breaking them, and hoping to help the SVP dev(s) out with my efforts (or Avisynth+ if it's their bug).

Silent failure during real-time playback could be due to almost anything, but most likely it's due to some conditional setting in SVP profiles menu. I would recommend first checking whether you are able to reproduce the issue while using a custom script with SVP remote control interface disabled, thus bypassing SVP GUI options entirely.

[DTL]

May be add square hyperbolic zoneplate generator as internal source of test pattern ? https://github.com/DTL2020/hpzp (internal calculation in float 'narrow' range 16.0..235.0 - can output any bitdepth from float to uint8). It creates 'edges aligned and conditioned' to level 16 (video black in 8bit) rectangular buffer so it can be infinitely extended with AddBorders() with colour #10101010 without creating of 'unconditioned' stepping and adding more ringing in processing.
It may be used for testing scalers and some other processing (like quality of sub-sample shifting and so on).
In its simple form it is square pattern (though in theory can have different H and V frequency scale to be rectangular without going to out-of-band frequencies and mirror itself). So it require only 1 parameter of render size (width or height). The only some additional work is require for 'auto-scale' or end-frequency control param (currently manually adjusted when render size changes).

As addition to ColorBars internal test pattern generators.

Currently I create .raw file with executable and read into scripts via RawSourcePlus plugin.

[Ceppo]

QUESTION:
I see here (http://avisynth.nl/index.php/Internal_functions#Functions_for_frame_properties) that there is no field-matching property. Should I just use _PictType, and set it to B/U/C/P/N? Or I'm going to blow up some filter by doing so?
EDIT:
If there is no field matching, and I'm not mistaken, can a _match property be added?

[real.finder]

QUESTION:
I see here (http://avisynth.nl/index.php/Internal_functions#Functions_for_frame_properties) that there is no field-matching property. Should I just use _PictType, and set it to B/U/C/P/N? Or I'm going to blow up some filter by doing so?
EDIT:
If there is no field matching, and I'm not mistaken, can a _match property be added?

_PictType is for mpeg codecs IIRC so that not ok here

and you can add new property with the name you want, but it's better to see if someone has another opinion

edit: tivtc in vs use PROP_TFMMATCH, PROP_TFMD2VFilm, PROP_TFMPP and PROP_TFMField https://github.com/dubhater/vapoursynth-tivtc/blob/1713095068d18a2fe93598aaabd7e53e12163e03/src/TDecimate.cpp#L1515 so yes, made anything you want here :)

[Ceppo]

Tomorrow I will get into it, thanks :)

[StainlessS]

Parser error [maybe], Bug report here:- https://forum.doom9.org/showthread.php?p=1967744#post1967744

[Ceppo]

Does someone know if there is a limit to the number of props that you can add to the frame?

[Dogway]

Does somebody know what's going on in here? I get different values when iterative summing and a simple multiplication.

add = 0.641099
num = 0
for (i = 1, 177, 1) {
num = num + add }
subtitle(string(num))
and
subtitle(string(0.641099*177))

The former seems to be more accurate but I suppose slower.

[wonkey_monkey]

The looped addition is less accurate. It's losing precision due to the limited accuracy of floats (rule of thumb is approx 7 decimal digits) with each operation.

[Dogway]

Thanks wonkey_monkey. I guess this is something ubiquitous because either Excel or Win7 calculator were closer to the looped addition. I wanted to use the multiplication either way so no prob.

[LigH]

Please read about the IEEE Standard for Floating-Point Arithmetic (https://en.wikipedia.org/wiki/Floating-point_arithmetic) (IEEE 754 (https://en.wikipedia.org/wiki/IEEE_754)). There are standard number formats with 32 bit (single precision), 64 bit (double precision) and even 80 bit internally (extended precision); but none is absolutely accurate due to the facts that the precision of the mantissa is limited at all, and the conversion between the decimal and dual number system may require infinite fractions in dual for some finite fractions in decimal (when any negative power of 5 is involved).

AviSynth may only use single precision as this is sufficient for most calculations with video dimensions, color values, and even audio samples as results (the "precision", in terms of significant/available bits, of integer formats is usually even a lot lower).

[Dogway]

Thanks LigH, I read about it some time ago (https://forum.doom9.org/showthread.php?p=1950751#post1950751) but it still puzzles me because a multiplication is nothing more than a looped addition, unless it's doing some bitshifts with rationals, also every software giving out different values despite being under the same standard.


On another note, is this a bug?:
ExtractY()
CombinePlanes(last, planes="YYY", source_planes="YYY",pixel_type="YUV444")
I want to copy Y plane to U and V, only managed it to work with the following.
ExtractY()
CombinePlanes(last, last, last, planes="YUV", source_planes="YYY",pixel_type="YUV444")

[VoodooFX]

"YYY" for planes is probably a 'typo' in wiki (http://avisynth.nl/index.php/CombinePlanes):


string planes = ""
The target plane order (e.g. "YVU", "YYY", "RGB")

[Dogway]

Thanks VoodooFX changing to "YVU" worked, I still fail to fully comprehend this filter.
CombinePlanes(last, planes="YVU", source_planes="YYY",pixel_type="YUV444")

[Reel.Deel]

"YYY" for planes is probably a 'typo' in wiki (http://avisynth.nl/index.php/CombinePlanes):

I don't think it's a typo.

ExtractY()
CombinePlanes(last, planes="YYY", source_planes="YYY", pixel_type="YUV444")

"YYY" in this case means that any plane that is not defined in the planes parameter is set to 0. Likewise, planes="YUY" means that the Y and U planes will be copied from the luma plane of the source clip and since the V plane is not defined it will be set to 0. I will add this info to the docs, if there are no objections.

Same story for RGB:

ExtractY()
CombinePlanes(last, planes="RRR", source_planes="YYY", pixel_type="RBGP")

The green and blue planes of the resulting clip will be set to 0.

[VoodooFX]

I don't think it's a typo.

ExtractY()
CombinePlanes(last, planes="YYY", source_planes="YYY", pixel_type="YUV444")

"YYY" in this case means that any plane that is not defined in the planes parameter is set to 0. Likewise, planes="YUY" means that the Y and U planes will be copied from the luma plane of the source clip and since the V plane is not defined it will be set to 0.
Do you have an example where planes="YYY" "works"?

[Reel.Deel]

Do you have an example where planes="YYY" "works"?

What do you mean works? Like a use case? Of the top of my head I don't but the planes parameter works as I described it.

[Dogway]

I think I understand now:

source_planes="YYY"
|||
|||
vvv
planes= "YUV"

Except for the null exception Reel.Deel explained.

EDIT: To make it a reference post, I tested with two clips and the above doesn't stand (another exception), you need to do the shuffle with the clips.
CombinePlanes(src, last, src, planes="YUV", source_planes="YUV")
This means copy Y and V from src, keep U from last.

[Reel.Deel]

I think I understand now:

source_planes="YYY"
|||
|||
vvv
planes= "YUV"

Except for the null exception Reel.Deel explained.

That's correct.

[VoodooFX]

What do you mean works? Like a use case?
Yes, practical use case. That's what I meant by 'typo' as there is no practical use case for it [maybe I don't see it] then no need to mention it in wiki.
I think "YYY" should be mentioned in source_planes parameter.

[Reel.Deel]

Yes, practical use case. That's what I meant by 'typo' as there is no practical use case for it [maybe I don't see it] then no need to mention it in wiki.
I think "YYY" should be mentioned in source_planes parameter.

I don't have a practical use case and I agree mentioning "YYY" can be a confusing if the mapping behavior is not fully explained. I'll add to the docs when I get a chance.

[wonkey_monkey]

Thanks LigH, I read about it some time ago (https://forum.doom9.org/showthread.php?p=1950751#post1950751) but it still puzzles me because a multiplication is nothing more than a looped addition, unless it's doing some bitshifts with rationals

Exactly. Multiplication in a computer is not looped addition. That's way too inefficient (and it wouldn't work on non-integers anyway). It pretty much is bitshifts (the mantissas are treated as integers and integer multiplied).

https://www.gamedeveloper.com/programming/in-depth-ieee-754-multiplication-and-addition

[Reel.Deel]

EDIT: To make it a reference post, I tested with two clips and the above doesn't stand (another exception), you need to do the shuffle with the clips.
CombinePlanes(src, last, src, planes="YUV", source_planes="YUV")
This means copy Y and V from src, keep U from last.

Correct, the last supplied clip is used for the remaining planes. So if you want a specific plane to come from a particular clip, the clips must be provided in the correct order. Let's take your "copy Y plane to U and V" use case but also with an alpha.

clip1 = Blankclip(pixel_type="Y8").Subtitle("Clip1")
alpha = Blankclip(pixel_type="Y8").Subtitle("Alpha")

CombinePlanes(clip1, clip1, clip1, alpha, planes="YUVA", source_planes="YYYY", pixel_type="YUVA444")

The first 3 planes (YUV) are taken from clip1 and the A plane from the alpha1 clip. If it would of been specified as CombinePlanes(clip1, alpha, planes="YUVA", ...) it would mean that only the first plane (Y) would be taken from the first clip and the remaining planes from the second clip.

[LigH]

Multiplication in a computer is not looped addition.

A loop of inaccurate calculations adds up rounding errors to a much larger sum than the rounding error of one direct multiplication. You may remember the "generation effect" of re-encoding video multiple times with a lossy algorithm and changing quantization factors, which increases the opacity of DCT artifacts (blocks and edge ringing).

[wonkey_monkey]

Just an idea I had and thought I'd put here in case anyone wants to pick it up: ordered dithering for integer output formata could be added fairly easily to Expr. A 4x4 ordered dither could be done as a lookup to a 4-entry __m128 or __m256 table (based on current y coordinate mod 3) and a single add.

[LigH]

Disadvantage: Bayer dither is pretty ugly due to obvious patterns and banding. Every kind of error distribution dithering (even simple Jarvis-Judice-Ninke, Sierra Lite or Atkinson) would look better. Of course, SIMD streaming is harder here.

[FranceBB]

Disadvantage: Bayer dither is pretty ugly due to obvious patterns and banding. Every kind of error distribution dithering (even simple Jarvis-Judice-Ninke, Sierra Lite or Atkinson) would look better. Of course, SIMD streaming is harder here.

Yep, I generally almost always use Floyd Steinberg error diffusion and when I'm not using it, I'm using the Sierra-2-4A error diffusion. There are also the Stucki and Atkinson error diffusion techniques which are also good.

[Gh@nz]

Good day, gentlemans.
Can someone explaine how to connect a second processor?

OS Windows Enterprise LTSC 2021 x64 21H2
Dell T7810: Xeon E5 2669 x 2 + 64Gb RAM
Avisynth+ 3.7.2 (20220317) + FFTW v3.3.10 x32-64 + x264 aMod (DJATOM) Haswell var.

[takla]

Good day, gentlemans.
Can someone explaine how to connect a second processor?

OS Windows Enterprise LTSC 2021 x64 21H2
Dell T7810: Xeon E5 2669 x 2 + 64Gb RAM
Avisynth+ 3.7.2 (20220317) + FFTW v3.3.10 x32-64 + x264 aMod (DJATOM) Haswell var.

Maybe try Process Lasso (https://bitsum.com/)

[Gh@nz]

Maybe try Process Lasso (https://bitsum.com/)

Well, Avisynth+ 3.5.1 use both processors.
Whats wrong with Avisynth+ 3.7.2 or with me)))?

[Solved]

[Selur]

4:1:1 to 4:2:0 interlaced conversion throws:
Convert: Input ChromaPlacement only available with 4:2:0 or 4:2:2 sources.
see: https://forum.doom9.org/showthread.php?t=184197

[DTL]

BlankClip(pixel_type="YV411")
Info()
ConvertToYV12(ChromaInPlacement="DV",interlaced=true)


Throws error about 4:2:0 input only in both 3.7.0 and 3.7.2 versions.
Only

BlankClip(pixel_type="YV411")
Info()
ConvertToYV12(interlaced=true)

is working.

The bug looks like with 411 and _ChromaLocation property is set. And most of colour Convert* functions (except for ConvertToY() at least) fail now.

To reproduce:

BlankClip(pixel_type="YV411")
propSet("_ChromaLocation", 0)
ConvertToYV12(interlaced=true)


The only working Convert with such input stream looks ConvertToY() .

[Balling]

BTW, Spline144 is not ported from http://www.wilbertdijkhof.com/SplineResize_v02.zip and no 64 bit dll in the link.

[FranceBB]

BTW, Spline144 is not ported from http://www.wilbertdijkhof.com/SplineResize_v02.zip

I know a "certain lady" (https://forum.doom9.org/showthread.php?t=175187) who's gonna be happy if Spline144Resize() will ever make it to the core...

[ajp_anton]

Why does Subtitle treat "\n" as newline only if lsp is set? It feels unnecessary to add lsp=0 to pretty much all my Subtitle calls.

[Dogway]

Is there a way for Histogram(mode="classic") to output waveform in PC levels? Or maybe inherit from frameprops. It would save a lot of processing power by skipping a range conversion in the curve graphs of my filters, specially in preview mode in AvsPmod.

[ajp_anton]

Feature request:

Expr("x[X,Y]")
where X and Y can be other than just plain written integers. Even "2 1 -" fails. Would be awesome to be able to use variables like frameno and even pixels from other clips to build a displacement map. Don't know if it's worth it trying to implement float support with some kind of interpolation from surrounding pixels. Maybe just round to the nearest integer.

Also would be nice to remove the -width < X < width and -height < Y < height constraints, as it's already able to handle out-of-frame pixels.

I know this would kind of explode the amount of things one can do with Expr, but does that matter? The user doesn't need to use everything that it's capable of. This would allow the user to, in theory, recreate most plugins within this expression, and even though it might not be the most efficient method, it's better than nothing if one wants to do something that no plugin can do. Coming back to the float/int comment above, even if the coordinate is rounded to an int, one could implement one's own interpolation method if needed.

[Reel.Deel]

Is there a way for Histogram(mode="classic") to output waveform in PC levels? Or maybe inherit from frameprops. It would save a lot of processing power by skipping a range conversion in the curve graphs of my filters, specially in preview mode in AvsPmod.

No, Histogram(mode="classic") is hardcoded to TV levels. Even the "midpoint" line is at 125.5. (https://github.com/AviSynth/AviSynthPlus/issues/268#issuecomment-1048546724) Only recently, "levels" mode outputs PC levels when the input is RGB. Maybe ask pinterf, it would be nice to have an option in Histogram to output PC levels.

[Dogway]

Yes, mid-grey in TV levels corresponds to 125.5. It naturally shifts back to 127.5 when converted to PC levels.
The issue is that graphs in TV levels makes it hard to manipulate (overlay, etc).
Not sure I want to bother pinterf as I think he is semiretired.

[kedautinh12]

Avs+ r3682
https://gitlab.com/uvz/AviSynthPlus-Builds

[StainlessS]

Feature Request for Avs+,

Log to base n.

Can calc nDigits(int) in script to nearly 10,000,000 for base BASE where BASE = 10, using

BASE=10
Int(Log(Max(n,1))/Log(BASE))+1

but craps out due to imprecise calcs in 32 bit float.

test,

Function nDigits(Int n) { Return Int(Log10(Max(n,1)))+1 } # Equivalent for +ve int:- Strlen(String(n)) : Log10 v2.60+ [v2.58, Log10(n) = Log(n)/Log(10) ]


Function nDigitsB(Int n,Int "Base") { Base=Default(Base,10) Assert(2 <= Base <= 36,"nDigits: Bad Base") Return Int(Log(Max(n,1))/Log(Base))+1 }

E=0

# Error MisMatch just before 10,000,000

For(i=0,2000000000) {
n1=nDigits(i)
n2=nDigitsB(i)
if(n1!=n2) {
E=E+1
RT_DebugF("%i] n1=%d n2=%d E=%d",i,n1,n2,E,name="TestBUG: ")
}
if(i% 100000 == 0) {
RT_DebugF("%i] E=%d",i,E,name="PROGRESS: ")
}
}

MessageClip(String(E,"Done E=%.0f"))


Of course there are other tricky bits, eg -ve numbers, [EDIT: or those that we might want as unsigned, eg $FFFFFFFF]
denary uses '-' sign and magnitude, whereas others do not.

Anyways, Log to base n via 64bit double would help.
Tanks :)

[Dogway]

Yep, overall more precision would help (specially for all the matrix calculations), but it might be difficult to implement.

[StainlessS]

but it might be difficult to implement.

The feature requested because of one log divided by another with only 32 bit precision,
Log to base n, if done in 64bit avoids the problem.
If you mean implement 64 bit floats in AVS, I would not hold out too high an expectaion there,
AVSValue [C/C++] is a union of several types, biggest being 32 bit, to add a 64 bit double
would increase size of AVSValue by 4 bytes, and break a whole helluva lot of existing plugins, which only
expect the current sized AVSValue, crashes galore.
A lot of plugins [ALL probably ] would need be recompiled with the new headers with increased AVSValue size, and
you could never mix old/new plugins or old/new avisynth. [return value from a plugin is an AVSValue, so are arguments to a plugin]
Also, some less than brilliant code [maybe some of mine, but I think/hope not, use fixed size for allocating float arrays for buffers,
its hard {some may say impossible} to fit and 8 byte double redefined as float, into a 4 byte gap].

Doubt if anything like that will appear in the next few weeks. [or decades :EDIT: but there are some clever guys here, so who knows.]

[LigH]

I guess a generic logarithm function could quickly be added via plugin compiled in a language which can calculate it in high precision internally and then return a single precision float compatible to AviSynth ... :cool:

[Dogway]

Yes I have done before the divide by Log(base) to get a log() over a different base. Want to think it worked for my case.
I think it shouldn't be less difficult to implement than current log() or log10(). I mean there are examples of 64-bit intermediate so it can be implemented MulDiv (http://avisynth.nl/index.php/Internal_functions#MulDiv)

In that regard I would like to have similar functions for multiply in 64-bit Mul() and maybe Sum()

[StainlessS]

Doggy, Actually I'm gonna change my mind a bit, x64 AVS+ must [I presume] have facility to store 64 bit pointer in AVSValue [eg pointer to clip {or safe pointer to clip, or whatever it is}],
so maybe for x64 not quite so difficult, maybe. There would still be a lot of 'hidden' dangers though, way more likely than the Y2K whotsit that never really materialised.
[EDIT: Dont know why, but avs x64 did not even cross my mind only x86 avs, even though I only use x64 avs myself, go figure]

added via plugin compiled in a language which can calculate it in high precision internally and then return a single precision float compatible to AviSynth
Yep, thats exactly what I wanted but as builtin function, I could easily add it to eg RT_Stats, whenever I get around to going back to it.

[qyot27]

I mean, maybe this is the migraine talking, but if it really needed to be cordoned off from the existing AVSValue, couldn't a new AVSValue2 structure or something like it be possible that allows for all the bigger types (heck, some CPU arches can do quad precision, or at least have it listed even if there's few - or no - existing examples of code making use of it) without posing a compatibility issue with old plugins?

[cretindesalpes]

Can calc nDigits(int) in script to nearly 10,000,000 for base BASE where BASE = 10, using
BASE=10
Int(Log(Max(n,1))/Log(BASE))+1
but craps out due to imprecise calcs in 32 bit float.

This problem can be addressed in a different way, using 100% integer code:
n = Max (n, 1) # n assumed positive, and stored as Int
d = 0
for (i = 0, 31)
{
if (n > 0)
{
d = d + 1
}
n = n / base
}
return d
If at some point n is converted to floating point, results won’t be accurate for large numbers because the 32-bit floating point mantissa is 23 bits only (+1 implicit lead bit). So all integers in the +/-2^24 range can be represented exactly. Out of this range, only a few of them are exact. Therefore using a dedicated 64-bit log+base function won’t help much if the input is 32-bit float.

[StainlessS]

I guess then its best if I just implement nDigitsB() or similar name, as plug func, with some additional control, number base, and on whether to treat
-ve input arg n as unsigned[extra care for 0x80000000]. Also have to decide on whether '-' for base 10 -ve numbers is counted as a digit or not, + maybe some other tricky bits.

I guess for my current immediate needs, I'll just use something like eg Strlen(RT_NumberString(n ,base=BASE,width=0))
where I just wanna know how long printed variable types are, so as to produce a formatted output listing.
{but converting to a string for something like this, has long been repulsive to me due to AVS not having string garbage collection}

Also I'll just use eg StrLen(String(v)) for Float and Bool.

And, for RT_Stats DBase type 'bin' {an unsigned 8 bit int} can just use nDigitsB() as it currently stands.

{I wanna be implementing user configured format for generic DB records listing, eg print a particular field as dec or hex [EDIT: or binary], and with self adjusting formatted width for each field <after scanning for longest field data over entire DBase record range>}


RT_NumberString(int ,int "base"=10, int "width"=0)
First arg is an integer to convert to a number base/radix string.
Base, (10, 2 -> 36), is the number base or radix, eg 2 == Binary, 8 == Octal, 10 == Denary/Decimal, 16 == Hexadecimal.
The default of 10 (decimal) will just convert a number to its decimal string equivalent possibly with a '-' minus sign.
All number bases with the exception of decimal, will be unsigned form, ie -1 to hexadecimal will produce "FFFFFFFF",
(the sign is in the digits rather than as separate 'sign and magnitude' used in decimal representation).
The digits used for the base are, "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". Binary uses first two; decimal, the first 10;
Hexadecimal the first 16; base 36 all 36 digits.
Width, (0, 0 -> 32) is the minimum width of the returned string.
eg RT_NumberString(255,16,4) returns "00FF".
To convert a Float to a decimal string use Avisynth native "String()" func.


Nifty bit of code there C, wish I still had my Knuth Volume 1 [long since left on a train somewhere], so as to check out
if thats where you got it. :)

[guest]

Avs+ r3682
https://gitlab.com/uvz/AviSynthPlus-Builds

Hi ked,

Not sure what's going on with this build, but I have had major decoding problems on 1 PC, but every other PC it has worked fine.

Had to revert back to r3661, on that 1 PC...strange behaviour :sly:

[kedautinh12]

Hi ked,

Not sure what's going on with this build, but I have had major decoding problems on 1 PC, but every other PC it has worked fine.

Had to revert back to r3661, on that 1 PC...strange behaviour :sly:

You need report here
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[guest]

You need report here
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

Yeah, I can't be bothered signing up, just to do that...I found a fix, so I'm happy.

[LigH]

But others may be left sad.

[guest]

But others may be left sad.

LigH, it's interesting how you quite often find some of my posts (anywhere in the Forum), and leave a very "thought provoking" comment :)

In my post about r3682, I mentioned that it only had a problem on 1 PC (so far), and going back to r3661 solved the problem, however, on further thought, it maybe an AVX thing, as the Xeon 5680's don't support AVX, and therefore, I will have several PC's that r3682 will probably have the same issue.

So even though I wont be reporting this "officially", I'm sure someone will pickup on this problem, and either give an explanation, or better still, fix it (for all the older PC's out there)

[FranceBB]

Scenario: I index a file flagged as TFF but that is actually BFF.

Question: Why when I use "AssumeBFF()" the frame property value _FieldBased isn't updated and stays to 2, Top Field First?

Here the indexing says _FieldBased(2) so Top Field First
https://i.imgur.com/2GFk93H.png

Here I use AssumeBFF() but the value of _FieldBased stays to 1, so Top Field First:

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

That is until I set it myself with: PropSet("_FieldBased", 1)

https://i.imgur.com/0BIZ0cj.png



I generally nuke all frame properties with propclearall() but in our staff the collective decision was to make frame properties work, so I'm trying to make them work...

So... is this expected / the right behavior? And in case: why?

[LigH]

Interlaced clips are not generally field based. This property means something different: The result after "SeparateFields()" is field based because previously woven fields are now separate frames.

[FranceBB]

Interlaced clips are not generally field based. This property means something different: The result after "SeparateFields()" is field based because previously woven fields are now separate frames.

I know, that was in "Avisynth terms" before frame properties were introduced.
The "FieldBased" and "FrameBased" meant something else entirely and were about what you're describing, in fact you had AssumeFrameBased() and AssumeFieldBased(), but this "_FieldBased" has nothing to do with AssumeFieldBased(), it's a frame property provided by the indexer in an FFMpeg-like style, hence the nightmare and why I generally start every script with: propclearall() to go back to the good old Avisynth.

[StvG]

Keep in mind that AssumeBFF/AssumeTFF/AssumeFieldBased... are clip properties while _FieldBased is frame property.

[FranceBB]

Gotcha.
So the old Avisynth clip properties won't update the new ffmpeg frame properties and that's the expected behaviour 'cause it's the user himself that has to populate them with propset (), I see...
I guess I'll shy away from frame properties once again

[qyot27]

Okay, so after so many months of putting this off, I have some performance comparisons between different CPU architectures.

Performance benchmarks for AviSynth+ on PowerPC and ARM (Apple Silicon)

The test benches are:
Power Mac G5 Quad, 8GB of DDR2 SDRAM, 7200rpm hard drive, Mac OS X 10.5 "Leopard"
Power Mac G5 Quad, 8GB of DDR2 SDRAM, SSD in USB/FW enclosure, booted over USB 2.0, Debian (Ports) sid ppc64
M1 Mac Mini, 8GB LPDDR4X Unified memory, Internal SSD, macOS 12 "Monterey"
(Control system) Intel Core i5-9400, 64GB DDR4 SDRAM, NVMe M.2 SSD, Ubuntu 22.04

There currently are no SIMD optimizations for AltiVec (PowerPC), or NEON (ARM), so those architectures are essentially at SetMaxCPU("none") anyway. There's also some difference in the compilers used: the M1 Mac Mini uses the default AppleClang, the G5 in OS X uses GCC 7, while the G5 in Debian and the Core i5 both used GCC 12. And because of the difference in architectures, the Version() output does differ slightly in horizontal resolution.

Single-thread Script:
Version(5000).ConvertToYUV420()

Multi-thread script:
SetFilterMTMode("DEFAULT_MT_MODE", MT_NICE_FILTER)
Version(5000).ConvertToYUV420()
Prefetch(x)

Testing:
avs2yuv test.avs -o /dev/null

Build types:
Default build, equivalent to no outstanding optimzations (GCC -O0, in effect)
-O3, which is the highest(?) level of optimization GCC provides in a single preset and includes tree vectorization

+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| | G5 Quad, OS X | G5 Quad, Debian | M1 Mac Mini | Core i5-9400 (SetMaxCPU = none) | Core i5-9400 |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Single thread | 66.98 fps | 40.02 fps | 477.51 fps | 353.41 fps | 840.73 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Single thread, -O3 | 260.32 fps | 319.96 fps | 2285.78 fps | 1373.73 fps | 7110.95 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=4 | 172.41 fps | 150.31 fps | 1744.24 fps | 1387.84 fps | 3343.81 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=4, -O3 | 639.01 fps | 1143.41 fps | 7897.31 fps | 5505.51 fps | 30668.71 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=6 | - | - | - | 1990.05 fps | 4603.13 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=6, -O3 | - | - | - | 6838.58 fps | 26036.46 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=8 | - | - | 2233.69 fps | - | - |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=8, -O3 | - | - | 9821.22 fps | - | - |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
Yeah, the obvious problem above is the whole 'running Debian in an enclosure through a USB 2.0 port', rather than directly through the SATA interface inside of the Mac. I do wonder if the rather poor -O0 numbers on Debian reflect that issue somewhat, even if the -O3 runs don't.

To be fair, the Power Mac G5 Quad was released in 2005, the M1 Mac Mini in 2020, and the Core i5 machine was built in 2019 (initially with only 16GB of RAM, upgraded to 64GB at the end of 2021). The G5 also can take a maximum of 16GB, which I may eventually do, so I'm not exactly sure how that might affect later results for the same test.

The M1 is a heterogenous chip, with 4 performance cores and 4 efficiency cores. Running Prefetch(4) was both to make it comparable to the G5 being a quad core, but it also demonstrates the core topology in the M1, as I'm guessing it prefers the performance cores first and the efficiency cores second, as evidenced by the much smaller jump in performance going from 4 threads to 8 threads (not nothing, but not anywhere near like having 8 performance cores).

Version().ConvertToYUV420() is also a really, really synthetic and unscientific benchmark, and not really representative of importing actual footage and filtering it. But since Version() is often one of the first scripts someone runs, why not?

[real.finder]

I did test with 12400F in win11 with Avs+ r3682 by asd-g (G S in gitlab) https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/44dd302916f1097f7a5deb69d65f9b0963cc654b/x64/AviSynth.dll

SetMaxCPU("none")
Version(5000).ConvertToYUV420()

PS Z:\> .\avs2yuv test.avs - > NULL
Avs2YUV 0.30 (https://github.com/DJATOM/avs2yuv/releases/download/0.30/avs2yuv.exe)
Script file: test.avs
Resolution: 384x104
Frames per sec: 24
Total frames: 5000
Progress Frames FPS Elapsed Remain
[100.0%] 4999/5000 521.71 0:00:09 0:00:00
Started: Sat Sep 10 07:13:17 2022
Finished: Sat Sep 10 07:13:26 2022
Elapsed: 0:00:09

faster than M1 :D

edit: with avs2yuv test.avs -o NUL is even faster

PS Z:\> .\avs2yuv test.avs -o NUL
Avs2YUV 0.30
Script file: test.avs
Resolution: 384x104
Frames per sec: 24
Total frames: 5000
Progress Frames FPS Elapsed Remain
[100.0%] 4999/5000 651.68 0:00:07 0:00:00
Started: Sat Sep 10 09:04:01 2022
Finished: Sat Sep 10 09:04:08 2022
Elapsed: 0:00:07

To be fair, the Power Mac G5 Quad was released in 2005

I wonder what will PS3 CELL in Linux will do

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?

[qyot27]

I did test with 12400F in win11 with Avs+ r3682 by asd-g (G S in gitlab) https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/44dd302916f1097f7a5deb69d65f9b0963cc654b/x64/AviSynth.dll

SetMaxCPU("none")
Version(5000).ConvertToYUV420()

PS Z:\> .\avs2yuv test.avs - > NULL

edit: with avs2yuv test.avs -o NUL is even faster
The first run was redirecting to a file named NULL, the second was actually going to the null device.

I wonder what will PS3 CELL in Linux will do
You'd probably be limited by what version of what distro you could run on it, as the only ones I was aware of are long dead or would have dropped support for the PS3 by now. Gentoo or one of the *BSDs (yes, I know, not Linux) might be the only really viable contemporary options left at this point.

GCC also dropped support for the SPE side of the Cell architecture in GCC 10, so you'd either have to make do with only the PPE (essentially a regular dual-core PowerPC, derived from the POWER4 like the G5 was), or you would have to go back to GCC 9 and hope it could optimize across the entire unit.

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?
Nope. The C++ ABIs are incompatible with each other. Unless there's some way of wrapping C++ dlls in a C interface bridge, but I'm not holding my breath.

[qyot27]

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?
What is possible, though, is having AviSynth+GCC live alongside the regular MSVC builds, with only one of them active at a time. 64-bit* builds of FFmpeg, x264, or avs2yuv will accept either one. GCC plugins can be stored in their own plugins_gcc and plugins64_gcc directories, which keeps them from conflicting with the MSVC ones.

*32-bit requires a completely separate build; when I've put up FFmpeg or mpv builds, that's what the -avsgcc suffixed ones are.

On Windows, I have symlinks to AviSynth.dll in system32 and syswow64 instead of the real .dlls, which I have in the typical AviSynth+ installation path. Then I can have many different versions there, with suffixes on them, and if I need to test one, I just change out which one is the active AviSynth.dll that the symlinks are pointed at:

$ ls -l
total 122980
-rwxrwxrwx 2 qyot27 qyot27 5811200 Mar 17 22:27 AviSynth32.dll
-rwxrwxrwx 2 qyot27 qyot27 351744 Dec 21 2008 avisynth32.dll.258
-rwxrwxrwx 2 qyot27 qyot27 5355520 Jan 11 2021 AviSynth32.dll.370
-rwxrwxrwx 2 qyot27 qyot27 6279168 Dec 29 2021 AviSynth32.dll.371
-rwxrwxrwx 2 qyot27 qyot27 15084112 Mar 20 22:43 AviSynth32.dll.372gcc
-rwxrwxrwx 2 qyot27 qyot27 378368 May 17 2016 avisynth32.dll.bak
-rwxrwxrwx 1 qyot27 qyot27 13509136 Feb 21 2021 AviSynth32.dll.staticgcc
-rwxrwxrwx 2 qyot27 qyot27 6542336 Mar 17 22:24 AviSynth64.dll
-rwxrwxrwx 2 qyot27 qyot27 5968384 Jan 11 2021 AviSynth64.dll.370
-rwxrwxrwx 2 qyot27 qyot27 6443520 Dec 28 2021 AviSynth64.dll.371
-rwxrwxrwx 2 qyot27 qyot27 19356916 Mar 20 22:43 AviSynth64.dll.372gcc
-rwxrwxrwx 2 qyot27 qyot27 19267536 Dec 24 2021 AviSynth64.dll.gcc
-rwxrwxrwx 2 qyot27 qyot27 14604864 Mar 21 2019 AviSynth64.dll.gcc2831
-rwxrwxrwx 1 qyot27 qyot27 2047488 Jan 11 2021 DevIL32.dll
-rwxrwxrwx 1 qyot27 qyot27 2300928 Jan 11 2021 DevIL64.dll
drwxrwxrwx 1 qyot27 qyot27 0 Jan 1 2022 docs
drwxrwxrwx 1 qyot27 qyot27 4096 Jan 1 2022 Examples
drwxrwxrwx 1 qyot27 qyot27 12288 Jan 1 2022 FilterSDK
drwxrwxrwx 1 qyot27 qyot27 4096 Jan 1 2022 License
drwxrwxrwx 1 qyot27 qyot27 40960 May 29 14:16 plugins
drwxrwxrwx 1 qyot27 qyot27 4096 Mar 20 14:54 plugins+
drwxrwxrwx 1 qyot27 qyot27 4096 May 20 23:11 plugins64
drwxrwxrwx 1 qyot27 qyot27 4096 Mar 20 14:53 plugins64+
drwxrwxrwx 1 qyot27 qyot27 4096 Mar 20 23:40 plugins64_gcc
drwxrwxrwx 1 qyot27 qyot27 4096 Mar 20 23:40 plugins_gcc
-rwxrwxrwx 2 qyot27 qyot27 170739 Dec 31 2021 readme_history.txt
-rwxrwxrwx 1 qyot27 qyot27 100640 Jun 19 2020 readme.txt
-rwxrwxrwx 2 qyot27 qyot27 23234 Jul 5 2018 'Setup Log 2018-07-05 #001.txt'
-rwxrwxrwx 2 qyot27 qyot27 259173 Nov 29 2020 'Setup Log 2020-11-29 #001.txt'
-rwxrwxrwx 2 qyot27 qyot27 336204 Jan 1 2022 'Setup Log 2022-01-01 #001.txt'
-rwxrwxrwx 1 qyot27 qyot27 356473 Jan 1 2022 unins000.dat
-rwxrwxrwx 1 qyot27 qyot27 1256527 Jan 1 2022 unins000.exe

[real.finder]

Unless there's some way of wrapping C++ dlls in a C interface bridge

something like LoadPluginEx.dll that used to load AviSynth v1.0x and v2.0x plugins in avs 2.5? anyway if we can get the speed of GCC -O3 then it worth the workaround

[Reel.Deel]

New test build (r3689): https://gitlab.com/uvz/AviSynthPlus-Builds

[wonkey_monkey]

Is there a way to override an internal function but still call the original version when required? E.g.:


function FlipVertical(clip c) {
return c.FlipVertical
}


As you'd imagine, this causes AviSynth to crash due to the recursive nature of the function, but is there, or could there be, some prefixed version of FlipVertical than can be called from within the function instead?

It would be useful to implement an environment-wide override for a built-in function, for example to workaround this oversight from way back when: http://forum.doom9.net/showthread.php?p=1849921

[EternalStudent]

Very cool you're testing on one of the newer Mac's with ARM! I used to mess around with a NVIDIA Jetson way back when (pre-public release), and wished there was more general support for arm64 hardware.

But on to my question... Are there any Avisynth+ logs I can look in, or a debug mode I can enable? I see a bit of text in a log, but it's very terse. And I'm not seeing an event connected with my problems.

I'm using SVP 4 and manually installed a newer Avisynth+ (the latest release 3.7.2). I'm having periodic visual hangs, but haven't found a log that mentions an issue. Nothing interesting/new in SVP's event log, nor Windows 10's event viewer, etc.

I'd estimate weekly or more, I see a video just stop changing on screen for 5-10 seconds, but the audio is still playing back fine. If I'm using other programs they continue working, but clicking on the player seems to cause the system to try to fix the issue. Which makes the whole UI hang for 2-3 seconds (mouse cursor stops moving), then suddenly it'll work again... and playback video frames at higher speed trying to get the video to match the audio position. No other crashes or instability is noticed so I think it's SVP related, and Avisynth+ seems a logical place to get more information.

I realize this is an atypical use case for the program. And that they package a specific older version, though I can't seem to figure out how to use that copy after my manually installed version. So if I revert it'll be to some random thing I've downloaded, not whatever their tested version is.

Last I looked they were using a pretty old version, like the first after starting development again. And I couldn't find a labeled version that printed the same text in the log (website said 3.5.1, but log said 3.5...it's been a bit since I last tried to downgrade so I might be remembering wrong).

System details... Intel i7-4790k, 32GB RAM, NVIDIA 1080 ti, Windows 10 64-bit, all with latest "release" updates and drivers. Virtualization features are enabled (HyperX) to allow WSL2 to function, but I haven't been using it lately. GeForce Experience is installed, and it's doing the video driver updates to the gaming driver (not studio version). Using MPC-HC + AviSynth Filter + (internal) LAV Filters for playback. Worst resource usage (CPU) is often 30-50% from the video playback, and GPU often 10%. Also have Firefox and low resource games running, but I've seen the video hangs with a variety of videos playing, games, and websites. And I'm not playing DRM videos on Firefox (mostly text documentation today).

[StainlessS]

Sounds to me like you could do with a re-install of W10, or revert to a previous good image (Macrium Reflect or whatever).
Nobody else seems to have your problems, I have pretty similar setup except for i7-8700, GTX 1070 and latest Standard studio driver.

There is a free version of Macrium Reflect (search for "Macrium Reflect free offline install") otherwise you get a downloader exe.
Can make USB bootable drive from Macrium Tools menu, thats the only part of Macrium that i use.

Can also try FoxClone if you like, is USB bootable cloner based on Linux, (Macrium can have problems with certain linux setups if you multi-boot),
can clone FAT/FAT32/NTFS, and Ext2/Ext3/Ext4 filesystems. [EDIT: I'de down the Std version, Edge version is Beta I think]

Good idea to make a known good image that is easily go-backable to.


EDIT: Here the Nvidia ADVANCED driver search page:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#
Latest Standard GeForce 10 x64 WHQL Studio = v472.84 / 13 Dec 2021
(I don't use the Game Drivers, I've had probs with them in the past - EDIT: Try install of Standard driver before re-install W10)

EDIT: Macrium Reflect (Free) x64 on FileHorse:- https://www.filehorse.com/download-macrium-reflect-64/

FoxClone:- https://www.foxclone.com/

EDIT: Also note from D9 thread "AMD, Intel and Nvidia driver issues and last recommended version"
Is there perhaps an error in OP PDF version number for 472.47 (there are two of them).
https://i.postimg.cc/nsv4CzC0/a3.jpg (https://postimg.cc/nsv4CzC0)

And from here [Official Advanced Driver Search | NVidia]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#
https://i.postimg.cc/SjXvxLmr/b4.jpg (https://postimg.cc/SjXvxLmr)

472.84 from 2nd image seems to be latest standard WHQL Studio Driver, and given same date as the latest 472.47 in pdf, ie 13 Dec 2021.

EDIT: To Below, thanks :)

You are right, I correct it soon, some problems now.

[Reel.Deel]

Are there any Avisynth+ logs I can look in, or a debug mode I can enable? I see a bit of text in a log, but it's very terse. And I'm not seeing an event connected with my problems.


Try using the logging facility: http://avisynth.nl/index.php/SetLogParams

[flossy_cake]

Are there any frame-accurate source filters for avisynth that support DXVA2-copyback hardware accelerated decoding like LAV Video Decoder seemingly does? Can Avisynth be configured to use LAV Video Decoder?

When opening .avs files with MPC-HC x64:


If I use DirectShowSource() I get 2 instances of external LAV Video Decoder in the system tray: 1 instance says DXVA2-copyback is active, the other not.


If I use LWLibavVideoSource() I get only 1 instance of external LAV Video Decoder in the tray and it says DXVA2-copyback is not active.

I've read that DirectShowSource() isn't frame accurate.

Trying to understand how this all works -- I thought "source filter" was separate from "transform filter" but it seems in Avisynth world a source filter can do both.

[DTL]

"If I use DirectShowSource() I get 2 instances of external LAV Video Decoder in the system tray: 1 instance says DXVA2-copyback is active, the other not."

May be try to construct DirectShow graph manually in the GraphEdit/GraphStudioNext to check and be sure what is happen inside DirectShow part of Windows first and load saved .grf file into DirectShowSource() to prevent graph from auto-building ? (If it can save from auto-adjustment of graph after loading in DirectShowSource ?). You need to construct typical file playback graph using your required data decoder and delete final renderer (after checking if everything can playback OK) and save as .grf file. May be start from Render Media File command for auto graph building and adjust it if it not looks good.

Allowing GraphBuilder to auto-build DirectShow graph may sometime cause very wierd results like loading too much redundant modules and so on. May be it try to insert LAV Video Decoder twice to make colour conversion or something other not needed op. So first is real DXVA processing and second is just pass-through.

[StainlessS]

There is [EDIT: quite old] DirectShowSource2() [avss.dll] which is frame accurate but only supports video, no audio.
(No idea if DXVA2-copyback or whatever)
https://forum.doom9.org/showthread.php?t=134275

EDIT: avss.dll is from Haali media splitter, apparently there is updated Dss2Mod,

do search on it in D9 or Google.

EDIT: On Wiki:- http://avisynth.nl/index.php/DSS2mod

[guest]

New test build (r3689): https://gitlab.com/uvz/AviSynthPlus-Builds

Did someone forgot to "us" about this...

New test build (r3820)
https://gitlab.com/uvz/AviSynthPlus-Builds

[flossy_cake]

There is [EDIT: quite old] DirectShowSource2() [avss.dll] which is frame accurate but only supports video, no audio.
(No idea if DXVA2-copyback or whatever)
https://forum.doom9.org/showthread.php?t=134275

EDIT: avss.dll is from Haali media splitter, apparently there is updated Dss2Mod,

do search on it in D9 or Google.

EDIT: On Wiki:- http://avisynth.nl/index.php/DSS2mod

Thanks, but it looks a little old -- last update was from 2014. Would that really work with modern files? What is everyone using these days?

I was recommended LWLibavVideoSource which seems fine but the cache file generation takes forever, which DirectShowSource() doesn't suffer from. Also with LWLibavVideoSource I have to manually join the audio with something like AudioDub(LWLibavVideoSource(),LWLibavAudioSource()) -- am I doing this right? Should I be doing something else?

And it seems I was mistaken about the meaning of "frame accurate" -- I thought this meant the pixel values were decoded accurately. Seems that is referring to seek accuracy, which isn't that important to me (unless it interferes with other filters like TDecimate which rely on frame counters when eg. specifying manual overrides of certain ranges of frames).

[flossy_cake]

So first is real DXVA processing and second is just pass-through.

Yeah that occurred to me and I tested with 4k60HDR file which my system can only play smoothly if DXVA2 decoding is active, and it still stutters even though the 1st instance of LAV is saying DXVA2-copyback is active.

Anyway thanks I will check out my graph configuration. I have K-Lite codec pack installed, not sure if that's interfering.

edit: it seems k-lite already installed "Win7DSfiltertweaker" for me which I can use to try and control what decoders are used by DirectShowSource()

edit2: after investigating with GPU-Z which shows "video engine load" it seems that DirectShowSource() is infact using DXVA2-copyback decoding (via LAV). I don't know why it's stuttering on that video though. A separate issue is that "mediainfo" type metadata isn't getting passed to the renderer (in my case MadVR) so MadVR doesn't know it's a HDR video and tonemapping is wrong (on it's ctrl+J debug screen it says "best guess" instead of "says upstream").

edit3: the double instance of LAV Video Decoder seems to be due to MPC-HC being configured to use its own internal version of that filter, and unticking it inside MPC-HC options makes the 2nd instances disappear, except for LAV splitter which still has 2 instances. Framerate is still stuttery though. Nevermind, I guess DirectShowSource() just can't handle 4k60HDR. So for Avisynth I am limited to about 4k30 SDR it seems, which covers 99% of my videos so it's not a big deal. A bigger issue is the lack of metadata being passed to MadVR which could result in inaccurate colours since MadVR has to guess based on other metrics like resolution, framerate etc.

[flossy_cake]

A separate issue is that "mediainfo" type metadata isn't getting passed to the renderer (in my case MadVR) so MadVR doesn't know it's a HDR video and tonemapping is wrong (on it's ctrl+J debug screen it says "best guess" instead of "says upstream").

This seems to be the biggest issue I'd like to solve -- are there any Avisynth functions which can tell the Avisynth source filter to pass on metadata (like matrix, primaries, SDR/HDR etc.) so that when MadVR gets the pixel data from Avisynth it doesn't have to use "best guess"?

[StainlessS]

Thanks, but it looks a little old
I imagine that DirectShowSource (v1) looks even older.

Seems that is referring to seek accuracy, which isn't that important to me (unless it interferes with other filters like TDecimate which rely on frame counters when eg. specifying manual overrides of certain ranges of frames).
Where filters rely on frame accurate seeking, it will become important to you. [because the result may be garbled video]

[kedautinh12]

You know original directshowsource very old and don't update too long although avs+ still up to date

[gispos]

Did someone forgot to "us" about this...

New test build (r3820)
https://gitlab.com/uvz/AviSynthPlus-Builds

This repo contains Clang builds of AviSynthPlus.

Unfortunately I get error messages every now and then with these builds.
AvsPThumb (a delphi program) cannot create a clip every now and then. I have never had this problem with the official versions, but I have never tested a 'Clang' version before.
I don't know if it's the clang compiler or not.

Unfortunately I can't provide any exact information about the error, but I just wanted to post it here, even if it doesn't make much sense.

[kedautinh12]

This repo contains Clang builds of AviSynthPlus.

Unfortunately I get error messages every now and then with these builds.
AvsPThumb (a delphi program) cannot create a clip every now and then. I have never had this problem with the official versions, but I have never tested a 'Clang' version before.
I don't know if it's the clang compiler or not.

Unfortunately I can't provide any exact information about the error, but I just wanted to post it here, even if it doesn't make much sense.

Can you report to Asd-g??
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[qyot27]

This seems to be the biggest issue I'd like to solve -- are there any Avisynth functions which can tell the Avisynth source filter to pass on metadata (like matrix, primaries, SDR/HDR etc.) so that when MadVR gets the pixel data from Avisynth it doesn't have to use "best guess"?
What versions of AviSynth+ and LSMASHSource are you using?

Open the script in either FFmpeg to see the info printout, or play it back in mpv and throw the file stats up on screen by pressing i.

[flossy_cake]

What versions of AviSynth+ and LSMASHSource are you using?

The lastest one, just downloaded it a couple weeks ago and learning it for the first time.

Open the script in either FFmpeg to see the info printout, or play it back in mpv and throw the file stats up on screen by pressing i.

Test file (mkv): https://4kmedia.org/lg-daylight-hdr-uhd-4k-demo/

Opening the mkv directly in MPC-HC, which is configured to use LAV splitter & LAV video decoder: https://lensdump.com/i/1FME3o (everything is good)

Opening the mkv via an Avisynth script in MPC-HC (the script uses LWlibavVideoSource or DirectShowSource to open the mkv): https://lensdump.com/i/1FMkN9 (everything is wrong, MadVR can't see matrix, primaries, & EOTF).

Running the Avisynth script from ffmpeg comand line: https://lensdump.com/i/1FMCi2

[qyot27]

I said mpv. (https://mpv.io/installation/)

[VoodooFX]

Is there some bug in ConditionalFilter, variables in expression are lost with Prefetch?

https://i.imgur.com/0jDQZes.png

v = ColorBars(width=500, height=200, pixel_type="YV12")
Y = BlankClip(v, pixel_type="Y8", color_yuv=$000000)
w = BlankClip(Y, width=50, height=50, color_yuv=$FFFFFF)
m = Y.Overlay(w)
c1 = Y.Subtitle("1")
c2 = Y.Subtitle("2")
#ConditionalFilter(v, c1, c2, "Y.RT_YPlaneMinMaxDifference(mask=m) > 128")
ConditionalFilter(v, c1, c2, "Y.YPlaneMinMaxDifference() > 128")
Prefetch(2)

EDIT:
"global Y" solves error. Is this expected behavior?

[FranceBB]

I don't wanna be "that guy", but... I'm gonna say it anyway.
In 2017 (and again in 2019) I suggested adding XYZ to Avisynth so that we could handle it without workarounds just like we can handle RGB and YUV.
Aside from a bunch of people promoting VapourSynth (which I will NOT use) I didn't get much feedback.
I'm back in 2022 to see if there has been any progress on this and if there's any will to add this.
The reason is that nowadays it's basically impossible to handle XYZ stuff in Avisynth unless you make a very very very convoluted workflow.
Any XYZ stuff won't be indexed by LWLibavVideoSource() as it says that it's not supported, while FFMpegSource2() will index it but it will also convert it to YUV 4:4:4 16bit planar as the conversion is done internally with 16bit precision, so if you have like a 12bit XYZ you'll always end up with a 16bit YUV.
Now, although this isn't such a big deal for most people, it makes it impossible for those who receive MJPEG2000 files in XYZ to work with those inside Avisynth.
There are other people like Jean Philippe Scotto di Rinaldi (JPSDR here on Doom9) who use XYZ effectively, but had to mark it as fake RGB64 (while it's actually carrying XYZ) so anything that "receives" the XYZ will think it's RGB64 and it takes some workaround to make the whole chain from Avisynth to the encoder to work.

Recently I've got a user called spoRv asking for this too, so clearly there are people who work in XYZ other than me and who would like it to be supported.

I'm gonna quote myself from a reply I gave to a user here on Doom9 in a different topic, but still, it would be awesome to have proper XYZ support in Avisynth.


If you have a DCP, it means that it's a MJPEG2000 4:4:4 XYZ 12bit, however XYZ isn't natively supported in Avisynth (despite my desperate requests to support it dating back to 2017 and which I included in my meme collection https://forum.doom9.org/showthread.php?p=1953469).
There are some people like Jean Philippe who had to work in XYZ, so what they did was to create a fake RGB64 output on his ConvertYUVtoXYZ() function with XYZ inside. Some other people like Hydra/HolyWu/Asd just recognized that XYZ isn't supported in Avisynth and therefore indexers like LWLibavVideoSource() won't output anything and report an error:


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


Other people like Myrsloyk instead added automatic conversion, which is the case for ffms2, which brings me to the final reply of your question: if you index an XYZ 12bit file with FFVideoSource(), it will automatically bring it to 16bit, convert it to YUV and output a YUV 16bit stream.

As you can see here, my input was a MJPEG2000 in UHD XYZ 4:4:4 12bit and after indexing with FFVideoSource() it has become a YUV 4:4:4 16bit planar:

https://i.imgur.com/6j88Bqt.png


This is the Mediainfo of the original file:

Video
ID : 2
Format : JPEG 2000
Format profile : D-Cinema 4k
Format settings, wrapping mode : Frame
Codec ID : 0D010301020C0100-0401020203010104
Duration : 1 h 15 min
Bit rate : 248 Mb/s
Width : 3 996 pixels
Height : 2 160 pixels
Display aspect ratio : 1.85:1
Frame rate : 25.000 FPS
Color space : XYZ
Chroma subsampling : 4:4:4
Bit depth : 12 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.147
Stream size : 130 GiB (100%)
Title : Picture Track
Color range : Full



XYZ seen as is through MPV: https://i.imgur.com/46XuSBi.jpg
XYZ indexed by FFVideoSource() in Avisynth which automatically converts to YUV 16bit: https://i.imgur.com/xi8pHH4.jpg

[StainlessS]

@VX, as your post

v = ColorBars(width=500, height=200, pixel_type="YV12")
Y = BlankClip(v, pixel_type="Y8", color_yuv=$000000)
w = BlankClip(Y, width=50, height=50, color_yuv=$FFFFFF)
m = Y.Overlay(w)
c1 = Y.Subtitle("1")
c2 = Y.Subtitle("2")
#ConditionalFilter(v, c1, c2, "Y.RT_YPlaneMinMaxDifference(mask=m) > 128")
ConditionalFilter(v, c1, c2, "Y.YPlaneMinMaxDifference() > 128")
Prefetch(2)

https://i.postimg.cc/vHL42dk8/vx-00.jpg (https://postimages.org/)
Y, No problem for me.

EDIT: You using Neo (or Cuda [EDIT: or XP]) version Avs ?

EDIT: Swapping commented out ConditionalFilter() works Ok too (result looks same as above image).

[VoodooFX]

Y, No problem for me.

EDIT: You using Neo (or Cuda [EDIT: or XP]) version Avs ?

AvS+ 3.7.2 r3661
Maybe you are fooled by the first frame or scrolling in AvsPmod, try to play or encode it.

[StainlessS]

Oopsie Daisy, you are correct, I only loaded first frame in VD2

you could try GConditionalFilter(args="Y,M") [ie Grunt]


v = ColorBars(width=500, height=200, pixel_type="YV12")
Y = BlankClip(v, pixel_type="Y8", color_yuv=$000000)
w = BlankClip(Y, width=50, height=50, color_yuv=$FFFFFF)
m = Y.Overlay(w)
c1 = Y.Subtitle("1")
c2 = Y.Subtitle("2")
GConditionalFilter(v, c1, c2, "Y.RT_YPlaneMinMaxDifference(mask=m) > 128",args="Y,M")
#GConditionalFilter(v, c1, c2, "Y.YPlaneMinMaxDifference() > 128",args="Y,M")
Prefetch(2)

wurx OK

Oopsie Daisy:- https://www.youtube.com/watch?v=brMJfFK9d44

[VoodooFX]

you could try GConditionalFilter(args="Y,M") [ie Grunt]
Thanks for info, I might switch to that.

[TomArrow]

Hello. I'm trying to develop a plugin and running into super strange stuff. My plugin is an import plugin that produces an RGB64 image. When I try to use ConvertToRGB48() on the output I get the error

"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame".

I can assure you that my code does absolutely nothing CUDA-related. The same happens if I output RGB48 and try to convert to RGB64. This does not happen if I try to do this with a BlankClip.

However if I just leave it at outputting RGB64 and open the script without any conversions in VirtualDub, it shows me the image just fine with no issues.

Is this some new stuff? How do I fix this? I reckon the error might lie somewhere else and this might just be a symptom but I find this mystifying.

Edit: With ffmpeg I get access violation. Must be some other issue I guess that's bleeding over.

Edit 2: This actually happens even with an older version of the plugin: http://avisynth.nl/index.php/ImageSequence . If you take the 64 bit plugin and use it with the wildcard input filter for 2 jpeg files and then run ConvertToRGB48() after it, the same error happens, including the access violation in ffmpeg (but not in VirtualDub). I'm at a loss.

Edit 3: On a sidenote, my PC doesn't even have CUDA. It's an AMD APU without a discrete GPU.

Edit 4: Searching around on Google, I ignorantly (without knowing what it even does) tried adding onCPU(1) after the input plugin. Made no difference. Then I tried onCUDA(1) and it said "This AviSynth does not support memory type 2(CUDA)". This is, uh, really strange?

Edit 5: Ok it might have been an access violation that somehow went under the radar for years and nobody noticed. I fixed that, however I downgraded to a lower AVISynth version, so not sure if I'll get to test if it also solved the CUDA thing error.

Edit 6: Ok this problem was completely unrelated to the Access Violation problem. Bottom line is, every version above 3.7.0 (I tested from newest backwards) has this problem with the CUDA stuff.

[gispos]

This repo contains Clang builds of AviSynthPlus.

Unfortunately I get error messages every now and then with these builds.
AvsPThumb (a delphi program) cannot create a clip every now and then. I have never had this problem with the official versions, but I have never tested a 'Clang' version before.
I don't know if it's the clang compiler or not.

Unfortunately I can't provide any exact information about the error, but I just wanted to post it here, even if it doesn't make much sense.
New test build (r3820)
https://gitlab.com/uvz/AviSynthPlus-Builds

Since r3820 there are no more problems so far.
Nice!

[Stereodude]

Is prefetch supposed to slow down sources?

A script consisting of only a source

DGSource("HZLIP.dgi")

I get 550fps per AVSmeter without a prefetch or with a prefetch of 1. With a prefetch of 2 or more it drops to ~60fps. I'm sure you're wondering why I'm using prefetch with just a source. I'm not normally, but I'm trying to figure out if my script was source limited and saw this behavior.

[FranceBB]

Some plugins have their own multithreading that works internally and I'm pretty sure DGSource() is one of them.
For those who have their own multithreading and/or threadpool, Prefetch() will do nothing but harm.
To be absolutely fair, I'm not a big fan of Prefetch as I believe plugins should be multithreading and create their own thread-pool in the best and most efficient way, without relying on Avisynth trying to be smart.
Things used to be much worse back in the days (I'm talking about AVS 2.5 MT) and that came back to bite me in one of my first jobs as encoder for a streaming company when I was hardsubbing stuff as some filters didn't really like the temporal discontinuity introduced by some of the MT Modes.

Anyway, long story short, it's normal to get faster speeds without prefetch for some filters/plugins as it means that they create their own threadpool with their own multithreading (and rightly so).

[Stereodude]

Some plugins have their own multithreading that works internally and I'm pretty sure DGSource() is one of them.
For those who have their own multithreading and/or threadpool, Prefetch() will do nothing but harm.
To be absolutely fair, I'm not a big fan of Prefetch as I believe plugins should be multithreading and create their own thread-pool in the best and most efficient way, without relying on Avisynth trying to be smart.
Things used to be much worse back in the days (I'm talking about AVS 2.5 MT) and that came back to bite me in one of my first jobs as encoder for a streaming company when I was hardsubbing stuff as some filters didn't really like the temporal discontinuity introduced by some of the MT Modes.

Anyway, long story short, it's normal to get faster speeds without prefetch for some filters/plugins as it means that they create their own threadpool with their own multithreading (and rightly so).
FWIW, I did find that after adding another filter to the script that the prefetch at the end didn't slow down DGSource anymore. :confused:

[FranceBB]

FWIW, I did find that after adding another filter to the script that the prefetch at the end didn't slow down DGSource anymore. :confused:

Perhaps the filter you added is single thread and therefore nullified the advantage of DGSource()?

Try with:


DGSource()

Spline64ResizeMT()


###Use whatever parameters you like###


from plugins_JPSDR.dll
I know for sure that his plugins have their own multithreading and create their own threadpool, so you should see better results without Prefetch() compared to with Prefetch, thus confirming my hypothesis.


p.s if you don't get better results without Prefetch, then I'll join you in the :confused: :confused: :confused:

[Boulder]

My guess is that using Prefetch clogs up the lane between the CPU and the GPU in a single line DGSource's case. Have you checked what the GPU usage shows in Task Manager for the AVSMeter process? I've noticed that when launching an encode, it jumps very high at the beginning and then gradually slows down as the encoder does not request frames so fast (because my script has denoising, resizing etc. in it). In my case it's like 3-4% at maximum during the encode phase.

[Stereodude]

r3820 doesn't really do this anymore. I was using r3661 before. No prefetch is 550, prefetch(2) is 535, prefetch(12) is 500.

[DTL]

It may be a bug or issue with internal MT:

I sometime have lost of MT (single thread running) with adding


myclip=some_filter()
return myclip

Prefetch(N)


If simply left internal last clip as output

some_filter()

Prefetch(N)


- the MT of N threads is working. It can not be easy simulated with BlankClip but happens with last filter of MDegrainN (or Weave after MDegrainN) from mvtools for me. May be it depends on MT_MODE somehow too.

It is typically not a great issue because I use return as debug/tuning preview and production script is running without return at the end. But some finding.

[Gavino]

'return' ends the script execution so the Prefetch() is never invoked.

Do this:
return myclip.Prefetch(N)
or

return myclip. \
Prefetch(N)

[LigH]

Another variation: If you don't explicitly use any return statement, then the last statement of a script is the implicit "return last" statement. All you have to do is assigning your active clip variable to the implicit "last" clip variable. You can do that with an explicit assignment using the equal sign, or implicitly by just mentioning the clip variable in a single line.

myclip = some_filter()

myclip
# means the same as:
# last = myclip

Prefetch(N)
# means the same as:
# last = last.Prefetch(N)

# implicit last statement:
# return last

Keep in mind: Wherever you don't explicitly assign a specific clip variable (using "=" or "."), the result of a filter is assigned to the implicit clip variable "last".

[DTL]

"the last statement of a script is the implicit "return last" statement."

If add

return last
Prefetch(N)


The MT also not working.

Prefetch(N) before return -

Prefetch(N)
return last

the MT is working. Putting Prefetch to the beginning of script returns error 'bad arguments for Prefetch'. So it looks Prefetch(N) need to be applied to the last (output) clip ?

Found in the documentation: http://avisynth.nl/index.php/SetFilterMTMode
Enabling MT
You enable MT by placing a single call to Prefetch(X) at the end of your script, where X is the number of threads to use. If there is a return statement in your script it must be placed after Prefetch().

So to return something from middle of script with MT:

myclip = some_filter()

myclip=Prefetch(myclip, N)

return myclip

?

[LigH]

You really misunderstood.

"Implicit" statements are those you do not write in the script but they are in fact executed because you did not write them.

"the last statement of a script is the implicit "return last" statement."

But only

If you don't explicitly use any return statement

Only if.

[Gavino]

If you don't explicitly use any return statement, then the last statement of a script is the implicit "return last" statement.
Being pedantic, it is not strictly true that "return last" is the default action when 'return' is omitted.
In practice, that is usually what happens, but there are some cases when 'last' is not returned, such as when the final expression is not a clip. See here (http://forum.doom9.org/showthread.php?p=1642079#post1642079).)

[guest]

Deleted. Wrong thought.

Try this :-

Go into "edit", and the delete option is in the bottom right corner of the message window.

[gispos]

Try this :-

Go into "edit", and the delete option is in the bottom right corner of the message window.

Thanks :)

[TomArrow]

Any clues on the "Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame" problem?

Way to reproduce:

1. Get newest AVISynth+ release.

2. Grab CoronaSequence plugin from http://avisynth.nl/index.php/ImageSequence

3. Load image sequence with CoronaSequence command.

4. Add ConvertToRGB64() at the end.

[Emulgator]

If I only had enough time I would skim AviSynth source code for that error
"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame"

[VoodooFX]

Any clues on the "Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame" problem?
No error on my side.

[Reel.Deel]

If I only had enough time I would skim AviSynth source code for that error
"Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame"

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/core/DeviceManager.cpp#L81

[TomArrow]

I should have added that I have an AMD 5700G APU, but someone else I know had this same issue and he has an RTX 3090 and an i9-10850k. Both our PCs run Win 10 Pro.

It happens with every AviSynth+ version above 3.7.0. 3.7.0 itself doesn't have this problem.

@Reel.Deel Yeah I found this code as well but I'm not sure what to do about it. I don't know how to debug AVISynth itself and I don't understand any of that code. And the plugin was written before any of this CPU/GPU stuff was added so it shouldn't really do anything in that regard.

Edit: Also for the record I wrote "ConvertToRGB48" in the error message and "ConvertToRGB64" in the reproduction steps. This was a mistake, however it applies to both really, it happens with both attempted conversions.

[flossy_cake]

Is there any interest in upgrading Avisynth+'s internal DirectShowSource filter to enable it to output 10-bit pixel formats like P010 or Y410 as these are the only 10-bit ones supported by LAV Video Decoder which means we can't get 10-bit output from DirectShowSource if using LAV.

I tried forcing pixel format to RGB48 which is the only >8-bit format supported by both LAV Video and DirectShowSource, however it fails to load LAV at all and I just get a blank screen.

edit: I noticed FFMpegSource2 and LWlibavVideoSource do support P010 but I'd still prefer to use DirectShow since it can use LAV Video Decoder which has a good feature set & no caching/indexing overhead.

edit: relevant log bit for DirectShowSource where it seem to be trying to use P010 but failing (I don't know why... LAV Video supports it)


00:00:00.270 001 0x00000000048542D0 0x00001154 *** Video: Subtype rejected - 'HVC1' {31435648-0000-0010-8000-00aa00389b71}
00:00:00.270 001 0x00000000048542D0 0x00001154 *** Video: Format type - {e06d80e3-db46-11cf-b4d1-00805f6cbbea}
00:00:00.270 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ConnectedTo() ** VFW_E_NOT_CONNECTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype rejected - 'P010' {30313050-0000-0010-8000-00aa00389b71}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Format type - {f72a76a0-eb0a-11d0-ace4-0000c0cc16ba}
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype rejected - 'P010' {30313050-0000-0010-8000-00aa00389b71}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Format type - {05589f80-c356-11ce-bf01-00aa0055595a}
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype rejected - 'P016' {36313050-0000-0010-8000-00aa00389b71}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Format type - {f72a76a0-eb0a-11d0-ace4-0000c0cc16ba}
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype rejected - 'P016' {36313050-0000-0010-8000-00aa00389b71}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Format type - {05589f80-c356-11ce-bf01-00aa0055595a}
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype denied - NV12
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype denied - NV12
00:00:00.300 020 0x00000000048542D0 0x00001154 GetSample::ReceiveConnection() ** VFW_E_TYPE_NOT_ACCEPTED **
00:00:00.300 001 0x00000000048542D0 0x00001154 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Subtype accepted - 'YV12' {32315659-0000-0010-8000-00aa00389b71}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: Format type accepted - {f72a76a0-eb0a-11d0-ace4-0000c0cc16ba}
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: format accepted: 1920x1080, pixel_type YV12, avg_time_per_frame 417083x100ns
00:00:00.300 001 0x00000000048542D0 0x00001154 *** Video: bFixedSizeSamples=1, bTemporalCompression=0, lSampleSize=3110400
00:00:00.512 002 0x00000000048542D0 0x0000135C GetSample::NewSegment(0, 63048817080, 1.000000) (video)
00:00:00.602 001 0x00000000048542D0 0x00001368 GetSample::QueryAccept(video) MEDIATYPE_Video
00:00:00.602 001 0x00000000048542D0 0x00001368 *** Video: Subtype accepted - 'YV12' {32315659-0000-0010-8000-00aa00389b71}
00:00:00.602 001 0x00000000048542D0 0x00001368 *** Video: Format type accepted - {f72a76a0-eb0a-11d0-ace4-0000c0cc16ba}
00:00:00.602 001 0x00000000048542D0 0x00001368 *** Video: format accepted: 1920x1080, pixel_type YV12, avg_time_per_frame 417083x100ns
00:00:00.602 001 0x00000000048542D0 0x00001368 *** Video: bFixedSizeSamples=1, bTemporalCompression=0, lSampleSize=3110400
00:00:00.602 020 0x00000000048542D0 0x00001368 GetSample::ReceiveConnection() ** VFW_E_NOT_STOPPED **
00:00:00.612 002 0x00000000048542D0 0x00001368 Receive: video sample time span x100ns 0 to 417083 (417083)
00:00:00.632 005 0x00000000048542B0 0x00001154 Directshow duration 63048817080, frame_count 0.
00:00:00.632 005 0x00000000048542B0 0x00001154 New Video: 1920x1080, frame_count=151167, pixel type=YV12.
00:00:00.632 fff 0x00000000 Close Create_DirectShowSource log 3.


The clip is 10-bit 4:2:0.

[tormento]

Is KTGMC supported by AVS+? I have read somewhere that the plugin should be rewritten to make it work.

[Reel.Deel]

Is KTGMC supported by AVS+? I have read somewhere that the plugin should be rewritten to make it work.

No.

1). Official AviSynth+ releases are not built with CUDA support enabled.

2). All of the AvisynthCUDAFilters need to be recompiled to work with the current AviSynth+.

See the issues page: https://github.com/AviSynth/AviSynthPlus/issues/296

[tormento]

No.
That is a real pity.

I hope that Pinterf (or someboby else!) one day will port the most useful Nekopanda plugins.

[gispos]

That is a real pity.

I hope that Pinterf (or someboby else!) one day will port the most useful Nekopanda plugins.

+1, it is a real pity that the Cuda support was not followed up.

[FranceBB]

+1, it is a real pity that the Cuda support was not followed up.

+2
We have Avisynth Neo largely merged into Avisynth+ now, however we can't use the actual useful part of it which is the OnCUDA() and OnCPU() functions with the old AVS Neo plugins. It would be really nice if someone picked the Neo plugins up and recompiled them to target the modern AVS+ headers as it would speed things up a lot.

[poisondeathray]

avs+ r3682 x64
https://i.postimg.cc/TwQ1BXF7/yuy2-coloryuv-analyze-true.png


b=blankclip(width=360, height=160, colors=[0,128,128], pixel_type="YV16")
w=blankclip(width=360, height=160, colors=[255,128,128], pixel_type="YV16")

stackhorizontal(b,w)
coloryuv(analyze=true)
subtitle("YV16")
planar=last

b=blankclip(width=360, height=160, colors=[0,128,128], pixel_type="YUY2")
w=blankclip(width=360, height=160, colors=[255,128,128], pixel_type="YUY2")

stackhorizontal(b,w)
coloryuv(analyze=true)
subtitle("YUY2")
packed=last

stackvertical(planar,packed.ConvertToYV16())

[kedautinh12]

Are you try r3820?
https://gitlab.com/uvz/AviSynthPlus-Builds

[poisondeathray]

Are you try r3820?
https://gitlab.com/uvz/AviSynthPlus-Builds

same issue with r3820

[Reel.Deel]

same issue with r3820

Not much has changed since r3682. The much higher number is just because of 120+ documentation commits.

I created a new issue for this bug: https://github.com/AviSynth/AviSynthPlus/issues/304

[pinterf]

Avisynth 3.7.3 test 2
Avisynth+ 3.7.3 test 2 (20221114) (https://drive.google.com/uc?export=download&id=1fCPbb4n1-nuR_mAaLG_4o1Zxfciwr2A4)

20221114 3.7.3 WIP
------------------
- Fix (#304): ColorYUV analyze=true was displaying wrong min-max values for YUY2
- Fix: C API undefined behavior when upstream throw runtime error
- Mute compilation warnings in avisynth.h
- CMakeLists.txt: fix clang-cl/intel with ninja generator
- Fix (#293): "Text" to throw proper error message if the specified font name (e.g. Arial) is not found among internal bitmap fonts.
- Fix (#293): "Subtitle" and "Text" filter to respect the explicitely given coorditanes for y=-1 or x=-1,
instead of applying vertical/horizontal center alignment.
- Fix: C interface crash when using avs_new_video_frame_p(_a)
- Fix (#283): broken runtime functions min/max/minmaxdifference when threshold is not 0 (returned -1). Regression in 3.7.2
- New: add a sixth array element to PlaneMinMaxStats: average. Defines variable "PlaneStats_average" as well if setting variables is required.
- Fix (#282): ConvertToRGB
- do check for exact 8 or 16 bit input, because packed RGB formats exist only for 8 and 16 bits
- keep alpha for RGBA planar - convert RGBAP8/16 to RGB32/64, while RGBP8/16 is still RGB24/48

[VoodooFX]

Avisynth 3.7.3 test 2

Thanks. So far so good.

[Dogway]

Thanks a lot pinterf, does this inherit changes from r3820 or are they different branches?

[Reel.Deel]

Thanks a lot pinterf, does this inherit changes from r3820 or are they different branches?

Same branch, pinterf's build is r3825.

[FranceBB]

Thank you, Ferenc!
Hugely appreciated, as always! :D
This is mid-November and we're already at Beta 2, looks like it's gonna be another white Christmas with Avisynth 3.7.3 Stable! :D

[poisondeathray]

Thanks for the new test version


RGBAdjust clips to [0,1] for RGBPS ? Is it intended behaviour ?


blankclip(pixel_type="RGBPS", colors=[1.1, 1.1, 1.1])
#avspmod correctly reads 1.1,1.1,1.1 with color picker

#RGBAdjust(rb=-0.05) #avspmod and RGBAdjust(analyze=true) read 1,1,1

#RGBAdjust(rb=-0.2) #avspmod and RGBAdjust(analyze=true) read 0.9,1,1 ; implies clipping only occurs after the adjustment

#RGBAdjust(analyze=true) #avspmod reads 0 to 1, when the call is alone, or any instance prefaced with RGBAdjust

#expr("x 0.05 -", "x", "x") #works correctly, avspmod reads 1.05,1.1,1.1 ; but when followed by RGBAdjust(analyze=true) reads 1,1,1


There is no way to load native float content into avs+ yet (eg. .hdr, .exr, or .tiff float, maybe the vapoursynth IM plugin could be ported...ahem.. :D )

[StainlessS]

Thanx P.

[pinterf]

RGBAdjust clips to [0,1] for RGBPS ? Is it intended behaviour ?

Yes, clipping is done before applying gamma.

[pinterf]

Thank you, Ferenc!
Hugely appreciated, as always! :D
This is mid-November and we're already at Beta 2, looks like it's gonna be another white Christmas with Avisynth 3.7.3 Stable! :D
Positive aspect of slowness: I spared tens of hours per month by not visiting doom9 forums. Addiction is dangerous.

[pinterf]

Any clues on the "Device unmatch: ConvertToRGB48[CPU] does not support [CUDA] frame" problem?

Way to reproduce:

1. Get newest AVISynth+ release.

2. Grab CoronaSequence plugin from http://avisynth.nl/index.php/ImageSequence

3. Load image sequence with CoronaSequence command.

4. Add ConvertToRGB64() at the end.
Being a 64 bit plugin from 2010, when no 64 bit Avisynth+ existed, it is pure luck if it works or not. Plus: maybe it is a 2.5-style plugin which can be an additional pain. If so, the plugin must be first recompiled with a 2.6 / Avisynth+ header.

[Reel.Deel]

Being a 64 bit plugin from 2010, when no 64 bit Avisynth+ existed, it is pure luck if it works or not. Plus: maybe it is a 2.5-style plugin which can be an additional pain. If so, the plugin must be first recompiled with a 2.6 / Avisynth+ header.

It seems Tom is using the Avisynth+ header but with AvisynthPluginInit2: https://github.com/TomArrow/CoronaSequence_x64mod/blob/master/imagesequence.cpp#L446

[kedautinh12]

Latest ver
https://github.com/TomArrow/CoronaSequence_x64mod/releases

[TomArrow]

It seems Tom is using the Avisynth+ header but with AvisynthPluginInit2: https://github.com/TomArrow/CoronaSequence_x64mod/blob/master/imagesequence.cpp#L446

Yeah I think I use the modern SDK.

Is this wrong? Either way I think this CUDA/whatever problem is not intended behavior so a fix would probably be nice to have.

I guess it's possible that the problem is in some of the plugin code elsewhere, like accidentally overwriting some property due to overflow or bad pointer handling, but I wouldn't even know where to start looking since I don't understand the feature. I'm also not the original author of the plugin, I just made changes.

[Reel.Deel]

Yeah I think I use the modern SDK.

Is this wrong?

Probably best to use AvisynthPluginInit3 when using AviSynth 2.6/AviSynth+ headers.

See here: https://github.com/pinterf/TNLMeans/commit/d0fb74ae8d8ef71100b52fb3131556f25441502a

[kedautinh12]

Avisynth 3.7.3 test 2
Avisynth+ 3.7.3 test 2 (20221114) (https://drive.google.com/uc?export=download&id=1fCPbb4n1-nuR_mAaLG_4o1Zxfciwr2A4)

20221114 3.7.3 WIP
------------------
- Fix (#304): ColorYUV analyze=true was displaying wrong min-max values for YUY2
- Fix: C API undefined behavior when upstream throw runtime error
- Mute compilation warnings in avisynth.h
- CMakeLists.txt: fix clang-cl/intel with ninja generator
- Fix (#293): "Text" to throw proper error message if the specified font name (e.g. Arial) is not found among internal bitmap fonts.
- Fix (#293): "Subtitle" and "Text" filter to respect the explicitely given coorditanes for y=-1 or x=-1,
instead of applying vertical/horizontal center alignment.
- Fix: C interface crash when using avs_new_video_frame_p(_a)
- Fix (#283): broken runtime functions min/max/minmaxdifference when threshold is not 0 (returned -1). Regression in 3.7.2
- New: add a sixth array element to PlaneMinMaxStats: average. Defines variable "PlaneStats_average" as well if setting variables is required.
- Fix (#282): ConvertToRGB
- do check for exact 8 or 16 bit input, because packed RGB formats exist only for 8 and 16 bits
- keep alpha for RGBA planar - convert RGBAP8/16 to RGB32/64, while RGBP8/16 is still RGB24/48

Clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[gispos]

Since Avisynth 3.7.3 or the extra builds from GS (https://gitlab.com/uvz/AviSynthPlus-Builds) I get error messages every now and then that are not present in Avisynth 3.7.2

Either no clip can be created (without error message) or the error message 'Function not found' appears (v3.7.3).
And in both cases: If the same script is loaded again, no error occurs.

If I go back to 3.7.2 everything is fine again.

I load some dll's and scripts via an avsi, has anything changed in the plugin loading order?

[ryrynz]

Yeah I decided to test the test build as well and just got nothing out the other end, I don't think test builds should be that broken :D
Basically an alpha, so I wasn't concerned and just went back to 3.7.2 as well, figuring something so broken would be identified soon enough.
Clang build wasn't any better either.

[gispos]

...so I wasn't concerned and just went back to 3.7.2 as well, figuring something so broken would be identified soon enough.
Clang build wasn't any better either.
If no one reports it, it cannot be identified.
I would like to provide more detailed information, but it is completely random and also not so often.

[VoodooFX]

Report: I still had no issues with Avisynth+ 3.7.3 test 2 (20221114) (https://drive.google.com/uc?export=download&id=1fCPbb4n1-nuR_mAaLG_4o1Zxfciwr2A4)

[poisondeathray]

Report: I still had no issues with Avisynth+ 3.7.3 test 2 (20221114) (https://drive.google.com/uc?export=download&id=1fCPbb4n1-nuR_mAaLG_4o1Zxfciwr2A4)

No problems either;

For the people having issues, post your script(s) maybe some clues there

[gispos]

Since I changed my avsi file to load my filters and dll's, there have been no problems with Avisynth 3.73 so far.

Before everything was listed randomly, now I load all dll's first and only then the scripts.

Something must have changed because 3.72 had no problems with the mixed loading order.

As long as it works now all is good. :)

[pinterf]

Happy New Year!

Let's start the year with some cosmetic and other changes and fixes in "Text" filter:
Avisynth+ 3.7.3 test 3 (20230118) (https://drive.google.com/uc?export=download&id=1FEww_BfRMY63D2NCg4h860ofxqfflRhu)

- Fix: "Text" filter negative x or y coordinates (e.g. 0 instead of -1)
- Fix: "Text" filter would omit last character when x<0
- Fix: "Text" halo_color needs only MSB=$FF and not the exact $FF000000 constant for fade
- "Text" ``halo_color`` allows to have both halo and shaded background
- "Text" much nicer rendering of subsampled formats

[FranceBB]

Happy New Year to you too, Master Ferenc!
Thanks for the new build! I'll definitely test! :D

[Reel.Deel]

Also, 32-bit AviSynth+ now supports non-decorated export names in C-plugins. This is something that was missing since the beginning of avs+.

By the way, this is how the Text filter on YUV420 looks like now, and how it used to look.

New
https://i.ibb.co/Z1sS3cP/text-new.png

Old
https://i.ibb.co/bPWq0Mz/text-old.png

[Emulgator]

Ah, welcome back, Ferenc !
(Was trying uvx 3825 and both 32 and 64 bit failed instantly...)

[StainlessS]

Welcome home P, and Happy New Year to U 2.

[Dogway]

Where is the Text filter in wiki?
I get error trying to use "Arial" as the font.
SimpleText: internal font name Arial in size 18 not found.

[Reel.Deel]

Where is the Text filter in wiki?
I get error trying to use "Arial" as the font.

It's not documented in the wiki. That is why there's a note at the top of the page with the link to the readthedocs documentation which is up-to-date. See here: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/subtitle.html#text

Text, is meant for bdf fonts (https://en.wikipedia.org/wiki/Glyph_Bitmap_Distribution_Format). It comes with "Terminus" (available in different sizes) and "Info.h" that is a fixed dimension.

---

PS, if someone wants to update the wiki, go for it. Updating the actual avs docs was a large task, and I don't feel like doing double work :).

[kedautinh12]

Happy New Year!

Let's start the year with some cosmetic and other changes and fixes in "Text" filter:
Avisynth+ 3.7.3 test 3 (20230118) (https://drive.google.com/uc?export=download&id=1FEww_BfRMY63D2NCg4h860ofxqfflRhu)

- Fix: "Text" filter negative x or y coordinates (e.g. 0 instead of -1)
- Fix: "Text" filter would omit last character when x<0
- Fix: "Text" halo_color needs only MSB=$FF and not the exact $FF000000 constant for fade
- "Text" ``halo_color`` allows to have both halo and shaded background
- "Text" much nicer rendering of subsampled formats

Some new 32-bit plugin don't support XP anymore. So next update can you add x86 for win 7 and up beside x86-xp??

[pinterf]

Some new 32-bit plugin don't support XP anymore. So next update can you add x86 for win 7 and up beside x86-xp??
My test versions with _xp can be run on xp _and_ on any newer OSes.
Where there is no xp in the folder name then it surely fails on XP.
Why are you asking? Did you test the 32 bit version on a Non-XP machine and something was not working for you?

[kedautinh12]

My test versions with _xp can be run on xp _and_ on any newer OSes.
Where there is no xp in the folder name then it surely fails on XP.
Why are you asking? Did you test the 32 bit version on a Non-XP machine and something was not working for you?

it's work like a charm on new os but some avs+ plugins don't support with XP avisynth ver. When I use with 32 bit Asd-g's clang-build don't have that errors. I think it's relate XP-32 bit ver support old OS. I'm using win 11
Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/auto_gamma.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/circle_warp.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/linear_gamma.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/luma_smooth.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/rgb_dither.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/saturation_percentiles.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/white_point.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

[Reel.Deel]

Didn't you already hijack another issue with the same problem: https://github.com/AviSynth/AviSynthPlus/issues/282#issuecomment-1140287429 ?

[FranceBB]

Some new 32-bit plugin don't support XP anymore. So next update can you add x86 for win 7 and up beside x86-xp??

Uh? Why?
Windows XP builds will run on Vista, 7, 8, 8.1, 10 x86 just fine.
The only difference is that it's compiled with v141_xp instead of v143 and with /Zc:threadSafeInit enabled.
Same thing for x64 XP.

This won't really make a difference in terms of performances as it targets SSE2 for the C part like other builds but Avisynth has intrinsics/asm inside beyond that which are gonna be used anyway.

TL;DR there's no need for additional builds.

[FranceBB]

Actually, Ferenc, 3.7.3 Beta 3 XP x86 won't work as it probably hasn't been compiled with v141_xp.
There are two missing functions in the Kernel: GetLocaleInfoEx and GetFileInformationByHandleEx

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

[kedautinh12]

Didn't you already hijack another issue with the same problem: https://github.com/AviSynth/AviSynthPlus/issues/282#issuecomment-1140287429 ?

Yes it's me and error still continue to present. I think it's relate x32-XP build so i think need add x32 for win 7 and above beside XP build

[kedautinh12]

Uh? Why?
Windows XP builds will run on Vista, 7, 8, 8.1, 10 x86 just fine.
The only difference is that it's compiled with v141_xp instead of v143 and with /Zc:threadSafeInit enabled.
Same thing for x64 XP.

This won't really make a difference in terms of performances as it targets SSE2 for the C part like other builds but Avisynth has intrinsics/asm inside beyond that which are gonna be used anyway.

TL;DR there's no need for additional builds.

You can check this build with crabshank_filters
https://drive.google.com/file/d/1hd-MGoHJFWN6sCwldqF45PUJ0oUzCiIA/view?usp=share_link

Dependencies
https://github.com/lucasg/Dependencies/releases

[FranceBB]

I get your point: third party plugins are sometimes compiled targeting non xp so incompatible builds and newer C++ Redistributables that don't work on XP, but I was talking about the core here, those plugins are not part of the core, are they?

[pinterf]

Actually, Ferenc, 3.7.3 Beta 3 XP x86 won't work as it probably hasn't been compiled with v141_xp.
There are two missing functions in the Kernel: GetLocaleInfoEx and GetFileInformationByHandleEx

Arrrgh, sorry for that, probably I set v141_xp but did not set the Support XP checkbox option for CMake? Anyway, there will be a new build after I finish another thing and I'm gonna double check the options then.

[kedautinh12]

Arrrgh, sorry for that, probably I set v141_xp but did not set the Support XP checkbox option for CMake? Anyway, there will be a new build after I finish another thing and I'm gonna double check the options then.

New ver had x86 for win 7 and above beside x86_xp :D

[FranceBB]

there will be a new build after I finish another thing and I'm gonna double check the options then.

Ok, perfect. Thanks! :)

[Hat3L0v3]

Can somebody help me to figure out why depan filter crashing my Avs(AvsPmod)?
I want to use DePanStabilize from mvtools pack but it crashes.
system and others:
win10 x64
avs+ 3.7.3 r3825 x86-64
AvsPmod_v2.7.3.2_.Windows_x86-64
mvtools-2.7.45 (.dll`s x64)
vcredist last time installed from here (https://github.com/abbodi1406/vcredist) (v0.64.0) (can't remember what versions I had before)

(libfftw3f-3.dll and libfftw3l-3.dll) from FFTW - 3.3.10 and 3.3.5 (Tried both) in 2 variation:
a) x64.dll into SysWoW64 folder (x32.dll on System32)
b) x64.dll into System32 folder (x32.dll on SysWoW64)
(First I read that x32 must be in System32 and x64 in SysWoW64 , then find that If you're using 64 bit AviSynth - put x64 FFTW3.DLL into System32). So b) variant must be correct one.

I remember before updating avs+ from 3.7.2 to r3825 I tried different stabilizers and depan was causing "access violation" error (same as TemporalDegrain2 with postFFT=2 option). Now they both just crashing without errors.
Sorry if I typed in wrong thread.

[kedautinh12]

Fftw3.3.10 here:
https://forum.doom9.org/showthread.php?p=1955609#post1955609

And yes, in windows64 86bit.dll must be in sysWow64, 64bit.dll must be in system32

[Hat3L0v3]

Fftw3.3.10 here:
https://forum.doom9.org/showthread.php?p=1955609#post1955609

And yes, in windows64 86bit.dll must be in sysWow64, 64bit.dll must be in system32

yeah, I using it right from there

[Selur]

I'm using Avisynth+ 3.7.2. (r3661, 3.7, x86_64).
with:
bool avsViewer::setRessource()
{
try {
QByteArray ba = m_currentInput.toLocal8Bit();
const char *infile = ba.data();
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
AVSValue tmp[1];
tmp[0] = &arg;
AVS_linkage = m_env->GetAVSLinkage();
m_res = m_env->Invoke("Import", tmp);
if (!m_res.IsClip()) {
std::cerr << "Couldn't load input, not a clip!" << std::endl;
return false;
}
if (!m_res.Defined()) {
QString error = QObject::tr("Couldn't import:") + " " + m_currentInput;
error += "\r\n";
error += QObject::tr("Script seems not to be a valid avisynth script.");
std::cerr << qPrintable(error) << std::endl;
return false;
}
return true;
} catch (AvisynthError err) { //catch AvisynthErrors
std::cerr << "-> " << err.msg << std::endl;
} catch( const std::exception & ex ) {
std::cout << ex.what() << std::endl;
}catch (...) { //catch everything else
std::cerr << "-> setRessource: Unknown error" << std::endl;
}
return false;
}

I get an exception in the 'm_res = m_env->Invoke("Import", tmp);' line.
NPGetCaps 2
WNNC_NET_TYPE
NPGetCaps 4
WNNC_USER
NPGetCaps 6
WNC_CONNECTION
NPGetCaps 13
default
NPGetCaps 11
WNNC_ENUMERATION
NPGetCaps 9
WNNC_ADMIN
NPGetCaps 8
WNNC_DIALOG
NPOpenEnum: dwScope 0x00000001, dwType 0x00000001, dwUsage 0x00000000, lpNetResource 0000000000000000
NPOpenEnum: pCtx 00000170DA821F30
onecore\vm\dv\storage\plan9\rdr\dll\util.cpp(99)\p9np.dll!00007FF9D4F4F0CC: (caller: 00007FF9D4F493B0) LogHr(1) tid(1dcc) C0000034 Msg:[瑎牃慥整楆敬☨敤楶散‬奓䍎剈乏婉ⱅ☠瑡牴扩瑵獥‬椦卯慴畴ⱳ渠汵灬牴‬䥆䕌䅟呔䥒啂䕔也剏䅍ⱌ⠠䥆䕌卟䅈䕒剟䅅⁄⁼䥆䕌卟䅈䕒坟䥒䕔簠䘠䱉彅䡓剁彅䕄䕌䕔Ⱙ䘠䱉彅偏久‬䥆䕌卟乙䡃佒低单䥟彏低䅎䕌呒‬畮汬瑰Ⱳ〠)]
NPEnumResource: hEnum 00000170DA821F30, lpcCount 0000004E5B94F090, lpBuffer 00000170DA829070, lpBufferSize 0000004E5B94F100.
NPEnumResource: *lpcCount 0xfffffffe, *lpBufferSize 0x3f6e, pCtx->index 0
NPEnumResource DokanGetMountPointList failed
NPCloseEnum: hEnum 00000170DA821F30
NPCloseEnum: returns
onecore\com\combase\dcomrem\security.cxx(2999)\combase.dll!00007FFA0B49505E: (caller: 00007FF9B064F80A) ReturnHr(1) tid(98c) 80010117 Auf den Aufrufkontext kann nicht zugegriffen werden, nachdem der Aufruf beendet ist.
NPGetCaps 11
WNNC_ENUMERATION
NPOpenEnum: dwScope 0x00000002, dwType 0x00000000, dwUsage 0x00000000, lpNetResource 0000000000000000
NPOpenEnum: pCtx 00000170DA8CF200
NPEnumResource: hEnum 00000170DA8CF200, lpcCount 0000004E2258EED8, lpBuffer 00000170DA8D8A20, lpBufferSize 0000004E2258EED4.
NPEnumResource: *lpcCount 0xffffffff, *lpBufferSize 0x4000, pCtx->index 0
NPEnumResource DokanGetMountPointList failed
NPCloseEnum: hEnum 00000170DA8CF200
NPCloseEnum: returns
onecore\com\combase\dcomrem\security.cxx(2999)\combase.dll!00007FFA0B49505E: (caller: 00007FF9B064F80A) ReturnHr(2) tid(98c) 80010117 Auf den Aufrufkontext kann nicht zugegriffen werden, nachdem der Aufruf beendet ist.

Exception at 0x7ffa08df06bc, code: 0xe06d7363: C++ exception, flags=0x81 (first chance) in AviSynth!avs_is_rgb48
Any idea what is going wrong here?

Cu Selur

[wonkey_monkey]

Does it work if you do

m_res = m_env->Invoke("Import", arg);

?

I was under the impression that when passing an array of AVSValues to Invoke, you're supposed to wrap them in another AVSValue with the array size:

m_res = m_env->Invoke("Import", AVSValue(tmp, 1));

[Selur]

I tried:
QByteArray ba = m_currentInput.toLocal8Bit();
const char *infile = ba.data();
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
AVSValue tmp[1];
tmp[0] = &arg;
AVS_linkage = m_env->GetAVSLinkage();
m_res = m_env->Invoke("Import", AVSValue(tmp,1));
and

QByteArray ba = m_currentInput.toLocal8Bit();
const char *infile = ba.data();
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
AVSValue tmp[1];
tmp[0] = &arg;
AVS_linkage = m_env->GetAVSLinkage();
m_res = m_env->Invoke("Import", arg);
and
QByteArray ba = m_currentInput.toLocal8Bit();
const char *infile = ba.data();
std::cout << "Importing " << infile << std::endl;
AVSValue arg(infile);
AVSValue tmp[1];
tmp[0] = &arg;
AVS_linkage = m_env->GetAVSLinkage();
m_res = m_env->Invoke("Import", AVSValue(arg, 1));

They all fail, with the above exception.

[Selur]

QByteArray ba = m_currentInput.toLocal8Bit();
const char *infile = ba.data();
std::cout << "Importing " << infile << std::endl;
AVS_linkage = m_env->GetAVSLinkage();
AVSValue filename = infile;
AVSValue args = AVSValue(&filename, 1);
m_res = m_env->Invoke("Import", args, 0);
seems to work.

Thanks!

Cu Selur

[kedautinh12]

Avs+ r3849 clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

it's work like a charm on new os but some avs+ plugins don't support with XP avisynth ver. When I use with 32 bit Asd-g's clang-build don't have that errors. I think it's relate XP-32 bit ver support old OS. I'm using win 11
Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/auto_gamma.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/circle_warp.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/linear_gamma.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/luma_smooth.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/rgb_dither.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/saturation_percentiles.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

Cannot load file 'C:/Program Files (x86)/AviSynth+/plugins+/white_point.dll'. Platform returned code 127:
The specified procedure could not be found.
Note: You may need a newer OS version in order to use this plugin

It's work with new ver of filters
https://gitlab.com/uvz/AviSynthPlus-Plugins-Scripts/-/tree/3ee91cada7a1e78baad73a3e4adc1271ab9e77ee/crabshank_filters/x86

[kedautinh12]

AviSynthPlus r3877 clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[ryrynz]

Gave that clang build a shot & Test build 3 and both just freeze when I change to one of my avisynth scripts., so no change from build 2.
Maybe a filter isn't up to date or something, I'll report back when I look into it.

[kedautinh12]

You need report here:
https://github.com/AviSynth/AviSynthPlus/issues

[Emulgator]

I had no luck with uvz builds either.

[kedautinh12]

You can report uvz's build issues here:
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[Fjord]

It would be handy to be able to specify multiple arguments to the propDelete() function, to get rid of several properties in one call.
propDelete(clip, "MyProp1", "MyProp2", "MyProp3")

An inverse of that could be a new function "propKeep()" that would delete any properties not named as arguments to the function.
propKeep(clip, "MyKeep1", "MyKeep2", "MyKeep3")
This would be handy for filtering properties to a fixed set, rather than clearing all, and restoring only the ones that are wanted.

What do you think?

EDIT: I see in the change log from 3.7.1 to 3.7.2 (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist372.html) that:

PropCopy: new string parameter "props": list of property names to copy (or ignore)
PropCopy: new bool parameter "exclude": whether property list is positive (copy) or negative (do not copy; blacklist)
PropDelete: accept an array string parameter as list of property names to remove

and a bit more detailed in the github readme_history.txt (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt):
- propCopy: able to specify that the property list is negative.
bool "exclude" = false # default: "props" is positive list

propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=false) # merge only two properties
propCopy(org,true,props=["_Matrix", "_ColorRange"], exclude=true) # merge all, except listed ones
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected
propCopy(org,props=["_Matrix", "_ColorRange"], exclude = true) # erase all, then copy all, except listed ones
...
- PropDelete: accept a non-empty array string as list of property names to remove
Parameter is not optional, and has no name. It can be either a string (as before) or an array of strings
propDelete("_Matrix") # old syntax, still accepted
propDelete(["_Matrix", "_ColorRange"])
- PropCopy: new string parameter "props" as list of property names to remove
"props": a non-empty array of strings

old syntax, still accepted:
propCopy(org,true) # merge from all org's properties
propCopy(org,false) # erase all then copy all org's properties (exact copy)
new syntax
propCopy(org,true,props=["_Matrix", "_ColorRange"]) # merge
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected

which means my request is already implemented (in another way), although this hasn't yet made it to the wiki regarding propCopy (http://avisynth.nl/index.php/Internal_functions#propCopy) (which is current for 3.7.1).

[Reel.Deel]

although this hasn't yet made it to the wiki regarding propCopy (http://avisynth.nl/index.php/Internal_functions#propCopy) (which is current for 3.7.1).

Wiki probably will not be updated (at least by me or pinterf) but there will be a link to the corresponding readthedocs page when ever it becomes available. I have 50% of the syntax pages done and includes up-to-date docs.

https://i.ibb.co/XpVtRGk/avs-propcopy.png

[Fjord]

... but there will be a link to the corresponding readthedocs page when ever it becomes available. I have 50% of the syntax pages done and includes up-to-date docs.

Thanks Reel.Deel. Your revisions and editing of readthedocs are terrific and is greatly appreciated.

[Fjord]

@Reel.Deel, does Sphinx have a "history" or "recent changes" function, to show what the latest updates are to readthedocs?

I cannot find your above update of the propCopy documentation in readthedocs (https://avisynthplus.readthedocs.io/en/latest/index.html). Where should I be looking? Or is this an offline change, yet to be merged into the online version?

[Reel.Deel]

It's on my hard drive :p ... The readthedocs automatically updates anytime there are changes so if you don't see a particular page there, it's yet to be finished. Hopefully I'll finish it in the coming week or so.

[kedautinh12]

AviSynthPlus r3912 clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[jpsdr]

This r3912 version broke high bit format, the following script: SetMemoryMax(192)
AviSource("Dark_Crystal_HDR_16b.avi")
ConverttoYUV444()
doesn't work anymore :(, my avi file is utvideo yuv422p10le.

The AvisynthPlus_3.7.3_20230118_test3 is working.

[kedautinh12]

This r3912 version broke high bit format, the following script: SetMemoryMax(192)
AviSource("Dark_Crystal_HDR_16b.avi")
ConverttoYUV444()
doesn't work anymore :(, my avi file is utvideo yuv422p10le.

The AvisynthPlus_3.7.3_20230118_test3 is working.

You can create issue here:
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[Reel.Deel]

This r3912 version broke high bit format, the following script: SetMemoryMax(192)
AviSource("Dark_Crystal_HDR_16b.avi")
ConverttoYUV444()
doesn't work anymore :(, my avi file is utvideo yuv422p10le.

The AvisynthPlus_3.7.3_20230118_test3 is working.

In what way did it break? What is the error message?

Just 3 hours ago pinterf merged this PR: https://github.com/AviSynth/AviSynthPlus/pull/332

All of that has been a work-in-progress in the last few weeks. There has not been any user related changes added ever since pinterf's test release (aside from "Text"). All has been internal API stuff and documentation.

I guess wait for a new release that includes the changes from today. If the problem still continues then open up an issue on Github.

[Fjord]

I was having difficulty with array arguments to a user function I was working on. So I tried the demo script showing an example use of array arguments in a user function. No wonder I was having issues - the demo script throws an error on the example for array arguments! (I am running v3.7.3 test3 r3835 in latest AvsPMod).

The demo script comes from the 9 feb 2023 readme_history.txt, lines 1841-1886, at
https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt
The same demo script is used in the 4th Example section in readthedocs page on Arrays:
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/script_ref/script_ref_arrays.html

The error message (in AvsPMod) is:
Script error: Invalid arguments to function 'FirstNSum'
(C:\Users\...\...\test Array examples.avs, line 25)

The error is fixed by putting quotes on the argument names in the function definition, and using the parameter names in the function call.

In my own code, I experienced weird errors when trying array arguments to a user function for the first time -- they were named arguments, but I omitted the names= in the function call. It took quite a while to debug -- which was just to use all argument names in the function call, which included an array argument.

If this is not a bug, then the requirement to always use argument names when calling functions with array arguments needs to be highlighted in the Array documentation.

Here is the demo script from readme_history.txt, with comments showing the necessary corrections on two lines - call to FirstNSum() function, and the function definition.

ColorBars()
clip=last
a = [[1,2],[3,4]]
aa = [1]
b = a[1,1] + ArrayGet(a, 1,0) + aa[0]

empty_array = []
empty_array_2 = empty_array
#n3 = empty_array_2.ArrayGet(0) # array index out out range error!

black_yuv_16 = [0,32768,32768]
grey_yuv_16 = [32768,32768,32768]
white_yuv_16 = [65535,32768,32768]
aSelectColors = [\
["black", black_yuv_16],\
["grey", grey_yuv_16],\
["white",white_yuv_16],\
["empty",empty_array]\
]
test_array = [99, 1.0, "this is a string"] # mixed types
test_array2 = [199, 2.0, "This is a string"]

n = ArraySize(test_array) # 3
n2 = ArraySize(empty_array_2) # 0
sum = FirstNSum(grey_yuv_16,2) # --> sum = FirstNSum(x=grey_yuv_16,n=2)
b = b

clip = clip.Text(e"Array size = " + String(n) +\
e"\n Empty array size = " + String(n2) +\
e"\n sum = " + String(sum) +\
e"\n b = " + String(b) +\
e"\n white_yuv_16[1]=" + String(aSelectColors["white"][1]) + \
e"\n [0]=" + String(ArrayGet(test_array,0)) + \
e"\n [1]=" + String(ArrayGet(test_array,1)) + \
e"\n [2]=" + ArrayGet(test_array,2), lsp=0, bold=true, font="info_h")

return clip

function FirstNSum(array x, int n) { # --> function FirstNSum(array "x", int "n") {
a = 0
for (i=0, x.ArraySize()-1) {
a = a + x[i]
}
return a
}

[jpsdr]

In what way did it break?

I can't open the avs file in Virtualdub2 anymore.

What is the error message?

Unknow or unsupported video format.

[pinterf]

Without being able to test jpsdr's issue:
Test build 4:
Avisynth+ 3.7.3 test 4 (20230216) (https://drive.google.com/uc?export=download&id=1sBZfhWjE-27HQ20Ok7Uhtk8HSRyyGt5y)

[FranceBB]

Just like Test3, Test4 also doesn't work on Windows XP x86 due to 2 missing functions in the kernel: GetLocaleInfoEx and GetFileInformationByHandleEx

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

[pinterf]

Just like Test3, Test4 also doesn't work on Windows XP x86 due to 2 missing functions in the kernel: GetLocaleInfoEx and GetFileInformationByHandleEx

I have double checked the option now. I don't know what happens.

[pinterf]

Test2 is still running fine for you?

[pinterf]

Test2 is still running fine for you?
Answering to myself :)
No. Test2 should not work either. Contains
493 (0x000001ed), GetFileInformationByHandleEx, C:\WINDOWS\SysWOW64\kernel32.dll
instead of
492 (0x000001ec), GetFileInformationByHandle, C:\WINDOWS\SysWOW64\kernel32.dll

[FranceBB]

I have double checked the option now. I don't know what happens.

Uhmmm weird.

Test2 is still running fine for you?

Actually no, I originally skipped Test2 'cause I forgot back then, but I downloaded it now and it has the same two missing functions.


No. Test2 should not work either.

Correct. I just tested it and it doesn't work.

Just to recap, if I remember correctly XP support is given by:

- Setting v141_xp
- Using /Z:threadsafeinit
- Ticking the "Support XP" checkbox in CMake

Were all those done?
I remember we had a very similar issue when you merged part of Avisynth Neo into Avisynth+ but was later solved.

[pinterf]

Great. Uninstalled v141_xp support from Visual Studio 2022. Then reinstalled.
Now the generated DLL seems good, at least I can see GetFileInformationByHandle and no GetFileInformationByHandleEx.
I'm gonna arrange another build soon.

[FranceBB]

Gotcha. Thanks! :)
I look forward to it.

[pinterf]

Here you are. XP forever (or not). :)
For our young members: https://en.wikipedia.org/wiki/Windows_XP

Avisynth+ 3.7.3 test 5 (20230217) (https://drive.google.com/uc?export=download&id=1WoLyY55YqfvB3PPP-pIs0GuDlbN6-zBm)

All-in-one changes since 3.7.2

20230216 3.7.3 WIP
------------------
- Bump AviSynth interface version to 10.0
- Add avs_video_frame_get_pixel_type and avs_video_frame_amend_pixel_type to C interface as well
- Fix (#327) Histogram "color2" markers. Fix right shifted 15 degree dots, fix square for bits>8
- Feature (#317): (V10 interface) The color format of a VideoFrame can now be retrieved with its GetPixelType()
function. Before, there was no reliable way of knowing it on a frame from propGetFrame().
The internally stored pixel_type in VideoFrame is properly converted upon a Subframe (Y8-32), SubframePlanar (strip alpha).
- Feature (#317): (V10 interface) added ``VideoFrame::AmendPixelType`` and ``avs_video_frame_amend_pixel_type``.
Introduced in order to keep VideoInfo and VideoFrame pixel_type synchronized for special cases:
when filter constructor would just change ``VideoInfo::pixel_type``, but the frame would be passed w/o any change, like in ``ConvertFromDoubleWidth`` or ``CombinePlanes``.
- Feature (#314): Added AVSValue::GetType()
Returns an AvsValueType enum directly, one can use it instead of calling all IsXXX functions to establish the type. (Rust use case)
- "Text" new parameter: "placement" for chroma location hint
- Used in subsampled YUV formats, otherwise ignored.
- Valid values for "placement" are the same as in ChromaInPlacement and
ChromaOutPlacement in the Convert functions.
- Meaningful values: "center", "left", "auto" at the moment
- Default value is
- read from "_ChromaLocation" frame property, otherwise "left"
- override or set from "placement" parameter if parameter is other than "auto"
- if "auto" + have frame property -> use frame property
- if "auto" + no frame property -> use "left"
- no frame property and no parameter -> use "left"
- Only "center" and "left" is implemented. (center is known as jpeg or mpeg1, left is known as mpeg2)
If "center" is given directly or read from frame property, it will be used.
Otherwise "Text" renders chroma as "left" (mpeg2)
- Enhancement (#314): Gave all enums of public C++ API a name, and added DEFAULT_PLANE to AvsPlane (also in C API).
- Fix (#314): Changed NewVideoFrameP() property source argument to const in accordance with copyFrameProps(), since it's not meant to be written
Fixed in C interface as well: avs_new_video_frame_p and avs_new_video_frame_p_a: prop_src argument now const (no change in use)
- Enhancement (#314): Made VideoFrameBuffer destructor public like in other classes of the public API to prevent compiler errors downstream when calling non-const member functions
- "Text": Almost fully rewritten.
(#310) Support any width of bdf fonts (but still of fixed width)
Render in YUY2 is as nice as in YV16
Halo is not limited to original character matrix boundaries
Halo is not character based, but rendered on the displayed string as a whole.
Some speed enhancements, mainly for subsampled formats and outlined (with halo) styles
- Enhancement (#315): Show exception message as well if a v2.6-style plugin throws AvisynthError in its
AvisynthPluginInit3() instead of only "'xy.dll' cannot be used as a plugin for AviSynth."
- "Text": draw rightmost on-screen character even if only partially visible (was: not drawn at all)
- "Text": support more from the BDF standard (issue #310): per-character boundary boxes and shifts
- "Text" (#310): support 17-32 pixel wide external BDF fonts (issue #310)
- Fix: "Text" filter negative x or y coordinates (e.g. 0 instead of -1)
- Fix: "Text" filter would omit last character when x<0
- Fix: "Text" halo_color needs only MSB=$FF and not the exact $FF000000 constant for fade
- "Text" ``halo_color`` allows to have both halo and shaded background when halo_color MSB=$FE
- "Text" much nicer rendering of subsampled formats (#308)
- Address Issue #305: Support for non-decorated avisynth_c_plugin_init in 32 bit C-plugins
- Huge documentation update by Real-Deal
- Fix (#304): ColorYUV analyze=true was displaying wrong min-max values for YUY2
- Fix: C API undefined behavior when upstream throw runtime error
- Mute compilation warnings in avisynth.h
- CMakeLists.txt: fix clang-cl/intel with ninja generator
- Fix (#293): "Text" to throw proper error message if the specified font name (e.g. Arial) is not found among internal bitmap fonts.
- Fix (#293): "Subtitle" and "Text" filter to respect the explicitely given coorditanes for y=-1 or x=-1,
instead of applying vertical/horizontal center alignment.
- CMakeLists.txt: add support for Intel C++ Compiler 2022
- Fix: C interface avs_prop_get_data behave like C++ counterpart. Interim version for this fix is 9.2
- Fix: C interface crash when using avs_new_video_frame_p(_a)
- Fix (#283): broken runtime functions min/max/minmaxdifference when threshold is not 0 (returned -1). Regression in 3.7.2
- New: add a sixth array element to PlaneMinMaxStats: average. Defines variable "PlaneStats_average" as well if setting variables is required.
- Fix (#282): ConvertToRGB
- do check for exact 8 or 16 bit input, because packed RGB formats exist only for 8 and 16 bits
- keep alpha for RGBA planar - convert RGBAP8/16 to RGB32/64, while RGBP8/16 is still RGB24/48

[FranceBB]

Works like a charm! :D

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

XP forever (or not). :)


You know, we do actually have a group on Skype called "Windows XP Forever" with lots of members from the community which is still alive and kicking ;)

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

Anyway, so far so good, thanks Ferenc, as always! ;)

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

[kedautinh12]

"Windows XP Forever" will make XP ver still update beside newer windows??

[FranceBB]

"Windows XP Forever" will make XP ver still update beside newer windows??

Yes, it's "forever" right in the name LMAO
Jokes aside, by the way, you should know that Avisynth 2.6.1 released in 2016 was still Windows98SE compatible, never mind XP hahahahaha

[ryrynz]

All-in-one changes since 3.7.2


Still crashing for me, narrowed down things as much as I think I can do.

ffdshow added as an external filter in media player - Avisynth box ticked in ffdshow, blank code in the code box (no filters loaded at all), YV12 ticked in ffdshow as input colorspace, that's it.

Windows 11 22H2, i5 10400F 16GB.

[poisondeathray]

20230216 3.7.3 WIP
------------------
- Huge documentation update by Real-Deal


Should be "Reel.Deel" ?

[Reel.Deel]

Should be "Reel.Deel" ?

Either one works. On GitHub and the AviSynth wiki my handle is with an A. Edit: I guess if I want to be picky, reel is always with 2 Es :D

----

This r3912 version broke high bit format, the following script: SetMemoryMax(192)
AviSource("Dark_Crystal_HDR_16b.avi")
ConverttoYUV444()
doesn't work anymore :(, my avi file is utvideo yuv422p10le.

The AvisynthPlus_3.7.3_20230118_test3 is working.

I can't open the avs file in Virtualdub2 anymore.

Unknow or unsupported video format.


Not exactly the same as yours but no error message with the script below with 3.7.3 test 5 (r3931).

SetMemoryMax(192)
ColorBars(1920, 1080, pixel_type="YUV420P10")
ConverttoYUV444()

[jpsdr]

The issue is not with the convert but with the AVISource.
My bad, i should have been more explicit.
I have to redo the test with test5 now.

[pinterf]

Still crashing for me, narrowed down things as much as I think I can do.

ffdshow added as an external filter in media player - Avisynth box ticked in ffdshow, blank code in the code box (no filters loaded at all), YV12 ticked in ffdshow as input colorspace, that's it.

Windows 11 22H2, i5 10400F 16GB.
Yes. For some reason test1 is OK, test2 is not.

[pinterf]

Yes. For some reason test1 is OK, test2 is not.
Fixed, test6 is coming soon.

[pinterf]

Avisynth+ 3.7.3 test 6 (20230218) (https://drive.google.com/uc?export=download&id=1MwIRCk65Gtto7qdWjaD1zlc47G0gRACD)
Changes since yesterday's test5: ffdshow fix, new resizers and parameterized chroma resampler option in ConvertToXXXX filters

20230218 3.7.3 WIP
------------------
- (#337) Add more resizers types by jpsdr's and DTL's idea: backport from https://github.com/jpsdr/ResampleMT

SinPowerResize "cii[src_left]f[src_top]f[src_width]f[src_height]f[p]f"
parameters like GaussResize: optional "p"
Default: p=2.5

SincLin2Resize "cii[src_left]f[src_top]f[src_width]f[src_height]f[taps]i"
parameters like SincFilter or LanczosFilter: optional "taps"
Default taps=15

UserDefined2Resize "cii[b]f[c]f[src_left]f[src_top]f[src_width]f[src_height]f"
parameters like BicubicResize: Optional "b" and "c"
Default b=121.0, c=19.0

and their equivalent for the ConvertToXXXX family:
"sinpow", "sinclin2" and "userdefined2"

- Add "param1" and "param2" to ConvertToXXXX where "chromaresample" parameter exists.
Now it is possible to use chromaresample with nondefault settings.

param1 will set 'taps', 'b', or 'p', while param2 sets 'c' parameter for resizers where applicable.

b,c: bicubic (1/3.0, 1/3.0), userdefined2 (121.0, 19.0)
taps: lanczos (3), blackman (4), sinc (4), sinclin2 (15)
p: gauss (30.0), sinpow (2.5)
'param1' and 'param2' are always float. For 'taps' 'param1' is truncated to integer internally.
When a resizer does not use parameters they are simply ignored.
- Add avs_video_frame_get_pixel_type and avs_video_frame_amend_pixel_type to C interface as well
- Fix (#327) Histogram "color2" markers. Fix right shifted 15 degree dots, fix square for bits>8
- Feature (#317): (V10 interface) The color format of a VideoFrame can now be retrieved with its GetPixelType()
function. Before, there was no reliable way of knowing it on a frame from propGetFrame().
The internally stored pixel_type in VideoFrame is properly converted upon a Subframe (Y8-32), SubframePlanar (strip alpha).
- Feature (#317): (V10 interface) added ``VideoFrame::AmendPixelType`` and ``avs_video_frame_amend_pixel_type``.
Introduced in order to keep VideoInfo and VideoFrame pixel_type synchronized for special cases:
when filter constructor would just change ``VideoInfo::pixel_type``, but the frame would be passed w/o any change, like in ``ConvertFromDoubleWidth`` or ``CombinePlanes``.
- Feature (#314): Added AVSValue::GetType()
Returns an AvsValueType enum directly, one can use it instead of calling all IsXXX functions to establish the type. (Rust use case)
- Enhancement (#314): (avisynth.h) Gave all enums of public C++ API a name, and added DEFAULT_PLANE to AvsPlane (also in C API).
- Fix (#314): (avisynth.h) Changed NewVideoFrameP() property source argument to const in accordance with copyFrameProps(), since it's not meant to be written
Fixed in C interface as well: avs_new_video_frame_p and avs_new_video_frame_p_a: prop_src argument now const (no change in use)
- Enhancement (#314): Made VideoFrameBuffer destructor public like in other classes of the public API to prevent compiler errors downstream when calling non-const member functions
- "Text" new parameter: "placement" for chroma location hint
- Used in subsampled YUV formats, otherwise ignored.
- Valid values for "placement" are the same as in ChromaInPlacement and
ChromaOutPlacement in the Convert functions.
- Meaningful values: "center", "left", "auto" at the moment
- Default value is
- read from "_ChromaLocation" frame property, otherwise "left"
- override or set from "placement" parameter if parameter is other than "auto"
- if "auto" + have frame property -> use frame property
- if "auto" + no frame property -> use "left"
- no frame property and no parameter -> use "left"
- Only "center" and "left" is implemented. (center is known as jpeg or mpeg1, left is known as mpeg2)
If "center" is given directly or read from frame property, it will be used.
Otherwise "Text" renders chroma as "left" (mpeg2)
- "Text": Almost fully rewritten.
(#310) Support any width of bdf fonts (but still of fixed width)
Render in YUY2 is as nice as in YV16
Halo is not limited to original character matrix boundaries
Halo is not character based, but rendered on the displayed string as a whole.
Some speed enhancements, mainly for subsampled formats and outlined (with halo) styles
- Enhancement (#315): Show exception message as well if a v2.6-style plugin throws AvisynthError in its
AvisynthPluginInit3() instead of only "'xy.dll' cannot be used as a plugin for AviSynth."
- "Text": draw rightmost on-screen character even if only partially visible (was: not drawn at all)
- "Text": support more from the BDF standard (issue #310): per-character boundary boxes and shifts
- "Text" (#310): support 17-32 pixel wide external BDF fonts (issue #310)
- Fix: "Text" rounding negative x or y coordinates (e.g. x=-1 resulted in 0 instead of -1)
- Fix: "Text" would omit last character when x<0
- Fix: "Text" halo_color needs only MSB=$FF and not the exact $FF000000 constant for fade
- "Text" ``halo_color`` allows to have both halo and shaded background when halo_color MSB=$FE
- "Text" much nicer rendering of subsampled formats (#308)
- CMakeLists.txt: add support for Intel C++ Compiler 2022
- Address Issue #305: Support for non-decorated avisynth_c_plugin_init in 32 bit C-plugins
- Huge documentation update by Reel-Deal
- Fix (#304): ColorYUV analyze=true was displaying wrong min-max values for YUY2
- Fix: C API undefined behavior when upstream throw runtime error
(released in test2, fixed in test6 - ffdshow crash)
- Mute compilation warnings in avisynth.h
- CMakeLists.txt: fix clang-cl/intel with ninja generator
- Fix (#293): "Text" to throw proper error message if the specified font name (e.g. Arial) is not found among internal bitmap fonts.
- Fix (#293): "Subtitle" and "Text" filter to respect the explicitely given coorditanes for y=-1 or x=-1,
instead of applying vertical/horizontal center alignment.
- Fix: C interface crash when using avs_new_video_frame_p(_a)
- Fix (#283): broken runtime functions min/max/minmaxdifference when threshold is not 0 (returned -1). Regression in 3.7.2
- New: add a sixth array element to PlaneMinMaxStats: average. Defines variable "PlaneStats_average" as well if setting variables is required.
- Fix (#282): ConvertToRGB
- do check for exact 8 or 16 bit input, because packed RGB formats exist only for 8 and 16 bits
- keep alpha for RGBA planar - convert RGBAP8/16 to RGB32/64, while RGBP8/16 is still RGB24/48

[Dogway]

- Add "param1" and "param2" to ConvertToXXXX where "chromaresample" parameter exists.
Thanks for the update! Wasn't expecting this, it will come very useful for perf optimizations.

[ryrynz]

Changes since yesterday's test5: ffdshow fix, new resizers and parameterized chroma resampler option in ConvertToXXXX filters


Thank you, all good now.

[kedautinh12]

AviSynthPlus r3935 clang build
https://gitlab.com/uvz/AviSynthPlus-Builds

[jpsdr]

I again have the same issue, the following script:
SetMemoryMax(192)
AviSource("frame_divide_count_2.avi")

where the video is yuv422p10le of utvideo gives me the following error:File open error
AVI Import Filter error: (unknow) (80040154) when i try to open it with VirtualDub2.

The issue is specific to the clang builds. It happens with the r3935 and r3912.
The test3, test5 and test6 files provided by Pinterf work fine, so i think there is something wrong with the clang builds, it doesn't seem to be an avisynth issue.

[pinterf]

I again have the same issue, the following script:
SetMemoryMax(192)
AviSource("frame_divide_count_2.avi")

where the video is yuv422p10le of utvideo gives me the following error: when i try to open it with VirtualDub2.

The issue is specific to the clang builds. It happens with the r3935 and r3912.
The test3, test5 and test6 files provided by Pinterf work fine, so i think there is something wrong with the clang builds, it doesn't seem to be an avisynth issue.
Hi jpsdr!

Fixed on git, kedautinh12 will be soon happy to announce that a new clang build appears.

Crash occured when P10 or P16 format was exported on AVI interface (which VirtualDub is using)

Reason: clang build was using an aligned store operation, but the pitch of the target was not dividable by 16, so exporting the second row failed immediately.
MSVC builds compiled an unaligned store at that place, this is why it did not crash.

Thanks for the report.

[Reel.Deel]

Fixed on git, kedautinh12 will be soon happy to announce that a new clang build appears.

Lol. I see now that there are Clang and IntelLLVM builds to announce, he will be very happy :p

[kedautinh12]

AviSynthPlus r3936 clang and IntelLLVM build
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

Lol. I see now that there are Clang and IntelLLVM builds to announce, he will be very happy :p

Yes, i like optimize ver of all plugins :D

[pinterf]

I'd like to see benchmarks with different builds. I found that non-optimized C++ only codes were indeed quicker with clang/llvm. The difference was even bigger at 32 bit builds, where LLVM was much smarter on using avaliable (of limited number) CPU registers.

I then remember RgTools where it depended on the specific filter mode. One mode was better with Clang other modes were much quicker with the plugin version built with Microsoft, if I remember well, it was especially the AVX2 optimization where MS shined.

Probably this benchmark should be periodically rechecked for each generation change in compilers.

EDIT:
I see that the README.md in https://gitlab.com/uvz/AviSynthPlus-Builds contains a short script, where clang is +10%, IntelLLVM is +14% quicker than MSVC.
I wonder if the gain is evenly distributed among the filters of there is a specific one or two filters which are the bottleneck.

EDIT 2:

My benchmarks; two measurements per Avisynth+ version
Machine: Win11 Pro, 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz 2.50 GHz

MS: 49,78; 49,93 fps
Clang: 50,90; 50,74
IntelLLVM: 53,29; 53,25

EDIT 3:
The difference is mainly in dither=1 option (which is written in pure C). When changing that option in ConvertBits into dither=0:
MS: 154,3 fps
Clang: 154,9 fps
Intel: 154,8 fps

Script for this last run:
ffms2("myvideo")
convertbits(16)
converttoyuv444(chromaresample="spline36")
convertbits(32, fulls=false, fulld=true)
converttoplanarrgb()
convertbits(16,dither=0)
Spline36Resize(width*2, height*2)
convertbits(8, dither=0)

[pinterf]

O.K. Challenge accepted :)
Avisynth+ 3.7.3 test 7 (20230223) (https://drive.google.com/uc?export=download&id=1dKBH5DM6RwNSBBwdEoB-weg50I_whTEm)
Changes since test6
20230223 3.7.3 WIP
------------------
- Update build documentation with 2023 Intel C++ tools. See Compiling Avisynth+
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html
- CMakeLists.txt: add support for Intel C++ Compiler 2023.
- Enhanced performance in ConvertBits Floyd dither (dither=1) for 10->8, 16->8 and 16->10 bit cases
by providing special function templates to allow compilers to optimize them much better.
(Both Microsoft and Intel Classic 19.2 benefits, LLVM based clangCL and IntelLLVM compilers not)
- Fix crash when outputting VfW (e.g. VirtualDub) for YUV422P16, or P10 in Intel SSE2 optimization
due to aligned SIMD write to an unaligned pointer - did not affect Microsoft builds.
As seen in https://forum.doom9.org/showthread.php?p=1983343#post1983343

The bottleneck was dither=1 option.


test6 test7 (fps)
Microsoft 49,86 53,71
Clang 50,85* 52,99**
Intel 53,43* 58,17**

* from https://gitlab.com/uvz/AviSynthPlus-Builds
** provided in test7 package by me

My Intel version was built with Intel Classic 19.2
uvz version named the folder IntelLLVM. I was not able to reach even MS's speed with my IntelLLVM build without any tweak.

Script:
ffms2("myvideo720x576.avi")
convertbits(16)
converttoyuv444(chromaresample="spline36")
convertbits(32, fulls=false, fulld=true)
converttoplanarrgb()
convertbits(16,dither=1)
Spline36Resize(width*2, height*2)
convertbits(8, dither=1)

[Reel.Deel]

Surprisingly the test 7 MSVC build is the fastest for me. I'm embarrassed to post the speeds of my 10 year old PC but here they go. Edit: well I'm not that embarrassed anymore, I didn't realize pinterf's video was 720x576 :p.

Windows 7 (x64) - Intel i7-4930K

Script
ColorBars(1920, 1080, pixel_type="YUV420P8")
Loop()
Trim(0,1000)
ConvertBits(16)
ConvertToYUV444(chromaresample="spline36")
ConvertBits(32, fulls=false, fulld=true)
convertToPlanarRGB()
ConvertBits(16, dither=1)
Spline36Resize(width*2, height*2)
ConvertBits(8, dither=1)

Test 7 (r3940, MSVC)
FPS (min | max | average): 4.652 | 7.187 | 6.517
Process memory usage (max): 456 MiB
Time (elapsed): 00:02:33.598

uvz (r3936, IntelLLVM)
FPS (min | max | average): 4.505 | 6.913 | 6.272
Process memory usage (max): 449 MiB
Time (elapsed): 00:02:39.605

uvz (r3936, Clang)
FPS (min | max | average): 4.266 | 6.755 | 6.062
Process memory usage (max): 449 MiB
Time (elapsed): 00:02:45.114

Test 7 (r3940, Clang)
FPS (min | max | average): 4.367 | 7.026 | 5.999
Process memory usage (max): 449 MiB
Time (elapsed): 00:02:46.860

Test 7 (r3940, Intel)
FPS (min | max | average): 4.072 | 6.310 | 5.578
Process memory usage (max): 450 MiB
Time (elapsed): 00:02:59.451

Test 6 (r3935, MSVC)
FPS (min | max | average): 3.812 | 6.551 | 5.554
Process memory usage (max): 456 MiB
Time (elapsed): 00:03:00.226

Thread count: 16 and CPU usage (average): 8.2% was the same for all.

[Fjord]

Is it possible to get a little more information in the Expr() error message when the stack is unbalanced on return. The message is currently
"Expr: Stack unbalanced at end of expression. Need to have exactly one value on the stack to return" (in AvsPMod).
The same error message appears both for empty stack as well as more than 1 value on the stack at return.

Is it possible to show the number of elements remaining on the stack in the error message? That would really help debugging of Expr expressions.

[pinterf]

Is it possible to get a little more information in the Expr() error message when the stack is unbalanced on return. The message is currently
"Expr: Stack unbalanced at end of expression. Need to have exactly one value on the stack to return" (in AvsPMod).
The same error message appears both for empty stack as well as more than 1 value on the stack at return.

Is it possible to show the number of elements remaining on the stack in the error message? That would really help debugging of Expr expressions.
Why not. Done, it will appear in the next build.

[DTL]

Current test results of resizers for 2:1 downsize and checking for displaying with taps=8 sincresize:
https://drive.google.com/file/d/1ds4x-63WnpT905nZVcbnELMfHKj3Cr_w/view?usp=sharing

2.2 support for UserDefined2Resize was tested with custom debug build of current avisynth+ sources.

[Fjord]

Why not. Done, it will appear in the next build.
Thank you! You and all the devs are fantastic. :thanks:

[Boulder]

Tested the three builds on my 5950X using Reel.Deel's script. The Intel build is the fastest on a Zen 3 as well.

MSVC
FPS (min | max | average): 11.12 | 14.64 | 14.19
Process memory usage (max): 367 MiB
Thread count: 33
CPU usage (average): 3.1%

Time (elapsed): 00:01:10.544

Clang
FPS (min | max | average): 11.14 | 14.84 | 14.09
Process memory usage (max): 367 MiB
Thread count: 33
CPU usage (average): 3.1%

Time (elapsed): 00:01:11.053

Intel
FPS (min | max | average): 11.20 | 14.81 | 14.22
Process memory usage (max): 367 MiB
Thread count: 33
CPU usage (average): 3.1%

Time (elapsed): 00:01:10.417

[FranceBB]

Current test results of resizers for 2:1 downsize and checking for displaying with taps=8 sincresize:
https://drive.google.com/file/d/1ds4x-63WnpT905nZVcbnELMfHKj3Cr_w/view?usp=sharing

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

[Reel.Deel]

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

Already implemented since test 6.


Changes since yesterday's test5: ffdshow fix, new resizers and parameterized chroma resampler option in ConvertToXXXX filters

20230218 3.7.3 WIP
------------------
- (#337) Add more resizers types by jpsdr's and DTL's idea: backport from https://github.com/jpsdr/ResampleMT

SinPowerResize "cii[src_left]f[src_top]f[src_width]f[src_height]f[p]f"
parameters like GaussResize: optional "p"
Default: p=2.5

and their equivalent for the ConvertToXXXX family:
"sinpow", "sinclin2" and "userdefined2"

....

[DTL]

Will SinPowResizeMT() finally become SinPowResize() in the Avisynth core or is it not currently in roadmap?

It is already transferred to AVS. But its kernel is more non-linear (its support is hardlimited to 2) so for more higher quality work we also have (possibly better) kernel of UserDefined(2).
The kernel of SinPow is based on several non-linear hacks and work only in very truncated size (with more or less discontinuity at edges).
The kernel of UD can be safely expanded to larger 'support' size (until it safely reach very low values).
Initially there were an idea to set larger fixed 'support' to UD(2) resize (like 3 for example) internally but with experiments I found it may be useful to limit its 'support' too by additional user-controlled param and to the finely adjusted float value (most changes occur at adjustments from 2 to 3 with steps like 0.1..0.2).
For example setting 'support' of 2.2 to UD2 it possible to get less residual ringing/artifacts at transients while using 'higher' b/c control params of 75/-25 and get more sharpness (closer to SinPow). Using old 'support' of 2 require to use 'lower' b/c control pair of 70/-30 (more 'extreme') to have comparable visible sharpness while having more residual ringing/artifacts. So limit of 'support' to 2 only for UD kernel significantly limits its possible 'peaking/sharpness' capability with extreme b/c setting of kernel members, also not allow to show its 'linear' properties in ringing control at full scale.

So I supplement the current issue description with request to add 3rd control param to UD(2) resize of 'support' or 's'. With s=2 (as in old implementation of jpsdr's plugin) the UD(2)Resize may be adjusted close enough to SinPowResize output (at least in some range of control param). And when increasing 'support' to 3 (and may be more) you can get less residual ringing (while having lower sharpness and thicker 'peaking' contours around sharp transients). So with adjusting 'support' param the UD(2)Resize can be adjusted between 'partially non-linear' resize with s=2 to 'more linear' with s>2. Though real difference between SinPow and UD resizers even with fixed support=2 as today is not easily visible and UD(2) s>2 is mostly for 'perfectionists' like creating high-end linear processing workflow. Understanding it will have lower 'per-sample' sharpness (so require to sit at more distance from screen or use higher DPI displays and more samples per frame to keep the same 'visual sharpness'). So for very limited in samples count per frame (small frame size internet-torrents) rips of UHD/HD sources (like 700MB version in something like 640x360) may be 'partially non-linear' form of current SinPow and UD2 s=2 resizers may have benefits of a bit higher sharpness while producing some more residual ringing/artifacts. I currently checking my new rip of 4k->FullHD of some nature documentary created with UD2(width/2, height/2, b=70, c=-30) and it looks about very good.

So SinPow kernel looks like limited to its initial design of single control param and 'support' of 2 and some non-linearity by-design with about no expanding possible. And UD can be easlily expanded in the number of kernel members used and 'support' size with some increasing of quality (control over residual ringing and artifacts). For example UD10Resize with 'support' of about 10 and 10 user-provided kernel members easiliy possible. So with some 'user-provided vector of arguments' more general form is
UserDefinedNResize(kernel members list, s, ...)
where is args_count=2 (and s=2) it is current UserDefined2Resize. But I poor in programming of AVS and still not know how to make filter with variable number of arguments and it require to ask very busy pinterf to make more programming or someone else.

And also as noted in https://forum.doom9.org/showthread.php?p=1983080#post1983080 and https://forum.doom9.org/showthread.php?p=1983119#post1983119 about chroma subsampling conversion it is now possible to use different types of 4:4:4<->4:2:x conversion filtering to UV in Convert() filters.

Here is example of muiti-generation default bicubic filter at 4:4:4<->4:2:0 chroma sharpness degradation:

ColorBars(960*4, 540*4, pixel_type="YUV444P8")
UserDefined2Resize(width/4, height/4, b=105, c=0) # put some conditioning

sinc=ConvertToYUV420(chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420()
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc,chromaresample="sinclin2")
sinc=ConvertToYUV444(sinc,chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)
bicub=ConvertToYUV444(bicub)

sinc=ConvertToYUV420(sinc, chromaresample="sinclin2")
bicub=ConvertToYUV420(bicub)

sinc_mon=ConvertToYUV444(sinc,chromaresample="userdefined2", param1=105, param2=0).Subtitle("sinc_mon") #monitoring chroma anti-Gibbs
sinc_no_mon=ConvertToYUV444(sinc,chromaresample="sinclin2").Subtitle("sinc_no_mon")
bicub=ConvertToYUV444(bicub).Subtitle("bicub")

Interleave(sinc_mon, sinc_no_mon, bicub)
SincLin2Resize(width*2, height*2)


Addition: Really with some more supplementing of UserDefinedResize with optional 'lin2' weighting as in SincLin2Resize the complete digital moving pictures system from scene light to display light (with subsampled chroma) can be built with UD Resize only. Because with b=c=16 the UD kernel is single sinc only.
So with w-param of w='none' or 'lin2' and extending of s to 16:

ColorBars(960*4, 540*4, pixel_type="YUV444P8") # our natural infinite resolution scene , really RGBP8 or better RGBPS

# main digital video camera transform of full conditioning of RGB/YUV (band-limiting and anti-Gibbs residual spectrum shaping
# to required look/makeup)
UserDefined2Resize(width/4, height/4, b=105, c=0, s=3, w="none") # film-look / makeup softer
#or
UserDefined2Resize(width/4, height/4, b=80, c=-20, s=3, w="none") # video-look / makeup sharper

# put 2:1 system compression converting to 4:2:0 with partial conditioning (band-limiting, no anti-Gibbs)
ConvertToYUV420(chromaresample="userdefined2", b=16, c=16, s=16, w="lin2")

#MPEG compression for distribution
#digital moving pictures production transform ends here

##########
# broadcasting / distribution / archive digital movie compressed content
###########

#enduser transform:
#MPEG decompression to 4:2:0

#1:2 decompression of 4:2:0 to 4:4:4 and continue 2:1 bandlimited UV data conditioning with anti-Gibbs
ConvertToYUV444(chromaresample="userdefined2", b=105, c=0, s=3, w="none")

UserDefined2Resize(width*4, height*4, b=16, c=16, s=16, w="lin2")# equal to SincLin2Resize(), decompression of sampled data to 'infinite' resolution (DAC)

ConvertToRGB()# for feed to RGB physical display

[jpsdr]

Hello.

Tested the Test7 version provided by Pinterf, and with the clang version, i still have the same issue, the following error message with VirtualdDub2:
File open error
AVI Import Filter error: (unknow) (80040154)
when i open with AVISource an yuv422p10le UTVideo file.
The MS build works fine.

[FranceBB]

Sox doesn't seem to be working neither in x86 nor in x64.
Tested on both Windows XP x86 and Windows Server 2019 x64.


How to reproduce:

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

this should upmix stereo to 5.1 using Sox, however it doesn't work.

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

This has been broken since 2017 and the last version working with sox was Avisynth 2.6.1 from 2016 (it's been a minute, I know).

I reported it here: https://forum.doom9.org/showthread.php?p=1887661

a while ago and has been reproduced by Tebasuna as well for both x86 and x64.
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?

[pinterf]

Hello.

Tested the Test7 version provided by Pinterf, and with the clang version, i still have the same issue, the following error message with VirtualdDub2:
File open error
AVI Import Filter error: (unknow) (80040154)
when i open with AVISource an yuv422p10le UTVideo file.
The MS build works fine.
Problem found and maybe fixed. A sample or telling the dimensions of your video would helped a lot :), I had only a width=640 sample which is a proper nice mod16 even mod32 value and only hacked the width to be 638 and there came the crash. I don't know if your actual sample would crash or not but I hope it's OK now.

[tebasuna51]

...
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?

An avs+ better audio management is always desirable, but the first improvement must be change the Audio property AudioChannels.

Must be MaskChannels (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ksmedia/ns-ksmedia-ksaudio_channel_config) instead NumChannels (than can be calculated from MaskChannels)

[pinterf]

Sox doesn't seem to be working neither in x86 nor in x64.
Tested on both Windows XP x86 and Windows Server 2019 x64.


How to reproduce:

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

this should upmix stereo to 5.1 using Sox, however it doesn't work.

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

This has been broken since 2017 and the last version working with sox was Avisynth 2.6.1 from 2016 (it's been a minute, I know).

I reported it here: https://forum.doom9.org/showthread.php?p=1887661

a while ago and has been reproduced by Tebasuna as well for both x86 and x64.
Since a new Avisynth version is in the making (3.7.3 Test 7), is there a way to get this sorted once and for all so that I can go back to use Sox?
Ohh, something written 17 years ago does not work anymore :)
And this is a CPP 2.5 style plugin. Nothing is guaranteed, if it works, we are happy.

I'm gonna put zero effort into checking why it does not work.

Instead, the whole Sox library integration must be refreshed; too bad they changed the API, first in 2006, then ... who knows when.
Anyway, I could not make Sox compile as a static library to link with SoxFilter avisynth filter, nor could do any integration in two hours' effort.

Everything has been changed since then. For example I had no grey hair in 2006 :) Maybe I return to it later. But it is a challenge for sure.

[FranceBB]

Yeah, I know.
It's a shame that they haven't updated anything since 2006 and I'm also sad to see it failing to compile while targeting new Avisynth+ headers... :(

Unfortunately, I used to rely on those upmix methods a lot in the past, in particular when I had to insert like distribution bumpers etc in what would otherwise be a 5.1 movie or tv series etc before creating the final DCP and send it over to the cinemas.
Nowadays, ever since it stopped working with newer versions of AVS, I used the surround filter in FFMpeg like:

ffmpeg.exe -i "New File (25).avs" -af surround=chl_in=stereo:chl_out=5.1:level_in=1:level_out=1:lfe_low=3:lfe_high=128:win_func=hann -acodec pcm_s24le -ar 48000 -y "out.wav"

pause

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


however ideally in the future I'd like to go back doing everything inside Avisynth like I used to.
Someone should really pick up the Sox filters and properly maintain them instead of leaving them in the Avisynth 2.5 abandonware... :(

[jpsdr]

Problem found and maybe fixed. A sample or telling the dimensions of your video would helped a lot :)
:thanks:

3840x1608
Sorry, i didn't thought about it, i was too much focussed on just the format part.
I can PM you my ftp server information and put the video on it if necessary, it's "small", less than 100 frames, it's was just a small thing for test purpose.

[pinterf]

Yeah, I know.
It's a shame that they haven't updated anything since 2006 and I'm also sad to see it failing to compile while targeting new Avisynth+ headers... :(

Someone should really pick up the Sox filters and properly maintain them instead of leaving them in the Avisynth 2.5 abandonware... :(
Just wait and you'll see :)

[jpsdr]

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

[kedautinh12]

Out of curiousity, why the Clang and Intel build don't have the DirectShowSource plugin ?

Cause Directshowsource don't had any change very long. So can got from old ver avs+

[Reel.Deel]

Cause Directshowsource don't had any change very long. So can got from old ver avs+

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

[qyot27]

DirectShowSource does not get built by default, you have to specifically opt-in to build it (https://github.com/AviSynth/AviSynthPlus/blob/master/plugins/CMakeLists.txt). This is intentional, because unlike the other core plugins, DSS has a dependency on the DirectShow baseclasses library that, for whatever reason, is not part of a default install of either MSVC or the DirectX SDK. You have to build that library from the SDK samples, and because that's so non-intuitive (and because DSS should only ever be used as a last resort), it's better to leave it off by default so it doesn't impede the build process. Not to mention that for MinGW-w64/GCC builds, the MSVC-built baseclasses library is *probably* a no-go. There is something of a port of the baseclasses library to MinGW, but because DirectShowSource doesn't build with GCC, there's not really any way of vetting whether it works as intended.

That's not even touching the question of whether Clang or Intel compilers can build the baseclasses library at all, although I would assume that they can at least link to an existing build of it just fine ('Clang' in this case being assumed to be the clang-cl MSVC compatibility frontend, not the regular version of Clang that uses GCC's conventions).

[kedautinh12]

Other core plugins have not been updated in sometime also but yet they are always recompiled. So there's probably a good reason why DirectShowSource is not included in the Clang and Intel builds.

I don't know but when Pinterf still use old date directshowsource.dll in his new build

[jpsdr]

Problem found and maybe fixed.
Tested the clang git build r3950, still the issue, so it's probably not pushed yet.

[pinterf]

Tested the clang git build r3950, still the issue, so it's probably not pushed yet.
It's pushed; could you upload your sample clip fragment?

[jpsdr]

It's pushed; could you upload your sample clip fragment?

I've PM you informations.

[jpsdr]

Ok, i made more tests.

When i test a new avs+ version, i always do the same thing : open in VirtualDub2 the same avs file reading the same 10bit422 UTVideo file.
When VDub2 throw me an error message (it wasn't a crash), i thought there was an issue with AVISource in the clang build.
Well... There was indeed an issue in AVISource, but this was a fluke. As, for me, it wasn't a crash.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....:confused:
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...

[pinterf]

Ok, i made more tests.

So i finaly thought to test with AVSMeter, result was "error, unable to load avisynth.dll"... Ah....:confused:
So i tried with Virtualdub (not VDub2) to open others avs files reading "nice" 8 bits avi. Same error message. Same thing x86 or x64 version.

Result is that clang and Intel version, from both r3950 git and Test7 zip file are not running at all, x86 or x64. It seems to be a build issue.
Or... is there some redistributable needed ?
I allready have the Intel 20.0.311 redistributable installed...
Strange, temporarily I'd try to get rid of all autoloaded plugins, move them away, to make sure if one of them is making avisynth crash when loading. I don't have any other idea. My avsmeter is 3.0.0.4, and happily consumes any avisynth version

[pinterf]

Just wait and you'll see :)
When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again, test its various filters, and then try UpSoundOnSound which is using the same SoxFilter'ed clip four times, and realize that Avisynth+ has NO audio cache implemented... The feeling is priceless.

[DTL]

It looks GeneralConvolution() is somehow broken between 201x and 202x years.

In old decade

GeneralConvolution(0, "
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true, luma=true, chroma=false)

Make some sharpening effect on more medium frequencies in compare with Sharpen() because Sharpen use only 3x3 kernel. Now it return significantly distorted frame with lots of banding. The sum of coefficients is =1 so auto=true/false do nothing.

For simple YV12 format. Tried RGB32, tried 16bit.
At Windows7 tried AVS versions from 2.6 to +3.6 , +3.7 and still the same distortion. May be GeneralConvolution depends on some updated VisualC++ libs or other windows7 components ?


Here most simple form of bug with GeneralConvolution:

GeneralConvolution(0, "
-0.4 -2 -0.4
-2 9 -2
-0.4 -2 -0.4", auto=true, luma=true, chroma=false)

Make sharpening about as expected.

GeneralConvolution(0, "
-0.5 -2 -0.5
-2 9 -2
-0.5 -2 -0.5", auto=true, luma=true, chroma=false)

Turn to significant blurring. The switch from about good to significantly bad result occur when diagonal angle coefficients of simplest 3x3 matrix go from -0.4 to -0.5. Looks like some rounding or auto-normalization error ?

Same is with documentation example:
GeneralConvolution(0, "
-0.4 -1 -0.4
-1 5 -1
-0.4 -1 -0.4 ", auto=true, luma=true, chroma=false)
Still make sharpening as expected.

GeneralConvolution(0, "
-0.5 -1 -0.5
-1 5 -1
-0.5 -1 -0.5 ", auto=true, luma=true, chroma=false)
Switch to very blurry.

Same result with 3.7.2 release, 3.7.3 test 7 x64, x64_xp (x64_clang and x64_IntelClassic not work with AVI import filter error).

[FranceBB]

When you spend ~40 hours on understanding what sox really is and slowly get the latest sox library work again

:)


test its various filters, and then try UpSoundOnSound

:D



, and realize that Avisynth+ has NO audio cache implemented...

:scared:


Jokes aside, thank you so so so much for taking a look at this. It means the world to me and I'm really grateful to see how every time I highlight something you always go above and beyond to get it working.
We're really lucky to have you in this community, Ferenc! I mean it.

[wonkey_monkey]

Looks like some rounding


Not sure about the rest of your trouble with GeneralConvolution but bear in mind that the Wiki states:

float values are converted to integers for 8-16 bit clips

So -0.5->-1, and -0.4->0.

[DTL]

Kernel of 5 at the center and -1 surround also should not be blur kernel. Now the significant discontinuity in output effect from corners kernel members 0 to -1 also not look like correct action. If even floats not accepted it is only expected more significant step from light sharp with
0 -1 0
-1 5 -1
0 -1 0

to stronger sharp with
-1 -1 -1
-1 5 -1
-1 -1 -1.

But now last kernel cause switching to blur. The visible difference - sum of 1st kernel is 5+(-4)=1 and sum of last is 5+(-8)=-3. May this negative sum sign also play role in the issue ?

Checked (YV12 8bit 4:2:0):
-1 -1 -1
-1 5 -1
-1 -1 -1 - blur

-1 -1 -1
-1 6 -1
-1 -1 -1 - slightly sharper

-1 -1 -1
-1 7 -1
-1 -1 -1 - sharper, horizontal and vertical double contour

-1 -1 -1
-1 8 -1
-1 -1 -1 - almost black frame ! (zero sum), still auto=true

-1 -1 -1
-1 9 -1
-1 -1 -1 - finally sharping, auto=true/false - equally.

-1 -1 -1
-1 10 -1
-1 -1 -1 (auto=true - less sharp, auto=false - significant level offset to white)

So auto=true do not work with zero and negative integer sum ?

But kernel of 5x5 of
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 37 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

with sum=1 still return sort of HigiPassFilter only with about removed DC component and very low frequencies. DC component (median level and very low frequecies) start to recover to about
-1 -1 -2 -1 -1
-1 -2 -2 -2 -1
-2 -2 45 -2 -2
-1 -2 -2 -2 -1
-1 -1 -2 -1 -1", auto=true,

45..50..60 value of the 'central' value. So sum is much higher 1. With auto=false and center 80 - return white frame. May be something is changed in 'auto=true' internal processing ?

Attempt to float32:
ConvertBits(32)
GeneralConvolution(0, "
-1 -1 -1
-1 5 -1
-1 -1 -1 ", auto=true, luma=true, chroma=false)
ConvertBits(8)

change nothing from 8bit luma - still blur.

So it looks logic of GeneralConvolution kernel coefficients processing is changed somehow and now for 'sharp' kernels the total sum must be >>1 and only auto=true is working ?
For example now about good linear sharpener is
GeneralConvolution(0, "
-1 -2 -2 -2 -1
-2 -2 -3 -2 -2
-2 -3 70 -3 -2
-2 -2 -3 -2 -2
-1 -2 -2 -2 -1", auto=true, luma=true, chroma=false) - result demo https://imgsli.com/MTYxNDkz
And adjusting center member in range about 60..100 it is now possible to adjust 'strength'. Where 60 is very strong, 100 is very weak and 50 is sort of high-pass filter only. May it is also valuable mode but it looks old versions work differently and old matrices require re-adjustment of 'center' member.

[wonkey_monkey]

So auto=true do not work with zero and negative integer sum ?

auto is disabled when the sum is zero. If the sum is negative, then it divides by that negative sum, and I think that's where it's not behaving as you'd expect. But it is behaving correctly. I put the same maths through a different filter and got the same result.

The negative sum means the pixel with the positive value (the center one) makes a negative contribution to the output, while the surrounding negative coefficient pixels end up making a positive contribution. And the negative contribution of the center pixel is smaller than the positive contribution of the surrounding pixels, so the result looks like a blur.

[DTL]

May be auto (normalizing) not needed when sum=1 ? Typical kernel normalizing process is:
1. calculate sum of all members.
2. divide each member to sum.

Convolution with kernel with sum=1 at least keep DC and very low frequencies components unchanged.

[ryrynz]

:)
We're really lucky to have you in this community, Ferenc! I mean it.

Ferenc needs to have his details in the forum changed from "Registered User" to Avisynth GOAT.

[Emulgator]

...and realize that Avisynth+ has NO audio cache implemented... The feeling is priceless.
For this and for all that cleanup work: Nagyon szépen köszönöm Ferenc !

[flossy_cake]

DSS should only ever be used as a last resort

DSS just uses whatever source filter has highest merit on your system, in my case that is LAV filters which are excellent and maintained with up to date features by nevcairiel.

But Avisynth's implementation of DSS seems to downsample to 8-bit internally before handing it to LAV, so I can't use it for 10-bit videos even though LAV filters support it. imo DSS deserves an overhaul and should support subtitles as well like DSS2Mod.

DSS is very useful for realtime use as it doesn't have to index/cache anything, instant playback, instant seeking (with LAV that is, which uses ffmpeg).

[guest]

For this and for all that cleanup work: Nagyon szépen köszönöm Ferenc !

And just in case nobody knows what that means...

"thank you so much" :D

[jpsdr]

Strange, temporarily I'd try to get rid of all autoloaded plugins, move them away, to make sure if one of them is making avisynth crash when loading. I don't have any other idea. My avsmeter is 3.0.0.4, and happily consumes any avisynth version
Excellent idea, i tested, and... Still the same.
Even with all the autoload directories empty (plugins, plugins+, plugins64, plugins64+), AVSMeter still says "Error, unable to load avisynth.dll" with r3950 clang and IntelLLVM+redist build files.
No issue with the VisualStudio test7 build files.
...:confused:

[StvG]

Excellent idea, i tested, and... Still the same.
Even with all the autoload directories empty (plugins, plugins+, plugins64, plugins64+), AVSMeter still says "Error, unable to load avisynth.dll" with r3950 clang and IntelLLVM+redist build files.
No issue with the VisualStudio test7 build files.
...:confused:

Download Dependencies_x64_Release.zip (https://github.com/lucasg/Dependencies/releases), load avisynth.dll in DependenciesGui and share the output/check if something is missing.

[filler56789]

DSS just uses whatever source filter has highest merit on your system,

DirectShowSource can also use ANY source filter /demuxer /decoder /processor available on one's Windows PC —
— just tell DSS() to open a "well-constructed" .grf file.

[FranceBB]

DirectShowSource can also use ANY source filter /demuxer /decoder /processor available on one's Windows PC —
— just tell DSS() to open a "well-constructed" .grf file.

True.
It used to be extremely useful back in the days when proprietary codecs which didn't have an indexer had a separate .exe that you could install to make such a codec widely available on the system by all applications that were able to use DirectShow. I still remember CanopusHQ being a prime example of this and how I could index it with DirectShowSource() only.

Unfortunately, nowadays, companies are way more reluctant in doing those things and when they release their codecs, it's generally just some "plugin" for the most common non linear editors like AVID Media Composer, Adobe Premiere, Davinci Resolve etc.
Think about Sony Raw, Canon Raw, Blackmagic Raw, Red Raw, Arri Raw etc...
They all work with their proprietary software like Sony Catalyst, ArriRaw Converter etc and their "codec" is more of a "plugin" as it exposes it to non linear editors, but not to Windows, so they can't be decoded using DirectShow.
This meant that over the years DirectShowSource() has lost a bit of popularity in its use, which is a shame, really, as those proprietary codecs (which don't have any open source indexer that can decode them) should really be exposing themselves to Windows via DirectShow...
Oh, if only those company listened to their users... :(

[jpsdr]

@StvG
I've checked the dependencise of AviSynth.dll and DevIL.dll, both x86 and x64, on both x64 and x86 OS, nothing is missing... :(

[pinterf]

For this and for all that cleanup work: Nagyon szépen köszönöm Ferenc !
Thanks :)

Anyway, the Avisynth+ audio cached version is uploaded on git, I won't provide test build today for sure. I guess old prehistoric SoxFilter will automagically start working.

But I'm still going to finish my new SoxFilter which is using the latest sox library. It is basically ready but you know, one must nicely arrange and polish the code, document, put it properly to github, try building it under various settings (maybe figure out how to build it under linux) still many days ahead...

Relevant change log part:
20230314 3.7.3 WIP
------------------
- Set automatic MT mode MT_SERIALIZED to
ConvertToMono, EnsureVBRMP3Sync, MergeChannels, GetChannel, Normalize, MixAudio, ResampleAudio
- Add back audio cache from classic Avisynth 2.6.
Believe it or not, audio cache was never ported to Avisynth+
- Make use of avisynth.h constants: CACHE_GETCHILD_AUDIO_MODE and CACHE_GETCHILD_AUDIO_SIZE:
Filters are queryed about their desired audio cache mode through their SetCacheHints (similarly to CACHE_GET_MTMODE).
- Filters can answer CACHE_GETCHILD_AUDIO_MODE with
CACHE_AUDIO: Explicitly cache audio, X byte cache.
CACHE_AUDIO_NOTHING: Explicitly do not cache audio.
CACHE_AUDIO_AUTO_START_OFF: Audio cache off (auto mode), X byte initial cache.
CACHE_AUDIO_AUTO_START_ON: Audio cache on (auto mode), X byte initial cache.
- Default value is CACHE_AUDIO_AUTO_START_OFF.
- Filters can specify the required cache size by returning CACHE_GETCHILD_AUDIO_SIZE.
Default cache size is 256kB.
- For custom audio cache querying example see EnsureVBRMP3Sync::SetCacheHints in source.
How it works:
- Modes CACHE_AUDIO_AUTO_START_OFF (default) and CACHE_AUDIO_AUTO_START_ON are automatic modes.
The decision whether the stream benefits caching or not - and how big the cache
size should be - is made upon continously gathering some statistics on the audio
stream requests (an internal score is maintained).
- when strict linear reading is detected. why bother with a cache,
mode would finally changed to CACHE_AUDIO_AUTO_START_OFF.
- When the requests are continously skipping chunks - a cache might not help;
go with CACHE_AUDIO_AUTO_START_OFF as well.
- When the next sample request is within the cache size, a cache could help:
if audio cache was swithed off Avisynth would turn it into active caching by changing
the working mode to CACHE_AUDIO_AUTO_START_ON.
- Modes CACHE_AUDIO and CACHE_AUDIO_NOTHING are explicitely enable/disable audio cache at a give size.

[pinterf]

@StvG
I've checked the dependencise of AviSynth.dll and DevIL.dll, both x86 and x64, on both x64 and x86 OS, nothing is missing... :(
Other ideas.
- Virus check engine?
- BTW: Looked at avsmeter (3009) source and avsmeter cannot report such error message: "Error, unable to load avisynth.dll". Is this your exact message? Is it a popup window or just written on the console?
- Can you find relevant entries in Sysem or Application in event viewer eventvwr.exe?
- Do you have ffdshow or some of its dll somewhere in your system?

[DTL]

The clang and IntelC builds of 3.7.3 test 7 also not work at my Win7 x64. With VirtualDub error is sort of 'AVI import fail'. So it is something with compilers expected. Though the performance of clang builds for some architectures (like AVX512) is much better in compare with MSVC compiler. So it is good to find why clang builds not loads at user side.

"Do you have ffdshow or some of its dll somewhere in your system?"

Yes - ffms2.dll is loaded as plugin in the script and in the current working directory. FFmpegSource2() used as the source.

[FranceBB]

Anyway, the Avisynth+ audio cached version is uploaded on git, I won't provide test build today for sure. I guess old prehistoric SoxFilter will automagically start working.


https://media.tenor.com/TrAsjYbL720AAAAM/chris-pratt-wow.gif

WOW! A-M-A-Z-I-N-G!
Thank you so, so, so much! :D
Now I can finally say goodbye to FFMpeg once again ehehehehehe



I'm still going to finish my new SoxFilter which is using the latest sox library.


A new sox version too? Is it Christmas already? :D
Thank you, again, a lot, Ferenc, we would be lost without you!! :)

[pinterf]

The clang and IntelC builds of 3.7.3 test 7 also not work at my Win7 x64. With VirtualDub error is sort of 'AVI import fail'. So it is something with compilers expected. Though the performance of clang builds for some architectures (like AVX512) is much better in compare with MSVC compiler. So it is good to find why clang builds not loads at user side.

"Do you have ffdshow or some of its dll somewhere in your system?"

Yes - ffms2.dll is loaded as plugin in the script and in the current working directory. FFmpegSource2() used as the source.
VirtualDub or VirtualDub2? (I meant ffdshow, not ffms)
Win 7? I forgot, jpsdr are you using Win7, too?

[pinterf]

Windows 7 vs. LLVM based compilers:

I found this on Intel's site.

https://www.intel.com/content/www/us/en/developer/articles/release-notes/intel-c-compiler-190-for-windows-targets-release-notes-for-intel-system-studio-2019.html#nextgen_sysreq

For the /Qnextgen option to use LLVM Technology only the following are supported:

For Intel64, supported Windows OSes and Visual Studio - only those listed below:
Windows 10
Windows Server 2019
Windows Server 2016 (1607)
Visual Studio 2019 with Windows SDK 10
Visual Studio 2019 Build Tools* with Windows SDK 10
Visual Studio 2017 with Windows SDK 10

Target software requirements

The target platform should be based on one of the following environments:

Microsoft Windows 10 IoT Core*, Microsoft Windows 10*, Microsoft Windows Embedded 8*, Microsoft Windows Embedded 7*

[pinterf]

And the above was only for two versions behind.

This is from 2022
https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-dpcpp-system-requirements-2022.html
"Windows* 10 (64 bit) Microsoft Windows Server* 2022, 2019, 2016"
Windows 7 or 8 is not mentioned

And this one from 2023
https://www.intel.com/content/www/us/en/developer/articles/system-requirements/intel-oneapi-dpcpp-system-requirements.html
Windows* 10, 11 (64 bit) Microsoft Windows Server* 2022, 2019

[jpsdr]

Yes, i'm using Windows 7.
BTW, I didn't know there was an Intel LLVM version. To make llvm builds of my plugins i'm using the LLVM at the llvm.org (well, their github release), and they work fine under Windows 7.
Ok, the Intel don't even target Windows 7, but what about the clang ?
I could try to build it myself... But don't know how...
Edit:
I think i've figured out, i've tried CMake, it seems to work.
Edit2:
Ohhh... First quick test worked... Now i just have to test with llvm.

[pinterf]

Forget DirectShow at the moment, uncheck or do not define the build DirectShowSrouce option. Not easy.
Check
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html#id8
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html#building-with-microsoft-c-cmake-command-line as well.

My test7 build was with Intel Classic 19.2 (icl), which btw. will be abandoned by Intel in 2023H2.
Then there is the IntelLLVM aka NextGen (icx) which is supported and recommended by Intel from now on.
I just tried them both and added them to the documentation some weeks ago (updated with the latest 2023 versions).
I have Windows 11 though so cannot even tell you about the adventures with Win10 and earlier version.

[jpsdr]

First, the AVSMeter error message is exactly : "Error: Cannot load avisynth.dll", in the console. My version is 3.0.9.0.

Second, i've build AviSynth with llvm the same way (and with the same compiler) i build my VDub or AviSynth plugins. It didn't work either, exact same behavior.
I build with llvm downloaded on the github, and with VisualStudio 2019 (16.9.26) installed with llvm support but without the llvm compiler provided with VS, Update 9 is the last version it works using "external" installed llvm version.

Very very odd, as my plugins work fine... :confused:

[kedautinh12]

Anyone had problem with intel build can try install latest Intel® oneAPI DPC++/C++ Compiler Runtime for Windows*
https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html

[DTL]

"For the /Qnextgen option to use LLVM Technology only the following are supported:
For Intel64, supported Windows OSes and Visual Studio - only those listed below:
Windows 10"

It looks AVS+ starting to lost compatibility not only with WinXP but with Win7 too.

[jpsdr]

Warning : There is 2 things :
- The OS supported by the compiler : Where you can install it.
- The targets supported by the compiler, what you can build for, not the same. Be sure to not mix them.

But what bothers me in my tries, is why the avisynth i've build is not working, when my plugins are, both being build with the exact same compiler...
And the x265.exe i've also build with the same compiler is working under Windows 7.

I'm totaly lost... :confused:

There must be something i'm not seeing in the options...?

[DTL]

"why the avisynth i've build is not working, when my plugins are, "

Possibly because AVS+ is designed differenly to your plugins. So it mean it starting to lost compatibility with old versions of windows. Sadly it not make compiler warnings or errors and simply fail to load in Win7 ? Or may be as large project as AVS+ have most of warnings and non completely critical stop-errors disabled to make building easier. But it may cause such issues on target operating systems. The debug build also not loads ? Or debug run not tested ?

[FranceBB]

It looks AVS+ starting to lost compatibility not only with WinXP but with Win7 too.

Nah, it will be something like: MSVC version compatible with literally everything and then Clang/LLVM version compatible only with the "latest and greatest" version of Windows and Windows Server.

To be fair, I don't see MSVC builds going away anytime soon and as long as they're gonna be there, people will have a choice. ;)

[DTL]

I mean internal design of AVS+ may starting to lost compatibility with Win7. It may be no one day process but someday even MSVC builds will no loads at Win7.

As you see with jpsdr example - some simple software like small plugins still can be built with llvm and run at Win7 and AVS+ as much complex software set already fails.

[FranceBB]

As you see with jpsdr example - some simple software like small plugins still can be built with llvm and run at Win7 and AVS+ as much complex software set already fails.

I too use his plugins and it's indeed very weird that they work while the AVS core doesn't.
I mean, there must be a reason, surely.

[pinterf]

I too use his plugins and it's indeed very weird that they work while the AVS core doesn't.
I mean, there must be a reason, surely.
Many things happen when loading a DLL with lots of classes, setting global variables, static initialization, which can be different among compilers.
Even before the any part is run from our written code.
E.g. LLVM clang-cl is trying the keep the same ABI as Microsoft.
And they made it more compatible than Microsoft themselves, when they broke their own ABI :)
https://clang.llvm.org/docs/MSVCCompatibility.html
"Thread-safe initialization of local statics: Complete. MSVC 2015 added support for thread-safe initialization of such variables by taking an ABI break. We are ABI compatible with both the MSVC 2013 and 2015 ABI for static local variables."
Avisynth initialization sequence is a "bit" more serious than most of the plugins'.

So it is not weird at all that plugins work, but Avisynth doesn't.

Or simply there is indeed a rare bug which happens only in special circumstances.

[pinterf]

Avisynth+ 3.7.3 test 8 (20230315 - r3958) (https://drive.google.com/uc?export=download&id=1BvFA3vNePZVLgtnQ4FiugcHddkricK2m)
Sporting with a good old friend: audio cache. I hope it won't introduce new problems. Basically the same as in classic Avisynth 2.6.
And a fix of a bug introduced in test7 (AvsPMod F5 refresh), thanks Asd-g for the report.

[FranceBB]

You nailed it, Ferenc, as always!
Sox magically started to work as you predicted. :)
And indeed, now I finally have a meaningful way to go from Stereo 2.0 to 5.1 thanks to the good old Avisynth upmix functions:

https://i.imgur.com/LViYTru.png
https://i.imgur.com/F1b8WQQ.png

[kedautinh12]

Avs+ r3958
https://gitlab.com/uvz/AviSynthPlus-Builds

[guest]

Avs+ r3958
https://gitlab.com/uvz/AviSynthPlus-Builds

Not another one...

I will try both, hopefully no issues, this time. :D :cool:

EDIT:- r3958 LLVM is working for me :) :)

[flossy_cake]

Sorry to keep asking for things, but is there any possibility the Normalize (http://avisynth.nl/index.php/Normalize) filter could be modded to support Normalize2 (http://avisynth.nl/index.php/Normalize2)'s "store the peak level value in an external file and uses a lookup table to do the actual normalizing (for speed)"

:thanks:

[jpsdr]

I have to test and check something i just tought when back home.
If i remember properly, the officiel release of 3.7.2 have "big" files -> It's a clang build (and now i know why there was "big" file releases, and pinterf's "small" files releases before), and they worked for me. So i have to check fir the "if i remember properly", and if it's the case, find in the git the exact release point this was built with (maybe there is a point where there is a 3.7.2 tag), try to build myself with my current build process, and :
- If it works, it means the commit wich break things can be identified.
- If it doesn't work, it means that it's the llvm version, an old one worked, not a current one.

Edit:
Don't have to wait...

Is the AviSynthPlus_3.7.2_20220317-filesonly.7z found here https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.2 build with clang/llvm ? Files are big enough for, but not sure...

[pinterf]

Is the AviSynthPlus_3.7.2_20220317-filesonly.7z found here https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.2 build with clang/llvm ? Files are big enough for, but not sure...
Size can be bigger, it may contain debug info and labels, despite being a release version.

[pinterf]

And now let's experiment a bit

Avisynth+ 3.7.3 test 9 (20230316 - r3961) (https://drive.google.com/uc?export=download&id=1xFMgLh5lh6kmKPxT5lYGZbpVVBkLyxiK)


20230316 3.7.3 WIP
------------------
- Add initial audio channel mask support (CPP and C interface, script function)
It still belongs to V10 changes (there were only tests since then), but it can be discussed if not.
Technically it is done by using another 18+2 bits in the Clip's VideoInfo.image_type field.
Due to lack of enough bits in this VideoInfo field, the mapping between the original dwChannelMask
and Avisynth's internal values are not 1:1, but all information is kept however.
This is because not 32 but only 18 (strictly: 18+1) bits are defining speaker locations, so
the remaining bits of our existing 'image_type' field can be used for this purpose.
Thus 20 new bits are occupied.
- 1 bit: marks if channel mask is valid or not
- 18 bits for the actually defined WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions
(https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatextensible)
- 1 bit for the special SPEAKER_ALL value

Programmers can check AvsChannelMask and AvsImageTypeFlags in avisynth.h and avisynth_c.h

- new C++ interface functions
- Check for existence:
bool VideoInfo::IsChannelMaskKnown()
- Setting:
void VideoInfo::SetChannelMask(bool isChannelMaskKnown, unsigned int dwChannelMask)
Re-maps and stores channel mask into image_type, sets the 'has channel mask' flag as well
Note: this data can be set independently from the actual NumChannels number!
- Retrieving:
unsigned int VideoInfo::GetChannelMask()

- new C interface functions
bool avs_is_channel_mask_known(const AVS_VideoInfo * p);
void avs_set_channel_mask(const AVS_VideoInfo * p, bool isChannelMaskKnown, unsigned int dwChannelMask);
unsigned int avs_get_channel_mask(const AVS_VideoInfo * p);

Like when establishing BFF, TFF and fieldbased flags from 'image_type', technically 'image_type' can
be manipulated directly. See SetChannelMask and GetChannelMask in Avisynth source for
image_type <-> dwChannelMask conversion.

I guess once ffmpeg will support it, it will read (or not read) channel masks such a way.

- new Script functions
bool IsChannelMaskKnown(clip)
int GetChannelMask(clip)
SetChannelMask(clip, bool known, int dwChannelMask) (parameters compulsory, no names must be set)
dwChannelMask must contain the combination of up to 18 positions or 0x80000000 for SPEAKER_ALL.

VfW export rules (included the existing sequence)
1.) OPT_UseWaveExtensible global variable must be 'true'
or
*new*new*new*
if VideoInfo::IsChannelMaskKnown is true, then fill WAVEFORMATEXTENSIBLE struct
2.) *new*new*new*
Is channel mask defined in Avisynth's VideoInfo? (VideoInfo::IsChannelMaskKnown() is true)
Yes -> return VideoInfo::GetChannelMask()
3.) No-> (Channel mask not defined in VideoInfo, guess it or set from variable)
3.1)Guess channel layout:
For 0 to 8 channels there is a predefined 'guess map':
#of channels dwChannelMask
0 0,
1 0x00004, // 1 -- -- Cf
2 0x00003, // 2 Lf Rf
3 0x00007, // 3 Lf Rf Cf
4 0x00033, // 4 Lf Rf -- -- Lr Rr
5 0x00037, // 5 Lf Rf Cf -- Lr Rr
6 0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
7 0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
8 0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs

For 9-18 channels:
sets first 9-18 bits in dwChannelMask
Above:
SPEAKER_ALL (dword msb bit is 1)
3.2) if OPT_dwChannelMask global variable is defined and is different from 0, then use it.

E.g. VirtualDub2 is using VfW, so after opening the script, ended with SetChannelMask(true, $0063F),
one can check the value File|File Info menü, under "compression" line (e.g.PCM, chmask 63f).
SetChannels does not check against NumChannels, so you can set the 7.1 constant for a stereo
if you wish. Microsoft's documentation mentions the cases of what can do az application with
less or more than necessary defined speaker bits.

- What to do about GetChannels, MixAudio, ConvertToMono? To be discussed.
KillAudio will call SetChannelMask(false, 0), nevertheless.

[tebasuna51]

Thanks for the audio improvement.
Now decoders must suply that info or we can use the exported variables?

About defaults please use a modern one (and more ffmpeg compatible) showed here (https://forum.doom9.org/showthread.php?p=1984523#post1984523).

[FranceBB]

Thanks for the audio improvement.


+1
Thanks for the new release, Ferenc!
It's always nice to see the audio getting its well deserved space after spending so much time on video. :)

Oh and by the way, 3.7.3 test 9 also works on Windows XP just fine, I just tested it before going to bed. (yep it's 1AM over here, ehehehehe).
Tomorrow I'll test on the Windows Server 2019 farm I have at work too. ;)

[jpsdr]

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.

[pinterf]

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.
As Intel say: "may or may not work".
"Note: These OS distributions are tested by Intel or known to work; other distributions may or may not work and are not recommended."

[pinterf]

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.
Or related to your machine.

I've freshly installed a Win7 Pro x64 (ISO from 2018) under HyperV VM.
Downloaded official Avisynth+ 3.7.2 (with redistributables)
Copied there latest VirtualDub2, avsmeter and avsmeter64, ffmpeg.

Everything worked. My clang and intel from 3.7.3 test7, latest uvz builds, my freshly compiled clang-cl.

Then installed the latest Visual C++ Redistributables. Same success.

[DTL]

Yes - it looks clang uses some >SSE instructions. The VirtualDub loaded via SDE emulator

set PATH=%PATH%;G:\sde
sde.exe -avx 1 -avx2 1 -emu_fast 1 -fma 1 -sse41 1 -- G:\Distr\VirtualDub-1.10.4-AMD64\veedub64.exe

can load script with x64-clang AVS+ 3.7.3 test7. Slow enough but working. So if it possible to disable AVX and higher usage in clang (also IntelClassic must have switches for it).

May be clang and llvm so visibly faster because they finally start to make use of registerfile of SIMD coprocessor for temporals and function arguments instead of pushing to stack and so on. But old chips do not have registerfile of required size (as AVX it is 256 bytes) and instructions to store and load data from it. So new clang and llvm no more compatible with SSE architecture chips ?

[pinterf]

Yes - it looks clang uses some >SSE instructions. The VirtualDub loaded via SDE emulator

set PATH=%PATH%;G:\sde
sde.exe -avx 1 -avx2 1 -emu_fast 1 -fma 1 -sse41 1 -- G:\Distr\VirtualDub-1.10.4-AMD64\veedub64.exe

can load script with x64-clang AVS+ 3.7.3 test7. Slow enough but working. So if it possible to disable AVX and higher usage in clang (also IntelClassic must have switches for it).

May be clang and llvm so visibly faster because they finally start to make use of registerfile of SIMD coprocessor for temporals and function arguments instead of pushing to stack and so on. But old chips do not have registerfile of required size (as AVX it is 256 bytes) and instructions to store and load data from it. So new clang and llvm no more compatible with SSE architecture chips ?

I doubt they are incompatible by design. I wonder, that the illegal instruction come from Avisynth code or somewhere from the library. I know that some of my plugins require sse4.1 when compiled with clang. (Where it would be too painful to separate SSE2 and SSE4.1 code to put them into different functions with different pragmas), while with MS I could do it simply by templates.

[pinterf]

Check cmakelist.txt. I think sse4.1 is set as the minimum for llvm compilation.

[DTL]

Unfortunately VS2019 debugger not break on the Illegal Istruction exception in AVS (or I still not know how to configure it to break and show disassembly). But my Core2Duo E7500 CPU do have MMX, SSE, SSE2, SSE3, SSSE3, SSE 4.1, EM64T, VT-x and still invalid instruction crash with that builds without SDE emulating up to AVX2.

It definitely something around AVX/2 :
Disabling AVX and AVX2 emulation
sde.exe -avx 0 -avx2 0 -- G:\Distr\VirtualDub-1.10.4-AMD64\veedub64.exe

cause crash with x64_clang build:
Illegal instruction at address = 7fed7947e0a: c5 fc 10 05 9e 17 19 00 c5 fc 11 05 e6 b4 24
Image name: C:\Windows\system32\AviSynth.dll
Offset in image: 0x4a7e0a

IDA shows at disassembly:
.text:00000001804A7E0A vmovups ymm0, cs:ymmword_1806395B0 - it is AVX or AVX2 instruction.

Same as VS2019 debug output : Exception thrown at 0x000007FEC4FF7E0A (AviSynth.dll) in Veedub64.exe: 0xC000001D: Illegal Instruction.
7E0A address from some page offset ?

[jpsdr]

My quick test PC hasn't AVX, but has SSE4.2. Never tested on my dedicated video processing PC (as it didn't work on quick test), which has AVX2.
I'll test again, but on my Video PC.
Is it possible that despite compile option clang still puts AVX/AVX2 when it shouldn't ? Or some intrinsic code with AVX/AVX2 is in some place it doesn't belong ? Because that's strange that both Intel and clang produce the same result.
Now Visual Studio has allready changed things without telling (the example is the bug in non aligned for AVISource, where VS compiled a not aligned when the code asked for aligned).

[DTL]

Or some intrinsic code with AVX/AVX2 is in some place it doesn't belong ?

IDA disassembly for clang build shows not anything looking like human-handcrafted program:

sub_1804A7E00 proc near
mov cs:dword_1806F32F0, 10100h
vmovups ymm0, cs:ymmword_1806395B0 < -- crash
vmovups cs:ymmword_1806F3300, ymm0
mov cs:dword_1806F3320, 1030200h
vmovups ymm0, cs:ymmword_1806395D0
vmovups cs:ymmword_1806F3330, ymm0
vmovaps xmm0, cs:xmmword_18052C510
vmovaps cs:xmmword_1806F3350, xmm0
vmovups ymm0, cs:ymmword_1806395F0
vmovups cs:ymmword_1806F3360, ymm0
vmovups ymm0, cs:ymmword_180639610
vmovups cs:ymmword_1806F3380, ymm0
vmovaps xmm0, cs:xmmword_18052C520
vmovaps cs:xmmword_1806F33A0, xmm0
vmovups ymm0, cs:ymmword_180639630
vmovups cs:ymmword_1806F33B0, ymm0
vmovups ymm0, cs:ymmword_180639650
vmovups cs:ymmword_1806F33D0, ymm0
vmovups ymm0, cs:ymmword_180639690
vmovups cs:ymmword_1806F3410, ymm0
vmovups ymm0, cs:ymmword_180639670
vmovups cs:ymmword_1806F33F0, ymm0
vmovups ymm0, cs:ymmword_180639710
vmovups cs:ymmword_1806F3490, ymm0
vmovups ymm0, cs:ymmword_1806396F0
vmovups cs:ymmword_1806F3470, ymm0
vmovups ymm0, cs:ymmword_1806396D0
vmovups cs:ymmword_1806F3450, ymm0
vmovups ymm0, cs:ymmword_1806396B0
vmovups cs:ymmword_1806F3430, ymm0

and so on. It looks like compiler generated block.

[pinterf]

It's an unrolled loop doing memcpy.
Fortunately I have a non-avx machine at home.

[DTL]

It is doing memcpy of large enough block. Typical universal memcpy must support from 1 byte to any ?

[jpsdr]

Tested on my Video PC with AVX2 (and Windows 7), my llvm build works.

[DTL]

So do llvm build environment have some settings to force disable emitting AVX and later instructions ? Or these builds can be only marked as AVX(2) minimum ?

Users may still have some second-hand multicore multi-chips Xeons systems capable of AVS processing but noAVX even.

[pinterf]

It is doing memcpy of large enough block. Typical universal memcpy must support from 1 byte to any ?
It is optimized, prechecking the data, then automatically handling multiple processor path, small block, aligned block, large block, overlaps, small one, usually inlined, different technique when amount is known; both MS and LLVM do it.

[pinterf]

Finally, in 37 minutes from switching on, my PC has happily loaded avs+ source. OMG, so slow, I've got no SSD in this machine.
Intel(R) Core(TM) i7 860, it has SSE4.1 at most.
This PC features with a VS 2019 with LLVM 12.0. Made a debug build. Run it. No problem :(

[pinterf]

So do llvm build environment have some settings to force disable emitting AVX and later instructions ? Or these builds can be only marked as AVX(2) minimum ?

Users may still have some second-hand multicore multi-chips Xeons systems capable of AVS processing but noAVX even.
Yep, use MSVC build. Simple as that. Maybe it is even quicker than llvm, llvm alone is not a magic wand.
(but the problem is interesting, very interesting, I can say. And may have other reasons, this is why I put in days to investigate)

[pinterf]

Ehh...

First of all, this slow machine makes me mad. 13 minutes for a simple cmake install. 17 minutes after starting VS2022 until Avisynth project is loaded. But then! BUT THEN! :)

Debug build was not failing.
Release with debug build did it. Yeah.

Strange.

It would really run avx code on my pre-avx machine.
This is what happened.

convert_bits_avx2.cpp includes "convert_bits.h"
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_bits_avx2.cpp#L54

convert_bits.h contains static initialization of the dither structures:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_bits.h#L89

like this:

// repeated 8x for sse size 16
static const struct dither2x2a_t
{
const BYTE data[4] = {
0, 1,
1, 0,
};
// cycle: 2
alignas(16) const BYTE data_sse2[2 * 16] = {
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0
};
dither2x2a_t() {};
} dither2x2a;
The illegal instruction came from
dither2x2a_t() {}
which triggered the static initialization.

Unfortunately, this initialization was requested from an AVX2 module.

Though the failure happened at the first struct initialization, there are other predefined dither structs, they would all fail as well:

I'm going to stop putting such active codes into common header files. They must be moved out to a hpp and be included into both the _sse2 and the _avx2 source. I wonder what happens if I do that change. Will it recognise that the static initialization of an AVX2 compiled code is forbidden?

Disassembly - for the records.

AviSynth.dll!_GLOBAL__sub_I_convert_bits_avx2.cpp(void):
00007FFBF987F4E0 mov dword ptr [dither2x2a (07FFBF9B03620h)],10100h
00007FFBF987F4EA vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+10h (07FFBF9A3CF60h)]
00007FFBF987F4F2 vmovups ymmword ptr [dither2x2a+10h (07FFBF9B03630h)],ymm0
00007FFBF987F4FA mov dword ptr [dither2x2 (07FFBF9B03650h)],1030200h
00007FFBF987F504 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+30h (07FFBF9A3CF80h)]
00007FFBF987F50C vmovups ymmword ptr [dither2x2+10h (07FFBF9B03660h)],ymm0
00007FFBF987F514 vmovaps xmm0,xmmword ptr [__xmm@02060307040005010307020605010400 (07FFBF991D470h)]
00007FFBF987F51C vmovaps xmmword ptr [dither4x4a (07FFBF9B03680h)],xmm0
00007FFBF987F524 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+50h (07FFBF9A3CFA0h)]
00007FFBF987F52C vmovups ymmword ptr [dither4x4a+10h (07FFBF9B03690h)],ymm0
00007FFBF987F534 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+70h (07FFBF9A3CFC0h)]
00007FFBF987F53C vmovups ymmword ptr [dither4x4a+30h (07FFBF9B036B0h)],ymm0
00007FFBF987F544 vmovaps xmm0,xmmword ptr [__xmm@050d070f09010b03060e040c0a020800 (07FFBF991D480h)]
00007FFBF987F54C vmovaps xmmword ptr [dither4x4 (07FFBF9B036D0h)],xmm0
00007FFBF987F554 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+90h (07FFBF9A3CFE0h)]
00007FFBF987F55C vmovups ymmword ptr [dither4x4+10h (07FFBF9B036E0h)],ymm0
00007FFBF987F564 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0B0h (07FFBF9A3D000h)]
00007FFBF987F56C vmovups ymmword ptr [dither4x4+30h (07FFBF9B03700h)],ymm0
00007FFBF987F574 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0F0h (07FFBF9A3D040h)]
00007FFBF987F57C vmovups ymmword ptr [dither8x8a+20h (07FFBF9B03740h)],ymm0
00007FFBF987F584 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0D0h (07FFBF9A3D020h)]
00007FFBF987F58C vmovups ymmword ptr [dither8x8a (07FFBF9B03720h)],ymm0
00007FFBF987F594 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+170h (07FFBF9A3D0C0h)]
00007FFBF987F59C vmovups ymmword ptr [dither8x8a+0A0h (07FFBF9B037C0h)],ymm0
00007FFBF987F5A4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+150h (07FFBF9A3D0A0h)]
00007FFBF987F5AC vmovups ymmword ptr [dither8x8a+80h (07FFBF9B037A0h)],ymm0
00007FFBF987F5B4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+130h (07FFBF9A3D080h)]
00007FFBF987F5BC vmovups ymmword ptr [dither8x8a+60h (07FFBF9B03780h)],ymm0
00007FFBF987F5C4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+110h (07FFBF9A3D060h)]
00007FFBF987F5CC vmovups ymmword ptr [dither8x8a+40h (07FFBF9B03760h)],ymm0
00007FFBF987F5D4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+190h (07FFBF9A3D0E0h)]
00007FFBF987F5DC vmovups ymmword ptr [dither8x8 (07FFBF9B037E0h)],ymm0
00007FFBF987F5E4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1B0h (07FFBF9A3D100h)]
00007FFBF987F5EC vmovups ymmword ptr [dither8x8+20h (07FFBF9B03800h)],ymm0
00007FFBF987F5F4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1D0h (07FFBF9A3D120h)]
00007FFBF987F5FC vmovups ymmword ptr [dither8x8+40h (07FFBF9B03820h)],ymm0
00007FFBF987F604 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1F0h (07FFBF9A3D140h)]
00007FFBF987F60C vmovups ymmword ptr [dither8x8+60h (07FFBF9B03840h)],ymm0
00007FFBF987F614 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+210h (07FFBF9A3D160h)]
00007FFBF987F61C vmovups ymmword ptr [dither8x8+80h (07FFBF9B03860h)],ymm0
00007FFBF987F624 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+230h (07FFBF9A3D180h)]
00007FFBF987F62C vmovups ymmword ptr [dither8x8+0A0h (07FFBF9B03880h)],ymm0
00007FFBF987F634 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+330h (07FFBF9A3D280h)]
00007FFBF987F63C vmovups ymmword ptr [dither16x16a+0E0h (07FFBF9B03980h)],ymm0
00007FFBF987F644 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+310h (07FFBF9A3D260h)]
00007FFBF987F64C vmovups ymmword ptr [dither16x16a+0C0h (07FFBF9B03960h)],ymm0
00007FFBF987F654 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2F0h (07FFBF9A3D240h)]
00007FFBF987F65C vmovups ymmword ptr [dither16x16a+0A0h (07FFBF9B03940h)],ymm0
00007FFBF987F664 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2D0h (07FFBF9A3D220h)]
00007FFBF987F66C vmovups ymmword ptr [dither16x16a+80h (07FFBF9B03920h)],ymm0
00007FFBF987F674 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2B0h (07FFBF9A3D200h)]
00007FFBF987F67C vmovups ymmword ptr [dither16x16a+60h (07FFBF9B03900h)],ymm0
00007FFBF987F684 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+290h (07FFBF9A3D1E0h)]
00007FFBF987F68C vmovups ymmword ptr [dither16x16a+40h (07FFBF9B038E0h)],ymm0
00007FFBF987F694 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+270h (07FFBF9A3D1C0h)]
00007FFBF987F69C vmovups ymmword ptr [dither16x16a+20h (07FFBF9B038C0h)],ymm0
00007FFBF987F6A4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+250h (07FFBF9A3D1A0h)]
00007FFBF987F6AC vmovups ymmword ptr [dither16x16a (07FFBF9B038A0h)],ymm0
00007FFBF987F6B4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+430h (07FFBF9A3D380h)]
00007FFBF987F6BC vmovups ymmword ptr [dither16x16+0E0h (07FFBF9B03A80h)],ymm0
00007FFBF987F6C4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+410h (07FFBF9A3D360h)]
00007FFBF987F6CC vmovups ymmword ptr [dither16x16+0C0h (07FFBF9B03A60h)],ymm0
00007FFBF987F6D4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3F0h (07FFBF9A3D340h)]
00007FFBF987F6DC vmovups ymmword ptr [dither16x16+0A0h (07FFBF9B03A40h)],ymm0
00007FFBF987F6E4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3D0h (07FFBF9A3D320h)]
00007FFBF987F6EC vmovups ymmword ptr [dither16x16+80h (07FFBF9B03A20h)],ymm0
00007FFBF987F6F4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3B0h (07FFBF9A3D300h)]
00007FFBF987F6FC vmovups ymmword ptr [dither16x16+60h (07FFBF9B03A00h)],ymm0
00007FFBF987F704 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+390h (07FFBF9A3D2E0h)]
00007FFBF987F70C vmovups ymmword ptr [dither16x16+40h (07FFBF9B039E0h)],ymm0
00007FFBF987F714 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+370h (07FFBF9A3D2C0h)]
00007FFBF987F71C vmovups ymmword ptr [dither16x16+20h (07FFBF9B039C0h)],ymm0
00007FFBF987F724 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+350h (07FFBF9A3D2A0h)]
00007FFBF987F72C vmovups ymmword ptr [dither16x16 (07FFBF9B039A0h)],ymm0
00007FFBF987F734 vzeroupper
00007FFBF987F737 ret

Eh.. I'm gonna finally sleep well at least. I'll return to it next week.

[LigH]

@DTL: If you had wrapped these lists in a bbCode CODE block, it would have taken less space in scrollable boxes.
_

Oops, missed another page of replies, sorry.

[jpsdr]

@pinterf
Nice you find something, good work as always, :thanks:
Out of curiosity, if you have any idea why Visual Studio build are working but not the others... If you don't, no big deal, at least there is something, and it's in the code, so the "rare bug" case, not compiler related. Means it's eventualy fixable.

[DTL]

I delete that posts as found better way of error reporting via SDE crash log.

[FranceBB]

eheheheh I knew there must have been something else there.

Very nicely spotted, Ferenc!
You're the "Avisynth Grandmaster" after all. :)

[qyot27]

@pinterf
Nice you find something, good work as always, :thanks:
Out of curiosity, if you have any idea why Visual Studio build are working but not the others... If you don't, no big deal, at least there is something, and it's in the code, so the "rare bug" case, not compiler related. Means it's eventualy fixable.
Judging by some of the replies, there are/were functions in headers and the process dispatching that were getting dinged by LLVM and not by MSVC because of the difference* in the way GCC/Clang (and presumably Intel now too, since it uses LLVM) and CL handle enabling intrinsics. And this was causing AVX instructions to be emitted for sources that it shouldn't have been generated for.

That's probably the simplest explanation.

*a very long-lived known difference that makes GCC very annoying when it comes to using intrinsics and runtime CPU detection and how one has to build the sources. (https://virtualdub.org/blog2/entry_363.html) This is the reason that there's an entire block in avs_core/CMakeLists.txt (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/CMakeLists.txt#L45) doing exactly what was described there: keeping separate sources for intrinsics-using code, and then using the build system to slice GCC's and LLVM's intrinsics flags down to just those files that require them to even compile and try to keep them separate from all of the other files in the sources so that it doesn't globally optimize non-intrinsics code for the most recent instruction set and bork the entire purpose of having runtime CPU detection.

(although since the SSE paths were templated a while back, those blocks probably need to be cleaned up since there are no files that would match the query for *_ssse3.cpp or *_sse41.cpp)

I doubt that the builds that crash on non-AVX machines could be made to work with the script declaring SetMaxCPU, but if building with GCC, Clang, or Intel, you would almost certainly be able to see it start working if you turn off SIMD entirely (-DENABLE_INTEL_SIMD:bool=off) and just use the appropriate -march flag in -DCMAKE_CXX_FLAGS to globally optimize for your particular CPU. Probably would take a pretty big theoretical** performance hit, but still.

**theoretical, because on non-x86 CPUs (like the IBM 970MP, ARM Cortex A72, or Apple M1), the core still works fairly well, at least on synthetic tests. It's just that on x86, those same tests get just absolutely stupid numbers because of the intrinsics. Almost comprehensibly meaningless numbers in some cases (Version getting north of 32000 fps vs a much more 'I can understand this' 2000-8000 fps range on the M1 or on a 9th Gen Core i5 with SetMaxCPU("None")). But if a large amount of the testing is on external plugins and not using much or any core functions, it's questionable whether you might see a performance hit at all, or if the thing for 'normal' core use that makes the most difference is not the intrinsics in all of the filters you may never use, but because of the use of the x86-optimized memcpy or bitblt. And just how much of it is down to non-SIMD-related compiler optimizations. I've not tried to do a '-march=native -O3' build on x86 that also has the intrinsics disabled, but that might be pretty enlightening.

[pinterf]

A theoretical fix is up on git, along with

https://github.com/AviSynth/AviSynthPlus/issues/347

Finally I think, this is not the compiler's fault.

Programmers must really take care of statically initialized tables in classes (and not use them) which would occur in other than the base CPU-arch modules.

[jpsdr]

I've made an LLVM build of r3966 and tested, it works.

:thanks:

[kedautinh12]

AviSynthPlus r3973
https://gitlab.com/uvz/AviSynthPlus-Builds

[real.finder]

with yv411 source using LWLibavVideoSource or ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

https://i.postimg.cc/hvK2ZK7b/Untitled.png (https://postimages.org/)

[pinterf]

with yv411 source using LWLibavVideoSource of ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

https://i.postimg.cc/hvK2ZK7b/Untitled.png (https://postimages.org/)
Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

[real.finder]

Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"

[FranceBB]

Avisynth 3.7.3 Beta 9, using the following script:


BlankClip(length=0)


makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():

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

Given that using BlankClip(length=1) produces 1 frame of black, namely frame 0:

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

what is BlankClip(length=0) supposed to output? And why is it making FFMpeg go on forever and AVSPmod mod fail?
I even tried with VirtualDub, it doesn't fail, and although the preview is bogus like this:

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

it does produce a file which is 1 frame long (frame 0) of pure black when I play it back with MPC-HC:

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

I reported the issue to the ffmpeg community, but the more I test the more I think that we (the Avisynth community) might be the one at fault here.
I'm not sure. What do you think, guys?

[poisondeathray]

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"

[qyot27]

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"
This. FFmpeg reads video and audio packets separately, and if either reaches EOF, it attempts to read the other one before exiting, because it is easily possible - and not a bug - that either video or audio might be longer than the other, and it shouldn't be truncated.

The error is that length=0 is treated by BlankClip as somehow valid when it isn't, and ends up creating an audio stream of infinite length, which FFmpeg then attempts to read/output. Forcing an output length via the -t parameter would probably demonstrate that it is indeed attempting to write an ever-increasing number of audio samples, until the process is killed.

[FranceBB]

Gotcha.
So... what next? I think we should be throwing an error and display it correctly as an error if length=0 is passed to BlankClip() instead of failing silently.

The good thing is that a new version of Avisynth is being worked on, so perhaps we can include this in 3.7.3 Beta 10 (or one of the next betas before the stable release)?

Anyway, it's just a proposition as I've addressed it in the code at work last Sunday (yes, I rushed to work on Sunday when I saw the server crash eheheheheh). Anyway, as far as my use case is concerned, now if there's a clip of 0 frame, length is forced to 1 as one workaround in the AVS Script that my supply chain generates automatically (and I'll make sure to include the fix in the next public release of FFAStrans, if Steinar approves my pull request). :)

I'll let the ffmpeg guy know as well and close the ticket there anyway, since this is not a bug on their end. ;)

[gispos]

Avisynth 3.7.3 Beta 9, using the following script:



makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():

At first I was also surprised that no error 'Not a clip' is output, had to look 2 - 3 times to find the error. Fixed.

Edit:
Avisynth should have returned an error here, but probably does not.

self.src_frame = self.clip.get_frame(frame)
if self.clip.get_error():
Error()
return False

[qyot27]

Now it does:
https://github.com/AviSynth/AviSynthPlus/commit/9c79d295b6917741d99a26bb28eee829223d1d54

[qyot27]

To explain a bit further, I'm now not really sure if it was generating valid audio either, because if I tried to do
ffmpeg -i test.avs -vn -acodec copy output.wav
the output length reported before it errored out was something like -577100 hours. Which would indicate a problem with the integer used to represent the length of the stream. And the AviSynth docs have the following rather useful tidbit when describing audio samples properties:
Returns the number of samples of the audio of the clip (type: int). Be aware of possible overflow on very long clips (2^31 samples limit).
Which made me think there might be an overflow happening for the length of the clip, since 2^31 = 2,147,483,648 seconds / 60 = 35,791,394.133 minutes / 60 = 596,523.235 hours. Like I said, it's not exact (~577100 vs. 596523) but with other kinds of overhead, it's close enough. That may be a completely wrong assumption about what the issue actually was, but it doesn't really matter, since it will error out now if BlankClip is set to less than 1 frame long.

[FranceBB]

Thanks for the fix and the explanation, Stephen! ;)
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod :) )

[gispos]

...
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod :) )
You can also test it right now:)
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

[FranceBB]

You can also test it right now:)
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

It works and it correctly returns an error message. :)

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

While this outputted an image without asking any questions about the audio, just like before:

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

[gispos]

It works and it correctly returns an error message. :)

While this outputted an image without asking any questions about the audio, just like before:

If I understand correctly, that's so good ?
But it will probably change when avisynth gives an error on BlankClip(0). Then there is nothing I can do about it.

[FranceBB]

If I understand correctly, that's so good ?


It's fine, it's fine, thanks :)


But it will probably change when avisynth gives an error on BlankClip(0).

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg that takes my whole farm of several servers down and makes me rush back to the office after getting an incident on Spark and a phone call on a Sunday! XD

[gispos]

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg...
My mistake, I thought you use BlankClip(0) in the script for something.
At the second look I recognized it now... The script was only meant as an example... Sometimes it takes longer...:)

[DTL]

Some syntax request for some resizers:

Currently AVS resampling engine also used as convolution filter with resizer's kernel for non-resizing processing. So it required not very nice hacky way of forcing processing using non-zero src_left and/or src_top small float value. Also non-zero non-required shift may more degrade output.

So 2 ideas:
1. Add more param to resizers like force_processing (fp) = 0 (default - no), 1,2,3 (H, V, H+V), or horfp=false/true and verfp=false/true.

2. Add naming aliases with H(V) ending - like standard GaussResize and GaussResizeH/GaussResizeV/GaussResizeHV (conditionless forced H, V or HV processing). It looks like shortest way of script typing.

Mostly needed for resizers with user-adjustable kernel (taps or p or b,c params).

May be other ideas exist how to force resizer processing if width and height not changed ?

[pinterf]

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"
Opened an issue (https://github.com/AviSynth/AviSynthPlus/issues/350) at github, just for the reference. I had (and maybe will continue to have) busy working weeks, you'll notice a minor slowdown for some days.
Then I can finally have a look at DTL's (old and new) resizer related things.

[kedautinh12]

AviSynthPlus r3982
https://gitlab.com/uvz/AviSynthPlus-Builds

[DTL]

They not provide update log ? So it is not known what changed from old builds ? Do it equal to pinterf 3.7.3_test10 (some version of test10) ? Or some intermediate build before _test10 release ?

[kedautinh12]

They not provide update log ? So it is not known what changed from old builds ? Do it equal to pinterf 3.7.3_test10 (some version of test10) ? Or some intermediate build before _test10 release ?
UVZ's build always up to date base changelog, somtime this build up to date than Pinterf's test build

[DTL]

I see the s-param for UD2 resize is added and working. There exist some addition to the current short documentation of this resizer:

In short description noted that increasing s-param value (over 2.0) decreases sharpness. After more research it was found effect is more complex:

1. Increasing s-value really depresses highest valid frequencies and it cause decreasing sharpness of the finest details. But in typical viewing conditions (about classic system-60 with 60 samples per degree of view) the finest details close to already invisible. So this effect is mostly visible if evaluate 200..400+% enlarged crops and it is not typical use cases of viewing natural images.

2. Increasing s-value cause significant amplification of 'medium' frequencies and it significantly add to real visible sharpness in typical viewing conditions. Also exist some current still non-perfectness of processing: with s>2.0 it started to show some more ringing and aliasing-like distortions at some test-patterns. But in natural imaging it may be still close to invisible issue. May be only 2 members of kernel is not enough to completely fix this issue.

So typically using s-value >2.0 not cause generally visible sharpness decreasing. For example for 2:1 downscale from sharp-video look/makeup to sharp-video look/makeup of 4K downscale to FullHD may be recommended b/c of 80/-20 and default s of about 2.3. With s of 2.0 the somehow comparable sharpness may be reached only with more extreme b/c values of about 70/-30.

[StainlessS]

This. FFmpeg reads video and audio packets separately, and if either reaches EOF, it attempts to read the other one before exiting, because it is easily possible - and not a bug - that either video or audio might be longer than the other, and it shouldn't be truncated.

The error is that length=0 is treated by BlankClip as somehow valid when it isn't, and ends up creating an audio stream of infinite length, which FFmpeg then attempts to read/output. Forcing an output length via the -t parameter would probably demonstrate that it is indeed attempting to write an ever-increasing number of audio samples, until the process is killed.

Now it does:
https://github.com/AviSynth/AviSynthPlus/commit/9c79d295b6917741d99a26bb28eee829223d1d54

env->ThrowError("BlankClip() length must be greater than 0 frames!");


Template=Colorbars()
EmptyClip=Template.BlankClip(Length=0)

Is quite often [EDIT: sometimes/seldom] used to create an empty clip from a template clip, with same properties as template.
I posted a script using that same method a few days ago.
Gavino was also fond of using that method. [EDIT: Methinks that he is the culprit that enticed me into doin' that there thing]

Not a Good idea to kill existing scripts by changing AVS+ functionality, it was implemented that way for good reason.

Wrong use of BlankClip(length=0) is the error.

EDIT: The script I posted a couple of days ago
Current_frame is not available outside of the runtime environment, and dont make much sense there either.
But, (probably not of use in required case) you can hack a one time use (on a single frame) just by setting
it to that frame number, eg


blankclip(length=100,pixel_type="YV12")
C = Last.BlankClip(length=0) # zero len clip, same characteristics as Last clip
For(n=0,FrameCount-1) {
current_frame = n # HACK for below AverageLuma
Y = AverageLuma # access frame n
T = Trim(n,-1)
T = T.Subtitle(String(n) + String(Y," : %f"),align=5)
C = C ++ T # add single frame n, to clip so far : EDIT: Would fail here on 1st iteration unless C = zero len clip, same characteristics as Last clip
}

C # Play C



I'm still using an older version Avs+, so works for me, I presume recent avs+ breaks above script and throws an error for Length=0.

[qyot27]

There happened to be some stuff concerning general timestamps/duration/framecount in FFmpeg during April (and coincidentally after the no zero-length clips commit on our side), and if I had to guess, those commits addressed this from FFmpeg's side without ever touching the AviSynth demuxer, since a reverted version of AviSynth+ no longer seems to trip anything with a script consisting of just BlankClip(length=0) (ffplay doesn't reject it as empty, but that's probably just ffplay being ffplay; it doesn't close regular videos when they finish).

So tentatively, it's been reverted. If it re-emerges, though, it will have to be addressed. Memory overflows are not something I'm willing to roll the dice with just because there's useful edge cases.

[StainlessS]

Memory overflows are not something I'm willing to roll the dice with just because there's useful edge cases.
I guess that there will be not that many scripts reliant upon c.BlankClip(Length=0),
and could be relatively easily scripted around as and when they arise.
[But, it was more useful than might at first appear]
Please do as you will.

[FranceBB]

Wait, so the error is reverted and Avisynth will still provide a clip with using BlankClip(Length=0), but now FFMpeg doesn't go on forever in the new version?

In the meantime, I addressed it in FFAStrans with:

;Check if the input is a 0 frame image and force blankclip to be at least 1 frame in length 'cause 0 would be infinity

If $i_src_vid_frames = 0 Then $i_src_vid_frames = 1

$s_avs_script &= 'audio_null = BlankClip(length=' & $i_src_vid_frames & ', width=' & $src.video.width & ', height=' & $src.video.height & ', color=$000000, channels=1, audio_rate=' & $i_PROC_AUD_SAMPLERATE & ', fps=' & $f_src_vid_fps & ')' & @CRLF

so that I won't be affected anyway.

[SkilledAbbot]

Hello Forum,

As you can see by my join date, I've been here a while but I am still a technewb. The test 9 version of AVS+ does not have an installer or instructions on how to set it up. It's been about 2 decades since I fiddled with encoding and Frameserving with AVS, and now its really lost on me.

I know I should add that dll somewhere in my windows folder, just not sure where.

Any help appreciated.

Cheers

[DTL]

Install any old version with installer to write win-registry values and replace avisynth.dll from old version to new in system32 windows folder (for x64).

[kedautinh12]

I think need replace both avisynth.dll and devil.dll

[FranceBB]

I think need replace both avisynth.dll and devil.dll

Correct, both avisynth.dll and devil.dll in System32.

For x86 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files\Avisynth+\plugins+

and swap the plugins from the x86 build


For x64 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x64 build

- Go to C:\Windows\SysWOW64

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins+

swap the plugins from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins64+

swap the plugins from the x64 build



As a bit of reference, in 64bit systems, system32 hosts the 64bit files, while the 32bit ones are emulated and reside in the SysWOW64 folder.
In 32bit systems, instead, system32 hosts the 32bit (x86) files.
A bit counterintuitive, I know, but blame Microsoft for that.

[pinterf]

I see the s-param for UD2 resize is added and working. There exist some addition to the current short documentation of this resizer:
[...]

Thanks, hopefully I'm gonna be back in May, we are in a race against time since weeks to beat a deadline to fulfill the informatic background for our dear goverment's sudden thoughts.

[SkilledAbbot]

Awesome! Exactly what I needed. Thank you!

That note at the end, too! ha!

Correct, both avisynth.dll and devil.dll in System32.

For x86 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files\Avisynth+\plugins+

and swap the plugins from the x86 build


For x64 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x64 build

- Go to C:\Windows\SysWOW64

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins+

swap the plugins from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins64+

swap the plugins from the x64 build



As a bit of reference, in 64bit systems, system32 hosts the 64bit files, while the 32bit ones are emulated and reside in the SysWOW64 folder.
In 32bit systems, instead, system32 hosts the 32bit (x86) files.
A bit counterintuitive, I know, but blame Microsoft for that.

[kedautinh12]

Awesome! Exactly what I needed. Thank you!

That note at the end, too! ha!

And here is latest ver not test 9
https://gitlab.com/uvz/AviSynthPlus-Builds

[Llawliet]

hi, What is the difference between Clang and IntelLLVM builds of AviSynthPlus?

[LigH]

Which compiler was used to build them. So, marginally, a bit of CPU optimization strategies.

[Llawliet]

Thanks. Considering a notebook, intel i5 4200u, 8gb ram ddr3, ssd sata III, windows 10 ltsc 2021 updated, is it appropriate to conclude that the IntelLLVM option would be generally more optimized than the Clang option for the aforementioned system?

[StainlessS]

Why not speed test them both yourself, you're likely to get a better answer using your own hardware.
(and a typical processing script, that you use, maybe test on 10 minutes clip)
Try with Grouch2004 AvsMeter.

Groucho's Avisynth Stuff:- https://forum.doom9.org/showthread.php?t=173259

[Llawliet]

Thanks, fair point, speed test in the end point of system is a really a helpful advice, it brings forth relevant statistical data at the very end, and using statistical knowledge and tools is possible reach miningful conclusion with good confidence interval

[StainlessS]

You might also find it usefull to do timing where encoding result to eg AVC or HEVC where timings will be much closer together due to encode overhead.

[Llawliet]

Nice point to check, thank you for your continued help

[kedautinh12]

L-SMASH-Works latest ver
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases
AviSynth: convert input filenames to UTF-8 (LWLibavVideo/AudioSource) (#30).
FFmpeg 41dd50a.
l-smash 2c0696c.
nv-codec-headers n12.0.16.0.
libxml2 v2.11.0.

[gispos]

Request to the Avisynth developers about ConvertToRGB32. Do you see a possibility to optimize the speed?
With a UHD video I get ~70 fps, after calling ConvertToRGB32 it's only ~28 fps.
With a 720 x 576 video I get ~2700 fps and after RGB conversion ~520 fps

It would be nice if the developers could squeeze out a few more fps.

[FranceBB]

Request to the Avisynth developers about ConvertToRGB32. Do you see a possibility to optimize the speed?
With a UHD video I get ~70 fps, after calling ConvertToRGB32 it's only ~28 fps.
With a 720 x 576 video I get ~2700 fps and after RGB conversion ~520 fps

It would be nice if the developers could squeeze out a few more fps.

Yeah, better performances would definitely be useful.
Out of curiosity, is your input Limited TV Range YUV?
I wonder if the speed penalty is because it's also converting the range from Limited to Full... Uhmmmmm

[kedautinh12]

Let's wait DTL explain it :D

[guest]

L-SMASH-Works latest ver
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

Errors

https://forum.doom9.org/showthread.php?p=1986659#post1986659

[StainlessS]

Request to the Avisynth developers about ConvertToRGB32. Do you see a possibility to optimize the speed?
With a UHD video I get ~70 fps, after calling ConvertToRGB32 it's only ~28 fps.
With a 720 x 576 video I get ~2700 fps and after RGB conversion ~520 fps

It would be nice if the developers could squeeze out a few more fps.

Well, this probably aint quite right but,
RGB32 is 32 bits per pixel,
YV12 is 12 bits per pixel.
32 / 12 = 2.666 {RGB has 2.666 times as many bits per pixel}
70fps / 2.666 = 26.25 FPS, {expected fps for RGB32}

So, maybe RGB32 processing not that bad really.

Somebody point out where I went wrong :)

EDIT: Also, the conversion itself adds another hit to speed.

[DTL]

It is right - if UHD in YV12 compressed format (2:1 to RGB24) it is about 2 times faster in memory transfer. RGB32 is even more slower. It is only issues of too slow memory subsystem of current computers. The actual computing dispatch ports at CPU core are fast enough. For 1 input frame and 1 output frame filter additional memory issues may be not applicable (though also possible at some chips).

In some future AVS core releases expected some more advanced protection from possible memory performance penalty after some redesign of virtual memory management - https://github.com/AviSynth/AviSynthPlus/issues/351 .

For possibly a bit better performance it may be recommended to use 'planar' RGB32 with separated planes. But memory performance at conversion from planar to interleaved and back is also not very good. Also high-quality decompression from YV12 to RGB may require many computing (up to Neural-Network AI-helpers) and may be really very slow. Because ugly old 4:2:x compression formats really lossy and makes irreversible damage to data - so only non-linear processing may somehow better recover from damaging errors.

[kedautinh12]

Errors

https://forum.doom9.org/showthread.php?p=1986659#post1986659

You need create issue to developer
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues

[guest]

You need create issue to developer
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues

Thanks, I went to that link location, and Asd-g had been notified with a comment about errors, and provided 2 test files...

So I will check these out tomorrow. :D

[gispos]

First of all, I'm not saying that Avisynth is too slow! 70 fps is delivered and ~29 fps remain after the RGB conversion.

Also ~29 fps remain after the routine has been run. But how was it run through.
A simple example is to copy a bitmap memory.
I can copy each pixel individually, which then takes double the time if the number of pixels is doubled.
Or I copy a whole ScanLine * height in a loop which is faster even with double pixel count.
Or I copy the entire memory in one go. Which is even faster.

Please do not misunderstand, this is just an example to show that a doubling of a thing does not necessarily lead to a doubling of time.
This is mainly to let StainlessS mathematical calculations come to nothing. Little fun, don't be angry. :)

I always thought that drawing the frame takes the most time, which turned out to be a mistake.
The drawing itself costs about 3-4 fps, the bottleneck is the conversion to RGB.

Whether it's RGB24 or 32 doesn't really matter, in my experience these are negligible time quantities.

I am currently experimenting with a Prefetch(2,2) after ConvertToRGB32. This brings almost 30% more speed with YV12, but with YUV444P10 it is only 2-3 fps.
I can still think of parameters "Threads" and "GPU", whether feasible...?

[DTL]

You can take PC/Windows profiling tools like freeware AMD uProf and try to see if you can find any significant hotspots (not with load from memory) or scalar processing at ConvertToRGB and present these findings to AVS core developers as nice to have/fix peformance feature.

Also as usual the shortest possible script to reproduce the issue is required.

[gispos]

Possibilities exist, but will be too much for me, would have to learn from scratch.
https://docs.nvidia.com/cuda/npp/index.html
https://docs.nvidia.com/cuda/npp/group__yuv420torgb.html

[DTL]

Uploading to and downloading from external to host CPU data computing accelerator is typicaly slow and costly. The only reason to use very powerful external data computing accelerator if it can provide some state_of_art 4:2:0 to 4:4:4 decoding (expected non-linear AI-driven and Machine Learning based). So user can upload 4:2:0 dataset to external accelerator and patiently wait for result ready to download.

Same as we have some examples of neural-network trained to fight fields-aliasing in interlaced content (NNEDI3 field vertical 2x upsampler as example) - it is possible to design good non-linear decoder of YUV420/422 to 4:4:4 to fight design bugs of very old and ugly 4:2:0/4:2:2 compression.

If NVIDIA can provide some nice 4:2:0 to RGB decoder - it can be implemented as an external plugin and tested for quality. Though it mostly probably will be limited to CUDA and NVIDIA vendor hardware only.

[gispos]

I know that moving the data back and forth takes most of the time, but the process itself takes almost none.
I read something about 1500 fps, but I don't know how the quality is.

Was at the beginning when I asked "if there could be improvements" also only picked up by me because I thought the function has been around for a long time,
maybe it was completely forgotten. And it could not hurt to draw attention to it.... :)

[DTL]

About current DDR SDRAM performance (typically something around 50 GB/s): 4K UHD frame is 8 Msamples x 4 bytes in RGB32 (in 8bit) is 32 Mbytes in size. 28 fps mean about 900 MB/s only. It looks really available some better performance (though test script still not known).

With test script

ColorBars(3840, 2160, pixel_type="YV12")
ConvertToRGB32()
Prefetch(6)


I got 136 fps at i5-9600K CPU. It is about 4.3 GB/s possible RAM store speed (not sure if AVSmeter really make store ?). Also if I count everything right. So for 50 GB/s possible peak store performance is about 1500 fps (but also something is required to readback for next operation and so on - so if store and load from RAM it may be about 500 fps max).

Attempt to cache read :

ColorBars(3840, 2160, pixel_type="YV12")
Trim(1,1)
Loop(1000)
ConvertToRGB32()
Prefetch(6)

Make about same fps so possibly ColorBars already calculated only once and read from AVS cache.

Caching output of ConvertToRGB322() with


ColorBars(3840, 2160, pixel_type="YV12")
ConvertToRGB32()
Trim(1,1)
Loop(10000000)
Prefetch(6)


AVSmeter display something about 320000 fps - so it looks not make store and only skip pointer to provided frame from AVS cache. So to measure performance of convert() it may be require some more complex script. It is strange but changing chromaresample from point to spline64 close to change nothing in performance of ConvertToRGB32().

Resize test :

ColorBars(1920, 1080, pixel_type="YV12")
BicubicResize(width*2, height*2)
Prefetch(6)


With same 4K size of 2 chroma planes shows about 640fps. May be really dematrix from YUV to RGB is not very good optimized to AVX2. My AMD uProf is broken (no sampling driver start) at work PC so I can not make profile at this system now.

At development PC profiling shows it uses partially SSE and partially AVX2 computing (AVS+ 3.7.3). So if put all to AVX2 (and AVX512) it can be somehow faster. Also about 20% of time in the vcruntime140 - do not know why it looks like uses some library C functions but it is AVX2 also. But as I see the developers resources are very small in 2023 and it unlikely someone will make dematrix on new AVX SIMD very fast.

Add: Some idea from Dogway: If internal ConvertToRGB32 is too slow and old - you may try avsresize plugin possibly also capable of convert to RGB32 ?

It looks only support planar RGB32 but runs about 2 times faster at my chip i5-9600K:

LoadPlugin("avsresize.dll")

ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8")

Prefetch(6)

About 250..260 fps. Though still not 500..600 fps as simple resize so dematrix calculation also takes some time and may be better opmitized too.

[StvG]

It looks only support planar RGB32 but runs about 2 times faster at my chip i5-9600K:

LoadPlugin("avsresize.dll")

ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8")

Prefetch(6)

About 250..260 fps. Though still not 500..600 fps as simple resize so dematrix calculation also takes some time and may be better opmitized too.

If you use use_props=0 you will get better fps:
LoadPlugin("avsresize.dll")

ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", use_props=0)

Prefetch(6)

[DTL]

Yes - with z_ConvertFormat(pixel_type="RGBAP8", use_props=0) it run at about 300 fps.

[gispos]

And how do I get a packed RGB out of it that I can move to a DIB?
That probably costs the time saved. Or not?

[StvG]

And how do I get a packed RGB out of it that I can move to a DIB?
That probably costs the time saved. Or not?


ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", use_props=0)
ConvertToRGB32()

[gispos]

ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", use_props=0)
ConvertToRGB32()

Well, with use_props=0 it will be 2-3 fps faster but the colors are off and without use_props=0 the colors are correct but the whole thing is then slower than a single ConvertToRGB32.
This is a dead end.

[DTL]

It looks you use very old CPU to process UHD fast enough. May be SSE only. Typically developers optimize for AVX2 or later because developer resources are more and more limited and make and debug 3 functions SSE/AVX/AVX512 is more time and low reason in 202x optimize for very limited SSE. Each SIMD family may require different function design to be max efficient so it is no good simply expand SSE to AVX/AVX512 in many cases.

Typically today chips at motion pictures computing are limited with very low host RAM speed (about 50..100 GB/s for 2..4 channels DDR4/DDR5).

Each AVX512 dispatch port can process 64bytes cacheline at single clock for many simple operations. So 3 GHz chip with 8 cores of 24 GHz effective x 64 bytes can produce 1500 GBytes/sec store stream. Not any possible to handle with poor DDR-SDRAM. Only new HBM RAM at special compute boards can reach about 2 TB/s at single board (old designs of Tesla A100 accelerator). New and future HBM RAM may provide something about 10 TB/s at enduser machine in 202x if everything will go fine enough.

[gispos]

It looks you use very old CPU to process UHD fast enough. May be SSE only. ....
You are right, my CPU is a bit older. i7 4770 K with 4 cores and 8 threads.

But AVX2 is available: Intel® SSE4.1, Intel® SSE4.2, Intel® AVX2
and with 3.9 GHz it is also not the slowest... at least I thought so far.

You wrote that you get 300 fps with your i5... I achieve just half ~160 fps. With what did you measure it?

Then it's about time for something new.

[StainlessS]

I think I read somewhere that early version of AVX2 (ie Gen 4, Haswell) was 'poorly implemented'.
Was not properly fixed till 1 or 2 generations later.

Could not find any reference to above prob on Wikipedia "Advanced Vector Extensions" page, maybe I imagined it.

EDIT: Back when I was looking for a 2nd user i7 machine, I had initially figured on a i7-4790(K),
but on reading about above, I dropped the idea and decided 6th Gen (skylake) or above only,
as it happens I got 8th Gen i7, with 6C/12T instead of 6th Gen 4C/8T.

For comparing 2 processors google eg

"i7-4790K" vs "i7-6700K"

https://www.google.co.uk/search?q=%22i7-4790K%22+vs+%22i7-6700K%22&iflsig=AOEireoAAAAAZFeiceXKk3yVs6ov-AmZEuB9uUTPb-FQ


"i7-4790K" vs "i7-8700K"

https://www.google.co.uk/search?q=%22i7-4790K%22+vs+%22i7-8700K%22&iflsig=AOEireoAAAAAZFejVlqp958dTYNrbEGw_JGC2uZCi4yR

Quoted processor names, else might list some comparisons for close but not exact cpu's you want to compare.

[Boulder]

The performance issue with AVX2 was in older Ryzens, it was not a true implementation but an emulated one. I think the 3000-series had a real AVX2 capability.

[DTL]

"i7 4770 K with 4 cores"

But it is only 4th generation intel Core. DDR3 RAM of 25 GB/s only max. Hyperthreading looks like no helps any at poor endusers chips at AVS processing. At expensive Xeons with much better memory controller and larger cache and more RAM channels it may add about 20%.

My example of 300-fps i5-9600K is 9th generation and 6 real cores and DDR4 RAM of 41 GB/s max.

I test with running script with AVSmeter64.

In 202x it is recommended something may be possible at endusers desktops like CPU with AVX512 and 4 channels of DDR5 (may be up to 200 GB/s). Mostly frequent at poor endusers market looks like non-AVX512 chip with only 2 channels of DDR5.

Good starter Workstation is today something about many cores (>10) Xeon with AVX512 all cores default and 4..6 channels of DDR4 at least. Top Xeons Platinum may reach 8..12 channels of DDR4. Possible new Xeons with 4..6 channels of DDR5 is better.

Well, with use_props=0 it will be 2-3 fps faster but the colors are off and without use_props=0 the colors are correct but the whole thing is then slower than a single ConvertToRGB32.


To get correct colours at YUV to RGB dematrix you need to provide correct matrix data to z_ConvertFormat (if you disable frame props - they can handle required metadata automatically).

See string colorspace_op = at http://avisynth.nl/index.php/Avsresize . It is required to set matS param at least properly.

[gispos]

Then I'll have to take a look. I also always pay attention to the TDP, my CPU has only 65 watts maximum. For heating the apartment I have a heater. :)

[VoodooFX]

What's the problem with the script below?

v=ColorBars.ConvertToYV12
c=v.ConvertToYV24.Crop(10,10,91,90)
v.Overlay(c,x=50,y=50)

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

Reading about Overlay (http://avisynth.nl/index.php/Overlay) I don't expect such error.

[kedautinh12]

In crop change number to multiple of 2

[VoodooFX]

In crop change number to multiple of 2
I'm not interested in that.

[kedautinh12]

I'm not interested in that.

please read Crop restrictions at here:
http://avisynth.nl/index.php/Crop

[poisondeathray]

please read Crop restrictions at here:
http://avisynth.nl/index.php/Crop

ConvertToYV24 for the overlay layer means 4:4:4. There are no crop restrictions for progressive video

I believe the old overlay behaviour was everything got converted to 4:4:4 internally...

Now
http://avisynth.nl/index.php/Overlay


bool use444 = true

AVS+ If set to false, Overlay uses conversionless mode where possible instead of going through YUV 4:4:4.

false when mode="blend", "luma" or "chroma and format is YUV420/YUV422 (YV12/YV16). Original format is kept throughout the whole process, no 4:4:4 conversion occurs.



But it's false, when format is YUV420 - Since base layer is 4:2:0 - it's correct behaviour according to documentation

So the answer is set use444=true , or ConvertToYV24 beforehand

v.Overlay(c,x=50,y=50, use444=true)

[VoodooFX]

please read Crop restrictions at here:
http://avisynth.nl/index.php/Crop

You should read them: "no restriction".

[VoodooFX]

@poisondeathray
Thanks, I didn't read "use444" section to the end, just saw "bool use444 = true", maybe it should be changed to something like "bool use444 = [adaptive]" in wiki.

[StvG]

Well, with use_props=0 it will be 2-3 fps faster but the colors are off and without use_props=0 the colors are correct but the whole thing is then slower than a single ConvertToRGB32.
This is a dead end.


ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", use_props=0, cpu_type="avx2")
ConvertToRGB32()
Trim(0, 1000)

~70fps (cpu freq AVX2@4400)



ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", use_props=0, cpu_type="avx512f")
ConvertToRGB32()
Trim(0, 1000)

~76fps (cpu freq AVX512@3800)



ColorBars(3840, 2160, pixel_type="YV12")
ConvertToRGB32()
Trim(0, 1000)

~54fps


Aboult colors off: as @DTL mentioned - you need to set every value for colorspace_op=x:x:x:x=>y:y:y:y and for chromaloc_op=x:y (for example, z_ConvertFormat(pixel_type="RGBAP8", colorspace_op="2020:2020:2020:l=>rgb:2020:2020:f", chromaloc_op="top_left=>left") otherwise using z_ConvertFormat(pixel_type="RGBAP8", use_props=0") will use default values (170m=>rgb).

[DTL]

"~76fps (cpu freq AVX512@3800)"

What AVX512 chip provide so poor fps ? Or it is single threaded compare ? If it is really dematrix math limited processing - it expected to have much more benefit from AVX512 over AVX2.

Also do different UV planes scaling engine can provide some quality/performance balance ? Default scaling engine is fastest possible ?

"ConvertToRGB32()
~54fps (cpu freq AVX512@3800)"

Do current AVS core really go to AVX512 at ConvertToRGB32 ?

[gispos]

Aboult colors off: as @DTL mentioned - you need to set every value for colorspace_op=x:x:x:x=>y:y:y:y and for chromaloc_op=x:y (for example, z_ConvertFormat(pixel_type="RGBAP8", colorspace_op="2020:2020:2020:l=>rgb:2020:2020:f", chromaloc_op="top_left=>left") otherwise using z_ConvertFormat(pixel_type="RGBAP8", use_props=0") will use default values (170m=>rgb).
Without prefetch I just reach 38 fps, with Prefetch(2) it is 78 fps, which is 14 fps faster than with a single ConvertToRGB and Prefetch(2).

ColorBars(3840, 2160, pixel_type="YV12")
z_ConvertFormat(pixel_type="RGBAP8", colorspace_op="709:709:709:l=>rgb:709:709:f", chromaloc_op="top_left=>left")
prefetch(2)
ConvertToRGB32()


But it's hard to convert the whole z_Format stuff into code.

To the YV24 discussion above:
I had not known that YV24 can be cropped without restriction.

[DTL]

"with Prefetch(2) it is 78 fps,"

For your 4 core CPU optimal prefetch may be 4 (may be try a bit higher to see if there will be any visible benefit from hyperthreading).

[StvG]

"~76fps (cpu freq AVX512@3800)"

What AVX512 chip provide so poor fps ? Or it is single threaded compare ?

The used scripts are posted - no prefetch.

Edit:
"ConvertToRGB32()
~54fps (cpu freq AVX512@3800)"

Do current AVS core really go to AVX512 at ConvertToRGB32 ?

No. It's typo.

[DTL]

I expect users always set Prefetch to optimal value for current CPU used. So it is no good to post any prefetch value because it may be not optimal for most users and can confuse some users. So the script only contain filtergraph and user need to set optimal prefetch manually for best performance.

[StvG]

Btw using Converttorgb32() only for planar->packed causes ~30% fps drop. It seems a lot at first look. I have to test with libp2p (https://github.com/sekrit-twc/libp2p).

[DTL]

"using Converttorgb32() only for planar->packed causes ~30% fps drop. It seems a lot at first look."

It may greatly depend on current hardware memory subsystem design and partially on memory management in application. Planar to packed uses 4 read memory streams and 1 write stream. 4 read streams possibly can not cause set-associative cache aliasing conditions even with bad virtual memory addresses mapping but there may be other (many be more rare) memory addressing issues. Also if there is no really nice memory controller used - the 4 read RAM streams may cause significant overhead on SDRAM pages switching and it may be no good hided with SDRAM banks scheduling. Best RAM performance at simple memory controller designs typically only at the 1 read/write stream or simply memcpy of large block of contigous virtual memory addresses. Many read streams may already stress the really slow RAM (and with very slow random access).

Also real test may be better to perform at real muiti-frame source so AVS core with quickly thrash all data from CPU cache to RAM and the RAM performance will limit more. With single frame source it may be cached in CPU and show significantly better result. The 4K YV12 frame only 12 MB in size (?) so at large-L2/L3 CPUs may be completely cached and 4streams read performance may be much better. Though as ConvertToRGB32 mostly possibly uses cached store it may also replace some source data from L2/L3 (if it is of < 44 MB in size).

To make better syntetic test may be some Colorbars + Animate + Trim_range + Loop required. To force AVS create some 4K frames sequence like 10 in RAM in AVS-cache so when cycling via 10 frames in a loop the host CPU will re-read source data from RAM as with typical content processing.

" I have to test with libp2p."

It looks only SSE max and also at https://github.com/sekrit-twc/libp2p/blob/5e65679ae54d0f9fa412ab36289eb2255e341625/simd/p2p_sse41.cpp#L69 uses not very nice cast of integer treated data to float domain simply to use MM_TRANSPOSE4_PS macro. The CPU allow to make such casting but there is a performance penalty (sort of because microcode reconfigure dispatch ports for float processing or even need to resend data to float dispatch ports from integer). So in the instruction sets typically available visually equal instructions for integer and float data domain operating with same sets of bits. It is directly to avoid penalty from jumping between integer and float domains.

May be it is required to make integer MM_TRANSPOSE macro and it can add to performance. The shufps() is our common lovely instruction at the old SSE-era and may be not have integer version in the SSE instruction set. But already SSE2 have pshufpd() instruction for 128i shuffle. So it is available in SSE4.1 version of program.

Also AVX2 and AVX512 with larger register file may allow to grab more data for transpose and make less read/write bus switching. AVX512 also have more nice instructions for data shuffling/permutation. AVX2 allow destination operand to be different from sources. So it looks very outdated library if it is SSE only.

As an example of somehow good optimized for AVX512 chip SIMD program you may look at the https://github.com/Asd-g/AviSynth-vsTTempSmooth/blob/master/src/vsTTempSmooth_AVX512.cpp - it not very nice in syntax using repeating blocks of text but I currently not know how to make shorter syntax to increase 'workunit size' for each SIMD pass and also use some superscalar capability when available (dispatch >1 instruction in parallel when free dispatch ports available and no data dependency exist). If you load too few data into AVX512 register file with many small sequential operations and process one by one small operations it can not reach its full performance and use superscalar way of computing when possible. The AVX/AVX512 processing like to process many data and make large blocks of data stream load/store (better of cacheline granularity and aligned).

I tried to look into https://github.com/sekrit-twc/zimg/blob/master/src/zimg/colorspace/x86/operation_impl_avx512.cpp part of zimg for example and found it looks like uses very small workunit size for AVX512 and may not allow chip to make several operations dispatch in parallel because typical computing is sequential. The 'superscalarity' is sort of additional level of multithreading at neibour instructions level (close to Hyperthreading but inside single logical thread) and it also adds to performance when used properly. It not only about equal instructions performance increase - sometime you can have 2 or even more separate computing threads dispatched at the same time as single thread if free dispatch ports avaialble.

[StvG]

Btw using Converttorgb32() only for planar->packed causes ~30% fps drop. It seems a lot at first look. I have to test with libp2p (https://github.com/sekrit-twc/libp2p).

No speed difference.

[DTL]

Hehe - it looks I understand why AVS core op
YV12 -> RGB32 with ConvertToRGB32() is not fully optimized:

The operation of
ColorBars(3840, 2160, pixel_type="YV12")
ConvertToRGB32()

Is equal in speed to

ColorBars(3840, 2160, pixel_type="YV12")
ConvertToYV24()
ConvertToRGB32()

So it looks very complex Convert() core functions is sometime a sequence of Convert() so make 2 or more close to full-frame RAM scan and so performance of YV12 -> ConvertToRGB32() is 2x slower in compare with BicubicResize of 2x size for UV planes. Also performance close to independent of resampler kernel (and support) used because memory transfer penalty is main limiting speed factor. Also it somehow visibly benefit from faster RAM hosts.

The really top performance YV12 to RGB32 SIMD function in single pass (3 RAM read streams and 1 write stream) is about the next:

1. Make stream reading of Y,U,V planes parts in cacheline granularity and alignment to fill about 1/4..1/3 of registerfile of SIMD co-processor (of 512 8-bit bytes for AVX_x64 and 2048 8-bit bytes for AVX512_x64). Cached or uncached read streaming - depend on use case and current host architecture. It is user-side performance tuning setting.
2. Make upsample 2x of U V planes in registerfile only (do not touch even L1D cache).
3. Make dematrix and interleaving in registerfile only (do not touch even L1D cache).
4. Prepare write stream of cacheline granularity and alignment and emit set of store instructions to flush prepared RGB32 dataset from registerfile to memory with single dataflow burst (of about 1/2 or more of registerfile sized). Using cached or uncached write streaming to host RAM - depend on use case and host architecture. It is user-side performance tuning setting.

It is really 'hardware ASIC programming' (using handcrafted asm or C-level instruments - from inline asm to intrinsics or VCL) - not some abstract C-program.

It require to develop special SIMD program for each SIMD family and bitdepth (if >8bit support required). With very limited number of AVS core developers it is unlikely and not frequent usage YV12->RGB32 (classic interleaved) may be rarely need in top performance implementation.
AVS is freeware amateur processing software - not professional for commertial datacenter so low performance not mean low money income.

Also the planar YUV to planar RGB possibly worst performance case because or 3 read streams and 3 separate write streams.

Also it looks some nice to have feature for all AVS core filters design to user-side performance tuning - add control of caching for reading and writing. So that user can select between cached or uncached read from host RAM and write-back or uncached store to host RAM. At the architectures where we have required CPU instructions.

[gispos]

"with Prefetch(2) it is 78 fps,"

For your 4 core CPU optimal prefetch may be 4 (may be try a bit higher to see if there will be any visible benefit from hyperthreading).
In the script I use Prefetch(4), the Prefetch(2) has its justification.
It is about drawing the video frame in AvsPmod, ConvertToRGB is the bottleneck.
The ConvertToRGB does not benefit from the prefetch that is present in the script, because it must be derived from the clip after the script.

So this is a bit experimental and also not optimal to add a prefetch after the ConvertToRGB. This can lead to a too high prefetch value (script prefetch + RGB conversion prefetch).
Therefore only the 2.

[DTL]

That looks sad but fmtc also not allow to to single pass 4:2:0 to RGB conversion (fmtc_matrix require 4:4:4 input). So it looks a task to developers if some interested still exist.

"It is about drawing the video frame in AvsPmod, ConvertToRGB is the bottleneck."

May be RGB24 is enough for preview ? It may run a bit faster RGB32.

Addition: Trying to make sample plugin for YV12 to RGB24 conversion I still stuck at the colorspace change at plugin output - how it is performed ?

Is it at GetFrame() or at plugin init somewhere ?

Trying to look into avsresize.cpp at https://github.com/TomArrow/avsresize/blob/master/avsresize/avsresize.cpp but still not understand where it is switched.

When trying to create new video frame with
vi.pixel_type = CS_BGR24;
PVideoFrame dst = env->NewVideoFrame(vi);

The dst returned as RGB24 line size but VirtualDub crash at load script and avsmeter still display it is YV12 colorformat (as input). So how to make different colorspace at plugin output ?

I see a few plugins make colorformat conversion so it not very easy to find sample to modify.

[StvG]

That looks sad but fmtc also not allow to to single pass 4:2:0 to RGB conversion (fmtc_matrix require 4:4:4 input). So it looks a task to developers if some interested still exist.

"It is about drawing the video frame in AvsPmod, ConvertToRGB is the bottleneck."

May be RGB24 is enough for preview ? It may run a bit faster RGB32.

Addition: Trying to make sample plugin for YV12 to RGB24 conversion I still stuck at the colorspace change at plugin output - how it is performed ?

Is it at GetFrame() or at plugin init somewhere ?

Trying to look into avsresize.cpp at https://github.com/TomArrow/avsresize/blob/master/avsresize/avsresize.cpp but still not understand where it is switched.

When trying to create new video frame with
vi.pixel_type = CS_BGR24;
PVideoFrame dst = env->NewVideoFrame(vi);

The dst returned as RGB24 line size but VirtualDub crash at load script and avsmeter still display it is YV12 colorformat (as input). So how to make different colorspace at plugin output ?

I see a few plugins make colorformat conversion so it not very easy to find sample to modify.

vi.pixel_type must be set in the constructor or in the "creater", not in GetFrame.

[gispos]

May be RGB24 is enough for preview ? It may run a bit faster RGB32.

For videos it is probably enough, only if someone uses the alpha channel then I would have to check that and fall back to RGB32.
I think that the difference is not so big that you should do without RGB32. But if it is really faster I can live with it.

But YV12 are normally HD videos, formats of 4K videos is actually what would be of interest.

I think that will be more complex than you estimated... Thanks anyway.

[FranceBB]

But YV12 are normally HD videos, formats of 4K videos is actually what would be of interest.

For consumers? Still 4:2:0, but 10bit instead of 8bit and with a different chroma location (top left, aka 4:2:0 type 2) than the default MPEG-2 one (left, aka 4:2:0 type 0).

[DTL]

Make some tech demo of YV12 to RGB (planar only for now, RGBP8) - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.1a . AVX2 only.

It sort of draft-preview quality (using sort of point-resize for UV upsampling and completely not-aware of 'chroma-location') and 265bit regs data shuffling is not completely debugged so columns are not arranged properly. Only should run on mod64 frame widths (1920 or 3840 is good) or will not process last non-mod64 columns. Playing with 64 YUV and RGB samples at once not very easy in debugging - to place everything in correct order over scanline.

For sort of point-resize of UV plane it uses 8bit unpack with itself (single instruction) for H-scale and for V-scale it make UV line doubling in load address advancing (so it is universal 4:2:2 and 4:2:0 to RGB convert engine). So UV upscaling takes close to minimal possible time in this example.

Also can use internal OpenMP (threads) param to check AVS MT vs internal MT (not yet tested at all).

It just some quick performance test of such approach. I not have AVX2 chip at home so can not run performance test, only check if it output something like RGB decoded frame in SDE and not crash with default 640,480 frame.

Expected script for performance test is:

LoadPlugin("DecodeYV12toRGB.dll")
ColorBars(3840, 2160, pixel_type="YV12")

DecodeYV12toRGB(threads=1)
Prefetch(N) # N is number of threads, or try internal OpenMP threads at filter.


Interleaving of 32samples R, G, B AVX registers into RGB24 (or RGB32 with empty alpha) will take some more design ideas how to make it any fast. So currently planar RGB wins for processing but create 3 different store streams into RAM (though total speed is comparable to RGB24 interleaved).

Interleaving of planar RGB into RGB24 of mod3 channels step may be so SIMD-unfriendly that it may be better to do RGB32 instead.

[VoodooFX]

Heads-up:
I encountered some bug creating "special effects" with that unofficial compile kedautinh12 is posting.
And some another with official avs. I need to remember what I was doing...

[guest]

Heads-up:
I encountered some bug creating "special effects" with that unofficial compile kedautinh12 is posting.
And some another with official avs. I need to remember what I was doing...

"unofficial compile" of what ??

[VoodooFX]

"unofficial compile" of what ??
AviSynth+

[gispos]

Make some tech demo of YV12 to RGB (planar only for now, RGBP8) - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.1a . AVX2 only.

It sort of draft-preview quality (using sort of point-resize for UV upsampling and completely not-aware of 'chroma-location') and 265bit regs data shuffling is not completely debugged so columns are not arranged properly. Only should run on mod64 frame widths (1920 or 3840 is good) or will not process last non-mod64 columns. Playing with 64 YUV and RGB samples at once not very easy in debugging - to place everything in correct order over scanline.

For sort of point-resize of UV plane it uses 8bit unpack with itself (single instruction) for H-scale and for V-scale it make UV line doubling in load address advancing (so it is universal 4:2:2 and 4:2:0 to RGB convert engine). So UV upscaling takes close to minimal possible time in this example.

Also can use internal OpenMP (threads) param to check AVS MT vs internal MT (not yet tested at all).

It just some quick performance test of such approach. I not have AVX2 chip at home so can not run performance test, only check if it output something like RGB decoded frame in SDE and not crash with default 640,480 frame.

Expected script for performance test is:

LoadPlugin("DecodeYV12toRGB.dll")
ColorBars(3840, 2160, pixel_type="YV12")

DecodeYV12toRGB(threads=1)
Prefetch(N) # N is number of threads, or try internal OpenMP threads at filter.


Interleaving of 32samples R, G, B AVX registers into RGB24 (or RGB32 with empty alpha) will take some more design ideas how to make it any fast. So currently planar RGB wins for processing but create 3 different store streams into RAM (though total speed is comparable to RGB24 interleaved).

Interleaving of planar RGB into RGB24 of mod3 channels step may be so SIMD-unfriendly that it may be better to do RGB32 instead.
It runs like a pig. (That's what they say in Germany):)

ConvertToRGB32() = ~35 fps

Your code and ConvertToRGB32() = ~116 fps
DecodeYV12toRGB(threads=1)
ConvertToRGB32()

All without prefetch, nice!

But, the picture is not clean, I have strong stripes.

https://i.postimg.cc/kXG2XDQd/Screenshot-4.jpg (https://postimg.cc/0bgkVkXt)

[gispos]

For consumers? Still 4:2:0, but 10bit instead of 8bit and with a different chroma location (top left, aka 4:2:0 type 2) than the default MPEG-2 one (left, aka 4:2:0 type 0).
Hmm... I have a lot of YUV422P10 lying around here. And after ConvertBits(8) it comes out YV16.

Consumer pfff :D

[DTL]

"the picture is not clean, I have strong stripes."

Yes - it is not finally debugged. It is only first tech demo to estimate performance of single pass processing. Also I got some ideas how to make output of RGB32 interleaved (sorry for our lovely RGB24 interleaved - it is really much more complex to design and debug). The AVX2 looks like not have dual-input permutes for 8bit bytes (also not have 8bit permutes at all - so accumulating of G and R after initial B-shuffling require permutes to temporal reg and masked blends to output) so it will be somehow slower in compare with our nice AVX512 instructions sets (having VBMI and VL families). Also AVX2 do not have dual-input permutes at all.

AVX512_VBMI have great _mm512_permutex2var_epi8 instruction for filling RGB32 output from planar RGB regs to whatever position required (without any temporals and masked blends). Also it is really 64-bytes all flat field to run at - not 2x128bit poor processing of AVX2 for lots of operations (so is the current bad running build require lots of debug between 2x128bit lanes operations of AVX2).

I like to have AVX512 chips only and forgot poorly designed AVX2 of semi-256bit real opeation. It is mostly dual-speed SSE2 2x128bit operation but not true 256bit.

[gispos]

I'm excited to see how it continues!

Where does this difference come from?
1920 x 1080 YUV422P10

ConvertToRGB32(matrix="Rec709")
~97 fps

ConvertBits(8)
ConvertToRGB32(matrix="Rec709")
~113 fps

I cannot see any difference in the quality.

[FranceBB]

Consumer pfff :D

LOL yeah TX Ready mezzanine files are of course 4:2:2 10bit for me too over here ehehehehe
But I gotta admit, it's a bit like a drug, once I started watching those for my favorite movies and tv series ehm I mean for work-related purposes, normal consumer Satellite and Terrestrial feeds feel like unwatchable... :rolleyes:

[DTL]

"Where does this difference come from?
1920 x 1080 YUV422P10

ConvertToRGB32(matrix="Rec709")
~97 fps

ConvertBits(8)
ConvertToRGB32(matrix="Rec709")
~113 fps"

When you process >8bit the AVS engines may generally run with 16bit words (all 10 12 14 16 bit are typically processed as 16bit and it typically require 32bit integer intermediates). So when you first downconvert to 8bit the UV upscale and dematrix run with 8bit words (and typically 16bit intermediates) and it is faster.

So possibly 1920 x 1080 YUV422P16 will run at the same speed as 1920 x 1080 YUV422P10.

New version: https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.2a

Now it can write RGB32 interleaved. At i3-9100T CPU the 4 and 1 AVS-threaded performance is about equal. It looks even 1 core of AVX2 can fill all RAM bandwidth of poor DDR-SDRAM.

Single threaded at i3-9100T is 38 fps for ConvertToRGB32() and 180 fps for DecodeYV12toRGB(threads=1) at 4K YV12 decode.

At i5-9600K:
1 thread 300fps
2 threads 355 fps
4 threads 366 fps

As theory says it can not run over about 500 fps at poor DDR4-SDRAM. The AVX2 units greatly overperform poor SDRAM at such simple tasks. So intel not like to put AVX512 into very poor end-users chips with very slow RAM.

[StainlessS]

It looks even 1 core of AVX2 can fill all RAM bandwidth of poor DDR-SDRAM.
Just curious, is that single channel, or dual channel DRAM that you're using ?

[My 1 litre (lenovo tiny/HP mini/Dell micro) machines all came with single channel DRAM. (1 DIMM used, 1 DIMM free), all mine are now dual channel]

EDIT: Below 9th Gen type 'T' CPU's (low power, as used in 1 litre desktop machines + others)

############## :LGA 1151: 6th Gen -> 9th Gen CPU's ##############
Intel Core i9-9900T (2.1 - 4.4 GHz 8C/16T 14nm HD630 12MB Cache DDR4-2666_Max128GB PCIe3.0) £140
Intel Core i7-9700T (2.0 - 4.3 GHz 8C/8T 14nm HD630 12MB Cache DDR4-2666_Max128GB PCIe3.0) £130 [EDIT: down from £140]

Intel Core i5-9600T (2.3 - 3.9 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £75 [EDIT: up from £65]
Intel Core i5-9500T (2.2 - 3.7 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £45 [EDIT: Price drop from £62]
Intel Core i5-9400T (1.8 - 3.4 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £52 [EDIT Price rise from £50, the i5-9500T above, is faster, cheaper]

Intel Core i3-9300T (3.2 - 3.8 GHz 4C/4T 14nm HD630 8MB Cache DDR4-2400_Max64GB PCIe3.0) Price not known
Intel Core i3-9100T (3.1 - 3.7 GHz 4C/4T 14nm HD630 6MB Cache DDR4-2400_Max64GB PCIe3.0) £22( ~ CPU 2nd user price [EDIT: Price drop from £28])


EDIT: Approx prices of 2nd user Intel Processors [Not necessarily in-stock], click on required socket type, and In_Stock buttons if required.
https://uk.webuy.com/search?stext=Intel+processor&sortBy=prod_cex_uk_price_asc&categoryFriendlyName=Intel+Processors&Manufacturer=Intel

[VoodooFX]

Heads-up:
I encountered some bug creating "special effects" with that unofficial compile kedautinh12 is posting.
And some another with official avs. I need to remember what I was doing...

One located for "unofficial" avs (https://gitlab.com/uvz/AviSynthPlus-Builds/-/tree/main/IntelLLVM/x86):

b = BlankClip(height=4, width=2, color_yuv=$000000, pixel_type="Y8")
w = BlankClip(height=4, width=2, color_yuv=$FFFFFF, pixel_type="Y8")

clp = StackHorizontal(w,b).Blur(1).BicubicResize(64,64)
turn = clp.Turn180

StackVertical(clp, turn)


Bug:

https://i.imgur.com/6PqrjPv.png


Another for "official" avs I can't remember what exactly I was doing, I'll try tomorrow.

[DTL]

Just curious, is that single channel, or dual channel DRAM that you're using ?

[My 1 litre (lenovo tiny/HP mini/Dell micro) machines all came with single channel DRAM. (1 DIMM used, 1 DIMM free), all mine are now dual channel]

EDIT: Below 9th Gen type 'T' CPU's (low power, as used in 1 litre desktop machines + others)

############## :LGA 1151: 6th Gen -> 9th Gen CPU's ##############
Intel Core i3-9100T (3.1 - 3.7 GHz 4C/4T 14nm HD630 6MB Cache DDR4-2400_Max64GB PCIe3.0) £22( ~ CPU 2nd user price [EDIT: Price drop from £28])


[/url]

Oh - I think it is impossible in 201x to have 1channel - but it is really so
https://i.ibb.co/Y7gRH9k/lenovo-sch.png (https://imgbb.com/)

It is lenovo monoblock PC. May be really 2nd channel left for RAM upgrade option.

For i3-9100T CPU intel promises about 37.5 GB/s MAX RAM bandwidth so 1channel may be around 15..17 GB/s only.

So 1channel of DDR4 is about 180fps, 2channel is about 360 fps.

Checked at Xeon Gold6134 (not sure how many RAM channels installed - CPU-Z can not run properly, but may be at least 3 of DDR4 dual ranks installed at least ?):

1 thread 270 fps
2 threads 500 fps
4 threads 670 fps
8 threads 750 fps


The ConvertToRGB32 performance is much lower at low threads number (compute bounded)
1 thread 40 fps
2 threads 75 fps
4 threads 150 fps
8 threads 245 fps

So if 6channels of DDR4 (2666) installed it saturates at about 700 fps of RGB32 4K store. Wiki https://en.wikipedia.org/wiki/DDR4_SDRAM DDR4-2666 is about 20 GB/s per channel (?) so 6 channels is about 120 GB/s only.

Some more modern 202x general compute platforms finally will be 12channels DDR5 per CPU (something around 500 GB/s ?, finally 1 TB/s per 2 CPU board ?) - https://www.techpowerup.com/306145/intel-xeon-granite-rapids-and-sierra-forest-to-feature-up-to-500-watt-tdp-and-12-channel-memory . LGA-7529 really huge package. But to reach 1..2+ TB/s it looks require non-user-side mountable chips. Only factory assembled CPU + RAM modules.

[StainlessS]

May be really 2nd channel left for RAM upgrade option.
Yep, that's my guess too,
In the past Dell etc tended to fit eg 4 x 1GB DIMMS for 4GB total,
and people used to get a bit miffed that the had to throw away some DIMMS and buy all new DIMMS to upgrade RAM.
I prefer what they seem to be doing now, less annoying.

[DTL]

Btw using Converttorgb32() only for planar->packed causes ~30% fps drop. It seems a lot at first look. I have to test with libp2p (https://github.com/sekrit-twc/libp2p).

You can try now this repacking at AVX2 - https://github.com/DTL2020/ConvertYV12toRGB/blob/7cd0d98f166db3444168a0c19e2ecd1135a64cea/DecodeYV12toRGB.cpp#L218

It process 64 samples per pass. Though if you read planar from main host RAM it may be only RAM speed limited and not visibly depend on byte permute engine implementation.

The only practical benefit from fast conversion function is it left more CPU cores to compute something useful. And possibly draw less power if someone still care about.

[gispos]

New version: https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.2a

Now it can write RGB32 interleaved. At i3-9100T CPU the 4 and 1 AVS-threaded performance is about equal. It looks even 1 core of AVX2 can fill all RAM bandwidth of poor DDR-SDRAM.

It gets better and better, ~205 fps without prefetch!

The stripes have become less, but still present.
https://i.postimg.cc/Wp6ytXkR/Screenshot-5.jpg (https://postimg.cc/5jygR5gp)


EDIT: Below 9th Gen type 'T' CPU's (low power, as used in 1 litre desktop machines + others)

############## :LGA 1151: 6th Gen -> 9th Gen CPU's ##############
Intel Core i9-9900T (2.1 - 4.4 GHz 8C/16T 14nm HD630 12MB Cache DDR4-2666_Max128GB PCIe3.0) £140
Intel Core i7-9700T (2.0 - 4.3 GHz 8C/8T 14nm HD630 12MB Cache DDR4-2666_Max128GB PCIe3.0) £130 [EDIT: down from £140]

Intel Core i5-9600T (2.3 - 3.9 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £75 [EDIT: up from £65]
Intel Core i5-9500T (2.2 - 3.7 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £45 [EDIT: Price drop from £62]
Intel Core i5-9400T (1.8 - 3.4 GHz 6C/6T 14nm HD630 9MB Cache DDR4-2666_Max128GB PCIe3.0) £52 [EDIT Price rise from £50, the i5-9500T above, is faster, cheaper]

Intel Core i3-9300T (3.2 - 3.8 GHz 4C/4T 14nm HD630 8MB Cache DDR4-2400_Max64GB PCIe3.0) Price not known
Intel Core i3-9100T (3.1 - 3.7 GHz 4C/4T 14nm HD630 6MB Cache DDR4-2400_Max64GB PCIe3.0) £22( ~ CPU 2nd user price [EDIT: Price drop from £28])


EDIT: Approx prices of 2nd user Intel Processors [Not necessarily in-stock], click on required socket type, and In_Stock buttons if required.
https://uk.webuy.com/search?stext=Intel+processor&sortBy=prod_cex_uk_price_asc&categoryFriendlyName=Intel+Processors&Manufacturer=Intel
I was looking at new CPU's and was shocked by the power consumption.... had immediately lost the desire.

Then I looked at older ones.
I might like this one, it also has AVX-512 if not neutered by Intel and a TDP of 65 watts.
What do the experts think of the CPU?
https://ark.intel.com/content/www/us/en/ark/products/212279/intel-core-i711700-processor-16m-cache-up-to-4-90-ghz.html

[DTL]

11th intel may be good candiate because it typically have all cores AVX512 and not very bad set of AVX512-family instructions support. But sadly it is only 2 channels and DDR4. So it limited to about 50 GB/s only. I not see >2 channels RAM chips of this consumer series of CPUs.

So it may be really hard choise between 11th intel having AVX512 but only 2ch of DDR4 or newer intels with DDR5 (though 2ch only but about twice faster). It is generally balance between user's lovely plugins - either compute bound (AVX512 better if implemented) or memory bound (2ch DDR5 will be better even with AVX2 only). No one for all good solution at shrinking and dying desktops market.

Also DDR5 is sort of beginnig nowdays and I still not see as it run at 100 GB/s at 2ch. So may be 4..6 ch of more cheap DDR4 may be easily faster.

The 4ch RAM require more expensive chip case design and more expensive motherboard. So for running MS Word and Internet Explorer at home it is enough 1..2 ch of any mass market DDR SDRAM and no-AVX512 chip. In the old decades large market of end-users high performance desktops support low prices and good progress close to every year. Some promises progress speed increase and reach 'singularity' in about 202x or a bit later. They were too low in knowledge in product marketing cycle and the expected 'singularity' turn to about death of end-users desktops at all. The mining at GPU only delayed it a bit. Now the end-users desktops market is close to death and prices are high and performance progress is very low. It may be more noisy and hot but do its job.

So may be if plan to work with video processing in future years it may be recommended to look at second-hand Xeons (or may be complete second-hand workstation with Xeon with full-blood AVX512 and 6ch of at least DDR4 RAM, or cheap Xeon with 4ch DDR4).

You can look to list of classic Xeon W for workstations https://ark.intel.com/content/www/us/en/ark/products/series/125035/intel-xeon-w-processor.html - it range from very poor 1250 with 2ch of DDR4 to much more advanced 33xx with 8ch of DDR4.

[Boulder]

Have you tested these in a real life situation where you have more stuff in the script and the encoder's work eating the CPU cycles and memory bandwidth as well? It's often a very different case where you may notice only minor improvements even if some step is several times faster than earlier.

Building a PC from second hand parts is usually the most cost effective way of getting more power to the encoding jobs. And the 5xxx series Ryzens for example can be tamed so that they won't consume that much electricity at the expense of less performance. In any case, it's best to think of performance per watt since that is what matters.

[StainlessS]

My Lenovo M70Q Tiny Gen 2, has i5-11400T (35W TDP) has AVX512,
I dont know why but Lenovo tends to use the i5-xx400T which are the lower speed i5 cpu's,
Dell and HP tend to sell i5-xx500T standard speed i5's. [EDIT: i5-xx600T are high speed]
I only decided upon the lenovo 11th gen i5, so I could (one day) try out the AVX512 thingy, but CPU speed is a little disapointing.

It seems that ODD gen intel CPU's sell fewer, and EVEN gen bigger jump in performance, so I myself would opt for 12th gen
(which I might do as some point for a low power type T cpu).

Here is a 2nd user 12th gen i5-12500T machine that was online a couple of weeks ago, with 32GB DDR5 [SOLD @ £500.00],
Lenovo M80Q Gen3 Tiny/i5-12500T/32GB DDR5/2x 1TB SSD/W11/A
https://uk.webuy.com/product-detail?id=sdeslenm80qg365a&categoryName=desktops-windows&superCatName=computing&title=lenovo-m80q-gen3-tiny-i5-12500t-32gb-ddr5-2x-1tb-ssd-w11-a&referredFrom=search&queryID=ea994f54baf6f5116ae928f474865748&position=34
Intel 15-12500T:- https://www.intel.co.uk/content/www/uk/en/products/sku/96140/intel-core-i512500t-processor-18m-cache-up-to-4-40-ghz/specifications.html
Not an i7, but it still seemed like a reasonable deal {I watched it for about a week, then was 'gutted' when it sold :( }.
EDIT: I think was PCIe 4.0 too {double speed over PCIe 3.0 for recent nvme SSD}.

Here an i7-12700T (again low power)
Dell 7000 Micro/i7-12700T/16GB DDR4/256GB SSD/W10/B £690.00.
https://uk.webuy.com/product-detail?id=sdesdel7000mic34b&categoryName=desktops-windows&superCatName=computing&title=dell-7000-micro-i7-12700t-16gb-ddr4-256gb-ssd-w10-b&referredFrom=search&queryID=5f76971477c09cf6166e18151135d313&position=18
Intel i7-12700T:- https://www.intel.co.uk/content/www/uk/en/products/sku/134596/intel-core-i712700t-processor-25m-cache-up-to-4-70-ghz/specifications.html

Note, the 12 gen CPUs drop from 14nm to 10nm Lithography { "Intel 7" is 10nm, maybe an attempt by intel to deceive ??? }.

I kinda like the tiny machines, but current (dell 12th gen) tiny's come with 90W PSU instead of 65W of previous gens, and for the higher power non 'T' comes with a 120W (or maybe its 130W) PSU.
Running non 'T' in eg Dell 7000 Micro is supposed to be quite noisy. [EDIT: Under load.]

Gispos, If you decide to opt for a new CPU, do tell what you decided and how it went.

EDIT:
How that works in practice is that those new third-generation 10nm chips will be referred to as “Intel 7,” instead of getting some 10nm-based name (like last year’s 10nm SuperFin chips).
https://www.theverge.com/2021/7/26/22594074/intel-acclerated-new-architecture-roadmap-naming-7nm-2025

[DTL]

DDR5 also greatly differs in performance from DDR5-4000 to DDR5-8000 and not all CPUs support all clock rates. So low speed DDR5 may be not very faster in compare with fast DDR4. And DDR4 can go up to about DDR4-4800.

If operate with large frame size and many threads and RGB colour formats the main host RAM speed may be significant. AVS very like to use large software caches around each filter as I see.

[gispos]

Gispos, If you decide to opt for a new CPU, do tell what you decided and how it went.

You know, with me it always takes an eternity until I have decided. With my monitor, I think it was 6 months. Then there will probably already be quantum computers.;)

[DTL]

New version - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.3

Possibly bugs with UV columns positions fixed. Added 'matrix' param - so for UHD with 2020(ncl ?) matrix it should be

DecodeYV12toRGB(matrix=2)

Currently only limitedYV12->limitedRGB32 conversion. As a benefit for monitor on typical PC-RGB display it not clips superwhites, but raises black to 16 (lower contrast). On professional 'video' display or supported limited range in RGB it should display everything right.

"Have you tested these in a real life situation where you have more stuff in the script and the encoder's work eating the CPU cycles and memory bandwidth as well? It's often a very different case where you may notice only minor improvements even if some step is several times faster than earlier."

Real situation with host RAM speed is about:

As 199x..200x endusers PC general purpose shows - the home PCs at typical general purpose designed software (games/office/internet) typically only compute limited and close to zero benefit from 2ch to 4ch RAM config. So general purpose home PCs typically of very low RAM channels to be cheaper.

Only special designed software for large datasets processing may be host-RAM speed limited. So for datacenters and other scientific (and may be video-proc) there are special Xeon families:

1. Many cores + low RAM ch (2 to 6) - for compute-bound applications
2. Lower cores + high RAM ch (8 to 12) - for memory-bound applications
3. Somehow balanced - many cores + high RAM ch (8) - for many types of applications

At the datacenter design for special computing it may be visibly profitable to select right family of Xeons to get more performace per investment. Also if compute task can not be offloaded to better compute accelerator and require general-purpose CPUs.

If it can be offloaded - there is no need to buy too slow DDR-SDRAM - the good compute unit in 202x years is something like 6RU chassis with 2 kW dual-PSU and 6..12 Tesla GA100 or may be better new GH100 accelerator boards mounted. With aggregated RAM speed about 24+ TB/s HBM2e/HBM3 and it is 1000x faster in compare with DDR3 2ch home enduser PCs.

Also Xeon Max finally go into HBM RAM - https://wccftech.com/intel-announces-the-worlds-first-x86-cpu-with-hbm-memory-xeon-max-sapphire-rapids-data-center-cpu/ 1 TB/s RAM bandwidth per CPU is much better for AVX512/1024 . https://wccftech.com/intel-unleashes-hbm-powered-xeon-cpu-max-sapphire-rapids-xeon-gpu-max-ponte-vecchio-for-data-centers/
So it is again some intermediate period of changing RAM type. 2023 is the very beginning of x86 general purpose CPUs with HBM RAM integrated. Marketing title is "Xeon CPU MAX 'Sapphire Rapids HBM' ".

Having Xeon Max in the undertable compute box is a new dream for 202x season. Xeon Max can directly run AVS+ and its plugins without offloading to external special programming accelerator (like Tesla A100 board).

*waiting for vendors to ship Performance Workstations Xeon Max based for UHD processing*. Xeon Platinum 9462 - 32 Core (2.7 / 3.1 GHz) - $7995 US may be cheaper in compare with A100 external accelerator unit (though only about 1/2 of RAM speed also). It is finally next-generation compute platform ready to use at home and compatible with all accumulated PC software. May be HP will announce some Workstations on new platform in 2023 or 2024 at least. Currently I hear poor users of old platforms can not run RAW 6K realtime NLE and need to use low-res proxy and offline render with RAW sources. The next-gen solution will easily run 6K RAW in realtime and save development time and make NLE workflow more simple ans less buggy. Also it mean in end of 2023 and next years the current 6ch old Xeons at DDR-SDRAM will become second-hand throw-away hardware at prices for poors.

Also in Max series listed Xeon 9460 - https://ark.intel.com/content/www/ru/ru/ark/products/232595/intel-xeon-cpu-max-9460-processor-97-5m-cache-2-20-ghz.html
Also can be expanded with 8ch of slow DDR5-4800 over internal 64 GB of HBM. Dual-CPU Workstation should be possible with 128 GB of HBM total.

For higher demanding applications intel provides 4 OAM: 512GB HBM2e, 512 Xe Cores, 2400W TDP, 208 TFLOPS, 12.8 TB/s memory. But require redesign AVS core to use in-accelerator memory management and filters running.

About displaying/monitoring of YV12 at Windows PCs - may be it is better to found some way to feed 4:2:0 data to display accelerator directly to decode to RGB and send to display. If GDI not support AVS YV12 format - the DirectX typically work with sort of NVIDIA-designed NV12 format. It is about same as YV12 (equal in datasize and transfer performance) but UV planes samples are interleaved and located under Y plane (so memory transfer line size is equal for Y and UV-interleaved lines). If you can test if your software can feed NV12 to display it may be better to make simple
ConvertYV12toNV12()
or add NV12 into AVS core (really hard because or many data-compute) filters.

https://learn.microsoft.com/en-us/windows-hardware/drivers/display/4-2-0-video-pixel-formats
NV12 is the preferred 4:2:0 pixel format.

Example of some poor non-SIMD conversion of YV12 to NV12 from MAnalyse to feed to DX12-ME accelerator - https://github.com/DTL2020/mvtools/blob/0a6b093507bc757457783d537bc6cfaaa273989d/Sources/MVAnalyse.cpp#L2407 (UV part only)

So if possible to feed Y and UV of NV12 separately to GDI API it is fastest format for display - you directly provide pointer to RAM Y plane of YV12 and it is DMA-uploaded to accelerator from RAM. No CPU-core load required (though PCIe board still uses CPU RAM controller and bus). You need only to interleave small UV planes and provide pointer to upload to accelerator.

In a perfect world - but really the DMA to accelerator may require special PHY/Virtual-RAM addresses lines mapping/alignment and stride so GDI may use internal or some intermediate library or driver function on host-CPU routine to relocate provided Y-plane buffer for DMA transfer preparation. So to make best AVS to accelerator transfer in YV12/NV12 it may require special AVS core redesign to meet DMA transfer requirements to display accelerators. It depend on display API used.

Also some ConvertYV12toNV12() filter may prepare all-aligned buffers for DMA to save from one more full-frame Y-plane memory remap.

[gispos]

New version - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.0.3

Possibly bugs with UV columns positions fixed. Added 'matrix' param - so for UHD with 2020(ncl ?) matrix it should be

DecodeYV12toRGB(matrix=2)


There are no more stripes, also the speed is still high, ~210 fps for me without prefetch.
But no matter what I set as matrix the colors do not match the original or to ConvertToRGB32().

Everything is a bit darker. Is that your hint on that?

Currently only limitedYV12->limitedRGB32 conversion. As a benefit for monitor on typical PC-RGB display it not clips superwhites, but raises black to 16 (lower contrast). On professional 'video' display or supported limited range in RGB it should display everything right.


Edit:
Looked at it again more closely.
You write limited range, 16..235, Yes everything light is darker and everything dark becomes lighter, is there a chance that you can still change this?

[DTL]

Yes - it is limitedYUV->limitedRGB.

Can you change range using GDI tools (programming of display accelerator if possible) ?

The ConvertToRGB32() possibly write Full range, but it cause clipping of superwhites (it is no good for monitoring anyway). Also it maps 16lvl to black. It helps to get full contrast on sRGB typical PC display.

I take coefficients for matrix from https://gist.github.com/yohhoy/dafa5a47dade85d8b40625261af3776a .

I not know now if it possible to make Full range (or partial-Full like 16..254 maps to 0..255 RGB without clipping of superwhites) playing with coefficients only. So no change to current processing engine from its current performance. If add special conversion to Full (standard mapping of 16..235 to 0..255 RGB) it will be somehow slower and also somehow lower in precision. Though the performance penalty may be invisible. Need to try.

Here is release of ver 0.1.0 https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.1.0

Added RGB post processing with gain and offset - you can adjust any levels mapping (Full or black offset only and others)

offset - signed short (16bit) value to add to 8bit RGB value after decoding, default 0 (no offset)
gain - scaled to 64 multiplier (64 mean 1.0float - no gain), default 64 (no gain).

Most close to ConvertToRGB32(matrix="Rec709") output is about
DecodeYV12toRGB(matrix=1, gain=74, offset=-16)

gain 74 is (255/219) * 64 = 74.52 (may be 75 can work a bit better with still no bugs)

For still not known reason scale of 128 with better precision (7bit) not work correctly (with ColorBarsHD()) so only 6bit of 64 multiplier currently looks like working.

Black offset only without superwhites clipping is something like
DecodeYV12toRGB(matrix=1, gain=68, offset=-16)

Postprocessing part work always so it make some performance penalty (can not check now without AVX2 CPU). Performance penalty not depend on gain/offset values (also no check for validity so too extreme values will cause 16bit signed short computing over/underflow and other issues).

[gispos]

Postprocessing part work always so it make some performance penalty (can not check now without AVX2 CPU). Performance penalty not depend on gain/offset values (also no check for validity so too extreme values will cause 16bit signed short computing over/underflow and other issues).
So it is still ~189 fps for me.

You write for previews, I think it's also good for animation videos.
It more precisely favors the color boundaries than ConvertToRGB32. Now whether this is better for normal videos... what do others say.
https://vimeo.com/826648468?share=copy

Edit:
With normal videos I see almost no difference.
But it might be really interesting for the anamation film lovers.
So if you have a YV12 video you get the color fringes clean. I don't know if there are other filters that can do this.

What else I need to get rid of:
With all the test I noticed that some things affect the speed of my PC.
I have a TV card that always runs as soon as the PC is turned on. The costs but smooth 20% when I measure fps.
Even the browser makes only 30 fps out of 35 fps.
Embarrassing, but I had never thought of it, or say I would not have believed that makes such a difference.

So now I have a CPU with 20% more power. :)

[DTL]

"So it is still ~189 fps for me."

It is good enough. Next week I will try to do Intel C compiled binary and also AVX512 compiled (both VS2019 and IC 19) to see if it will benefit from AVX512 larger register file. The main program text is intrinsics-based so depend on C-compiler used. Also may be someone having LLVM compiler may try to do AVX2-limited and AVX512-limited compiled binaries to test performance.

I not check if current implementation run out of AVX2 register file size or not (so may use temp store/load some data to/from L1D cache and it adds performance penalty). Also it may depends on compiler used.

"It more precisely favors the color boundaries than ConvertToRGB32"

It should be equal to lowest quality resize for 'classic moving pictures' - ConvertToRGB32(chromaresample=point). Though for pixel-art it is good and make sharper chroma.

"With normal videos I see almost no difference."

For not very sharp 4K footages (and also soft film transfers) it may be not visible difference from bicubic resize chroma. So UHD1/2 may be treated as dual/quad upsampled FullHD and not need as precise subsampling processing as SD and HD.

"I don't know if there are other filters that can do this."

You can compare with ConvertToRGB32(chromaresample=point).

New version 0.2.0 - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.2.0

Uncached load looks like not work in most of chips (may work in future ?). Uncached store works very fine in > 1 thread. Though it may be mostly benefit if display accelerator loads result directly from RAM. Each use case may require cached of not store. With AVSmeter it looks much better to use non-cached store.

Test results at i5-11600 (AVX512 builds just very slightly faster, so looks most of data fit AVX2 register file well) with 2ch of DDR4-3200 RAM:

1thread cached store 255 fps, non-cached store 268 fps
2thread cached store 400 fps, non-cached store 532 fps
4thread cached store 340 fps, non-cached store 811 fps

at Xeon Gold 6134 (looks like 6ch of DDR4-2666 ?)
1thread cached store 256 fps, non-cached store 295 fps
2thread cached store 488 fps, non-cached store 596 fps
4thread cached store 694 fps, non-cached store 1175 fps
6thread cached store 760 fps, non-cached store 1570 fps (ConvertToRGB32 is 216 fps)
and some hyperthreading example:
8thread non-cached store 1725 fps
10thread non-cached store 1780 fps

Finally 1500+ fps with 6ch DDR4 is running. It looks with non-cached store it good to check if AVX512 version of processing may double fps per 1 thread.

AVS multithreading looks like visibly faster in compare with internal OpenMP (may use slower workunit size per thread and having more threads sync penalty). But takes much more RAM.

Also some redesigned non-cached read version - https://github.com/DTL2020/ConvertYV12toRGB/releases/tag/0.2.1
At i5-9600K the cl=false is slightly faster (about 730 and 760 fps). At i5-11600 the cl=false is significantly slower (about 800 and 560 fps). So it greatly depend on CPU family and may be use case in surrounding data source/sink.

[gispos]

"So it is still ~189 fps for me."

Next week I will try to do Intel C compiled binary and also AVX512 compiled (both VS2019 and IC 19) to see if it will benefit from AVX512 larger register file. The main program text is intrinsics-based so depend on C-compiler used. Also may be someone having LLVM compiler may try to do AVX2-limited and AVX512-limited compiled binaries to test performance.

I don't know if you are using AvsPmod.
Have here a test version to allow a real test (not only fps measured without display).

Under menu 'Options' there are the 2 entries
'Prefetch RGB display conversion' = Prefetch(2,2)
'Fast YV12 display conversion' = Your plugin

Your plugin is used when:
The function exists, the option is turned on, the video is YV12, the video width is mod 64.

For me with a real 4K video YUV420P10 and ConvertBits(8)
ConvertToRGB32()
~23 fps

ConvertToRGB32() with option 'Prefetch display conversion'
~32 fps

DecodeYV12toRGB(threads=1, matrix=1, gain=74, offset=-16) no prefetch
~40 fps

With option prefetch it becomes jerky ~46 fps then 30 fps and so on, I think that then my RAM or Bus limit is exceeded.

It is a pity that, as you have already written, the quality is only "simple".
I compared it with a 4K video and saw small differences... so this AvsPmod version will probably remain the only one that contains this function.

Too bad, but I think no one will want to use it in AvsPmod for preview.
Make one with 'bicubic'... it can be slower.... must only be faster than ConvertToRGB32. :)

https://drive.google.com/file/d/1Q6lfOZmMcW8KojRCcd1JF3_z1I-RreES/view?usp=sharing

[DTL]

"I don't know if you are using AvsPmod."

I not know what is AvsPmod (expect it is some script editor with some preview window and some frame number control ?). Also pinterf also ask where is this strange 4K ConvertToRGB32 is used - https://github.com/AviSynth/AviSynthPlus/issues/354#issuecomment-1549689053 . May you can write all required for AvsPmod directly at github ?

"the video width is mod 64."

It may be tested with other widths (or plugin may be simply fixed for +1 64-columns process). As I see with Asd-g plugins he also uses some mod64 processing for all widths and it may be feature of new AVS+ core to provide mod64 real row pitch for all frame widths.

"and ConvertBits(8)"

May be better to design version with input in 10..16 bits and skip this 1 more convert. It is anyway internally upconverted to 16bit to process. Or make 10->8 internally with close to zero time (right bitshift to 2). Will try later.

[Dogway]

Yes - it is limitedYUV->limitedRGB.

Can you change range using GDI tools (programming of display accelerator if possible) ?

The ConvertToRGB32() possibly write Full range, but it cause clipping of superwhites (it is no good for monitoring anyway). Also it maps 16lvl to black. It helps to get full contrast on sRGB typical PC display.

I take coefficients for matrix from https://gist.github.com/yohhoy/dafa5a47dade85d8b40625261af3776a .

I not know now if it possible to make Full range (or partial-Full like 16..254 maps to 0..255 RGB without clipping of superwhites) playing with coefficients only. So no change to current processing engine from its current performance. If add special conversion to Full (standard mapping of 16..235 to 0..255 RGB) it will be somehow slower and also somehow lower in precision. Though the performance penalty may be invisible. Need to try.


You can use coefficients for range conversion within the transformation matrix. Take a look at my YUV_to_RGB() (https://github.com/Dogway/Avisynth-Scripts/blob/8c45afa6142e043a0ff83148e48ad9db3f316968/TransformsPack%20-%20Models.avsi#L212) function.

In this case using Rec709 primaries with D65 illuminant, for TV to PC range the coefficients are:
m=[1.16895, 0 , 1.799772,\
1.16895,-0.214149,-0.535015,\
1.16895, 2.120637, 0]
Then the conversion goes as follows. You still have to substract footroom to Y and center chroma to 0 for the matrix to work.

ConverttoYUV444(chromaresample="bicubic",param1=0.1750,param2=0.4125)
YUV=ExtractClip()
bi=8
range_PC = "ymin - "
range_TV = ""
UVf = bi < 32 ? "range_half - " : ""

Expr(YUV[0],YUV[1],YUV[2], ex_dlut("x "+range_PC+" "+string(m[0])+" * "+range_TV+" z "+UVf + string(m[2])+" * + ", bi, false), \
ex_dlut("x "+range_PC+" "+string(m[0])+" * "+range_TV+" y "+UVf + string(m[4])+" * + z "+UVf + string(m[5])+" * + ", bi, false), \
ex_dlut("x "+range_PC+" "+string(m[0])+" * "+range_TV+" y "+UVf + string(m[7])+" * + ", bi, false), optSingleMode=true, format=bi>16?"RGBPS":"RGBP"+string(bi))

[DTL]

"DecodeYV12toRGB(threads=1, matrix=1, gain=74, offset=-16) no prefetch
~40 fps"

With versions 0.2.x and later you can try additional options cl/cs true/false (all 4 cases may be tested) for aditional performance tuning. Typically cs=false make things faster and cl=true/false depend on CPU chip and other.

[FranceBB]

I not know what is AvsPmod

Said DTL, without the blink of an eye, not knowing he was talking to the current and only AVSPmod mod maintainer, Gispos XD


Test results at i5-11600 (AVX512 builds just very slightly faster, so looks most of data fit AVX2 register file well) with 2ch of DDR4-3200 RAM:

1thread cached store 255 fps, non-cached store 268 fps
2thread cached store 400 fps, non-cached store 532 fps
4thread cached store 340 fps, non-cached store 811 fps

at Xeon Gold 6134 (looks like 6ch of DDR4-2666 ?)
1thread cached store 256 fps, non-cached store 295 fps
2thread cached store 488 fps, non-cached store 596 fps
4thread cached store 694 fps, non-cached store 1175 fps
6thread cached store 760 fps, non-cached store 1570 fps (ConvertToRGB32 is 216 fps)
and some hyperthreading example:
8thread non-cached store 1725 fps
10thread non-cached store 1780 fps




Interesting. Tomorrow I'll try to run some benchmarks too with the normal AVSPmod mod version (current ConverttoRGB32() function) and the new yv12 to RGB32 function.
p.s sorry DTL for "ghosting" you on PMs, but believe me, I clock in the office at 08.00AM and I leave at 07.00PM these days, yet I never find time to do the stuff I wanna do... :(

[DTL]

"Tomorrow I'll try to run some benchmarks"

Do your company plan to buy new Xeon Max platforms ? In 2023 or 2024 ? It will be nice to see how the all AVS software will run there.

[FranceBB]

Do your company plan to buy new Xeon Max platforms ? In 2023 or 2024 ?

I wish...
I think it will all depend on whether we'll get the football rights back in Italy.
Currently they're saying "no" to any request I put forward... :(

[gispos]

"the video width is mod 64." ... "and ConvertBits(8)"

These were your specifications. YV12 and width mod 64.
To be able to use your plugin.

Update, I had tested with a video YUV420P10:
video=LWLibavVideoSource(SourceFile, cache=True, indexingpr=False, format="")
audio=LWLibavAudioSource(SourceFile, cache=True)
audioDub(video, audio)
ConvertBits(8)

That was ~40 fps with your plugin

But if I do this with ColorBars(3840, 2160, "YV12") these are over 100 fps to ConvertToRGB32() with only ~33 fps

Apparently the source filter for this video takes quite a long time.
Must compare this with some other videos and with DirectShowSource.

So at over 100 fps (I had 120) I'm thinking of leaving this option.

[pinterf]

Anyway, I added AVX2 code path for YV24 to RGB32/RGB24 conversion. My gain (i7-11th gen) was typically +50% fps shown by AvsMeter.
At least the 2nd part of the ConvertToRGB32 conversion chain is enhanced.

[DTL]

And what about caching control for storing ?

[pinterf]

And what about caching control for storing ?
In my opinion this feature is too specific need, at least to involve it into the parameters of the filters. I'd better leave Avisynth to be independent of actual processor architectures and operating systems, even if it would seem that introducing a hardware specific parameter makes it quicker for some actual processors in 2023.

[gispos]

Anyway, I added AVX2 code path for YV24 to RGB32/RGB24 conversion. My gain (i7-11th gen) was typically +50% fps shown by AvsMeter.
At least the 2nd part of the ConvertToRGB32 conversion chain is enhanced.
I had noticed that if a ConvertBits(8) is used before the ConvertToRGB32() it becomes faster for formats > 8bit.
Does this have an influence on the quality? Is that still needed with the update?

[DTL]

In my opinion this feature is too specific need, at least to involve it into the parameters of the filters. I'd better leave Avisynth to be independent of actual processor architectures and operating systems, even if it would seem that introducing a hardware specific parameter makes it quicker for some actual processors in 2023.

If adding of cache control at end-user side with more filter params is difficult - it may be recommended to make fixed non-cached store because in all current tests it shows about twice more memory performance and may only add some penalty with very small frame sizes (fitting in L2/L3 caches x number_of_threads). So for processing of FHD/UHD1/UHD2 frame sizes with massive-multicore CPUs in 202x it may add to general performance.

The _stream_si256() instruction (intrinsic) is not depend on OS used and also work in the AVX2 instructions set.

I had noticed that if a ConvertBits(8) is used before the ConvertToRGB32() it becomes faster for formats > 8bit.
Does this have an influence on the quality? Is that still needed with the update?

Processing in >8 bit typically will create better precision/quality. You can compare with Subtract() and see if you got more or less precision/quality loss.

[pinterf]

I had noticed that if a ConvertBits(8) is used before the ConvertToRGB32() it becomes faster for formats > 8bit.
Does this have an influence on the quality? Is that still needed with the update?

Case:
444 source over 8 bits
Target: RGB32 or RGB24

Conversion chain:
- 4:4:4 -> Planar RGB (bit depth kept)
- ConvertBits(8)
- 8 bit Planar RGB -> RGB32/24

But when you convert the source YUV clip to 8 bits before ConvertToRGB32, then direct YV24->RGB32 process is done. (No planar RGB workaround)

Reasons:
- Packed RGB exists only at 8 or 16 bits
- YUV444P16 to RGB64 is not implemented in SIMD code, only in slow C.

In my AVX2 update only the last element of a 8 bit chain YV24->RGB32/24 was made quicker.

[DTL]

"direct YV24->RGB32 process is done."
"only the last element of a 8 bit chain YV24->RGB32/24 was made quicker."

Example of AVX2 YV24 to RGB32 64 columns per SIMD pass started from

https://github.com/DTL2020/ConvertYV12toRGB/blob/bd88a2b5be6c84bb5650860eafb14fa6a4ea2716/DecodeYV12toRGB.cpp#L226

(point resize of UV of YV12 to YV24 is https://github.com/DTL2020/ConvertYV12toRGB/blob/bd88a2b5be6c84bb5650860eafb14fa6a4ea2716/DecodeYV12toRGB.cpp#L214 to https://github.com/DTL2020/ConvertYV12toRGB/blob/bd88a2b5be6c84bb5650860eafb14fa6a4ea2716/DecodeYV12toRGB.cpp#L224 )

May be transfer it to AVS core as option for AVX2 processing ? Though I not sure if it keep same precision for dematrix.

Though still slow UV upsize from YV12 to YV24 if using standard AVS resampling engine may eat most of performance gain.

[flossy_cake]

Is there any possibility of Avisynth supporting namespaces at some point in future?

I need to use globals for reliable messaging between frames in ScriptClip, and this is eating a lot of namespace.

Also user cannot make multiple calls to my function because both calls would be writing to the same globals.

ScriptClip(local=true/false) doesn't seem to work, I'm guessing due to caching or something. It only seems to work if I declare globals outside and before the ScriptClip, then I can write to them inside the ScriptClip and the messaging between frames seems to work properly. Maybe I am doing something wrong here, I will keep trying.

I tried to save namespace by using a single array containing all my globals but couldn't get it to work as there doesn't seem to be any way to SET an element of an array through a string-key, only through an integer-index. It is possible to GET an element of the array through a string-key, though, but it must be explicitly defined before hand like eg. dictionary = [["one", 1], ["two", 2]] then you can go like dictionary["one"] but to set dictionary["one"] to something is not possible, only ArraySet(dictionary, 1, 0) to write integer 1 to index 0. Cannot go ArraySet(dictionary, 1, "one").

For now I will just prefix all my globals with some random string that nobody would use like


global 5dl31h_prevFrameYDiff
global 5dl31h_prevFrameUDiff
global 5dl31h_prevFrameVDiff

[pinterf]

"direct YV24->RGB32 process is done."
"only the last element of a 8 bit chain YV24->RGB32/24 was made quicker."

Though still slow UV upsize from YV12 to YV24 if using standard AVS resampling engine may eat most of performance gain.

The main two differences why the quick YV12->YV24 chroma is not used: default UV resampler is not pointresize. Secondly the default chroma location is "mpeg" ("left") and not "center".

The YV12->YV24 U and V resize method would recognize and work upon the very quick special case only when both parameters are set properly: pointresize and center.

(Overlay was using this method when some of its modes were supported only in 4:4:4 mode internally; Any 4:2:0 and 4:2:2 from and to conversion used this special conversion
See here: https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/overlay/444convert.cpp
)

[FranceBB]

Happy 23rd Birthday, Avisynth! :D

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

(at least according to Wikipedia, 19th of May 2000)
I wasn't here on Doom9, back then, of course, as I only started using this amazing frameserver in June 2006 as a home user (and professionally only in 2013), but I'm sure some of the people who are still here were.
The world has changed a lot since then and so did Avisynth, constantly evolving towards a better future.

[StainlessS]

Is there any possibility of Avisynth supporting namespaces at some point in future?

I need to use globals for reliable messaging between frames in ScriptClip, and this is eating a lot of namespace.

Also user cannot make multiple calls to my function because both calls would be writing to the same globals.

ScriptClip(local=true/false) doesn't seem to work, I'm guessing due to caching or something. It only seems to work if I declare globals outside and before the ScriptClip, then I can write to them inside the ScriptClip and the messaging between frames seems to work properly. Maybe I am doing something wrong here, I will keep trying.

I tried to save namespace by using a single array containing all my globals but couldn't get it to work as there doesn't seem to be any way to SET an element of an array through a string-key, only through an integer-index. It is possible to GET an element of the array through a string-key, though, but it must be explicitly defined before hand like eg. dictionary = [["one", 1], ["two", 2]] then you can go like dictionary["one"] but to set dictionary["one"] to something is not possible, only ArraySet(dictionary, 1, 0) to write integer 1 to index 0. Cannot go ArraySet(dictionary, 1, "one").

For now I will just prefix all my globals with some random string that nobody would use like


global 5dl31h_prevFrameYDiff
global 5dl31h_prevFrameUDiff
global 5dl31h_prevFrameVDiff


Hi Flossy,
Martin53 and Gavino developed a multi-instance method of scripting. .

Here, two templates

Bare_MI.avs

Function BARE_MI(clip c,Bool "Show") {
myName="BARE_MI: "
IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("Grunt")
Assert(IsAvsPlus||HasGScript,RT_String("%sEssential either GScript or AVS+",myName))
Assert(RT_FunctionExist("GScriptClip"), RT_String("%sEssential GRunt installed"),myName))
Assert(RT_FunctionExist("MSuper"),RT_String("%sEssential MvTools2 installed"),myName))
FuncS="""
Function Fn@@@(clip c,Bool Show,String Fmt) {
c n = current_frame
Return Last
}
#######################################
# Unique Global Variables Initialization
#######################################
Global Prev@@@= -666 # Init vars, Prev = -666 forces initalize
#######################################
# Unique Runtime Call, GScriptClip must be a one-liner:
#######################################
ARGS = ""
c.GScriptClip("Fn@@@(last, "+ARGS+")", local=true, args=ARGS)
"""
#######################################
# Unique Identifier Definition
#######################################
GIFunc ="BARE_MI" # Function Name, Supply unique name for your multi-instance function.
GIName =GIFunc+"_InstanceNumber" # Name of the Instance number Global
RT_IncrGlobal(GIName) # Increment Instance Global (init to 1 if not already exists)
GID = GIFunc + "_" + String(Eval(GIName))
InstS = RT_StrReplace(FuncS,"@@@","_"+GID)
# RT_WriteFile("DEBUG_"+GID+".TXT","%s",InstS) # UnComment to write each unique script function instance to log file
HasGScript?GScript(InstS):Eval(InstS):
# if CallCmd available, Auto delete DBase file on clip closure.
#RT_FunctionExist("CallCmd")?CallCmd(close=RT_String("""CMD /C chcp 1252 && del "%s" """,DB), hide=true, Synchronous=7,debug=true):NOP
}


MultiInstanceTemplate.avs

Function FFMS_MakeMultiPartScript(clip c) {
c myName="FFMS_MakeMultiPartScript: "
IsAvsPlus=(FindStr(UCase(versionString),"AVISYNTH+")!=0) HasGScript=RT_FunctionExist("GScript") HasGrunt=RT_FunctionExist("GScriptClip")
Assert(IsAvsPlus || HasGScript,myName+"Essential Avs+ OR GScript installed")
Assert(HasGrunt,myName+"Essential GRunT plugin installed, http://forum.doom9.org/showthread.php?t=139337")
Show=Default(Show,False)
Fmt = "%d ] c1AveLum=%6.2f" # Make format string only once, not at every frame
FuncS="""
Function Fn@@@(clip c,Bool Show,String Fmt) {
c
n = current_frame
If(Prev@@@ == n) { # Cache failure, requested same frame again.
RT_DebugF("%d ] Cache Failure",n,name="Fn@@@_DBUG: ")
} Else If(Prev@@@ + 1 != n) { # Init OR Rewind OR User jumped about, dont you just hate users!
if(n == 0) {
if(Prev@@@ == -666) {
RT_DebugF("%d ] Initialized to frame 0",n,name="Fn@@@_DBUG: ")
} else {
RT_DebugF("%d ] Rewind to frame 0",n,name="Fn@@@_DBUG: ")
}
} else {
RT_DebugF("%d ] User Jumped About",n,name="Fn@@@_DBUG: ")
}
}
if(Show) {
RT_Subtitle(Fmt,n, c.RT_AverageLuma(n=n))
}
Global Prev@@@=n # Previous frame (For next interation jump about detect)
Return Last
}
#######################################
# Unique Global Variables Initialization
#######################################
Global Prev@@@= -666 # Init vars, Prev = -666 forces initalize
#######################################
# Unique Runtime Call, GScriptClip must be a one-liner:
#######################################
ARGS = "Show,Fmt"
c.GScriptClip("Fn@@@(last, "+ARGS+")", local=true, args=ARGS)
"""
#######################################
# Unique Identifier Definition
#######################################
GIFunc ="FFMS_MMPS" # Function Name, Supply unique name for your multi-instance function.
GIName =GIFunc+"_InstanceNumber" # Name of the Instance number Global
RT_IncrGlobal(GIName) # Increment Instance Global (init to 1 if not already exists)
GID = GIFunc + "_" + String(Eval(GIName))
InstS = RT_StrReplace(FuncS,"@@@","_"+GID)
# RT_WriteFile("DEBUG_"+GID+".TXT","%s",InstS) # UnComment to write each unique script function instance to log file
HasGScript ? GScript(InstS) : Eval(InstS) # Use GSCript if installed (loaded plugs override builtin)
Return Last
}


If you need any follow-up, then start new thread.

EDIT: MultiInstanceTemplate.avs stolen from here:
https://forum.doom9.org/showthread.php?t=176386&highlight=MakeMultiPartScript

EDIT: Some script names ending in "_MI"
DirtBox_MI :- https://forum.doom9.org/showthread.php?t=175708
Dupped_MI :- https://forum.doom9.org/showthread.php?p=1716968#post1716968
MorphDupes_MI_1.01:- https://forum.doom9.org/showthread.php?p=1764865#post1764865
DetectSub_MI :- https://forum.doom9.org/showthread.php?p=1782036#post1782036

EDIT: The "@@@" parts of function/variable names are given unique number as per multi-instance function instance.

EDIT: There is also this, for creating unique names (file or variable).

RT_LocalTimeString(Bool "file"=True)
Returns current local time as a string.
Where digits Y=Year, M=Month, D=Day, H=Hour, M=Minute, S=Second, m=millisecond.
When bool file==False, then string in format "YYYY-MM-DD HH:MM:SS.mmm"
When bool file==True (Default) string is in format "YYYYMMDD_HHMMSS_mmm"
Also when file==True, function first waits until the system tick count is incremented (about every 10ms)
before inquiring system time. This is to prevent 2 consecutive calls returning the same time string.
Perhaps useful for temporary filename generation.


EDIT:
And see Gavino stuff here [try move as much code as you can out of Scriptclip script and into function].
GRunT does not change the behaviour of ScriptClip regarding string usage, even when local scope is used, as string memory in Avisynth is orthogonal to the scope of variables and, as you say, is not released until script destruction.

The RTE script string (as a whole) is created only once when the containing script is loaded. However, that string itself is parsed afresh on every frame, which means that any identifiers and string literals within it are repeatedly added to the string heap.

Usually this is not significant, but for large run-time scripts, coupled with lots of source frames, it can add up. In fact, I discovered this was the source of a memory leak in SRestore (see here).

The solution is to move the code inside the run-time script to another function, reducing the run-time script itself to a simple function call. This effectively eliminates memory problems, and also gives a speed increase.

In other words, instead of
ScriptClip("""
... very long script ...
""")
use
function f(... some params ...) {
... previous script code ...
}
...
ScriptClip("f(...)")
Unless using GRunT, current_frame needs to be passed as a parameter to the function. (In GRunT, this is a [i]global variable.)

EDIT: Thread where some of the multi-instance stuff was debated.
Runtime variables scope and lifetime:- https://forum.doom9.org/showthread.php?p=1650250#post1650250

[flossy_cake]

Thanks for the info StainlessS

[DTL]

Asd-g make some clang and icx builds of DecodeYV12toRGB:

_clang_avx2 - arch:avx2
_clang_avx512 - arch:avx512
_icx_avx2 - arch:avx2 (intel c++ compiler 2023)
_icx_avx512 - arch:avx512 (intel c++ compiler 2023)

https://github.com/Asd-g/AviSynth-vsTTempSmooth/files/11517940/DecodeYV12toRGB.zip

May be they run somehow faster VS2019 builds ?

Also pinterf wrote next point about lower quality of DecodeTV12toRGB: It currently uses more data to process per SIMD pass but with only 16bit intermediate precision. And AVS+ internal YV24 to RGB dematrix uses 32bit intermediates - so AVS+ ConvertToRGB32 provide better precision.

So it looks we can have 2 version of dematrix functions:

1. 16bit internal processing with higher performance but lower precision.
2. 32bit internal processing with somehow lower performance but better precision.
3. float32 highest precision and probably lowest performance.

AVX2 with 512 bytes registerfile looks like allow to process 64 samples (colour - YV24 and output RGB) with 16bit intermediates or 32 samples with 32bit intermeadiates (it is version to try for performance check).

AVX512 with 2048 bytes registerfile looks like allow to process 256 samples (colour - YV24 and output RGB) with 16bit intermediates or 128 samples with 32bit intermeadiates (both need to be implemented and check for performance).

[gispos]

Asd-g make some clang and icx builds of DecodeYV12toRGB...
Thanks to all contributors!

I am so free and post it here and not in the AvsPmod thread.

Everything with zoom 100%, dll version icx_avx2

Video 1920 x 1080 YV12, playback (also with display drawing)
ConvertRGB = ~95 fps
DecodeRGB = ~112 fps
I can not see any visual difference.

ColorBars(width=3840, height=2160, pixel_type="YV12"), also playback
ConvertRGB = ~32 fps
DecodeRGB = ~100 fps

ColorBars(width=3840, height=2160, pixel_type="YUV420P10"), also playback
ConvertRGB = ~24 fps
DecodeRGB = ~92 fps

Well, for ColorBars DecodeRGB looks nicer (sharp edges).
RGB (255,255,255) becomes (253,253,253)
I took a snapshot in AvsPmod and compared.
The difference is barely visible on my monitor, and there is almost no difference in the other colors either.

If you use it you have to be careful to use the right dll with the right AVX version.
Had once tested the 512... crash.
Maybe it would be possible to create only one dll with checking the existing AVX version.

AvsPmod Pre-Release_7 also to test the dll
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

https://i.postimg.cc/GmZHXFRH/Convert-To-RGB.gif (https://postimages.org/)

[flossy_cake]

Is there some way of getting Avisynth to print out the namespace of all global variables and function names, so that we know what names NOT to use?

I named my function AIT() but it doesn't work properly & I think it's a namespace clash with some other plugin that might also be declaring a function called AIT().

[DTL]

New version - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.3.0

Now can take also 10..16bits YUV planar and convert to 8bit YV12 internally before processing.

With skipping ConvertBits(8) before YUV to RGB with one more full frame scan it also adds performance at out-of-cache frame sizes. If AVS can either have lots of ready to use SIMD functions inside for different conversions with single source scan or can dynamically compile required SIMD program for requested format conversion it can save from several host RAM read/writes for sequence of formats conversion and adds to performance.

At i3-9100T CPU both AVX2 Asd-g builds run a bit faster in compare with my VS2019 builds. So even close to pure SIMD program but intrinsics based (not fixed assembler) can have visibly different performance depending on C-compiler used even if it not very visibly run out of register file size.

About transients display - the internal AVS ColorBars(HD) are only about levels checking - not about transients for moving pictures. Maybe only for special designed pixel-art with moving pictures. So point-resize for UV work very well with pixel-art based output of ColorBars(HD). With natural footage for moving pictures it will be somehow different.

Also BicubicResize for UV default for ConvertToRGB32 with default b/c values can create some small over/undershoots with too sharp input from ColorBars(HD) data - it is expected.

[StainlessS]

Flossy,

From RT_Stats,

RT_VarExist(string)
Given the name (string) of the variable that you want to test for existence, returns true if exists, else false.
Eg, #a=32
RT_Debug(string(RT_VarExist("a"))) # would output 'false' to debugview unless '#a=32' uncommented. {Defined(a) would fail with error}.
return colorbars()

***
***
***

RT_FunctionExist(string)
Given the name (string) of the Function (plugin) that you want to test for existence, returns true if exists, else false.



Some builtin

Exist

Exist(filename)
Tests if the file specified by filename exists.

Examples:

filename = ...
clp = Exist(filename)
\ ? AviSource(filename)
\ : Assert(false, "file: " + filename + " does not exist")

Defined

Defined(var)
Tests if var is defined. Can be used inside Script_functions to test if an optional argument has been given an explicit value.
More formally, the function returns false if its argument (normally a function argument or variable) has the void ('undefined') type, otherwise it returns true.

Examples:

b_arg_supplied = Defined(arg)
myvar = b_arg_supplied ? ... : ...

FunctionExists

FunctionExists(name) AVS+
Tests if the function or filter name is defined in the script.
name can be any string – it does not need to be a legal name.
Example – see Apply below

InternalFunctionExists

InternalFunctionExists(name) AVS+
Tests if the function, filter or property name is defined natively within AviSynth+.

Unlike FunctionExists, returns false for external plugins and user-defined functions.

VarExist

VarExist(name) AVS+
Tests if the variable exists or not. Note: if variable exists, it returns true regardless of the "defined" state of the variable

http://avisynth.nl/index.php/Internal_functions#FunctionExists

EDIT: There is no way to query Global/Local scope, VarExist first scans Local list, and if var not found there, then scans Global list.
True and False are Global vars not constants, but Local vars 'Hide' Globals,
so inside function can do eg,
True = !True # (New True is Local and 'Hides' Global True).

[flossy_cake]

http://avisynth.nl/index.php/Internal_functions#FunctionExists


Thanks - and sorry for not seeing it in avisynth.nl wiki - at the time I was using the offline documentation html files that come with Avisynth which is out of date and doesn't mention those ones like VarExist and FunctionExists.

[gispos]

New version - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.3.0

Now can take also 10..16bits YUV planar and convert to 8bit YV12 internally before processing.

With skipping ConvertBits(8) before YUV to RGB with one more full frame scan it also adds performance at out-of-cache frame sizes. If AVS can either have lots of ready to use SIMD functions inside for different conversions with single source scan or can dynamically compile required SIMD program for requested format conversion it can save from several host RAM read/writes for sequence of formats conversion and adds to performance.

That's great, the new version runs faster even with YUV420P16 than the previous one with only YUV420P8.
With the previous one I had to put a ConvertBits(8) in front.

Thanks for the new version!
A big improvement would be if the mod 64 could be scaled down.

I have a new Pre-Release that works with both DLL versions.
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

[DTL]

Here is attempt to process all widths - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.3.1

It looks with 64 samples per pass it is not compatible with max mod64 bytes rows strides ? So the last columns up to 63 are processed with simple C-scalar program. At UHD frame 3840+60 width and at i3-9100T CPU it looks not add significant penalty -
3840 width 313 fps
3840+60 width 308 fps.

It is not tested with all possible frame widths so some bugs may happen.

"the new version runs faster even with YUV420P16 than the previous one with only YUV420P8. "

From ver 0.3.0 I set cs default to false as I see it typically make storing data faster and users may be lazy to test best setting of true/false at current host.

[gispos]

Here is attempt to process all widths - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.3.1
.
Wow! Wow! Wow! I can hardly believe it, excellently done!

Tried all dimensions and no error received so far.
4K ColorBar YUV420P10 with AvsPmod 'Resample Filter' and option 'Prefetch display conversion' resized to 1980 x 1080
runs in playback with ~153 fps shrunk to 1280 x 720 it is ~189 fps

ColorBar 1920 x 1080 YUV420P10 ~196 fps in the playback with display drawing.

I've spent a few hours optimizing everything, at least it was worth it.

Thanks!

[flossy_cake]

And see Gavino stuff here [try move as much code as you can out of Scriptclip script and into function].

string (as a whole) is created only once when the containing script is loaded. However, that string itself is parsed afresh on every frame, which means that any identifiers and string literals within it are repeatedly added to the string heap...this was the source of a memory leak in SRestore

The solution is to move the code inside the run-time script to another function, reducing the run-time script itself to a simple function call. This effectively eliminates memory problems, and also gives a speed increase.

In other words, instead of
ScriptClip("""
... very long script ...
""")
use
function f(... some params ...) {
... previous script code ...
}
...
ScriptClip("f(...)")



Unfortunately it appears the solution above requires ScriptClip(local=true) which doesn't allow messaging between frames, which I absolutely need.

So I am stuck with a huge memory leak - around 2MB/sec in my case :o

Is there perhaps some way to manually "clear the string heap"?

[StainlessS]

Is there perhaps some way to manually "clear the string heap"?
Nope, nuttin' at all, no mem is garbage collectable.

What are you trying to do, post what you attempted.

EDIT: You can still use globals even when Local = true.
Must use eg

Global SomeVar = WhateverVar

Trying to pass a 'Stored Frame", will fail after a few (hundred or thousand) frames, ie Huge mem usage.
(You are calcing current frame, based on previous frame, which is also based on frame before it, etc.
Not possible to just "throw away" prev temp frames as re-seek requires every frame before it to be available.)

EDIT:
I have tried many times (and find hard to accept the futility) to try find solution for what it is I think that you are trying to do,
even this attempt at solution failed.
FrameStore v0.03 - Avs+ x86/x64 - 15 Jan 2019
https://forum.doom9.org/showthread.php?t=175212

[flossy_cake]

What are you trying to do, post what you attempted.

This is leaking around 1.3MB/sec for 30fps video on my system (too big to paste on forum): https://pastebin.com/raw/pKfBJ26Q

This however produces no leak: https://pastebin.com/raw/PGWtzubz

But it won't allow runtime funcs like this:


ScriptClip( last,
\ function [] (c) {

diff = YDifferenceToNext(c, -1) # requires local=true, else error message
c

} , after_frame=true, local=false)


If I set local=true then I lose the ability to message between frames:


global PrevFrameNumber = 0

ScriptClip( last,
\ function [] (c) {

global PrevFrameNumber = PrevFrameNumber + 1 # doesn't work, just stays at 1
c.SubTitle(String(PrevFrameNumber))

} , after_frame=true, local=true)


Perhaps messaging could be done through frame properties instead.

[StainlessS]

Sorry, I aint got a clue about that new fangled "Function [] (c)" stuff, old dog and new trick thingy.

Perhaps messaging could be done through frame properties instead.
Same, old dog, new tricks.

[StainlessS]

Is this what you are tryin' to do with that there new fangled stuff ?


/*
ScriptClip( last,
\ function [] (c) {
# EDIT: "Plane Difference: this filter can only be used within run-time filters.
diff = YDifferenceToNext(c, -1) # requires local=true, else error message
c

} , after_frame=true, local=false)
*/

Colorbars.Killaudio.ConvertToYV12

Function func(clip c) {
diff = YDifferenceToNext(c, -1) # EDIT: Works. Does NOT require local=true
c.Subtitle(String(diff))
}

SSS = """
func()
"""

ScriptClip( SSS , after_frame=true, local=false)

And

/*
ScriptClip( last, function [] (c) {
global PrevFrameNumber = PrevFrameNumber + 1 # doesn't work, just stays at 1
c.SubTitle(String(PrevFrameNumber))
} , after_frame=true, local=true)
*/


Colorbars.Killaudio.ConvertToYV12

Global PrevFrameNumber = 0

Function func(clip c) {
Global PrevFrameNumber = PrevFrameNumber + 1 # EDIT: Works, Does NOT stay at 1
c.SubTitle(String(PrevFrameNumber))
}

SSS = """
func()
"""

ScriptClip( SSS , after_frame=true, local=true)


EDIT: Both above WORK OK.

[Rob105]

path = "C:\Video\"

v0 = FFmpegSource(path + "video.mp4")

v1 = ImageSource(path + "Colors Gradient Horizontal 1920x1080.jpg", fps=50, end = 299).crop(0,980,0,0)
v2 = ImageSource(path + "BW Gradient Horizontal 1920x1080.jpg", fps=50, end = 299).crop(0,980,0,0)

StackVertical(v0, v1, v2)
Avisynth open failure: StackVertical: image formats don't match

How do i make it work?

Source files https://www.upload.ee/files/15277223/video.zip.html

[flossy_cake]

EDIT: Both above WORK OK.

Hmm neither are working for me - I'm getting the same result as the previous samples. I copy pasted your exact code so I'm not sure what's going on. What version Avisynth are you using? I've got 3.7.3 (r3936, 3.7, x86_64).

[FranceBB]

How do i make it work?


Easy peasy lemon squeezy: a simple Converttoyv12() after you index the images will do it. ;)


FFMPEGSource2("D:\video\video.mp4", fpsnum=50000, fpsden=1000, atrack=-1)

img1=ImageSource("D:\video\Colors Gradient Horizontal 1920x1080.jpg", fps=50, end=212).crop(0, 980, 0, 0).Converttoyv12()

img2=ImageSource("D:\video\BW Gradient Horizontal 1920x1080.jpg", fps=50, end=212).crop(0, 980, 0, 0).Converttoyv12()


StackVertical(last, img1, img2)



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


Explanation:

when you stack together different clips, they must all be the same, so you need to convert either the original video file you're indexing to reflect the two jpg you're trying to add on OR the other way around. In the example, I've done the opposite, so I've converted the two images to yv12 (4:2:0 planar 8bit).


I can now shut down my computer and go to bed :P

[StainlessS]

Hmm neither are working for me - I'm getting the same result as the previous samples. I copy pasted your exact code so I'm not sure what's going on. What version Avisynth are you using? I've got 3.7.3 (r3936, 3.7, x86_64).

v3.7.3(r3825,master, x86_64)

EDIT: Re-checked and both do work OK here.
Perhaps others with either version could verify results.

[flossy_cake]

v3.7.3(r3825,master, x86_64)

EDIT: Re-checked and both do work OK here.
Perhaps others with either version could verify results.

Thanks, I tried a few other versions without luck. In the end I got it working by copying exactly what Gavino's SRestore does:


global count = 0

ScriptClip(last, "MyFunc(last, current_frame)", after_frame=true, local=false)

function MyFunc(clip c, int current_frame) {

global count = count + 1
diff = YDifferenceToNext(c, -1)
c.SubTitle(string(diff) + ", " + string(count))
}


Passing current_frame to MyFunc is what makes it work for me, otherwise I get "this filter can only be used within run-time filters".

Hopefully there is no other weird side effect of doing it this way, but I've got a feeling it's going to be weird about something.

[StainlessS]

Also, the first of the scripts [works for me, not for you], kinda surprised me,
I was under the impression that current_frame did not survive when calling a function,
stangely it worked for me in that script where I might have expected it not to.
[perhaps something strange in the version I'm currently using].

Passing current_frame to MyFunc is what makes it work for me, otherwise I get "this filter can only be used within run-time filters".

Yep, I posted similar in Usage a little while ago.
https://forum.doom9.org/showthread.php?p=1986042#post1986042
Current_frame is not available outside of the runtime environment, and dont make much sense there either.
But, (probably not of use in required case) you can hack a one time use (on a single frame) just by setting
it to that frame number, eg


blankclip(length=100,pixel_type="YV12")
C = Last.BlankClip(length=0) # zero len clip, same characteristics as Last clip
For(n=0,FrameCount-1) {
current_frame = n # HACK for below AverageLuma
Y = AverageLuma # access frame n
T = Trim(n,-1)
T = T.Subtitle(String(n) + String(Y," : %f"),align=5)
C = C ++ T # add single frame n, to clip so far
}

C # Play C


current_frame is set only for use within runtime (eg by ScriptClip) where it is initialised before each frame that is processed by
the script arg of Scriptclip. Hacking current_frame to some number just allows to use some runtime func (eg AverageLuma), on that SINGLE frame.

EDIT:
Nuther script of limited use

blankclip(length=100,pixel_type="YV12")

Function SomeFunc(clip c, int n) { # Dont think current_frame is visible within this func, but can be provided by caller in n
current_frame = n
Y = c.AverageLuma
Return Y
}

SSS="""
Y = SomeFunc(Last,current_frame)
return Subtitle(String(current_frame) + String(Y," : %f"))
"""

ScriptClip(SSS)


# ...



EDIT:
Function SomeFunc(clip c, int current_frame)
Does not taste quite right to me, so I used an int n then assigned to current_frame internal to function.

[Gavino]

Also, the first of the scripts [works for me, not for you], kinda surprised me,
I was under the impression that current_frame did not survive when calling a function,
stangely it worked for me in that script where I might have expected it not to.
[perhaps something strange in the version I'm currently using].
Are you using GRunT's ScriptClip()?
In GRunT (unlike vanilla Avisynth 2.x), current_frame is a global variable (though still of course only visible inside the run-time environment).
Avs+ has incorporated some functions of GRunT, but I'm not sure if this one applies there.

[StainlessS]

Are you using GRunT's ScriptClip()?
Yep, renaming Grunt.dll so as not to use it,

1st script produces error report.

2nd script, shows subtitle '1' for all frames.

Cheers Gavin. [nice Welsh name].

[DTL]

Made new version of converter to RGB32 - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.4.0

It is finally more correct processing in 16bit intermediates and in narrow range the resudual error only about +1LSB. After gained to Full range - at some colours may reach error of 2LSB.

Also when compared to ConvertToRGB32(matrix="PC.709") it was found that matrix (coefficients ?) in AVS core is somehow broken:

At script:

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()

ConvertToRGB32(chromaresample="point", matrix="PC.709")


Output for colours (R,G,B):
Yellow 181, 180, 12
Cyan 12, 181, 180
Green 13, 181, 12
Magenta 183, 15, 184
Red 184, 15, 16
Blue 15, 16, 184

The DecodeYUVtoRGB with narrow range mapping (gain=64 and offset=16) keep output in 15..17 and 179..181 range. It was found with math simulation the 8bit YUV can not be decoded to ideal 16 and 180 RGB at all colours because or already rounding errors in 8bit YUV. So only with 10bit and more it can be reach ideal 16 and 180 levels output.

Also added 32bit immediates processing mode - it run 2+ times slower at AVX2 and provide only slightly better precision in the Full range mapping (error looks like +-1LSB). And close to no better in narrow range. So it looks 32bit immediate processing only required for >8bit sources and results. And can make a bit better precision with 8bit output only if input is >8bit.

For some possible future of fastest 16bit immediate processing engine for YV12 to RGB32 it is possible to play with coefficients tweaking and rounders tweaking and may be reduce average error over all possible range of YUV input 8bit values - using some math simulator engine. But it require programmer of such optimizing engine.

Also added x86_32 build if someone still use 32bit Windows. It runs only slightly slower (register file size in 32bit CPU mode is 1/2 of size and compiler make more data temporal store/load from cache).

[kedautinh12]

First time for 32 bit from DTL :D

[poisondeathray]

Note that "PC matrices" are not quite the same thing as "Studio RGB", or "limited range RGB" used in broadcast or some NLE's

The equivalent way in avisynth as what's used a Studio RGB NLE (like vegas) for 8bit for that example above would be


ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()
Levels(0,1,255,16,235, coring=false)
ConvertToRGB32(chromaresample="point", matrix="rec709")


Y 180,179,16
C 16,181,179
G 16,179,14
M 179,16,181
R 180,16,17
B 15,16,180

There was an old dedicated "studio RGB" function by "trevlac" for avisynth


EDIT:
It should be coring=false . Limiting (for example 0,255) is separate . Nominal Black to white is defined as 16 to 235 for studio RGB, but you can have superblack, superwhite . If you clip it in the levels (coring=true), you never get superblack or superwhite

[DTL]

What was the reason for such strange matrix ? Wiki says PC-matrix keep range unchanged. But ColorBarsHD already create levels in standard (industry ITU-R/ARIB) narrow range. Additional Levels of 0,255 to 16,235 looks like compress range even more ? Also aditional Levels() make precision and performance lower - may be add one more single-filter 'matrix' to ConvertToRGB() to create 16..235 RGB from 16..235 standard YUV ?

Also using Levels() for >8bit create additional nightmare for users to compute correct params because it is not autoscale.

Also it is good to add into documentation (wiki ?) about PC-matrix only in Convert() do not keep range in 16..235 (as input) but create some distorted RGB decode (above possible compute errors for 8bit in/out) in narrow-like levels if input standard narrow range not additionally compressed with Levels() processing.

"First time for 32 bit"

I see avspmod still release 32bit builds and require 32bit .dll for it. But I think at AVX2 chips users mostly running x64 OS so 32bit builds a not very required. With intrinsics-based SIMD program 32bit builds are easily possible (mostly all instructions have 32bit versions) but may have somehow lower performance because in 32bit mode addressable by instructions register file space is 1/2 of total.

[Rob105]

When opening Avisynth script is there command to get windows open file window to populate variable with the video.

Purpose is i have script that do not change at all, but file i apply script to changes a a lot, i don't want to type file name in script, i want to use windows open file dialog to populate it.

How i apply Avisynth script to all video files in folder, batch?

[FranceBB]

How i apply Avisynth script to all video files in folder, batch?

Let me introduce you to the fantastic world of FFAStrans: https://forum.doom9.org/showthread.php?t=176655
It does exactly what you want in terms of automation.
Just add a watchfolder -> A/V Decoder -> Custom Avisynth Script (doing whatever you want) -> Encoder -> Delivery
works every time. ;)

[DTL]

Note that "PC matrices" are not quite the same thing as "Studio RGB", or "limited range RGB" used in broadcast or some NLE's

The equivalent way in avisynth as what's used a Studio RGB NLE (like vegas) for 8bit for that example above would be


ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToYV12()
Levels(0,1,255,16,235)
ConvertToRGB32(chromaresample="point", matrix="rec709")


Y 180,179,16
C 16,181,179
G 16,179,14
M 179,16,181
R 180,16,17
B 15,16,180

There was an old dedicated "studio RGB" function by "trevlac" for avisynth

I tried 2 more plugins for convert: avsresize and fmtc - they both output equal RGB in narrow range and can accept feed from ColorBarsHD directly:

Y 180, 180, 16
C 16, 180, 179
G 16, 180, 15
M 180, 16, 181
R 180, 16, 17
B 16, 16, 180

So it looks only AVS internal 'narrow' matrix is something special and of lowest precision if even feed by 'double-narrow' 8bit YV24.

[poisondeathray]

What was the reason for such strange matrix ?

Not sure what the "PC matrix" was originally for. Back then, people didn't know what "studio RGB"/"limited range RGB" was.

I tried 2 more plugins for convert: avsresize and fmtc - they both output equal RGB in narrow range and can accept feed from ColorBarsHD directly:

Y 180, 180, 16
C 16, 180, 179
G 16, 180, 15
M 180, 16, 181
R 180, 16, 17
B 16, 16, 180


zimg/avsresize seems better/faster for just about everything in terms of pixel format conversions than internal functions.

[Rob105]

Subtitle() (http://avisynth.nl/index.php/Subtitle) problem.

Subtitle("Hello World!", font="Arial", size=34, text_color=color_gold, halo_color=color_black, align=1, x=20)

Shows text in bottom left corner, if i add y=-20 to move text 20 pixels up from bottom left corner, text disappears.

I have to use frame height 1080 minus 20 = 1060 in y value.

Subtitle("Hello World!", font="Arial", size=34, text_color=color_gold, halo_color=color_black, align=1, x=20, y 1060)

this is major annoyance that whenever i set y value for Subtitle() function it starts to move text from top rather than its current position, am i doing something wrong or its a bug? I use AviSynthPlus_3.7.2_20220317_vcredist.exe


Let me introduce you to the fantastic world of FFAStrans: https://forum.doom9.org/showthread.php?t=176655
It does exactly what you want in terms of automation.
Just add a watchfolder -> A/V Decoder -> Custom Avisynth Script (doing whatever you want) -> Encoder -> Delivery
works every time. ;)

Thanks will give it a try.


Easy peasy lemon squeezy: a simple Converttoyv12() after you index the images will do it. ;)

Explanation:

when you stack together different clips, they must all be the same, so you need to convert either the original video file you're indexing to reflect the two jpg you're trying to add on OR the other way around. In the example, I've done the opposite, so I've converted the two images to yv12 (4:2:0 planar 8bit).



Thx for explaining.

[StainlessS]

When opening Avisynth script is there command to get windows open file window to populate variable with the video.

Purpose is i have script that do not change at all, but file i apply script to changes a a lot, i don't want to type file name in script, i want to use windows open file dialog to populate it.

How i apply Avisynth script to all video files in folder, batch?

1) Not exactly what you want but might like to know if its existence.
From RT_Stats plugin. https://forum.doom9.org/showthread.php?t=165479

RT_FSelOpen(string "title"="Open",string "dir"="",string "filt",string "fn="",bool "multi"=false,bool "debug"=false)

Function to select EXISTING filename using GUI FileSelector.

Title = Title bar text.
Dir = Directory, "" = Current
Filt = Lots, eg "All Files (*.*)|*.*"
[Displayed text | wildcard] [| more pairs of Displayed text and wildcard, in pairs ONLY].
first one is default.
fn = Initially presented filename (if any).
multi = Multiply Select filenames. Allows selection of more than one filename at once.
debug = Send error info to DebugView window.

Returns
int, 0, user CANCELLED.
int, non zero is error (error sent to DebugView window).
String, Filename selected, Chr(10) separated multiline string if MULTI==true (and multiple files selected).

Example, to prompt for an AVI file and play it.
avi=RT_FSelOpen("I MUST have an AVI",filt="Avi files|*.avi")
Assert(avi.IsString,"RT_FSelOpen: Error="+String(avi))
AviSource(avi)

***
***
***

Function RT_FSelSaveAs(string "title"="Open",string "dir"="",string "filt",string "fn="",bool "debug"=false)

Function to select filename for Save using GUI.

Title = Title bar text.
Dir = Directory, "" = Current
Filt = Lots, eg "All Files (*.*)|*.*"
[Displayed text | wildcard] [| more pairs of Displayed text and wildcard, in pairs ONLY].
first one is default.
fn = Initially presented filename (if any).
debug = send errors to DebugView window.

Returns
int, 0, user CANCELLED.
int, non zero is error (error sent to DebugView window).
String, Filename selected.
Will prompt to overwrite if file already exists.

***
***
***

Function RT_FSelFolder(string "title"="",string "dir"=".",bool "debug"=false)

Function to select Folder using GUI.

Title = UNDERNEATH the title bar text, for instructions.
Dir = Directory, Default "." = Current, ""=Root.
debug = Send errors to DebugView window.

Returns
int, 0, user CANCELLED.
int, non zero is error (ie -1, error sent to DebugView window, usually selecting non Folder object eg 'My Computer').
String, Folder selected (minus trailing BackSlash).


2) Avisynthesizer_Mod
A SendTo App that allows Windows Explorer selection of video files and fills in a user supplied Template with the filenames.
Can concatenate (join/splice) selected files (default as original non mod version) and create a single output AVS file OR,
batch create multiple AVS files, one for each input source file (MOD version only).
Has a GUI to select required template and sort input files if multiple input files selected.

https://forum.doom9.org/showthread.php?t=166820

Also, This thread is Avisynth Development thread, not really for asking questions on Usage, Avisynth Usage forum appropriate place for that.

Do not reply in this thread to this post, thanx.

[Rob105]

Do not reply in this thread to this post, thanx.
Do not tell others what to do, thanks.

[kedautinh12]

Do not tell others what to do, thanks.

StainlessS right, you ask wrong thread, you need create a thread in avisynth usage

[gispos]

Made new version of converter to RGB32 - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.4.0

It is finally more correct processing in 16bit intermediates and in narrow range the resudual error only about +1LSB. After gained to Full range - at some colours may reach error of 2LSB.

Yes, the colors are even better (more accurate) and I am glad that there is also a 32bit dll.
Thanks again for your work. I hope you don't mind because I deliver the dll with AvsPmod.

Edit:
I think you have something mixed up

Full range - gain=74, offset=0,
narrow range - gain=64, offset=16,
zero black and non-clipping superwhited - gain=69, offset=0.

should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0

[DTL]

"should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0"

No. In latest version the computing of R,G,B changed significantly (the 16 is subtracted from Y at first). So in old versions (not correct) the computing make R,G,B in 16..235 range, and in latest version it is in 0..219 range (with signed integer 16bit format so underblacks are negative).

0..219 range with negative underblacks is not standard to either narrow or full range in 8bit output. So to make it narrow - addition of 16 only required and to make it full - multiplication to (255/219)*64=74.5 only. So to output narrrow range it is now required gain=64 (no gain), offset=16. So to output full range - gain=74, offset=0 (no offset). To make computing a bit faster I even thing about templating main processing function even more so it can skip multiplication and addition of rounder and shifting if only addition of offset of 16 is required or skip addition if only range scaling is required. But it still not implemented because may not make significant difference in performance and make program text even more complex. And I think multiplication to 64 with addition of rounder of 32 and integer shift to 6 bits to the right (/64) not make precision lower in compare with skipping this operation (may be I not correct here because addition of rounder 32 may somehow change output in worse precision ?) in case of outputting narrow range with gain=64 and offset=16. So currently 'proc-amp' of gain+offset always full active. Also it may be some research if the sequence of operations of multiplication (range scale) and addition may make residual errors less - may be it is more better to make addition of offset first and next is scale. The total performance may be not any depend of the sequence of operations but residual error over all RGB range may change somehow. So current version have some internal features not completely optimized for case of gain only (no offset) and offset only (no gain) operations. Also the non-clipping superwhites monitoring setting of gain=69, offset=0 also required no offset so do-nothing addition of 0 may be skipped with some very small performance gain. Though most of expected operations with output full-RGB and non-superwhites clipping RGB both require full scale operation (of 3 stages - integer multiplication, addition of rounder and div-shifting). So only may be currently rare-needed narrow-RGB output may possibly benefit a bit in precision and performance if the scale/gain 3 operations may be skipped in completely template-based if-then new version. But it require even more complex selector of processing function (if gain=64 - select no-gain proc function version and if gain !=64 - select gain-proc function version). It may finally require redesign all large number of combinations params selector to 'tuple-type' like was implemented in mvtools by pinterf and not large and very complex set of if-else statements (they can also eat some performance and make program text harder to design and understand). May be will try it in some next versions.

Also about possible precision optimizations: Current computing of RGB performed not with 3x3 matrix multiplication and additions but with 'classic' RGB equations and with 16bit signed immediates:

R = (Y-16) + (Kr * (V-128) + 32) >> 6;
B = (Y-16) + (Kb * (U-128) + 32) >> 6;
G = (Y-16) - (Kgu * (U-128) + 32) >> 6 - (Kgv * (V-128) + 32)>>6;

this produce RGB in 0..219 range.

and proc-amp to make required range mapping
Val = ((Val * gain) + 32) >> 6) + offset;

So it have internally 16, 128 and 32 lots of hidden constants and matrix-dependent Kr, Kb, Kgu, Kgv coefficients and may be using some optimizing software (like zopti ?) there constants and coefficients may be tweaked so the absolute mean error over possible RGB output values may be reduced to minimum (in both or separate narrow-range RGB output mode and/or full-range RGB). But it require to run optimizer software with about 18 input variables (of 16bit signed short each) to optimize - may be long to run and I still not know this ready to use optimizer software (with brute-force search for example in +-defined range for each variable). May be some simple C-program may be designed to make this optimizing search.

16bit immediate computing allow to about double performance of AVX-engine in compare with 32bit immediate but not allow to accumulate several multiplication results before addition of rounder and div-shifting.
With 32bit immediate the possible computing is like

R = (R (Y, Kr, V, gain, offset) + rounder(4096)) >> 13; so it possibly have less rounder addition operations and div-shifts but total compute performance in 32bit IOPS is only 1/2 of 16bit IOPS for AVX-engine. Also the total workunit size for 32bit immediate only 1/2 of 16bit immediate computing (32 or 64 RGB triplets per 1 SIMD pass for AVX2). So the 32bit immediate computing mode can be also checked for performance in 3x3-matrix way of computing (as in AVS core now). The simple redesign of non-matrix computing to 32bit immediate shows it is about 2+x times slower.

[gispos]

"should be

Full range - gain=64, offset=16
narrow range - gain=74, offset=0"

No. In latest version the computing of R,G,B changed significantly (the 16 is subtracted from Y at first). So in old versions (not correct) the computing make R,G,B in 16..235 range, and in latest version it is in 0..219 range (with signed integer 16bit format so underblacks are negative).

Then I'll probably mess something up. I asezoate 'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255

Is that correct?
But I just saw that if I look at a YV12 with PC-levels I get only 235 as white value and with TV-levels 255 (RGB value).

I am completely confused now, where is my thinking error?

AvsPmod Display setting TV-Levels:
ConvertToRGB32("Rec709") and DecodeYUVtoRGB(matrix=1, gain=74, offset=0) are the same (I thought this is narrow range)

AvsPmod Display setting PC-Levels:
ConvertToRGB32("PC709") and DecodeYUVtoRGB(matrix=1, gain=64, offset=16) are equal (I thought this is full range)

[StainlessS]

Then I'll probably mess something up. I asezoate 'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255
Google guesses that you mean "associate" there. [better than my guess which did not exist]

[DTL]

"'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255"

Yes - in EBU terms narrow range is 16..235. And PC is not limited to any range mapping but widely used at PCs sRGB uses 0 black and 255 max (and nominal ?) white.

"AvsPmod Display setting TV-Levels:
DecodeYUVtoRGB(matrix=1, gain=74, offset=0) are the same (I thought this is narrow range)"

In latest version with 0..219 computing it is not correct. The 'narrow' integer range mapping is also 'shifted/offsetted range' - its black is offsetted to code value 16 in 8bit words to have some footroom for underblacks in same 8bit unsigned words. Underblacks (and superwhites) typically not exist in PC-sRGB so sRGB (named also full) not require such shift and compression of nominal white to under-255 area.

Also PC-users like to map nominal 'moving pictures' white of 235 to max sRGB 255 white (so possible valid superwhites of 'motion pictures' become clipped). It is just one of widely used practice - other users may like to monitor up to at least 254 'moving pictures' Y/RGB non-clipped or even route RGB datastream to 'video/motion pictures/professional' display device (not sRGB PC monitor) - so that device will handle all levels in 0..255 code words in 'narrow mapping' as it should (with both scaler and displaying of superwhites).

So to convert computed in 0..219 RGB signed 16bit integer to narrow/shifted unsigned integer it is required to add only offset of 16. After adding offset of 16 it will map to 16..235 (it not mean 0..15 and 236..255 code values are not used - they may be populated with underblacks and superwhites).

" DecodeYUVtoRGB(matrix=1, gain=64, offset=16) are equal (I thought this is full range)"

To convert 0..219 into full-sRGB range only gain/scale with 255/219 ratio required so it is DecodeYUVtoRGB(matrix=1, gain=74, offset=0). Negative underblacks below 0 in signed 16bit integers are auto-cut-off by saturated 16bit signed to 8bit unsigned SIMD conversion at 8bit RGB producing so not require additional handling.

[gispos]

"'narrow range' with TV-levels 16-235 and 'full range' with PC-levels 0-255"

Yes - in EBU terms narrow range is 16..235. And PC is not limited to any range mapping but widely used at PCs sRGB uses 0 black and 255 max (and nominal ?) white.

Described the other way:

ConvertToRGB32("Rec709") visually looks like DecodeYUV(matrix=1, gain=74, offset=0).
And "Rec709" is called TV-levels, so narrow range

ConvertToRGB32("PC709") visually looks like DecodeYUV(matrix=1, gain=64, offset=16).
And "PC709" is called PC-levels, so full range

But you write:
narrow range = gain=64, offset=16
full range = gain=74, offset=0

But it doesn't matter, I use it in a way that it matches the other settings.

[DTL]

First you need to download latest ver 0.4.0 (all previous uses different RGB computing and require different output proc-amp settings for levels mapping).

Test script for both levels and performance is

LoadPlugin("DecodeYUVtoRGB.dll")

ColorBarsHD(640, 480)
ConvertToYV12()

// make caching of YV12 to skip ConvertToYV12 compute at each frame for performance check
Trim(1,1)
Loop(1000000)

DecodeYUVtoRGB(matrix=1, gain=64, offset=16)


I open it in the VirtualDub and Ctrl+1 frame to buffer and paste into MS Paint to check levels in code values with colour pick tool (not simply look into image) -
Its Yellow patch RGB is in the narrow range of 180 and 16. 180 is computed to 180-16=164 164/219=~0.75 and it looks correct for 75% colour bars (in transfer-domain, not linear).

Also in VirtualDub monitor window it is visible all black level setup patches are visible (using PC sRGB monitor mode) - so black is shifted/offsetted to higher levels from normal display. If user have PC or other display with switching to limited/narrow/16-235 levels display - it may be switched to that mode and black will be placed to nominal.

For full range -
DecodeYUVtoRGB(matrix=1, gain=74, offset=0)

Now Yellow patch RGB is in range 190 and 0 - it is full (sRGB) range mapping with zero black for sRGB black display.

ConvertToRGB32(matrix="Rec709") - output Yellow RGB in 191 and 0 range - so it is equal to full/sRGB.

ConvertToRGB32(matrix="PC.709") - output Yellow RGB in 181/180/12 - it is somehow 'broken' narrow/limited range.

Also some info on YUV to RGB computing:
The simple equations of
R,B = Y + (Kb, Kr) * (U, V)
G = Y - Kgu * U - Kgv * V

Looks only work for YUV in 0.0f..1.0f range and produce RGB in 0.0..1.0f range. It was designed for some abstract YUV also may be analog range 0 to 0.7V , bipolar voltage with negative underblacks.

Digital YUV with unsigned integers code values have scaled and biased range, also not equal Y and UV scale:
Digital Y is Y*219 + 16
Digital UV is UV*224 + 128
(looks like equal for all commonly used standards of 601/709/2020)

So before start computing of RGB it is required both subtraction of bias of 16 and 128 from Y and UV and also make scale of UV and Y equal (for example division of UV to 224/219=1.02283). The additional division may be included into Kr,Kb, Kgu, Kgv coefficients of computing to make processing faster.

So version of DecodeYUVtoRGB from 0.4.0 have both Y-16 added and division of UV to 1.02283 included - so total compute errors in RGB expected to be lower. But it also cause range shift to 0..219. Also it adds some performance penalty over versions before 0.4.0 but I hope not very visible.

[poisondeathray]

What was the reason for such strange matrix ? Wiki says PC-matrix keep range unchanged.


PC matrix still has usage scenario - for full range video. Y=0 black , Y=255 white . Many videos are full range out of the camera (e.g. gopro, many consumer cameras, some phones), gameplay recordings

If you take a perfect full range ramp Y 0-255 from a 256 width video. The pc matrix returns RGB 0-255. Each x-coordiante produces perfect RGB value. (e.g. x position 96 would equal RGB 96,96,96)


BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")


Neither of the DecodeYUVtoRGB variants produce the 1:1 mapping desired result in this case, there are values repeated and missing


For 'Full' levels mapping: DecodeYUVtoRGB(matrix=0, threads=1, gain=74, offset=0)

For non-clippig superwhites monitoring or other processing with zero black: DecodeYUVtoRGB(matrix=0, threads=1, gain=69, offset=0)

[DTL]

So we have different YUV->RGB conversion tools for different use cases. My version designed to better decode colour bars from some (Japan/Asian ?) ARIB standard YUV implemented in AVS ColorBarsHD() source. I not test extreme 'full YUV' values.

"If you take a perfect full range ramp Y 0-255 from a 256 width video. The pc matrix returns RGB 0-255. Each x-coordiante produces perfect RGB value. (e.g. x position 96 would equal RGB 96,96,96)"

But to decode output of ColorBarsHD with better low/high RGB mapping to 16 and 180 it require additional Levels() processing ?

"Neither of the DecodeYUVtoRGB variants produce the 1:1 mapping desired result in this case, there are values repeated and missing"

Hmm - the initial design of DecodeYUVtoRGB is to decode 'always narrow/limited' YUV to either narrow/limited or 'full' or other RGB. I not test it with 'full YUV' input. I even not shure how awful nightmare may be full-YUV in 8bit if our 'normal YUV narrow/limited' already produce out-of-range RGB triplets. Though if this 'full YUV' is encoded from game capture with RGB full-range initially it will simply not have some extreme YUV triplets ?

As I read the PC-matrix is 'not change range'. So if you provide 'full YUV' and want 'full RGB' (unchanged range) it probably will be with
DecodeYUVtoRGB(matrix=0, threads=1, gain=64, offset=16) (no gain, offset 16 to compensate for input Y-16).

So gain=64, offset=16 proc-amp setting should work as 'not change range' - if narrow/limited input - it will also output narrow/limited. Also if full input - it will also output full. And gain=74, offset=0 is 'expand from narrow/limited to full' range setting.

Also if user want full YUV to narrow/limited RGB conversion it may be gain=55 ((219/255)*64) and offset=16 (may be someone need such conversion too).

[poisondeathray]

But to decode output of ColorBarsHD with better low/high RGB mapping to 16 and 180 it require additional Levels() processing ?


Yes for PC matrix. That was demonstrated earlier. PC matrix is not the same thing as "Studio RGB"



Though if this 'full YUV' is encoded from game capture with RGB full-range initially it will simply not have some extreme YUV triplets ?

Probably - Game captures begin as RGB (and some people capture as RGB for higher quality, eg. Fraps) ,but many people capture as full range YUV. The conversion is 8bit RGB to 8bit YUV full range using something similar to PC matrix

But full range YUV camera recordings are internally raw, debayered to RGB and processed at higher bitdepths, then converted to usually 8bit 4:2:0 full range for the recording format. Some recording formats are 10bit 4:2:0 now, 10bit is becoming more commonplace in consumer world


As I read the PC-matrix is 'not change range'. So if you provide 'full YUV' and want 'full RGB' (unchanged range) it probably will be with
DecodeYUVtoRGB(matrix=0, threads=1, gain=64, offset=16) (no gain, offset 16 to compensate for input Y-16).


Not change min,max range, or intermediate ranges ? For Y values on the grey ramp , none of the values are changed . Y = R = G = B

Yes that's equivalent to pc matrix for Y values on the ramp . Not sure about colors. But it is a valid usage case, I suggest you add that example to the documentation examples.

[DTL]

"PC matrix is not the same thing as "Studio RGB"

As practice show the YUV to RGB decoder may have its own Transfer Function. Even if it is linear it can do range remapping. So for AVS core the rec709 is range expanding Transfer Function embedded in transform. For PC.709 it is range no change ? So if narrow/limited at input - it will also output narrow/limited (but looks not completely and not match other plugins).

"Not change min,max range, or intermediate ranges ?"

As Transfer Function of typical YUV to RGB conversion expected to be linear - so all immediate code values should follow general range remapping. Only compute/rounding quantization errors may make some additional digital-noise.

I not sure if fixed Y-16 internal will make best RGB for full-YUV input. So it looks the YUV to RGB need to have adjustable proc-amps at input and at output. I will add Ybias and UVbias as new params in next builds. So Ybias will be -16 and UVbias -128 default. For full-YUV input it may be better to set Ybias=0 (and output offset to 0) ? The gains (for Y and UV) may be also important - but most easier to use without performance lost is UVgain only (it is additional multiplier to all UV coefficients). So may be UVgain (float) of 1.0 default better to add too.

Some full-YUV may use not 224 gain and not 128 offset for Digital UVs ?

[poisondeathray]

As practice show the YUV to RGB decoder may have its own Transfer Function. Even if it is linear it can do range remapping. So for AVS core the rec709 is range expanding Transfer Function embedded in transform. For PC.709 it is range no change ? So if narrow/limited at input - it will also output narrow/limited (but looks not completely and not match other plugins).


That's why I like zimg better. You can specify input/output ranges, matrix, transfer, primaries. fmtc is slower but has additional transfer curve options



I not sure if fixed Y-16 internal will make best RGB for full-YUV input. So it looks the YUV to RGB need to have adjustable proc-amps at input and at output. I will add Ybias and UVbias as new params in next builds. So Ybias will be -16 and UVbias -128 default. For full-YUV input it may be better to set Ybias=0 (and output offset to 0) ? The gains (for Y and UV) may be also important - but most easier to use without performance lost is UVgain only (it is additional multiplier to all UV coefficients). So may be UVgain (float) of 1.0 default better to add too.

Some full-YUV may use not 224 gain and not 128 offset for Digital UVs ?

I think it's better to have options . There are different valid usage scenarios


For reference, this is what vegas is doing with the studio RGB interpretation of the grey ramp. The R channel was extracted and waveform plotted with histogram (on colorbars it gets 180 and 16 for primaries +/-2 for 8bit bars, perfect for 10bit bars) .

So there appears to be a discrepancy in the low and high values and the slope. Vegas' studio RGB interpretation appears linear, with some repeats/gaps. The internal levels(0,1,255,16,125,false) + ConvertToRGB appears close approximation, but with more gaps than vegas'

https://i.postimg.cc/59wrNZ5B/decodeyuvtorgb-compare.png (https://postimages.org/)

[DTL]

New version - https://github.com/DTL2020/ConvertYUVtoRGB/releases/tag/0.4.1

Defaut params values for input YUV proc-amp (Ybias=-16, UVbias=-128, UVgain=1.0) selected to make things unchanged for 'standard narrow YUV' input.

For full-YUV you can now test Ybias=0, gain=64, offset=0. It expected to decode colours in case of full-YUV input more precisely. But I not have full-YUV test charts to test it. Also user may try to tweak UVgain for either some saturation tweaking or for better dematrix if full-YUV source uses non-224 scale for Digital UV. UVgain may be as low as 0.0 - no colour (black and white equal RGB - copy of Y to RGB channels). Too high UVgain values may cause 16bit processing overflows and severe distortions. It is expected to be some fine tuning. For the case some source may use 219 scale for Digital UV for example. So UVgain may be in about 0.9..1.1f range.

All these adjustments should be no change in performance (no changes to processing core).

The shape of the computing errors of different engines with linear ramp input may be interesting.

I tried to use HistogramRGBParade script from http://avisynth.nl/images/Histograms_in_RGB_%26_CMY.avsi to display such graphs - but it cause VirtualDub crash with AVS+ 3.7.3 (some build) and 3.6.1 and masktools latest (?) 2.2.30. With both my plugin and ConvertToRGB32 conversion with script:


LoadPlugin("masktools2.dll")


function HistogramRGBLevels( clip input, bool "range", float "factor" )
{
return HistogramRGBLevelsType( input, input.ConvertToRGB(), $800000, $008000, $000080, range, factor )
}

function HistogramCMYLevels( clip input, bool "range", float "factor" )
{
return HistogramRGBLevelsType( input, input.ConvertToRGB().Invert(), $008080, $800080, $808000, range, factor )
}

function HistogramRGBParade( clip input, float "width" )
{
return HistogramRGBParadeType( input, input.ConvertToRGB(), $800000, $008000, $000080, width )
}

#---

# Generic levels form, not very useful as a standalone function
function HistogramRGBLevelsType( clip input, clip rgb, int color1, int color2, int color3, bool "range", float "factor" )
{
range = default(range,true)
ChannelHeight = 64
Gap = 8 # divisible by 4

r = rgb.ShowRed ("YV12").HistogramChannel("Levels", color1, "add", ChannelHeight, range, factor)
g = rgb.ShowGreen("YV12").HistogramChannel("Levels", color2, "add", ChannelHeight, range, factor)
b = rgb.ShowBlue ("YV12").HistogramChannel("Levels", color3, "add", ChannelHeight, range, factor)
gap = BlankClip(r, height=Gap)
hist = StackVertical(r,gap,g,gap,b).ConvertToMatch(input)
return input.Height() > hist.Height() ? \
StackHorizontal(input, hist.AddBorders(0,0,0,input.Height() - hist.Height())) : \
StackHorizontal(input.AddBorders(0,0,0,hist.Height() - input.Height()), hist)
}

# Generic parade form, not very useful as a standalone function
function HistogramRGBParadeType( clip input, clip rgb, int color1, int color2, int color3, float "width" )
{
width = default(width,0.25)
Gap = 8 # divisible by 4

rgb = rgb.PointResize( m4(rgb.Width()*width), m4(rgb.Height()) ).TurnRight()
r = rgb.ShowRed ("YV12").HistogramChannel("Classic", color1, "chroma", 0, true)
g = rgb.ShowGreen("YV12").HistogramChannel("Classic", color2, "chroma", 0, true)
b = rgb.ShowBlue ("YV12").HistogramChannel("Classic", color3, "chroma", 0, true)
gap = BlankClip(r, height=Gap)
hist = StackVertical(r,gap,g,gap,b).TurnLeft().ConvertToMatch(input)
return input.Height() > hist.Height() ? \
StackHorizontal(input, hist.AddBorders(0,0,0,input.Height() - hist.Height())) : \
StackHorizontal(input.AddBorders(0,0,0,hist.Height() - input.Height()), hist)
}

# Used by functions above, not a standalone function
function HistogramChannel( clip input, string type, int color, string colorMode, int height, bool range, float "factor" )
{
input.Histogram(type, factor).Crop(input.Width(),0,0,height).Greyscale()
range ? last : Levels(128,1.0,255,0,255,false)
return Overlay(BlankClip(color=color), mode=colorMode)
}

# Returns "input" converted to same colorspace as "ref"
function ConvertToMatch( clip input, clip ref )
{
return ref.IsYV12() ? input.IsYV12() ? input : input.ConvertToYV12() : \
ref.IsRGB32() ? input.IsRGB32() ? input : input.ConvertToRGB32() : \
ref.IsRGB24() ? input.IsRGB24() ? input : input.ConvertToRGB24() : \
ref.IsYUY2() ? input.IsYUY2() ? input : input.ConvertToYUY2() : \
ref.IsYV16() ? input.IsYV16() ? input : input.ConvertToYV16() : \
ref.IsYV24() ? input.IsYV24() ? input : input.ConvertToYV24() : \
ref.IsY8() ? input.IsY8() ? input : input.ConvertToY8() : \
ref.IsYV411() ? input.IsYV411() ? input : input.ConvertToYV411() : \
input
}

# Convert value to multiple of 4 which is >= 16
function m4( float x ) { return (x < 16 ? 16 : int(round(x / 4.0) * 4)) }


BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")

ConvertToRGB32()
#DecodeYUVtoRGB(matrix=1, threads=1, cl=true, cs=false, gain=64, offset=16, ib=16, Ybias=-16, UVbias=-128, UVgain=0.0)

HistogramRGBParade()


Debugger shows

Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D070.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D070.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D070.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D070.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D240.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D290.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D290.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D9C0.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014D9C0.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014E030.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFA5458CF19 in Veedub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x000000000014E030.
Critical error detected c0000374
Veedub64.exe has triggered a breakpoint.


Not sure where is the bug - AVS or masktools or VirtualDub 1.10.4 ? The HistogramRGBParade is simply script for AVS and should not cause crashes ? AVSmeter looks like also crashes at startup (exit without error at F0 / T0.00), so it is not VirtualDub crash ?

The
mt_lutspa(mode="relative closed", expr="x 255 *")
produced some ramp without crash. Only call to HistogramRGBParade start crash. Is it some AVS+ core new crash ?

[StainlessS]

DTL,
Have you tried VirtualDub2 (VDub 1.10.4 Oct 2013, is pretty much abandoned).

VirtualDub2:- https://forum.doom9.org/showthread.php?t=172021
[SourceForge: Latest, March 2020, Version 20, VirtualDub_Pack: VirtualDub2_44282.zip]:- https://sourceforge.net/projects/vdfiltermod/files/

VirtualDub 1.10.4 is out (Oct 2013) :- https://forum.doom9.org/showthread.php?t=169640

[DTL]

Got VirtualDub2_44282 - also crashes. It draw wide frame (so got frame width/height from AVS OK) but next disappear-crash.

Debugger shows same errors -
Exception thrown at 0x00007FFA5458CF19 in VirtualDub64.exe: Microsoft C++ exception: ReturnExprException at memory location 0x0000000000CFCD20.
Exception thrown at 0x00007FFA5458CF19 in VirtualDub64.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
and so on.

So it is some AVS+masktools or AVS+ only crash ?

Without masktools it also crashes:


function HistogramRGBLevels( clip input, bool "range", float "factor" )
{
return HistogramRGBLevelsType( input, input.ConvertToRGB(), $800000, $008000, $000080, range, factor )
}

function HistogramCMYLevels( clip input, bool "range", float "factor" )
{
return HistogramRGBLevelsType( input, input.ConvertToRGB().Invert(), $008080, $800080, $808000, range, factor )
}

function HistogramRGBParade( clip input, float "width" )
{
return HistogramRGBParadeType( input, input.ConvertToRGB(), $800000, $008000, $000080, width )
}

#---

# Generic levels form, not very useful as a standalone function
function HistogramRGBLevelsType( clip input, clip rgb, int color1, int color2, int color3, bool "range", float "factor" )
{
range = default(range,true)
ChannelHeight = 64
Gap = 8 # divisible by 4

r = rgb.ShowRed ("YV12").HistogramChannel("Levels", color1, "add", ChannelHeight, range, factor)
g = rgb.ShowGreen("YV12").HistogramChannel("Levels", color2, "add", ChannelHeight, range, factor)
b = rgb.ShowBlue ("YV12").HistogramChannel("Levels", color3, "add", ChannelHeight, range, factor)
gap = BlankClip(r, height=Gap)
hist = StackVertical(r,gap,g,gap,b).ConvertToMatch(input)
return input.Height() > hist.Height() ? \
StackHorizontal(input, hist.AddBorders(0,0,0,input.Height() - hist.Height())) : \
StackHorizontal(input.AddBorders(0,0,0,hist.Height() - input.Height()), hist)
}

# Generic parade form, not very useful as a standalone function
function HistogramRGBParadeType( clip input, clip rgb, int color1, int color2, int color3, float "width" )
{
width = default(width,0.25)
Gap = 8 # divisible by 4

rgb = rgb.PointResize( m4(rgb.Width()*width), m4(rgb.Height()) ).TurnRight()
r = rgb.ShowRed ("YV12").HistogramChannel("Classic", color1, "chroma", 0, true)
g = rgb.ShowGreen("YV12").HistogramChannel("Classic", color2, "chroma", 0, true)
b = rgb.ShowBlue ("YV12").HistogramChannel("Classic", color3, "chroma", 0, true)
gap = BlankClip(r, height=Gap)
hist = StackVertical(r,gap,g,gap,b).TurnLeft().ConvertToMatch(input)
return input.Height() > hist.Height() ? \
StackHorizontal(input, hist.AddBorders(0,0,0,input.Height() - hist.Height())) : \
StackHorizontal(input.AddBorders(0,0,0,hist.Height() - input.Height()), hist)
}

# Used by functions above, not a standalone function
function HistogramChannel( clip input, string type, int color, string colorMode, int height, bool range, float "factor" )
{
input.Histogram(type, factor).Crop(input.Width(),0,0,height).Greyscale()
range ? last : Levels(128,1.0,255,0,255,false)
return Overlay(BlankClip(color=color), mode=colorMode)
}

# Returns "input" converted to same colorspace as "ref"
function ConvertToMatch( clip input, clip ref )
{
return ref.IsYV12() ? input.IsYV12() ? input : input.ConvertToYV12() : \
ref.IsRGB32() ? input.IsRGB32() ? input : input.ConvertToRGB32() : \
ref.IsRGB24() ? input.IsRGB24() ? input : input.ConvertToRGB24() : \
ref.IsYUY2() ? input.IsYUY2() ? input : input.ConvertToYUY2() : \
ref.IsYV16() ? input.IsYV16() ? input : input.ConvertToYV16() : \
ref.IsYV24() ? input.IsYV24() ? input : input.ConvertToYV24() : \
ref.IsY8() ? input.IsY8() ? input : input.ConvertToY8() : \
ref.IsYV411() ? input.IsYV411() ? input : input.ConvertToYV411() : \
input
}

# Convert value to multiple of 4 which is >= 16
function m4( float x ) { return (x < 16 ? 16 : int(round(x / 4.0) * 4)) }


BlankClip(length=1, width=256, height=256, pixel_type="Y8")

ConvertToRGB32()

HistogramRGBParade()

As a pure AVS script.
So need to be reported as bug at github ?

[poisondeathray]

I believe the crash is dimension related (width, height)
No crash if you resize to 640x480, preview , then change to 512x512. But it only works after you run a script first that works (this is in avspmod) . If you start with 512x512, it crashes

It's odd behaviour


BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")
ConvertToRGB(matrix="PC.601")
#pointresize(640,480) #1st run
pointresize(512,512)
histogramrgbparade


EDIT: actually I can't reproduce it consistently, it sometimes crashes. But resizing to 640x480 always works. It seems height related - you need a certain min height

[StainlessS]

With PDR script,

Windows Logs/Application: 0xc0000374, Heap Corruption.


Faulting application name: VirtualDub64.exe, version: 2.0.0.0, time stamp: 0x5e73f48a
Faulting module name: ntdll.dll, version: 10.0.19041.2788, time stamp: 0x2f715b17
Exception code: 0xc0000374
Fault offset: 0x00000000000ff449
Faulting process ID: 0x24f4
Faulting application start time: 0x01d99680ff1cb793
Faulting application path: C:\NON-INSTALL\VDUB\VDUB2\VirtualDub64.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 3170e74f-582d-40e8-891b-0847f484c03c
Faulting package full name:
Faulting package-relative application ID:

[DTL]

It is good to narrow where the initial C++ exception happen - may be in AVS core and passed via SEH stack into VirtualDub module and finally thrown to operating system so debugger point to the .exe module and not to AVS.dll ? Or in calling application ? But debugger point to ntdll.dll and it is Windows part and it may detect heap corruption with initial source in either AVS of VirtualDub ?

[flossy_cake]

Is there any possibility to upgrade DirectShowSource() to support pixel formats greater than 8-bits?

https://i3.lensdump.com/i/63lgbq.png

https://i.lensdump.com/i/63lZlD.png

[DTL]

RGB48 is 3x 16bit RGB ? So you can try to force output in RGB48. It will cover 10bit precision too.

[flossy_cake]

RGB48 is 3x 16bit RGB ? So you can try to force output in RGB48. It will cover 10bit precision too.

Yeah the wiki for DirectShowSource doesn't mention RGB48 as a supported pixel_type but I did try it anyway and it doesn't seem to work - no video frame displayed as if there isn't any video stream present, but audio still plays. RGB24 works though. Converting RGB24 to RGB48 with ConvertToRGB48() works and media player renderer reports pixel format RGB48LE. I don't really want to be converting to RGB in Avisynth as that involves chroma upscaling & matrix that I want to handle elsewhere.

[DTL]

With PDR script,

Windows Logs/Application: 0xc0000374, Heap Corruption.


Faulting application name: VirtualDub64.exe, version: 2.0.0.0, time stamp: 0x5e73f48a
Faulting module name: ntdll.dll, version: 10.0.19041.2788, time stamp: 0x2f715b17
Exception code: 0xc0000374



It looks pinterf fix it now - https://github.com/AviSynth/AviSynthPlus/commit/534d4957be561ad497ad3c960ebf19dbfb06828a . Awaiting next release-build to use. Pinterf found and fix serious memory corruption bug around AVScore/convert and it may cause lots of random crashes with many scripts. It is not known when this bug was introduced ?

Build with VS2019 - https://drive.google.com/file/d/1_tl9hUzO3ST_57OM3SLQAWBGespjLeeA/view?usp=sharing . It finally start to draw some waveform without crash at 256x256 size.

Now can see waveforms draw :
"The internal levels(0,1,255,16,125,false) + ConvertToRGB appears close approximation, but with more gaps than vegas' "

It looks the code values duplicating going from Levels() transform. If put simple
ConvertToRGB(matrix="601:f")

It output also completely linear ramp -

BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")

ConvertToRGB(matrix="601:f")

HistogramRGBParade(width=1.0)

https://i.postimg.cc/Pr1JBfzf/image.png

Same as latest 0.4.1 ver - DecodeYUVtoRGB(gain=64, offset=0, Ybias=0, UVbias=-128, UVgain=0.0)

[flossy_cake]

I was reading up on multithreading modes and I would like to use mode 3 to ensure my ScriptClip is evaluated in linear sequential chronological order ("MT_SERIALIZED: If the filter requires sequential access or uses some global storage, then mode 3 is the only way to go (http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode)"). However I'm not sure how to apply it to my ScriptClip - is it even possible?

I tried:

SetFilterMTMode("ScriptClip", MT_SERIALIZED)


And/or:

SetFilterMTMode("MyFunctionWhichMyScriptClipCalls", MT_SERIALIZED)


But I can't see any change in behaviour - I'm still seeing many frames where current_frame inside the ScriptClip is not equal to previous_frame+1. I count these as "desync" frames and print it out with SubTitle, and the behaviour is unpredictable - sometimes I have no desync frames and other times I get them quite a lot and my ScriptClip won't produce the output frame I want because Avisynth is evaluating it in nonlinear frame order. For example if I'm keeping a counter of how many combed frames in a row there were, the decision making logic is slightly broken since the counter can sometimes increment up like 1-2-5-3-4 instead of 1-2-3-4-5.

Single threading of course avoids the issue but performance is in the toilet. For now I'm keeping multithreading and warning the user with SubTitle error message if they get n desync frames within a 30 second period, but it would be nicer to force my ScriptClip to linear access.

:thanks:

edit: also tried GrunT.dll without improvement (tried local=true as well, which works in GRunT for global variable messaging between frames, unlike stock AVS+). It's weird because realtime playback of the .avs in MPC-HC using LAV (which uses ffmpeg) settles down to 0 desync frames after about 10 seconds of playback, but rendering the .avs to mpeg file with ffmpeg.exe at command line just continues to produce desync frames for the entire duration of the video.

edit: I noticed when desync frames cease during realtime MPC-HC playback, this seems to correlate to a drop in CPU usage, which I'm pretty sure is the multithread prefetch buffer becoming full. So maybe when prefetch buffer gets full then Avisynth starts evaluating ScriptClip in linear order. Whereas rendering the script with ffmpeg.exe, Avisynth never fills the prefetch buffer, probably because CPU is pegged at 100% on all cores busy encoding to h264. If true, then as long as you have some CPU headroom the nonthreadsafe issue seems to resolve itself. Although it seems it can crop up again for a few random frames if CPU suddenly gets very busy, like on certain high contrast line patterns when nnedi3 prescreener switches from bicubic to neural net the CPU usage can suddenly spike causing some desync frames.

[Boulder]

I was reading up on multithreading modes and I would like to use mode 3 to ensure my ScriptClip is evaluated in linear sequential chronological order ("MT_SERIALIZED: If the filter requires sequential access or uses some global storage, then mode 3 is the only way to go (http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode)"). However I'm not sure how to apply it to my ScriptClip - is it even possible?

You could try placing the RequestLinear function from the TIVTC package after the ScriptClip part.

[StainlessS]

Avs internal filters are already internally set/defaulted to optimium mode,
ScriptClip (and other runtime filters) will already be MT_SERIALIZED.
(Nothing else really makes much sense).

[kedautinh12]

AviSynthPlus r3993
https://gitlab.com/uvz/AviSynthPlus-Builds/

[guest]

AviSynthPlus r3993
https://gitlab.com/uvz/AviSynthPlus-Builds/

Double up :(

https://forum.doom9.org/showthread.php?p=1988143#post1988143

[pinterf]

Avs internal filters are already internally set/defaulted to optimium mode,
ScriptClip (and other runtime filters) will already be MT_SERIALIZED.
(Nothing else really makes much sense).
MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

[kedautinh12]

Double up :(

https://forum.doom9.org/showthread.php?p=1988143#post1988143

Someone won't go to there post, i think up here more people will catch it

[flossy_cake]

MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

Am I correct in thinking there is perhaps no such concept as multithreading in which calls would be sequential?

The way I'm imagining it in my mind right now, if calls were sequential, then all other threads would have to wait until the previous call was finished before they could do any work, meaning no work could be done in parallel, thus no multithreading?

If true, then I'm left wondering how the heck Avisynth is seemingly becoming sequential once the prefetch buffer becomes full. Example:


ColorBarsHD().Killaudio().ConvertToYV12() #HD video to make some more CPU load. ChangeFPS(60) for more if required.

global desyncCounter = 0
global previous_frame = 0

ScriptClip(last, "CheckSync(last, current_frame)", after_frame=true, local=false)

function CheckSync(clip c, int current_frame){

if (current_frame != 0){

if (previous_frame != current_frame-1){

global desyncCounter = desyncCounter + 1
c = c.SubTitle("Desync", text_color=$FF0000)
}

c = c.SubTitle("\ndesyncCount:" + string(desyncCounter) + "\n" +
\ "current_frame: " + string(current_frame) + "\n" +
\ "previous_frame: " + string(previous_frame)
\ , text_color=$C0C0C0, lsp=10)

}

global previous_frame = current_frame

c
}

Prefetch(8, 8) # may need to increase this on higher spec systems to generate desync frames. Try seeking around too.


edit: after some more testing with ChangeFPS(120) and/or loading up the CPU with QTGMC, the number of desync frames can become entirely unpredictable on my system, even after CPU usage settles to a lower level (indicating the prefetch buffer is full). So that theory of mine would seem to be false and perhaps it's just a pure fluke whether ScriptClip will be evaluated in linear order or not, depending on how the CPU is loaded or what other filters are doing. This makes me wonder how QTGMC can be successful with multithreading if that means QTGMC can't make any guarantee that it will be comparing the current frame to previous frame, in relation to how it "temporally smooths over the neighboring frames using a binomial kernel" if the neighbouring frame order can't be guaranteed due to multithreading.

edit: tried a workaround of using 2 ScriptClips - first one to do the decision making math and is set to Prefetch(1,4). Second ScriptClip does the heavy lifting of rendering the output clip based on previous ScriptClip's decision making and is set to Prefetch(7,4). At first it seemed to work and the first ScriptClip would always be chronologically prior to the second one (based on comparing frame counters between the two ScriptClips) but then as soon as I put any load on the first ScriptClip like doing some YDiffToNext or CFrameDiff I start getting desync frames again.

edit: after more testing of the above it seems that splitting the work into multiple ScriptClips with each of them set to "after_frame=true" does seem to be helping to control the order in which ScriptClip code is evaluated. But it's still a crapshoot and can't be guaranteed. It still seems to be a function of how many cores and prefetch frames I specify with Prefetch(), eg:


# seems to work under all tests - desync frames settle to 0 after n seconds of playback
ScriptClip(last, "GetFrameMetrics()").Prefetch(1, 4)
ScriptClip(last, "ChooseOutputClipBasedOnFrameMetrics()").Prefetch(7, 4)

# works only if CPU is loaded a certain way
ScriptClip(last, "GetMetricsPlusChooseOutputClipBasedOnMetrics()").Prefetch(8, 4)

# works only if CPU is loaded a certain way
ScriptClip(last, "GetMetrics()").Prefetch(1, 8)
ScriptClip(last, "ChooseOutputClipBasedOnMetrics()").Prefetch(7, 8)


edit: it seems this function Preroll (http://avisynth.nl/index.php/Preroll) can mitigate the issue, eg prerolling 1-2 seconds of video on the ScriptClip which you want to evaluate things in linear order.

[StainlessS]

MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

I stand corrected, good sir :)

[pinterf]

Avisynth+ 3.7.3 test 11 (20230608 - r3996) (https://drive.google.com/uc?export=download&id=1ZmFSUZ3ndDzfPYuVWp9MQpZ_YqHCoSEO)

Change log (including test9 changes)
20230608 3.7.3 WIP
------------------
**test11**
- Add "bold"=true (linux/NO_WIN_GDI: false), "italic"=false, "noaa"=false parameters to
"ShowFrameNumber", "ShowCRC32", "ShowSMPTE", "ShowTime" filters.
As noted below, "italic" and "noaa" parameters are ineffective in NO_WIN_GDI builds (e.g. Linux)
- Add "noaa" parameter to SubTitle and Info. Setting it true will disable antialiasing.
Useful when someone would use "VCR OSD Mono" as-is, without beautifying the outlines,
as it as mentioned in https://forum.doom9.org/showthread.php?t=184627
- Address #358, plus "noaa"
- add "bold", "italic" and "noaa" boolean parameters to "SubTitle" and "Info"
- add "italic" and "noaa" boolean parameter to "Text" ("bold" already existed)
"italic" and "noaa" is provided only to match the parameter list with SubTitle.

SubTitle: to mimic former working method, defaults are "bold"=true, "italic"=false, "noaa"=false
Text: "bold"=false (as before); "italic" is not handled at all, either true or false, it does not affect output.
"italic" and "noaa" parameters exist only because on non-Windows systems "Subtitle" is aliased to "Text"
(Each Subtitle parameter must exist in "Text" as well)
- Fix #360: plane fill wrongly assumed that pitch is rowsize, which is not the case after a Crop
It would result in crash e.g. in HistogramRGBParade, when an aligned Crop was immediately followed by a GreyScale().
- Enhancement: much quicker YV24 to RGB32/RGB24 conversion when AVX2 instruction set is supported. (+50% fps at i7-11700)
- UserDefined2Resize got an 's' parameter (to the existing b and c): support, default value = 2.3
(following DTL2020's addition in jpsdr's MT resizer repo, UserDefined2ResizeMT filter)

Now, as we have already three variable parameters to the optional chroma resamplers in ConvertToXX
converters, ConvertToXX family got a new float 'param3' parameter which is passed to UV resizer as
's', if "userdefined2" is specified as chroma resampler.
If param3 is not used in a resizer but is defined, then it is simply ignored.
Such as "ConvertToYV24" parameter signature: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f
e.g.: ConvertToYV24(chromaresample="userdefined2", param1=126, param2=22, param3=2.25)

see also description at **test6**, which was updated with this parameter as well.

s (support) param - controls the 'support' of filter to use by resampler engine. Float value in valid range from
1.5 to 15. Default 2.3. It allows to fine tune resampling result between partially non-linear but more sharper and less
residual ringing (at low b and c values) and more linear processing with wider 'peaking' used. Setting too high
in common use cases (about > 5) may visibly degrade resampler performance (fps) without any visible output changes.
Recommended adjustment range - between 2 and 3.

Examples:
b=126 c=22 - medium soft, almost no ringing.
b=102 c=2 - sharper, small local peaking.
b=70 c=-30 s=2 - sharper, thinner 'peaking'.
b=70 c=-30 s=2.5 - a bit softer, more thick 'peaking'.
b=82 c=20 - sharp but lots of far ringing. Not for using.

- Fix #350 ConvertXXX to accept YV411 clip's frame property _ChromaLocation set to 'left'
(and 'topleft' and 'bottomleft' which give the same result) instead of giving an error message.
- Fix #348 bitrol/bitror functions return incorrect results when first argument is negative.
Regression since the asm code of Avisynth 2.6 classic was ported to C in Avisynth+ project.
- "Info": if channel mask exists, then
- its friendly name
- otherwise the number of channels and the channel combinations
is displayed under "AudioLength: x".

e.g.
SetChannelMask("stereo") --> "Channel mask: stereo"
SetChannelMask("stereo+LFE") --> "Channel mask: 2.1" because the combination resulted in another known channel combo name
SetChannelMask("mono+LFE") --> "Channel mask: 2 channels (FC+LFE)" because the combination is unknown

- Add SetChannel parameter: channel string syntax: (similar to ffmpeg)
a channel number followed by "c" for getting the default layout for a given number of channels.
E.g. SetChannelMask("3c") will set "2.1" because this is the default choice for 3 channels
- Add SetChannel parameter: channel string syntax:
a simple number is treated as the actual numeric mask.
E.g. SetChannelMask("3") will set "stereo" because 3=1+2 that is "FL+FR" that is "stereo"
- SetChannelMask string version: If string is other than "" then its set to known. It has a single string parameter.
SetChannelMask("mono") -> mask is known: "mono"
SetChannelMask("") -> mask is unknown
- Add "speaker_all" to accepted layout mask strings

- Fix possible crash of LLVM builds (clang-cl, Intel nextgen) on pre-AVX (SSE4-only) CPUs.
(Prevent static initialization from avx2 source modules, which cause running AVX instructions on DLL load)
- ConvertToMono, GetLeftChannel, GetRightChannel: sets channel layout AVS_SPEAKER_FRONT_CENTER (mono)
- GetChannel, GetChannels, MergeChannels will set default channel layout if channel count is 1 to 8
For defaults see VfW section below
- New Script function: SetChannelMask: string version.

SetChannelMask(clip, string ChannelDescriptor) (parameters compulsory, no names must be set) (test10)

Accepts predefined channel string or channel layout names or their combination, in ffmpeg style.
Numerical indexes or channel counts are not allowed.
String is case sensitive!
E.g. "stereo+LFE+TC" or "FL+LR" or "5.1(side)"
"mono",
"stereo",
"2.1",
"3.0",
"3.0(back)",
"4.0",
"quad",
"quad(side)",
"3.1",
"5.0",
"5.0(side)",
"4.1",
"5.1",
"5.1(side)",
"6.0",
"6.0(front)",
"hexagonal",
"6.1",
"6.1(back)",
"6.1(front)",
"7.0",
"7.0(front)",
"7.1",
"7.1(wide)",
"7.1(wide-side)",
"7.1(top)",
"octagonal",
"cube"
"speaker_all"
Individual Speaker Channels:
"FL", front left
"FR", front right
"FC", front center
"LFE", low frequency
"BL", back left
"BR", back right
"FLC", front left-of-center
"FRC", front right-of-center
"BC", back center
"SL", side left
"SR", side right
"TC", top center
"TFL", top front left
"TFC", top front center
"TFR", top front right
"TBL", top back left
"TBC", top back center
"TBR", top back right

- AudioDub will inherit channel layout setting from the audio clip.
- VfW output channel guess (when ChannelMask is not specified) changed at some points.
Default number of channels to channel layout guess was modified to match of ffmpeg
3 channels: Surround to 2.1
4 channels: Quad to 4.0
6 channels: 6.1(back) to 6.1
This follows ffmpeg defaults
Present rules:
const chnls name layout
0x00004 1 mono -- -- FC
0x00003 2 stereo FL FR
0x0000B 3 2.1 FL FR LFE
0x00107 4 4.0 FL FR FC -- -- -- -- -- BC
0x00037 5 5.0 FL FR FC -- BL BR
0x0003F 6 5.1 FL FR FC LFE BL BR
0x0070F 7 6.1 FL FR FC LFE -- -- -- -- BC SL SR
0x0063F 8 7.1 FL FR FC LFE BL BR -- -- -- SL SR

**test9**
- Add initial audio channel mask (channel layout) support (CPP and C interface, script function)
It still belongs to V10 changes (there were only tests since then), but it can be discussed if not.
Technically it is done by using another 18+2 bits in the Clip's VideoInfo.image_type field.
Due to lack of enough bits in this VideoInfo field, the mapping between the original dwChannelMask
and Avisynth's internal values are not 1:1, but all information is kept however.
This is because not 32 but only 18 (strictly: 18+1) bits are defining speaker locations, so
the remaining bits of our existing 'image_type' field can be used for this purpose.
Thus 20 new bits are occupied.
- 1 bit: marks if channel mask is valid or not
- 18 bits for the actually defined WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions
(https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatextensible)
- 1 bit for the special SPEAKER_ALL value

Programmers can check AvsChannelMask and AvsImageTypeFlags in avisynth.h and avisynth_c.h

- new C++ interface functions
- Check for existence:
bool VideoInfo::IsChannelMaskKnown()
- Setting:
void VideoInfo::SetChannelMask(bool isChannelMaskKnown, unsigned int dwChannelMask)
Re-maps and stores channel mask into image_type, sets the 'has channel mask' flag as well
Note: this data can be set independently from the actual NumChannels number!
- Retrieving:
unsigned int VideoInfo::GetChannelMask()

- new C interface functions
bool avs_is_channel_mask_known(const AVS_VideoInfo * p);
void avs_set_channel_mask(const AVS_VideoInfo * p, bool isChannelMaskKnown, unsigned int dwChannelMask);
unsigned int avs_get_channel_mask(const AVS_VideoInfo * p);

Like when establishing BFF, TFF and fieldbased flags from 'image_type', technically 'image_type' can
be manipulated directly. See SetChannelMask and GetChannelMask in Avisynth source for
image_type <-> dwChannelMask conversion.

I guess once ffmpeg will support it, it will read (or not read) channel masks such a way.

- new Script functions
bool IsChannelMaskKnown(clip)
int GetChannelMask(clip)
SetChannelMask(clip, bool known, int dwChannelMask) (parameters are compulsory, dont't use parameter name)
SetChannelMask(clip, string ChannelDescriptor) (test10)
dwChannelMask must contain the combination of up to 18 positions or 0x80000000 for SPEAKER_ALL.

VfW export rules (included the existing sequence)
1.) OPT_UseWaveExtensible global variable must be 'true'
or
*new*new*new*
if VideoInfo::IsChannelMaskKnown is true, then fill WAVEFORMATEXTENSIBLE struct
2.) *new*new*new*
Is channel mask defined in Avisynth's VideoInfo? (VideoInfo::IsChannelMaskKnown() is true)
Yes -> return VideoInfo::GetChannelMask()
3.) No-> (Channel mask not defined in VideoInfo, guess it or set from variable)
3.1)Guess channel layout:
For 0 to 8 channels there is a predefined 'guess map':
#of channels dwChannelMask
0 0,
1 0x00004, // 1 -- -- Cf
2 0x00003, // 2 Lf Rf
3 0x00007, // 3 Lf Rf Cf
4 0x00033, // 4 Lf Rf -- -- Lr Rr
5 0x00037, // 5 Lf Rf Cf -- Lr Rr
6 0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
7 0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
8 0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs

For 9-18 channels:
sets first 9-18 bits in dwChannelMask
Above:
SPEAKER_ALL (dword msb bit is 1)
3.2) if OPT_dwChannelMask global variable is defined and is different from 0, then use it.

E.g. VirtualDub2 is using VfW, so after opening the script, ended with SetChannelMask(true, $0063F),
one can check the value File|File Info menu, under "compression" line (e.g.PCM, chmask 63f).
SetChannels does not check against NumChannels, so you can set the 7.1 constant for a stereo
if you wish. Microsoft's documentation mentions the cases of what an application can do with
less or more than necessary defined speaker bits.

- What to do about GetChannels, MixAudio, ConvertToMono? To be discussed.
KillAudio will call SetChannelMask(false, 0), nevertheless.

[gispos]

Thanks for the new version.

[StainlessS]

Lotsa changes there, yeah dude, thanx P. :)

[tebasuna51]

Thanks pinterf for your effort to manage audio in avs+.

I make some test with 4 ac3 samples:
4a301.ac3 MaskChannels : 15 (FL FR FC LF)
4s211.ac3 MaskChannels : 267 (FL FR LF BC)
4s220.ac3 MaskChannels : 1539 (FL FR SL SR)
4w310.ac3 MaskChannels : 263 (FL FR FC BC) (default for 4 channels)

And a .avs like:
OPT_UseWaveExtensible = true
#
BestAudioSource("4a301.ac3")
#FFAudioSource("4a301.ac3")
#LWLibavAudioSource("4a301.ac3")
#SetChannelMask("15")
to test the 4 files with the 3 decoders, and:

1) The decoders don't fill the MaskChannels and "Info" do not show it.
Using the appropiate SetChannelMask the "Info" show it correctly.

BestAudioSource say than a global variable BASCHANNEL_LAYOUT is created with the MaskChannels, how can use it to SetChannelMask?
The same with FFAudioSource and FFCHANNEL_LAYOUT

2) With the SetChannelMask set manually I output correct WaveFormatExtensible files with VirtualDub2 but the ChannelMask is ignored with MeGUI, mpc-hc or ffmpeg:

ffmpeg -i 4a301.avs 4a301.wav

the output is always the default 263 (FL FR FC BC) for my 4 samples.

EDIT: BeHappy crash with the SetChannelMask("15") active.
Of course old soft like wavi/avspipemod ignore also the internal ChannelMask and put the header and the channelmask with the command line parameters. New versions needed.

[DTL]

Found some temporal solution how to fix precision of PC.709 matrix when converting to narrow-RGB:

ColorBarsHD(640, 480, pixel_type="YV24")
ColorYUV(cont_u=-6, cont_v=-6)
ConvertToRGB32(matrix="PC.709")

Now RGBs are
Y 181,180,15
C 15,180,180
G 16,180,16
M 180,16,180
R 181,16,16
B 15,16,181

It looks internal coefficients for PC.709 matrix need adjustments.

Same correction of UV gain (contrast from mid value) looks also required for PC.2020 matrix.

Addition: Also looks like found the source of a bug - the Digital Y to Digital UV 219/224 additional multiplier (equal for all 3 IUT-R 601/709/2020) was missed at calculation of PC.x matrices. Hope it will be fixed in next build.

[qyot27]

Thanks pinterf for your effort to manage audio in avs+.

I make some test with 4 ac3 samples:
4a301.ac3 MaskChannels : 15 (FL FR FC LF)
4s211.ac3 MaskChannels : 267 (FL FR LF BC)
4s220.ac3 MaskChannels : 1539 (FL FR SL SR)
4w310.ac3 MaskChannels : 263 (FL FR FC BC) (default for 4 channels)

And a .avs like:

to test the 4 files with the 3 decoders, and:

1) The decoders don't fill the MaskChannels and "Info" do not show it.
Using the appropiate SetChannelMask the "Info" show it correctly.

BestAudioSource say than a global variable BASCHANNEL_LAYOUT is created with the MaskChannels, how can use it to SetChannelMask?
The same with FFAudioSource and FFCHANNEL_LAYOUT

2) With the SetChannelMask set manually I output correct WaveFormatExtensible files with VirtualDub2 but the ChannelMask is ignored with MeGUI, mpc-hc or ffmpeg:

ffmpeg -i 4a301.avs 4a301.wav

the output is always the default 263 (FL FR FC BC) for my 4 samples.

EDIT: BeHappy crash with the SetChannelMask("15") active.
Of course old soft like wavi/avspipemod ignore also the internal ChannelMask and put the header and the channelmask with the command line parameters. New versions needed.
Try this build of FFmpeg:
https://www.mediafire.com/file/cdvaed4e5mp23wb/ffmpeg_avschannellayout_test_win64.7z/file

[tebasuna51]

Try this build of FFmpeg
Seems work fine, thanks qyot27.

EDIT:
I found a problem, I think in avs+:

The max maskchannel than run ok is 13839 (FL FR FC LFE SL SR TFL TFC)
With 20543 (FL FR FC LFE BL BR TFL TFR) 7.1(top) the ChannelMask is truncated to 4159 (FL FR FC LF BL BR TFL ERROR: don't match with NumChan)

ffmpeg show errors like:
[pcm_f32le @ 000001f8a19d2010] Invalid PCM packet, data has size 20 but at least a size of 28 was expected

VirtualDub2 output also a invalid wav

[pinterf]

Oh, I didn't expect other softwares to use speaker bits so quickly. Finally a good feedback. Anyway, channel count and bit setting must match, this is the user's responsibility, maybe it must be checked more strictly by avisynth (aside from that there can be bugs on my side as well)

[qyot27]

Oh, I didn't expect other softwares to use speaker bits so quickly. Finally a good feedback. Anyway, channel count and bit setting must match, this is the user's responsibility, maybe it must be checked more strictly by avisynth (aside from that there can be bugs on my side as well)
I thought it was going to be more complicated than it was as well. I was fiddling with stuff for the better part of a day before I realized that what avs_get_channel_mask was outputting could just be ingested as-is by a function that already existed in FFmpeg and turned it into literally a one-line addition (aside from the necessary boilerplate to load the function and check version presence):
https://github.com/qyot27/FFmpeg/commit/1443d2b6ab4ab224f6ec27dedb47857f033c64fe

Functionally, I was concerned about the note in readme_history (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt#L162):
Due to lack of enough bits in this VideoInfo field, the mapping between the original dwChannelMask and Avisynth's internal values are not 1:1, but all information is kept however.
and whether that would cause problems with larger or more exotic layouts (even though at that point you'd be dealing with numbers of speakers akin to theaters or Atmos configurations), but because it says 'all information is kept' I wasn't actually sure about that, or if the mappings between AviSynth and FFmpeg could end up not matching and causing issues when doing it with av_channel_layout_from_mask instead of doing something like needing to tether the AVS_[IT|MASK]_SPEAKER defines to their equivalents in FFmpeg and use a for loop iterating over the channels and using AV_CHANNEL_ORDER_CUSTOM or something.


The only real issue is that - because we have to have to protect it behind the get_version check, the version of the headers FFmpeg checks for needs to be raised when this goes upstream. And because the interface version bump was in the middle of the current dev cycle, getting the patch upstreamed will have to wait until after the official release of 3.7.3.

[tebasuna51]

Just to test this is a channel test (https://www.sendspace.com/file/g9bq5z) encoded with Audition 2017 like 3/4(L R C LFE Ls Rs Vhl Vhr)

With SetChannelMask("22031") FL FR FC LFE SL SR TFL TFR
7.1(top-side) the oficial ffmpeg decode it correctly but like1599 (FL FR FC LF BL BR SL SR) 7.1

Virtualdub2 show that info:

EDIT: 18 bits is enough for WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions, but seems cut at 14 bits 16384

[pinterf]

Just to test this is a channel test (https://www.sendspace.com/file/g9bq5z) encoded with Audition 2017 like 3/4(L R C LFE Ls Rs Vhl Vhr)

With SetChannelMask("22031") FL FR FC LFE SL SR TFL TFR
7.1(top-side) the oficial ffmpeg decode it correctly but like1599 (FL FR FC LF BL BR SL SR) 7.1

Virtualdub2 show that info:

EDIT: 18 bits is enough for WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions, but seems cut at 14 bits 16384
Thanks, fixed on github.
(No test build from me yet, other things are under construction.)

[tebasuna51]

Thanks, fixed on github.
(No test build from me yet, other things are under construction.)
Thanks, no problem we can wait.

[pinterf]

Functionally, I was concerned about the note in readme_history (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt#L162):

and whether that would cause problems with larger or more exotic layouts (even though at that point you'd be dealing with numbers of speakers akin to theaters or Atmos configurations), but because it says 'all information is kept' I wasn't actually sure about that, or if the mappings between AviSynth and FFmpeg could end up not matching and causing issues when doing it with av_channel_layout_from_mask instead of doing something like needing to tether the AVS_[IT|MASK]_SPEAKER defines to their equivalents in FFmpeg and use a for loop iterating over the channels and using AV_CHANNEL_ORDER_CUSTOM or something.

Thank you for the update.
I don't know since when, but ffmpeg features a more sophisticated channel layout, which may superseed the 18 (+ "all channels") bits supported by WAVE_FORMAT_EXTENSIBLE. I was not able to stuff these extra exotic layout options into the available Avisynth VideoInfo bits.

[kedautinh12]

Avs+ asd-g's build r3996
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

AviSynthPlus r4001
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

Thanks, no problem we can wait.

Try new build

[tebasuna51]

AviSynthPlus r4001
https://gitlab.com/uvz/AviSynthPlus-Builds
Try new build

503 Server Unavailable

[guest]

503 Server Unavailable

Works for me !

[FranceBB]

Works for me !

Yes, it's back now, but it's been down for a while.

[tebasuna51]

AviSynthPlus r4001 work fine now with my channel test:

[tebasuna51]

Now decoders like ffms2, LSMASHSource and BestAudioSource can use the new https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/include/avisynth.h (it is the last?) and store the image_type with the Channel mask

[real.finder]

AviSynthPlus r4001
https://gitlab.com/uvz/AviSynthPlus-Builds

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

https://i.postimg.cc/4yZLWYbZ/Untitled.png (https://postimages.org/)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

[StvG]

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

https://i.postimg.cc/4yZLWYbZ/Untitled.png (https://postimages.org/)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties (https://forum.doom9.org/showthread.php?p=1986000#post1986000)

[real.finder]

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties (https://forum.doom9.org/showthread.php?p=1986000#post1986000)

thanks, that work but will all other 2.5 plugins will not work? there are some of them even close source

[StvG]

thanks, that work but will all other 2.5 plugins will not work? there are some of them even close source

Probably. There is also this comment (https://github.com/AviSynth/AviSynthPlus/issues/272#issuecomment-1054123695).

[tebasuna51]

A new version of LSMASHSource.dll to test in https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/35

For me work fine with some samples ac3, eac3 and dts, the correct channel mask is created (without SetChannelMask() ) and VirtualDub2 save the correct WAVE_FORMAT_EXTENSIBLE output.

Now we need at least ffmpeg read that info. http://trac.ffmpeg.org/ticket/10473

[qyot27]

AviSynth+ 3.7.3 has been released (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.3)

- Add "bold"=true (linux/NO_WIN_GDI: false), "italic"=false, "noaa"=false parameters to
"ShowFrameNumber", "ShowCRC32", "ShowSMPTE", "ShowTime" filters.
As noted below, "italic" and "noaa" parameters are ineffective in NO_WIN_GDI builds (e.g. Linux)
- Add "noaa" parameter to SubTitle and Info. Setting it true will disable antialiasing.
Useful when someone would use "VCR OSD Mono" as-is, without beautifying the outlines,
as it as mentioned in https://forum.doom9.org/showthread.php?t=184627
- Address #358, plus "noaa"
- add "bold", "italic" and "noaa" boolean parameters to "SubTitle" and "Info"
- add "italic" and "noaa" boolean parameter to "Text" ("bold" already existed)
"italic" and "noaa" is provided only to match the parameter list with SubTitle.

SubTitle: to mimic former working method, defaults are "bold"=true, "italic"=false, "noaa"=false
Text: "bold"=false (as before); "italic" is not handled at all, either true or false, it does not affect output.
"italic" and "noaa" parameters exist only because on non-Windows systems "Subtitle" is aliased to "Text"
(Each Subtitle parameter must exist in "Text" as well)
- Fix #360: plane fill wrongly assumed that pitch is rowsize, which is not the case after a Crop
It would result in crash e.g. in HistogramRGBParade
- Enhancement: much quicker YV24 to RGB32/RGB24 conversion when AVX2 instruction set is supported. (+50% fps at i7-11700)
- UserDefined2Resize got an 's' parameter (to the existing b and c): support, default value = 2.3
(following DTL2020's addition in jpsdr's MT resizer repo, UserDefined2ResizeMT filter)

Now, as we have already three variable parameters to the optional chroma resamplers in ConvertToXX
converters, ConvertToXX family got a new float 'param3' parameter which is passed to UV resizer as
's', if "userdefined2" is specified as chroma resampler.
If param3 is not used in a resizer but is defined, then it is simply ignored.
Such as "ConvertToYV24" parameter signature: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f
e.g.: ConvertToYV24(chromaresample="userdefined2", param1=126, param2=22, param3=2.25)

see also description at **test6**, which was updated with this parameter as well.

s (support) param - controls the 'support' of filter to use by resampler engine. Float value in valid range from
1.5 to 15. Default 2.3. It allows to fine tune resampling result between partially non-linear but more sharper and less
residual ringing (at low b and c values) and more linear processing with wider 'peaking' used. Setting too high
in common use cases (about > 5) may visibly degrade resampler performance (fps) without any visible output changes.
Recommended adjustment range - between 2 and 3.

Examples:
b=126 c=22 - medium soft, almost no ringing.
b=102 c=2 - sharper, small local peaking.
b=70 c=-30 s=2 - sharper, thinner 'peaking'.
b=70 c=-30 s=2.5 - a bit softer, more thick 'peaking'.
b=82 c=20 - sharp but lots of far ringing. Not for using.

- Fix #350 ConvertXXX to accept YV411 clip's frame property _ChromaLocation set to 'left'
(and 'topleft' and 'bottomleft' which give the same result) instead of giving an error message.
- Fix #348 bitrol/bitror functions return incorrect results when first argument is negative.
Regression since the asm code of Avisynth 2.6 classic was ported to C in Avisynth+ project.
- "Info": if channel mask exists, then
- its friendly name
- otherwise the number of channels and the channel combinations
is displayed under "AudioLength: x".

e.g.
SetChannelMask("stereo") --> "Channel mask: stereo"
SetChannelMask("stereo+LFE") --> "Channel mask: 2.1" because the combination resulted in another known channel combo name
SetChannelMask("mono+LFE") --> "Channel mask: 2 channels (FC+LFE)" because the combination is unknown

- Add SetChannel parameter: channel string syntax: (similar to ffmpeg)
a channel number followed by "c" for getting the default layout for a given number of channels.
E.g. SetChannelMask("3c") will set "2.1" because this is the default choice for 3 channels
- Add SetChannel parameter: channel string syntax:
a simple number is treated as the actual numeric mask.
E.g. SetChannelMask("3") will set "stereo" because 3=1+2 that is "FL+FR" that is "stereo"
- SetChannelMask string version: If string is other than "" then its set to known. It has a single string parameter.
SetChannelMask("mono") -> mask is known: "mono"
SetChannelMask("") -> mask is unknown
- Add "speaker_all" to accepted layout mask strings

- Fix possible crash of LLVM builds (clang-cl, Intel nextgen) on pre-AVX (SSE4-only) CPUs.
(Prevent static initialization from avx2 source modules, which cause running AVX instructions on DLL load)
- ConvertToMono, GetLeftChannel, GetRightChannel: sets channel layout AVS_SPEAKER_FRONT_CENTER (mono)
- GetChannel, GetChannels, MergeChannels will set default channel layout if channel count is 1 to 8
For defaults see VfW section below
- New Script function: SetChannelMask: string version.

SetChannelMask(clip, string ChannelDescriptor) (parameters compulsory, no names must be set) (test10)

Accepts predefined channel string or channel layout names or their combination, in ffmpeg style.
Numerical indexes or channel counts are not allowed.
String is case sensitive!
E.g. "stereo+LFE+TC" or "FL+LR" or "5.1(side)"
"mono",
"stereo",
"2.1",
"3.0",
"3.0(back)",
"4.0",
"quad",
"quad(side)",
"3.1",
"5.0",
"5.0(side)",
"4.1",
"5.1",
"5.1(side)",
"6.0",
"6.0(front)",
"hexagonal",
"6.1",
"6.1(back)",
"6.1(front)",
"7.0",
"7.0(front)",
"7.1",
"7.1(wide)",
"7.1(wide-side)",
"7.1(top)",
"octagonal",
"cube"
"speaker_all"
Individual Speaker Channels:
"FL", front left
"FR", front right
"FC", front center
"LFE", low frequency
"BL", back left
"BR", back right
"FLC", front left-of-center
"FRC", front right-of-center
"BC", back center
"SL", side left
"SR", side right
"TC", top center
"TFL", top front left
"TFC", top front center
"TFR", top front right
"TBL", top back left
"TBC", top back center
"TBR", top back right

- AudioDub will inherit channel layout setting from the audio clip.
- VfW output channel guess (when ChannelMask is not specified) changed at some points.
Default number of channels to channel layout guess was modified to match of ffmpeg
3 channels: Surround to 2.1
4 channels: Quad to 4.0
6 channels: 6.1(back) to 6.1
This follows ffmpeg defaults
Present rules:
const chnls name layout
0x00004 1 mono -- -- FC
0x00003 2 stereo FL FR
0x0000B 3 2.1 FL FR LFE
0x00107 4 4.0 FL FR FC -- -- -- -- -- BC
0x00037 5 5.0 FL FR FC -- BL BR
0x0003F 6 5.1 FL FR FC LFE BL BR
0x0070F 7 6.1 FL FR FC LFE -- -- -- -- BC SL SR
0x0063F 8 7.1 FL FR FC LFE BL BR -- -- -- SL SR

- Add initial audio channel mask (channel layout) support (CPP and C interface, script function)
It still belongs to V10 changes (there were only tests since then), but it can be discussed if not.
Technically it is done by using another 18+2 bits in the Clip's VideoInfo.image_type field.
Due to lack of enough bits in this VideoInfo field, the mapping between the original dwChannelMask
and Avisynth's internal values are not 1:1, but all information is kept however.
This is because not 32 but only 18 (strictly: 18+1) bits are defining speaker locations, so
the remaining bits of our existing 'image_type' field can be used for this purpose.
Thus 20 new bits are occupied.
- 1 bit: marks if channel mask is valid or not
- 18 bits for the actually defined WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions
(https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatextensible)
- 1 bit for the special SPEAKER_ALL value

Programmers can check AvsChannelMask and AvsImageTypeFlags in avisynth.h and avisynth_c.h

- new C++ interface functions
- Check for existence:
bool VideoInfo::IsChannelMaskKnown()
- Setting:
void VideoInfo::SetChannelMask(bool isChannelMaskKnown, unsigned int dwChannelMask)
Re-maps and stores channel mask into image_type, sets the 'has channel mask' flag as well
Note: this data can be set independently from the actual NumChannels number!
- Retrieving:
unsigned int VideoInfo::GetChannelMask()

- new C interface functions
bool avs_is_channel_mask_known(const AVS_VideoInfo * p);
void avs_set_channel_mask(const AVS_VideoInfo * p, bool isChannelMaskKnown, unsigned int dwChannelMask);
unsigned int avs_get_channel_mask(const AVS_VideoInfo * p);

Like when establishing BFF, TFF and fieldbased flags from 'image_type', technically 'image_type' can
be manipulated directly. See SetChannelMask and GetChannelMask in Avisynth source for
image_type <-> dwChannelMask conversion.

I guess once ffmpeg will support it, it will read (or not read) channel masks such a way.

- new Script functions
bool IsChannelMaskKnown(clip)
int GetChannelMask(clip)
SetChannelMask(clip, bool known, int dwChannelMask) (parameters compulsory, no names must be set)
SetChannelMask(clip, string ChannelDescriptor) (parameters compulsory, no names must be set) (test10)
dwChannelMask must contain the combination of up to 18 positions or 0x80000000 for SPEAKER_ALL.

VfW export rules (included the existing sequence)
1.) OPT_UseWaveExtensible global variable must be 'true'
or
*new*new*new*
if VideoInfo::IsChannelMaskKnown is true, then fill WAVEFORMATEXTENSIBLE struct
2.) *new*new*new*
Is channel mask defined in Avisynth's VideoInfo? (VideoInfo::IsChannelMaskKnown() is true)
Yes -> return VideoInfo::GetChannelMask()
3.) No-> (Channel mask not defined in VideoInfo, guess it or set from variable)
3.1)Guess channel layout:
For 0 to 8 channels there is a predefined 'guess map':
#of channels dwChannelMask
0 0,
1 0x00004, // 1 -- -- Cf
2 0x00003, // 2 Lf Rf
3 0x00007, // 3 Lf Rf Cf
4 0x00033, // 4 Lf Rf -- -- Lr Rr
5 0x00037, // 5 Lf Rf Cf -- Lr Rr
6 0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
7 0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
8 0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs

For 9-18 channels:
sets first 9-18 bits in dwChannelMask
Above:
SPEAKER_ALL (dword msb bit is 1)
3.2) if OPT_dwChannelMask global variable is defined and is different from 0, then use it.

E.g. VirtualDub2 is using VfW, so after opening the script, ended with SetChannelMask(true, $0063F),
one can check the value File|File Info menu, under "compression" line (e.g.PCM, chmask 63f).
SetChannels does not check against NumChannels, so you can set the 7.1 constant for a stereo
if you wish. Microsoft's documentation mentions the cases of what an application can do with
less or more than necessary defined speaker bits.

- What to do about GetChannels, MixAudio, ConvertToMono? To be discussed.
KillAudio will call SetChannelMask(false, 0), nevertheless.

- Set automatic MT mode MT_SERIALIZED to
ConvertToMono, EnsureVBRMP3Sync, MergeChannels, GetChannel, Normalize, MixAudio, ResampleAudio
- Add back audio cache from classic Avisynth 2.6.
Believe it or not, audio cache was never ported to Avisynth+
- Make use of avisynth.h constants: CACHE_GETCHILD_AUDIO_MODE and CACHE_GETCHILD_AUDIO_SIZE:
Filters are queryed about their desired audio cache mode through their SetCacheHints (similarly to CACHE_GET_MTMODE).
- Filters can answer CACHE_GETCHILD_AUDIO_MODE with
CACHE_AUDIO: Explicitly cache audio, X byte cache.
CACHE_AUDIO_NOTHING: Explicitly do not cache audio.
CACHE_AUDIO_AUTO_START_OFF: Audio cache off (auto mode), X byte initial cache.
CACHE_AUDIO_AUTO_START_ON: Audio cache on (auto mode), X byte initial cache.
- Default value is CACHE_AUDIO_AUTO_START_OFF.
- Filters can specify the required cache size by returning CACHE_GETCHILD_AUDIO_SIZE.
Default cache size is 256kB.
- For custom audio cache querying example see EnsureVBRMP3Sync::SetCacheHints in source.
How it works:
- Modes CACHE_AUDIO_AUTO_START_OFF (default) and CACHE_AUDIO_AUTO_START_ON are automatic modes.
The decision whether the stream benefits caching or not - and how big the cache
size should be - is made upon continously gathering some statistics on the audio
stream requests (an internal score is maintained).
- when strict linear reading is detected. why bother with a cache,
mode would finally changed to CACHE_AUDIO_AUTO_START_OFF.
- When the requests are continously skipping chunks - a cache might not help;
go with CACHE_AUDIO_AUTO_START_OFF as well.
- When the next sample request is within the cache size, a cache could help:
if audio cache was swithed off Avisynth would turn it into active caching by changing
the working mode to CACHE_AUDIO_AUTO_START_ON.
- Modes CACHE_AUDIO and CACHE_AUDIO_NOTHING are explicitely enable/disable audio cache at a give size.

- Fix Clang build AviSource crash on yuv422p10le UTVideo at specific widths (SSE2 or SSE4.1)
- #340: stop memory leak on propSet / MakePropertyWritable;
A bit less memory/processing overhead in internal FrameRegistry as a side effect.
- #282: make 32-bit MSVC build to generate both decorated and undecorated export function names for C plugins
C plugins built with mingw possibly expect decorated names.
- Expr: Add remaining stack element count to "Unbalanced stack..." error message.
- #306: Add ConvertToYUVA420, ConvertToYUVA422 and ConvertToYUVA444.
Resulting clip is always YUVA:
Alpha plane is kept if exists (even from packed RGB formats like RGB32/64),
otherwise filled with maximum transparency mask value.
Parameters are the same like in ConvertToYUVYUVxxx versions.
- Update build documentation with 2023 Intel C++ tools. See Compiling Avisynth+
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html
- CMakeLists.txt: add support for Intel C++ Compiler 2023.
- Enhanced performance in ConvertBits Floyd dither (dither=1) for 10->8, 16->8 and 16->10 bit cases
by providing special function templates to allow compilers to optimize them much better.
(Both Microsoft and Intel Classic 19.2 benefits, LLVM based clangCL and IntelLLVM compilers not)
- Fix crash when outputting VfW (e.g. VirtualDub) for YUV422P16, or P10 in Intel SSE2 optimization
due to aligned SIMD write to an unaligned pointer - did not affect Microsoft builds.
As seen in https://forum.doom9.org/showthread.php?p=1983343#post1983343

[...trimmed for length...]

[StainlessS]

Wow, somebodies been busy, ta very much :)

[DTL]

Heh - small fix for UV scale at RGB<->YUV at 'limited/narrow' levels mapping https://forum.doom9.org/showthread.php?p=1988318#post1988318 is not included in the 3.7.3 release. Pinterf promised to make a big redesign of all 'convert' core functions with a fix for this issue included (also with better performance) but it looks like it will happen in some 3.7.4testXXX next builds. So currently with 3.7.3 release the same workaround with additional UV scaling is required.

[tebasuna51]

Thanks qyot27 for the new release 3.73 r4003

With VirtualDub2 I can output correct WAVE_FORMAT_EXTENSIBLE audio output using:

global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
LWLibavAudioSource("8w3D.ec3")
#SetChannelMask("22031") # Not needed with last LSMASHSource.dll

Also with:
global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
global OPT_UseWaveExtensible = true # Needed to use global OPT_dwChannelMask=
FFAudioSource("8w3D.ec3")
global OPT_dwChannelMask=FFCHANNEL_LAYOUT
And:
global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
global OPT_UseWaveExtensible = true # Needed to use global OPT_dwChannelMask=
BestAudioSource("8w3D.ec3")
global OPT_dwChannelMask=BASCHANNEL_LAYOUT

Now we need a way to use it with ffmpeg, wavi or avs2pipemod
Also MeGUI and BeHappy need changes.

[FranceBB]

Very nice! I've been testing it on all my servers and so far so good! :D

https://i.imgur.com/3yCW94r.png

[zambelli]

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.

[StainlessS]

@Z,
U wanna post your mysterious script ?

[FranceBB]

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.


A simple test with:

video=LWLibavVideoSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf")
ch12=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=1)
ch34=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=2)
ch56=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=3)
ch78=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=4)
audio=MergeChannels(ch56, ch78, ch56, ch78)


AudioDub(video, audio)

Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

Bob()

neo_FFT3D(sigma=3.0, bt=3, y=3, u=3, v=3)

shows no issues:

https://i.imgur.com/tskunwc.png
https://i.imgur.com/WzqDMPv.png

a simple check with AVSMeter also shows no issues:

AvsMeter64.exe "\\mibctvan000\Ingest\MEDIA\temp\New File (37).avs"

pause

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


as always, I suggest getting rid of frame properties to speed things up:

video=LWLibavVideoSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf")
ch12=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=1)
ch34=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=2)
ch56=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=3)
ch78=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=4)
audio=MergeChannels(ch56, ch78, ch56, ch78)

AudioDub(video, audio)

propClearAll()
AssumeTFF()

Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

Bob()

neo_FFT3D(sigma=3.0, bt=3, y=3, u=3, v=3)

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

[tebasuna51]

@pinterf, we need a new AviSynthWrapper.dll (https://forum.doom9.org/showthread.php?p=1913117#post1913117) for MeGUI to support Avs+ 3.7.3 (avs_core_10)?

[real.finder]

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.

try with Avisynth+ 3.7.3 test 7 (20230223) https://drive.google.com/uc?export=download&id=1dKBH5DM6RwNSBBwdEoB-weg50I_whTEm

[zambelli]

@Z, U wanna post your mysterious script ?
a simple check with AVSMeter also shows no issues:
try with Avisynth+ 3.7.3 test 7
I'm so sorry folks, it turned out to be a false alarm. I thought I had done the due diligence last night and narrowed down the problem to neo_FFT3D, but when I reinvestigated the script this morning with fresh eyes - of course it turned out to be an unrelated user error. :rolleyes: I should've known better than to try to debug a problem at 1 am! :)

[FranceBB]

I should've known better than to try to debug a problem at 1 am! :)

No worries, it happens to everyone, especially with large scripts or with functions with lots of dependencies.
For instance, you have no idea how long it took me to find out an avstp related issue out of my scripts few years ago. (https://github.com/pinterf/mvtools/issues/46)
(and just FYI the actual fix Ferenc did back then worked like a charm but we all felt as if it was black magic as we didn't understand why xD).

[flossy_cake]

If I have for example:

plugins64/bwdif (v1.2.0).dll
plugins64/bwdif (v1.2.5).dll

What logic is Avisynth using to choose which one will be used for scripts? Does it check the version number inside the dll and use the newer one? Does this apply to .avsi files as well? In my testing it seems to be using the newer version, but I need to be 100% sure of this.

Also is there any way to check plugin version inside a script? My script won't work properly with certain versions of TFM & BWDIF due to updates in the way they handle field ordering, so the user might look at my dependency list in my readme.md and think "ah yes I already have those plugins" and get broken output and think my script is bad.

I was thinking to workaround this by putting my script and all its dependencies into one folder and then the user can just copy that one folder into /plugins64 and Avisynth might automatically preference any newer version dll's inside that folder - would that work?

:thanks:

[real.finder]

If I have for example:

plugins64/bwdif (v1.2.0).dll
plugins64/bwdif (v1.2.5).dll

What logic is Avisynth using to choose which one will be used for scripts? Does it check the version number inside the dll and use the newer one? Does this apply to .avsi files as well? In my testing it seems to be using the newer version, but I need to be 100% sure of this.

IIRC it will load them in alphabetical order, so the "bwdif (v1.2.5).dll" in your example will be used because it load after the 1st one, I think it's a same thing for avsi

[flossy_cake]

IIRC it will load them in alphabetical order, so the "bwdif (v1.2.5).dll" in your example will be used because it load after the 1st one, I think it's a same thing for avsi

Thanks.

@StainlessSBy any chance did you happen to make a plugin that can get the version string from a plugin, something like this?

https://i3.lensdump.com/i/JP19LC.png

[kedautinh12]

TIVTC had 1.0.27 now
https://github.com/pinterf/TIVTC/releases

[flossy_cake]

TIVTC had 1.0.27 now
https://github.com/pinterf/TIVTC/releases

Yes I know - that's actually the problem, something in 1.0.27 interprets the field order differently that makes it incompatible with my script. It has to do with the fact that I use DoubleWeave() which alternates the field order per frame and the new version of TFM doesn't appear to interpret field order in the same way that 1.0.26 does, resulting in some failure to field match.

I have lodged an issue on the Git but it probably won't be fixed for a long time, and even if it was fixed, a newer version of TIVTC or other plugin could break something, so I'd rather have my script validate all plugin versions on startup so I can be confident the user will get the output frames that I've tested it with across a variety of content over the last few months.

[StainlessS]

By any chance did you happen to make a plugin that can get the version string from a plugin, something like this?
Nope, and neither did Groucho2004 with his SysInfo plugin:- https://forum.doom9.org/showthread.php?t=176131
He does though provide a few for Avisynth.dll itself,

Avisynth related functions:

string AI_AvsFileVersion
Returns the value of the FileVersion resource property

string AI_AvsProductVersion
Returns the value of the ProductVersion resource property

int AI_AvsPlusBuildNumber
Returns the AVS+ build number

# ...

not that that is of any use to you.

[flossy_cake]

Not to worry, it seems Avisynth has this DLLName_function() (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_plugins.html#plugin-autoload-and-conflicting-function-names-v2-55) so I can force a particular version with eg.


TIVTCv1026_TFM() # uses TFM() from TIVTCv1026.dll

[StainlessS]

Yes, that works, but beware of possible problems if the dll name has "_" underscore in it. [eg dll = "TIVTC_v1026.dll"]

[tebasuna51]

Removed a duplicated post and moved the answers to QTGMC Deinterlacing Script (v3.384) (https://forum.doom9.org/showthread.php?t=174544)

[flossy_cake]

IIRC it will load them in alphabetical order, so the "bwdif (v1.2.5).dll" in your example will be used because it load after the 1st one, I think it's a same thing for avsi

For completeness I just tested this now and indeed Avisynth uses whichever one comes alphabetically last. Makes sense if Avisynth is just iterating through all dll's in alphabetical order and loading each one.

Yes, that works, but beware of possible problems if the dll name has "_" underscore in it. [eg dll = "TIVTC_v1026.dll"]

Checked this as well and it seems Avisynth is only looking for the last underscore so there can be others before it and it works fine, at least in my testing (don't hold me to it!).

I tried hyphens and that produced some weirditude...

MyScript.avs:
MyFunc-AnyRandomStringHere() #triggers stuff in MyFunc()

MyScript.avsi in plugins64:

function MyFunc(val "arg1"){
Assert(Defined(arg1), "Inside MyFunc() - arg1 is not defined")
}

[LigH]

Hyphens are not allowed as part of identifiers; they should cause a syntax error due to an invalid function name...

[flossy_cake]

Regarding Gavino's memory leak workaround:


And see Gavino stuff here [try move as much code as you can out of Scriptclip script and into function].

string (as a whole) is created only once when the containing script is loaded. However, that string itself is parsed afresh on every frame, which means that any identifiers and string literals within it are repeatedly added to the string heap...this was the source of a memory leak in SRestore

The solution is to move the code inside the run-time script to another function, reducing the run-time script itself to a simple function call. This effectively eliminates memory problems, and also gives a speed increase.

In other words, instead of
ScriptClip("""
... very long script ...
""")
use
function f(... some params ...) {
... previous script code ...
}
...
ScriptClip("f(...)")




The workaround was working nicely until I started setting some debug strings and got large memory leak again. It seems the string concatenation (+) is the culprit:


ColorBars().ConvertToYV12().KillAudio()

ScriptClip(last, "Leak(last, current_frame)", after_frame=true, local=false)

function Leak(clip c, int current_frame){

# doesn't leak
# string =
# \ "stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring
# \ stringstringstringstringstringstringstringstringstringstringstringstringstringstring"

# leaks 1MB/sec
string =
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string" +
\ "string" + "string" + "string" + "string" + "string" + "string" + "string" + "string"

c
}

[real.finder]

thanks, that work but will all other 2.5 plugins will not work? there are some of them even close source

I was test some old script that use yadifmod (I have tritical one not Chikuzen) and I note the same problem, so I think any avs 2.5 plugin can have this problem

[Gavino]

Hyphens are not allowed as part of identifiers; they should cause a syntax error due to an invalid function name...
Not a syntax error as such, but a hyphen is interpreted as a 'minus' sign, so in the example
MyFunc-AnyRandomStringHere() #triggers stuff in MyFunc()
it will attempt to call MyFunc and subtract the result of AnyRandomStringHere().

[flossy_cake]

:scared: what has happened to the wiki @ avisynth.nl?
Heaps of pages missing / incomplete / old

[StainlessS]

:scared: what has happened to the wiki @ avisynth.nl?
Heaps of pages missing / incomplete / old
Dont know.

(replying to flossy_cake) Hyphens are not allowed as part of identifiers; they should cause a syntax error due to an invalid function name...

Valid Variable/FunctionName/ identifier [really also applies to dll name excluding the ".dll" appended to end].

1st character, "_" or Alpha character.
Thereafter = "_" or Alpha character, or digit.
(other languages tend to have exact same requirement for identifiers)

[VoodooFX]

:scared: what has happened to the wiki @ avisynth.nl?
Heaps of pages missing / incomplete / old

Looks like a back-up from 2013, 10 years of stuff missing.

[flossy_cake]

Looks like a back-up from 2013, 10 years of stuff missing.

I'll be pulling my hair out if that's the only backup they've got.

[DJATOM]

Fortunately wayback snapshot available - https://web.archive.org/web/20230729032301/http://avisynth.nl/index.php/Main_Page. Someone very dedicated can site-rip that content and put back onto the site :D

[FranceBB]

:scared: what has happened to the wiki @ avisynth.nl?

Wilbert changed his hosting company: https://forum.doom9.org/showthread.php?p=1990518

Looks like a back-up from 2013, 10 years of stuff missing.

Yeah... July 2013... :scared:

I'll be pulling my hair out if that's the only backup they've got.

As a regular contributor, I feel your pain...
I think only Wilbert can answer our questions...

Fortunately wayback snapshot available - https://web.archive.org/web/20230729032301/http://avisynth.nl/index.php/Main_Page. Someone very dedicated can site-rip that content and put back onto the site :D

Yeah, copy-pasting is better than rewriting everything, sure, but still... if we actually have to do this I'm gonna cry...

https://media0.giphy.com/media/v1.Y2lkPTc5MGI3NjExNG9mdXRnMzFhdWZkOXEwcXllbnN6YzBkN2p5ZXA3cjR1ZHZpYnY2dCZlcD12MV9naWZzX3NlYXJjaCZjdD1n/l378giAZgxPw3eO52/giphy.gif

[flossy_cake]

The wiki has been restored. All's right with the world.

[FranceBB]

Yep, it's back to a modern backup. Nice.

[kedautinh12]

I'm still got 404 error with this page
https://avisynth.nl/index.php/External_filters

[VoodooFX]

I think https never worked, use this: http://avisynth.nl/index.php/External_filters

[flossy_cake]

Yeah that's always been an issue for me as well - the wiki site has no support for https. Often I'll open a link and my browser automatically changes it to https and then I have to manually delete the s, it's quite annoying and frankly I don't know how that could even be a thing.

[flossy_cake]

Does Avisynth not have a clip property for colour range (16-235 vs 0-255)?

There appears to be a FRAME property, but that relies on the source filter setting it.

Surely Avisynth must know the colour range of the clip otherwise its internal processing would be all wrong. Should I just infer that if the pixel type is YV12 that it's limited range, or is there such a thing as YV12 full range?

Thanks

[real.finder]

Does Avisynth not have a clip property for colour range (16-235 vs 0-255)?

There appears to be a FRAME property, but that relies on the source filter setting it.

Surely Avisynth must know the colour range of the clip otherwise its internal processing would be all wrong. Should I just infer that if the pixel type is YV12 that it's limited range, or is there such a thing as YV12 full range?

Thanks

I don't think there are clip property for this but there are http://avisynth.nl/index.php/Internal_functions#ColorRange and IIRC vs use frame property of frame 0 as clip property

and there are YV12 full range even in mpeg2 japanese tv but it's rare or very rare

[flossy_cake]

use frame property of frame 0 as clip property

I was going to do that but then I saw FFMS2 and DirectShowSource don't set the property at all, only LWLibAv does. I guess it's better than nothing so I'll use it if available.

I'm worried AverageLuma() will be different for full range vs limited. I'm trying to normalise my scenechange detection threshold to AverageLuma as I noticed brighter content has higher scenechange framediffs, especially brighter animation which was causing me some false positives.

[StainlessS]

I'm worried AverageLuma() will be different for full range vs limited.
Limited range luma mid point is 125.5 ie (16+235)/2.0 (rounded to 126),
whereas full range is 127.5 ie (0 + 255)/2.0 (rounded to 128).

EDIT: Also, Subtract always assumes limited range mid point 126, so
Subtract(ClipA,ClipA) always produces a clip where all luma result samples are 126.

[DTL]

I'm worried AverageLuma() will be different for full range vs limited. I'm trying to normalise my scenechange detection threshold to AverageLuma as I noticed brighter content has higher scenechange framediffs, especially brighter animation which was causing me some false positives.

You can try MSCDetection from mvtools. To make it faster the fastest settings may be provided to MAnalyse like pel=1, levels=1, searchparam=1 - so it will work mostly as SAD computing engine only. Though using some real MVs search and better SADs from single cutscene makes scenedetection even better.

As I see some plugins uses scenedetection based on SAD computing between frames (vsTTempSmooth and mvtools and maybe other too) and it work good enough.

[StainlessS]

Some SC detect stuff:- https://forum.doom9.org/showthread.php?p=1954985#post1954985

EDIT: Dont know if of any use


Function MMaskFromPrevClip(clip c,Int "MaskType",Float "Gamma",Int "thSCD1",Int "thSCD2") {
# MaskType:- 0=Motion, 1=SAD, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap.
MaskType=Default(MaskType,0) Gamma=Default(Gamma,1.0) thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
fv=sup.MAnalyse(isb=false,delta=1,blksize=16)
Return c.MMask(fv,Gamma=1.0,kind=MaskType,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function MMaskFromNextClip(clip c,Int "MaskType",Float "Gamma",Int "thSCD1",Int "thSCD2") {
# MaskType:- 0=Motion, 1=SAD, 2=Occlusion, 3=Horizontal, 4=Vertical, 5=ColorMap.
MaskType=Default(MaskType,0) Gamma=Default(Gamma,1.0) thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
bv=sup.MAnalyse(isb=True,delta=1,blksize=16)
Return c.MMask(bv,Gamma=1.0,kind=MaskType,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at EOS, else 0
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
bv=sup.MAnalyse(isb=true, delta=1,blksize=16)
Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function StartOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at SOS, else 0
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
fv=sup.MAnalyse(isb=false,delta=1,blksize=16)
Return c.MSCDetection(fv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function SceneCutClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma pixel = 0 =Norm, 1=EOS, 2=SOS, 3=EOS & SOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
Sup = c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
BvEos= Sup.MAnalyse(isb=True, delta=1,blksize=16)
FvSos= Sup.MAnalyse(isb=False, delta=1,blksize=16)
Eos = c.MSCDetection(BvEos,thSCD1=thSCD1,thSCD2=thSCD2)
Sos = c.MSCDetection(FvSos,thSCD1=thSCD1,thSCD2=thSCD2)
Return MT_Lutxy(Eos,Sos,yexpr="y 0 == x 0 == 0 1 ? x 0 == 2 3 ? ?",u=-128,v=-128)
}


EDIT: Added below
It works sorta like ScSelect/ScSelect_HBD, but you must also Provide a "BOTH" [ie both EOS and SOS detect] clip (you can choose whatever solution you like for that possible outcome).
You will likely fire a BOTH if there is a single frame scene cut, ie and 'odd' frame that belongs neither with previous nor following scenes.

Function SceneCutSelectClip(clip dClip,clip Start,clip End,clip Both,clip Motion,Int "thSCD1",Int "thSCD2") { # (c) ssS: https://forum.doom9.org/showthread.php?p=1955111#post1955111
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
Sup = dClip.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
BvEos= Sup.MAnalyse(isb=True, delta=1,blksize=16)
FvSos= Sup.MAnalyse(isb=False, delta=1,blksize=16)
Eos = dClip.MSCDetection(BvEos,thSCD1=thSCD1,thSCD2=thSCD2).crop(0,0,4,4)
Sos = dClip.MSCDetection(FvSos,thSCD1=thSCD1,thSCD2=thSCD2).crop(0,0,4,4)
CondS="""
ix = (Sos.AverageLuma>0?1:0) + (Eos.AverageLuma>0?2:0)
Return ix==0?Motion:ix==1?Start:ix==2?End:Both
"""
ARGS="Motion,CondS,Motion,Start,End,Both,Eos,Sos"
Motion.GSCriptClip(CondS,Args=ARGS,After_Frame=True,Local=True) # Requires Grunt
}

# Client
AviSource("D:\hard sub - 01 WEBdlRip 720p, 23.976.mkv.AVI")
dclip = BilinearResize(320,240).Blur(1.0) # Whatever (just testing frame size can be different to other clips)
ConvertToRGB32 # Just testing works where Dclip colorspace is differenct from the other clips.
Motion = Last
Start = Subtitle("START",size=64,align=5)
End = Subtitle("END",size=64,align=5)
Both = Subtitle("BOTH",size=64,align=5)
SceneCutSelectClip(dClip,Start,End,Both,Motion,400,130)


Also perhaps SCSelect_HBD() of interest too [Works a little like SCSelect but less likely to produce erroneous detect where near dupe either precedes or follows a dupe].
https://forum.doom9.org/showthread.php?t=182392

EDIT: By DTL,
To make it faster the fastest settings may be provided to MAnalyse like pel=1, levels=1, searchparam=1
Maybe add in the above DTL suggest options for eg "EndOfSceneClip()" to speed up a bit [we already used pel=1].
MAnalyse(int pelsearch) is defaulted to MSuper(pel), so defaults 1 below in MAnalyse.
EDIT: Eg (Presumed intent of DTL mods)

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2") { # All Luma Samples set 255 at EOS, else 0
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
sup=c.MSuper(pel=1,sharp=0,rfilter=2,hpad=16, vpad=16)
bv=sup.MAnalyse(isb=true, delta=1,blksize=16,Levels=1,searchparam=1) # Levels Default 0(ALL). searchparam Default=2 (radius)
Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

From MvTools2 docs
Search, searchparam, pelsearch

search decides the type of search at every level, searchparam is an additional parameter (step, radius) for this search, and pelsearch is the radius parameter at finest (pel) level. Below are the possible values for the search type:
0 'OneTimeSearch'. searchparam is the step between each vectors tried (if searchparam is superior to 1, step will be progressively refined).
1 'NStepSearch'. N is set by searchparam. It's the most well known of the MV search algorithm.
2 Logarithmic search, also named Diamond Search. searchparam is the initial step search, there again, it is refined progressively.
3 Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.
4 Hexagon search, searchparam is the range. (similar to x264).DEFAULT Search type
5 Uneven Multi Hexagon (UMH) search, searchparam is the range. (similar to x264).
6 pure Horizontal exhaustive search, searchparam is the radius (width is 2*radius+1).
7 pure Vertical exhaustive search, searchparam is the radius (height is 2*radius+1).



EDIT: above modded EndOfSceneClip(), pre mod = 33 secs on a sample clip, post mod = 27 secs on same clip.

[DTL]

"MAnalyse(isb=true, delta=1,blksize=16,Levels=1,searchparam=1)"

If quality is enough with levels=1 in MAnalyse - you can also set levels=1 for MSuper to skip calculating lower sized levels. Also idea to set large blocksize also may add good performance - try blocksize 32 or even 64 if quality still good. Also if function used with bitdepth > 8 clips - input to scenedetect function may be converted to fixed 8 bit to make performance better.

[StainlessS]

Thanks DTL, do these look OK-ish :) {in particular, MSuper(levels=Levels) and MAnalyse(levels=0<default ie All>)
Made defaults for better detection, but user moddable via args.


/*
BlkSz, Default 16. Allows for faster 32x32 and 64x64 block size (8 maybe better accuracy).
Pel, Default 2. (1 or 2 or 4) 1 is fastest.
Levels, Default 0 (ALL)
Search, Default 4 (4 Hexagon search)
Search decides the type of search at every level, searchparam is an additional parameter (step, radius) for this search, and pelsearch is the radius parameter at finest (pel) level. Below are the possible values for the search type:
0 'OneTimeSearch'. searchparam is the step between each vectors tried (if searchparam is superior to 1, step will be progressively refined).
1 'NStepSearch'. N is set by searchparam. It's the most well known of the MV search algorithm.
2 Logarithmic search, also named Diamond Search. searchparam is the initial step search, there again, it is refined progressively.
3 Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.
4 Hexagon search, searchparam is the range. (similar to x264). # MVTOOLS DEFAULT.
5 Uneven Multi Hexagon (UMH) search, searchparam is the range. (similar to x264).
6 pure Horizontal exhaustive search, searchparam is the radius (width is 2*radius+1).
7 pure Vertical exhaustive search, searchparam is the radius (height is 2*radius+1).
SearchParam, Default 2
TM, Default true. (MAnalyse(TrueMotion=TM), but MAnalyse(Global=True) even when TM=False) <TrueMotion is a group setting>
Bits8, Default False, True forces source conversion to 8 bit (8 bit result clip).
Chroma, Default true, False, dont use chroma in analysis {BEST change to false if greyscale}
*/

Function EndOfSceneClip(clip c,Int "thSCD1",Int "thSCD2",
\ int "BlkSz", int "Pel",int "Levels",int "Search",int "SearchParam",Bool "TM",Bool "Bits8",bool "Chroma") { # All Luma (and Chroma) Samples set 255 at EOS, else 0
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
BlkSz=Default(BlkSz,16) Pel=Default(Pel,2) Levels=Default(Levels,0)
Search=Default(Search,4) SearchParam=Default(SearchParam,2) TM=Default(TM,True)
Bits8=Default(Bits8,False) Chroma=Default(Chroma,true)
Pad=Max(BlkSz,8)
Try{bpc=c.BitsPerComponent} Catch(msg) {bpc=8}
c = (bpc==8 || !Bits8) ? c : c.ConvertBits(8)
sup=c.MSuper(hpad=Pad, vpad=Pad, pel=Pel, levels=Levels, chroma=Chroma, sharp=0, rfilter=2)
bv=sup.MAnalyse(isb=true, blksize=BlkSz, levels=Levels,search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
Return c.MSCDetection(bv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function StartOfSceneClip(clip c,Int "thSCD1",Int "thSCD2",
\ int "BlkSz",int "Pel",int "Levels",int "Search",int "SearchParam",Bool "TM",Bool "Bits8",bool "Chroma") { # All Luma (and Chroma) Samples set 255 at SOS, else 0
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
BlkSz=Default(BlkSz,16) Pel=Default(Pel,2) Levels=Default(Levels,0)
Search=Default(Search,4) SearchParam=Default(SearchParam,2) TM=Default(TM,True)
Bits8=Default(Bits8,False) Chroma=Default(Chroma,true)
Pad=Max(BlkSz,8)
Try{bpc=c.BitsPerComponent} Catch(msg) {bpc=8}
c = (bpc==8 || !Bits8) ? c : c.ConvertBits(8)
sup=c.MSuper(hpad=Pad, vpad=Pad, pel=Pel, levels=Levels, chroma=Chroma, sharp=0, rfilter=2)
fv=sup.MAnalyse(isb=false, blksize=BlkSz, levels=Levels, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
Return c.MSCDetection(fv,thSCD1=thSCD1,thSCD2=thSCD2)
}

Function SceneCutClip(clip c,Int "thSCD1",Int "thSCD2",
\ int "BlkSz", int "Pel",int "Levels",int "Search",int "SearchParam",Bool "TM",Bool "Bits8",bool "Chroma") { # All Luma samples = 0 =Norm, 1=EOS, 2=SOS, 3=EOS & SOS
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
BlkSz=Default(BlkSz,16) Pel=Default(Pel,2) Levels=Default(Levels,0)
Search=Default(Search,4) SearchParam=Default(SearchParam,2) TM=Default(TM,True)
Bits8=Default(Bits8,False) Chroma=Default(Chroma,true)
Pad=Max(BlkSz,8)
Try{bpc=c.BitsPerComponent} Catch(msg) {bpc=8}
c = (bpc==8 || !Bits8) ? c : c.ConvertBits(8)
sup=c.MSuper(hpad=Pad, vpad=Pad, pel=Pel, levels=Levels, chroma=Chroma, sharp=0, rfilter=2)
BvEos= Sup.MAnalyse(isb=True, blksize=BlkSz, levels=Levels, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
FvSos= Sup.MAnalyse(isb=False, blksize=BlkSz, levels=Levels, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
Eos = c.MSCDetection(BvEos,thSCD1=thSCD1,thSCD2=thSCD2)
Sos = c.MSCDetection(FvSos,thSCD1=thSCD1,thSCD2=thSCD2)
Return MT_Lutxy(Eos,Sos,yexpr="y 0 == x 0 == 0 1 ? x 0 == 2 3 ? ?",u=-128,v=-128)
}

Function SceneCutSelectClip(clip dClip,clip Start,clip End,clip Both,clip Motion,Int "thSCD1",Int "thSCD2",
\ int "BlkSz",int "Pel",int "Levels",int "Search",int "SearchParam",Bool "TM",Bool "Bits8",bool "Chroma") {
thSCD1=Default(thSCD1,400) thSCD2=Default(thSCD2,130)
BlkSz=Default(BlkSz,16)
Pel=Default(Pel,2) Levels=Default(Levels,0)
Search=Default(Search,4) SearchParam=Default(SearchParam,2) TM=Default(TM,True)
Bits8=Default(Bits8,False) Chroma=Default(Chroma,true)
Pad=Max(BlkSz,8)
Try{bpc=dClip.BitsPerComponent} Catch(msg) {bpc=8}
dClip = (bpc==8 || !Bits8) ? dClip : dClip.ConvertBits(8)
sup = dClip.MSuper(hpad=Pad, vpad=Pad, pel=Pel, levels=Levels, chroma=Chroma, sharp=0, rfilter=2)
BvEos= Sup.MAnalyse(isb=True, blksize=BlkSz, levels=Levels, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
FvSos= Sup.MAnalyse(isb=False, blksize=BlkSz, levels=Levels, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)
Eos = dClip.MSCDetection(BvEos,thSCD1=thSCD1,thSCD2=thSCD2).crop(0,0,4,4)
Sos = dClip.MSCDetection(FvSos,thSCD1=thSCD1,thSCD2=thSCD2).crop(0,0,4,4)
CondS="""
ix = (Sos.AverageLuma>0?1:0) + (Eos.AverageLuma>0?2:0)
Return ix==0?Motion:ix==1?Start:ix==2?End:Both
"""
ARGS="Motion,CondS,Motion,Start,End,Both,Eos,Sos"
Motion.GSCriptClip(CondS,Args=ARGS,After_Frame=True,Local=True) # Requires Grunt
}

EDIT: BugFix In BLUE changed from 'c' to dClip.

Testing 1, 2, 3

AviSource(".\DE.avi")
Trim(2543,0)
ConvertBits(10) # TESTING
ORG=Last
Try{bpc=ORG.BitsPerComponent} Catch(msg) {bpc=8} # Remember original bit depth
#########

BLKSZ = 16 # 16
PEL = 2 # 2
LEVELS = 0 # 0
SEARCH = 4 # 4 <Hexagon search>
SEARCHPARAM = 2 # 2 <radius>
TM = True # True <MAnalyse(TrueMotion=TM), but MAnalyse(global) ALWAYS true> <TrueMotion is a group setting>
BITS8 = False # False
CHROMA = True # True, Best change to false if greyscale

#
SZ=Height/16
STARTC=ORG.Subtitle("START OF SCENE",Size=SZ,Align=5)
ENDC=ORG.Subtitle("END OF SCENE",Size=SZ,Align=5)
BOTHC=ORG.Subtitle("BOTH START AND END OF SCENE",Size=SZ,Align=5)

##########
# UNCOMMENT ONLY ONE of BELOW LINES

#EndOfSceneClip(Last,blksz=BLKSZ,pel=PEL,search=SEARCH,Searchparam=SEARCHPARAM,bits8=BITS8,Chroma=CHROMA)
#StartOfSceneClip(Last,blksz=BLKSZ,pel=PEL,search=SEARCH,Searchparam=SEARCHPARAM,bits8=BITS8,Chroma=CHROMA)
#SceneCutClip(Last,blksz=BLKSZ,pel=PEL,search=SEARCH,Searchparam=SEARCHPARAM,bits8=BITS8,Chroma=CHROMA).ScriptClip("""Subtitle(String(AverageLuma,"%.0f"),Size=48)""")
SceneCutSelectClip(Last,StartC,EndC,BothC,Last,blksz=BLKSZ,pel=PEL,search=SEARCH,Searchparam=SEARCHPARAM,bits8=BITS8,Chroma=CHROMA)

##########

Try{StackVertical(ORG,Last)} Catch(msg){StackVertical(ORG,Last.ConvertBits(bpc)) }

Return last

BugFix EDITED:

[DTL]

"sup=c.MSuper(hpad=Pad, vpad=Pad, pel=Pel, levels=Levels, chroma=Chroma, sharp=0, rfilter=2)
bv=sup.MAnalyse(isb=true, blksize=BlkSz, search=Search, searchparam=SearchParam, chroma=Chroma, delta=1,truemotion=TM, global=True)"

Default levels in MAnalyse is 0 (all), so user can not set levels in MSuper < levels in MAnalyse. MAnalyse will throw error "not enough levels in super clip". So for performance user may set equal 'levels' number in MSuper and MAnalyse.

Also chroma typically not very critical and may be skipped for scenechange detection with good performance boost at many types of content.

[StainlessS]

Post 2631, Fixed bug in SceneCutSelectClip, used clip c, instead of dClip, marked in BLUE.

Also, changed MAnalyse(levels=Levels) # I thought Default levels=0, meant All levels as set for MSuper.

Thanx DTL for the help, 2 operations on Dislocated and Broken ankle make for bad moods and shitty thinking. :(

[flossy_cake]

Also chroma typically not very critical and may be skipped for scenechange detection with good performance boost at many types of content.
@Stainless

Coincidentally I was wondering about chroma weighting in Stainless's RT_FrameDifference(): 0.333 for chroma and 0.666 for luma. I am curious to know the reasoning behind this if Stainless wouldn't mind explaining. I have been using this weighting for my scene change detection and it seems to work quite well, even better if I scale it to AverageLuma() and use change of value instead of absolute value (avoid false positive on fast pans). Still some rare false positive on contrasty animation when character fills the screen and does some large 1-frame gestures like waving arms or something. But it is fast and can be implemented with Avisynth built in Y/U/VDifferenceToNext(). Realtime performance (60+fps on quad core) is a requirement so I can't really use MVTools as I'm already leaving some headroom for that with a QTGMC pass later on. I'm biasing my errors towards false positive instead of false negative. Is there such a thing as perfect scene change detection?

[StainlessS]

RT_FrameDifference(): 0.333 for chroma and 0.666 for luma.
Actually, I've come to prefer ChromaWeight in the region of about 0.10 -> 0.20, or of course, just use 0.0 for luma only.
Obviously use ChromaWeight=0.0 for greyscale.
I had a clip where was a sort of nightclub situation under red light, ChromaWeight=0.0 was real bad detections, non zero much better.

EDIT: Also, I remember in one of the X-Men movies, in the room where all mutant 'souls' were projected onto a wall, ChromaWeight=0.0
could not tell apart different scene frames that should be totally different and were much better detected with non 0.0 chromaweight.

I'm biasing my errors towards false positive instead of false negative.
Same preferred here. [EDIT: Also, it is a lot easier to manual edit false positive to no detect, than the other way around]
Is there such a thing as perfect scene change detection?
Dont be silly :) [EDIT: Take a look at some of JohnMeyer American Football clips]
SC detection quickly loses its fun factor, kinda like banging your head against a wall.
(Some A.I. thingy might be better one day)

EDIT: Also, simple difference dont take into account ambient light level, low light situation differences should be weighted higher, somehow.
EDIT: Where there is some visible color in low light, I think non 0.0 Chromaweight should detect better (as for the nightclub situation in 1st paragraph).

[flossy_cake]

EDIT: Also, simple difference dont take into account ambient light level, low light situation differences should be weighted higher, somehow.

What you're describing sounds like what I meant by scaling the framediff to AverageLuma - or did you mean something else?

[StainlessS]

Sounds similar.

[pokota]

Quick question - are the plugins folders searched recursively (that is, can I organize my plugins into folders within the plugins folder)? I'm setting up AnimeIVTC and would prefer to keep "the stuff AnimeIVTC depends on" separate from the small collection of plugins I already have.

[poisondeathray]

Quick question - are the plugins folders searched recursively (that is, can I organize my plugins into folders within the plugins folder)? I'm setting up AnimeIVTC and would prefer to keep "the stuff AnimeIVTC depends on" separate from the small collection of plugins I already have.

Subfolders are not parsed

[StainlessS]

pokota, You can have a loader avsi to load plugins in sub folder.

[flossy_cake]

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression


global withAudio = ColorBars().ConvertToYV12().Text("withAudio")

global withoutAudio = ColorBars().ConvertToYV12().KillAudio().Text("withoutAudio")

ScriptClip(withoutAudio, "return withAudio", after_frame=true, local=false)

# the returned clip appears to be equivalent to AudioDub(withAudio, withoutAudio)

[Gavino]

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression
That's by design.
ScriptClip doesn't do any audio processing, it only operates on the video track.

[flossy_cake]

If it's by design, then I would say it's not very good design as I noticed just now that it also sets the field parity of the returned clip to that of the one being iterated on.


last = ColorBars().ConvertToYV12().KillAudio()
global tff = last.AssumeTFF().Text("TFF", align=9)
global bff = last.AssumeBFF().Text("BFF", align=9)
ScriptClip(tff, "return bff", after_frame=true, local=false)
info()


This will cause problems for filters downstream from the ScriptClip which need to see its field order, such as if the ScriptClip returns DoubleWeave which has alternating field order. Hopefully this can be worked around by manually setting the parity of each frame back to what it should be via a custom frame property.

[wonkey_monkey]

If it's by design, then I would say it's not very good design

It has to get its output clip properties from somewhere, and while it's easy for a human to look at "return bff" and know that it's just returning all the frames of bff, it would (correct me if I'm wrong, Gavino) be far too complicated for ScriptClip to be able to do this kind of introspection on arbitrary inputs. For a lot of scripts it would just be impossible - for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

[flossy_cake]

for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

I believe the fps of the input clip and return clip have to be the same for it to work correctly, otherwise eg. if input clip is 30 and return clip is 60, the output plays back at half speed.

I don't see the need to modify the audio or field order of the output clip.

[flossy_cake]

Also sorry if my comments about ScriptClip sound overly critical - I've been fighting with it the past few weeks and it's causing me a lot of headaches getting it to play nice with multithreading, avoiding memory leaks and my QTGMC output was broken due to this field order issue. Gavino's Grunt thread page 1 has some quotes from other members noting how quirky and strange the runtime environment is, so I know I'm not alone in this frustration.

[flossy_cake]

I'm just playing around with Avisynth's internal TimeStretch audio filter and was wondering about this:

Since tempo, rate and pitch are floating-point values, but sample rates are integers, rounding effects in calculations are unavoidable; the resulting audio track duration may be off by up to several 10's of milliseconds (less than one video frame) per hour.

Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

I was thinking... is it possible to somehow force a manual audio resync every n minutes, to nudge it back in sync? Could this be done in Aviysynth scripting or only within the TimeStretch plugin itself?

[tebasuna51]

...
Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

The time can't be stretched.

The audio don't be never stretched, if it is not in sync with the video is a video fps problem. Play the video at fps it was filmed and the audio is always in sync.

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

BTW if you want modify the real audio duration to fit the wrong video duration you can add some correction at your taste, there are audio editors.

[flossy_cake]

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

I think that depends if you used ChangeFPS() or AssumeFPS().

Anyway, I'm not modifying the video fps at all. The TimeStretch function only processes audio, and I'm going to be modifying audio pitch while retaining audio length, and the wiki says audio length will be slightly off due to unavoidable rounding errors, and if the audio length is different then it's not going to be in sync with video.

I tried to reproduce it by taking a 1hr clip and Loop(20).TimeStretch(pitch_n=24000, pitch_d=25025) to simulate pitch down of 4% and skipped to the end and audio was still in sync. But I don't think this simulates the issue - I'll probably have to leave the video running overnight and come back the next day and see if it's still in sync.

If it isn't, then I had an idea: split the clip into say 3 hour chunks with Trim, and do the TimeStretch() on each individual clip before joining them back together with ++. But then maybe there will be a little audio glitch every 3 hours at the splice point. I think the optimal solution would be for TimeStretch to handle it internally and when it detects drift is > some value it should smooth over the resync point using its own timestretching algorithms.

[r0lZ]

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible. So, unless you want absolutely to watch a 24 hours movie, you should not worry too much.

[flossy_cake]

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible.

In MPC-HC I can adjust audio delay with hotkeys in 10ms increments and at 100ms it's noticeable to me the lip sync is off.

[pinterf]

Heh - small fix for UV scale at RGB<->YUV at 'limited/narrow' levels mapping https://forum.doom9.org/showthread.php?p=1988318#post1988318 is not included in the 3.7.3 release. Pinterf promised to make a big redesign of all 'convert' core functions with a fix for this issue included (also with better performance) but it looks like it will happen in some 3.7.4testXXX next builds. So currently with 3.7.3 release the same workaround with additional UV scaling is required.
Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change. Probably I'm going to upload the changes as is to the git repo, because I didn't find issues by myself.

[pinterf]

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

https://i.postimg.cc/4yZLWYbZ/Untitled.png (https://postimages.org/)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error
Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

[FranceBB]

Is it still an issue the 3.7.3 release?

No, looks like it was broken in some of the 3.7.3 test but eventually got fixed in the stable build:

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


Sorry for not closing this https://github.com/AviSynth/AviSynthPlus/issues/365 I should have checked too, but I very rarely have time to do anything nowadays... :(

I'm gonna comment it there too, thank you as always, Ferenc, the conditional to check the version of the plugins and apply the workaround is indeed working as expected ;)

Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change.

Don't worry, I think plenty of people here are gonna be more than happy to test it on the field as soon as the first 3.7.4 test1 release is gonna be available (me included). Testing is literally the least we could do ;)

[StvG]

Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

It's still an issue with 3.7.3 release. I reproduced it with this version (http://ldesoras.free.fr/src/avs/dither-1.28.1.zip) (the version from here (http://avisynth.nl/index.php/Dither)).
What version did you use?

[FranceBB]

It's still an issue with 3.7.3 release. I reproduced it with this version (http://ldesoras.free.fr/src/avs/dither-1.28.1.zip) (the version from here (http://avisynth.nl/index.php/Dither)).
What version did you use?

Just to keep everyone aligned, the conversation is continuing here: https://github.com/AviSynth/AviSynthPlus/issues/365

I used v1.28.0 built on Wednesday 07 October 2020, 16.27.15 however even if I swap dither.dll 1.28.0 from October 2020 with the one you provided (which is the same as the one provided by Real Finder) that was built on Monday 17 July 2023, 08.33.18, I get the same result:

https://user-images.githubusercontent.com/18946343/275250175-9839e62b-95e4-4346-8d23-fa0ecebefb84.png

VersionString: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.3.0 / 3.7.3.0
Interface Version: 10
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2023-07-15, 21:48:08 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

[C 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\assrender.dll [0.35.0.0, 2021-03-04]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ncnn.dll [1.0.1.0, 2023-03-20]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ov.dll [1.0.0.0, 2023-03-20]

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\dither.dll [n/a, 2023-07-17]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRMatrix-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRNoise-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRSharp-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\LeakKernelDeint.dll [1.5.4.0, 2010-03-14]
C:\Program Files (x86)\AviSynth+\plugins64+\VSFilter.dll [3.0.0.306, 2014-12-07]
C:\Program Files (x86)\AviSynth+\plugins64+\warpsharp.dll [n/a, 2011-06-14]

Play audio is of course enabled in AVSPmod mod.


Ferenc also tried to reproduce it, but to no avail... :(
The fact that you can also reproduce this, StvG, and not just real.finder, means that there's something really there.
In the meantime, despite not being able to reproduce the issue (just like I can't reproduce it on my pc :( ), Ferenc made some changes and provided a test build https://drive.google.com/uc?export=download&id=1xHP6jaFDpAb4j4pXKoVe2L6rw2qEohs4
Testing on my computer would be pointless 'cause I can't reproduce the error anyway, so can you guys who can actually reproduce the error, test the new build and see if it solves it?

[StvG]

@FranceBB, thanks for the info.

From that github thread, it seems they found the culprit.

[FranceBB]

From that github thread, it seems they found the culprit.

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link (https://drive.google.com/uc?export=download&id=1auyCcQRg1QJbSc6RL1Rq53ApJ7KTVzxN)

[pinterf]

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link (https://drive.google.com/uc?export=download&id=1auyCcQRg1QJbSc6RL1Rq53ApJ7KTVzxN)
yes, but do not use it yet for production please, contains some unfinished code parts on other areas. Wait a little bit for the official git commits.

[pinterf]

Try this one. Much safer, git commits are still not uploaded, I'd wait a bit.
Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013) (https://drive.google.com/uc?export=download&id=1xQ9EmT2LG5Ouqz-Je7rvDTP01Sc4Ve5i)

20231019 3.7.3 post 4
---------------------
- Fix #365 (https://github.com/AviSynth/AviSynthPlus/issues/365)
Avisynth 2.5 plugins when NICE_FILTER would crash with "invalid response to CACHE_GETCHILD_AUDIO_MODE".
Bug appeared since reintroducing audio cache in 3.7.3.
- Fix #370: array size assert error in ConvertToYUY2 when internally ConvertTo422 is called.
Reason: ConvertToYUV422 has one more parameter (ChromaOutPlacement) than ConvertToYUY2 has
- Issues mentioned in #354 https://github.com/AviSynth/AviSynthPlus/issues/354
- Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601",
for example in ConvertToRGB32.
Formerly _ColorRange property would always set to 0 (full range), even if a limited range
clip (e.g. ColorBarsHD) was inputted. Now we act as the specification
( http://avisynth.nl/index.php/Convert ) says:
"PC.601 and PC.709 keep the range unchanged, instead of converting between 0-255 RGB
and 16-235 YUV, as is the normal practice."
Now ColorBarsHD().ConvertToRGB32(matrix="PC.601").propShow()
would display "_ColorRange=1 (limited)", since ColorbarsHD's output is limited as well.
- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx.
When input or output would require it, rgb offset of 16 (or scaled equivalents) is used
for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)

[FranceBB]

Try this one. Much safer, git commits are still not uploaded, I'd wait a bit.
Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013) (https://drive.google.com/uc?export=download&id=1xQ9EmT2LG5Ouqz-Je7rvDTP01Sc4Ve5i)


- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx.
When input or output would require it, rgb offset of 16 (or scaled equivalents) is used
for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)

Uhhhhh, as someone who's forced to work with Studio RGB (Narrow Range) all the time this is very much appreciated! :D

[pinterf]

Uhhhhh, as someone who's forced to work with Studio RGB (Narrow Range) all the time this is very much appreciated! :D
This one was quite a huge change throughout the code, this is why I haven't uploaded the source it to github yet. Pls. report if old things would get broken or something is not clear or illogical.

[FranceBB]

Well, I was testing exactly that and I noticed another issue. :(
Unfortunately, PlanarTools (http://avisynth.nl/index.php/PlanarTools) produce an Access Violation both with 3.7.3 stable and with this new build.


FFImageSource("Image.png")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

The image is a simple RGB32 (so RGB24 + 8 for the alpha channel) png lossless, but it can be replaced with a simple ColorBars():


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

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

This was tested on Windows 10 22H2 x64 Enterprise, but I also tested it on Windows XP x86 Professional and the result is also an error but perhaps even worse:

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

[pinterf]

Well, I was testing exactly that and I noticed another issue. :(
Unfortunately, PlanarTools (http://avisynth.nl/index.php/PlanarTools) produce an Access Violation both with 3.7.3 stable and with this new build.


FFImageSource("Image.png")

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

The image is a simple RGB32 (so RGB24 + 8 for the alpha channel) png lossless, but it can be replaced with a simple ColorBars():


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

ExtractPlane(0)


https://i.imgur.com/2Zc69XI.png

This was tested on Windows 10 22H2 x64 Enterprise, but I also tested it on Windows XP x86 Professional and the result is also an error but perhaps even worse:

https://i.imgur.com/Nsamsd0.png
The latest source code does not have a binary release.

But this PlanarTools is crashing of course. It is using the IScriptEnvironment2 interface which is not allowed and Avisynth version dependant.

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.
----------------------------------------------------------------------------- */



As I can see, this issue is already fixed in the github source and is using the usual SetCacheHints method instead of calling the crashing SetFilterMTMode. So a rebuild would help.

[FranceBB]

Gotcha!
Well, I used this as a temporary workaround:

FFImageSource("image.png")

my_alpha=ShowAlpha(pixel_type="RGB24")


RemoveAlphaPlane()

ConvertBits(16)
ConvertToPlanarRGB(matrix="PC.709", interlaced=false)

Cube("3a_BT709_HLG_Type1.cube", interp=1, fullrange=1)

my_HLG=last

ConvertBits(my_alpha, 16)
ConvertToPlanarRGB(matrix="PC.709", interlaced=false)

Cube("3a_BT709_HLG_Type1.cube", interp=1, fullrange=1)

ConverttoY(matrix="PC.2020")


my_alpha_HLG=last


AddAlphaPlane(my_HLG, my_alpha_HLG)


There I was working in Full Range with your new build and it was fine as levels were preserved during the conversion given that I used "PC.2020".
About RGB Narrow Range, this is an RGB 16bit Limited TV Range (i.e Narrow Range) in PQ:


Frame: 831
Keys: 15
MasteringDisplayMaxLuminance (4000.0)
MasteringDisplayMinLuminance (0.005)
MasteringDisplayPrimariesX (0.68, 0.265, 0.15)
MasteringDisplayPrimariesY (0.32, 0.69, 0.06)
MasteringDisplayWhitePointX (0.3127)
MasteringDisplayWhitePointY (0.329)
_AbsoluteTime (34.659625)
_ColorRange (1[limited])
_DurationDen (24000)
_DurationNum (1001)
_FieldBased (0[progressive])
_Matrix (0[RGB])
_PictType (I)
_SARDen (1)
_SARNum (0)


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


it's correctly recognized as limited tv range RGB.
Now, in 3.7.3 stable, if I did something like:


#Indexing Studio RGB PQ
LWLibavVideoSource("Test.mxf")

ConverttoYUV444(matrix="Rec2020")

then levels would have been screwed 'cause everything would have been shrinked 'cause it basically was gonna do the limited of the limited tv range as it automatically assumed that RGB was Full Range, in fact:

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

which is clearly wrong.
Now, as per your new build, I expected it to read the Limited TV Range flag and actually get it right automagically, however I seem to be misunderstanding something 'cause this:

#Indexing Studio RGB PQ
LWLibavVideoSource("Test.mxf")

ConverttoYUV444()

results in the same (wrong) level shift as it does the limited of the limited again:

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

I even tried to force the range detection with:

PropSet("_ColorRange", 1)

just to be 100% sure, but nothing...

This is the build:

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

[real.finder]

The latest source code does not have a binary release.

But this PlanarTools is crashing of course. It is using the IScriptEnvironment2 interface which is not allowed and Avisynth version dependant.

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.
----------------------------------------------------------------------------- */



As I can see, this issue is already fixed in the github source and is using the usual SetCacheHints method instead of calling the crashing SetFilterMTMode. So a rebuild would help.

back then https://forum.doom9.org/showpost.php?p=1915428&postcount=473 it seems not worth it for avs+

ExtractPlane(0) can't be replaced with avs+ Extract()? like ExtractR()

[pinterf]

FranceBB, thanks for the feedback, I'm looking into that.
edit: my bad, I've propably used cut-and-paste at one place instead of copy-paste, so before RGB->444 conversion no properties were obtained from 0th frame. Expect new builds on Friday.
edit2: Thursday is the new Friday. :)
Avisynth+ 3.7.3post test 5 (20231026 - r4017) (https://drive.google.com/uc?export=download&id=1gFcu3Wp3jRiT7lAi7WzrV3Rym7y9jcPO)
(with narrow rgb -> 444 fix - hopefully)

[pinterf]

Avisynth+ 3.7.3post test 6b (20231031 - r4018) (https://drive.google.com/uc?export=download&id=1ONJtxKUXh4L-eQi3j7_RoSbVJUdvfg3f)

Change from test5:
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the
second one is an empty line.
See also https://forum.doom9.org/showthread.php?t=185145

edit: zip content fixed.

[Emulgator]

Jó estet Ferenc !
Here my findings from 17.03.2023 as I was puzzled too by AviSynth's typographic habits
while getting my portalscope tidied. Maybe it helps while rewriting documentation...
(Don't know the english wording for some typographical expressions, so please be kind and translate on your side.)

AviSynth Subtitle align

789
456
123

size (total line size) := 1/8 Unterlänge + 3/4 Capital letter size + 1/8 Akzent-Oberlänge

7 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist linksbündig, läuft ab x nach rechts
8 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist x-zentriert, läuft nach links und rechts
9 y:=Oberlänge, Text hängt unter seiner Akzent-Oberlänge y und ist rechtsbündig, läuft ab x nach links

4 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist linksbündig, läuft ab x nach rechts
5 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist x-zentriert, läuft nach links und rechts
6 y:=Grundlinie, Text steht auf seiner Grundlinie y und ist rechtsbündig, läuft ab x nach links

1 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist linksbündig, läuft ab x nach rechts
2 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist x-zentriert, läuft nach links und rechts
3 y:=Unterlänge, Text schwebt auf seiner Unterlänge y und ist rechtsbündig, läuft ab x nach links

Vertical centering:

7,8,9 y:=y-size/2
4,5,6 y:=y+size*3/8
1,2,3 y:=y+size/2

subtitle applies font_angle first, then aligns along the original orientation.

In the end AviSynth's derivation appears logical:
For a fullsize glyph having all possible underlengths/upperlengths/accents
giving one of the 4 width x height corner coordinates
any appropriate (inward running) alignment's rendering must result
in touching, but not exceeding both appropriate screen borders.

P.S. As this has been discussed recently,
I would concur that this had been conceived with only one-liners in mind,
so one should not expect any provisions for multiline-text.

[Rob105]

Vertical centering:

7,8,9 y:=y-size/2
4,5,6 y:=y+size*3/8
1,2,3 y:=y+size/2

Can you provide a working code or explain how i can adopt it to my code i am getting errors like I don't know what 'y' means.

[Reel.Deel]

Can you provide a working code or explain how i can adopt it to my code i am getting errors like I don't know what 'y' means.

Y is the height of the frame:

Colorbars()
y2 = (last.Height() + 18) / 2 # assume font size is 18
Subtitle("asdfg", y=y2)

[StainlessS]

Avisynth+ 3.7.3post test 6 (20231031 - r4018)

Change from test5:
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the
second one is an empty line.
See also https://forum.doom9.org/showthread.php?t=185145

"Ending "\n" is treated as a new empty line, so "Line1" is one line, but "Line1\n" has two lines and the second one is an empty line."

Nope, dont like that, but dont like below either :(
"Line1" has only a single line of text.
"Line1\n", has still only a single line of text, text written/flushed to output device, and logical print cursor position moves down 1 line due to NewLine '\n',
but there is no more text to print and so still only a single line of text was output.
"Line1\nLine2", 2 lines output, "Line1" and "Line2", with a Newline moving cursor down between them.
"Line1\nLine2\n", 2 lines output, "Line1" and "Line2", with a Newlines moving cursor down after both of them.
A final move of the cursor (after final print line) does not affect the number of lines printed.
[EDIT: This Line in SubV script function,
# Line count with/without final newline
means that we want only the text lines count, and it has to be the same whether or not the multiline string ends with a newline or not.
END EDIT]


However, NewLines in any position other than at very end of the string, have to be counted as they affect the 'area' of [and position of any additional] print.
"\nLine2", is 2 lines. In this case leading empty line has to be taken into account. The initial '\n' prints empty line and then moves down 1 line and prints "Line2".
"\nLine2\n". is 2 lines, the initial '\n' prints empty line and then moves down 1 line and prints "Line2", the final '\n' only moves the cursor, does not affect 'area' of print.
"Line1\n\n". is 2 lines, the initial '\n' prints empty line and then moves down 1 which does affect print 'area', the final '\n' only moves the cursor, does NOT affect 'area' of print.
"\nLine2\n\n", is 3 lines, If an ending empty line is required (to affect justification) then cannot omit the final '\n' (ie "\nLine2\n" is only 2 lines, not 3).

"\nLine2\nLine3\n", is 3 lines. [final '\n' just moves cursor]
"\nLine2\nLine3\n\n", is 4 lines. [final '\n' just moves cursor]
"\n\nLine3\nLine4", is 4 lines.
"\n\nLine3\nLine4\n", is 4 lines. [final '\n' just moves cursor]
"\n\nLine3\nLine4\n\n", is 5 lines. [final '\n' just moves cursor]
"\n\nLine3\n\nLine5", is 5 lines.
"\n\nLine3\n\nLine5\n", is 5 lines. [final '\n' just moves cursor]
"\n\nLine3\n\nLine5\n\n", is 6 lines. [final '\n' just moves cursor]

Ending complete multi-line string with '\n' has no justifiication effect [same line count as the string without any trailing '\n'].
Ending complete multi-line string with '\n\n' vertical center justifies upwards by 0.5 lines [vertical print lines 'area' seems 1 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n' vertical center justifies upwards by 1 line [vertical print lines 'area' seems 2 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n\n' vertical center justifies upwards by 1.5 lines [vertical print lines 'area' seems 3 bigger than actual text lines].
Ending complete multi-line string with '\n\n\n\n\n' vertical center justifies upwards by 2.0 lines [vertical print lines 'area' seems 4 bigger than actual text lines].

Similarly, starting a multiline string with '\n' will vertical center justify downwards by 0.5 of a line (and '\n\n' by 1, and '\n\n\n' by 1.5).

Its a bit awkward to explain, but has to work like above so as to be able to affect vertical justification using Newlines.
To be sure that you are counting your newlines correctly, always end with '\n'.

[B]Counting Lines in Multi-line string:
For vertical justification we need to count the number of lines printed in a multi-line string.
So, firstly if the multi-line text string is "" then number of lines is 0, Otherwise below,
To count the text lines, you need to count the '\n' newlines, but, if newline '\n' does not occur at very end of the multi-line string, then counting
newlines alone gives wrong answer (you need add 1 to line count in such a case).

[kedautinh12]

@pinterf, the x64 folder of your download link is test 5 cause it's compiler at 27/10 while x64-xp, x86, x86-xp are test 6 cause it's compiler at 31/10

[pinterf]

Thanks, x86 folder contained an x64 dll as well, package is fixed, please redownload (the link was edited above)
@Emulgator, thank you
@StainlessS Thanks for the feedback, I'm going to digest your whole post later, I see now that newline count must be changed (following "Counting Lines in Multi-line string").
Till then, pls test it with this future change in mind. I'd really like to upload my changes to git before I die :) (I was lightly and gently hit by a car yesterday when riding home - fortunately I have no injuries)

[kedautinh12]

Hope someone inherit you before you die or avs+ will die so long before someone development it :D

[FranceBB]

(I was lightly and gently hit by a car yesterday when riding home - fortunately I have no injuries)

:scared:

OH!
I'm so sorry to hear that, Ferenc! :(
Get well soon and rest.

[wonkey_monkey]

Just came across an oddity. Since 2.54, ChangeFPS has a parameter linear = true which forces linear access (apparenly for up to 10 frame gaps).

If you use SelectEven (or some other frame-culling filter) after ChangeFPS with linear = true (the default), it will insist on fetching every frame, which can cause quite an unexpected slowdown.

Does anyone know the rationale for linear = true?

[StainlessS]

P,
This is source for RT_TxtQueryLines(), however it counts '\n' [Chr(10) Linefeed, rather than "\n" subtitle string style escape].
Some scriptors {MAC users ?} use Chr(13) {carriage return} instead of correct [IMHO] Chr(10) {LineFeed} for NewLine, we have to deal
with both in RT_TxtQueryLines(), but you do not have to do that for subtitle escaped strings.
We also do not know source of the provided string, and so have to cope with matched pairs of both '\r' + '\n' OR, '\n' + '\r'
just incase somebody got the order mixed up. DOS order should be CR/LF where paired {if you create a text file containing
lots of wrongly paired LF/CR, and load it into eg Word, it will drive the poor app crazy... very jumpy about-y}.
Use if you wish., should be easy modded.

Anyways, you be careful and stop having fights with the traffic, bicycle riders rarely win such fights.
This guy here was NEARLY lightly and gently hit by a car yesterday too [standing by his broken down car on motorway].
https://www.thesun.co.uk/motors/24589027/watch-shocking-moment-driver-smashes-into-stationary-lamborghini/

OOps, forgot the source.

AVSValue __cdecl RT_TxtQueryLines(AVSValue args, void* user_data, IScriptEnvironment* env) {
const char *Str=args[0].AsString();
const char *s=Str;
int c,Lines=0;
while(c=*s) {
if(c=='\n' || c == '\r') {
if((c=='\n' && s[1]=='\r') || (c=='\r' && s[1]=='\n'))
++s;
++Lines;
}
++s;
}
if(Str < s && s[-1] != '\n' && s[-1] != '\r')
++Lines; // Last line not n/l terminated, but still counts
return Lines;
}

[FranceBB]

Just came across an oddity. ChangeFPS has a parameter linear = true which forces linear access (apparenly for up to 10 frame gaps).

If you use SelectEven (or some other frame-culling filter) after ChangeFPS with linear = true (the default), it will insist on fetching every frame, which can cause quite an unexpected slowdown.

Does anyone know the rationale for linear = true?

I'd like to know it too, also 'cause it actually caused some errors in my scripts.
Essentially, if the difference between the ChangeFPS() target frame rate and the original clip framerate was higher than x it outputted an error and I've seen it in lots of logs as I was using it in one of my automated workflows.
I changed it to linear=false in the script, the files processed fine and I never looked back, but I'd like to know more on what exactly that parameter is doing.
Still, I think that linear=false will reproduce the original behavior, especially 'cause before that you could use ChangeFPS() on literally any FPS in input to produce any FPS in output by dropping or duplicating frames (the only one having limitations was ConvertFPS() instead as it uses blending).

This can be easily reproduced with:

Old Avisynth (works):

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

ChangeFPS(100)

ChangeFPS(5)

Avisynth 3.7.3 r4013 (doesn't work):

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

ChangeFPS(100)

ChangeFPS(5)

https://i.imgur.com/3NUlLQs.png

Avisynth 3.7.3 r4013 works (old behavior is restored with linear=false):

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

ChangeFPS(100, linear=false)

ChangeFPS(5, linear=false)


Wouldn't it make more sense to have linear=false set by default rather than having it set to true by default so that the old behavior is restored?

[tormento]

I'd really like to upload my changes to git before I die :)
I forbid you to die at least until you will introduce CUDA processing and filtering ;)

[Selur]

I forbid you to die at least until you will introduce CUDA processing and filtering
+ port a working removedirt to Vapoursynth :D
(using just specific mods (https://forum.doom9.org/showthread.php?t=185121) does kind of work, but is just a workaround)
;)

[DTL]

mvtools 2+ requires additional 10..20+ years of development too.

[pinterf]

P,
This is source for RT_TxtQueryLines(), however it counts '\n' [Chr(10) Linefeed, rather than "\n" subtitle string style escape].

Thanks, it's already a comment/uncomment in the code, anyway in SubTitle and Text the string "\n" is valid only if it's not inside a "\\n" sequence (which would print the \n string itself).

[pinterf]

@Selur, probably I'm too old for learning new things such as porting filters to VS, nor have I pressure such as impatient customers who'd like to see that feature ported :)
And despite my two younger sons are just finishing their IT studies at the technical university, I cannot pass my knowledge, because they know nothing about Avisynth and video filter programming and have other interests.

[ryrynz]

I nominate DTL and Tormento.

[StainlessS]

SubTitle and Text the string "\n" is valid only if it's not inside a "\\n" sequence (which would print the \n string itself).
Not sure if I was never aware or if forgot about the '\\n' escape of newline in Subtitle.

But on Wiki, it does say that it is so, as here,
int lsp =
Line Spacing Parameter; enables multi-line text (where "\n" enters a line break). If lsp is less than zero, inter-line spacing is decreased; if greater, the spacing is increased, relative to Windows' default spacing. By default, multi-line text disabled.
In the unlikely event that you want to output the characters "\n" literally in a multi-line text, you can do this by using "\\n".

And like the others, we hopes that U live forever [what a ghastly thought].

[pinterf]

Avisynth+ 3.7.3post test 8 (20231103 - r4021) (https://drive.google.com/uc?export=download&id=1ZGt6F7pLnMj6lo_n-gwjl4S6PtOYHD35)
20231103 3.7.3 post 8
---------------------
- New: "Info" new parameter
bool "cpu" (true)
If set to false, displaying CPU capabilities is disabled
- Enhancement: "Info" displays partially visible lines as well.
- Address #366 partially
"Info" new parameters, similar to SubTitle/Text:
int "align" (default 7: top left)
float "x" (default 4 for top left, screen center or right otherwise)
float "y" (default 0 for top left, screen center or bottom otherwise)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/info.html
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
See also https://forum.doom9.org/showthread.php?t=185145
Note 1: The "\n" after the last line does not result in an empty bottom line, so both "Line1" and "Line1\n" are one-line texts.
- Fix: "Text" use "lsp" parameter the same way as in SubTitle: in 1/8 pixel units, not in 1 pixels.
Historically "lsp" in SubTitle is measured in 1/8 pixels, so "lsp"=8 means 1 pixels.
"lsp" Line Spacing Parameter sets the additional line space between two lines in 1/8 pixel units.
- Fix: "Text" vertical alignment position would be wrong for multiline strings containing even number of lines.

[pinterf]

test8->test9: propShow user experience enhancement. Unreal Engine 5.3 nanite support... eeerrr not :) Simply you can change color and position of the text.
Avisynth+ 3.7.3post test 9 (20231105 - r4022) (https://drive.google.com/uc?export=download&id=1ZsU6x-ttYJxUugYAAw_4eTSe5bpc4F2L)
20231105 3.7.3 post 9
---------------------
- (#366):
"propShow" add further parameters, like in "Text".
string "font", int "text_color", int "halo_color", bool "bold", float "x", float "y", int "align"

full signature: c[size]i[showtype]b[font]s[text_color]i[halo_color]i[bold]b[x]f[y]f[align]i

font default: "Terminus" (can also be: "info_h")
bold default: false
x, y default: depending on the "align"
align default: 7 (top left) valid values 1-9 (see your numeric keyboard)
halo color MSB = FF (e.g. FF000000) -> no outline + semi transparent background
FE (e.g. FE000000) -> outline + semi transparent background
01 (e.g. 01000000) -> no outline + normal display
00 (e.g. 00000000) -> outline + normal display

propShow(align=1, halo_color=$FF000000)
propShow(size=6,bold=true, align=3, halo_color=$FE000000)
propShow(size=16,bold=true, align=5, halo_color=$00000000)
propShow(font="info_h", align=9, halo_color=$01000000)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/propShow.html
- New: "Info" new parameter
bool "cpu" (true)
If set to false, displaying CPU capabilities is disabled
- Enhancement: "Info" displays partially visible lines as well.
- (#366)
"Info" new parameters, similar to SubTitle/Text:
int "align" (default 7: top left)
float "x" (default 4 for top left, screen center or right otherwise)
float "y" (default 0 for top left, screen center or bottom otherwise)
See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/info.html
- Fix #368 (https://github.com/AviSynth/AviSynthPlus/issues/368)
Make proper vertical alignment for multiline text (containing "\n" and parameter "lsp" is defined)
in Subtitle and Text when vertical alignment is set to bottom (align=1,2,3) or center (4,5,6).
See also https://forum.doom9.org/showthread.php?t=185145
Note 1: The "\n" after the last line does not result in an empty bottom line, so both "Line1" and "Line1\n" are one-line texts.
- Fix: "Text" use "lsp" parameter the same way as in SubTitle: in 1/8 pixel units, not in 1 pixels.
Historically "lsp" in SubTitle is measured in 1/8 pixels, so "lsp"=8 means 1 pixels.
- Fix: "Text" vertical alignment position would be wrong for multiline strings containing even number of lines.
- Fix #365 (https://github.com/AviSynth/AviSynthPlus/issues/365)
Avisynth 2.5 plugins when NICE_FILTER would crash with "invalid response to CACHE_GETCHILD_AUDIO_MODE".
Bug appeared since reintroducing audio cache in 3.7.3.
- Fix #370: array size assert error in ConvertToYUY2 when internally ConvertTo422 is called.
Reason: ConvertToYUV422 has one more parameter (ChromaOutPlacement) than ConvertToYUY2 has
- Issues mentioned in #354 https://github.com/AviSynth/AviSynthPlus/issues/354
- Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601",
for example in ConvertToRGB32.
Formerly _ColorRange property would always set to 0 (full range), even if a limited range
clip (e.g. ColorBarsHD) was inputted. Now we act as the specification
( http://avisynth.nl/index.php/Convert ) says:
"PC.601 and PC.709 keep the range unchanged, instead of converting between 0-255 RGB
and 16-235 YUV, as is the normal practice."
Now ColorBarsHD().ConvertToRGB32(matrix="PC.601").propShow()
would display "_ColorRange=1 (limited)", since ColorbarsHD's output is limited as well.
- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx (latter fixed in test5).
When input or output would require it, rgb offset of 16 (or scaled equivalents) is used
for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)

[kedautinh12]

Avs+ r4029
https://gitlab.com/uvz/AviSynthPlus-Builds

[flossy_cake]

Hello, I am trying to workaround some undesired interpreter behaviour...

clip1 = myFunc(setting=1)
clip2 = myFunc(setting=2)
if (something==true){ clip2 }
else { clip1 }

It seems no matter which way the conditional evaluates, the interpreter always initialises myFunc() twice at lines 1 and 2. I can tell it's doing this because globals are getting initialised twice inside myFunc() and this is not allowing me to manage multiple calls to myFunc().

I can workaround it by going...

if (something==true){ myFunc(settting=2) }
else { myFunc(setting=1) }

But then I can't use variables to reference clips which is a bit of a downer.

Is there any way to tell Avisynth interpreter to only initialise function calls if they are going to be used at runtime? (during "get frame" or whatever it's called)?

:thanks:

[FranceBB]

Hi guys,
I know that there are lots of things going on for the upcoming version of Avisynth and this is probably gonna be one of the least important things so it can really be at the very bottom of the list, but I'm just gonna write it down here 'cause otherwise I fear we might forget: is anyone gonna add UTF-8 support to DirectShowSource()?

The reason why I'm asking is that this whole thing originated from this discussion here in the AVSPmod mod topic (post 1554) (https://forum.doom9.org/showthread.php?t=175823&page=78) in which we were trying to organize a list on which encoding schemes are supported by the various indexers and we just realized that DirectShowSource() is working with ANSI / Enhanced ANSI (like WinLatin) but it's lacking UTF-8 support.

I'm posting it here only 'cause DirectShowSource() is one of the plugins distributed by default as part of the main Avisynth+ installation so it's almost as if it's part of the core, let's say, and let's be honest, it's also 'cause I had no idea where else to ask xD

[pinterf]

Definitely, this is the right place. :). I have started to think there was nothing left to do.

[tormento]

definitely, this is the right place. :). I have started to think there was nothing left to do.


cuda….

[gispos]

cuda cuda cuda cuda... :D

[pinterf]

is anyone gonna add UTF-8 support to DirectShowSource()?
Here you are:
Avisynth+ 3.7.3post test 10 (20231202 - r4035) (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX)
It works the usual way, add utf8=true.

[Emulgator]

DG land would love to work with pinterf on this. Other stakeholders should participate as well.
The main effort would be to agree an architecture/API for minimizing CPU<->GPU transfers.
And then when that is in place to enhance internal and 3rd-party filters to support that.
DG demonstrated gains of 300%+ for typical scripts using his CUDASynth framework, but nobody seemed interested.
Maybe Vulkan is a better way to go to avoid nVidia fixation. We need to look into all this.
Yeees ! Thanks, Donald and Ferenc, for all the work !

[FranceBB]

Here you are:
Avisynth+ 3.7.3post test 10 (20231202 - r4035) (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX)
It works the usual way, add utf8=true.

Works like a charm.
Reliable as ever, Grandmaster Ferenc! :D

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

This year, under the Christmas tree, Santa Ferenc brought us presents:

https://i.imgur.com/6b5ZTfb.png

[pinterf]

Thank you for your kind and unusually visual feedback :)

[lewyturn]

After I upgraded to version 3.7.3, "GetChannel" does not work, there is only image but no sound. After I returned to version 3.7.2, the sound returned. Please tell me what I missed.

-----------------------------------------------------------------------------
SetWorkingDir("c:\AviSynth+\plugins64+")


v1 = FFmpegSource2("D:\video\v1.mp4",atrack=-2).TurnRight()
v2 = FFmpegSource2("D:\video\v2.mp4",atrack=-2).TurnRight()
a1=DirectShowSource("D:\video\v1.mp4")
a2=DirectShowSource("D:\video\v2.mp4")


b=BlankClip(length=5307,width=2160,height=1920,fps=29,channels=2,color=$000000)
xpos = 1080
ypos = 0
k=Overlay(b,v1)

video=Overlay(k,v2,x=xpos,y=ypos)

mono1=GetLeftChannel(a1, 1).AmplifydB(7)
mono2=GetChannel(a2, 2).AmplifydB(2)

audio=mergechannels(mono1,mono2)

AudioDub(video,audio)

[StainlessS]

Add Return a1.Info after line a1=DirectShowSource("D:\video\v1.mp4")
to check for audio.

EDIT: Is this correct ? [error for me]

mono1=GetLeftChannel(a1, 1).AmplifydB(7)
mono2=GetChannel(a2, 2).AmplifydB(2)


EDIT: GetLeftChannel() does not take a channel number.

After I returned to version 3.7.2, the sound returned.
Dont see how that is possible with that same error script.

[pinterf]

AviSynthPlus Builds r4035 with IntelLLVM and Clang build by Asd-g, fix this error (https://forum.doom9.org/showthread.php?p=1994621#post1994621) too
https://drive.google.com/file/d/1OcPJNK_qEuYPTsL6yXvy-FV3XATUx9Io/view?usp=drive_link
What error? You mean there was an error in your previous 3rd party unofficial Avisynth build?

[kedautinh12]

Yeah, fix error from IntelLLVM build

[pinterf]

And what's new in the build? Please write something, what it contains, because just dropping yet another link here is not enough.
Or just keep posting in your 'I'm the quickest one who found a new stuff on the internet' topic.

[kedautinh12]

Did you see "r4035" same with your test 10. Why i put more info when you were post changes in test 10?? I added more info "it contains IntelLLVM and Clang build"
https://forum.doom9.org/showthread.php?p=1994584#post1994584

Modern days, are people lazy for just click and read info?

[tebasuna51]

I have 3 r4035 now:

05/12/2023 02:54 7.252.480 AviSynthClang.dll
05/12/2023 02:54 9.033.216 AviSynthILLVM.dll
02/12/2023 19:48 4.958.720 AviSynthTest10.dll

What is the recommended one and for what?
The changelog is the same.

[kedautinh12]

Test what is faster build and choose, easy. For personal PC, speed is different for one by one build. That mean one build can't always faster than other build so i'm not recommended what build is better one
Example: your PC faster with clang build than otther build, you can choose clang. My PC faster with IntelLLVM, i choose IntelLLVM

[FranceBB]

What is the recommended one and for what?
The changelog is the same.

Strictly speaking, it might not be totally correct, but I go by the following line of reasoning:

- anything Ferenc posts is considered beta and will eventually become stable in Stephen's (qyot) final builds which is what I consider the official releases

- anything everyone else commits in other repositories might or might not be merged upstream and is considered experimental


TL;DR if there's a build, I always pick the Ferenc one.

[VoodooFX]

I think Asd-g doesn't add there unofficial commits, just that those unofficial builds are less tested and may contain weird bugs.

[StvG]

Yeah, fix error from IntelLLVM build

And what's new in the build? Please write something, what it contains, because just dropping yet another link here is not enough.
Or just keep posting in your 'I'm the quickest one who found a new stuff on the internet' topic.

Related - https://github.com/AviSynth/AviSynthPlus/commit/77ac885cfa64cdcec0469a87237a44d3472d8425

[tebasuna51]

My test, a QTGMC() over a interlaced DV:

AVSMeter64 02/12 AviSynthTest10 05/12 AviSynthClang 05/12 AviSynthILLVM
-------------------------- --------------------- --------------------- ---------------------
Frames processed: 40430 (0 - 40429) 40430 (0 - 40429) 40430 (0 - 40429)
FPS (min | max | average): 35.68 | 83.37 | 59.84 35.81 | 95.07 | 58.98 35.44 | 92.10 | 58.25
Process memory usage (max): 382 MiB 370 MiB 373 MiB
Thread count: 29 29 29
CPU usage (average): 28.6% 28.3% 28.3%

Time (elapsed): 00:11:15.583 00:11:25.530 00:11:34.072

Then the last ones are slow for me.

[kedautinh12]

Like i said
https://forum.doom9.org/showthread.php?p=1994786#post1994786

[gispos]

Did you see "r4035" same with your test 10. Why i put more info when you were post changes in test 10?? I added more info "it contains IntelLLVM and Clang build"
https://forum.doom9.org/showthread.php?p=1994584#post1994584

Modern days, are people lazy for just click and read info?
"Avisynth+ builds. This repo contains Clang and IntelLLVM builds of AviSynthPlus."

Now the penny drops.

Nowhere is it pointed out that they are the same versions as from pinterf and only the compilers are different.
I think that was not clear to most people, e.g. not to me, I always wondered why Avisynth builds are created here, and above all what other functions are included in them.

This should perhaps be made clearer on the website, so that I can understand it too. :)

[kedautinh12]

"r4035" is point this is same commits with test 10 cause pinterf was use that word in his release post
https://forum.doom9.org/showthread.php?p=1994584#post1994584

[kedautinh12]

AviSynthPlus Builds r4035 (same commmits with official build for people who lazy to read pinterf release (https://forum.doom9.org/showthread.php?p=1994584#post1994584)) with IntelLLVM and Clang build by Asd-g
https://gitlab.com/uvz/AviSynthPlus-Builds

[guest]

https://gitlab.com/uvz/AviSynthPlus-Builds

This appears to have had a refresh, yesterday !!!

[jpsdr]

Hello.
I followed the instructions for building DirectShowSource plugin provided by Asd-g in his IntelLLVM & Clang builds : downloading baseclasses, adjusting the CMakefile in the plugin directory. It was less complex than expected...
It worked with Visual Studio, but when i'm building baseclasses with LLVM (17.0.6) (LLVM integrated with VS 2019, not IntelLLVM), it fails with an error in wxdebug.cpp.
And trying to use the .lib build with Visual Studio during the LLVM build is not working.
So... How are you able to build baseclasses with clang/LLVM ?

[kedautinh12]

Ask him :D
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[jpsdr]

In case someone has an idea, the error i have :
1>wxdebug.cpp(1087,20): warning : ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings]
1>wxdebug.cpp(1093,16): warning : ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings]
1>wxdebug.cpp(1237,16): error : qualified reference to 'CDisp' is a constructor name rather than a type in this context
1>wxdebug.cpp(1237,21): warning : parentheses were disambiguated as redundant parentheses around declaration of variable named 'pp' [-Wvexing-parse]
1>wxdebug.cpp(1237,21): message : add a variable name to declare a 'CDisp::CDisp' initialized with 'pp'
1>wxdebug.cpp(1237,9): message : add enclosing parentheses to perform a function-style cast
1>wxdebug.cpp(1237,21): message : remove parentheses to silence this warning
1>wxdebug.cpp(1237,22): error : no matching constructor for initialization of 'CDisp::CDisp'
1>wxdebug.cpp(1130,8): message : candidate constructor not viable: requires single argument 'clsid', but no arguments were provided
1>./wxdebug.h(303,5): message : candidate constructor not viable: requires single argument 'd', but no arguments were provided
1>wxdebug.cpp(1143,8): message : candidate constructor not viable: requires single argument 'llTime', but no arguments were provided
1>wxdebug.cpp(1174,8): message : candidate constructor not viable: requires single argument 'pPin', but no arguments were provided
1>wxdebug.cpp(1203,8): message : candidate constructor not viable: requires single argument 'pUnk', but no arguments were provided
1>./wxdebug.h(298,7): message : candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided
1>wxdebug.cpp(1101,8): message : candidate constructor not viable: requires at least argument 'll', but no arguments were provided
1>wxdebug.cpp(1238,11): error : member reference type 'CDisp::CDisp' is not a pointer; did you mean to use '.'?
1>wxdebug.cpp(1238,13): error : no member named 'Release' in 'CDisp'
1>Génération du projet "BaseClasses.vcxproj" ends -- FAIL.


EDIT
Asd-g answered me.

[jpsdr]

Out of curiosity, where the DevIL.dll is comming from ?
When i want to build avisynth and i create the project with CMake, the .dll is already here in the Output before i even start any build...:confused:

[pinterf]

I think it is from here: https://openil.sourceforge.net/
But it's put in the project tree:
https://github.com/AviSynth/AviSynthPlus/tree/master/plugins/ImageSeq/lib/

Edit 2:
They are of version 1.7.8
But there exists version 1.8.0
https://openil.sourceforge.net/download.php
Probably those DLLs in ImageSeq/lib (x86/x64) must be replaced, after checking if they are compatible. (unicode or not, dependencies, etc.)

[kedautinh12]

Maybe can add more commits from offical project??
https://github.com/DentonW/DevIL/commits/master/

[flossy_cake]

Has anyone noticed memory leaks when seeking? Especially if CPU is loaded with a heavy filter like QTGMC and I seek back or forward 10 seconds, memory usage can spike up by as much as 1000MB per seek. Seeking by 1 frame in either direction seems to be even worse. After too much seeking I eventually reach the SetMemoryMax value (4GB on my system) after which filters may become slow, eg. QTGMC will become slower once the max memory usage has been reached. I was able to reproduce this with other filters too, and I tried changing source filters to no effect.

Anyone experienced anything like that?

[kedautinh12]

no, i use QTGMC(Preset="Very Slow", Sharpness=0).SelectEven() with prefetch(4) and don't pike up by as much as 1000MB per seek. My memory increased by 1000mb and after the preview and it doesn't pike up anymore

[flossy_cake]

no, i use QTGMC(Preset="Very Slow", Sharpness=0).SelectEven() with prefetch(4) and don't pike up by as much as 1000MB per seek. My memory increased by 1000mb and after the preview and it doesn't pike up anymore

Can you try doing some 1-frame step backwards in a row at a reasonably fast tempo, like a frame step every 200ms (edit: or just try rapidly clicking around in the seek bar close to current position). Especially backwards seems to trigger it, I think because it has to go back and kind of preroll up to the current frame or something. I don't know what video player you are using but in MPC-HC there is a hotkey for "frame-step back".

Prefetch doesn't affect it for me. But it depends how fast I press it. There is a random element to it. Sometimes I seek +/- 10 seconds multiple times and it doesn't spike the memory usage at all. Other times a single skip ahead 10 seconds will shoot it up 1000MB. It seems to be a function of what the current frame is in the clip. If I do Preroll() that seems to make it worse too.

https://c.l3n.co/i/3dJsNM.png

Above is just with
LWLibavVideoSource(clip, repeat=true)
QTGMC(preset="slow")
With this (https://drive.google.com/file/d/1KdE0np8016zr7ovRassdbH7OtbKU7e-a/view?usp=sharing) clip.

edit: I'm using LAV DirectShow filter to open .avs files in MPC-HC, but I tried with default "AVI/WAV file source" (I think it's Microsoft filter) and that leaks too (and has other issues).

[kedautinh12]

I'm using preview of megui and don't have that error

[flossy_cake]

I'm using preview of megui and don't have that error

Ok thanks, I tried AvsPMod just now and same issue after frame stepping backwards with left arrow, or just clicking around in the seek bar multiple times:

https://c.l3n.co/i/3q9K8M.png

I've got two theories:

1. It's somehow CPU load related, as it only happens when CPU is loaded. I can also reproduce it by doing multiple Spline36Resize from 480p->4k->480p to load up the CPU. So it's not QTGMC related. If you have a powerful CPU then maybe you don't experience it because CPU is not loaded up enough.

2. It's something specific to my version of Avisynth.dll (3.7.3 r3936 x64)

[kedautinh12]

Try latest avs+ ver (4035)
https://gitlab.com/uvz/AviSynthPlus-Builds

[flossy_cake]

Try latest ver avs+ (4035)
https://gitlab.com/uvz/AviSynthPlus-Builds

Updated to 4035, same issue.

How much CPU load do you have with QTGMC(preset="slow").Prefetch(4)?

For a 480i clip I have 85% initially then drops to 55% after about 10 seconds once prefetch buffer is full. 4 cores @ 3.2ghz (i5-4570).

[kedautinh12]

I used your video with your script, Memory from 78 to 84 and keep it here even I load frame by frame manual or auto play
https://i.imgur.com/MWucxSl.png

[flossy_cake]

I used your video with your script, Memory from 78 to 84 and keep it here even I load frame by frame manual or auto play

Ok thank you. Must be an issue with Windows 7 memory management.

[pinterf]

Has anyone noticed memory leaks when seeking? Especially if CPU is loaded with a heavy filter like QTGMC and I seek back or forward 10 seconds, memory usage can spike up by as much as 1000MB per seek. Seeking by 1 frame in either direction seems to be even worse. After too much seeking I eventually reach the SetMemoryMax value (4GB on my system) after which filters may become slow, eg. QTGMC will become slower once the max memory usage has been reached. I was able to reproduce this with other filters too, and I tried changing source filters to no effect.

Anyone experienced anything like that?
It's not very likely that you are seeing this because of Win7 memory management.
I have to try to reproduce using the very same environment.
- I'd need the simplest script (no QTGMC, just the resizer; btw. does it happen with a simple ColorBarsHD as the source filter?)
- seeking from MPC-HC only?, or does it happen with AvsPMod as well?
- Which version of LWLibavVideoSource?

[flossy_cake]

I have to try to reproduce using the very same environment.
- I'd need the simplest script (no QTGMC, just the resizer; btw.
does it happen with a simple ColorBarsHD as the source filter?)
- seeking from MPC-HC only?, or does it happen with AvsPMod as well?

In AvsPMod and MPC-HC I am able to reproduce it with:


ColorBarsHD().KillAudio()
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Prefetch(4)


In AvsPmod:

1. Press play and let the video play for a bit
2. Press pause
3. Framestep backwards by rapidly tapping or holding the left arrow key in AvsPMod

https://c.l3n.co/i/3qGOIA.png

[pinterf]

In AvsPMod and MPC-HC I am able to reproduce it with:

Thanks, that info must be enough for me for the holiday week :)

[qyot27]

I think it is from here: https://openil.sourceforge.net/
But it's put in the project tree:
https://github.com/AviSynth/AviSynthPlus/tree/master/plugins/ImageSeq/lib/

Edit 2:
They are of version 1.7.8
But there exists version 1.8.0
https://openil.sourceforge.net/download.php
Probably those DLLs in ImageSeq/lib (x86/x64) must be replaced, after checking if they are compatible. (unicode or not, dependencies, etc.)

A user can drop in 1.8.0 as a replacement for 1.7.8 and it'll still work.

My position has been that we need to remove the DevIL binaries and embedded copy of SoundTouch that we currently use, in favor of just using the one found on the system. It was something that I'd planned on doing back in 2020 just after we'd gotten the Linux port working, but I'd encountered issues in trying to detect things and walked away from it for a while.

In fact, anyone that's used the upstream release of AviSynth+ for macOS has been using latest DevIL in the ImageSeq plugin the whole time. All the non-Windows OSes can use the version from their distro's/OS' repositories, which is typically 1.8.0 by now.

I finally did figure out the proper way to handle both DevIL on Windows as well as grabbing the system copy of SoundTouch by using pkg-config, and confirmed that it does work when building on Windows (even if Windows is supremely weird with all the CMake/pkg-config system detection stuff).

To illustrate this,
Proof of concept. (https://www.mediafire.com/file/i08vu91xvj4715l/static_plugs.7z/file)

Both ImageSeq and TimeStretch are using the current git HEAD of DevIL and SoundTouch rather than the old versions from the source tree.

[pinterf]

In AvsPMod and MPC-HC I am able to reproduce it with:


ColorBarsHD().KillAudio()
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Spline36Resize(3840, 2160)
Spline36Resize(1920, 1080)
Prefetch(4)




As a workaround try setting 1 to default cache mode.

#SetCacheMode(0) # Run until frame 40, then step back 10 times in avspmod, 11th and on back step increases 200MB cache space
SetCacheMode(1) #no problem
.. script follows


An issue was created at github: https://github.com/AviSynth/AviSynthPlus/issues/379

(The video cache size prediction algorithm probably went mad after this manually governed frame order pattern - 1,2,3,4,...25 then back 24-23-22-21, etc.)

[flossy_cake]

As a workaround try setting 1 to default cache mode.


Can confirm that works for me for the colorbars demo in AvsPMod, but breaks a lot of other things in my scripts - freezing on certain seek patterns, performance randomly goes bad after seeking, and my scriptclips become desynchronised where current_frame != previous_frame + 1 (it's never guaranteed with cache mode 0 either, but tends towards synchronicity over time whereas with cache mode 1 it can randomly get suck in desync).

I'm quite happy to just continue using cache mode 0 and limit my seeking behaviour to avoid the issue.

I'm now worried you are going to try to fix cache mode 0 and break all my scripts permanently so I'm kinda regretting mentioning this now :scared:

[pinterf]

This issue will be fixed surely. This part is black magic, such problems usually require 30-40 net working hours to understand, experiment, fix, test.

[flossy_cake]

This issue will be fixed surely. This part is black magic, such problems usually require 30-40 net working hours to understand, experiment, fix, test.

Ok well thank you for putting in the time. Hopefully it doesn't break my Preroll()'d ScriptClips too much :thanks:

[flossy_cake]

This issue will be fixed surely. This part is black magic, such problems usually require 30-40 net working hours to understand, experiment, fix, test.

For backwards compatibility would it be possible to let the user still have access to the current caching behaviour? Something like SetCacheMode(CACHE_FAST_START_OLD) to force legacy behaviour.

[gispos]

I'm now worried you are going to try to fix cache mode 0 and break all my scripts permanently so I'm kinda regretting mentioning this now :scared:
I also hope that the shot doesn't backfire.
Almost none of my scripts run in cache mode 1 and take ages to load. Then it's better to eat up the memory and be fast :)

[FranceBB]

Yep, RAM is there to be allocated. If it needs to be allocated, so be it. :P
My laptop has 64GB while my servers have 128GB, both DDR4 'cause they're from 2016 and 2019 respectively, so it's not really a big deal if a script consumes 3.5 GB of RAM.
Heck, I regularly have UHD encodes using over 12 GB of RAM and I'm totally fine with it.
Even my Windows XP machine with PAE supports 64 GB of RAM (with the only caveat that each process tops up at 2GB, so on some encodes I might have to use MPPipeline to split on each filter so that each one of them has 2GB allocable memory up to 64GB instead of it being 2GB max for the whole thing). :)

[flossy_cake]

That's what I thought too but then I noticed QTGMC becomes slow once memory use hits the SetMemoryMax value. This is only an issue for real-time use as CPU would be pegged at 100 the whole time when transcoding anyway.

I can workaround it by giving QTGMC an extra thread or two, but then it's a bit tricky to find the sweet spot where it's not overutilizing CPU during the period before the memory hits max. Basically I need to keep around 20% CPU overhead for the media player, the remaining 80% can go to QTGMC during realtime playback.

[Boulder]

Is there a measurable performance difference between the two cache modes?

[flossy_cake]

Is there a measurable performance difference between the two cache modes?

As long as you don't seek or use a ScriptClip that rapidly picks frames from different clips the average fps seems to be about the same - measure with ffmpeg.exe:

"c:\program files\ffmpeg\bin\ffmpeg.exe" -i "C:\YourScript.avs" -f null NUL

[DTL]

Is there a measurable performance difference between the two cache modes?

It may greatly depends on lots of ways: OS used, memory subsystem (CPU caches and RAM), scripts and plugins used and settings for each filter, frame size and pixel type for each filter input and output and so on.

But it looks user can not control cache mode for each filter to finetune performance if possible (in the same way as frame-based MT) ?

[ErazorTT]

Could anybody on any 2.7.3 check this simple code, and confirm that blue and green are switched?


clip=BlankClip(color=$0000ff,pixel_type="RGBP8")
StackHorizontal(clip,clip.ShowRed(),clip.ShowGreen(),clip.ShowBlue())


In contrast to what my expection I'm seeing this:
https://i.postimg.cc/2VHf89TZ/show-Channel-status-quo.jpg (https://postimg.cc/2VHf89TZ)

My expection was of course:
https://i.postimg.cc/pmpM9Q11/show-Channel-expectation.jpg (https://postimg.cc/pmpM9Q11)

[flossy_cake]

Could anybody on any 2.7.3 check this simple code, and confirm that blue and green are switched?


clip=BlankClip(color=$0000ff,pixel_type="RGBP8")
StackHorizontal(clip,clip.ShowRed(),clip.ShowGreen(),clip.ShowBlue())


In contrast to what my expection I'm seeing this:
https://i.postimg.cc/2VHf89TZ/show-Channel-status-quo.jpg (https://postimg.cc/2VHf89TZ)

My expection was of course:
https://i.postimg.cc/pmpM9Q11/show-Channel-expectation.jpg (https://postimg.cc/pmpM9Q11)

The issue is RGBP8, since pixel_type=RGB/undefined() works as expected.

The wiki (http://avisynth.nl/index.php/ShowAlpha) says "Returns the selected channel of an RGB32 or RGB24 clip as greyscale." I guess that doesn't include RGBP8 so the function should probably throw an exception if the clip isn't RGB32/24.

[ErazorTT]

should probably throw an exception if the clip isn't RGB32/24.

I don’t think so, since currently ShowGreen returns the Blue channel and ShowBlue returns the Green channel. So a working fix should be very easy.

[flossy_cake]

I don’t think so, since currently ShowGreen returns the Blue channel and ShowBlue returns the Green channel. So a working fix should be very easy.

I could be totally wrong but my guess is the planar data is getting interpreted as interleaved, because the function doesn't check to confirm pixel format is interleaved. In the meantime you could just convert your clip to interleaved and avoid the issue.

[pinterf]

Could anybody on any 2.7.3 check this simple code, and confirm that blue and green are switched?


clip=BlankClip(color=$0000ff,pixel_type="RGBP8")
StackHorizontal(clip,clip.ShowRed(),clip.ShowGreen(),clip.ShowBlue())


In contrast to what my expection I'm seeing this:
https://i.postimg.cc/2VHf89TZ/show-Channel-status-quo.jpg (https://postimg.cc/2VHf89TZ)

My expection was of course:
https://i.postimg.cc/pmpM9Q11/show-Channel-expectation.jpg (https://postimg.cc/pmpM9Q11)
Thanks for the report, it must be a bug. It's more than I can bear :) so expect a fix soon.
EDIT: fixed on git + updated documentation (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/showalpha.html)

[flossy_cake]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

[kedautinh12]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

pinterf was released beta ver at this thread, and the repo belongs to Asd-g

[tebasuna51]

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?

"Avisynth.dll and DevIL.dll in Windows/System32" OK for dll's 64 bits

"the rest in /plugins64+ folder" or in other folder defined in the register, check the register commands. I use C:\Portable\Avs\AVSPLUS370_x64\plugins

[pinterf]

Hey I was wondering where is the best place to get the latest Avisynth builds from?

I saw it referenced on official GitHub here (https://github.com/AviSynth/AviSynthPlus/actions/runs/7531059881/job/20498782095) but no download links.

I saw this (https://gitlab.com/uvz/AviSynthPlus-Builds) repo which has download links but I don't know who's making the builds.
edit: oh I just saw pinterf is putting them on gdrive in post#1 :thanks:

edit: looking at avisynth_updater.bat (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/main/avisynth_updater.bat?ref_type=heads) it seems I just need to put Avisynth.dll and DevIL.dll in Windows/System32, and the rest in /plugins64+ folder, have I got that right?
I meant I've fixed on the git repo, in the source code. I didn't have time to assemble a test build (binary). This time the above mentioned asd-g builds can help you probably.

[hello_hello]

I seem to have stumbled upon a ConvertToYUY2 oddity.
Avisynth+ 64 bit, r4035 (Clang, I think).

ColorBars().KillAudio()
ConvertToYUY2()

https://i.ibb.co/g6sY29Q/YUY2.png

This is okay.

ColorBars().KillAudio()
ConvertToYV16()
ConvertToYUY2()

https://i.ibb.co/7tHVy17/YV16-to-YUY2.png

[pinterf]

I seem to have stumbled upon a ConvertToYUY2 oddity.
Avisynth+ 64 bit, r4035 (Clang, I think).

ColorBars().KillAudio()
ConvertToYUY2()

This is okay:

ColorBars().KillAudio()
ConvertToYV16()
ConvertToYUY2()


Thanks for the report. Afaik there is direct rgb -> yuy2 conversion. The conversion code or the usage of color conversion matrix must be wrong there.

EDIT: there was a bug in Studio Range RGB (_ColorRange = 1) to YUY2 conversion. (ColorBars outputs studio range sample)
Regression since Avisynth+ 3.7.3post test 4 (20231019 - r4013)
(this one:
- Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in
conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx.
When input or output would require it, rgb offset of 16 (or scaled equivalents) is used
for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)
)

[flossy_cake]

There's also an issue with Text() colour in YV12 in pinterf's gdrive build 4035 (https://drive.google.com/uc?export=download&id=1yuiF6rnphnfpBoZGFTsT9vKPGiZxbGCX):


ColorBars().ConvertToYV12().Trim(0, 300)
Text("Red text", font="Terminus", bold=true, size=20, text_color=$FF0000, align=5, lsp=0)
Text("\n\nGreen text", font="Terminus", bold=true, size=20, text_color=$00FF00, align=5, lsp=0)
Text("\n\n\n\nBlue text", font="Terminus", bold=true, size=20, text_color=$0000FF, align=5, lsp=0)


https://b.l3n.co/i/4OCack.png

But curiously not in this gitlab 4035 build (https://gitlab.com/uvz/AviSynthPlus-Builds/-/blob/cadadcabe1eb31eedb1d6bee122aaf4df31f83c2/Clang/x64/AviSynth.dll):

https://c.l3n.co/i/4OJgEm.png

edit: I'm guessing it's probably the same issue hello_hello is referring to, but just in case it isn't, I'll leave this post

[pinterf]

Bug flood :)

Till then
- Planar RGB ShowBlue/Green fix
- Studio RGB to YUY2 fix (of test4)

Avisynth+ 3.7.3post test 11 (20240118 - r4059) (https://drive.google.com/uc?export=download&id=199YthQlcKrvBkBU-btd0k40Yyzvbo24K)

[pinterf]

@flossy_cake
Interesting.
The xp version (v141_xp platform) works fine. But the normal version is showing the colorful artifacts.

The same applies on the latest test11 builds.

??

[flossy_cake]

@flossy_cake
Interesting.
The xp version (v141_xp platform) works fine. But the normal version is showing the colorful artifacts.
??

What is the xp version? Windows XP?

In your gdrive builds Text() was ok in test 9 (r4022) and went bad in test 10 (r4035).

But that still doesn't explain why all the builds on gitlab are unaffected, so I'm guessing it's some kind of build issue?

[pinterf]

What is the xp version? Windows XP?

In your gdrive builds Text() was ok in test 9 (r4022) and went bad in test 10 (r4035).

But that still doesn't explain why all the builds on gitlab are unaffected, so I'm guessing it's some kind of build issue?

What makes me even more happy that the bug does not appear in debug builds. Only in release. I'm just looking at the compiled assembler code (but it's very hard to follow an optimized assembly list, as it may only loosely follow the actual program code source lines); nevertheless, I'm almost sure that it is a compiler bug; when the text bitmap is longer than 64 pixel (8 bytes) then it fails (the compiler creates more code paths, one for non-optimizable cases - this works, but for the optimized parts it switches to SIMD instructions, and I think this is where MSVC compiler produces bad code). Now I have already found the area (~100 lines of original Avisynth code) where it would generate false code.

[FranceBB]

What is the xp version? Windows XP?


Yes, the XP builds are built with MSVC set to v141_xp, /Zc:threadSafeInit and SSE2 only assembly optimizations.
They're compatible with Windows XP x86, Windows XP x64 and upwards, so they can be used in all Windows after that (Vista, 7, 8, 8.1, 10, 11) but they're gonna be slightly slower.


All the other builds (from Ferenc and Stephen, that is) are built with MSVC set to v143 and they're compatible with Windows 10 x86, Windows 10 x64 and upwards.


When you extract the package from Ferenc and Stephen, you'll always find the following folders:

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

The "xp" ones are the Windows XP and upwards ones ;)



For those wondering, Windows98SE x86 support was deprecated in 2016 after the last Avisynth 2.6.1 build, before Avisynth became Avisynth+.



ColorBars().ConvertToYV12().Trim(0, 300)
Text("Red text", font="Terminus", bold=true, size=20, text_color=$FF0000, align=5, lsp=0)
Text("\n\nGreen text", font="Terminus", bold=true, size=20, text_color=$00FF00, align=5, lsp=0)
Text("\n\n\n\nBlue text", font="Terminus", bold=true, size=20, text_color=$0000FF, align=5, lsp=0)


Avisynth 3.7.3 r4059

Windows XP:

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

Windows 10:

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



I'm just looking at the compiled assembler code

That's because you're a legend.
For me it would be like reading geoglyphs: I would be fascinated by the look of it while still not being able to understand anything it says.

What makes me even more happy that the bug does not appear in debug builds. Only in release.


Wow! So it is a compiler bug after all. O_O
I never thought I would have seen something like this in my life.
Debug is plain C/C++ so it's fine, while the XP one is up to SSE2, so I guess forcing v143 to not produce anything more than SSE2 code should "fix" the issue?

[pinterf]

It is clearly a compiler bug, I reported the issue.

https://developercommunity.visualstudio.com/t/Bad-c-codegen-in-1784-x64-unless-se/10565370?
I don't know though, where is the project source that I sent them as an attachment...

Not only finding the right place of the bug, but creating a minimal reproducible example to demonstrate the compiler error to Microsoft is very time-consuming.

I have a temporary solution for now, but I will wait for a few more days.

[qyot27]

It would have to be a very recent update, as well. I can't reproduce it here. So it could be limited to either something in VS 2022 (which I wouldn't hit because I'm still using VS 2019, and the last time I ran an update on the toolchain may have been back in July, right before building 3.7.3), or more specifically in one of the Windows toolkit update targets between the two test builds where this first arose.

https://www.mediafire.com/file/j8q93ufi7qwymqe/avisynth_build_20240119.7z/file

There seems to be a trend of weird compiler/OS bugs cropping up lately. The most recent FFMS2 C-plugin build hits memory access problems in Windows when trying to load the NovosobornayaSquare VVC sample but the exact same FFmpeg/FFMS2 commits work fine on Ubuntu.

[tormento]

Try intel compiler, it’s free in its community version.

[pinterf]

It is clearly a compiler bug, I reported the issue.

https://developercommunity.visualstudio.com/t/Bad-c-codegen-in-1784-x64-unless-se/10565370?

That was unexpectedly quick.
"Thanks for your feedback. We can reproduce the issue in VS 2022 17.8.4. And we've checked this issue has been fixed in VS2022 17.9.0 preview 3.0. ..."

[gispos]

That was unexpectedly quick.
"Thanks for your feedback. We can reproduce the issue in VS 2022 17.8.4. And we've checked this issue has been fixed in VS2022 17.9.0 preview 3.0. ..."
Sometimes life is good to you. :)

[pinterf]

RedTextBlueTextGreenTextRelease.
And a (hopefully) fixed issue found by Asd-g.
Avisynth+ 3.7.3post test 12 (20240124 - r4062) (https://drive.google.com/uc?export=download&id=1CKYoQSCHDDbMFH14j8rYNT2TI5S3aCbJ)
20240124 3.7.3 post 12
----------------------
- (temporary fix for VS2022 17.8.4 compiler bug)
- Fix #386: Interleave to call plugin destructor like StackXXXX
(20240118 3.7.3 post 11)

[FranceBB]

It works, now the v143 builds output matches the v141_xp one. :)
Thank you Ferenc, as always.

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

[VoodooFX]

Found some random bug:

https://thumbs2.imgbox.com/5f/ae/m5CMRF7K_t.png (https://images2.imgbox.com/5f/ae/m5CMRF7K_o.png)


It's generated in this "else if" block: https://github.com/Purfview/InpaintDelogo/blob/13e27f3deb83ef4415543351d362111015959e82/InpaintDelogo.avsi#L2898
There are 4 crops stacked and second from the top can be in various random colors or normal without any glitches. [with the same script]

I encountered it in 3.7.2 and 3.7.3


UPDATE:

I think I found a way how to always reproduce the bug.
Bug is when "analyze = 2" [clip there goes as yv12].
If first I use "analyze = -2" [clip there goes as rgb24] and then if I change to "analyze = 2" then it bugs out, I've no idea what happens. Some memory leak?

[pinterf]

Found some random bug:

https://thumbs2.imgbox.com/5f/ae/m5CMRF7K_t.png (https://images2.imgbox.com/5f/ae/m5CMRF7K_o.png)


It's generated in this "else if" block: https://github.com/Purfview/InpaintDelogo/blob/13e27f3deb83ef4415543351d362111015959e82/InpaintDelogo.avsi#L2898
There are 4 crops stacked and second from the top can be in various random colors or normal without any glitches. [with the same script]

I encountered it in 3.7.2 and 3.7.3


UPDATE:

I think I found a way how to always reproduce the bug.
Bug is when "analyze = 2" [clip there goes as yv12].
If first I use "analyze = -2" [clip there goes as rgb24] and then if I change to "analyze = 2" then it bugs out, I've no idea what happens. Some memory leak?
Hi,

I'd need your calling script and probably the video, the minimum you can see the garbage. All I see is that there are function(s) with a thousand parameters in that avsi. (It wanted me to Install GrunT, O.K., I copied the dll. Then now it requires a mask string definition. Given the fact I don't use it for myself, I need help.

[VoodooFX]

Hi,

I'd need your calling script and probably the video, the minimum you can see the garbage. All I see is that there are function(s) with a thousand parameters in that avsi. (It wanted me to Install GrunT, O.K., I copied the dll. Then now it requires a mask string definition. Given the fact I don't use it for myself, I need help.

Here you go: https://we.tl/t-BD8RzJnv38

Run it as is, then run it with "Analyze=2" and you should see error from the script that it didn't found suitable frames (if it bugs out).
[then if it bugs out you can remove padding in extension from the "txt" file and use "Show=7" so you can see video with the bugged frames]

EDIT:

I think these should be enough to run it:
AvsInpaint v1.3 or later ( https://github.com/pinterf/AvsInpaint ).
MaskTools2 ( https://github.com/pinterf/masktools ).
RgTools ( https://github.com/pinterf/RgTools ).
GRunT ( https://github.com/pinterf/GRunT ).
RT_Stats ( http://avisynth.nl/index.php/RT_Stats ).
FrameSel ( http://avisynth.nl/index.php/FrameSel ).
LSMASH ( http://avisynth.nl/index.php/LSMASHSource ).

EDIT2:
On Windows 7 x64, but I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

EDIT3:
Just reproduced it with your shared "b12" test files.
Btw, rar'ed txt file is wrongly named, should be named as "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" if you'll want to see bugged video.

[gispos]

Question for the Avisynth developers or those who can answer it.

When I get audio samples with 'get_audio', the time required depends on the video filters used. Which makes me wonder!
I assumed that this is not the case, is this another C Interface bug or is there no other way?

Because it is almost impossible to create an audio buffer of several frames without major delays in the image playback.

Is there another way to get the audio samples without processing all the video filters?

Would it make sense to derive an extra audio clip with 'KillVideo' from the clip or would this audio clip then claim its parent when getting an audio sample from another frame?

#######################

Each line represents 10 video frames from which the audio samples were read in a loop with get_audio from each video frame
So before reading and timing 'get_frame' was called and then only 'get_audio' was executed.
Time in seconds:

with video filters and with prefetch(4) (get audio fluctuates strongly, 0.5 is too much)
0.598999977112 !!!
0.00300002098083
0.00200009346008
0.00200009346008
0.588999986649 !!!
0.00200009346008
0.0019998550415
0.00200009346008
0.588999986649 !!!
0.00300002098083
0.00200009346008
0.000999927520752
0.609999895096 !!!
0.000999927520752
0.0019998550415
0.000999927520752
0.600000143051 !!!

with video filters without prefetch (get audio is mostly slow)
0.204999923706
0.203000068665
0.207000017166
0.000999927520752
0.210000038147
0.209000110626
0.0019998550415
0.209999799728
0.210000038147
0.232999801636
0.000999927520752
0.209000110626
0.204999923706
0.206000089645
0.211999893188
0.209000110626

without video filters and without prefetch (get audio is very fast)
I would have expected that even with video filtering
0.000999927520752
0.000999927520752
0.000999927520752
0.00100016593933
0.0
0.000999927520752
0.000999927520752
0.000999927520752
0.0
0.0019998550415
0.000999927520752
0.00100016593933
0.0
0.000999927520752
0.000999927520752
0.000999927520752
0.0

without video filters but with prefetch(4) (get audio is fast)
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.00100016593933
0.00100016593933
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752
0.000999927520752

[Emulgator]

Would it make sense to derive an extra audio clip with 'KillVideo' from the clip or would this audio clip then claim its parent when getting an audio sample from another frame?
Remembering script snippets from the past I am feeling that being the solution, but lets see what more experienced coders have to say.

[pinterf]

Here you go: https://we.tl/t-BD8RzJnv38

Run it as is, then run it with "Analyze=2" and you should see error from the script that it didn't found suitable frames (if it bugs out).
[then if it bugs out you can remove padding in extension from the "txt" file and use "Show=7" so you can see video with the bugged frames]

EDIT:

I think these should be enough to run it:
AvsInpaint v1.3 or later ( https://github.com/pinterf/AvsInpaint ).
MaskTools2 ( https://github.com/pinterf/masktools ).
RgTools ( https://github.com/pinterf/RgTools ).
GRunT ( https://github.com/pinterf/GRunT ).
RT_Stats ( http://avisynth.nl/index.php/RT_Stats ).
FrameSel ( http://avisynth.nl/index.php/FrameSel ).
LSMASH ( http://avisynth.nl/index.php/LSMASHSource ).

EDIT2:
On Windows 7 x64, but I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

EDIT3:
Just reproduced it with your shared "b12" test files.
Btw, rar'ed txt file is wrongly named, should be named as "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" if you'll want to see bugged video.

Hi, thanks, downloaded, run and now I don't know what to see.

You wrote that I should rename the text file xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-255.txt_to_disable_this_file to xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt.
But the script would generate files with "A-2" in their name (instead of "A2"). As I didn't see any changes (or dont' know what to look for), I'd rather stop experimenting with renaming, I don't see the logic behind them. Anyway I tried both.

The first mp4 file is different as well, than it is required in the script. I renamed it.

I can see however colorful blocks in the top third of xxx2.bmp_InpaintDelogo3_296-136-296-136_A-2-30_Deep1.ebmp
Is this the bug?

What does it mean "you should see error from the script that it didn't found suitable frames"? I have to watch the frames or there will be an error message or some generated files will contain the error message?

[pinterf]

Question for the Avisynth developers or those who can answer it.

When I get audio samples with 'get_audio', the time required depends on the video filters used. Which makes me wonder!
I assumed that this is not the case, is this another C Interface bug or is there no other way?


I have some tips (without knowing the reason).

Does it happen if source video is ColorBars?

If not, then I'd suspect the "real" source filter, which would seek and decode the video and audio in a way which is not 100% independent.

During video processing and Prefetch, out-of-order frame requests must be served by the source. I've seen already that a 1-2-3-4-5...98-100-99-... frame reqest pattern would kill the speed of the source filter, because the 100->99 change would cause re-read and re-decode the whole 0-100 frame range.

The audio requests are pass-through operations when video filters do nothing with them.

Then I'd test the slowdown and speed fluctuations with a test script, which is using different audio and video sources, and finish the script with "AudioDub".

[tormento]

During video processing and Prefetch, out-of-order frame requests must be served by the source. I've seen already that a 1-2-3-4-5...98-100-99-... frame reqest pattern would kill the speed of the source filter, because the 100->99 change would cause re-read and re-decode the whole 0-100 frame range.
Idea from a programming noob: why not to let the user have 2 independent buffers (with customizable frame numbers, not necessarily the same number for both), one for the forward requests and the other one for the backward ones?

How does motion vector filters deals with frame calls? Perhaps a dual buffer strategy would give some nice numbers and solve other issues.

It’s a long time that I am thinking about the bad results when denoising the frames close to the end of scene change. In my mind a reverse order denoising would function and having a dual buffer could help.

[VoodooFX]

The first mp4 file is different as well, than it is required in the script. I renamed it.

Oh, I shared the wrong video, here are the right test files -> https://we.tl/t-B8xrryRIfT

I don't know what to see.
To see the error from an assert in the script [in the red letters], if there is no error then there is no bug,
To be sure, check generated "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt" file, if it says "# Total frames to analyze: 2000" then definitely no bug.

You wrote that I should rename the text
That's only after the bug is encountered, it's not important, forget that...

But the script would generate files with "A-2" in their name (instead of "A2")

ebmp & txt files with "A-2" are created only with "Analyze=-2".
There is no bug with "Analyze=-2", we run it to trigger the bug in a next run with "Analyze=2".
Note: Generated files with "Analyze=-2" are not relevant for "Analyze=2" run.

To trigger the bug:
1) Run with "Analyze=-2"
2) After "1" finished, run "Analyze=2" - here we should see error from Assert if bug is present.


Rinse And Repeat:
a) Close AvsPmod.
b) Delete all ebmp & txt files.
c) Do "1" & "2" steps again.

[VoodooFX]

Other people could test it too, so we can pin point the bug faster.

My test environment: On Windows 7 x64, Avisynth+ 3.7.3 (3.7.2 tested too), I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5

[pinterf]

Other people could test it too, so we can pin point the bug faster.

My test environment: On Windows 7 x64, Avisynth+ 3.7.3 (3.7.2 tested too), I run AvS x86 with x86 plugins in AvsPmod v2.7.4.5
I now have the red Assert saying to change the threshold.
And I have only one txt file after the first pass (-2):
xxx2.bmp_InpaintDelogo3_296-136-296-136_A-2-30_Deep1.txt
with content
# Total frames to analyze: 2000
0,-2000

The 2nd pass would generate the other txt, which would be this one: xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt

But I don't have such file because of the assert?

How did you visualize the stacked clip? (where there is the stange clip - the second one from the top?)

[VoodooFX]

I now have the red Assert saying to change the threshold.

That means you successfully reproduced the bug.


The 2nd pass would generate the other txt, which would be this one: xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt
But I don't have such file because of the assert?

Yes.

How did you visualize the stacked clip? (where there is the stange clip - the second one from the top?)

When you got the assert:
1) Just rename txt file from "Analyze=-2" to "xxx2.bmp_InpaintDelogo3_296-136-296-136_A2-30.txt".
2) In the script change to "Show=7"
3) Press or trigger refresh in AvsPmod. -> You should see the bugged clip.

NOTE:
If no bug then in txt file should be written frames numbers/ranges with minmax lower than 15 in chroma & lower than 30 in Y. Because of the bug there are no frames written there.

[pinterf]

That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.

Avisynth+ 3.7.3post test 14 (20240131 - r4066) (https://drive.google.com/uc?export=download&id=1nrdoQgzzYJh7RwkkrPZwW9OGpmI53A9-)
20240131 3.7.3 r4066
---------------------
- Fix corrupt Turn functions when a planar RGB turn would be followed by a YUV Turn.
Regression since TurnXXXX supports planar RGB (2016.08.23; probably since r2081 commit dba954e2de0c9c6218d17fc5c4974f4c28b627c3)
See VooDooFX's AvsInPaint problem at https://forum.doom9.org/showthread.php?p=1996653#post1996653

EDIT: pls test, and if it's good enough, then I'm gonna commit the fix to the central git repo

[VoodooFX]

That was a nasty bug. I’d rate it 9 out of 10 on the disgusting factor. It gave me an adrenaline rush but made me mentally empty for the rest of the week.

The bug had impact between sessions. When a program loaded Avisynth.DLL once, then run and reload scripts, e.g. AvsPMod editor. "The first takes everything", whatever script was using TurnLeft for RGB all the later TurnLefts were trying to save the results into RGB planes, even if they were of YUV format. Which of course was resulting in garbage.

Thanks for the challenge.

You're welcome.
"test14" - works good, no bug.


Btw, I was hopping that the bug will be related to the two bugs I encountered when I was creating gradients in Y8, mentioned there:
https://forum.doom9.org/showthread.php?p=1987019#post1987019


Second bug there aka "Another for official avs" - I couldn't remember how to reproduce it, script was somewhat similar to the first bug, I only remember the effect of it, instead of completely broken gradient (the bottom stacked clip in the example) it had a slight smudge of grey at the bottom of a clip.

[pinterf]

You're welcome.
"test14" - works good, no bug.

It’s no surprise that it worked, since I deliberately skipped test13. :)

[jpsdr]

3.7.3...??? Shouldn't be 3.7.4 ?

[VoodooFX]

3.7.3...??? Shouldn't be 3.7.4 ?

"3.7.3post" means post 3.7.3 aka 3.7.4.

[rgr]

During conversion ("ffmpeg -i input.avs output.mp4"), it rarely happens that suddenly the conversion simply stops (no error occurs, the line in ffmpeg simply stops refreshing).

I'm rather sure it's a problem with AviSynth, probably with some filter (I use ffms2, QTGMC, ff3dfilter and lsfmod + a few others like Vinverse).

How can I diagnose what is causing it?

[FranceBB]

it rarely happens that suddenly the conversion simply stops

I'm pretty sure it's the "frozen as ice" issue with avstp.dll I faced a long time ago and that Ferenc fixed.

See here: https://github.com/pinterf/mvtools/issues/46

Either update to the new avstp.dll https://github.com/pinterf/AVSTP/releases or get rid of the one you have in the plugins folder.
I'm pretty sure that it will solve the issue ;)

[real.finder]

speaking of cuda did someone note this https://github.com/vosen/ZLUDA ? did nekopanda Neo plugins work with it?

it was work with intel gpu https://github.com/vosen/ZLUDA/tree/60d2124a16a7a2a1a6be3707247afe82892a4163 but now it only work with amd gpu

[tormento]

speaking of cuda did someone note this
Nvidia stated a few days ago that reverse engineering of CUDA is illegal and I don’t see a very bright future for that project.

[hello_hello]

I'm not sure if it's ColorBars or the conversion to YUV, but there appears to be an out of range black. I assume it shouldn't be out of range after the conversion, although as ColorBars outputs limited range RGB, maybe there's supposed to be an out of range black. I don't know, so I thought I'd ask.
Cheers.

The first Image is
ColorBars().ConvertToYV24() with the histogram on top.
The second image is just to show where it is.
ColorBars().ConvertToYV24().Levels(0,2.5,255,0,255,coring=false)
Both color bars are half size.

https://i.ibb.co/5hVTLd5/A.jpg

https://i.ibb.co/zPNPqHP/B.jpg

[Emulgator]

ColorBars called without any parameters will export RGB32 8bpc PLUGE 7,16,25, and IIRC there is no "limited range RGB", so I would expect this.

[hello_hello]

Good to know. Thanks.

[DTL]

ColorBars()

Outputs narrow RGB. So White is 235 and Black is 16 as expected in lower stripe for levels check/setup. Also RGB data of 75% amplitude for WYCGRBB colour bars are in 180/16 narrow range.

(180-16)/(235-16) = 0.74885

Also
ColorBars()
PropShow()

correctly displays internal metadata marking:
_ColorRange = 1 = limited
_Matrix = 0 = rgb

[wonkey_monkey]

I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

PVideoFrame src = child->GetFrame(n, env);
PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);


The result of this code:

int planes[3] = { PLANAR_R, PLANAR_G, PLANAR_B };

for (int p = 0; p < 3; ++p) {
debug("%p , %p", dst->GetReadPtr(planes[p]), dst->GetWritePtr(planes[p]));
}


is always similar to the following:

00000000116E0A40 , 00000000116E0A40
0000000010C94040 , 0000000000000000
00000000111BA540 , 00000000111BA540


In other words, dst->GetReadPtr(PLANAR_G) returns a valid pointer, but dst->GetWritePtr(PLANAR_G) returns null.

Presumably something to do with this in interface.cpp:

BYTE* VideoFrame::GetWritePtr(int plane) const {
if (!plane || plane == PLANAR_Y || plane == PLANAR_G) { // planar RGB order GBR
if (vfb->GetRefcount()>1) {
_ASSERT(FALSE);
// throw AvisynthError("Internal Error - refcount was more than one!");
}
return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;
}
return vfb->data + GetOffset(plane);
}

[DTL]

It looks was same issue as in DecodeYUVtoRGB - I sometime got bad pointers if using PLANAR_R G B defines. I report it to pinterf but there were no detailed check what happen. So I simply use hand-adjusted numbers to get planes pointers -
https://github.com/DTL2020/ConvertYUVtoRGB/blob/625dcbfb91a2c11bc7850e8261b6bfc4b5a14519/DecodeYV12toRGB.cpp#L551

auto dstp_R = dst->GetWritePtr(4);
auto dstp_G = dst->GetWritePtr(6);
auto dstp_B = dst->GetWritePtr(2);

auto dstp_BGRA = dst->GetWritePtr(2);
auto dst_pitch_BGRA = dst->GetPitch();

auto dst_pitch_R = dst->GetPitch(PLANAR_R);
auto dst_pitch_G = dst->GetPitch(PLANAR_G);
auto dst_pitch_B = dst->GetPitch(PLANAR_B);

Though GetPitch() with PLANAR_R G B defines is working OK.

Maybe something is wierd with include headers or some other defines required or other C++ magic.

In the current AVS+ repository https://github.com/AviSynth/AviSynthPlus/blob/85057371294405f745f5c51b7a39fa0e3fdde821/avs_core/include/avisynth.h#L163
enum AvsPlane {
DEFAULT_PLANE = 0,
PLANAR_Y = 1 << 0,
PLANAR_U = 1 << 1,
PLANAR_V = 1 << 2,
PLANAR_ALIGNED = 1 << 3,
PLANAR_Y_ALIGNED = PLANAR_Y | PLANAR_ALIGNED,
PLANAR_U_ALIGNED = PLANAR_U | PLANAR_ALIGNED,
PLANAR_V_ALIGNED = PLANAR_V | PLANAR_ALIGNED,
PLANAR_A = 1 << 4,
PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7,
PLANAR_A_ALIGNED = PLANAR_A | PLANAR_ALIGNED,
PLANAR_R_ALIGNED = PLANAR_R | PLANAR_ALIGNED,
PLANAR_G_ALIGNED = PLANAR_G | PLANAR_ALIGNED,
PLANAR_B_ALIGNED = PLANAR_B | PLANAR_ALIGNED,
};

So PLANAR_R = 1 << 5,
PLANAR_G = 1 << 6,
PLANAR_B = 1 << 7, is much larger than 2,4,6 but may not work at some use cases as expected with GetWritePtr() calls (from some C++ objects ?) ?

From your part of program text:
something to do with this in interface.cpp:
return (refcount == 1 && vfb->refcount == 1) ? vfb->GetWritePtr() + GetOffset(plane) : 0;

If PLANAR_G processed as it should - there are 2 more ways to fail to zero -
refcount == 1 (not 1)
or
vfb->refcount == 1 (not 1)

So maybe you need to prepare somehow 'dst' pointer (around that 'refcount' C++ magic) before calling GetWritePtr() and system will return finally valid G-plane pointer as vfb->GetWritePtr() + GetOffset(plane) ? Can you build debug build of AVS+ and go with debugger inside GetWritePtr() function to check what is happen with (refcount == 1 && vfb->refcount == 1) ? condition and which of 2 (or both ?) internal 'refcount' variables cause condition to fail ? Or it is really vfb->GetWritePtr() returns zero ptr (and GetOffset(plane) returns zero because G is the first plane in planar RGB as comment notes) ?

Though other interesting question is: If 'dst' object is not in the 'right condition' to call GetWritePtr() method - why R and B planes are not fail call (returning failed zero ptr) ?

[StvG]

I may have found a bug with PlanarRGB (32-bit float, at least, I haven't tried any other depths yet). I use this code to re-use the src frame as dst, if it's writeable, or to create a new dst frame (I'm going to overwrite the contents anyway, so I do this to avoid the unnecessary copy that MakeWriteable might do):

PVideoFrame src = child->GetFrame(n, env);
PVideoFrame dst = src->IsWritable() ? src : env->NewVideoFrameP(vi, &src);


IsWritable() - "The rule about writability is this: A buffer is writable if and only if there is exactly one PVideoFrame pointing to it." (from here (http://avisynth.nl/index.php/Filter_SDK/Cplusplus_API)). If src->IsWritable() return true you do PVideoFrame dst = src and dst is not anymore writable because you have two PVideoFrame pointing to child->GetFrame(n, env).

[DTL]

So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like

PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else
dst = &(env->NewVideoFrameP(vi, &src));

?

[wonkey_monkey]

dst = &(env->NewVideoFrameP(vi, &src));

That seems unsafe. Wouldn't there then be zero real references to the newly-created video frame, because there's no PVideoFrame variable? Maybe:


PVideoFrame dst;
PVideoFrame *dst_p;
if (src->IsWritable() {
dst_p = &src;
} else {
dst = env->NewVideoFrameP(vi, &src);
dst_p = &src;
}

(*dst_p)->GetWritePtr(...



is safer?

I assume there is some logic to the code in interface.cpp which only does the reference count checks for PLANAR_Y and PLANAR_G, but I don't know what it might be. Unless that's the real bug, that it fails to check on the other planes? And should it throw an exception instead of returning null?

[StvG]

So dst must be pointer first and either point to existing src or create new object with env->NewVideoFrameP(vi, &src) ?

Something like

PVideoFrame *dst;
if (src->IsWritable()
dst = &src;
else
dst = &(env->NewVideoFrameP(vi, &src));

?

Just:


PVideoFrame dst;
if (!src->IsWritable())
dst=env->NewVideoFrameP();

uint8_t* dstp = (dst) ? dst->GetWritePtr() : src->GetWritePtr;

Edit: Or another way:


if (!src->IsWritable())
env->MakeWriteable(&src);

uint8_t* dstp = src->GetWritePtr;

[qyot27]

Presumably, the check exists the way it does because you would be allocating PLANAR_Y and PLANAR_G at the beginning of the sequence, since they're both the first plane in the the sequence order. Planar RGB is ordered GBR, as opposed to endian-specific packed RGB (which is either BGR in little or RGB in big).

For comparison, see how FFmpeg initiates the format in the AviSynth demuxer,
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avisynth.c;h=e85b9ae48878e52df5bb31da450f58229dff5277;hb=95a6788314a2f5080e8d5488dd5ba1040abeba6f#l127

127 static const int avs_planes_rgb[3] = { AVS_PLANAR_G, AVS_PLANAR_B,
128 AVS_PLANAR_R };
129 static const int avs_planes_yuva[4] = { AVS_PLANAR_Y, AVS_PLANAR_U,
130 AVS_PLANAR_V, AVS_PLANAR_A };
131 static const int avs_planes_rgba[4] = { AVS_PLANAR_G, AVS_PLANAR_B,
132 AVS_PLANAR_R, AVS_PLANAR_A };

[ENunn]

Hey there. I don't know if this is the place for bug reports or not but I found a bug. Whenever I use the normalize function, the audio gets super loud. Even if I have it set to 0.0001 it's really loud. I downgraded to 3.7.3 final and it's fixed. Don't know if I'm the only one with this issue but I wanted to give you a heads up.

[tebasuna51]

Hey there. I don't know if this is the place for bug reports or not but I found a bug. Whenever I use the normalize function, the audio gets super loud. Even if I have it set to 0.0001 it's really loud. I downgraded to 3.7.3 final and it's fixed. Don't know if I'm the only one with this issue but I wanted to give you a heads up.

I can't reproduce the problem with last test 14 (r4066), what is your installed version?
If it is the same version please upload the .avs used and the source (or a sample)

[pwnsweet]

I'm also having this issue. I'd love to enjoy 3.7.3 but haven't been able to resolve this so I'm stuck on 3.7.2



https://i.postimg.cc/4yZLWYbZ/Untitled.png (https://postimages.org/)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

[kedautinh12]

I'm also having this issue. I'd love to enjoy 3.7.3 but haven't been able to resolve this so I'm stuck on 3.7.2

Cause you don't update to 3.7.3 beta version. You just use the 3.7.3 stable version

[Dogway]

What's currently the recommended audio loading filter in avisynth? I generally use ffms2 but apparently bestaudiosource is better/less bugs? The thing is bestaudiosource hasn't been updated in 3 years.

[Emulgator]

LWLibavAudioSource here, occasionally FFAudioSource

[ravewulf]

Be careful with LWLibavAudioSource and the Dolby codecs as LWLibavAudioSource applies DRC by default. drc_scale needs to be manually set to 0 to avoid it

https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/issues/5

[Julek]

The thing is bestaudiosource hasn't been updated in 3 years.
A big update is coming.

And the current repo is this one:
https://github.com/vapoursynth/bestsource

[Kurt.noise]

Hi,

I would like to test the channelmask internal functions from the latest stable release (3.7.3) using this script :

LoadPlugin("C:\Users\LionelDUCHATEAU\Downloads\megui_git\megui\bin\x64\Debug\tools\lsmash\LSMASHSource.dll")
LWLibavAudioSource("C:\Users\LionelDUCHATEAU\Downloads\AC3 Samples\8w3D.eac3", drc_scale=0)
AudioDubEx(BlankClip(length=Int(1000*AudioLengthF(last)/Audiorate(last)), width=720, height=720, fps=25), last)
m=IsChannelMaskKnown()
g=GetChannelMask()
s=SetChannelMask(true,g)

Info()
Subtitle(
\ "\nAudioLength = " + String(AudioLength)
\ + "\nAudioLengthS = '" + AudioLengthS + "'"
\ + "\nAudioLengthF = " + String(AudioLengthF)
\ + "\nAudioLengthLo= " + String(AudioLengthLo)
\ + "\nAudioLengthHi= " + String(AudioLengthHi)
\ + "\nIsChannelMaskKnown= " + String(m)
\ + "\nGetChannelMask= " + String(g)
\ + "\nSetChannelMask= " + String(s)
\ , font="courier", text_color=$ffffff, size=32, align=4, lsp=0)

but String(s) doesn't return something whereas I get information from Info(). Did I miss something here ?

[rgr]

I'm pretty sure it's the "frozen as ice" issue with avstp.dll I faced a long time ago and that Ferenc fixed.

See here: https://github.com/pinterf/mvtools/issues/46

Either update to the new avstp.dll https://github.com/pinterf/AVSTP/releases or get rid of the one you have in the plugins folder.
I'm pretty sure that it will solve the issue ;)

I updated a few things in the last 2 months (including AviSynth and AVSTP) and haven't had any freezes since. So something helped :)

[FranceBB]

I updated a few things in the last 2 months (including AviSynth and AVSTP) and haven't had any freezes since. So something helped :)

Yep, Ferenc fixed it in avstp.
I mean, of course he did, he's amazing.

[Emulgator]

Be careful with LWLibavAudioSource and the Dolby codecs as LWLibavAudioSource applies DRC by default. drc_scale needs to be manually set to 0 to avoid it.
Thanks ravewulf. Comes in handy, just developing a snippet where this can be used:
https://forum.doom9.org/showthread.php?t=167435&page=80

[pinterf]

Hi,

I would like to test the channelmask internal functions from the latest stable release (3.7.3) using this script :

LoadPlugin("C:\Users\LionelDUCHATEAU\Downloads\megui_git\megui\bin\x64\Debug\tools\lsmash\LSMASHSource.dll")
LWLibavAudioSource("C:\Users\LionelDUCHATEAU\Downloads\AC3 Samples\8w3D.eac3", drc_scale=0)
AudioDubEx(BlankClip(length=Int(1000*AudioLengthF(last)/Audiorate(last)), width=720, height=720, fps=25), last)
m=IsChannelMaskKnown()
g=GetChannelMask()
s=SetChannelMask(true,g)

Info()
Subtitle(
\ "\nAudioLength = " + String(AudioLength)
\ + "\nAudioLengthS = '" + AudioLengthS + "'"
\ + "\nAudioLengthF = " + String(AudioLengthF)
\ + "\nAudioLengthLo= " + String(AudioLengthLo)
\ + "\nAudioLengthHi= " + String(AudioLengthHi)
\ + "\nIsChannelMaskKnown= " + String(m)
\ + "\nGetChannelMask= " + String(g)
\ + "\nSetChannelMask= " + String(s)
\ , font="courier", text_color=$ffffff, size=32, align=4, lsp=0)

but String(s) doesn't return something whereas I get information from Info(). Did I miss something here ?
SetChannelMask returns the clip itself, you cannot stringify it.

If you'd like to get the friendly name of the channel mask constant combination, it's not possible. It's used by Info, so it is only an internal function.

Docs.
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/setchannelmask.html

[pinterf]

Yep, Ferenc fixed it in avstp.
I mean, of course he did, he's amazing.
Your welcome, yes, the culprit was possibly avstp.

[pinterf]

What's happening in the background:
There are some difficult, though very specific phenomenons under investigation, such as
- why memory consumption grows when someone manually singlesteps forward 40 then backward 10 frames in Avspmod
- is it theoretically possible to eliminate the ever-growing behavior of Avisynth's string heap, which can be vry agressive if a runtime function (ScriptClip) contains a lot of string operation
They are both annoying ones but still, interesting challenges to solve.

Then there are some ideas from qyot27 about supporting/emulating frame property inheritance / setting for old plugins and filters which possibly would never get rebuilt.

- implemented 'continue' and 'break' for control loops, after Asd-g's request. (no build from me yet)
More info at
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/syntax/syntax_control_structures.html#using-break-and-continue-in-loops

[FranceBB]

- implemented 'continue' and 'break' for control loops

uuuuuuuuuuh very very nice! :D

[wonkey_monkey]

- why memory consumption grows when someone manually singlesteps forward 40 then backward 10 frames in Avspmod

Just Avspmod, not VirtualDub? I have my own viewer I can test against if there's a particular clip that has this behaviour.

[pinterf]

Just Avspmod, not VirtualDub? I have my own viewer I can test against if there's a particular clip that has this behaviour.
Probably the situation is the same with VirtualDub and with any tool that can request arbitrary frames.

[pinterf]

Probably the situation is the same with VirtualDub and with any tool that can request arbitrary frames.
Not necessarily. I don't know what AvsPmod is doing.

I put several debug lines to see what the real frame sequence that must be served by Avisynth (avs_get_frame C interface call). In order to see, which specific frame sequence fools Avisynth prefetcher prediction logic. (I supposed that when I do a backward single-step in Avspmod, Avisynth prefetcher will recognize the new - now negative - pattern, and the Prefetcher will lock into the new delta=-1 prefetching schema.)

And it seems that AvsPMod is requesting the same frame numbers multiple times during its display, even in arbitrary (not one-by-one) order

I see multiple clips, two Prefetch statements, which made the debugging a bit harder :), maybe they are different clips, one before the resizing - the actual unaltered clip - and one after the display conversion?

E.g. sometimes, when I press the "back-reverse", it skips back by 2 frames on one of its script instance, which ends with Prefetch(1,1).
And only by 1 frames with another (?) script instance which ends with the Prefetch(4) - the last line in the script.

@gispos, can you help me with it? The actual issue on github is:
https://github.com/AviSynth/AviSynthPlus/issues/379#issuecomment-2048852993
after a doom9 report:
https://forum.doom9.org/showthread.php?p=1995403#post1995403
Thank you

[tormento]

Do we still need to declare SetMemoryMax?

I mean, almost 70% of the computers are now 64-bit with gazillions of GBs of RAM.

Is it of any use? Can't we simply let modern Windows to manage memory?

[LigH]

You can probably omit it quite safely. Avisynth uses a convenient default.

[Boulder]

The default is quite conservative and is sometimes not enough if you work on 4K sources with heavy filtering and use multithreading. There's no real harm setting the max higher if you have the memory available, Avisynth will use what it needs and not all of it automatically.

[tormento]

Perhaps I didn't explain well.

I know I can set it as I want but, seen VaporSynth memory use, why can't AVS+ go that way too and send Setmemorymax to ancient memories?

[tormento]

The default is quite conservative and is sometimes not enough if you work on 4K sources with heavy filtering and use multithreading.
I can't find my post but, some years ago, I did some tests where I saw performance decrease with Setmemorymax increase.

[FranceBB]

I know I can set it as I want but, seen VaporSynth memory use, why can't AVS+ go that way too and send Setmemorymax to ancient memories?

It's already ancient memory.
There's no need to set it, Avisynth will manage that automatically.
By default, in modern x64 systems, it will use 4GB of RAM which is plenty.
Remember that this is the memory of the cache, in other words the memory used to store frames without having to fetch them again, NOT the RAM used by filters in general. This means that even if you were to set SetMemoryMax(512) but you were heavily filtering a UHD content, Avisynth would still use way more than 512MB of RAM. Remember that the cache is there only so that if you have temporal filters and encoders that need to access frames in a non linear fashion, Avisynth won't have to compute them every single time it moves forward and backward and forward and backward etc. The bigger the cache the more frames are gonna be stored, but storing too many frames can be detrimental as it's gonna use RAM that could otherwise be used by - let's say - the encoder, which is why the cache size is calculated on the fly on the basis of the available RAM and it never exceeds 4GB.

Assuming RGB48 (which is overkill anyway), we have:

3840×2160×48 = 398131200 bits = 0.0498 gigabyte

That's just for one frame, so at the current default Avisynth can cache more than 80 frames. Obviously working with RGB48 UHD is a bit unrealistic, but if we work in YUV that number increases and it even goes much further if we work in 8bit and at lower resolutions.
My point is that it's already implemented correctly and I don't see a reason to change that. If anything, having the SetMemoryMax() is useful if you wanna reduce the cache. ;)

[DTL]

It looks you not understand how frame-based AVS+ MT is working.

To make things as fast as possible (to minimize CPU stall on threads sync) it looks AVS+ simply put several frames cache around _each_ filter in the filtergraph and in _each_ logical thread. So any time system have some free logical CPU cores it can load it with some useful computing.

But it cause awful RAM consuming in any 'complex' scripts of a several filters in a chain.

Total RAM in a cache is about NumFrames_in_Prefetch_x_NumFilters_x_NumThreads_x_FrameSize.

[Boulder]

Regarding the 4GB, which is unfortunately not enough in many cases: https://forum.doom9.org/showthread.php?p=1913375#post1913375

[tormento]

Regarding the 4GB
AVSMeter can provide realistic results?

(Where on hell has Groucho2004 gone?)

Secondo question: SetCacheMode(1) is a good choice?

[FranceBB]

Regarding the 4GB, which is unfortunately not enough in many cases: https://forum.doom9.org/showthread.php?p=1913375#post1913375

Another interesting thing about prefetch, I see!



Total RAM in a cache is about NumFrames_in_Prefetch_x_NumFilters_x_NumThreads_x_FrameSize.

I see! But to clarify I don't actually use Prefetch, like ever, I'm on the good old concept of letting plugin developers handle multithreading, so my scripts don't have it.
For instance, my scripts are like:

video=LWLibavVideoSource("video.mxf")
audio=LWLibavAudioSource("audio.mxf")
AudioDub(video, audio)

ConvertBits(16)

ConvertYUVtoXYZ(Color=0, OutputMode=1, HDRMode=0, fullrange=false)

ConvertXYZ_Reinhard_HDRtoSDR(exposure_X=2.5, contrast_X=0.9)

ConvertXYZtoYUV(pColor=0)


without prefetch. In the example above, the filters would create their own threadpool which is how I think it's intended to be. Call me traditionalist but I see Prefetch() as an evolution of the old MT Modes from 2009 (https://forum.doom9.org/showthread.php?t=148782) and in my head they should only be used if the filter you're calling is old and single-threaded only and of course at your own risk as it might misbehave, especially if it filters temporally.


This however brings me to a different question, then.
Is there an advantage in raising the SetMemoryMax() value from 4GB to something higher IF I don't use Prefetch()?

[DTL]

If you not use Prefetch() it mean AVS+ will run all filtergraph with single threaded cache mode ? So the equation for total cache size is about
NumFrames_in_Prefetch_x_NumFilters_x_FrameSize.

Default num frames in AVS+ cache (for each filter) is at least several ? (2..3 to 10 ? or num of physical cores ?).

"Is there an advantage in raising the SetMemoryMax() value from 4GB to something higher IF I don't use Prefetch()?"

It may depends on workflow. And easy tested between 4 GB and all RAM avaialble. The idea of SetMemoryMax() may be complex hint to AVS memory manager like to save from swapping of too much allocated cache pages attempt to lower number of cached frames if total process RAM allocation approaches the current RAM limit.

Because with increasing number of frames in the cache user may got some performance boost (depending of filters used and many more effects) setting too low MemoryMax may cause decreasing of performance in some use cases. It is better to check with exact end user workflow.

[Boulder]

AVSMeter can provide realistic results?

(Where on hell has Groucho2004 gone?)

Secondo question: SetCacheMode(1) is a good choice?

Windows Task Manager shows the same information. With heavy prefetch settings like threads=32, frames=12 on my 5950X, a 4K source with MVTools based filtering and downscaling with avsresize's functionalities, outputting 16-bit data to x265 can take 20GB of memory. The amount of frames to prefetch is the key to memory usage. That's why it is important to restrict it if you have a lot of cores, the default is way too much (would be 64 frames in this case :eek:)

I've found out that mode 1 is better.

[Boulder]

This however brings me to a different question, then.
Is there an advantage in raising the SetMemoryMax() value from 4GB to something higher IF I don't use Prefetch()?

I would say probably not. I've been running my chunked encoding tool and the memory usage is usually max 3GB per avs2yuv64 process with my standard denoising and resizing functions. Though it's with 10-bit output, I've not tested if 16-bit output changes things that much to go over the 4GB limit.

[tormento]

My findings.

Basic script

SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("M:\In\2013 GIT - Arise ~864p Dynit\2013_06 Ghost pain.dgi")
Comptest24(1)
Convertbits(16)
libplacebo_Resample(1536,864,filter="ewa_lanczossharp")
SMDegrain (tr=3, thSAD=300, refinemotion=false, contrasharp=false, PreFilter=7, plane=4, chroma=true, mode="MDegrain")
libplacebo_Deband(iterations=3, temporal=true)
fmtc_bitdepth (bits=10,dmode=7)
Prefetch(3)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4071, 3.7, x86_64) (3.7.3.0)

Number of frames: 1680
Length (hh:mm:ss.ms): 00:01:10.070
Frame width: 1536
Frame height: 864
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P10

Frames processed: 1680 (0 - 1679)
FPS (min | max | average): 1.202 | 116279 | 11.54
Process memory usage (max): 1990 MiB
Thread count: 45
CPU usage (average): 35.7%

GPU usage (average): 15%
VPU usage (average): 8%
GPU memory usage: 1496 MiB
GPU Power Consumption (average): 41.6 W

x265 slow: encoded 1680 frames in 297.25s (5.65 fps), 1134.83 kb/s, Avg QP:23.77

Adding on top:

SetMemoryMax()

FPS (min | max | average): 1.589 | 55866 | 11.33
Process memory usage (max): 1947 MiB
Thread count: 45
CPU usage (average): 35.6%

x265 slow: encoded 1680 frames in 293.64s (5.72 fps), 1138.50 kb/s, Avg QP:23.70

Adding on top:

SetCacheMode(1)

FPS (min | max | average): 0.340 | 178572 | 11.52
Process memory usage (max): 1849 MiB
Thread count: 45
CPU usage (average): 35.7%

x265 slow: encoded 1680 frames in 297.86s (5.64 fps), 1137.39 kb/s, Avg QP:23.72

Adding on top:

SetMemoryMax()
SetCacheMode(1)

FPS (min | max | average): 0.338 | 133333 | 11.42
Process memory usage (max): 1846 MiB
Thread count: 45
CPU usage (average): 35.6%

x265 slow: encoded 1680 frames in 284.14s (5.91 fps), 1136.06 kb/s, Avg QP:23.72

I see some discrepancies between avs+ only and real world scenario with x265 encoding but, perhaps, is just my old machine.

[DTL]

"SetMemoryMax() "

I think it requires memory size (in MBytes ?). Empty params call do not change current AVS memory max.

SetMemoryMax(amount)
Sets the maximum memory that AviSynth uses (in MB) to the value of amount. Setting to zero just returns the current Memory Max value. In the 2.5 series the default Memory Max value is 25% of the free physical memory, with a minimum of 16MB.
The default Memory Max is also limited to 512MB.
AVS+In Avisynth+ this limit for default Memory Max is 1024MB for 32 bits and 4096MB on the x64 version
DefaultMemoryMax = minimum(physical_memory / 4, secondary_memory_max_limit)

This really working:

ColorBars()

mem=SetMemoryMax(0)
SubTitle(Format("old default max={mem}!"))


SetMemoryMax(5000)
mem=SetMemoryMax(0)
SubTitle(Format("new max={mem}!"), align=4)


First call returns old memory max value (4074 at me) and second call sets to 5000 MB.

So you can first check your current system default memory max and check some significant changes like set to 10 times lower and about 70..80% of current RAM installed.

[guest]

Where did this come from ??

AviSynth+ 3.7.3 (r4071, 3.7, x86_64) (3.7.3.0)

[DTL]

From documentation at http://avisynth.nl/index.php/Internal_functions

http://avisynth.nl/index.php/Internal_functions#SetMemoryMax

[guest]

From documentation at http://avisynth.nl/index.php/Internal_functions

http://avisynth.nl/index.php/Internal_functions#SetMemoryMax

Sorry DTL, you misunderstood :(

Where did that build of Avisynth come from, (r4071) In tormento's post.

But :thanks:

Found it....https://gitlab.com/uvz/AviSynthPlus-Builds

[tormento]

"SetMemoryMax() "

I think it requires memory size (in MBytes ?). Empty params call do not change current AVS memory max
I look at numbers :)

Something happens and is not what I expected.

Some years ago I did benchmarks here with various amount of memory and that () lead to the best results, even against higher ones.

[hello_hello]

Is it intended for the Convert functions to change the chroma location when they're not actually changing the color format?

For example, if you have a YUV420 source with the chroma location in frame properties as "top_left", and you add ConvertToYUV420() to the script, the color format doesn't change but the chroma location changes to "left".

I know "left" is the default output chroma location, and it works as the Avisynth wiki says it does, but before I noticed the chroma location had changed and checked, I expected it to remain the same unless the color format had changed.

I can't decide if changing the location when there's no conversion taking place is a good idea. Or maybe it doesn't matter much....

Cheers.

[FranceBB]

I'm back with some examples.
After the last discussion about SetMemoryMax() I did some more tests and this time I used a real script from a real use case scenario (although I trimmed the first 1000 frames only as I didn't want to let it filter 40 minutes worth of documentary for nothing).


Source: DNX HQX UHD 4:2:2 12bit 728 Mbit/s BT709 SDR

Video
ID : 2
Format : VC-3
Commercial name : DNxHR HQX
Format version : Version 3
Format profile : RI@HQX
Format settings, wrapping mode : Frame
Codec ID : 0D01030102110100-0401020271250000
Duration : 40 min 53 s
Bit rate mode : Constant
Bit rate : 728 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 12 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.512
Stream size : 208 GiB (100%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709



AVS Script:


video=LWLibavVideoSource("PARTE 1.mxf")
FL=WAVSource("Parte 1 Mix OnAir.L.wav")
FR=WAVSource("Parte 1 Mix OnAir.R.wav")
CC=WAVSource("Parte 1 Mix OnAir.C.wav")
LFE=WAVSource("Parte 1 Mix OnAir.LFE.wav")
LS=WAVSource("Parte 1 Mix OnAir.Ls.wav")
RS=WAVSource("Parte 1 Mix OnAir.Rs.wav")

Dolby=MergeChannels(FL, FR, CC, LFE, LS, RS)

Stereo=WAVSource("Parte 1 MIX Lt - Rt.wav")

Mute=BlankClip(length=61335, fps=25, audio_rate=48000, channels=2)

audio=MergeChannels(Stereo, Mute, Dolby, Mute, Mute, Mute)

AudioDub(video, audio)


ConvertBits(16)

z_ConvertFormat(pixel_type="RGBP16", colorspace_op="709:709:709:limited=>rgb:709:709:full", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

Cube("C:\Program Files (x86)\AviSynth+\LUTs\5a_BT709_HLG_UPCONVERT_DISPLAY_mode.cube", fullrange=1, interp=1)

z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion", use_props=0)

Limiter(min_luma=64, max_luma=940, min_chroma=64, max_chroma=960)

trim(0, 1000)




AVS Meter Test:


AvsMeter64.exe "Test.avs"

pause



Hardware:

CPU: Intel Xeon Gold 6238R 2.20GHz x2 (56c/112th)
RAM: 32 x 4 DDR4 1460 MHz (128 GB)
Motherboard: HPE ProLiant XL420 Gen10
GPU: HP Matrox Matrox G200eh3 32MB
Storage 1: 447GB Hitachi
Storage2: 4471GB Hitachi
NIC: HP 562SFP+ 10 Gigabit

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


Test 1 - no SetMemoryMax() specified (i.e default 4GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 3.484 | 4.231 | 4.084
Process memory usage (max): 808 MiB
Thread count: 73
CPU usage (average): 2.3%

Time (elapsed): 00:04:05.089



Test 2 - SetMemoryMax(25000) specified (i.e 25GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 3.574 | 4.406 | 4.201
Process memory usage (max): 841 MiB
Thread count: 73
CPU usage (average): 2.3%

Time (elapsed): 00:03:58.282



Test 3 - SetMemoryMax(90000) specified (i.e 90GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 3.580 | 4.405 | 4.209
Process memory usage (max): 841 MiB
Thread count: 73
CPU usage (average): 2.3%

Time (elapsed): 00:03:57.812


As we can see from the tests above, even when working on UHD 12bit contents with 16bit precision and doing very heavyweight operations like converting to RGB full range, applying a LUT with tetrahedral interpolation, going back to YUV limited tv range and dithering down to 10bit, the RAM usage never exceeds 4GB, in fact it doesn't matter how much RAM I tell Avisynth to allocate with SetMemoryMax(), it never really uses it anyway and the performances stay the same. This is - of course - without using Prefetch() and I never use it in any of my encodes anyway, so I guess I'm safe to say that I don't really need to specify SetMemoryMax() and I'm pretty much fine with the default value. :)


Here's another test with a different kind of conversion, this time instead of going from BT709 SDR to BT2020 HLG with highlights expansions to 420 nits using the BBC LUT, we're using HDR Tools by Jean Philippe Scotto di Rinaldi to go to BT2020 SDR 100 nits:

AVS Script:

video=LWLibavVideoSource("PARTE 1.mxf")
FL=WAVSource("Parte 1 Mix OnAir.L.wav")
FR=WAVSource("Parte 1 Mix OnAir.R.wav")
CC=WAVSource("Parte 1 Mix OnAir.C.wav")
LFE=WAVSource("Parte 1 Mix OnAir.LFE.wav")
LS=WAVSource("Parte 1 Mix OnAir.Ls.wav")
RS=WAVSource("Parte 1 Mix OnAir.Rs.wav")

Dolby=MergeChannels(FL, FR, CC, LFE, LS, RS)

Stereo=WAVSource("Parte 1 MIX Lt - Rt.wav")

Mute=BlankClip(length=61335, fps=25, audio_rate=48000, channels=2)

audio=MergeChannels(Stereo, Mute, Dolby, Mute, Mute, Mute)

AudioDub(video, audio)


ConvertBits(16)

#BT709 SDR to BT2020 SDR

ConvertYUVtoXYZ()
ConvertXYZtoYUV(Color=1, pColor=2)

ConverttoYUV422(matrix="Rec.2020", interlaced=false)

ConvertBits(bits=10, dither=1)

Limiter(min_luma=64, max_luma=940, min_chroma=64, max_chroma=960)

trim(0, 1000)


Test 1 - no SetMemoryMax() specified (i.e default 4GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 4.594 | 8.925 | 5.896
Process memory usage (max): 1377 MiB
Thread count: 129
CPU usage (average): 16.5%

Time (elapsed): 00:02:49.782


Test 2 - SetMemoryMax(25000) specified (i.e 25GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 4.550 | 8.933 | 5.884
Process memory usage (max): 1377 MiB
Thread count: 129
CPU usage (average): 16.3%

Time (elapsed): 00:02:50.134


Test 3 - SetMemoryMax(90000) specified (i.e 90GB)

AVSMeter 3.0.9.0 (x64), (c) Groucho2004, 2012-2021
AviSynth+ 3.7.3 (r4003, 3.7, x86_64) (3.7.3.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YUV422P10
Audio channels: 16
Audio bits/sample: 24
Audio sample rate: 48000
Audio samples: 1921920

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 4.655 | 8.845 | 5.877
Process memory usage (max): 1377 MiB
Thread count: 129
CPU usage (average): 16.0%

Time (elapsed): 00:02:50.337

For those wondering why I'm "happy" with this, please consider that this server is part of a wider farm and would typically run several encodes at the same time, so the CPU is gonna be pegged at 100% anyway. Besides, those tests were made only considering Avisynth, but when x264 is encoding the files in XAVC Intra Class 300 then the usage consumption is of course much higher.

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

For reference, today the farm encoded 284 files:

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

[hello_hello]

This is - of course - without using Prefetch() and I never use it in any of my encodes anyway, so I guess I'm safe to say that I don't really need to specify SetMemoryMax() and I'm pretty much fine with the default value.

If you don't add Prefetch, Avisynth+ runs in single threaded mode. Adding Prefetch can make a huge difference to encoding speed, depending on the filtering in the script.

There's a file here that can be saved as an avsi script and auto-loaded by Avisynth+. It tells Avisynth+ the type of multi-threading to use for most of the common plugins. Many plugins register their multi-threading mode with Avisynth+ automatically these days, but they still require you to add Prefetch to the script to activate multi-threading.

https://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

More info
http://avisynth.nl/index.php/AviSynth+#Help_filling_MT_modes

I assume for plugins with "internal" multi-threading it's a different thing to enabling Avisynth's own multi-threading. Ideally for some plugins, such as the ones in the JPSDR plugins pack, you should use the plugin arguments to specify how many threads Avisynth+ is using when you've added Prefetch to the script. And sometimes it's better to disable a plugin's multi-threading. Apparently it's not a good idea to use avstp.dll for multi-threading when Avisynth's multi-threading is enabled. The script I linked to above also tells avstp.dll to run in single threaded mode, assuming it's loaded.

[cretindesalpes]

Yep, Ferenc fixed it in avstp.
I mean, of course he did, he's amazing.

Sorry I’m a bit late to the party. I read the Ferenc debugging report (https://github.com/pinterf/AVSTP/issues/1). Very interesting, nice catch! I saw that an assert occured in:

++ loop_cnt;
if (loop_cnt >= max_loop)
{
// This could indicate that the queue is:
// - corrupted
// - or in heavy contention
assert (false);
return nullptr;
}

Obviously returning 0 is not expected at all by the calling code and makes everything fail. But have you tried to increase max_loop? The value in the code is totally arbitrary, I haven’t done any statistics on the maximum loop_cnt I could encounter in a heavy use, but maybe we are sometimes close to the limit (contention case)? (edit: the GRAME paper doesn’t even have this check in the presented algorithm, I probably added it during development).

Anyway, I love the irony of the fix: enclosing a “lock-free” code in a std::lock_guard :D
BTW this could be achieved more simply using a trivial std::list or std::deque for storage with guarded access instead of the complicated lock-free procedure. But I’m glad you fixed it!

[FranceBB]

Currently, when a Convertto function is called, it uses the matrix from the frame properties.
This is ok, however it only really works when the file is right and the indexer populates the frame properties correctly, which is not always the case.
Here's a sample file: https://we.tl/t-aJB9L84pmw (link valid for 7 days)
(keep in mind that the file ain't important, it's just an example to make a point).

When it's being indexed by FFVideoSource() it shows the following frame properties:

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

Clearly Matrix(3) doesn't mean anything, but you can bet everything you want that ConverttoRGB24() is gonna try to use that and fail, in fact it fails with "Unknown matrix".

Of course one could always nuke frame properties with propClearAll() before using ConverttoRGB24() and call it a day, however that's not exactly ideal.

What I'm proposing here is to still allow the Convertto functions to use the matrix populated by the frame properties as it is today, but, if it's populated automatically and not passed by the user explicitly, to fallback to a safe default instead of throwing an error if what is passed through is garbage.

[ENunn]

I can't reproduce the problem with last test 14 (r4066), what is your installed version?
If it is the same version please upload the .avs used and the source (or a sample)

Sorry for the months late reply.

I just tried it again, and I'm still having the issue. It's not happening with every script, but some.

Source video (https://mega.nz/file/X19HRZQT#cB05_0cj0HJjEttX3Pxrd1QSsUmD1R65frvtNkF2scg)
Source audio (https://mega.nz/file/3scj3RTJ#sl-pV9hRn_9VTjO-IoYEiqjnyn6Wic2NHtvTHH74Mbs)

Script:
v = lwlibavvideoSource("f:\virtualdub\tape transfers\opening to swing time 1996 vhs - edit.mkv", fpsnum=30000,fpsden=1001)
a = lwlibavaudiosource("d:\recordings\opening to swing time 1996 vhs - edit.flac")
audiodub(v,a)
#delayaudio(-.150)
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
#Crop(8, 4, -24, -6_
Levels(50, 1,920, 0, 1020, coring=false,dither=true).tweak(bright=0, cont=1.00, hue=-0, sat=1.00, coring=false, dither=true).convertbits(8)
#turnRight().Histogram().TurnLeft()
normalize(0.8912)
Trim(415, 5286)
prefetch(8)

Example (https://mega.nz/file/3tkR3DrQ#pIYwhumwtu2GDiwn9R1n2mncaYzNpR3f3VoFsPMMr4c) WARNING: LOUD!!!

[tebasuna51]

Yes, there are a problem and I can't understand where.

Played your script in VirtualDub2 sound noise and distorted audio.

Without the normalize() play fine, but also without the normalize play noise in mpc_hc.

Tested also the FFAudioSource and BSAudioSource decoders, and only the audio without video, normalize, etc., always noise and distort.

Maybe something related with AviSynth flac decoders?
Decoded with ffmpeg or flac seems fine.

[LigH]

There is FLAC with 24 bit resolution. That might be unusual for an Avisynth audio decoder and sound wrong when it does not report the correct sample layout.

Can you check technical details of your audio source, e.g. with MediaInfo or FLAC tools?

[ENunn]

Yes, there are a problem and I can't understand where.

Played your script in VirtualDub2 sound noise and distorted audio.

Without the normalize() play fine, but also without the normalize play noise in mpc_hc.

Tested also the FFAudioSource and BSAudioSource decoders, and only the audio without video, normalize, etc., always noise and distort.

Maybe something related with AviSynth flac decoders?
Decoded with ffmpeg or flac seems fine.

I had the same issue with an ac3 file, but as I said before, it seems to happen on some files, but not all.

There is FLAC with 24 bit resolution. That might be unusual for an Avisynth audio decoder and sound wrong when it does not report the correct sample layout.

Can you check technical details of your audio source, e.g. with MediaInfo or FLAC tools?
General
Complete name : D:\recordings\opening to swing time 1996 vhs - edit.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 15.9 MiB
Duration : 3 min 0 s
Overall bit rate mode : Variable
Overall bit rate : 740 kb/s

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 3 min 0 s
Bit rate mode : Variable
Bit rate : 740 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Compression mode : Lossless
Stream size : 15.9 MiB (100%)
Writing library : libFLAC 1.3.2 (2017-01-01)
MD5 of the unencoded content : 3C5F271BC902D1430FDC4F3D062F4A21


This was a FLAC created by Adobe Audition. I usually do some dehumming and denoising. I imported the raw audio, also in FLAC (but this time converted with ffmpeg), and the same issue happens. I did try converting it to PCM with ffmpeg as well, and the issue persists. This doesn't happen with r4003.

[qyot27]

I can't reproduce it here. Samples as posted, script as posted. LSMASHSource built on May 1, freshly built AviSynth+ r4076 plugnew, Ubuntu 24.04. There's no noise or distortion.

[ENunn]

Just to be safe, I updated LSMASHWorks, and the issue persists.

[qyot27]

What happens if you use SetMaxCPU("None")?

Is this with 32-bit or 64-bit AviSynth+?

[ENunn]

What happens if you use SetMaxCPU("None")?
Still loud unfortunately.

Is this with 32-bit or 64-bit AviSynth+?
64-bit.

[Emulgator]

Confirmed on AviSynth r4066.
LWLibavAudioSource, normalize(0.8912) on 64 bit Avisynth 4066 -> too much gain, negative values only, positive sample values clipped at 0
BestAudioSource: the same -> too much gain, negative values only, positive sample values clipped at 0
FFAudioSource: the same -> too much gain, negative values only, positive sample values clipped at 0
normalize(0.001) the same -> too much gain, negative values only, positive sample values clipped at 0
normalize(0.001, show=true) tells amplify DB: -58.9998 while still clipping heavily.

LWLibavAudioSource, normalize(0.8912) on 32 bit Avisynth 4066 -> fine
All these sourcefilters decode that .flac file as 2.0 16bit int, SoundForgePro 11.0 see it as 2.0 16bit too.

In SoundForgePro 11.0 I see a ± disbalance, not just a DC offset towards negative values.
Negative peaks coming from the narrator's mike are much stronger.
May be that is it what dips normalize64bit in the ocean ?

BTW, I had a overused Shure SM58 here which delivered the same waveform.
As a sound engineer I had to retire this one from duty.
Misadjusted coil vs gap, so a diaphragm dip gave less efficient voltage than a lift.
Nice to see on a scope or from the waveform.

AviSynth 4073 Clang is a no-starter for me. Gotta look out for AviSynth r4076...
Ah, AviSynth+ r4073 Intel LVM 64bit works ! And normalize fault is gone. Phew.

[tebasuna51]

Ah, AviSynth+ r4073 Intel LVM 64bit works ! And normalize fault is gone. Phew.

With:
AviSynth+ 3.7.3 (r4073, 3.7, x86_64) IntelLLVM
BestSource.dll [n/a, 2024-04-25]
ffms2.dll [2390.0.0.0, 2024-03-06]
LSMASHSource.dll [1194.0.0.0, 2024-04-08]
And using (tested 3 decoders, same behavior):
#BSAudioSource("opening to swing time 1996 vhs - edit.flac")
#FFAudioSource("opening to swing time 1996 vhs - edit.flac")
LWLibavAudioSource("opening to swing time 1996 vhs - edit.flac", drc_scale=0)
AudioDubEx(BlankClip(length=Int(1000*AudioLengthF(last)/Audiorate(last)), width=720, height=720, fps=25), last)
Info()
Normalize(0.95)

Play fine in VirtualDub2 (stereo 16 bits).
Using AviSynth test 14 r4066 the output is like the attached image.

But, with r4073, still is wrong played in mpc-hc

[Emulgator]

tebasuna51, did you try to play a .avs script in MPC-HC served from r4073 ?
Or did you play a transcoded .wav as the title bar suggests, maybe from SoundOut() AviSynth r4073?

[tebasuna51]

tebasuna51, did you try to play a .avs script in MPC-HC served from r4073 ?
Or did you play a transcoded .wav as the title bar suggests, maybe from SoundOut() AviSynth r4073?

Of course I listen noise playing the .avs directly over mpc-hc with r4073 active, the wav is the VirtualDub2->File->Save Audio with r4066 active

[Emulgator]

So this would mean that r4073 still has the fault inherited.
AviSynth64+ r4073
Just throwing the script on MPC-HC64 2.3.0 here: plays fine.
LAVSplitter -> SaneAR Render

MPC-BEx64 1.7.2 using MPC Audio renderer: missing audio source filter, plays video only.
AVI/WAV File Source::Avisynth audio #1

Media Type 0:
--------------------------
Audio: 0xfffe 48000Hz 2.0 chn 1536 kbit/s

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_0xfffe {0000FFFE-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 4
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 2
nSamplesPerSec: 48000
nAvgBytesPerSec: 192000
nBlockAlign: 4
wBitsPerSample: 16
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 16
dwChannelMask: 0x00000003
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

[StvG]

AviSynth64+ r4073 (both clang and Intel LLVM) + MPC-BE x64 1.7.2 (MPC Audio Renderer, LAV Filters 0.79.2) no issues with the following (also no issues with mpv 0.38.0 x86_64):
v = lwlibavvideoSource("opening to swing time 1996 vhs - edit.mkv", fpsnum=30000,fpsden=1001)

a = lwlibavaudiosource("opening to swing time 1996 vhs - edit.flac")
audiodub(v,a)
#delayaudio(-.150)
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
#Crop(8, 4, -24, -6_
Levels(50, 1,920, 0, 1020, coring=false,dither=true).tweak(bright=0, cont=1.00, hue=-0, sat=1.00, coring=false, dither=true).convertbits(8)
#turnRight().Histogram().TurnLeft()
normalize(0.8912)
Trim(415, 5286)

[tebasuna51]

Test with some player options:
r4073 r4066
------------------ ------------------
Player without Normalize without Normalize
--------------------- ------- --------- ------- ---------
mpc-hc 2.3.2 DirectS Ok Noise Noise Noise
mpc-hc 2.3.2 + SaneAR Ok Ok Ok Noise
VirtualDub2 2.1.1.607 Ok Ok Ok Noise
mpc-be 1.7.1 MPC-Aud Ok Ok Ok Ok
mpc-be 1.7.1 DirectS Ok Ok Ok Noise
vlc 3.0.21 Ok Ok Ok Noise

@pinterf
Maybe we need a new test15 and/or a new release 3.7.4, the 3.7.3 is 1 year old.

[qyot27]

Between r4066 and r4073 these were the changes:
Add cache for string heap to avoid duplicates. related to #389
pinterf committed Apr 17, 2024

Add basic ArraySort
pinterf committed Apr 17, 2024

Update documentation and changelog (break/continue)
pinterf committed Apr 10, 2024

SetLogParams defaults to follow doc: stderr and LOG_INFO (mentioned in #391)
pinterf committed Apr 9, 2024

Add "continue" for for/while loops Implement #392
pinterf committed Apr 9, 2024

Fix: "break" to return up-to-date "last" in the expression chain
pinterf committed Apr 9, 2024

fix when building with absolute paths
jopejoe1 authored and qyot27 committed Feb 3, 2024

None of these are a fix for anything audio-related. 1 is related to pkg-config, 3 are related to script syntax constructs, 1 adjusts the defaults for logging, 1 is a documentation change, and 1 relates to string handling.



What everyone is actually comparing here - and a couple of the posts acknowledge this around the periphery without directly calling it out - are different compilers. Ubuntu uses GCC 13, which is unaffected. ClangCL and Intel are reported to be [mostly] unaffected. 3.7.3 was reported to be unaffected; it was built with MSVC 2019.

It's pointing at there being a problem with MSVC 2022, at least as of the time of the last test build having been built. In the time since, maybe the issue has been resolved with an update to the compiler, or it would produce a build of r4073 that's still affected by the same problem, even when all the other compilers produce working builds.

[gispos]

When will there be a final build of all the fixes that were included in post_test14?

[gispos]

Seems to be dying out here, unfortunately... :(

[BilboFett]

Seems to be dying out here, unfortunately... :(

I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.
What else do you hope for it to do? HDR processing or something?

[FranceBB]

HDR processing or something?


It already can handle pretty much everything in terms of HDR, from custom LUTs to tonemapping in any possible way etc. Heck, with frame properties we can even have dynamically changing metadata (like the brightness in nits) per single frame. I mean, in theory you could literally calculate and have the MaxCLL defined on a frame-by-frame basis and then perform dynamic tonemapping based on that. If anything, Avisynth is probably the best frameserver out there to handle HDR contents and has been on the forefront of innovation for a very long time.


I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.


Yep, yep, all this is true but this doesn't mean that innovation will stop. I'm sure Ferenc and Stephen will cook out a new release. :)

Let's take a look at the last few releases from 2019 to today:

AviSynth+ 3.7.3 - Jul 16, 2023
AviSynth+ 3.7.2 - Mar 18, 2022
AviSynth+ 3.7.1 - Jan 1, 2022
AviSynth+ 3.7.0 - Jan 11, 2021
AviSynth+ 3.6.1 - Jun 20, 2020
AviSynth+ 3.6.0 - May 20, 2020
AviSynth+ 3.5.1 - Apr 3, 2020
AviSynth+ 3.5.0 - Mar 3, 2020
AviSynth+ 3.4.0 - Oct 21, 2019

Leaving aside 2020 which was a bit weird being it the pandemic period, between March 18, 2022 and July 16, 2023, 485 days passed, so if we apply the same logic we can expect the future release to be:

AviSynth+ 3.7.4 - Nov 12, 2024

It's a long way 'till November.
Given that we're currently in August and that up until now we've had 70 commits shaping up 3.7.4 (https://github.com/AviSynth/AviSynthPlus/commits/master/?before=2b55ba40ec22652d72121fcef56b46da1fc2e427+70) I'd say that we're totally on track and we have nothing to worry about.
Mines are just speculations, but remember: in master Ferenc we trust. :D



EDIT: Uhhh, this is my 3000th post. It had to be special and I'm glad that it was about Avisynth, my favorite frameserver.

[gispos]

I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.
What else do you hope for it to do?
See, I'm too late... Almost forgot the Avisynth thread. :)
There are several reasons for my post.

I want to read something here again, this wish has been fulfilled. :) Thanks FranceBB

The official version contains bugs that can cause AvsPmod to crash when reinitializing a clip.
Many (new) users do not use the latest test version in which this bug has been fixed.

And last but not least, you can never have enough of good things.

[Guest]

I would just like to ask if anyone here knows why there seems to be issues when using Avisynth filters & scripts, that on CPU's over 12 cores, drop encoding speeds with x265 ??

Or is it x265 ??

[LigH]

I don't believe you can generalise that easily. Not without knowing your exact setup in detail.

In general, the speed of a well scalable encoder should increase with the number of cores, but not linearly, it will saturate. The efforts to manage more parallel calculations will increase. More calculations need to wait for intermediate results of others.

Similar for filtering: Parallel processing of video frames may reduce the scope of each thread, depending on the strategy how the material is split among the threads. Each thread needs its own copy of a filter to run, each copy needs RAM. In the special case of QTGMC, it may spawn multiple EDI filter threads per copy of the main routine, so the dependency on the number of cores squares if you don't limit EDIThreads. And when RAM is fully utilized by both Avisynth filters and the encoder (easily possible when encoding UHD video), Windows will start to use the swap file on disk which will delay the processing a lot...

[FranceBB]

Hey master Ferenc, I've got a reply from Olli Parviainen, the SoundTouch guy, about bumping the limit from 16ch to 32ch, thus allowing TimeStretch to handle more channels in Avisynth.
His reply is tracked here: Link (https://codeberg.org/soundtouch/soundtouch/issues/38) and he updated his repository after applying the following changes: Link (https://codeberg.org/soundtouch/soundtouch/commit/ddf28667c9f52f30573853c8177e77149829fa7c)
The latest master of SoundTouch with the relative changes is here: Link (https://codeberg.org/soundtouch/soundtouch/src/branch/master/source/SoundTouch)
As such, I've updated the issue I opened in July in the Avisynth repository about TimeStretch() failing when the clip had more than 16 audio channels Link (https://github.com/AviSynth/AviSynthPlus/issues/395)
As result, I opened the following pull request to implement the same changes Olli has done (kudos to him) in the local SoundTouch copy we have in Avisynth thus allowing TimeStretch() to process more than 16ch Link (https://github.com/AviSynth/AviSynthPlus/pull/397)
Hopefully, this change will make its way into the next AviSynth+ 3.7.4 release. That would make me extremely happy, but if not, it's not a big deal, we can wait until a new stable version of SoundTouch is released before the changes are implemented.
Either way, it's your call, you're the master (well, you and Stephen obviously :P ).

[FranceBB]

In Avisynth 3.7.3 r4066, when I use FadeIn() I get 2 extra frames, but when I use FadeOut() I only get 1 extra frame.

To reproduce:

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

trim(0, 100)

This will give you a 101 frames clip.

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

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

trim(0, 100)

FadeIn(1)


This will give you a 103 frames clip (2 frames are added).

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

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

trim(0, 100)

FadeOut(1)


This will give you a 102 frames clip (1 frame is added).

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


So the question is: why does FadeIn() add 2 frames, but FadeOut() only adds 1 frame? Shouldn't they both add 1 frame (or both 2 frames)?

[LigH]

Doesn't look like intended. But please compare also against Fade...[0|2].

[qyot27]

As also posted in the frame properties thread:

@qyot27

Would it be possible for AviSynth+ to pass a timecode file (VFR) to FFmpeg?

Nearly three years later...

$ ../ffmpeg_build/bin/ffmpeg -i test.avs -vf vfrdet -f null -
ffmpeg version N-117370-g8f3957c41c Copyright (c) 2000-2024 the FFmpeg developers
built with gcc 13 (Ubuntu 13.2.0-23ubuntu4)
libavutil 59. 41.100 / 59. 41.100
libavcodec 61. 21.100 / 61. 21.100
libavformat 61. 9.100 / 61. 9.100
libavdevice 61. 4.100 / 61. 4.100
libavfilter 10. 6.100 / 10. 6.100
libswscale 8. 4.100 / 8. 4.100
libswresample 5. 4.100 / 5. 4.100
libpostproc 58. 4.100 / 58. 4.100
Input #0, avisynth, from 'test.avs':
Duration: 00:03:16.95, start: -0.667000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 512x384, 21.83 fps, 29.97 tbr, 1k tbn
Stream #0:1: Audio: pcm_f32le, 24000 Hz, stereo, flt, 1536 kb/s
[Parsed_vfrdet_0 @ 0x5a1d9609e7c0] VFR:-nan (0/0)
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Stream #0:1 -> #0:1 (pcm_f32le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[out_#0:1 @ 0x79f294003140] The "all_channel_counts" option is deprecated: accept all channel counts
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf61.9.100
Stream #0:0: Video: wrapped_avframe, yuv420p(progressive), 512x384, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn
Metadata:
encoder : Lavc61.21.100 wrapped_avframe
Stream #0:1: Audio: pcm_s16le, 24000 Hz, stereo, s16, 768 kb/s
Metadata:
encoder : Lavc61.21.100 pcm_s16le
[Parsed_vfrdet_0 @ 0x79f29c002600] VFR:0.782667 (2348/652) min: 33 max: 668 avg: 47
[out#0/null @ 0x5a1d96b50f40] video:1289KiB audio:18402KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 3001 fps=0.0 q=-0.0 Lsize=N/A time=00:02:20.37 bitrate=N/A speed= 141x


To zero in on the important bits there (https://superuser.com/a/1487417):
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 512x384, 21.83 fps, 29.97 tbr, 1k tbn
...
[Parsed_vfrdet_0 @ 0x79f29c002600] VFR:0.782667 (2348/652) min: 33 max: 668 avg: 47

The very experimental FFmpeg test build:
ffmpeg_N-117370-g8f3957c41c.7z (https://www.mediafire.com/file/dcz6pin3s1zavh2/ffmpeg_N-117370-g8f3957c41c.7z/file)
Because the test build is intended to test the feature, vfr mode is enabled by default, but can be turned off by -avisynth_flags -vfr.

By 'very experimental' I mean that it comes with some very obvious issues that will need addressing. These are documented in the patch's commit message (https://github.com/qyot27/FFmpeg/commit/8f3957c41c1586badf9bb27090c240e52006fee8).

[Jamaika]

By 'very experimental' I mean that it comes with some very obvious issues that will need addressing. These are documented in the patch's commit message (https://github.com/qyot27/FFmpeg/commit/8f3957c41c1586badf9bb27090c240e52006fee8).

I don't like the structure of the avisynth .dll in static ffmpeg. So Windows says don't add viruses.
I removed shared .dll avisynthm but that doesn't apply to added plugins.
Since I removed the .dll avisynth, I had to adapt the plugins to C++11 or rather C++23 ffmpeg.

avisynth_c.cpp:2142:57: warning: narrowing conversion of '(unsigned int)avs->AviSynthContext::vi->AVS_VideoInfo::fps_numerator' from 'unsigned int' to 'int' [-Wnarrowing]
2142 | st->avg_frame_rate = (AVRational) { avs->vi->fps_numerator,
| ~~~~~~~~~^~~~~~~~~~~~~
avisynth_c.cpp:2143:57: warning: narrowing conversion of '(unsigned int)avs->AviSynthContext::vi->AVS_VideoInfo::fps_denominator' from 'unsigned int' to 'int' [-Wnarrowing]
2143 | avs->vi->fps_denominator };
| ~~~~~~~~~^~~~~~~~~~~~~~~

FFmpeg has a larger video decoder database than 5 years ago
No support for decoding AVI files in avisynth by ffmpeg
switch(pbiSrc->biCompression) {
case MAKEFOURCC('M','P','4','3'): // Microsoft MPEG-4 V3 '34PM'
case MAKEFOURCC('D','I','V','3'): // "DivX Low-Motion" (4.10.0.3917) '3VID'
case MAKEFOURCC('D','I','V','4'): // "DivX Fast-Motion" (4.10.0.3920) 4VID'
case MAKEFOURCC('A','P','4','1'): // "AngelPotion Definitive" (4.0.00.3688) '14PA'
if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
pbiSrc->biCompression = MAKEFOURCC('M', 'P', '4', '3');
if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
pbiSrc->biCompression = MAKEFOURCC('D', 'I', 'V', '3');
if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
pbiSrc->biCompression = MAKEFOURCC('D', 'I', 'V', '4');
if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
pbiSrc->biCompression = MAKEFOURCC('A', 'P', '4', '1');
default:
...
env->ThrowError("AVISource: couldn't locate a decompressor for fourcc %s", s);
Directshow is thrown into the trash. It is only under MSVC.

[poisondeathray]

ConvertToRGB / ConvertToPlanarRGB PC.Matrix bug introduced somewhere between r4003 to r4013

values greater than Y = 231 are shifted +1 during YUV (Y only, or YV12/YV16/YV24 variants tested) to RGB conversion using "PC" matrix 601/709 for "full range" conversion using either ConvertToRGB24 or ConvertToPlanarRGB matrix="pc.xx". Expected a 1:1 conversion eg. Y=235 (CbCr 128 for YV12/YV16/YV24 variants) would result in R=G=B=235

*But aliases matrix="709:f", or matrix="601:f" work ok

avsresize ok


r3996 ok
r4003 ok (3.7.3 final)
r4013 broken (20231019)
r4066 broken (20240131 last pinterf build)
r4073 broken (gitlab)

sample script


BlankClip(length=300, width=256, height=256, pixel_type="Y8", fps=29.97)
mt_lutspa(mode="relative closed", expr="x 255 *")
ConvertToRGB24(matrix="pc.601")
#ConvertToRGB24(matrix="601:f") #ok
#ConvertToPlanarRGB(matrix="pc.709")
#ConvertToPlanarRGB(matrix="709:f") #ok

ExtractR (or ExtractG, ExtractB)
THisto

function THisto(clip c, int "bits")
{
bits = Default(bits, 8)
c.TurnRight().Histogram(bits=bits).TurnLeft()
}



https://i.postimg.cc/BvZXkvJW/pc-matrix.png (https://postimages.org/)

[v0lt]

I have some old code - scripted_vdplugin (https://github.com/v0lt/scripted_vdplugin). It has a call IScriptEnvironment::GetVar("$PluginFunctions$") which doesn't seem to work as per the documentation I found (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#getvar). Is it outdated?

[StainlessS]

This any good to answer your question, (From RT_Stats v2 Beta 13, probably same in earlier version v1.xxx)

From RT_Odds.cpp

AVSValue __cdecl RT_PluginDir(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_PluginDir: ";
char * varname="$PluginDir$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}

AVSValue __cdecl RT_PluginFunctions(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_PluginFunctions: ";
char * varname="$PluginFunctions$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}

AVSValue __cdecl RT_InternalFunctions(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_InternalFunctions: ";
char * varname="$InternalFunctions$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}


AVSValue __cdecl RT_ScriptName(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_ScriptName: ";
char * varname="$ScriptName$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}

AVSValue __cdecl RT_ScriptFile(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_ScriptFile: ";
char * varname="$ScriptFile$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}

AVSValue __cdecl RT_ScriptDir(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_ScriptDir: ";
char * varname="$ScriptDir$";
char *ps;
try {
AVSValue var = env->GetVar(varname);
if(!var.IsString()) {
env->ThrowError("%s Var '%s' is not a string",myName,varname);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
return env->SaveString(ps);
}


AVSValue __cdecl RT_PluginParam(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_PluginParam: ";
const char *s=args[0].AsString();
int len = int(strlen(s));
char *bf = new char[len + 16];
if(bf==NULL) env->ThrowError("%sCannot allocate memory",myName);
strcpy(bf,"$Plugin!");
strcat(bf,s);
strcat(bf,"!Param$");
char *ps;
try {
AVSValue var = env->GetVar(bf);
if(!var.IsString()) {
delete [] bf;
env->ThrowError("%s Var '$Plugin!%s!Param$' is not a string",myName,s);
}
ps = (char*)var.AsString();
} catch (IScriptEnvironment::NotFound) {
ps="";
}
delete [] bf;
return env->SaveString(ps);
}


Above code worked for a long time, I presume that it still does.

EDIT: I think Pinterf made some changes couple of years ago, maybe broke something. [EDIT: I seem to recall that he did something I did not like too much]

EDIT:
Here a small Snippet from Gavino for use in avisynth.

AVSValue __cdecl GetVar(IScriptEnvironment* env, const char* name) {
try {return env->GetVar(name);} catch (IScriptEnvironment::NotFound) {} return AVSValue();
}

[StainlessS]

This still seems to work, uses RT_Stats functions


# Make_Avisynth_BuiltIn_FunctionList.avs by StainlessS.
# Requires either Avs+ or GScript.

ORDER=True

HEAD="""
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
###################################
"""
myName="Make_Avisynth_BuiltIn_FunctionList: "
IsAvsPlus = (FindStr(VersionString, "AviSynth+")>0 || FindStr(VersionString, "AviSynth Neo")>0)
HasGScript=RT_FunctionExist("GScript")
Assert(IsAvsPlus || HasGScript,RT_String("%sNeed either GScript or AVS+",myName))
ALL_PLUGS = RT_StrReplace(RT_InternalFunctions," ",Chr(10))
LINES = RT_TxtQueryLines(ALL_PLUGS)
PLUGS = ""
PARMS = ""
MaxLen = 0
DQUOT=34 # Double Quote Chr(34)
GS="""
for(i=0,LINES-1) {
PLG=RT_TxtGetLine(ALL_PLUGS,Line=i)
MaxLen=Max(MaxLen,StrLen(PLG))
PARAM=RT_PluginParam(PLG)
PLUGS=RT_TxtAddStr(PLUGS,PLG)
PARMS=RT_TxtAddStr(PARMS,RT_String(" %c%s%c",DQUOT,PARAM,DQUOT))
}
PLUGS_AND_PARMS=""
for(i=0,LINES-1) {
PLUGS_AND_PARMS=RT_TxtAddStr(PLUGS_AND_PARMS,RT_StrPad(RT_TxtGetLine(PLUGS,Line=i),MaxLen)+RT_TxtGetLine(PARMS,Line=i))
}
"""
HasGScript ? GScript(GS) : Eval(GS) # Use GScript if installed (loaded plugs override builtin)

PLUGS_AND_PARMS = (ORDER) ? RT_TxtSort(PLUGS_AND_PARMS) : PLUGS_AND_PARMS # Order Alphabetical
FND_S=RT_string(" \n:\n-\n\\\n/\n")
REP_S=RT_string("_\n_\n_\n_\n_\n")
VER = RT_StrReplaceMulti(VersionString,FND_S,REP_S)
TXT = VER
INTERN=RT_String("_%sFunction_List",(ORDER)?"ORDERED_":"")
FN = TXT+INTERN+".TXT"
S=RT_String("\n %s%s\n\n%s\n\n%s",VER,INTERN,HEAD,PLUGS_AND_PARMS)
RT_WriteFile(FN,S)
S2=RT_String("\n\n%s\n\nCreated in current directory\n",FN)
S=RT_TxtAddStr(S,S2)
W=1280 H=640 LINES=RT_TxtQueryLines(S)
L= LINES*20 + H + 100
Global Glb_S=S # Avisynth NEO fix
BlankClip(Width=W,Height=H,Length=L).ScriptClip("""RT_Subtitle("%s",Glb_S,x=10,y=height+100-current_frame,expx=true,expy=true)""")


Produces a scrolling video clip, here a single frame from it
[ClickMe]
https://i.postimg.cc/w1QZjtx7/Make-Avisynth-Built-In-Function-List-00.jpg (https://postimg.cc/w1QZjtx7)

EDIT: 3 scripts:- https://www.mediafire.com/file/8uk4tdc1o65s0in/FunctionLists.zip/file

EDIT: Previous script as well as scrolling video clip, outputs txt file to script directory,
here some of it, builtin A,B,and C, functions (no header).


abs "f"
abs "f"
acos "f"
AddAlphaPlane "c[mask]."
AddAutoloadDir "s[toFront]b"
AddBorders "ciiiii[color_yuv]i"
AlignedSplice "cci"
AlignedSplice "cci"
Amplify "cf+"
AmplifydB "cf+"
Animate "ciis.*"
Animate "ciis.*"
Apply "s.*"
ApplyRange "ciis.*"
Array ".*"
ArrayAdd "..i*"
ArrayDel ".i+"
ArrayGet ".i+"
ArrayGet ".i+"
ArrayIns "..i+"
ArraySet "..i+"
ArraySize "."
asin "f"
Assert "s"
Assert "s"
AssumeBFF "c"
AssumeFieldBased "c"
AssumeFPS "cc[sync_audio]b"
AssumeFPS "cc[sync_audio]b"
AssumeFPS "cc[sync_audio]b"
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"
audiolength "c"
audiolengthf "c"
audiolengthhi "c[]i"
audiolengthlo "c[]i"
audiolengths "c"
audiorate "c"
AudioTrim "cf[end]f[cache]b"
AudioTrim "cf[end]f[cache]b"
AudioTrim "cf[end]f[cache]b"
AudioTrim "cf[end]f[cache]b"
AutoloadPlugins ""
AverageA "c[offset]i"
AverageB "c[offset]i"
AverageChromaU "ci"
AverageChromaV "ci"
AverageG "c[offset]i"
AverageLuma "ci"
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"
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"
bitand "ii"
bitchange "ii"
bitchg "ii"
bitclear "ii"
bitclr "ii"
bitlrotate "ii"
bitlshift "ii"
bitlshifta "ii"
bitlshiftl "ii"
bitlshifts "ii"
bitlshiftu "ii"
bitnot "i"
bitor "ii"
bitrol "ii"
bitror "ii"
bitrrotate "ii"
bitrshifta "ii"
bitrshiftl "ii"
bitrshifts "ii"
bitrshiftu "ii"
bitsal "ii"
bitsar "ii"
bitset "ii"
bitsetcount "i+"
bitshl "ii"
bitshr "ii"
BitsPerComponent "c"
bittest "ii"
bittst "ii"
bitxor "ii"
BlackmanResize "cii[src_left]f[src_top]f[src_width]f[src_height]f[taps]i"
Blackness "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c"
Blackness "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c"
BlankClip "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]f+"
BlankClip "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]f+"
BlankClip "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]f+"
BlankClip "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]f+"
Blur "cf[]f[mmx]b"
Bob "c[b]f[c]f[height]i"
BPlaneMax "c[threshold]f[offset]i"
BPlaneMedian "c[offset]i"
BPlaneMin "c[threshold]f[offset]i"
BPlaneMinMaxDifference "c[threshold]f[offset]i"
BuildPixelType "[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"
Cache "c[name]s"
ceil "f"
ChangeFPS "cc[linear]b"
ChangeFPS "cc[linear]b"
ChangeFPS "cc[linear]b"
ChangeFPS "cc[linear]b"
Chr "i"
ChromaUDifference "cci"
ChromaVDifference "cci"
ClearAutoloadDirs ""
ColorBars "[width]i[height]i[pixel_type]s[staticframes]b"
ColorBarsHD "[width]i[height]i[pixel_type]s[staticframes]b"
ColorKeyMask "ci[]i[]i[]i"
ColorSpaceNameToPixelType "s"
ColorYUV "c[gain_y]f[off_y]f[gamma_y]f[cont_y]f[gain_u]f[off_u]f[gamma_u]f[cont_u]f[gain_v]f[off_v]f[gamma_v]f[cont_v]f[levels]s[opt]s[matrix]s[showyuv]b[analyze]b[autowhite]b[autogain]b[conditional]b[bits]i[showyuv_fullrange]b[f2c]b[condvarsuffix]s[optForceUseExpr]b"
CombinePlanes "cccc[planes]s[source_planes]s[pixel_type]s[sample_clip]c"
CombinePlanes "cccc[planes]s[source_planes]s[pixel_type]s[sample_clip]c"
CombinePlanes "cccc[planes]s[source_planes]s[pixel_type]s[sample_clip]c"
CombinePlanes "cccc[planes]s[source_planes]s[pixel_type]s[sample_clip]c"
Compare "cc[channels]s[logfile]s[show_graph]b"
ComplementParity "c"
ComponentSize "c"
ConditionalFilter "cccs[showx]b[args]s[local]b"
ConditionalFilter "cccs[showx]b[args]s[local]b"
ConditionalFilter "cccs[showx]b[args]s[local]b"
ConditionalReader "css[show]b[condvarsuffix]s[local]b"
ConditionalSelect "cnc+[show]b[local]b"
ConditionalSelect "cnc+[show]b[local]b"
ContinuedDenominator "f[]i[limit]i"
ContinuedNumerator "f[]i[limit]i"
ConvertAudio "cii"
ConvertAudioTo16bit "c"
ConvertAudioTo24bit "c"
ConvertAudioTo32bit "c"
ConvertAudioTo8bit "c"
ConvertAudioToFloat "c"
ConvertBackToYUY2 "c[matrix]s"
ConvertBits "c[bits]i[truerange]b[dither]i[dither_bits]i[fulls]b[fulld]b"
ConvertFPS "cc[zone]i[vbi]i"
ConvertFPS "cc[zone]i[vbi]i"
ConvertFPS "cc[zone]i[vbi]i"
ConvertFPS "cc[zone]i[vbi]i"
ConvertTo16bit "c[bits]i[truerange]b[dither]i[dither_bits]i[fulls]b[fulld]b"
ConvertTo8bit "c[bits]i[truerange]b[dither]i[dither_bits]i[fulls]b[fulld]b"
ConvertToFloat "c[bits]i[truerange]b[dither]i[dither_bits]i[fulls]b[fulld]b"
ConvertToMono "c"
ConvertToPlanarRGB "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToPlanarRGBA "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToRGB "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToRGB24 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToRGB32 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToRGB48 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToRGB64 "c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToY "c[matrix]s"
ConvertToY8 "c[matrix]s"
ConvertToYUV411 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToYUV420 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYUV422 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYUV444 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToYUVA420 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYUVA422 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYUVA444 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToYUY2 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToYV12 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYV16 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s[param1]f[param2]f[param3]f"
ConvertToYV24 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
ConvertToYV411 "c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f"
cos "f"
cosh "f"
Crop "ciiii[align]b"
CropBottom "ci"


EDIT:
NOTE, where there is a function that takes multiple sets of argument lists [eg Abs(int), Abs(Float)], we can only
return the first argument list, there is no way to extract subsequent arg lists external to avisynth itself.
See the duplicated [COLOR="Blue"]abs "f" at beginning of above output text file.

[v0lt]

This any good to answer your question, (From RT_Stats v2 Beta 13, probably same in earlier version v1.xxx)

From RT_Odds.cpp
I have very similar code and it doesn't work.
EDIT: 3 scripts:- https://www.mediafire.com/file/8uk4tdc1o65s0in/FunctionLists.zip/file

EDIT: Previous script as well as scrolling video clip, outputs txt file to script directory,
here some of it, builtin A,B,and C, functions (no header).
Script error: There is no function named 'RT_FunctionExist'.

AviSynth+ 3.7.3 (r4003, 3.7, x86_64)

Added:
FunctionLists scripts work (RT_Stats_x64.dll was needed).
FSEL_Make_PluginFunctionList.AVS works only for the selected plugin.

[Jamaika]

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.

I'm testing latest avisynth with latest ffmpeg in GNU 11.5.0 SIMD AVX2. What surprises me?
I realize that this isn't paid editor with video effects.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/f41e8d511be8dd124b91e3502dfa128d190e78fb
https://github.com/l-smash/l-smash/commit/18a9ed25c7ff79a7f4f4bf850c345c72179b8998
https://github.com/AviSynth/AviSynthPlus/commit/b7dbabd0c6bd2069e2bb2d31c127622a8b919d06
https://github.com/FFmpeg/FFmpeg/commit/7b20985d8d886fb32badc94f8d210bb596b19c2d

Why do I have to think about framerate?
NOTE: You must explicitly set this if the source is an AVI file that contains null/drop frames that you would like to keep. For
example, AVI files captured using VirtualDub commonly contain null/drop frames that were inserted during the capture process.
Unless you provide this parameter, these null frames will be discarded, commonly resulting in loss of audio/video sync.

Why do I have to convert lossy AVI files in ffmpeg (XviD, X264) so ​​that the LWLibavVideoSource plugin doesn't stutter?
ffmpeg_avx2.exe -i myAvi.avi -c:v libx264 -c:a mp3 -vb 850k -ab 128k 111.avi

LWLibavVideoSource("111.avi", stream_index=-1, cache=true , seek_mode=0, ff_loglevel=6, format="YUV420P8" ).selectevery(2,0)


Edit:
Which library is up to date and correct today. Because I see on github https://github.com/Mr-Ojii/L-SMASH-Works
There are also other git libraries.

Is this necessary? https://github.com/rwxPOPn/LSW-FFmpeg/commit/1e932fce0dbb1d5657ca54cedd51180a8f11e5fc


Converter ffmpeg 7.1.0
https://www.sendspace.com/file/hxbjj5

Source video
https://www.sendspace.com/file/jtjvyv

???
if( codec->pix_fmts )
codecpar->format = (int)avcodec_find_best_pix_fmt_of_list( codec->pix_fmts, pix_fmt, 1, NULL );

c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\lwlibavsource_x64.a(lwlibav_video.o):lwlibav_video.:(.text+0x3263): undefined reference to `avcodec_find_best_pix_fmt_of_list'

qsv.c: In function 'is_qsv_decoder':
qsv.c:45:5: warning: 'pix_fmts' is deprecated [-Wdeprecated-declarations]
45 | if( codec && codec->pix_fmts )
| ^~
In file included from c:\gcc1150\x86_64-w64-mingw32\include\libavcodec\avcodec.h:41,
from qsv.c:31:
c:\gcc1150\x86_64-w64-mingw32\include\libavcodec\codec.h:215:31: note: declared here
215 | const enum AVPixelFormat *pix_fmts; ///< @deprecated use avcodec_get_supported_config()
| ^~~~~~~~

Test: https://github.com/Mr-Ojii/L-SMASH-Works
Assertion failed: IsString(), file interface.cpp, line 836B

[LigH]

Please note that Jamaika statically compiles Avisynth+ into ffmpeg as internal demultiplexer, instead of using it as DLL installed in the system.

So I would not be surprised if there are competing file access, seeking, caching routines; but I have no clue.

[StainlessS]

I have very similar code and it doesn't work.
See the EDIT in post #2875, ie,
EDIT:
Here a small Snippet from Gavino for use in avisynth.

AVSValue __cdecl GetVar(IScriptEnvironment* env, const char* name) {
try {return env->GetVar(name);} catch (IScriptEnvironment::NotFound) {} return AVSValue();
}

Think you need that. [Very useful function. Dont think it exists in RT_Odds.cpp, is in some other src file as used throughout RT_Stats.]

FSEL_Make_PluginFunctionList.AVS works only for the selected plugin
Yes, as intended. [EDIT: You have to select the plugin to load so that it is force loaded, otherwise is only loaded by avisynth if used in script (its something like that, I think)]

Sorry about delay, I did not see your reply.

[wonkey_monkey]

There's a problem with FadeIn (http://avisynth.nl/index.php/Fade). It's adding 2 blank frames to the start of a clip instead of (as stated on the wiki page) just 1.

Edit: I see FranceBB already reported it: https://forum.doom9.org/showthread.php?p=2007314#post2007314


version # 240 frames
version.fadein(10) # 242 frames (should be 241)
version.fadeout(10) # 241 frames
version.fadeio(10) # 242 frames


The error is on line 84 of edit.cpp, which reads:

{ "FadeIn", BUILTIN_FUNC_PREFIX, "ci[color]i[fps]f[color_yuv]i[colors]f+", Create_Fade, (void*)FADE_MODE_IN2 },

but presumably should read:

{ "FadeIn", BUILTIN_FUNC_PREFIX, "ci[color]i[fps]f[color_yuv]i[colors]f+", Create_Fade, (void*)FADE_MODE_IN },

https://github.com/AviSynth/AviSynthPlus/commit/5e10f9879b9b5c4538ce63b708ca2d5c047db941#diff-e23d6ff7c1f32b342b53a537e35cf66762e2eaec3b7a6995a1e32cd637d7a18aL82

Handy replacement function that works around the error and should continue to work as expected after it is fixed:

function RealFadeIn(clip a, n) {
x = a.framecount
f = FadeIn(a, n)
y = f.framecount
return f.trim(y - x - 1, 0)
}

[qyot27]

Looks like it was simply a copy-paste typo. Fixed in 81b564fc (https://github.com/AviSynth/AviSynthPlus/commit/81b564fc406c86a87755f7ad26dc29b81248b4ff).

[FranceBB]

Thank you Stephen, as always! :)
Given that we're in December already, I gotta pop the question: are we gonna find Avisynth 3.7.4 under the Christmas Tree?

[tormento]

are we gonna find Avisynth 3.7.4 under the Christmas Tree?
And possibily an official ICC build ;)

[pinterf]

Test with some player options:
r4073 r4066
------------------ ------------------
Player without Normalize without Normalize
--------------------- ------- --------- ------- ---------
mpc-hc 2.3.2 DirectS Ok Noise Noise Noise
mpc-hc 2.3.2 + SaneAR Ok Ok Ok Noise
VirtualDub2 2.1.1.607 Ok Ok Ok Noise
mpc-be 1.7.1 MPC-Aud Ok Ok Ok Ok
mpc-be 1.7.1 DirectS Ok Ok Ok Noise
vlc 3.0.21 Ok Ok Ok Noise

@pinterf
Maybe we need a new test15 and/or a new release 3.7.4, the 3.7.3 is 1 year old.

What is the latest status of this distortion bug?
edit: yes, I know I'm a bit late :)

[pinterf]

Thank you Stephen, as always! :)
Given that we're in December already, I gotta pop the question: are we gonna find Avisynth 3.7.4 under the Christmas Tree?
No one shall tell the future. :)

[pinterf]

ConvertToRGB / ConvertToPlanarRGB PC.Matrix bug introduced somewhere between r4003 to r4013

values greater than Y = 231 are shifted +1 during YUV (Y only, or YV12/YV16/YV24 variants tested) to RGB conversion using "PC" matrix 601/709 for "full range" conversion using either ConvertToRGB24 or ConvertToPlanarRGB matrix="pc.xx". Expected a 1:1 conversion eg. Y=235 (CbCr 128 for YV12/YV16/YV24 variants) would result in R=G=B=235

*But aliases matrix="709:f", or matrix="601:f" work ok

sample script


BlankClip(length=300, width=256, height=256, pixel_type="Y8", fps=29.97)
mt_lutspa(mode="relative closed", expr="x 255 *")
ConvertToRGB24(matrix="pc.601")
#ConvertToRGB24(matrix="601:f") #ok
#ConvertToPlanarRGB(matrix="pc.709")
#ConvertToPlanarRGB(matrix="709:f") #ok

ExtractR (or ExtractG, ExtractB)
THisto

function THisto(clip c, int "bits")
{
bits = Default(bits, 8)
c.TurnRight().Histogram(bits=bits).TurnLeft()
}




There was a change, indeed in this commit:

https://github.com/AviSynth/AviSynthPlus/commit/184eebe886352a1c1ce3041af89a84dc407e2297
"Keep "_ColorRange" value on ConvertToRGBxx for "PC.709" or "PC.601";"

Referring to a longer conversation, one of my comments (https://github.com/AviSynth/AviSynthPlus/issues/354#issuecomment-1584579548)on this specific topic.

Without telling whether it is full or limited, it will just do the matrix multiplication, assuming a default full or limited range, (dunno, what it is when a greyscale is inputted).

Just because it is called "PC" matrix, it does not imply anything of the conversion full or limited behaviour, a source frame property, or the :f hint can help with it.

[qyot27]

What is the latest status of this distortion bug?
edit: yes, I know I'm a bit late :)
Compiler issue. I believe all the problematic builds were built with VS 2022, the ones that worked correctly were the VS 2019 builds. At best, there might have been a change at a certain point between 3.7.3 and HEAD that simply exposed the problem in VS 2022, but if it was compiler-side, further updates *might* have already resolved it.

[Jamaika]

Matrix functions are inactive.
Avisynth function: LWLibavVideoSource [AudioBoost.avi, 5]
[avi @ 000002122a221b70] non-interleaved AVI
Avisynth function: ConvertToYUV422 [2020ncl:l]
Input #0, avisynth, from 'AudioBoost.avs':
Duration: N/A, start: 0.040000, bitrate: N/A
Stream #0:0: Video: rawvideo (Y42B / 0x42323459), yuv422p(progressive), 592x336, 25 fps, 25 tbr, 1k tbn

Matrix functions are active.
Avisynth function: LWLibavVideoSource [AudioBoost.avi, 5]
[avi @ 000001cd54dc5c40] non-interleaved AVI
Avisynth function: z_ConvertFormat [RGBP10, 2020ncl:st2084:2020:l=>rgb:linear:2020:f, none]
Input #0, avisynth, from 'AudioBoost.avs': 0KB sq= 0B
Duration: 00:00:04.00, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (G3[0][10] / 0xA003347), gbrp10le(pc, gbr/bt2020/linear), 592x336, 25 fps, 25 tbr, 25 tbn

[pinterf]

Compiler issue. I believe all the problematic builds were built with VS 2022, the ones that worked correctly were the VS 2019 builds. At best, there might have been a change at a certain point between 3.7.3 and HEAD that simply exposed the problem in VS 2022, but if it was compiler-side, further updates *might* have already resolved it.

How I love debugging non-debuggable release versions! I went down the rabbit hole and examined the disassembly list.

I then successfully created an ultra-minimal bug demo for Microsoft and reported the issue to them.

https://github.com/pinterf/msvc_bad_codegen_demo_2

Edit: ... and the issue report
https://developercommunity.visualstudio.com/t/Bad-code-gen-with-inlined-functions-with/10813706

[tormento]

I then successfully created an ultra-minimal bug demo for Microsoft and reported the issue to them.[/url]
I told you to use ICC. :p

[pinterf]

I told you to use ICC. :p
There were times when I found bug in LLVM generated code as well.

[Jamaika]

By 'very experimental' I mean that it comes with some very obvious issues that will need addressing. These are documented in the patch's commit message (https://github.com/qyot27/FFmpeg/commit/8f3957c41c1586badf9bb27090c240e52006fee8).

There is mistake here:
/* Variable frame rate */
if(avs->flags & AVISYNTH_FRAMEPROP_VFR) {
if((avs_prop_get_type(avs->env, avsmap, "_DurationDen") != AVS_PROPTYPE_UNSET) ||
(avs_prop_get_type(avs->env, avsmap, "_DurationNum") != AVS_PROPTYPE_UNSET)) {
avs->is_vfr = false;
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator, avs->vi->fps_numerator);
} else {
avs->is_vfr = true; <-- false for ColorBars
avpriv_set_pts_info(st, 64, 1, 1000);
}
} else {
avs->is_vfr = false;
avpriv_set_pts_info(st, 32, avs->vi->fps_denominator, avs->vi->fps_numerator);
}

Now l-smash works.

Inactive feature in ffmpeg. Is it unnecessary in l-smash? And I guess there are mistakes here too.

env->propSetFloat(props, "_AbsoluteTime", static_cast<double>(n * duration_num) / duration_den, 0);
...
env->propSetData(props, "_PictType", &pict_type, 1, 0);
...
env->propSetInt(props, "_EncodedFrameTop", top, 0);
env->propSetInt(props, "_EncodedFrameBottom", bottom, 0);
...
env->propSetFloatArray(props, "MasteringDisplayPrimariesX", display_primaries_x, 3);
env->propSetFloat(props, "MasteringDisplayWhitePointX", av_q2d(mastering_display->white_point[0]), 0);
env->propSetFloat(props, "MasteringDisplayMinLuminance", av_q2d(mastering_display->min_luminance), 0);
env->propSetInt(props, "ContentLightLevelMax", content_light->MaxCLL, 0);
env->propSetInt(props, "ContentLightLevelAverage", content_light->MaxFALL, 0);
...
env->propSetData(props, "DolbyVisionRPU", reinterpret_cast<const char*>(rpu_side_data->data), rpu_side_data->size, 0);

https://www.sendspace.com/file/6t712w

Testing
https://github.com/captainadamo/descratch
ConvertToYV12()
descratch(mindif=4, maxgap=20, minlen=300, blurlen=50, keep=100, border=0, maxangle=0)
??? Error: ???

http://avisynth.nl/index.php/RgTools/Repair
ConvertToYV12(Unprocessed, matrix="rec709")
Processed = RemoveGrain(Unprocessed, mode=2, modeU=2, modeV=2, planar=false)
Repair(Processed, Unprocessed, mode=2, modeU=2, modeV=2, planar=false)
[avisynth @ 00000233127ea140] RemoveGrain works only with planar colorspaces

TemporalRepair(Processed2, Unprocessed, mode=0, grey=false, planar=true)
Weird screenshot

I don't know how to use the plugin.
http://avisynth.nl/index.php/RemoveGrainHD

Test wiki vapoursynth function
vsCnr2(mode="oxx", scdthr=10.0, ln=35, lm=192, un=47, um=255, vn=47, vm=255, sceneChroma=false)
vsDeblockPP7(qp=2.0, mode=0, y=3, u=3, v=3)
vsDeGrainMedian(limitY=4, limitU=4, limitV=4, modeY=1, modeU=1, modeV=1, interlaced=false, norow=false, opt=-1)
vsLGhost(mode=[2, 2, 1, 1], shift=[4, 7, -4, -7], intensity=[20, 10, -15, -5])
vsMSmooth(threshold=6.0, strength=3.0, mask=false, luma=true, chroma=false)
vsTBilateral vsTBilateral (diameterY=5, diameterU=5, diameterV=5, sdevY=1.4, sdevU=1.4, sdevV=1.4, idevY=7.0, idevU=7.0, idevV=7.0, csY=1.0, csU=1.0, csV=1.0, d2=false, kerns=2, kerni=2, restype=0, y=3, u=3, v=3)
vsTCanny(sigmaY=1.50, sigmaU=0.75, sigmaV=0.75, sigma_vY=1.50, sigma_vU=0.75, sigma_vV=0.75, t_h=8.0, t_l=1.0, mode=0, op=1, scale=1.0, y=3, u=3, v=3, opt=-1)
vsTEdgeMask (threshY=8.0, threshU=8.0, threshV=8.0, type=2, link=1, scale=1.0, y=1, u=1, v=1, opt=-1)
vsTMM vsTMM(order=-1, field=-1, mode=0, length=10, mtype=1, ttype=1, mtql=-1, mthl=-1, mtqc=-1, mthc=-1, nt=2, minthresh=4, maxthresh=75, cstr=4, athresh=-1, metric=0, expand=0, link=true, binary=false, eight=false, y=1, u=1, v=1, opt=-1)
vsTTempSmooth(maxr=3, ythresh=4, uthresh=5, vthresh=5, ymdiff=2, umdiff=3, vmdiff=3, strength=2, scthresh=12.0, fp=true, y=3, u=3, v=3)

Test https://github.com/pinterf/amDCT
amDCTmain.cpp: In function 'int amDCTmain(const uint8_t*, uint8_t*, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int, int)':
amDCTmain.cpp:170:14: warning: comparison is always false due to limited range of data type [-Wtype-limits]
170 | if (matrix > 255) matrix = 255;
| ~~~~~~~^~~~~
amDCTmain.cpp:174:19: warning: comparison is always false due to limited range of data type [-Wtype-limits]
174 | if (brightStart > 255) brightStart = 255;
| ~~~~~~~~~~~~^~~~~
amDCTmain.cpp:176:17: warning: comparison is always false due to limited range of data type [-Wtype-limits]
176 | if (darkStart > 255) darkStart = 255;
| ~~~~~~~~~~^~~~~
amDCTmain.cpp:179:10: warning: comparison is always false due to limited range of data type [-Wtype-limits]
179 | if (T2 > 255) T2 = 255;
| ~~~^~~~~
amDCTmain.cpp:180:16: warning: comparison is always false due to limited range of data type [-Wtype-limits]
180 | if (showMask > 255) showMask = 255;
| ~~~~~~~~~^~~~~
avgDctLoop.cpp: In function 'uint8_t avgDctLoopAccumSmoothed(FrameInfo_args*)':
avgDctLoop.cpp:576:17: warning: comparison is always false due to limited range of data type [-Wtype-limits]
576 | if (maxSmooth > 255) maxSmooth = 255;
| ~~~~~~~~~~^~~~~
MaxMinFilter.cpp: In function 'void sadWindowH(uint8_t*, uint8_t*, uint8_t*, uint16_t, uint16_t, uint8_t)':
MaxMinFilter.cpp:88:16: warning: comparison is always false due to limited range of data type [-Wtype-limits]
88 | if (temp < 0) temp = 0;
| ~~~~~^~~
Sharp.cpp: In function 'int Sharp(FrameInfo_args*, int)':
Sharp.cpp:138:19: warning: comparison is always false due to limited range of data type [-Wtype-limits]
138 | if (sharpWPos < 0 || sharpWPos >= 8) {
| ~~~~~~~~~~^~~
Sharp.cpp:150:18: warning: comparison is always false due to limited range of data type [-Wtype-limits]
150 | if (blkCol < 0 || blkCol >= 8) continue; // Safety check to keep lint happy.
| ~~~~~~~^~~
transfer_add.cpp: In function 'void copy_add_16to16_clpsrc_c(uint16_t*, int16_t*, uint32_t)':
transfer_add.cpp:96:13: warning: comparison is always false due to limited range of data type [-Wtype-limits]
96 | if (i < 0) i = 0;
| ~~^~~

[poisondeathray]

There was a change, indeed in this commit:

https://github.com/AviSynth/AviSynthPlus/commit/184eebe886352a1c1ce3041af89a84dc407e2297
"Keep "_ColorRange" value on ConvertToRGBxx for "PC.709" or "PC.601";"

Referring to a longer conversation, one of my comments (https://github.com/AviSynth/AviSynthPlus/issues/354#issuecomment-1584579548)on this specific topic.

Without telling whether it is full or limited, it will just do the matrix multiplication, assuming a default full or limited range, (dunno, what it is when a greyscale is inputted).

Just because it is called "PC" matrix, it does not imply anything of the conversion full or limited behaviour, a source frame property, or the :f hint can help with it.


Then it's not really the "same" thing as described in the wiki - because the behaviour is different between the "aliases" . Also the behaviour is different for old scripts.

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


e.g. "709:f" means the same as the old "PC.709"




Note: old-style "matrix" parameters are kept, their name indicate the full/limited

For memo and the similar new string

"pc.601" and "pc601" "470bg:f"
"pc.709" and "pc709" "709:f"




If you explicitly set the prop before ConvertToRGB24(matrix="pc.709") , the "full" gives the expected result

propSet("_ColorRange",0) # full, expected results

propSet("_ColorRange",1) # limited, unexpected results


But limited or unset is very different than what avsresize produces. I don't know why that notch is there . If you set the prop to limited, you would have expected a Limited range YUV to full range RGB conversion

Something like this

z_ConvertFormat(pixel_type="RGBP8",colorspace_op="709:709:709:l=>rgb:709:709:f")



Perhaps some notation like avsresize, or fmtc - where source/destination are explicitly specified; I'm just thinking out loud

[pinterf]

Then it's not really the "same" thing as described in the wiki - because the behaviour is different between the "aliases" . Also the behaviour is different for old scripts.

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


You are right, the documentation is misleading, seems we were not aware of the original behavior of PC.709 matrix and did not fix that sentence

This is the old (true) text:
"The special-purpose matrices PC.601 and PC.709 keep the range unchanged, instead of converting between 0d-255d RGB and 16d-235d YUV, as is the normal practice."

And this is how I added my lines to the wiki:
e.g. "709:f" means the same as the old "PC.709"
Obviously this - and the other line, mentioning the aliases - is what misled you. It has to be fixed...
(For myself. I don't even find these additions on our - otherwise much more up-to-date - documentation page (https://avisynthplus.readthedocs.io/en/latest/)

When there is no frame property, nor :f or :l hint given, then the default range is guessed as "limited" for Y and YUV, and "full" for RGB.

[hello_hello]

A blank clip and color range question.

When a full range YUV clip is used to specify the properties for a blank clip, should the resulting blank clip be full range? Currently it's limited range.
For example:

A = YUVclip.ConvertBits(fulls=false, fulld=true)
BlankClip(A)

[Jamaika]

A blank clip and color range question.

When a full range YUV clip is used to specify the properties for a blank clip, should the resulting blank clip be full range? Currently it's limited range.
For example:

A = YUVclip.ConvertBits(fulls=false, fulld=true)
BlankClip(A)
I am not creator. Don't believe anyone. Test it yourself to see how it works.

http://avisynth.nl/index.php/ConvertBits
ConvertBits(truerange=true, dither=-1, dither_bits=3, fulls=true, fulld=false)
Changes bit depth while keeping color format the same, if possible.
If the conversion is not possible – for example, converting RGB32 to 14bit – an error is raised.
Avisynth function: LWLibavVideoSource [input_rgba/rgb24.avi, 30000, 1001]
Avisynth function: ConvertBits [true, -1, 3, true, false]
[avisynth @ 000002abd655b120] ConvertBits: truerange specified for non-planar source
Hint: forget it. Deprecated, do not use. Maybe once removed.
When converting from true 10-16 bit formats, truerange=false indicates bitdepth of 16 bits regardless of the 10-12-14 bit format. Not applicable for non planar formats.
I don't know what this is about. When truerange is false then colorrange is unknown no matter what you set in fulls or fulld.
I understand that the function is only for 8bit movies. I have no bad information about pixel_format. When truerange is true then you can convert colorrange limited to full (this is lying in practice) and full to limited.
Avisynth function: LWLibavVideoSource [input_v210.avi, 30000, 1001]
Avisynth function: ConvertBits [true, -1, 3, true, false]
Input #0, avisynth, from 'AudioBoost.avs': 0KB sq= 0B
Duration: 00:00:33.40, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[10][10] / 0xA0A3359), yuv422p10le(tv, progressive), 1280x720, 29.97 fps, 29.97 tbr, 29.97 tbn
When ConvertBits doesn`t convert fulld from fulls then colorrange is unknown.

[pinterf]

As it says.
Forget about this 'truerange' parameter. I even removed it from the latest documentation.

As to BlankClip: it only inherits the color format and the dimensions.

[hello_hello]

ConvertBits: truerange specified for non-planar source
Hint: forget it. Deprecated, do not use. Maybe once removed.
When converting from true 10-16 bit formats, truerange=false indicates bitdepth of 16 bits regardless of the 10-12-14 bit format. Not applicable for non planar formats.
I don't know what this is about. When truerange is false then colorrange is unknown no matter what you set in fulls or fulld.

It's working for me (Avisynth+ 3.7.3 r4073).
This produces a full range 16 bit clip with 0 (full range) saved to frame properties.
I assume it's a 16 bit clip with only 10 bits worth of data.
truerange=false only works for me when the bitdepth is actually being converted though.

ConvertBits(10, fulls=false, fulld=true, truerange=false)

When ConvertBits doesn`t convert fulld from fulls then colorrange is unknown.

I'm not sure what you mean there.
This produces the correct limited range output for me (assuming the source is limited range with limited in frame properties).
The second ConvertBits writes 1 (limited range) to frame properties.

ConvertBits(fulls=false, fulld=true)
propDelete("_ColorRange")
ConvertBits(fulls=true, fulld=false)

[Jamaika]

I'm not sure what you mean there.
This produces the correct limited range output for me (assuming the source is limited range with limited in frame properties).
The second ConvertBits writes 1 (limited range) to frame properties.

FFmpeg doesn't report known colorrange.
ConvertBits(10, fulls=false, fulld=false, truerange=true) or
ConvertBits(10, fulls=true, fulld=true, truerange=true)

[hello_hello]

This is what AvsPmod displays. Same video each time.

https://imgur.com/FSCD8jg.png

https://imgur.com/JSyb1rR.png

[Jamaika]

Thanks for the info. That means a crappy ffmpeg plugin.

[pinterf]

Thanks for the info. That means a crappy ffmpeg plugin.
Also, older Avisynth plugins (technically: which are using NewVideoFrame and not MakeWritable/NewVideoFrame2 for the new frame creation) are not able to pass input frame properties.

[wonkey_monkey]

What exactly does VideoInfo::FramesFromAudioSamples return? The documentation isn't very specific - is it strictly the minimum number of frames that would cover that number of audio samples?

E.g. if you have 25fps video and 48000Hz audio, would FramesFromAudioSamples(48000) return 25 and FramesFromAudioSamples(48001) return 26?

[StainlessS]

From Avisynth.h [v2.58, (VERSION 3)], baked in header.

// useful functions of the above
bool HasVideo() const { return (width!=0); }
bool HasAudio() const { return (audio_samples_per_second!=0); }
bool IsRGB() const { return !!(pixel_type&CS_BGR); }
bool IsRGB24() const { return (pixel_type&CS_BGR24)==CS_BGR24; } // Clear out additional properties
bool IsRGB32() const { return (pixel_type & CS_BGR32) == CS_BGR32 ; }
bool IsYUV() const { return !!(pixel_type&CS_YUV ); }
bool IsYUY2() const { return (pixel_type & CS_YUY2) == CS_YUY2; }
bool IsYV12() const { return ((pixel_type & CS_YV12) == CS_YV12)||((pixel_type & CS_I420) == CS_I420); }
bool IsColorSpace(int c_space) const { return ((pixel_type & c_space) == c_space); }
bool Is(int property) const { return ((pixel_type & property)==property ); }
bool IsPlanar() const { return !!(pixel_type & CS_PLANAR); }
bool IsFieldBased() const { return !!(image_type & IT_FIELDBASED); }
bool IsParityKnown() const { return ((image_type & IT_FIELDBASED)&&(image_type & (IT_BFF|IT_TFF))); }
bool IsBFF() const { return !!(image_type & IT_BFF); }
bool IsTFF() const { return !!(image_type & IT_TFF); }

bool IsVPlaneFirst() const {return ((pixel_type & CS_YV12) == CS_YV12); } // Don't use this
int BytesFromPixels(int pixels) const { return pixels * (BitsPerPixel()>>3); } // Will not work on planar images, but will return only luma planes
int RowSize() const { return BytesFromPixels(width); } // Also only returns first plane on planar images
int BMPSize() const { if (IsPlanar()) {int p = height * ((RowSize()+3) & ~3); p+=p>>1; return p; } return height * ((RowSize()+3) & ~3); }
__int64 AudioSamplesFromFrames(__int64 frames) const { return (fps_numerator && HasVideo()) ? ((__int64)(frames) * audio_samples_per_second * fps_denominator / fps_numerator) : 0; }
int FramesFromAudioSamples(__int64 samples) const { return (fps_denominator && HasAudio()) ? (int)((samples * (__int64)fps_numerator)/((__int64)fps_denominator * (__int64)audio_samples_per_second)) : 0; }
__int64 AudioSamplesFromBytes(__int64 bytes) const { return HasAudio() ? bytes / BytesPerAudioSample() : 0; }
__int64 BytesFromAudioSamples(__int64 samples) const { return samples * BytesPerAudioSample(); }
int AudioChannels() const { return HasAudio() ? nchannels : 0; }
int SampleType() const{ return sample_type;}
bool IsSampleType(int testtype) const{ return !!(sample_type&testtype);}
int SamplesPerSecond() const { return audio_samples_per_second; }
int BytesPerAudioSample() const { return nchannels*BytesPerChannelSample();}
void SetFieldBased(bool isfieldbased) { if (isfieldbased) image_type|=IT_FIELDBASED; else image_type&=~IT_FIELDBASED; }
void Set(int property) { image_type|=property; }
void Clear(int property) { image_type&=~property; }


I actually got this from Avisynth_v2.6-FINAL_English_Manual,
https://forum.doom9.org/showthread.php?t=152781&highlight=avisynth+v2.6+final+english

direct link here:- https://www.mediafire.com/file/62mphc846sdh6u0/AvisynthEngHelp%252BSDK26_FINAL-2015-05-31.zip/file

You can access avisynth v2.6 header + 2.58, + avisynth_c.h via the List Of Source Files table, FilterSDK\Include whotsit.

[pinterf]

In actual Avisynth+ code this calculation is the same as StainLessS showed in the old headers.


int VideoInfo::FramesFromAudioSamples(int64_t samples) const { return (fps_denominator && HasAudio()) ? (int)((samples * fps_numerator)/((int64_t)fps_denominator * audio_samples_per_second)) : 0; }

"Normalize" is using it for getting the frame number where the peak audio sample value was found:


frameno = vi.FramesFromAudioSamples(peaksampleno / vi.AudioChannels());

[wonkey_monkey]

Edit: thinking it over.

So, rather than being a count of frames associated with a count of samples, it is the 0-indexed number of the individual frame which is associated with a sample.

For example (again with a 25fps 48000Hz clip), FramesFromAudioSamples(47999) would return 24, meaning the 25th frame (0-indexed).

However if you needed to know how many frames were needed to contain 47999 samples, that number would be 25 (0-24).

Similarly FramesFromAudioSamples(48000) would return 25 (meaning 26th frame).

I think this might be a distinction worth documenting, as the function name is a bit misleading (I would have removed the plurals and called it FrameFromAudioSample - "Frames" implies it is returning a count).

[wonkey_monkey]

Bug? If you call env->Invoke from inside your filter, but get the parameters wrong, Avisynth returns an error about invalid arguments, but naming your filter rather than the filter you were trying to invoke.

E.g.:

SpliceFadeIn::SpliceFadeIn(PClip _child, IScriptEnvironment* env) : GenericSpliceFilter(_child, env) {
{
AVSValue args[2] = { child, "32" }; // second parameter should be an integer, not a string
child = env->Invoke("ConvertBits", AVSValue(args, 2)).AsClip();
vi = child->GetVideoInfo();
}


results in the following error:

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

[jpsdr]

I've build very recently avisynth, and two plugins DLL disapeared (or were not build) ImageSeq & TimeStretch compared to the previous build i've made.
Is it normal ?
Does it mean that these are not necessary anymore and can be removed from the plugins+/plugins64+ directory, or should i keep the DLL from previous build ?

[FranceBB]

I think that there have been some changes made by Stephen on DevIL (https://github.com/AviSynth/AviSynthPlus/commit/4a938215f3403fb8dbf766c5c34973eda936a73f) and SoundTouch (https://github.com/AviSynth/AviSynthPlus/commit/28749857b4c446420878f4f10f1ede6cdc5ad4fb) as he removed both dependencies from the Avisynth project.
ImageSeq and TimeStretch() are still there and they're very much needed, but for instance if you open https://github.com/AviSynth/AviSynthPlus/tree/master/plugins/TimeStretch you're only gonna see TimeStretch.cpp without the SoundTouch subfolder.
The same goes for ImageSeq https://github.com/AviSynth/AviSynthPlus/tree/master/plugins/ImageSeq
There's now a new CMakeLists.txt that is supposed to fetch the dependencies from the system rather than from the two subfolders in the Avisynth repository.

By the way, compiling using a new version of SoundTouch is something I really look forward to 'cause Avisynth 3.7.4 will finally have support for up to 32ch in TimeStretch() and I won't have to divide the various audio tracks any longer. :D

[jpsdr]

So, it means that i have no idea of what to do to have these DLL built again.... :(
It means i have to install some other stuff...???
What ? How ?

[FranceBB]

I think the best person to ask is Stephen directly (I mean qyot27).
Hopefully he's gonna reply here as he regularly reads.
This is what he wrote in the commit:


ImageSeq: rely on CMake-internal find_package on all platforms
CMake's find_package was already used on everything other than
Windows, but as it turns out, on Windows, the user only needs
to pass -DCMAKE_PREFIX_PATH with the root directory of where
the DevIL installation is for it to find it.

The DevIL SDK as distributed from upstream requires either:
A) Moving the relevant x64 or x86 version of DevIL.lib and ILU.lib
into the main lib/ directory instead of them residing in
lib/{x64,x86}/Release or lib/{x64,x86}/unicode/Release
or
B) Using -DIL_LIBRARIES and -DILU_LIBRARIES when configuring
AviSynth+ to point directly at DevIL.lib and ILU.lib.

This also allows for linking against a static build of DevIL,
removing the need for any extra system DLLs.

[wonkey_monkey]

I just spent some time being confused over the following:

ColorBars(pixel_type="yv24").ConvertToRGB.ConvertToYV24

My expectation was that colour values would remain the same before and after the two conversions (to within the limits of 8-bit values), but in fact they did differ quite a bit. This seems to be because ColorBars gives itself a _Matrix property of "BT.709" - ConvertToRGB uses that property to do its conversion, but then overwrites it to "RGB", such that the conversion back to YV24 defaults to Rec601.

Anyway, just another of my wacky little observations that had me wondering if there might not be a more "least surprise" way of doing things.

[wonkey_monkey]

Me again...

I'm getting either an Access Violation exception (if my DLL is built as Release) or just the silent death of VirtualdDub (if built as Debug) when calling AddFunction with an invalid parameter string, e.g.:

env->AddFunction("_", "[fade_length]f[fade_offset]f[fade_offset_type]f!", Create_params, 0); // ! at end of string

env->AddFunction("_", "[fade_length]f[fade_offset]!f[fade_offset_type]", Create_params, 0); // ! in middle of string

env->AddFunction("_", "[fade_length]f[fade_offset]f[fade_offset_type]", Create_params, 0); // missing the final parameter type specifier


AddFunction calls IsValidParameterString, which seems to work correctly in isolation (all of the above return false). A false result should throw an Avisynth exception:

void PluginManager::AddFunction(const char* name, const char* params, IScriptEnvironment::ApplyFunc apply, void* user_data, const char *exportVar, bool isAvs25)
{
if (!IsValidParameterString(params))
Env->ThrowError("%s has an invalid parameter string (bug in filter)", name);


But for some reason it doesn't seem to work. I'm a bit stuck on debugging it any further.

----------------------------------------------------------------------------------

An aside: IsValidParameterString and its attendent functions seem a bit unwieldy; can I suggest the following regex instead? I'm pretty sure it's correct, and it also validates parameter names:

^((\[[A-Za-z_]\w*\])?[.cisbfna][+*]?)*$

In PluginManager.cpp:

...

#define _REGEX_MAX_STACK_COUNT 20000 // needs increasing for long parameter strings
#include <regex>

void PluginManager::AddFunction(const char* name, const char* params, IScriptEnvironment::ApplyFunc apply, void* user_data, const char* exportVar, bool isAvs25)
{
if (!std::regex_match(params, std::regex(R"(^((\[[A-Za-z_]\w*\])?[.cisbfna][+*]?)*$)")))
Env->ThrowError("%s has an invalid parameter string (bug in filter)", name);

...

[Selur]

btw. is there an eta. for a new official Avisynth release over at https://github.com/AviSynth/AviSynthPlus ?

[StainlessS]

I'm getting either an Access Violation exception (if my DLL is built as Release) or just the silent death of VirtualdDub (if built as Debug) when calling AddFunction with an invalid parameter string, e.g.:

I think that has been the case for a long time, any screwup in AddFunction can cause weird probs.

[FranceBB]

btw. is there an eta. for a new official Avisynth release over at https://github.com/AviSynth/AviSynthPlus ?

+1
I would also like to know when 3.7.4 is gonna be released as I really look forward to it. :D
By the way, I was wrong in my prediction here:

between March 18, 2022 and July 16, 2023, 485 days passed, so if we apply the same logic we can expect the future release to be:

AviSynth+ 3.7.4 - Nov 12, 2024

We're currently 61 days after the date I predicted by looking at the time it passed between the other releases.
Avisynth 3.7.3 is 546 days old.

[wonkey_monkey]

I think that has been the case for a long time, any screwup in AddFunction can cause weird probs.


PluginManager::AutoloadPlugins calls LoadPlugin, which calls TryAsAvs26, which calls AvisynthPluginInit3, which calls AddFunction, which (because of the badly-formatted string) throws an exception back up to TryAsAvs26, which only stores the exception in a string and returns to LoadPlugin, which then ignores the error because it was called with onErrorThrow = false.

I don't know what's ultimately causing the later Access Violation, but changing line 695 of PluginManager.cpp from

LoadPlugin(p, false, &dummy);

to

LoadPlugin(p, true, &dummy);

results in the proper plugin loading exception being thrown and being displayed to the user. I'm not sure why it defaults to being silent but it's been that way for years.

[Jamaika]

I just spent some time being confused over the following:

ColorBars(pixel_type="yv24").ConvertToRGB.ConvertToYV24

My expectation was that colour values would remain the same before and after the two conversions (to within the limits of 8-bit values), but in fact they did differ quite a bit. This seems to be because ColorBars gives itself a _Matrix property of "BT.709" - ConvertToRGB uses that property to do its conversion, but then overwrites it to "RGB", such that the conversion back to YV24 defaults to Rec601.

Anyway, just another of my wacky little observations that had me wondering if there might not be a more "least surprise" way of doing things.

I have color matrix smpte170m and color range tv.
Stream #0:0: Video: rawvideo (444P / 0x50343434), yuv444p(tv, smpte170m/unknown/unknown), 640x480, 29.97 fps, 29.97 tbr, 29.97 tbn

The transfer function defined for SMPTE 170M is the same as the one defined in Rec. 709.

[pinterf]

So, it means that i have no idea of what to do to have these DLL built again.... :(
It means i have to install some other stuff...???
What ? How ?
First, let me mention that there is a quite well maintained page where one can find Avisynth documentation. When we update the 'rst doc' on github then this page is automatically refreshed as well.

https://avisynthplus.readthedocs.io/en/latest/

Specifically about two external DLLs (Soundtouch/Timestretch and DevIL):
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/avsplus_external_deps_guide_manual.html

This is a bit more complicated than just "build solution" from Visual Studi and the build process is still under discussions on github, but I succeeded with it (contrary the fact that I always fear of command-line build processes, I like MSVC GUI better :) ). These DLLs are not changed frequently. So if building them is inconvenient you can just copy/leave them from a previous versions. They are still part of Avisynth.

Back to our online documentation.

It's the same as Avisynth wiki. Since we update the documentation on github, only the readthedocs is refreshed. When we don't forget, a short note is put at the beginning of the classic avisynth wiki page about the possibly outdated content. When the changes are small I update the old wiki as well. There are still parts where is Avisynth wiki page is more actual, but I try to convert such sections when I realize the lag.

For example:

http://avisynth.nl/index.php/Subtitle
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/subtitle.html

Btw, you can follow the actual changes at:

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html

[pinterf]

+1
I would also like to know when 3.7.4 is gonna be released as I really look forward to it. :D
By the way, I was wrong in my prediction here:



We're currently 61 days after the date I predicted by looking at the time it passed between the other releases.
Avisynth 3.7.3 is 546 days old.

Yep. Unfortunately, the builds are not restricted to the classic x86/x64 architectures. I cannot provide a release date as it's definitely not a quick process due to the extensive checking required. I don't know how to build the Mac or Arm versions, and all such work is usually done by our build master, qyot27, who is a very thorough person. (And there are still conversations about the build process with ClangCl for example). So it will be released when it's done :)

[pinterf]

PluginManager::AutoloadPlugins calls LoadPlugin, which calls TryAsAvs26, which calls AvisynthPluginInit3, which calls AddFunction, which (because of the badly-formatted string) throws an exception back up to TryAsAvs26, which only stores the exception in a string and returns to LoadPlugin, which then ignores the error because it was called with onErrorThrow = false.

I don't know what's ultimately causing the later Access Violation, but changing line 695 of PluginManager.cpp from

LoadPlugin(p, false, &dummy);

to

LoadPlugin(p, true, &dummy);

results in the proper plugin loading exception being thrown and being displayed to the user. I'm not sure why it defaults to being silent but it's been that way for years.

When LoadPlugin is called from a .avs script then the error message (exception text) is shown.

Otherwise (called from AutoLoadPlugins) the exception is not shown because there can be other - non Avisynth - helper DLLs in the *.dll list which could prematurely finish the autoloading procedure. I think this is why it is silent in this case.

[jpsdr]

This is a bit more complicated than just "build solution"...

ARGGH !!!!!! :scared:

I think i'll just keep the previous versions of the DLL for now...

[tormento]

I think i'll just keep the previous versions of the DLL for now...
I am using the gitlab build since a couple of weeks and it seems ok.

[wonkey_monkey]

Otherwise (called from AutoLoadPlugins) the exception is not shown because there can be other - non Avisynth - helper DLLs in the *.dll list which could prematurely finish the autoloading procedure. I think this is why it is silent in this case.

Ah yes, that makes complete sense. Still, it would be nice to see the exception if the parameter string is wrong, otherwise us developers are left scratching our heads over an Access Violation (still not sure why that happens, since the plugin shouldn't be pushed to the plugins structure; at one point debugging took me to code for a completely different plugin of mine that I wasn't even compiling at the time), or, if that Access Violation is solved, our plugin silently failing to load.

[pinterf]

Ah yes, that makes complete sense. Still, it would be nice to see the exception if the parameter string is wrong, otherwise us developers are left scratching our heads over an Access Violation (still not sure why that happens, since the plugin shouldn't be pushed to the plugins structure; at one point debugging took me to code for a completely different plugin of mine that I wasn't even compiling at the time), or, if that Access Violation is solved, our plugin silently failing to load.
I have tried to mess up the parameter string with an extra "!" after the last type.

I was using Avsmeter64 which reports the exception text properly, since it works on the console.

1.) Direct use of LoadPlugin:

LoadPlugin("c:\Github\RemoveDirt\x64\Debug\RemoveDirt.dll")

The console message:

'c:/Github/RemoveDirt/x64/Debug/RemoveDirt.dll' plugin loading error:
RestoreMotionBlocks has an invalid parameter string (bug in filter)
(d:\Tape13\myfolder\s1.avs, line 1)

2.) Then I put the bad DLL to Avisynth's plugins64 folder for autoloading.
Obviously the function with the wrong parameter string did not load at all, so any referencing gave an error on the console output:

Script error: There is no function named 'RestoreMotionBlocks'.
(d:\Tape13\myfolder\s1.avs, line 39)
(d:\Tape13\myfolder\s1.avs, line 13)

[wonkey_monkey]

Hmm, so no Access Violation. I'll see if I can narrow it down on my computer.

Edit: AVSMeter64.exe aborts in the same manner as GUI programs do. Visual Studio debugging told me "Unhandled exception at 0x00007FFD4C0D36F8 (SubtitleEx_x64.dll) in VirtualDub64.exe: 0xC000001D: Illegal Instruction."

:confused:

I moved SubtitleEx_x64.dll out and this time it showed an access violation in one of my own filters, but also debugging took me to line 25 of FilterConstructor.cpp:

AVSValue retval = Func->apply(funcArgs, Func->user_data,
Func->isAvs25 ? (IScriptEnvironment *)Env25 : Env);

[wonkey_monkey]

Edit: never mind. Issue is that SuperEq should throw an error if the input audio isn't float, but it doesn't.

[pinterf]

Edit: never mind. Issue is that SuperEq should throw an error if the input audio isn't float, but it doesn't.
Fixed by qyot27. Was it you who created an issue on this on git?
https://github.com/AviSynth/AviSynthPlus/issues/421

[pinterf]

Hmm, so no Access Violation. I'll see if I can narrow it down on my computer.

Edit: AVSMeter64.exe aborts in the same manner as GUI programs do. Visual Studio debugging told me "Unhandled exception at 0x00007FFD4C0D36F8 (SubtitleEx_x64.dll) in VirtualDub64.exe: 0xC000001D: Illegal Instruction."

:confused:

I moved SubtitleEx_x64.dll out and this time it showed an access violation in one of my own filters, but also debugging took me to line 25 of FilterConstructor.cpp:

AVSValue retval = Func->apply(funcArgs, Func->user_data,
Func->isAvs25 ? (IScriptEnvironment *)Env25 : Env);

Make sure that this 64 bit dll was created for Avisynth+. 2.5 interface is not compatible.

[StainlessS]

Fixed by qyot27. Was it you who created an issue on this on git?
https://github.com/AviSynth/AviSynthPlus/issues/421

Issue poster "dartheditous", is Wonkey_Donkey alias on YouTube, so I assume so.

dartheditous@YouTube:- https://www.youtube.com/@DarthEditous/videos

EDIT: A dartheditous favourite:- https://www.youtube.com/watch?v=ZkkUNFXaYyk
EDIT: And source clip transformed by dartheditous to above clip:- https://www.youtube.com/watch?v=dPPjUtiAGYs

EDIT: And conversion script on D9:- https://forum.doom9.org/showthread.php?p=1792366#post1792366

EDIT: A frame from 2nd link clip, converted from 3rd link clip by 4th link script:
https://s20.postimg.cc/xcn153sl9/structures_zpsg2mpn3kn.jpg (https://postimg.cc/image/6et43d7y1/)

[wonkey_monkey]

What I was most surprised about with that video was how you get realistic shading without even trying, just because of how averaged/anti-aliased pixels stack up around the edges.

[Emulgator]

Just a quick test if r4096 x64 would finally be able to feed frames to Topaz 2.6.4:
Not. First frame #0, last frame #-1.
All uvz builds I have tested fail in that regard.
3973; 4073 LLVM, 4073 Clang stalls anyway here; 4096 LLVM, Clang both work in AvsPmod)
Last good for me is pinterf's r4066.

[wonkey_monkey]

I think that has been the case for a long time, any screwup in AddFunction can cause weird probs.

I think I figured this one out. If there are multiple AddFunctions in a plugin's init function, some of them can get added to the AviSynth environment before a faulty one is reached. The faulty one stops the plugin from being properly loaded, but the earlier functions are still created, and calling one of them results in the Access Violation.

[pinterf]

I think I figured this one out. If there are multiple AddFunctions in a plugin's init function, some of them can get added to the AviSynth environment before a faulty one is reached. The faulty one stops the plugin from being properly loaded, but the earlier functions are still created, and calling one of them results in the Access Violation.

Good catch, now I hope I can reproduce it, so far I tried messing up my first function in the plugin. (And an internal avs function as well, but it didn't give error.)

[wonkey_monkey]

This is a vague idea I've had for a while and I'm wondering how practical/useful it might be...

Could GenericVideoFilter be extended, without breaking old filters, to allow communication between filters? I'm thinking of something dead simple like

AVSValue GenericVideoFilter::GetAVSValue(AVSValue input)

which the next filter down could call:

AVSValue result = child->GetAVSValue(val); // val is whatever the "child" (really should be called "parent"...) clip is expecting - array, string, integers representing different instructions

which authors could use to transfer data between filters. The default could be to return false or throw an exception or pass the request up the chain (not really sure how it would work with existing filters). Filters could also pass pointers (either in an array of 32-bit integers, bit clunky, or as a 64-bit integer once Avisynth supports it) so data could then go both down and up the filter chain.

Too esoteric? I rolled my own version with GetAudio and magic numbers before frame properties were implemented and it's been surprisingly useful, but the disadvantage is that clips have to have audio and you can't use certain audio filters. But maybe it's just me who writes such ridiculously complicated filters.

[LigH]

Reminds me of TDecimate using hints from TFM, just with an explicit API.

[wonkey_monkey]

That's the idea. Something like MVtools wouldn't need separate "super" clips any more; Manalyse could return the original video while also providing access to its motion data through the same clip. A simple helper filter could "dub" clips with other clips' data, and with magic numbers to differentiate (maybe required by the function to help developers avoid clashing with each other), a clip could have multiple sets of data/pointers associated with it.

[pinterf]

That's the idea. Something like MVtools wouldn't need separate "super" clips any more; Manalyse could return the original video while also providing access to its motion data through the same clip. A simple helper filter could "dub" clips with other clips' data, and with magic numbers to differentiate (maybe required by the function to help developers avoid clashing with each other), a clip could have multiple sets of data/pointers associated with it.
Why not frame properties?

When mvtools was ported to Vapoursynth it was one of their first step to replace the inter-filter datapointer-in-sound-vi-data hack to frame property usage. I did not yet backported this feature.

Also, in the VapourSynth TIVTC pack the magic-number related things were eliminated as well, I have backported them, if they exists they are used, otherwise the good old magic 32 bits are used for marking the specific properties.

[DTL]

That's the idea. Something like MVtools wouldn't need separate "super" clips any more; Manalyse could return the original video while also providing access to its motion data through the same clip. A simple helper filter could "dub" clips with other clips' data, and with magic numbers to differentiate (maybe required by the function to help developers avoid clashing with each other), a clip could have multiple sets of data/pointers associated with it.

Super clip in mvtools is designed for at least 3 needs:

1. Provide padded original frames so that MVs can run slightly out of the frame borders.

2. Provide multi-levels downsized hierarchy of frame copies for hierarchical search algorithm (at least in MAnalyse onCPU but any other filter can use this data).

3. Provide sub-sample shifted copies of frame (sort of upscaled-separated) for sub-sample precision processing (pel > 1). It takes lots of RAM but still faster in comparison with runtime sub-shifting at time of MAnalyse at least.

So you can not simply use pointers to original frames (in most use cases). Only with MAnalyse with DX12-ME feature - it sends full unpadded frames to ME engine and without downsized versions.

Only if you somewhere use MSuper(levels=1, hpad=vpad=0, pel=1) you can make pointers.

[DTL]

We got some random crashes at the JincResize plugin (at least in AVS 32bit) - https://forum.doom9.org/showthread.php?t=186053 . It typically happen in SIMD processing functions and looks like out of allocated memory access (0xc___5 code). Mostly happen with production release builds and hard to catch in debugger with debug build.

The SIMD processing functions are 'simple' https://github.com/Asd-g/AviSynth-JincResize/blob/9d813f95e2aee549800e64470ddd6b2841a51c84/src/resize_plane_avx2.cpp#L49 (witout scalar epilogue down to single sample at the end of line) and looks like designed to work only with enough padded lines from AVS core.

The question: Is it known the guaranteed lines padding to work with this design of processing plugins and how it can changed in different AVS (and AVS+) versions ? In the old days of SSE 128bit it can be lower (or not even desigbed to be mod of 128bits) and in the era of AVX-512 it is expected to be at least mod of 512 bit ? The more line padding waste some RAM (and the lower image width - the more RAM wasted relatively).

Also can we got a user-defined control (via some script command) of the frame buffers line padding so it can be some hint to some plugins or user-selection of some balance between RAM usage and performance or some way to increase stability of some plugins with 'unsafe' design of the frame buffer processing functions (but with some more RAM usage if set to too high padding) ?

[wonkey_monkey]

Why not frame properties?

Well, mainly because conceptually these things are not per-frame properties (you shouldn't have to get a frame, whether that's frame 0 or any other, to find them), but also because it provides, without cluttering up frame properties, a specific, simple, but very extensible method for reaching back up the filter chain for whatever reason an author might find for doing so.

E.g.: I've written a filter (as part of a suite) that allows you to specify a coordinate on a video, and has use cases where you might add 100 or more such points (each with varying properties). That doesn't seem like it would be a practical or performant use of frame properties to me (but again, maybe I'm the only one who writes such grotesque filters!). Each instance would have to read the existing properties to make sure it appended without overwriting any previous records, for example, which just seems a bit wasteful to me, especially if it's also a non-trivial actual video filter.

Instead, by talking directly to the preceding filter (which can also pass messages further up, if required), I can pass a pointer to a container and get all of those preceding filters to push their data into it. You could also use a filter to modify a preceding filter's behaviour (probably against the ethos of a filter chain, but potentially a useful trick), which you couldn't do with frame properties.

So you can not simply use pointers to original frames (in most use cases).

It wouldn't be a pointer to a frame, it would be a pointer to the filter instance (or just one of its variables) which generated the clip. With that you could access its methods, which might include one that generates and returns the padded, hierarchical data, or what have you (mvtools is maybe not the best example since passing such data as frames does make some sense; but there are other cases where it's not visual data, or isn't even per-frame data).

I dunno, maybe it is a silly idea that few other people would ever have a reason to use. But - if I'm not mistaken - it would be pretty much zero-cost to implement, practically a one-liner like GenericVideoFilter::GetAudio.

[Jamaika]

I have a question about the ColorBars plugin.
http://avisynth.nl/index.php/ColorBars
string pixel_type = "RGB32"
Set color format of the returned clip.
May be any of the following: "YUY2", "YV12", "YV24" (v2.60), or (default) "RGB32".
AVS+ "RGB32", "RGB64", "YUY2", or any planar RGB, 4:2:0 or 4:4:4 format.
I use ffmpeg with avisynth 3.7.3+.
End result black screen. Is RGB32\64 supported by ffmpeg 64bit?
ColorBars(width=640, height=480, pixel_type="rgb32")

[pinterf]

We got some random crashes at the JincResize plugin (at least in AVS 32bit) - https://forum.doom9.org/showthread.php?t=186053 . It typically happen in SIMD processing functions and looks like out of allocated memory access (0xc___5 code). Mostly happen with production release builds and hard to catch in debugger with debug build.

The question: Is it known the guaranteed lines padding to work with this design of processing plugins and how it can changed in different AVS (and AVS+) versions ?
Frame and scanline alignment is 64 bytes. So pitch and rowsize is guaranteed to have 64 bytes granularity.

An unaligned simd load can cause C0000005 as well. I loosely follow that topic; try replacing all _mm_load_xxxx / _mm256_load_xxx / _mm512_load _xxx to _mm_loadu versions and check if errors still occur.

[DTL]

Frame and scanline alignment is 64 bytes. So pitch and rowsize is guaranteed to have 64 bytes granularity.



Can we expect some user-side control via script to increase (change/set) alignment size ? At the AVS+ environment init at least. Also API control for plugins auto-set (if possible ?). 64 byes is ony 1 AVX512 dataword load and for some formats like float32 it takes also not much samples and sometime 128byte or 256bytes loads may make some better performance (at large frame sizes like 4K 8K) or can work as some test if running out or last line happen and crash.

Also 64bytes starte from the first AVS version or some AVS+ and also exist in latest AVS 2.60 ?

Also the second important question - the N-bytes alignment make also line stride integer number of alignment. But last line of buffer also have padding to the N-1 byte allocated and valid or not ?

https://ibb.co/K5WJ8vZ

Image url https://ibb.co/K5WJ8vZ

In this 3 lines frame buf example of the stride of 0x100 - we make allocation of 0x2E0 bytes (like frame 736x3 dec size) with _aligned_malloc(0x2E0, 64) . Will be the addreses up to 0x300-1 valid ? If not - the 64bytes SIMD read of the end of last line can crash ? Also SIMD write can cause memory corruption if even addresses are in same RAM page and valid for read/write.

The description of _aligned_malloc() at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/aligned-malloc?view=msvc-170 do not describe where located the last valid address ?

[pinterf]

Can we expect some use-side control via script to increase alignment size ? 64 byes is ony 1 AVX512 dataword load and for some formats like float32 it takes also not much samples and sometime 128byte or 256bytes loads may make some better performance (at large frame sizes like 4K 8K) or can work as some test if running out or last line happen and crash.

Also 64bytes starte from the first AVS version or some AVS+ and also exist in latest AVS 2.60 ?

Also the second important question - the N-bytes alignment make also line stride integer number of alignment. But last line of buffer also have padding to the N-1 byte allocated and valid or not ?

https://ibb.co/K5WJ8vZ

Image url https://ibb.co/K5WJ8vZ

In this 3 lines frame buf example of the stride of 0x100 - we make allocation of 0x2E0 bytes (like frame 736x3 dec size) with _aligned_malloc(0x2E0, 64) . Will be the addreses up to 0x300-1 valid ? If not - the 64bytes SIMD read of the end of last line can crash ? Also SIMD write can cause memory corruption if even addresses are in same RAM page and valid for read/write.

64 byte alignment is documented and plugins can rely on that. Even Avisynth core is using that fact. (In a resizer and in Expr?)

Last line is safe. Originally height * aligned row_size is allocated, so it is safe to use full simd at the very end of the last line as well. Note: the last line is safe up to row_size and not pitch size. Pitch can be double of row_size for example after a SeparateFields (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/separatefields.html#separatefields)

Avs 2.6 aligned frame buffers to 16 bytes, but the user had the opportunity to Crop to completely unaligned frame starting point.

So early plugins had to check the pointers all the time. Some history:
https://github.com/pinterf/RgTools/blob/master/RgTools/removegrain.cpp#L952

[DTL]

64 byte alignment is documented and plugins can rely on that. Even Avisynth core is using that fact. (In a resizer and in Expr?)

Last line is safe. Originally height * aligned row_size is allocated, so it is safe to use full simd at the very end of the last line as well. Note: the last line is safe up to row_size and not pitch size.

Avs 2.6 aligned frame buffers to 16 bytes,

It is nice to have this in documentation so the plugins developers can put to documentation note about minimum required AVS(+) version.

As for _aligned_malloc(size, alignment) WinAPI - I think because the 'alignment' may be very high and API do not knows anything about internal treatment of allocated area - no any safe addresses exist after aligned_address+size ? And user must calculate size to allocate with space for last SIMD read/write size ?

[pinterf]

It is nice to have this in documentation so the plugins developers can put to documentation note about minimum required AVS(+) version.

As for _aligned_malloc(size, alignment) WinAPI - I think because the 'alignment' may be very high and API do not knows anything about internal treatment of allocated area - no any safe addresses exist after aligned_address+size ? And user must calculate size to allocate with space for last SIMD read/write size ?
Alignment parameter is only for the beginning address. The size can be anything the user want.

[DTL]

Alignment parameter is only for the beginning address. The size can be anything the user want.

The main question was "Are there any valid/safe to read/write addresses exist after aligned_address+size ?". If the 'alignment' param is unlimited and can be very large like 4MBytes - it is mostly probably no.

Practically some non-crashable addresses may last till the end of typical 4KBytes RAM page after aligned_address+size. But if start address changes - the crash will happen. So it is the way to have random crashes at different runs.

[pinterf]

The main question was "Are there any valid/safe to read/write addresses exist after aligned_address+size ?". If the 'alignment' param is unlimited and can be very large like 4MBytes - it is mostly probably no.
https://en.cppreference.com/w/c/memory/aligned_alloc
theoretically the size must be multiple of alignment. It may fail - or not.

[pinterf]

...
instead, by talking directly to the preceding filter (which can also pass messages further up, if required), I can pass a pointer to a container and get all of those preceding filters to push their data into it. You could also use a filter to modify a preceding filter's behaviour (probably against the ethos of a filter chain, but potentially a useful trick), which you couldn't do with frame properties.

It wouldn't be a pointer to a frame, it would be a pointer to the filter instance (or just one of its variables) which generated the clip. With that you could access its methods, which might include one that generates and returns the padded, hierarchical data, or what have you (mvtools is maybe not the best example since passing such data as frames does make some sense; but there are other cases where it's not visual data, or isn't even per-frame data).

I dunno, maybe it is a silly idea that few other people would ever have a reason to use. But - if I'm not mistaken - it would be pretty much zero-cost to implement, practically a one-liner like GenericVideoFilter::GetAudio.
Your ideas are never silly. You are one of the rare Avisynth developers who create *new* plugins and ideas. (Unlike me, who is just a plugin maintainer/fixer/enhancer).

So you'd like to create a wormhole or a message queue between filter instances?

[wonkey_monkey]

So you'd like to create a wormhole or a message queue between filter instances?

Pretty much, but the details can be left to authors as long as they can pass an AVSValue upward. In that way it's complementary to frame properties, which propagate downward.

I'm not too clear on exactly what's required to do this but I'm guessing IClip needs to handle a base case and maybe return a void AVSValue, while GenericVideoFilter's override will pass the value up to the parent (sorry, child! :D)

Could it be as simple as:


AVSValue IClip::ReceiveMessage(AVSValue input) { return AVSValue(); }

AVSValue GenericVideoFilter::ReceiveMessage(AVSValue input) { return child->ReceiveMessage(input); }


?

Or to go really barebones:


void IClip::ReceiveMessage(void* input) { }

void GenericVideoFilter::ReceiveMessage(void* input) { child->ReceiveMessage(input); }


and let authors figure everything else out for themselves!

[LigH]

I have a question about the ColorBars plugin.

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...

I use ffmpeg with avisynth 3.7.3+.

The current documentation is in the AviSynth+ Docs (https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html). I hope you can find more details there.

[Jamaika]

ColorBars is a core filter, not a loadable plugin DLL.

There are several possible FourCC's for 32-bit RGB in AVI. But I guess ffmpeg will use an internal video format identifier instead when using an internal AviSynth demultiplexer...
Thank you for your answer. I was surprised by the creators' answer.
When we enter RGB32, only the alpha channel is displayed.
To unlock the rest, use the function RGBAdjust(ab=255)

And one more thing contrary to wiki documentation. No RGB is supported using KNLMeansCL. And everything is clear.
What isn't clear to Jamaika. Does OpenCL support Intel processors without graphics card? It is about the CPU option.

[LigH]

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.

PS: Who do you mean by "the creator"?!

[Jamaika]

In general, OpenCL is an abstraction library for complex calculations. It does not require GPGPU support per se, it can be implemented in CPU SIMD instructions too. But it usually gains a lot of efficiency from massive parallelism in GPGPU's.
I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

PS: Who do you mean by "the creator"?!
https://github.com/pinterf/KNLMeansCL/pull/9

[LigH]

I have an inactive CPU for Intel. How do I set the BIOS? What drivers should I install for Intel i5-13600K?

I don't think you need to set any special option in the BIOS, as a CPU-only OpenCL driver would just use CPU instructions available for every application.

I do not have any intel CPU. So I can only guess that Intel® CPU Runtime for OpenCL™ Applications with SYCL support (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-cpu-runtime-for-opencl-applications-with-sycl-support.html) might be the one you are interested in; no warranties.

[Jamaika]

Thanks LigH. I thought it was impossible. I was convinced that OpenCL was overriding Windows. I also don't see an option to connect openCL GPU and CPU although press wrote about it some time ago. For x264 it's always GPU.It even works. Is OpenCL needed today when there is CUDA?
Intel processor without graphics card:
https://ibb.co/fHQCsbv

[LigH]

Is OpenCL needed today when there is CUDA?

I remember that Universe Sandbox is not able to use CUDA because it only supports single precision calculations. It works well with OpenCL.

[tormento]

No RGB is supported using KNLMeansCL.
Dunno your needs but for noise reduction BM3D is vastly superior, even if lot heavier and unfortunately it needs CPU for the temporal part.

[pinterf]

And one more thing contrary to wiki documentation. No RGB is supported using KNLMeansCL. And everything is clear.
What isn't clear to Jamaika. Does OpenCL support Intel processors without graphics card? It is about the CPU option.
Wiki is O.K. As it says, KNLMeans supports packed _and_ planar RGB, except RGB24 and RGB48.

[Jamaika]

Wiki is O.K. As it says, KNLMeans supports packed _and_ planar RGB, except RGB24 and RGB48.
I disagree.
Supported color formats: RGB32, Y8, YV12, YV16, YV24, YV411
AviSynth+: all planar formats (8/10/12/14/16/32bit, Y/YUV/RGB with or without alpha) are supported. RGB64 is also supported.

Test original:
ColorBars(width=640, height=480, pixel_type="rgb32")
KNLMeansCL(device_type="gpu",device_id=0)

KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!

I added no display information. After corrections:
https://ibb.co/t3BYVkg

[pinterf]

I disagree.
Supported color formats: RGB32, Y8, YV12, YV16, YV24, YV411
AviSynth+: all planar formats (8/10/12/14/16/32bit, Y/YUV/RGB with or without alpha) are supported. RGB64 is also supported.

Test original:
ColorBars(width=640, height=480, pixel_type="rgb32")
KNLMeansCL(device_type="gpu",device_id=0)

KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!

I added no display information. After corrections:
https://ibb.co/t3BYVkg
False alarm. If you do your own build where
- you intentionally changed the source and hardcoded info="true" (?? why?)
- despite you know about the error message ("KNLMeansCL: 'info' requires Gray8 or YUVP8 color space!")
Then it is the plugin which does not work??

No more comments.

[Jamaika]

Thanks for the explanation. For Jamaica it was convoluted and complicated. I added the info parameter so that there would be an automatic test of the GPU card when removing white Gaussian noise.
If the user finds that it is good, he can disable the parameter.
What surprises Jamaica? That he has to look for the number of colors for 8/16bit RGB and has to give an external parameter to display these colors.
ColorBars(width=640, height=480, pixel_type="rgb64")
KNLMeansCL(device_type="gpu",device_id=0,info=false)
RGBAdjust(ab=65535)

[Jamaika]

Dunno your needs but for noise reduction BM3D is vastly superior, even if lot heavier and unfortunately it needs CPU for the temporal part.
Thanks for the info. Is this plugin or some replacement also for avisynth?

[tormento]

Thanks for the info. Is this plugin or some replacement also for avisynth?


It’s a plugin for VS, ported to AVS+ too.

[FranceBB]

Out of curiosity, I'm gonna put it out here 'cause I wouldn't know where else to put this, but I've got a live recorded feed which was quite interesting once indexed it in terms of frame properties:

frame 1 to 13 (matrix, transfer, primaries as BT709)
frame 14 to 910 (matrix, transfer, primaries are missing)
frame 911 (matrix BT709, transfer, primaries are missing)
frame 912 to 922 (matrix, transfer, primaries as BT709)

This wasn't made by several appended clips, it's a single interview transmitted via a satellite feed and encoded by an hardware encoder.

https://i.imgur.com/wLiwn3J.pnghttps://i.imgur.com/oQWnTD9.png
https://i.imgur.com/ecVJW2G.pnghttps://i.imgur.com/9iLlHCt.png

With Avisynth now carrying frame properties, those were "transmitted" to FFMpeg but remained statically set as BT709, thus making the encode go through. :D
FFMpeg itself on the other hand isn't able to read the input on its own 'cause if you -i the source.mxf file instead of the AVS Script.avs then it sees them changing and it really really really didn't like that:

[vf#0:0 @ 00000192f22fed40] Reconfiguring filter graph because video parameters changed to yuv422p(tv, unknown), 1920x1080

immediately followed by:

[swscaler @ 00000192f23de080] Unsupported input (Error number -129 occurred): fmt:yuv422p csp:unknown prim:reserved trc:reserved -> fmt:yuv422p csp:bt709 prim:reserved trc:reserved

which resulted in:

[vf#0:0 @ 00000192f22fed40] Error while filtering: Error number -129 occurred

[vf#0:0 @ 00000192f22fed40] Task finished with error code: -129 (Error number -129 occurred)

[vf#0:0 @ 00000192f22fed40] Terminating thread with return code -129 (Error number -129 occurred)


Sample (if you're curious): https://we.tl/t-qfePLdYbcM
Now, given that FFMpeg doesn't support changing frame properties, sticking with the same property at the beginning and setting it static was a smart move (as far as the Avisynth scripts are concerned) ;)
This can also be tested with a simple:

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

part1=trim(0, 5).propSet("_Matrix", 5)
part2=trim(6, 10).propSet("_Matrix", 1)

part1++part2


which doesn't make it crash and leaves the Matrix set to BT601 for the entirety of the clip.
In my opinion this is the expected behavior, so please don't change it.
In the meantime, however, I did open a ticket to the FFMpeg guys to get that fixed: https://trac.ffmpeg.org/ticket/11436
Have you guys ever faced anything like this?
By the way, with me being me I actually just take the nuclear option of going full propclearall(), but you know... :P

[DTL]

There were the feature request to implement 2D resampler engine in AVS core at ages of AVS 2 - https://sourceforge.net/p/avisynth2/feature-requests/113
Created: 2013-05-26
Milestone: Future Release
Status: accepted

Can we expect such engine in AVS+ core in 202x years so it can have Jinc-based resizers (also about any 1D kernel can be tested in 2D using radius length as agrument) ? At 202x years we got >10 GB RAM in typical execution host so it can store full-frame coeffs table in x64 mode for UHD frames with some usable kernel size (like 3..5 taps at least).

For fixed integer size upsampling the very low memory implenentations also possible (examples in master-1 branch of JincResize plugin at https://github.com/Asd-g/AviSynth-JincResize/tree/master-1 ) and running also faster because of no host RAM read traffic.

[FranceBB]

Does it mean that

Jinc36Resize()
Jinc64Resize()
Jinc144Resize()
Jinc256Resize()

are gonna be included in the core and won't require asd's plugin any longer, just like all the other currently available resizers?

[Jamaika]

For fixed integer size upsampling the very low memory implenentations also possible (examples in master-1 branch of JincResize plugin at https://github.com/Asd-g/AviSynth-JincResize/tree/master-1 ) and running also faster because of no host RAM read traffic.
I'm a lousy programmer. I don't know why the JInc plugin is reverted under AVS 2.0. The problem with plugins is also that ALING is always 64 under AVX512. Changing it to 32 under AVX2 doesn't necessarily have to work.

[DTL]

Jinc36Resize()
Jinc64Resize()
Jinc144Resize()
Jinc256Resize()


They are simply short names for JincResize(tap=N) where N from 3 to 8.

Jinc36Resize is an alias for JincResize(tap=3).
Jinc64Resize is an alias for JincResize(tap=4).
Jinc144Resize is an alias for JincResize(tap=6).
Jinc256Resize is an alias for JincResize(tap=8).

I really think of testing SinPow (soft of) and UserDefined2 kernels as 2D downsize. The UserDefined2 kernel is easier to convert to 2D with replacing sinc() to jinc() base function. So with JincResize they can form complementary downscale and upscale resizers for 2D resampling engine (same as SinPow and UserDefined2 for downscale and any Sinc-based resizer for upscale for 1D resample engine).

In libplacebo I see users already make some not very small set of resizers including 2D engine and some set of base kernels and weighting functions - https://github.com/Asd-g/avslibplacebo . Though the naming is completely messy and not directly shows if 1D or 2D resampler used (may be ewa-prefixed are 2D only ?). So 2D resizers are not lost in the past.

The main (complex) step required is implementing a 2D resampling engine in AVS+ core and next (easy) steps are addition of any possible (practically useful) kernels to it.

"I don't know why the JInc plugin is reverted under AVS 2.0."

May be it was in the very beginning of development and was not ported to AVS+ core because of too many issues at that time ? Though from 2013 - If someone does the hard yards and submits some working code I am happy to include it in a future version.

First AVS version of 2D resampler (with example of Jinc weighted by Jinc kernel named JincResize) dated of November 2013 - https://forum.doom9.org/showthread.php?p=1655610#post1655610

[Jamaika]

Thanks for answer. I did for c++17 as best could. If there are any modifications let us know.

For those willing. How to run vsTBilateral? Test wiki.
http://avisynth.nl/index.php/VsTBilateral

vsTBilateral(diameterY=5, diameterU=5, diameterV=5, sdevY=1.4, sdevU=1.4, sdevV=1.4, idevY=7.0, idevU=7.0, idevV=7.0, csY=1.0, csU=1.0, csV=1.0, d2=false, kerns=2, kerni=2, restype=0, y=3, u=3, v=3)
Assertion failed: IsClip(), file interface.cpp, line 827

[pinterf]

Hi, dear early adopters :),

Please take a look at this test release and give it a try. We would appreciate your feedback, especially if you find any incompatibilities.

There are significant internal changes, including support for 64-bit integers and doubles, as well as v11 interface additions and modifications. (Just making proper thematic commits from the already finished code took a day!)

Thanks.
(reuploaded after a hotfix)
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4173

Changes (please read it):
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new

[tormento]

Hi, dear early birds
Tried, just for fun. :p

LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\DehaloAlpha\Dehalo_alpha.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\Dither\mt_xxpand_multi.avsi")
Import("D:\Eseguibili\Media\StaxRip\Apps\Plugins\AVS\FineDehalo\FineDehalo.avsi")
DGSource("M:\In\Attack on titan ~858p Dynit\1-04.dgi")
z_ConvertFormat(resample_filter="Bicubic", pixel_type="yuv420p16")
Resize8(1526,858, kernel="z_Spline36Resize", kernel_c="z_Spline36Resize", noring=true, noring_c=true, fullc=true)
z_ConvertFormat(resample_filter="Spline64", pixel_type="yuv444ps")
BM3D_CUDA(sigma=4, radius=3, chroma=true)
BM3D_VAggregate(radius=3)
z_ConvertFormat(resample_filter="spline64",dither_type="error_diffusion",pixel_type="YUV420P16")
FineDehalo(rx=2.2, ry=2.2, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0.6, brightstr=1.0, showmask=0, contra=0.0, excl=true)
libplacebo_Deband(iterations=5,temporal=false, planes=[3,3,3], threshold=6.0)
fmtc_bitdepth (bits=10,dmode=8)
Prefetch(2,6)

Error:

D:\Eseguibili\Media\StaxRip\Apps\Encoders\x265\x265.exe --crf 16 --preset slow --output-depth 10 --level-idc 4.1 --no-high-tier --auto-aq --vbv-bufsize 20000 --vbv-maxrate 20000 --bframes 5 --ref 5 --keyint 96 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --min-luma 64 --max-luma 940 --overscan show --qpfile "M:\In\Attack on titan ~858p Dynit\1-05.qp" --output "M:\In\Attack on titan ~858p Dynit\1-05.hevc" --input "M:\In\Attack on titan ~858p Dynit\1-05.avs_temp\1-05.avs"

avs+ [INFO]: AviSynth+ 3.7.3 (r4172, master, x86_64)
avs+ [INFO]: 1526x858 fps 24000/1001 i420p10 frames 0 - 34737 of 34738
raw [INFO]: output file: M:\In\Attack on titan ~858p Dynit\1-05.hevc
x265 [INFO]: HEVC encoder version 4.1+79+12-81640d428 [Mod by Patman]
x265 [INFO]: build info [Windows][ICC 20250000][64 bit] 10bit
x265 [INFO]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [INFO]: Main 10 profile, Level-4.1 (Main tier)
x265 [INFO]: Thread pool created using 8 threads
x265 [INFO]: Slices : 1
x265 [INFO]: frame threads / pool features : 3 / wpp(14 rows)
x265 [INFO]: Coding QT: max CU size, min CU size : 64 / 8
x265 [INFO]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [INFO]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [INFO]: Keyframe min / max / scenecut / bias : 9 / 96 / 40 / 5.00
x265 [INFO]: Lookahead / bframes / badapt : 25 / 5 / 2
x265 [INFO]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [INFO]: References / ref-limit cu / depth : 5 / on / on
x265 [INFO]: AQ: mode / str / qg-size / cu-tree : auto / 1.0 / 32 / 1
x265 [INFO]: Rate Control / qCompress : CRF-16.0 / 0.60
x265 [INFO]: VBV buffer / maxrate / init : 20000 / 20000 / 0.900
x265 [INFO]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [INFO]: tools: rskip mode=1 signhide tmvp strong-intra-smoothing lslices=4
x265 [INFO]: tools: deblock sao dhdr10-info


Video encoding returned exit code: -1073741819 (0xC0000005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Start: 12:59:46
End: 12:59:52
Duration: 00:00:05

[pinterf]

Video encoding returned exit code: -1073741819 (0xC0000005)


Big thanks, this is what I thought of.

Did it start or crashed immediately upon loading the avs script? (I can see that 0:05 is shown, so it has started?)

As the list of the plugins and scripts is a little bit too long to understand what failed exactly, can you comment out this and that from your script and run it again.

Meanwhile I try to grab those tools and scripts you are using.

[tormento]

Did it start or crashed immediately upon loading the avs script? (I can see that 0:05 is shown, so it has started?
AFAIK it didn't process even a single frame. The initial delay has to do with my slow PC.

[pinterf]

Thank you, I hope it is fixed now.
EDIT: reuploaded.
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4173

[DTL]

In 2023 we had some issue with not very nice conversion YUV <-> RGB with narrow range and pinterf wrote some fix was made but not applied to AVS. Was it finally added to the latest release (or some previous tests) ? Last note about some work in progress I found https://github.com/AviSynth/AviSynth...ent-1587607946

Test script to check

ColorBarsHD(640, 480, pixel_type="YV24")
ConvertToRGB32(matrix="PC.709")

If issue is present - it creates RGB with > +-1 LSB errors.

In r4173 it looks fixed. But where to find its note in the change log ?

[Emulgator]

Many thanks, pinterf !
First impressions on Win10P64, CPU i9-11900K, GPU RTX3080, 128GB RAM:
AviSynth.dll r4173 (06.02.2025 17:10) 64bit, AvsPmod64 2.7.8.9: Known-to-be-working-under-r4066 script (larger stuff, RIFE etc.): Crash on first loading (F5)
Well, even with empty plugins folder: Silent crash.
AviSynth.dll r4173 (06.02.2025 16:56) 32bit, AvsPmod32 2.7.8.9: Known-to-be-working-under-r4066 script: Loads ok.

P.S. AVSMeter64 found PlanarTools.dll (2016-07-05) guilty.
Lets see. Why the r4173 64bit crash with empty plugins folder ?
Renamed that PlanarTools.dll to .dead
r4173 64bit still crashes on simple loading of a framecounter script.

XP32ProSP3 and Win7U64 tests to follow as I get access to these systems again.
If all works nicely, a donation of mine is in order.

[FranceBB]

In r4173 both x86 and x64 Avisynth seem to be complaining about the old PlanarTools.dll

x64

'C:/Program Files (x86)/AviSynth+/plugins64+/PlanarTools.dll' plugin loading error:
Unknown exception

x86

'C:/Program Files (x86)/AviSynth+/plugins+/PlanarTools.dll' plugin loading error:
Unknown exception


Verified on both Windows 10 Enterprise x64 and Windows XP Professional x86.

[Emulgator]

That fits. I just see that within 32bit AviSynth I had my 32bit PlanarTools (05.07.2016) deactivated some years ago because of incompatibilities.
So there couldn't have been complaints in 32bit world here today.
Ah... Could it be that the 64bit PlanarTools still hangs around in RAM here and hampers the innocent new AviSynth ?

Power cycling soon...
Well, did not help, not even ColorBars() can be invoked here in AviSynth.dll r4173 (06.02.2025 17:10) 64bit, AvsPmod64 2.7.8.9

[pinterf]

In r4173 both x86 and x64 Avisynth seem to be complaining about the old PlanarTools.dll
How old? Could you please upload it somewhere?

[Emulgator]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these PlanarTools.dlls are not the main culprit, although they may be.
They expect MS VisualC++ 2015 and SSE2 or crash, SSSE3 for RGBtoRGB or fallback.

For x64 I went back to your r4066 and all is peachy.

[Jamaika]

I see that tests have already started. :D
exprfilter.cpp: In member function 'void Exprfilter::calculate_lut(IScriptEnvironment*)':
exprfilter.cpp:4403:32: error: 'avs_malloc' was not declared in this scope; did you mean '_mm_malloc'?
4403 | d.luts[plane] = (uint8_t *)avs_malloc(lut_size, 32); // 256 lut_x 65536: lut_xy (8 bit)
| ^~~~~~~~~~
| _mm_malloc
exprfilter.cpp: In destructor 'virtual Exprfilter::~Exprfilter()':
exprfilter.cpp:4658:19: error: 'avs_free' was not declared in this scope
4658 | if(d.luts[i]) avs_free(d.luts[i]); // aligned free
| ^~~~~~~~
Problem name Cache:
x86inc.asm:31: error: private_prefix not defined
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o):cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o):svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here

[pinterf]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these are not the main culprit. For x64 I went back to your r4066 and all is peachy.
Yep, I'm looking into the Avspmod issue.
(for myself: Avspmod is calling avs_release_value on an array, I don't understand why. The array has two elements, the first is a string containing the whole text of the script, the second is the full path with filename of the script.)
EDIT:
the array [script, filename] on which avs_release_value is called is assembled here:
self.clip = self.env.invoke('Eval', [script, filename])
EDIT2:
Issues are not enabled on AvsPMod repo, so I started a discussion:
https://github.com/gispos/AvsPmod/discussions/16

[pinterf]

These are Chikuzen's PlanarTools.dlls 0.3.0 from 05.07.2016, x86 from 00:28 and x64 from 00:30
https://github.com/chikuzen/PlanarTools/releases

BTW, these PlanarTools.dlls are not the main culprit, although they may be.
They expect MS VisualC++ 2015 and SSE2 or crash, SSSE3 for RGBtoRGB or fallback.

For x64 I went back to your r4066 and all is peachy.
0.3.0 is not good, using the forbidden-to-use internal interface (IScriptEnvironment2*) of Avs+.
It was fixed
https://github.com/chikuzen/PlanarTools/commit/5b58b579fda1db589574042e7b45df507a27fb23
but 0.3.1 was never released.

Btw, this Avisynth build already contains wonkey-monkey's request, that a bad plugin would cause instant crash, instead of silently do nothing and poor developer/script writer debugs for days to detect why it does not work.

This is why it crashed upon the plugin autoloading process.

[pinterf]

I see that tests have already started. :D
exprfilter.cpp: In member function 'void Exprfilter::calculate_lut(IScriptEnvironment*)':
exprfilter.cpp:4403:32: error: 'avs_malloc' was not declared in this scope; did you mean '_mm_malloc'?
4403 | d.luts[plane] = (uint8_t *)avs_malloc(lut_size, 32); // 256 lut_x 65536: lut_xy (8 bit)
| ^~~~~~~~~~
| _mm_malloc
exprfilter.cpp: In destructor 'virtual Exprfilter::~Exprfilter()':
exprfilter.cpp:4658:19: error: 'avs_free' was not declared in this scope
4658 | if(d.luts[i]) avs_free(d.luts[i]); // aligned free
| ^~~~~~~~
Problem name Cache:
x86inc.asm:31: error: private_prefix not defined
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o):cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o):svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
collect2.exe: error: ld returned 1 exit status
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
c:/gcc1150/bin/../lib/gcc/x86_64-w64-mingw32/11.5.0/../../../../x86_64-w64-mingw32/bin/ld.exe: lib\avisynth_x64.a(cache.o) :cache.cpp: (.text+0x290): multiple definition of `Cache::~Cache()'; lib\libvmaf_x64.a(svm.o) :svm.cpp: (.text+0xd60): first defined here
I hope you are using our CMake build environment.
EDIT.
When you compile together 100000000 different projects, don't surprise that the 'rarely used' Cache class name occurs in multiple places, like in libvmaf_x64 (what is it??? Avisynth related? No.) as well. Please don't report nonexistant bugs which are not bug and error, and don't make me spend more time on your "reports", which has approximately 9 out of 10 is just like trolling. Thanks in advance.

[Jamaika]

I've dealt with problems. The new avisynth works. Is it better? I'll leave that to the professional.
I treat my ffmpeg creation as a toy.

https://github.com/AviSynth/AviSynthPlus/commit/528b67805ae218c08703ef71dd0cbce5bd7335b2
https://www.sendspace.com/file/k3qy6x

[FranceBB]

0.3.0 is not good, using the forbidden-to-use internal interface (IScriptEnvironment2*) of Avs+.
It was fixed
https://github.com/chikuzen/PlanarTools/commit/5b58b579fda1db589574042e7b45df507a27fb23
but 0.3.1 was never released.

Thank you Grandmaster Ferenc, as always, for the explanation and for pointing me to the right direction! :)
I relinked to the new Avisynth 3.7.4 r4173 header and used the latest master which includes commit 5b58b57 to create the new builds. It works! :D

x64 Avisynth 3.7.4 r4173
https://i.imgur.com/zK6ye97.png

x86 Avisynth 3.7.4 r4173
https://i.imgur.com/gsqZ373.png

They expect MS VisualC++ 2015

I built statically this time with v143 (MSVC - Visual Studio 2022).
In case anyone needs those: https://github.com/FranceBB/PlanarTools/releases/download/0.3.1/PlanarTools-0.3.1.zip


Chikuzen repository: https://github.com/chikuzen/PlanarTools
Temporary builds: https://github.com/FranceBB/PlanarTools/releases


There are 4 folders:

- x86
- x64
- x86_xp
- x64_xp

The normal ones are compiled with v143 and linked statically, the XP ones are compiled with v141_xp and /Zc:threadSafeInit and they're also linked statically, however it seems to be complaining about ReleaseSRWLockExclusive, AcquireSRWLockExclusive, WakeAllConditionVariable and SleepConditionVariableSRW when running on XP.

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

Any other hint for the XP builds, Grandmaster Ferenc?

[Emulgator]

Continuing testing r4173 x64 on VirtualDub64 44282:
Framecounter works, ColorBars works.
filepaths derived via AviSynth internal functions: The filename "The Young BD Lens Correction AVS+64.avi.avs" comes out reversed:
NO SUCH FILE: E:\5_PREPROC\sva.iva.46+SVA noitcerroC sneL DB gnuoY !

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("LWLibavAudioSource", 3)
SetFilterMTMode("DGSource", 3)
SetFilterMTMode("InpaintDelogo", 3)
scriptextlen=FindStr(RevStr(ScriptFile()),".")
vidextlen=FindStr(RevStr(LeftStr(ScriptFile(),StrLen(ScriptFile())-scriptextlen)),".")
vidfolder=ScriptDir()
audfolder=vidfolder
vidfile=LeftStr(ScriptFile(),(StrLen(ScriptFile())-scriptextlen-vidextlen))
audfile=vidfile
vidext=LeftStr(RightStr(ScriptFile(),scriptextlen+vidextlen),vidextlen)
vidsrc= vidext==".d2v" ? "MPEG2Source" : vidext==".dga" ? "AVCSource" : vidext==".dgi" ? "DGSource" : "LWLibavVideoSource"
audext=vidext==".d2v" ? ".ac3" : vidext==".dgi" ? ".ac3" : vidext
audpid= vidext==".d2v" ? " T80 2_0ch 224Kbps DELAY 0ms" : vidext==".dgi" ? " PID 1100 2.0ch 48KHz 192Kbps DELAY 0ms" :""
#audpid= vidext==".d2v" ? " T81 3_2ch 448Kbps DELAY 0ms" : vidext==".dgi" ? " T81 3_2ch 48KHz 448Kbps DELAY 0ms" :""
audsrc= audext==".ac3" ? "NicAC3Source" : audext==".mp4" ? "LWLibavAudioSource" : "LWLibavAudioSource"
#audsrc="BestAudioSource"
Exist(String(vidfolder)+String(vidfile)+String(vidext)) ? Apply(vidsrc,String(vidfolder)+String(vidfile)+String(vidext))\
: Assert(false, "NO SUCH FILE: " + String(vidfolder)+String(vidfile)+String(vidext) + " !")
Exist(String(audfolder)+String(audfile)+String(audpid)+String(audext)) ? AudioDub(last,Apply(audsrc,String(audfolder)+String(audfile)+String(audpid)+String(audext))) : last
#++++++++++ End of AutoPath script head ++++++++++++

This snippet works under r4066

Hrm. The filename
vts_01_1.d2v.avs
works fine in r4173. Are spaces the problem ? Seems so. The first space in <filename> seems to break it by reversing the string.

[VoodooFX]

Issues are not enabled on AvsPMod repo, so I started a discussion:
https://github.com/gispos/AvsPmod/discussions/16

I think gispos doesn't know that such thing exists at github.
Better post at https://forum.doom9.org/showthread.php?t=175823

[Jamaika]

Testing further news.
The latest version of avisynth does not like the latest version of l-smach.
https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/commit/7dc8ba9295aafa5e99a59903cdd62c4fffc512a5
https://github.com/AviSynth/AviSynthPlus/commit/528b67805ae218c08703ef71dd0cbce5bd7335b2

LWLibavAudioSource("input.mp4")
Assertion failed: IsArray() && index>=0 && index<array_size, file interface.cpp, line 975

[tormento]

Thank you, I hope it is fixed now.
Tested and working for that script.

Speed is on par with 4096 version.

P.S: I saw that many plugings from Asd-G are still based on 2.5 header, even if from last year or so. Is it a bug from AVSMeter or a tragic reality? ;)

[pinterf]

Tested and working for that script.

Speed is on par with 4096 version.

P.S: I saw that many plugings from Asd-G are still based on 2.5 header, even if from last year or so. Is it a bug from AVSMeter or a tragic reality? ;)

The C plugins have traditionally used different numbering, which is a bit more coarse than the actual interface version they support. This 2.5 version is different from an older C++ plugin version 2.5.

Anyway, I plan to update AVSMeter (I use it frequently). This update is necessary because C plugins will also be updated; there is a new entry point that signals 64-bit data compatibility.

[wonkey_monkey]

Anyway, I plan to update AVSMeter (I use it frequently).

Any feasibility of registering it so it appears as a right-click option for .avs files?

[pinterf]

Continuing testing r4173 x64 on VirtualDub64 44282:
Framecounter works, ColorBars works.
filepaths derived via AviSynth internal functions: The filename "The Young BD Lens Correction AVS+64.avi.avs" comes out reversed:
NO SUCH FILE: E:\5_PREPROC\sva.iva.46+SVA noitcerroC sneL DB gnuoY !

Thank you for the report. The issue originated from a commit on April 17, 2024, which introduced the string cache.

Previously, RevStr would first store the string and then reverse it. However, if the string was already stored, it did not create a duplicate, causing the previously stored variable to be overwritten.

This has been fixed by making a safe copy of the string before performing the operation.

A similar bug occurred with UCase and LCase, which have now been fixed as well.

I'm gonna prepare a new build.

[pinterf]

Any feasibility of registering it so it appears as a right-click option for .avs files?
And supporting GetAudio as well. I missed it badly.

[Emulgator]

The issue originated from a commit on April 17, 2024, which introduced the string cache.
Beautiful, nice find !

[pinterf]

Thank you Grandmaster Ferenc, as always, for the explanation and for pointing me to the right direction! :)
I relinked to the new Avisynth 3.7.4 r4173 header and used the latest master which includes commit 5b58b57 to create the new builds. It works! :D

The normal ones are compiled with v143 and linked statically, the XP ones are compiled with v141_xp and /Zc:threadSafeInit and they're also linked statically, however it seems to be complaining about ReleaseSRWLockExclusive, AcquireSRWLockExclusive, WakeAllConditionVariable and SleepConditionVariableSRW when running on XP.

Any other hint for the XP builds, Grandmaster Ferenc?
You have statically linked, but even with dynamic linking, Windows XP requires the system to use the last XP-compatible VC++ redistributable, not the latest one. You will likely need to choose a specific version: 14.28.29213.0 is the last compatible version, as newer versions result in errors due to missing APIs.

For more information,
https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170
Or at our github repo:
https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Prerequisites/keep.me

[pinterf]

Early adopter test version with a ten-month regression fix:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4176

Changes (since last real release):
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#what-s-new-in-the-api-v11