AviSynth+ thread Vol.2

[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)