Avisynth+

[MysteryX]

Why do you need a whole class simply to write a utility function? Just write a simple function that just uses a switch statement to return the value based on the integer.
Switch or if's is what I used to do, but with all the new data formats, it's getting very messy.

[JoeyMonco]

Switch or if's is what I used to do, but with all the new data formats, it's getting very messy.

I fail to see how it's less messy than your solution which is an over-engineered mess. The switch statement in C is entirely created to do what you want which is to map some action to an integeral value.

This isn't Java where you need an abstract factory factory builder simply to create a one-off utility function.

[MysteryX]

I fail to see how it's less messy than your solution which is an over-engineered mess. The switch statement in C is entirely created to do what you want which is to map some action to an integeral value.
I want to know BitsPerComponent of the destination format passed as a string. How am I to know whether it's 8-bit, 10-bit or 16-bit? It could be YV12, YUV444P10, YUVAP16... doing it the "if" or "switch" way is a direct road to hell. If you want to write long series of conditions each time you want to do such an operation, then go ahead, but I'm not going down that road.

[JoeyMonco]

And why do you need to pass the format as a string? What are you doing that you actually need the string for? What purpose is the string serving that can't be served by passing through the enum value? It sounds like you're inventing an over-complicated solution to an imaginary problem.

[wonkey_monkey]

So you want the integer output of BitsPerComponent to be turned into a string? Ok.

I think he meant "I want to know BitsPerComponent of the [destination format passed as a string]", not "I want to know [BitsPerComponent of the destination format] passed as a string."

[JoeyMonco]

I think he meant "I want to know BitsPerComponent of the [destination format passed as a string]", not "I want to know [BitsPerComponent of the destination format] passed as a string."

Okay. :o

Still failing to see the reason why strings need to be passed around instead of the enum value, though.

[MysteryX]

There are many standard functions that take a format as parameter ... or is there? Actually, there is ConvertToY8, ConvertToYV24, ConvertToYUV444, ConvertToRGB32... many different functions, sometimes taking only BitsPerComponent as a parameter. There's got to be other filters taking the format as a string ...

oh yeah, ColorBars, AviSource and CombinePlanes take pixel_type as a string.

[MysteryX]

Pinterf, ConvertFromDoubleWidth and ConvertToDoubleWidth don't support RGB24 and RGB32.

In ConvertToDoubleWidth, add

else if (vi.IsColorSpace(VideoInfo::CS_BGR48)) vi.pixel_type = VideoInfo::CS_BGR24;
else if (vi.IsColorSpace(VideoInfo::CS_BGR64)) vi.pixel_type = VideoInfo::CS_BGR32;


In ConvertFromDoubleWidth, add

else if (vi.IsRGB24())
vi.pixel_type = VideoInfo::CS_BGR48;
else if (vi.IsRGB32())
vi.pixel_type = VideoInfo::CS_BGR64;


I hope you don't mind if I copy/paste ConvertStacked.cpp into my project to avoid dependency?

[MysteryX]

Bug in ConvertBits. If I call ConvertBits(14, dither=-1), it says "dithering is allowed only for 8 bit targets". If I do not specify "dither=-1", then it works.

Also, ConvertFromDoubleWidth supports 10-16 bit, while ConvertToDoubleWidth only supports 16-bit. Code needs to be replaced with this:

if (vi.BitsPerComponent() < 10 || vi.BitsPerComponent() > 16)
env->ThrowError("ConvertToDoubleWidth: Input clip must be 10-16bit format");
else if (vi.Is420()) vi.pixel_type = VideoInfo::CS_YV12;
else if (vi.Is422()) vi.pixel_type = VideoInfo::CS_YV16;
else if (vi.Is444()) vi.pixel_type = VideoInfo::CS_YV24;
else if (vi.IsY()) vi.pixel_type = VideoInfo::CS_Y8;
else if (vi.IsColorSpace(VideoInfo::CS_BGR48)) vi.pixel_type = VideoInfo::CS_BGR24;
else if (vi.IsColorSpace(VideoInfo::CS_BGR64)) vi.pixel_type = VideoInfo::CS_BGR32;
else env->ThrowError("ConvertToDoubleWidth: Input clip must be 10-16bit format");

[MysteryX]

This code causes a crash: "cannot decompress video frame: the video data is too short"

ConvertToYV24()
AddAlphaPlane()
CombinePlanes(planes="RGBA", source_planes="YUVA", pixel_type="RGBAP8")
ConvertToYV24()

This also gives the same error

ConvertToPlanarRGBA()
CombinePlanes(planes="YUVA", source_planes="RGBA", pixel_type="YUVA444P8")


Also, is it normal that CombinePlanes doesn't only cast the planes but inverts the image? If so, that means I have to call FlipVertical again.

[feisty2]

In C# I could easily convert a string to its enumeration value but that won't work in C++.

http://stackoverflow.com/questions/16100/how-do-i-convert-a-string-to-an-enum-in-c

Note that the performance of Enum.Parse() is awful, because it is implemented via reflection. (The same is true of Enum.ToString, which goes the other way.)
If you need to convert strings to Enums in performance-sensitive code, your best bet is to create a Dictionary<String,YourEnum> at startup and use that to do your conversions.


not that much different here, uh?

I also like dynamic features a lot cuz they are handy to use, but I would just go with a completely dynamic programming language like Python if I'm gonna use dynamic features throughout my program

[MysteryX]

not that much different here, uh?
Good to know.

Then, I could create a generic class that automatically builds a dictionary from specified Enum on first use (via reflection), and then does the conversion though the dictionary on all subsequent calls.

But in the case of AviSynth, the Enum is a bit more complicated than that, with combinations of fields, and with names that don't always match format values, so here there's no way around listing all valid formats manually. Plus, it's only 1 Enum, and it's unlikely to change much. If it were 100 Enums that could change and evolve regularly, then it would be a different story.

[feisty2]

But in the case of AviSynth, the Enum is a bit more complicated than that, with combinations of fields, and with names that don't always match format values, so here there's no way around listing all valid formats manually.

if you don't need portable C++ code, you could do reflection tricks in C++ as in C# with CLR under visual studio.

[MysteryX]

Perhaps, but it's kind of getting off-topic -- not providing any value to the topic of Avisynth+. I got the code working already.

[vinnytx]

I have problems with Avisynth+ latest versions and Potplayer.
I use this script to resize my videos while playing
SetMemoryMax(512)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
ffdshow_source()
dispWidth = 1920
dispHeight = 1080
mWidth = float(last.width)
mHeight = float(last.height)
ratio = (mWidth/mHeight)
newHeight= round((dispWidth/ratio)/2)*2
newHeight > dispHeight ? Eval("""
newHeight=dispHeight
newWidth=round((newHeight*ratio)/2)*2
""") : Eval("""
newWidth=dispWidth
""")
spline64resize(newWidth,newHeight)
Prefetch(4)
Videos are "flashing" at the first seconds of reproduction, then they are showed correctly
Here an example. https://www.mediafire.com/?4t75s2m74wuvzj3
The only Avisynth+ version that works well is r1779



Another problem with Potplayer is that I can't hear audio unless I remove TimeStretch.dll plugin.
It appears this error message
http://i.imgur.com/RTyg9aR.jpg



Also, I had to remove ImageSeq.dll plugin because I had many Potplayer crashes with it

[MysteryX]

I'll also mention that I've been seeing an audio/video sync issue with the latest version.. not even sure if it's related to Avisynth version, but I'm just throwing it out there. Has anyone else experience audio/video sync issue? Might be related to VFR as I only have issues with a few videos, and I'm pretty sure it was working fine before. This is when I open the AVS script in MPC-HC to retune the audio to 432hz. That would require more investigation to identify where the issue comes from.

[MysteryX]

CombinePlanes acts weird with a non-planar source such as RGB32. It should instead return an error and require planar input.

[amayra]

I'll also mention that I've been seeing an audio/video sync issue with the latest version.. not even sure if it's related to Avisynth version, but I'm just throwing it out there. Has anyone else experience audio/video sync issue?
i try few video no problem have been found with latest version so far :confused:

[pinterf]

CombinePlanes acts weird with a non-planar source such as RGB32. It should instead return an error and require planar input.
Weird means ........ /fill the missing words/ :)

[pinterf]

Bug in ConvertBits. If I call ConvertBits(14, dither=-1), it says "dithering is allowed only for 8 bit targets". If I do not specify "dither=-1", then it works.
Thanks, fixed.

Converting String to VideoInfo:: pixel_type integer: Invoke this script function:
int ColorSpaceNameToPixelType (string ColorSpaceName)

[pinterf]

I have problems with Avisynth+ latest versions and Potplayer.
[...]
Another problem with Potplayer is that I can't hear audio unless I remove TimeStretch.dll plugin.
It appears this error message
[...]
Also, I had to remove ImageSeq.dll plugin because I had many Potplayer crashes with it
These Avisynth+ plugins that are normally found in plugins+ directory, are planned to be used together with specific avs+ version. From time to time, internal interface can change, not too frequently but changes. Since 17xx version there was two or three jumps in IScriptEnvirontment2 (this is that special interface), maybe these external plugins rely on that and break if e.g. an old external avs+ plugin is used with a new avs+ core.
That's why after a lot of dev build I made a release on r2420 and compiled those plugins again and have put them into the pack.

Well, but if you have handled the dll's together with avs+ core, and the problem still occurs then ... I don't know. Maybe Groucho's excellent AVSMeter tool can show you other issues with your plugins or installation.

[MysteryX]

Thanks, fixed.
Converting String to VideoInfo:: pixel_type integer: Invoke this script function:
int ColorSpaceNameToPixelType (string ColorSpaceName)
That function already exists? What versions of Avisynth support it?

Because I have to write code that works both on Avisynth 2.6 and Avisynth+.

Also need the opposite: int to string. I guess calling Clip.PixelType does the job, since VideoInfo only returns an int.

[MysteryX]

Out of curiosity, what is the performance cost of calling a function via env->Invoke, in comparison to, say, a conversion via reflection in .NET?

[StainlessS]

If env->Invoke called in your constructor then no problem, however if filter then it's constructor called at every invocation and so will
perform similar to within ScriptClip, with constructor overhead at every frame if called from within GetFrame().
No idea about .NET stuff.

EDIT: But without the script parsing overhead of ScriptClip.

[real.finder]

MysteryX

I think PixelType() is what you want, can work in avs26 and avs+ and return string

[MysteryX]

Weird means ........ /fill the missing words/ :)
It's hard to find the words but... I think "weird" is the right word.

https://s20.postimg.org/57pq6wqop/Combine_Planes1.jpg (https://postimg.org/image/57pq6wqop/)

ConvertToRGB24()
CombinePlanes(planes="YUV", source_planes="RGB", pixel_type="YUV444P8")

https://s20.postimg.org/l78dqgmqh/Combine_Planes2.jpg (https://postimg.org/image/l78dqgmqh/)

Destination format complains if you specify a non-planar format, so it would be consistent to apply the same restriction for the input format.

Converting String to VideoInfo:: pixel_type integer: Invoke this script function:
int ColorSpaceNameToPixelType (string ColorSpaceName)
I still don't know if Avisynth 2.6 supports this but this is not something that should need to be exposed to the script interface. Scripts work purely with format as string and never see the underlying int. Only the c++ interface needs to work with the int value, so the only place that makes sense to do such a conversion is in the header file or custom c++ code.

I think PixelType() is what you want, can work in avs26 and avs+ and return string
Yes this has been mentioned already. Converting the other way to get an int, however, is different.

Also, ConvertToYV24() on YUVA444P8 isn't converting it to YUV444P8.

By the way, CombinePlanes is making things a lot easier for me. I wasn't sure about the components order in AvisynthShader... it is RGBA in 8-bit and BGRA in 16-bit. Now that's easy to deal with.

[pinterf]

It's hard to find the words but... I think "weird" is the right word.

ConvertToRGB24()
CombinePlanes(planes="YUV", source_planes="RGB", pixel_type="YUV444P8")

Destination format complains if you specify a non-planar format, so it would be consistent to apply the same restriction for the input format.
Ahhh, thanks, good catch, never tried CombinePlanes with packed rgb inputs, while giving a different, but planar output type.
I decided that packed RGB inputs will be silently converted to planar rgb variant, to make the function transparent for the user. (The same logic is already working in ExtractR,G,B,A)

[Groucho2004]

@pinterf
I was doing some testing with AVS+ last night and noticed that some error messages thrown in case of plugin problems are still very cryptic and not helpful.
For example, the same error message ("There is no function named...") is thrown if:

A function from 64 bit plugin in the 32 bit auto-load directory is used
*or*
The runtimes for a specific plugin are not installed

Tracking the error can be difficult, especially for people who are not so technically versed. There are hundreds of posts on this forum that can be traced back to missing runtimes. It's not difficult to test for bitness and missing dependencies prior to Loadplugin()/LoadLibraryEx(). If you are interested in implementing these tests you are welcome to re-use the code I already have in AVSMeter.

[LigH]

Plus, I just had a case of an error 0xc1 loading LSMASHSource.dll in MeGUI (using AviSynth+ as internal copy) in the German doom9/Gleitz forum, which could be solved by forcing a re-installation of L-SMASH Works in the MeGUI updater; the reason was a bit unclear, may have been a manual substitution with a 64-bit version of the DLL while MeGUI uses a 32-bit environment.

Until now, I was not even successful in discovering which category of errors this code 0xc1 belongs to. (May it be similar to Pascal's DosError?)
_

P.S.: Searching for the decimal value (193): MSDN System Error Codes (https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx)

ERROR_BAD_EXE_FORMAT
193 (0xC1)

%1 is not a valid Win32 application.

Apparently confirms.

[MysteryX]

Now this is weird.

My script plays fine in MPC-HC or VirtualDub. When opening in Windows Media Player, however, it crashes.


LWLibavVideoSource("video.mp4", cache=False)
ConvertToShader()


Script error: Invalid arguments to function 'ConvertToShader'. !?? It plays perfectly fine in MPC-HC. What's going on here?

That error might be of something else going on within the filter as it was crashing on the constructor at this line so I commented it


if (!vi.IsY() && !vi.Is420() && !vi.Is422() && !vi.Is444() && !vi.IsRGB())
env->ThrowError("ConvertToShader: Source format is not supported.");


Source is YV12.

[tormento]

New Features

[…]

Video SDK 8.0

High-bit-depth (10/12-bit) decoding (VP9/HEVC)

Another mosaic tile?

[shekh]

After applying ConvertAudioToFloat the audio still appears as 16-bit integer in VirtualDub.
Can it output PCM_FLOAT format? Tried with r2375.

[Groucho2004]

After applying ConvertAudioToFloat the audio still appears as 16-bit integer in VirtualDub.
What does AVSMeter report (AVSMeter script.avs -i)?

[shekh]

What does AVSMeter report (AVSMeter script.avs -i)?


AVSMeter 2.4.9 (x86) - Copyright (c) 2012-2017, Groucho2004
Query Avisynth info...
AviSynth+ 0.1 (r2375, MT, i386) (0.1.0.0)
Query system info...
Loading script...
Number of frames: 720
Length (hh:mm:ss.ms): 00:00:30.030
Frame width: 720
Frame height: 400
Framerate: 23.976 (2500000/104271)
Colorspace: BGR64
Audio channels: 6
Audio bits/sample: 32 (Float)
Audio sample rate: 48000
Audio samples: 1441442

[Groucho2004]

It may be the same problem I had in AVSMeter where it did not return the correct audio bits/sample in some cases. I'm now using VideoInfo::sample_type which seems to work fine.

[shekh]

I am looking at vfw interface where format is described by WAVEFORMATEX.

[StainlessS]

After applying ConvertAudioToFloat the audio still appears as 16-bit integer in VirtualDub.
Can it output PCM_FLOAT format? Tried with r2375.

Shekh, is below what you are after ?


OPT_AllowFloatAudio
global OPT_AllowFloatAudio = True
This option enables WAVE_FORMAT_IEEE_FLOAT audio output. The default is to autoconvert Float audio to 16 bit.

OPT_UseWaveExtensible
global OPT_UseWaveExtensible = True
This option enables WAVE_FORMAT_EXTENSIBLE audio output. The default is WAVE_FORMAT_EX.
Note: The default DirectShow component for .AVS files, "AVI/WAV File Source", does not correctly implement WAVE_FORMAT_EXTENSIBLE
processing, so many application may not be able to detect the audio track. There are third party DirectShow readers that do work correctly.
Intermediate work files written using the AVIFile interface for later DirectShow processing will work correctly if they use the DirectShow "File
Source (async)" component or equivalent.

OPT_VDubPlanarHack
global OPT_VDubPlanarHack = True v2.60
This option enables flipped YV24 and YV16 chroma planes. This is an hack for early versions of Virtualdub with YV24/YV16 support.

OPT_dwChannelMask
global OPT_dwChannelMask(int v) v2.60
This option enables you to set ChannelMask. It overrides WAVEFORMATEXTENSIBLE.dwChannelMask[[1] which is set according to this table
0x00004, // 1 -- -- Cf
0x00003, // 2 Lf Rf
0x00007, // 3 Lf Rf Cf
0x00033, // 4 Lf Rf -- -- Lr Rr
0x00037, // 5 Lf Rf Cf -- Lr Rr
0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs


On Wiki:-
http://avisynth.nl/index.php/Internal_functions#OPT_AllowFloatAudio

EDIT: Snippet from TwriteAVI doc

See also Avisynth settings for WaveExtensible and Float output for compatible players (otherwise audio may be converted to 16bit on output
from avisynth to a player).

# For Float/WaveExtensible player eg MPC-HC (Else comment out below if Player not capable)
Global OPT_UseWaveExtensible = (AudioChannels>2||AudioBits>16) # If more than 2 channels or > 16 bit, set true (Also Float, ie > 16 bits).
Global OPT_AllowFloatAudio = (IsAudioFloat) # Must be set true to play in eg Media Player Classic - Home Cinema

[shekh]

OPT_AllowFloatAudio


Cool, problem solved :)

[bxyhxyh]

Hello. I'm not always online, so I don't know the progress of AVS+ with AvsPmod. Please tell me about it.

AvsPmod from this post (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148) gives error and crashes when it's starting to launch.Traceback (most recent call last):
File "run.py", line 49, in <module>
File "avsp.pyo", line 18881, in main
File "wx\_core.pyo", line 7981, in __init__
File "wx\_core.pyo", line 7555, in _BootstrapApp
File "avsp.pyo", line 18868, in OnInit
File "avsp.pyo", line 5229, in __init__
File "avsp.pyo", line 6290, in defineFilterInfo
File "avsp.pyo", line 6648, in getFilterInfoFromAvisynth
IndexError: string index out of range

Normal AvsPmod doesn't crash. But it either gives me error "Error loading Avisynth" or red frame when I call ConvertTo16bit()
Is it how it is now? Or there is problem on my end?

[Reel.Deel]

Hello. I'm not always online, so I don't know the progress of AVS+ with AvsPmod. Please tell me about it.

AvsPmod from this post (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148) gives error and crashes.Traceback (most recent call last):
File "run.py", line 49, in <module>
File "avsp.pyo", line 18881, in main
File "wx\_core.pyo", line 7981, in __init__
File "wx\_core.pyo", line 7555, in _BootstrapApp
File "avsp.pyo", line 18868, in OnInit
File "avsp.pyo", line 5229, in __init__
File "avsp.pyo", line 6290, in defineFilterInfo
File "avsp.pyo", line 6648, in getFilterInfoFromAvisynth
IndexError: string index out of range

Normal AvsPmod doesn't crash. But it either gives me error "Error loading Avisynth" or red frame when I call ConvertTo16bit()
Is it how is it now? Or there is problem on my end?

Maybe because AvspMod has not been updated to support AVS+ high bit depth colorspaces. Does your script work if the output is 8-bit.

---

A while back on IRC, Line0 mentioned something about adding high bit depth support to AvsPmod but I don't know if there's been any progress made. Here's an old pull request: https://github.com/AvsPmod/AvsPmod/pull/28

[bxyhxyh]

Yeah it works ok if output is 8-bit.

[Reel.Deel]

Yeah it works ok if output is 8-bit.

Ok, well until AvsPmod gets updated the output video needs to be 8-bit (for preview purposes).

[pinterf]

@pinterf
I was doing some testing with AVS+ last night and noticed that some error messages thrown in case of plugin problems are still very cryptic and not helpful.
For example, the same error message ("There is no function named...") is thrown if:

A function from 64 bit plugin in the 32 bit auto-load directory is used
*or*
The runtimes for a specific plugin are not installed

Tracking the error can be difficult, especially for people who are not so technically versed. There are hundreds of posts on this forum that can be traced back to missing runtimes. It's not difficult to test for bitness and missing dependencies prior to Loadplugin()/LoadLibraryEx(). If you are interested in implementing these tests you are welcome to re-use the code I already have in AVSMeter.
Yes I am (and all of us, "supporters" :) are) interested.

How do you expect Avisynth to give error code on missing dependencies? By the means of debug log? Now if a plugin cannot be loaded (e.g. you put an x64 version in the x86 plugin folder), it does not prevent other plugins from loading properly so we can't raise exception and put a visible error message here. (or should we?)

I haven't checked your code yet, but isn't it slowing down the DLL loading process in general?

[pinterf]

A while back on IRC, Line0 mentioned something about adding high bit depth support to AvsPmod but I don't know if there's been any progress made. Here's an old pull request: https://github.com/AvsPmod/AvsPmod/pull/28
But that PR is from 2013. Is AvsPMod a dead project? And how many AvsMod forks are circulating out there and which one is the latest? It shouldn't be that hard to update it.

[amayra]

But that PR is from 2013. Is AvsPMod a dead project? And how many AvsMod forks are circulating out there and which one is the latest? It shouldn't be that hard to update it.

no one release it to public as far as i know :mad:

[Reel.Deel]

But that PR is from 2013. Is AvsPMod a dead project? And how many AvsMod forks are circulating out there and which one is the latest? It shouldn't be that hard to update it.

Yes that was before AVS+ received native high bit-depth support. If I understand correctly the plan was to add support for the Stack16 formats. Later on there was a brief discussion to support the additional high bit-depth colorspaces in AVS+. I don't know if any progress has been made, I'll ask on IRC.

AvsP (http://www.avisynth.nl/users/qwerpoi/) is the original project and has not been updated in a long time. AvsPmod (r459) is the latest and the the source is available on GitHub: https://github.com/AvsPmod/AvsPmod

I do not know of any other forks or versions floating around.

[qyot27]

Or just use mpv to run the previews.

[amayra]

Or just use mpv to run the previews.

this well take alot of time of you run Mpv for every change you did

[LigH]

How about VirtualDub FilterMod (https://sourceforge.net/projects/vdfiltermod)? It has an integrated script editor and should support high bit depths.

[tuanden0]

How about AVSEdit (https://forum.doom9.org/showthread.php?t=173640)? It work well for avs+.

[Groucho2004]

Yes I am (and all of us, "supporters" :) are) interested.

How do you expect Avisynth to give error code on missing dependencies? By the means of debug log? Now if a plugin cannot be loaded (e.g. you put an x64 version in the x86 plugin folder), it does not prevent other plugins from loading properly so we can't raise exception and put a visible error message here. (or should we?)

I haven't checked your code yet, but isn't it slowing down the DLL loading process in general?
First of all, I would suggest additional checks only if a problem is encountered. For example, checking the correct bitness after the "there is no function..." is thrown is very simple and only takes milli/microseconds. You don't have to dig through my code, I'll send you the relevant stuff.

Checking for dependencies is a bit more complicated but I suppose you only have to do it after the dreaded "... Install missing library?" is thrown and it can all be tucked into one function. Again, I can send you the relevant code.

So, as I see it, none of these checks need to happen during the initial plugin enumeration and there would be no slowdown.

[amayra]

How about VirtualDub FilterMod (https://sourceforge.net/projects/vdubfiltermod)? It has an integrated script editor and should support high bit depths.

i think you post worng link VirtualDub FilterMod (https://sourceforge.net/projects/vdfiltermod/)

[LigH]

Oops, fixed...

[blaze077]

Could anyone tell me why Avisynth gives an error when trying to use the chroma planes of YV12 videos that output a non-mod2 chroma plane but have a mod2 luma resolution?

Resolutions such as: 1760x990 or 1504x846

Script:
BlankClip(240, 1760, 990, pixel_type="YV12").UToY()

"Filter Error: Attempted to request a planar frame that wasn't mod2 in height!"

The BlankClip filter call alone works well.
Thank you.

EDIT: How would one process the chroma separately in this case? UToY() outputs a YV12 video so it cannot be non-mod2. And adding a ConvertToY8() call after UToY() also does not work.

[real.finder]

Could anyone tell me why Avisynth gives an error when trying to use the chroma planes of YV12 videos that output a non-mod2 chroma plane but have a mod2 luma resolution?

Resolutions such as: 1760x990 or 1504x846

Script:
BlankClip(240, 1760, 990, pixel_type="YV12").UToY()

"Filter Error: Attempted to request a planar frame that wasn't mod2 in height!"

The BlankClip filter call alone works well.
Thank you.

EDIT: How would one process the chroma separately in this case? UToY() outputs a YV12 video so it cannot be non-mod2. And adding a ConvertToY8() call after UToY() also does not work.

UToY is old, it's for avs25, use UToY8 is avs26

and in avs+ there are ExtractU

[blaze077]

UToY is old, it's for avs25, use UToY8 is avs26

and in avs+ there are ExtractU
That worked well. Thank you. :)

[tcope]

What am I missing..?

After over a week of scraping the forums wiki etc..
I have been unsuccessful in running avisynth+ on wine.

Fresh compile of 32 bit wine.
Latest 32 bit zeranoe ffmpeg.
vc2010 vc2013 from winetricks
vs2015 redist from installer

Even the recommended: using the old installer from Avisynth+
and copy over current synth files will not run right.

Switching between all the versions found
in the Avisynthrepository, all the other variants work
as expected, except AVSPLUS.

this works
AVSMeter.exe Processing.avs

this crashes @ Analysing script...
AVSMeter.exe Authors.avs.
trimmed list
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
fixme:ntdll:EtwRegisterTraceGuidsW (0x6fa19d, (nil), {f7b697a3-4db5-4d3b-be71-c4d284e6592f}, 7, 0x76069c, (null), (null), 0x760ad0): stub
fixme:ntdll:EtwRegisterTraceGuidsW register trace class {72b14a7d-704c-423e-92f8-7e6d64bcb92a}
fixme:process:GetNumaHighestNodeNumber (0x33cf08): semi-stub
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2
fixme:msvcrt:__clean_type_info_names_internal (0x1489b38) stub
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2
fixme:msvcrt:__clean_type_info_names_internal (0x1489b38) stub
AviSynth+ 0.1 (r2420, MT, i386) (0.0.0.0)
fixme:msvcrt:__clean_type_info_names_internal (0x1489b38) stub

Exception while processing ScriptEnvironment::ThrowError().


I'm guessing there must be some dependency that is either taken for granted
by the vets here and not talked about, or maybe just some brief mention buried
in thread. I believe I have installed all mentioned in first post here.

What ever the cause, I can tell you for those that dont do this
every day, getting this running has been like eating glass.
I have even gone as far as to write a Linux-wine friendly version
of the setavs switcher with the hopes of it helping iron this out.

I am assuming others have this running under wine.?

AVSMeter.exe -avsinfo
VersionString: AviSynth+ 0.1 (r2420, MT, i386)
VersionNumber: 2.60
File version: 0.0.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location:
Avisynth.dll time stamp: Cannot determine timestamp
PluginDir2_5 (HKLM, x86): C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins


[CPP 2.6 / 32 Bit plugins]
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\TCPDeliver.dll [2.6.0.7]
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll

[sl1pkn07]

works for me in Archlinux, 32 and 64 bits avs+ r2420-MT with wine-staging 1.9.21

[qyot27]

At least with Wine 2.2, it looks like no finagling with the redists is necessary for 2013 or prior now - not with winetricks, or the MS installer. The same may or may not be true for 2015 builds, or the old trick of using the MS redist but forcing the .dlls to native,builtin in winecfg might be needed. Whether 2.0 is similarly okay, I don't know.

I just build avsplus with VS2013 so I can avoid the delay/bugs in Wine supporting the newest version of the runtime.

EDIT: although pinterf's MT branch doesn't currently build with VS2013; imghelpers.h errors out.

[tcope]

It looks like the missing dependencies were what
ever core filters have been removed. I had
discounted that, thinking there would be more
informative error messages than just crash.

After dissecting the Authors.avs the offending
component turned out to be this:
messageclip(ovText, height=c)

A posted list of filters that are no longer
included in the core would have likely gone
a long way towards saving sanity.

Thank You all for the feedback.
I have made the Linux bash switcher script
avail for those who may be interested.

I welcome feedback and
hope others find it useful.
Cheers :)
________________________
AVS version Switcher Script (http://criteriondigital.net/setavs.sh.zip)

[Groucho2004]

AVSMeter.exe -avsinfo
VersionString: AviSynth+ 0.1 (r2420, MT, i386)
VersionNumber: 2.60
File version: 0.0.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location:
Avisynth.dll time stamp: Cannot determine timestamp
PluginDir2_5 (HKLM, x86): C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins

Looks like a bunch of Win32 API functions don't work under Wine, it's quite safe to assume that other things in AVSMeter such as the DLL dependency checks don't work either.

[sl1pkn07]

Dependency check throught asvmeter under wine works with MvTools2 2.7.14.22 is FFT3W is not installed, for example.

then i assume this funcionality works ok

also works the version of the plugins in some cases (if has implemented)


┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/breeze-gtk-git]|
└───╼ mv /home/wine-Avisynth/drive_c/windows/syswow64/libfftw3f-3.dll /home/wine-Avisynth/drive_c/windows/syswow64/libfftw3f-3.dll.old
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/breeze-gtk-git]|
└───╼ avsmeter -avsinfo
wine: cannot find L"C:\\windows\\system32\\winemenubuilder.exe"

AVSMeter 2.4.9 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2420, MT, i386)
VersionNumber: 2.60
File version: 0.0.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location:
Avisynth.dll time stamp: Cannot determine timestamp
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[CPP 2.5 / 32 Bit plugins]
C:\Program Files (x86)\AviSynth+\plugins\AddGrainC.dll [1.7.1.0]
C:\Program Files (x86)\AviSynth+\plugins\avstp.dll [1.0.3.0]
C:\Program Files (x86)\AviSynth+\plugins\dfttest.dll [1.9.4.0]
C:\Program Files (x86)\AviSynth+\plugins\dither.dll
C:\Program Files (x86)\AviSynth+\plugins\flash3kyuu_deband.dll
C:\Program Files (x86)\AviSynth+\plugins\LSMASHSource.dll

[CPP 2.6 / 32 Bit plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll
C:\Program Files (x86)\AviSynth+\plugins+\DePan.dll [2.13.1.2]
C:\Program Files (x86)\AviSynth+\plugins+\DePanEstimate.dll [2.10.0.1]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll
C:\Program Files (x86)\AviSynth+\plugins+\ffms2.dll
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll
C:\Program Files (x86)\AviSynth+\plugins+\KNLMeansCL.dll
C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll [2.2.1.0]
C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll [2.7.14.22]
C:\Program Files (x86)\AviSynth+\plugins+\RgTools.dll [0.94.0.0]
C:\Program Files (x86)\AviSynth+\plugins+\SangNom2.dll
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll


[Plugin errors/warnings]
------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth+\plugins\dfttest.dll"

Dependencies that could not be loaded:
libfftw3f-3.dll

Note: "libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

libfftw3f-3.dll must be placed in a directory to which the
'PATH' environment variable points, i.e. System32/SysWOW64"

------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth+\plugins+\DePanEstimate.dll"

Dependencies that could not be loaded:
libfftw3f-3.dll

Note: "libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

libfftw3f-3.dll must be placed in a directory to which the
'PATH' environment variable points, i.e. System32/SysWOW64"

------------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth+\plugins+\mvtools2.dll"

Dependencies that could not be loaded:
libfftw3f-3.dll

Note: "libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

libfftw3f-3.dll must be placed in a directory to which the
'PATH' environment variable points, i.e. System32/SysWOW64"

------------------------------------------------------------------------------
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/breeze-gtk-git]|
└───╼


if can detect the plugins path and version, idk why not detect the path/version of avisynth.dll (or is different implementation?)

greetings

[Groucho2004]

if can detect the plugins path and version, idk why not detect the path/version of avisynth.dll (or is different implementation?)

greetings
I think I figured it out. In order to determine the correct location of avisynth.dll on 64 bit Windows and avoiding file re-direction problems (which happen on some Windows versions) I'm using code that is only supported on a native Windows platform. I'll have a look if I can rectify this.

[LigH]

Also the kind of dependency is different. AviSynth plugins which need libfftw3f-3.dll would use exported functions from within this DLL to be functional at all. But I believe they won't use any function from within avisynth.dll, there is probably no necessary runtime dependency in this direction. Vice versa, avisynth.dll instead uses exported functions from within the plugin DLL's (when used in the script).

[tcope]

PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


The switcher script currently only sets one plugin path.
A second for + is an easy addition.
Am I remembering correctly that multiple plugin
paths are only supported by Avisynth+ ?

Looking for an elegant solution to use a standard
plugin repo along with the unique plugins within
the switcher, but not know enough about the
internal loading mechanism.

Can plugin directories be nested and will all synth
versions look into all sub directories for plugins ?

[Groucho2004]

The switcher script currently only sets one plugin path.
A second for + is an easy addition.
Am I remembering correctly that multiple plugin
paths are only supported by Avisynth+ ?
Correct.


Can plugin directories be nested and will all synth
versions look into all sub directories for plugins ?
No Avisynth version supports nested plugin directories.

[tcope]

I further narrowed the issue with avisynth+ and
the Authors.avs down to this internal function.

+chr(13)+

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)+



none of the authors will render,
but this does run.
ovText = "AviSynth Authors:"

[real.finder]

I further narrowed the issue with avisynth+ and
the Authors.avs down to this internal function.

+chr(13)+

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)+



none of the authors will render,
but this does run.
ovText = "AviSynth Authors:"

just test it with


ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)
MessageClip(ovText)


http://i.imgur.com/eR9RubY.png

work fine in avs26 and avs+ x64, your code is not correct in normal avs26 btw so I did't test it in avs+

[tcope]

I do not have 64 bit wine installed so I can only test 32 bit.

The Authors.avs runs correctly for me in all flavors of avs26
except for avs+ x32.

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)
MessageClip(ovText)

Every combination of options I have tried fails
to run on avs+ x32 until I remove the +chr(13)+

Please share your experience so I can improve compatibility.
your code is not correct in normal avs26 btw so I did't test it in avs+

[videoFred]

Thanks to Groucho's exellent Avisynth installer I discovered Avisynth Plus.
With MT enabled it runs my scripts 3-4 times faster!

:thanks:

Fred.

[StainlessS]

tCope, have you tried replacing Chr(13) with Chr(10) # Carriage Return -> Line Feed.
I personally would never use Chr(13) for such a task.

EDIT: On AVS v2.6 standard, both Chr(10) and Chr(13) work as expected.

[tcope]

Thanks for the suggestion, but no joy.
cr(10) and cr(13) work for me in avs.2.6
but neither are working in avs+

[pinterf]

Thanks for the suggestion, but no joy.
cr(10) and cr(13) work for me in avs.2.6
but neither are working in avs+

Hi!

Here is the code for MessageClip
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/source.cpp#L436

There is a GetTextBoundingBox call that establishes the dimensions of a rendered text to get the video width and height. It uses \n for separators.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/text-overlay.cpp#L2569

These codes were not changed since the classic Avisynth versions (aside from an anti-warning int cast)

[qyot27]

MessageClip isn't the thing erroring out. The Authors.avs tcope is referring to is this (https://github.com/AviSynth/AviSynthPlus/blob/MT/distrib/Examples/Authors.avs), which hasn't been updated since 2007. There's something 'clever' that the video block is doing that causes AviSynth+ to crash, and it's not a simple MessageClip invocation. My bet is something in Overlay, given the variable tango going on in there.

[pinterf]

MessageClip isn't the thing erroring out. The Authors.avs tcope is referring to is this (https://github.com/AviSynth/AviSynthPlus/blob/MT/distrib/Examples/Authors.avs), which hasn't been updated since 2007. There's something 'clever' that the video block is doing that causes AviSynth+ to crash, and it's not a simple MessageClip invocation. My bet is something in Overlay, given the variable tango going on in there.

There is a line in the error log:
Exception while processing ScriptEnvironment::ThrowError().


This exception was raised here:
static std::string FormatString(const char *fmt, va_list args)
{
va_list args2;
va_copy(args2, args);
_locale_t locale = _create_locale(LC_NUMERIC, "C"); // decimal point: dot

int count = _vsnprintf_l(NULL, 0, fmt, locale, args);
std::vector<char> buf(count + 1);
_vsnprintf_l(buf.data(), buf.size(), fmt, locale, args2);

_free_locale(locale);
va_end(args2);

return std::string(buf.data());
}


There is a _create_locale and _vsnprintf_l call here, I don't know that they are supported in wine or not.

[qyot27]

Wine acts a little differently than a native Windows distribution, but since the crash I was referring to happened on Windows 10, I'd think that the Exception may happen in Windows too, but that error message isn't readily available in Windows unless you dive into a debugging session - in Wine, it's front and center in the Terminal you ran the program from.

EDIT: Somewhat never mind, I updated to r2420 and the crash on Windows disappeared, and I could verify that that Exception error message shows up under Wine 2.2 on Ubuntu 16.10, regardless of trying to use 32-bit or 64-bit.

[tcope]

What ever is happening is deff unique
to avs+ .. all the other versions of avs
run it with no issues.

With absolutely no other changes to
Authors.avs than changing this
ovText = "AviSynth Authors:"+chr(13)+

to this
ovText = "AviSynth Authors:"

it will then run as expected. Granted none of
the author info below that line gets rendered
but the script runs with no issues.

http://criteriondigital.net/Authors.png

[LigH]

I hope there are syntactically correctly following terms after the last "plus". Unfortunately this is omitted in your examples.

[pinterf]

EDIT: Somewhat never mind, I updated to r2420 and the crash on Windows disappeared, and I could verify that that Exception error message shows up under Wine 2.2 on Ubuntu 16.10, regardless of trying to use 32-bit or 64-bit.
I don't know which version was crashing for you, but I fixed bug earlier that could cause crash, for me it was only a garbaged error display, but it would show up as crash under other conditions.
20161222 r2347dev
- Fix: ScriptClip would show garbage text when internal exception occurs instead of the error message

Regarding the wine issue, I will make a special release and post the link to you and tcope.

[wonkey_monkey]

I hope there are syntactically correctly following terms after the last "plus". Unfortunately this is omitted in your examples.

There is this snippet from earlier:

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)

Is it something to do with the placement of the backslash? Doesn't it normally go at the end of a continued line, rather than at the beginning of the continuation?

Since the --------- doesn't show in tcope's screenshot, I'm guessing he's got confused over line continuations.

tcope - post your full working and broken scripts in order to get an accurate diagnosis.

Edit: perhaps by putting the backslash on the beginning of the line, the rest of the line is being ignored?

[LigH]

AviSynth has a rather flexible syntax in this case. From the documentation shipped with AviSynth 2.60:

Continue on next or from previous line: \

Subtitle ("Test-Text")

Subtitle ( \
"Test-Text")

Subtitle (
\ "Test-Text")

What I mean was your quoted snippet, originally by tcope in #3067 (https://forum.doom9.org/showthread.php?p=1798341#post1798341), which I saw as truncated due to the last plus:

ovText = "AviSynth Authors:"+chr(13)+
\ "----------------------------"+chr(13)+

I assume that a few more concatenated strings would follow in the next lines.

[qyot27]

I don't know which version was crashing for you, but I fixed bug earlier that could cause crash, for me it was only a garbaged error display, but it would show up as crash under other conditions.
20161222 r2347dev
- Fix: ScriptClip would show garbage text when internal exception occurs instead of the error message
Yeah, it was a personal build of r2343, so that's more than likely what was going on there.

[pinterf]

Meanwhile real.finder, our script master has found a bug in Merge in 32 bit float.

[qyot27]

Output of Wine 2.2 on Ubuntu 16.10 with the winetest build:
[~:$] wine --version
wine-2.2

[~:$] wine ffplay -i Authors.avs
fixme:advapi:GetCurrentHwProfileA (0x23f770) semi-stub
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
fixme:win:RegisterDeviceNotificationA (hwnd=0x36cb0, filter=0xd3e3c8,flags=0x00000001) returns a fake device notification handle!
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
ffplay version r83188 git-bb7db37 Copyright (c) 2003-2017 the FFmpeg developers
built on Jan 20 2017 12:33:30 with gcc 6.3.0 (GCC)
libavutil 55. 43.100 / 55. 43.100
libavcodec 57. 75.100 / 57. 75.100
libavformat 57. 62.100 / 57. 62.100
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 69.100 / 6. 69.100
libavresample 3. 2. 0 / 3. 2. 0
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
fixme:win:EnumDisplayDevicesW ((null),0,0x364f8c8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x364f8c8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x364f510,0x00000000), stub!
fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",1,0x364f8c8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x364f8c8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),0,0x364f8c8,0x00000000), stub!
fixme:win:EnumDisplayDevicesW ((null),1,0x364f8c8,0x00000000), stub!
nafixme:module:load_library unsupported flag(s) used (flags: 0x00000a00)
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2 0B f=0/0
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 1
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 1
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 1
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 1
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 102
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2 0B f=0/0
fixme:msvcp:_Mtx_init_in_situ unknown flags ignored: 2
[avisynth @ 0023ca80] Exception while processing ScriptEnvironment::ThrowError().
nan : 0.000 fixme:msvcrt:__clean_type_info_names_internal (0x4b89b38) stub
Authors.avs: Unknown error occurred 0B f=0/0
nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
[~:$] fixme:msvcrt:__clean_type_info_names_internal (0x1298c20) stub
fixme:msvcrt:__clean_type_info_names_internal (0x1528360) stub
fixme:msvcrt:__clean_type_info_names_internal (0x1687448) stub
fixme:msvcrt:__clean_type_info_names_internal (0x5a4d4600) stub
fixme:msvcrt:__clean_type_info_names_internal (0xb0f480) stub
fixme:msvcrt:__clean_type_info_names_internal (0xb307a0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x35d1f0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x580cb0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x7f1858) stub
fixme:msvcrt:__clean_type_info_names_internal (0x94cff0) stub
fixme:msvcrt:__clean_type_info_names_internal (0x614770) stub
fixme:msvcrt:__clean_type_info_names_internal (0x5f3710) stub
fixme:msvcrt:__clean_type_info_names_internal (0x5cf760) stub
fixme:msvcrt:__clean_type_info_names_internal (0x1800045a0) stub


Or with the Wine-related messages trimmed out:
[~:$] wine --version
wine-2.2

[~:$] wine ffplay -i Authors.avs
ffplay version r83188 git-bb7db37 Copyright (c) 2003-2017 the FFmpeg developers
built on Jan 20 2017 12:33:30 with gcc 6.3.0 (GCC)
libavutil 55. 43.100 / 55. 43.100
libavcodec 57. 75.100 / 57. 75.100
libavformat 57. 62.100 / 57. 62.100
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 69.100 / 6. 69.100
libavresample 3. 2. 0 / 3. 2. 0
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
[avisynth @ 0023ca80] Exception while processing ScriptEnvironment::ThrowError().
nan : 0.000
Authors.avs: Unknown error occurred 0B f=0/0
nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0

[tcope]

I hope there are syntactically correctly following terms after the last "plus". Unfortunately this is omitted in your examples.

tcope - post your full working and broken scripts in order to get an accurate diagnosis.

The Authors.avs is the file being tested. It is one of several
example test scripts avail for download from the AviSynthPlus
github repo. Here (https://github.com/AviSynth/AviSynthPlus/tree/MT/distrib/Examples)

Here is that Authors.avs script (https://github.com/AviSynth/AviSynthPlus/blob/MT/distrib/Examples/Authors.avs)

[tcope]

32 bit wine

$ uname -r
3.2.0-4-amd64
------------------
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
------------------
$ wine --version
wine-2.0
------------------
wine 'C:\FFMPEG\bin\ffmpeg.exe' -version
ffmpeg version 3.2.2 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.4.0 (GCC)
configuration: --enable-gpl
.
.
.
--enable-zlib
libavutil 55. 34.100 / 55. 34.100
libavcodec 57. 64.101 / 57. 64.101
libavformat 57. 56.100 / 57. 56.100
libavdevice 57. 1.100 / 57. 1.100
libavfilter 6. 65.100 / 6. 65.100
libswscale 4. 2.100 / 4. 2.100
libswresample 2. 3.100 / 2. 3.100
libpostproc 54. 1.100 / 54. 1.100

wine ~/.wine/drive_c/Program\ Files/AVSMeter/AVSMeter.exe -avsinfo
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub

AVSMeter 2.5.0 (x86) - Copyright (c) 2012-2017, Groucho2004
fixme:file:K32GetMappedFileNameA (0xffffffff, 0x220000, 0x33d508, 260): stub
.
.
.
VersionString: AviSynth+ 0.1 (r2423, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\windows\system32\avisynth.DLL
Avisynth.dll time stamp: 2017-02-25, 03:06:06 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins


[CPP 2.6 / 32 Bit plugins]
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\TCPDeliver.dll [2.6.0.7]
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Program Files\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll

------------------
wine ~/.wine/drive_c/Program\ Files/AVSMeter/AVSMeter.exe -i ~/.wine/drive_c/Examples/Authors.avs
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub

AVSMeter 2.5.0 (x86) - Copyright (c) 2012-2017, Groucho2004
.
.
.
Exception while processing ScriptEnvironment::ThrowError().
fixme:msvcrt:__clean_type_info_names_internal (0x1489b38) stub

------------------
wine 'C:\FFMPEG\bin\ffmpeg.exe' -i ~/.wine/drive_c/Examples/Authors.avs ~/example-test-output.mkv
ffmpeg version 3.2.2 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.4.0 (GCC)
.
.
.
[avisynth @ 00256260] Exception while processing ScriptEnvironment::ThrowError().
fixme:msvcrt:__clean_type_info_names_internal (0x4529b38) stub
.wine/drive_c/Examples/Authors.avs: Unknown error occurred

[pinterf]

tcope, qyot27, thanks.
Finally installed a VirtualBox, Ubuntu 16.04, Wine stage, and of course a Midnight commander :) Grouchos's AVS plus installer did the dirty job and started to iterate the problematic line.

It turned out that the functions, I suspected earlier were the culprit.

Before formatting a string, we are querying the buffer size, which is returned by _vsnprintf_l when a null-length buffer size is given.
int count = _vsnprintf_l(NULL, 0, fmt, locale, args);

under Wine, this function returns -1, which is a rather unexpected number here.

Now I'm using this function instead:
int count = _vscprintf_l(fmt, locale, args2);
which works on both Wine and Windows, and the Authors.avs script with the scrolling credits is rendered fine.

You two will get a bonus build to test it.

But only after I have a little glass of wine (red) :)

[LigH]

Oh, well ... "Little Known Facts" about incompletely supported features in a compatibility layer.

Cheers. :) https://cosgan.de/images/smilie/nahrung/n055.gif

[qyot27]

Confirmed, the second winetest .dll works without issues for me.

[tcope]

Woot ..! Is working here as well.
Looking forward to giving it a spin
with production workflow.

TY for working on this and finding a fix.
Cheers :)

[martin53]

Hi pinterf,
forked your Github AviSynthPlus today :cool:
The README.md of the MT branch (also of the AviSynth/AviSynthPlus project, where you probably forked your project) says that the documentation is built with 'Sphinx'.
Do you know anything about that?

I'm asking because I thought I'd have a look if the doc is up do date and maybe I could be useful there...

[pinterf]

Hi pinterf,
forked your Github AviSynthPlus today :cool:
The README.md of the MT branch (also of the AviSynth/AviSynthPlus project, where you probably forked your project) says that the documentation is built with 'Sphinx'.
Do you know anything about that?

I'm asking because I thought I'd have a look if the doc is up do date and maybe I could be useful there...
No, it wasn't me. But this question will soon be answered I think.

Regarding the two important bugfixes (32 bit float Merge and wine compatibility), I will try to do something in this or next week. I was bothered by having a half-done MaskTools, but now I took a big breath of relief.

[qyot27]

Hi pinterf,
forked your Github AviSynthPlus today :cool:
The README.md of the MT branch (also of the AviSynth/AviSynthPlus project, where you probably forked your project) says that the documentation is built with 'Sphinx'.
Do you know anything about that?

I'm asking because I thought I'd have a look if the doc is up do date and maybe I could be useful there...
What's not clear about it?

Like README.md says, install Python, use the pip tool to install Sphinx. Make the desired changes to the .rst files in distrib/docs/english/source, run the Sphinx commands from README.md to regenerate the HTML, view the HTML in your web browser.

[martin53]

What's not clear about it?
I'd mainly like to know if the statement is still true or someone changed the HTML directly after last .rst update (the AviSynth/AviSynth+ project repeatedly became a sudden orphan until it was adopted by someone new, as it appears :D)

Github points most .rst files to be at least 2 years old. But definitely AviSynth+ has been extended since. So it's reasonable to ask this question, no?

[qyot27]

I'd mainly like to know if the statement is still true or someone changed the HTML directly after last .rst update
The simplest answer to that there's no way they could do that. The English* HTML documentation was completely removed from the AviSynth+ source tree (except for the separate FilterSDK directory, but the RST version of that is subsumed into the general documentation, and was updated at the same time as that merge from upstream), so it would be impossible for someone to change the HTML directly. In reality, all of any extant documentation regarding AviSynth+'s newer features has gone directly to the AviSynth+ wiki page on avisynth.nl (http://avisynth.nl/index.php/AviSynth%2B), based on//copy-pasted from the descriptions contained in the thread discussion. If anyone wants to integrate those changes into the RST documentation, feel free to do so.

Github points most .rst files to be at least 2 years old. But definitely AviSynth+ has been extended since. So it's reasonable to ask this question, no?
AviSynth+'s English* documentation (which it inherited from AviSynth 2.6) was officially ported to RST/Sphinx a couple years ago, that's why the dates for most of those files show they were updated two years ago. There was no effort at all in changing the specifics of the documentation beyond simply porting it over (apart from the occasional glaring error that had to be corrected), so the only reasons for it to change would be with post-fork changes from 2.6's docs merged in after-the-fact (https://github.com/AviSynth/AviSynthPlus/commit/9e06f44b2972461d85fb2834e6a73b058c5b9e8e), or the new 'Contributing to AviSynth+' section.

*yes, only the English docs; the original plan was that the rest of the language-specific docs were going to be removed from the source tree since most of them hadn't been updated by classic AviSynth for years (prior to the fork), but if anyone wanted to port them to RST like the English docs had been, that would have been fine and we would likely have kept the newer RST version around or moved them to a separate git repository.

[pinterf]

What is the normal way to add things to the Avisynth+ wiki pages? Is saw in the page history that poor Reel.Deel, practically he alone was doing additions there.

I've never edited Wiki, and I'm feeling the same when I was introduced to git last year and had fears of annihilating other's work if I'm doing something wrong like accidental reformatting, deleting content or whatever.

I'd like to have there new pages for the new or changed avs+ functions, I've already found that there is a template for this. And another one for general info, maybe a new page for filter writers.
I suppose the pages describing classic Avisynth functions and behaviour should not be changed. (And please ignore if my questions are stupid, I had very limited time to deal with this documentation topic, every hours I can spare with your hints or tutorial is welcome)

[qyot27]

I've never edited the avisynth.nl Wiki (and the last time I did edit a Wiki of any sort was probably something on the order of 10+ years ago), so someone else will have to comment on that. But Wikis store the revision history like git does and can be reverted to a previous revision if necessary. The only big thing I can think of is to make sure that the comment box has some hint as to what the change(s) made were, so it shows up in the page history.

[martin53]

What is the normal way to add things to the Avisynth+ wiki pages?
I'll PM to you. A couple of years ago there was a severe problem with spam flooding the wiki, so Wilbert was forced to make changing less easy.

[martin53]

The simplest answer to that there's no way they could do that.
I really hope I don't start a quarrel here, and 1st I must admit I'm new to using Git/Github and I'm afraid the discussion tends to get off topic.
I realized that pinterf is doing many, many valuable things these days, but I feel documentation/installer things become left behind.
So i forked pinterf's Github AviSynthPlus fork and stupid as I am I thought I might work myself into the docs and update here and there.
Now I have the new question on my mind if someone who forks a Guthub project can commit his changes back to the original project without being authorized by the original project's owner? Should I regard AviSynth/AviSynthPlus or pinterf/AviSynthPlus as the most up to date and legitimate current version of AviSynth+?
I could not spot any commits after about Aug 17,2016 to avisynth/AviSynthPlus, but the pinterf repository is much more recent.
With the ideal that everone's contribution is of most use for the community and no one stands in the other's way: where should I start?

Anyone replying: please refrain from criticising anything in the past, but if you can, give hints & explanations on how we can keep the project in good shape.

[blaze077]

What is the correct syntax to use arrays? Or were they removed?

I tried the one specified in this post (https://forum.doom9.org/showthread.php?p=1788529#post1788529) but it seems to give an error in AvsPMod as well as AVSMeter.
Version()
array_variable = [[1,2,3],[4,5,8],"hello"]
n = ArraySize(array_variable)
last

ERROR: Unexpected character "["

Thank you.

[qyot27]

I really hope I don't start a quarrel here, and 1st I must admit I'm new to using Git/Github and I'm afraid the discussion tends to get off topic.
I realized that pinterf is doing many, many valuable things these days, but I feel documentation/installer things become left behind.
So i forked pinterf's Github AviSynthPlus fork and stupid as I am I thought I might work myself into the docs and update here and there.
Now I have the new question on my mind if someone who forks a Guthub project can commit his changes back to the original project without being authorized by the original project's owner? Should I regard AviSynth/AviSynthPlus or pinterf/AviSynthPlus as the most up to date and legitimate current version of AviSynth+?
I could not spot any commits after about Aug 17,2016 to avisynth/AviSynthPlus, but the pinterf repository is much more recent.
If you fork a project on Github, it spawns a copy under your user account. You clone from your user account's copy repository with commit privileges so that you have it locally. You commit the changes locally in a separate topic branch (preferably; it keeps things cleaner), push your commits back to your Github repository, and then issue a pull request to the main repository to allow them to review the commits and propose changes, or if they have no objections or critiques, they can just go ahead and merge the changes into the upstream repo.

AviSynth/AviSynthPlus is the official upstream repository, but it probably shouldn't matter that you told Github to fork it from pinterf's. You can also open pull requests against other users' repositories, if need be.

[pinterf]

The arrays syntax support for script arrays was temporarily removed because I was nit able to not solve compatibility with 2.5 style plugin interfaces. This is the "baked code" problem, in plugins/apps using 2.5 headers the AVSValue constructor and destructor is hardcoded in the header. In avs interface 6 the allocation/deallocation/copy routines are using interface calles and are running finally in the current avisynth core.
I will put it back, at least I intend to provide a build that has arrays but that build won't support 2.5 plugins. I have worked weeks on arrays, so they will come back mne nice day.

[tormento]

I will put it back, at least I intend to provide a build that has arrays but that build won't support 2.5 plugins. I have worked weeks on arrays, so they will come back mne nice day.
I think that 2.5 signed DNR (http://en.wikipedia.org/wiki/Do_not_resuscitate). Please do not sort therapeutic persecution. It's time 2.5 dies of honorable death.

[pinterf]

And another incompatible application if AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.

[tormento]

And another incompatible application if AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.

Latest version was released on 16th February 2015, two years ago.



It's the same problem as with Windows XP or Flash.



Until nobody stopped supporting them (hint: Google), they wouldn't die.

I mean... nobody tells people to stop using Avspmod.. they can stay there with older AVS+ version or AviSynth 2.5.

But why should we?

[martin53]

And another incompatible application is AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.
Latest version was released on 16th February 2015, two years ago.
Umm, more precisely Aug 9, 2015 (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148), but one one hand it's obvious it needs someone who cares or a successor app, and on the other hand: can you name any alternative? Maybe I don't get what you are suggesting with 'Google'.

[pinterf]

Just to inform you what is happening behind the scenes:

On git commits:

Fixed Merge for float formats
ColorBars allows any 4:2:0, 4:4:4 formats, plus RGB64 and all planar RGB.
ColorBarsHD accepts any 4:4:4 formats
ConvertBits dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
Use of parameter "dither_bits": ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling :) I was astonished that dither_bits=6 still resulted in a quite usable image)
dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
Ordered dither to 8bit: SSE2 (10x speed)
(you still cannot dither from 8 or 32 bit source)
ConditionalFilter syntax extension like Gavino's GConditional: no "=" "true" needed


Experimenting/planned (not on git):
- gain back the speed of MP_Pipeline like filters - I did it but I have to find a nicer way.
- perhaps GScriptClip-like parameter passing

[real.finder]

what about add IsVideoFloat() (as there are already IsAudioFloat())? :)

[pinterf]

Or IsDuckFloat?

[real.finder]

Or IsDuckFloat?

LOL, or even IsGooseFloat :P

anyway, I waiting for these changes (the other one here (https://forum.doom9.org/showpost.php?p=1799108&postcount=49)) to seriously start port some scripts (the one I did in MaskTools2 - pfmod thread was for test only)

[mp3dom]

Uhmm, there's surely an error on my side that I can't resolve, but with r2420, the output from UtoY is the same image as VtoY, while UtoY8 and VtoY8 outputs proper different result.
Am I doing something wrong?

[blaze077]

Those functions work well on my side in both the 32 and 64 bit versions of Avisynth+ r2420. UToY() and VToY() output YV12 video if that has anything to do with it. Do you have anything else in your script?

EDIT: UToY() and VToY() output the source colorspace and not YV12 - I was mistaken.

[mp3dom]

I mean, UtoY=VtoY, while UtoY8 != VtoY8 (as expected, since different chroma channels).
So if I separate each channel and then recombine it back, I get wrong colors


y=ConvertToYV12()
u=UtoY().ConvertToYV12()
v=VtoY().ConvertToYV12()
YtoUV(u,v,y)

[pinterf]

I mean, UtoY=VtoY, while UtoY8 != VtoY8 (as expected, since different chroma channels).
So if I separate each channel and then recombine it back, I get wrong colors


y=ConvertToYV12()
u=UtoY().ConvertToYV12()
v=VtoY().ConvertToYV12()
YtoUV(u,v,y)

I was not able to reproduce it. Please test is with Colorbars, and if it works but with your real video still fails, then please upload a short (couple of frames is enough) sample somewhere, thanks.

[tormento]

Umm, more precisely Aug 9, 2015 (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148), but one one hand it's obvious it needs someone who cares or a successor app, and on the other hand: can you name any alternative? Maybe I don't get what you are suggesting with 'Google'.
Chrome stopped supporting Flash and Google told Windows XP browser limitation will make it stop supporting on Gmail and other suite apps.

More: there is hardware out there that has no driver support for platform more recent than XP.

Things have to change, it's law of thermodynamics.

Even more: nobody asks people to stop using AVSPmod. They simply won't have any upgrade to environment.

Just my 2 cents.

[mp3dom]

I was not able to reproduce it. Please test is with Colorbars, and if it works but with your real video still fails, then please upload a short (couple of frames is enough) sample somewhere, thanks.

Yeah, it fails on ColorBars too, on both x86 and x64.

colorbars(width=720,height=480,pixel_type="yuy2")
y=last
u=UtoY()
v=VtoY()

YtoUV(u,v,y)


U channel is a "copy" of the V channel, so I get the same result of:
YtoUV(v,v,y)

However, it seems to fail on YUY2 only, because on YV12, YV16 and YV24 seems to work fine.

[pinterf]

Ah, thanks, that helps. I'll check it.
EDIT:
Thanks for the report. Fixed on git.
YUY2 UToY did not work since August, 2016 (r2150)

[tcope]

For those interested...

A new stable version is avail. Along
with supporting web page.

I highly recommend giving this a spin,
and very much look forward to feedback.

Original post with link
...HERE... (https://forum.doom9.org/showthread.php?p=1798200#post1798200)

Cheers :)

[videoFred]

Hello everybody,

I'm using Avisynth+ with great succes: for example a pretty complex (removedirt(), Mdegrain2() etc...) script that normally runs at 4fps runs now easily at 15fps in MTmode, using all my processor power.

But everytime I start up a script in AvsPmod v2.5.1 (it can be any script, even the most simple AviSource() ), I get this error message:
Error parsing plugin string at position 0:

And when closing AvsPmod, I get this error message:
Traceback (most recent call last):
File "avsp.pyo", line 5404, in OnActivate
File "wx\_core.pyo", line 14619, in __getattr__
wx._core.PyDeadObjectError: The C++ part of the AvsStyledTextCtrl object has been deleted, attribute access no longer allowed.


I'm using Groucho's installer so my plugins are in a specified folder.

Those error messages are not hurting me:p but I wonder why I get them?

PS: I have tried the modified AvsPmod v2.5.1 r452 no more error messages , but this version does not like this:
[Multi Tasking=0]
Prefetch(4)
[/Multi Tasking]

It throws this error message:
Only a single prefetcher is allowed per script

But the only prefetch in the script is this one, at the end as it should be and it works fine with AvsPmod v2.5.1.
I realy need the option to switch MT on/off so I can not use AvsPmod r452.

many greetings,
Fred.

[pinterf]

New release with important bug fixes and interesting enhancements.

Avisynth+ r2440-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2440-MT)

20170310 r2440
- Fix Merge for float formats
- Fix error text formatting under wine (_vsnprintf_l issue)
- Fix Regression: YUY2 UToY copied V instead of U, since August, 2016 (v2150)
- faster Merge: float to sse2 (both weighted and average)
- faster ordered dither to 8bit: SSE2 (10x speed)
- ColorBars allows any 4:2:0, 4:4:4 formats, RGB64 and all planar RGB formats
- ColorBarsHD accepts any 4:4:4 formats
- Dithering: Floyd-Steinberg
Use ConvertBits with parameter dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
- Dithering: parameter "dither_bits"
For dithering to lower bit depths than the target clip format
Usage: ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling I was astonished that dither_bits=6 still resulted in a quite usable image)
- Dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
- Dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
(you still cannot dither from 8 or 32 bit source)
- ConditionalFilter syntax extension like Gavino's GConditional: no "=" "true" needed
- Revert: don't give error for interlaced=true for non 4:2:0 sources (compatibility, YATTA)
- CombinePlanes: silently autoconvert packed RGB/YUY2 inputs to planar
- ConvertBits: show error message on YV411 conversion attempt: 8 bit only
- ConvertBits: Don't give error message if dither=-1 (no dithering) is given for currently non-ditherable target formats
- Script function: IsVideoFloat. returns True if clip format is 32 bit float. For convenience, same as BitsPerComponent()==32
- ConvertToDoubleWidth and ConvertFromDoubleWidth: RGB24<->RGB48, RGB32<->RGB64
- New MT mode: MT_SPECIAL_MT. Specify it for MP_Pipeline like filters, even if no Prefetch is used (MP_Pipeline issue, 2 fps instead of 20)

[Groucho2004]

@pinterf
I noticed that in cpuid.cpp the reported CPU features (AVX, FMA) depend on CPU and OS support. So, if I run "Info()" on XP for example, these new extensions will be hidden even though the CPU has them.
In "Info()", it says "CPU detected:" so is it not a bit misleading? With the OS conditional, should it not rather read something like "CPU features supported by OS"?

[tuanden0]

@pinterf

- New MT mode: MT_SPECIAL_MT. Specify it for MP_Pipeline like filters, even if no Prefetch is used (MP_Pipeline issue, 2 fps instead of 20)

Can you give me an example or document for this?
:thanks:

[pinterf]

@pinterf
Can you give me an example or document for this?
:thanks:
SetFilterMtMode("MP_Pipeline",MT_SPECIAL_MT)

[ryrynz]

Can you list a few MP_Pipeline like filters please?

[pinterf]

@pinterf
I noticed that in cpuid.cpp the reported CPU features (AVX, FMA) depend on CPU and OS support. So, if I run "Info()" on XP for example, these new extensions will be hidden even though the CPU has them.
In "Info()", it says "CPU detected:" so is it not a bit misleading? With the OS conditional, should it not rather read something like "CPU features supported by OS"?
The text now is simply "CPU:", I have made it shorter, there is only a little place, I wanted to fit the feature list in 300-400 pixels wide, which is hard when the capabilities include FMA3, AVX2, etc.

Possible AVX512 extensions are listed in a second line however, there is quite a few of them.

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OS

[pinterf]

Can you list a few MP_Pipeline like filters please?
No, I don't know yet similar filters like MP_Pipeline, but I did not know it either, before the issue had been reported.
Similar filters:
Behaving as source filters because they have no input clip parameter.
Unlike regular source filters, they are internally starting processes in multiple script environments (?)

Unfortunately this mt thing is the most difficult area in avs core, I was not able to understand it 100% (not even near of that) or else I could fix it by rewriting the relevant module.

Basically this option prevents Avisynth core from trying to figure out the effective mt mode of this filter.
I'm not sure that it will work in all situations, but in this specific MP_Pipeline case it works fine.

(When a filter is invoked it may invoke other filters, the core follows the nested invoke list and the effective mt mode is determined by the weakest mt mode, e.g. if there are invokes for filter with an MT_NICE_FILTER and MT_SERIALIZED, the latter will be chosen as the safest mt method. During the process internal MT guard object(s) is(are) created.)

[burfadel]

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OS

Encoding on XP would be a significant slowdown on AVX and AVX2 machines when compared to running Windows 10, not to mention security and other issues. Also unless they're running 64-bit XP you are limited in RAM, which in turn could impinge on encode rate.

Any reason for using XP on a 'modern' AVX CPU?

[Groucho2004]

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OSI know it's mostly semantics and I see your point. However, my opinion is that if you report CPU features, report them all, regardless of OS support
- or -
if you're including OS dependency, phrase it differently like x264 does:
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

[Groucho2004]

Encoding on XP would be a significant slowdown on AVX and AVX2 machines when compared to running Windows 10, not to mention security and other issues. Also unless they're running 64-bit XP you are limited in RAM, which in turn could impinge on encode rate.

Any reason for using XP on a 'modern' AVX CPU?
I was hoping that this wouldn't turn into another OS argument.

[jmac698]

I just wanted to clear up something. Using avx requires OS support. It seems strange at first, but it's because the os has to save the extra registers so they don't get changed between processes. You could try to use it, but the program would mess up the results.

avx requires win7+ I believe.

[jmac698]

I have a question, did you derive the exact values for the high bit depth colour bars? I was the one who got them into avisynth in the first place. Especially the -I value requires some sin() calculations.

ConvertToDoubleWidth
was confusing to me, perhaps ConvertToDoubleDepth ?

[pinterf]

I just wanted to clear up something. Using avx requires OS support. It seems strange at first, but it's because the os has to save the extra registers so they don't get changed between processes. You could try to use it, but the program would mess up the results.

avx requires win7+ I believe.
AVX safe context switching is available from Windows 7 SP1

[pinterf]

I have a question, did you derive the exact values for the high bit depth colour bars? I was the one who got them into avisynth in the first place. Especially the -I value requires some sin() calculations.

ConvertToDoubleWidth
was confusing to me, perhaps ConvertToDoubleDepth ?
The values are scaled from the 8 bit constants. Can you help me with that if it is not correct?

DoubleWidth is a compatibility format ("hack"), sometimes called as interleaved. Format is an Avs2.6 compatible 8 bits one, but internally stores 16bit pixels, thats why the reported width is double than the original. Unlike stacked format its internal layout is the same as Avs+'s high bit depth formats.

[pinterf]

ConvertBits supports ordered and Floyd-Steinberg dithering.
Latter is new, available from r2440. You can dither down to 1-2-4-6-8..14 bits with parameter dither_bits. For restriction see the readme or the release announcement some posts back. Ordered dither is simd optimized.

[ChaosKing]

I started to use the x64 version now and noticed one thing. It's seems it is impossible to autoload avsi script for both 32 and 64 bit.

Would it be a good idea to implement a seperate "script-autoload-folder" in avs+?
This would also make the plugins plugins folder less cluttered.

[Groucho2004]

I started to use the x64 version now and noticed one thing. It's seems it is impossible to autoload avsi script for both 32 and 64 bit.

Would it be a good idea to implement a seperate "script-autoload-folder" in avs+?
This would also make the plugins plugins folder less cluttered.
Judging by your earlier post today I assume that you're using my Avisynth Version Selector which supports separate plugin directories for 64 and 32 bit by default.

[ChaosKing]

Yes. But I would like to have a shared avs script autoload folder, so I don't need to copy my avsi script in both (32 & 64 bit) folders.

The goal is:
Plugins32
Plugins64
Avs-Scripts (witch can be used by 32 & 64 avisynth) <-- missing yet



Edit:
I just found that there is a AddAutoloadDir() function. Will test it...

Edit2:
ok this is working, but it needs to be placed in the scripts header everytime. I guess I can live with that. But a global extra folder like the plugins folder would still be convenient.

AddAutoloadDir("D:\AvisynthRepository\SCRIPTS")

Sadly it does not work when I put a "scriptlaoder.avsi" with the line above in my plugins folder.

[real.finder]

speaking of that

the autoload folder list order now is

PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE

why not like this?

PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER

see here to know why https://forum.doom9.org/showthread.php?p=1789735#post1789735

[pinterf]

Hello everybody,

PS: I have tried the modified AvsPmod v2.5.1 r452 no more error messages , but this version does not like this:
[Multi Tasking=0]
Prefetch(4)
[/Multi Tasking]

It throws this error message:
"Only one prefetcher...."

But the only prefetch in the script is this one, at the end as it should be and it works fine with AvsPmod v2.5.1.
I realy need the option to switch MT on/off so I can not use AvsPmod r452.

Hi Fred, welcome to Avisynth+! I hope we'll solve your problems.

I have downloaded AvsPMod r452, and toggleing the option is working for me.
However when another Prefetch line is present, the "Only one prefetcher is allower per script" error occurs (as expected)
[Multi Tasking=1]
Prefetch(4)
[/Multi Tasking]
Prefetch(4)


Can you check that you don't have another Prefetch somewhere else (for example in an imported avsi)?

[Motenai Yoda]

Looks like someone has to add Is400()/IsYXX or mod IsY() to return true with 8+ Y-only clips too.
edit: I mean >8

[real.finder]

Looks like someone has to add Is400()/IsYXX or mod IsY() to return true with 8+ Y-only clips too.

there are already isy()

[Motenai Yoda]

there are already isy()

converttoy()
converttofloat()
subtitle(PixelType().string()+" "+isY().string())
convertbits(32)
subtitle(PixelType().string()+" "+isY().string(),y=16)
convertbits(16)
subtitle(PixelType().string()+" "+isY().string(),y=32)
convertbits(14)
subtitle(PixelType().string()+" "+isY().string(),y=48)
convertbits(12)
subtitle(PixelType().string()+" "+isY().string(),y=64)
convertbits(10)
subtitle(PixelType().string()+" "+isY().string(),y=80)
convertbits(8)
subtitle(PixelType().string()+" "+isY().string(),y=96)
what did it return to you?

I'll give you an hint...
https://3-t.imgbox.com/6wJJOEc6.jpg (http://imgbox.com/6wJJOEc6)

[real.finder]

converttoy()
converttofloat()
subtitle(PixelType().string()+" "+isY().string())
convertbits(32)
subtitle(PixelType().string()+" "+isY().string(),y=16)
convertbits(16)
subtitle(PixelType().string()+" "+isY().string(),y=32)
convertbits(14)
subtitle(PixelType().string()+" "+isY().string(),y=48)
convertbits(12)
subtitle(PixelType().string()+" "+isY().string(),y=64)
convertbits(10)
subtitle(PixelType().string()+" "+isY().string(),y=80)
convertbits(8)
subtitle(PixelType().string()+" "+isY().string(),y=96)
what did it return to you?

I'll give you an hint...
https://3-t.imgbox.com/6wJJOEc6.jpg (http://imgbox.com/6wJJOEc6)

there are bug then

[pinterf]

Thanks for the report. Fix will come soon. Only the script function was affected, VideoInfo::IsY was O.K.

[tormento]

- Dithering: Floyd-Steinberg
Use ConvertBits with parameter dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
- Dithering: parameter "dither_bits"
For dithering to lower bit depths than the target clip format
Usage: ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling I was astonished that dither_bits=6 still resulted in a quite usable image)
- Dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
- Dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
(you still cannot dither from 8 or 32 bit source)
@real.finder is it of any use in SMDegrain instead of Dither dll?

[pinterf]

New Avisynth build.

Avisynth+ r2455-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2455-MT)

v2455 (20170316), changes since v2440
-------------------------------------
# Fixes
IsY() script function returned IsY8() (VideoInfo::IsY was not affected)

# other modification, additions
ConvertBits, dither=1 (Floyd-Steinberg): allow any dither_bits value between 0 and 8 (0=b/w)


Thanks to Motenai Yoda for the IsY bug report.

[Motenai Yoda]

err... I don't know if it's a bug but
dither=1 to ie 2 bits give 0-64-128-192-255 -> 5 shades

[pinterf]

Sorry, quickly replaced 2454 to 2455, dither=1, dither_bits=any_less_than_8 did not work for 10 bits->10 bits conversion.

[pinterf]

err... I don't know if it's a bug but
dither=1 to ie 2 bits give 0-64-128-192-255 -> 5 shades
Yes, I was also expecting exactly 2^N levels for Floyd, and don't know the reason yet. I extended dither_bits for any <8 bit values to experiment what it looks like after seeing that dither_bits=1 gave me three histogram spikes.
dither_bits=0 -> 2 levels
dither_bits=1 -> 3 levels
dither_bits=2 -> 5 levels
dither_bits=3 -> 9 levels

[real.finder]

@real.finder is it of any use in SMDegrain instead of Dither dll?

no, no convert will done, input = output, but you can do it by your self, there are no need for dither dll without lsb in first place

[Myrsloik]

I HATE YOU ALL

The baked code related to PClip doesn't error out if AVS_Linkage is null. Instead it does nothing. This means that if a PClip (and probably most other objects too) is constructed with null linkage it'll consist of uninitialized memory and will most likely crash if the linkage is set later.

Just crash immediately if this happens, you'll save the world a lot of bugs that way.

[tormento]

no, no convert will done, input = output, but you can do it by your self, there are no need for dither dll without lsb in first place

A bit cryptic to me. :(

[real.finder]

A bit cryptic to me. :(

convertbits(16)
SMDegrain()
convertbits(10,dither=1,dither_bits=8)

[LigH]

Suddenly I am reminded of working in CoolEdit / Audition with Noise Shaping. Just visually now. :D

[real.finder]

I just find this by chance https://github.com/DJATOM/TCPDeliver/releases I put the link since there are no TCPDeliver in avs+

[Motenai Yoda]

A bit cryptic to me. :(

Sta senza pensieri. (cit)

[VS_Fan]

Suddenly I am reminded of working in CoolEdit / Audition with Noise Shaping. Just visually now. :DYou could try fft3dfilter with "noise pattern" (shape). From the description (http://avisynth.org.ru/fft3dfilter/fft3dfilter.html)of the filter:

Using noise pattern

Since v1.5 it is possible to get noise pattern (shape) by spectrum analysis of some empty block (without any objects), and then to reduce the noise with the same pattern in whole frame and in whole clip. It may be useful for removal of film (especially amateur 8 mm) grain and analog TV capture interference.


pframe - noise pattern frame number (default=false)
px - noise pattern block horizontal X position (default=0)
py - noise pattern block vertical Y position (default=0)
if px=px=0, then the pattern block is defined automatically with minimal power spectral density.
pshow - show noise pattern block and its properties (default=false)
pcutoff - noise pattern cutoff frequency (relative to max) (default=0.1)
pfactor - noise pattern denoise strength (0 to 1.0, default=0, this method disabled)


In order to use noise pattern method in place of ordinary (blind) method you must:
Firstly switch show mode pshow=true, and set some non-zero value pfactor=1.0.
Then select frame number and some block position, thus the block shown must not contain any objects beside typical noise pattern.
The switch off show mode pshow=false,
and set noise reduction strength, recomended value pfactor= 0.5 to 1.0.
The best windows type for this method is wintype=2.
The sigma and beta parameters are not used in this denoising method, but you can use this method in show mode pshow=true to estimate sigma value for ordinary denoising method (it is not strictly the same, but similar value).

[LigH]

Well, I just referred to working in high bit depth and finalizing with dithering.

[videoFred]

Hi Fred, welcome to Avisynth+! I hope we'll solve your problems.

That's very kind, thank you in advance :)


Can you check that you don't have another Prefetch somewhere else (for example in an imported avsi)?

No other Prefetch in the script itself and also not in imported avsi files, but I have found the problem. My script is using a function to select the different results with a AvsPmod slider. And here is the problem: with MT enabled I get the "prefetch" error message when selecting another result. So I have to disable MT, then select another result, then enable MT again.

Please try this script and you will get the error message too.

result = (selectresult([<"select result", 0, 3, 1>])) #function selectresult() see end of script

SetFilterMTMode("DEFAULT_MT_MODE", 2)

source= AviSource("Z:\VDP\VdP_Sp2.avi")

A = source
B = source.tweak(sat=2.0)
C = source.converttoRGB().GamMac()
D = source.sharpen(1.0)

eval(result)

[Multi Tasking=0]
Prefetch(4)
[/Multi Tasking]


function selectresult(int index)
{
return Select(index,"A","B","C","D")
}


For some reason prefetch must be called twice when switching results. But only with the r452 version of AvsPmod. It works fine with AvsPmod v2.5.1

Fred.

[pinterf]

Fred, I cannot help you with that at the moment.

Is there anybody out there who can tell that the compilation of the existing AvsPmod project is easy and straightforward?

Now I have some work with masktools, then it seems that there are still a couple of things to investigate.
- Scriptclip mt behaviour
- vdubfilter (deshaker issue at exit)
- PClip thing, that Myrsloik has kindly noticed and possibly presented him some happy hours and turned his hair grey.
- avspmod
...zimg

[MysteryX]

- vdubfilter (deshaker issue at exit)

Isn't that the issue I had fixed?

[olex99]

I've just moved to Avisynth+ from Avisynth 2.6 MT and i'm seeing some weird performance issues.

Using the following script in AviSynth 2.6 MT (x86), I get an average of 4.115fps

SetMemoryMax(2000)
SetMTMode(5, 6)

DGSource("D:\Videos\Video.dgi")

SetMTMode(2)
QTGMC(EdiThreads=1, DftThreads=1).SelectEven()
Trim(0,999)

Using a the following script in AviSynth+ r2455 (x64), I get an average of 2.505fps

SetMemoryMax(2000)

DGSource("D:\Videos\Video.dgi")
QTGMC(EdiThreads=1, DftThreads=1).SelectEven()
Trim(0,999)

Prefetch(6)

I've tried the 32bit version of avisynth+ and see similar performance to the 64bit version.

I've downloaded a MTModes.avsi file, aswell as trying to set the Default MT Mode to 2 and nothing seemed to make a difference.

Any ideas of why I might be seeing such a big difference in speed? I was hoping to move to Avisynth+ 64 bit to utilise more memory to increase performance, setting max memory to 3000 in Avisynth 2.6 MT gets me another 1fps but it crashes as soon as I try encode cause it runs out of memory.

The following plugins are installed (for both x64 and x86):
DGDecodeNV 0.0.0.2052
masktools2 - 2.2.4.0
mvtools2 - 2.7.15.22
nnedi3 - 0.9.4.37
rgtools - 0.95.0.0

Thanks

[pinterf]

Isn't that the issue I had fixed?
Yes, you have partially fixed an issue (https://github.com/pinterf/AviSynthPlus/commit/e5e8bbdca48d9fbd561ae6c6a0f1e90760460a9c), but now it was reported again, this time with a multiple call scenario

Works:
source="test.mp4"
LoadVirtualDubPlugin ("c:\Virtualdub\plugins32\deshaker.vdf", "deshaker", preroll=0)
FFVideoSource(source)
clip=ConvertToRGB32()
clip.deshaker("
12|2|30|4|1.09402|1|1|0|640|480|
1|2|1|400|400|400|1500|4|1|4|2|
5|40|300|4|C:\deshaker.log|0|0|0|0|0|
0|0|0|0|0|0|0|0|1|15|
15|5|15|1|1|30|30|0|0|0|
0|1|0|1|10|1|15|1000|1|88")


Freeze on exit:

source="test.mp4"
LoadVirtualDubPlugin ("c:\Virtualdub\plugins32\deshaker.vdf", "deshaker", preroll=0)
FFVideoSource(source)
clip=ConvertToRGB32()
clip.deshaker("
19|1|30|4|1|0|1|0|1920|1080|
1|2|1000|1000|1000|1000|4|1|0|2|
8|30|300|4|C:\Deshaker.log|0|0|0|0|0|
0|0|0|0|0|0|0|0|1|15|
15|5|15|0|0|30|30|0|0|1|
0|1|0|0|10|1000|1|104|1|1|
20|5000|100|20|1|0|ff00ff")

clip.deshaker("
19|2|30|4|1|0|1|0|1920|1080|
1|2|1000|1000|1000|1000|4|1|0|2|
8|30|300|4|C:\Deshaker.log|0|0|0|0|0|
0|0|0|0|0|0|0|0|1|15|
15|5|15|0|0|30|30|0|0|1|
0|1|0|0|10|1000|1|104|1|1|
20|5000|100|20|1|0|ff00ff")

The difference is that we have two deshaker calls.

[LigH]

^ which appears nonsensical to me, especially if you take the implicit assignment to last into account:

...
clip = ConvertToRGB32()
last = clip.deshaker({ParamSet1}) # ignored due to the following call superseding the output
last = clip.deshaker({ParamSet2}) # this is the call producing the script output

If you want to create a sequence of two calls, which possibly depend on each other, you will have to ensure that both will have an impact on the output clip, and may it just be a merge of 0% and 100% weight. Furthermore, understand that the sequence will run per frame: If you need a first pass to produce a log file, and a second pass to read and process it, you will need two different scripts anyway, or the second call will not find a finished log file because the first call did not yet complete it.

[pinterf]

^ which appears nonsensical to me, especially if you take the implicit assignment to last into account:

Report is from here (https://forum.doom9.org/showthread.php?p=1801511#post1801511)
Anyway, it shouldn't freeze on exit.

[LigH]

I'll post my thoughts there if not yet answered by someone else; for me it looks like the author of this report tried to run a 2-pass sequence in one script, so the second-pass call will have either missed a non-existing log file, or tried to read from an open file being written to (and depending on file sharing modes, this might cause a lock?). So I would not bet on the AviSynth core to be blamed.

[StainlessS]

Small point though, the first calls constructor will be called, even if that filters result is ignored.
EDIT: Is deshaker re-entrant. Perhaps adding a "Last=0" between calls would make freeze disappear, ie call destructor on Last.

EDIT: Post here seems to suggest that log does indeed need to be closed between calls (as per LigH):- https://forum.doom9.org/showthread.php?p=1782998#post1782998
Also of course need complete scan between calls.

[pinterf]

I've just moved to Avisynth+ from Avisynth 2.6 MT and i'm seeing some weird performance issues.

Using the following script in AviSynth 2.6 MT (x86), I get an average of 4.115fps
[...]
Using a the following script in AviSynth+ r2455 (x64), I get an average of 2.505fps
[...]
Thanks
For Prefetch(6) the SetMemoryMax(2000) kills performance for this script.
Avisynth+ r2455:
x64, SetMemoryMax(2000): 6.1 fps
x64, SetMemoryMax(3000): 8.8 fps (AVSMeter: 2500MB virtual)
x86, SetMemoryMax(2000): 7.7 fps
x86, SetMemoryMax(3000): 8.2 fps (AVSMeter: 2600MB virtual)

AVS2.6 MT 2.6.0.5
x86, SetMemoryMax(2000): 8.7 fps (AVSMeter: 2540MB virtual)
x86, SetMemoryMax(3000): 8.6 fps (AVSMeter: 3540MB virtual)

I don't have DGSource, used a test clip with lsmashvideosource.
Run from AVSMeter, no extra memory was needed for the encoder.

Using this script line:
SetLogParams("log.txt", LOG_DEBUG)
a warning appears in the log file for the SetMemoryMax(2000) case:
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().

[olex99]

Thanks Pinterf.

You are right, i've managed to get similar performance between Avisynth+ 64bit and Avisynth 2.6 MT by setting the Max Memory to 3000.

I did a lot of testing a few months back on the best Max Memory value for my setup and I settled on 2000 as it gave me the best speed and reliability, going to 3000 in x86 obviously gave me faster speed but it would crash when encoding cause the process would run out of memory.

I'm surprised to see such a big performance difference between Avisynth+ and Avisynth 2.6 MT, the same script and plugins are about 40% faster in Avisynth 2.6 MT, I guess the internals of both programs are a fair bit different though when it comes to multithreading.

The bonus of Avisynth+ is the 64bit mode though which allows me to pump more memory into it but it looks like for my setup, 6 threads and 3000 max memory give me the best performance, anymore threads and all it does is increase the amount of memory required without giving me any performance increase.

Is there anything you can think of that might increase my performance in Avisynth+ to get it closer to Avisynth MT?

I am looking at getting some more ram soon as i'm currently stuck running single channel on a x58 xeon which can run triple channel and I've found memory speed gives a fairly substantial jump in performance so hopefully when I get that I should see a difference.

Thanks for your help.

[vdcrim]

AvsPmod throws this error message:
Only a single prefetcher is allowed per script
But the only prefetch in the script is this one.

It's a bug in AvsPmod, I just posted a build with a fix here (https://forum.doom9.org/showpost.php?p=1801766&postcount=1202).

[pinterf]

I'm surprised to see such a big performance difference between Avisynth+ and Avisynth 2.6 MT, the same script and plugins are about 40% faster in Avisynth 2.6 MT, I guess the internals of both programs are a fair bit different though when it comes to multithreading.

40% difference between avs+ 32 and avs+ x64 (and classic x86 Avisynth MT 2.6.0.5) is too huge and it cannot be reasoned by internal mt differences.

[olex99]

40% difference between avs+ 32 and avs+ x64 (and classic x86 Avisynth MT 2.6.0.5) is too huge and it cannot be reasoned by internal mt differences.

Would you expect the 64bit version to be faster than the 32bit version? I know x264 is meant to be faster as 64bit and I assumed that Avisynth would be the same but from what I've seen in my tests the 32bit version is faster.

I don't have the results of my tests on me as the computer is at work so ill have to get them on Monday but I ended up getting the speed to within 5% of each other. Avisynth 2.6 MT x86 with SetMaxMemory at 2000 is about 5-10% faster than Avisynth+ 64 bit with SetMaxMemory at 3000.

Today I basically uninstalled Avisynth+ and normal Avisynth, deleted everything and started from scratch. Installed Avisynth+ 2294 and then updated to 2455, removed all plugin other than the ones I use for QTGMC. I downloaded the latest QTGMC 3.355s as well as the latest SMDegrain.

Then I ran 1000 frames of a 1080i (25fps) video through AVSMeter with a whole bunch of different SetMaxMemory and Prefetch, trying to match or beat the speed I got with Avisynth 2.6MT.

One thing I haven't tried is Avisynth+ x86 version to see what sort of speed I get from that but I was hoping to use the x64 version so I could use more memory as I know 2000 is limiting but cant go anymore than that in x86 without it crashing.

I've set the logging in Avisynth+ to Debug and it is empty.

[pinterf]

Would you expect the 64bit version to be faster than the 32bit version? I know x264 is meant to be faster as 64bit and I assumed that Avisynth would be the same but from what I've seen in my tests the 32bit version is faster.

mvtools2, RgTools benefit from running on x64.
In QTGMC most of the time is spent in plugins, not in avisynth, unless there are other factors like mt sceduling and memory issues.
Btw, on what exact processor type have you made the speed tests?

[olex99]

mvtools2, RgTools benefit from running on x64.
In QTGMC most of the time is spent in plugins, not in avisynth, unless there are other factors like mt sceduling and memory issues.
Btw, on what exact processor type have you made the speed tests?

Is there a way I can work out which plugin/s might be the issue?

It's weird cause i'm literally using the exact same plugins and scripts between the different avisynths, I downloaded all the latest ones this morning. I installed Avisynth+ 2294 exe and then copied the Avisynth.dll and DevIl.dll from Avisynth 2.6 MT over the top of the x86 version and the same dlls from Avisynth r2455 over the top of the x64 version..

I'm running an Intel Xeon X5675 6 core clocked at 4ghz with 8gig of ddr3 ram clocked at 1820mhz with Windows 10 Pro x64. As I said in a previous post, the ram is only running single channel at the moment but I'm looking at buying another 2 sticks for triple channel in the next week or so, I found the faster I have the memory clocked the faster the encoding runs.

The scripts are literally just doing a load of the source using DGDecodeNV and then QTGMC with default settings other than setting the threads to 1.. I've commented the QTGMC call out to see if there was an issue with DGDecodeNV, however both versions of avisynth give me around 340fps with just DGDecode in there so its got to be something within QTGMC.

[olex99]

I wonder if it could be something to do with the runtime version I'm using? I can't remember the versions but I installed the x86 ones a while ago and I did have to install a x64 version for one of the plugins so maybe there is a difference there.

On Monday when I get back to the computer I'll do some testing between avisynth 2.6 mt and avisynth+ x86 and see what the performance difference is. Least that way I can narrow down whether it's a difference between avisynth and avisynth+ or if there is something wrong with my x64 setup.

Should I expect them to be pretty similar with the exact same plugins and script, the only difference in script would be the different way we specify MT.

[DJATOM]

I'm running an Intel Xeon X5675 6 core clocked at 4ghz with 8gig of ddr3 ram clocked at 1820mhz with Windows 10 Pro x64

My friend has encoding server with the same CPU, but there are actually 2 CPUs and he didn't OC them. Also we using windows server 2008 as host OS.
All I can say that's a good low-cost CPU for encoding, especially if you can afford a pair of them. It's above 2x speed boost against my i5-4670k clocked at 4.3 GHz.

pinterf
If you need any test on that CPU, ask me in PM or so.

[pinterf]

Thanks, I was just wondering whether the processor has AVX or better capabilities (but not, it has only SSE4.2), because Avs+ can report AVX or better CPU flags to plugins, and that may result in a different code path. And if that code path would contain bug that can explain the different.

Another question for olex99, please set SetMemoryMax to 5000, and run the x64 avsmeter64 process to see how much memory is needed actually (it tops at a maximum, I don't expect to reach 5000). Maybe even 3000 is not enough (though you have said that no cache warning was seen in your logs). What are the frame dimensions (and format YV12?) of your clip?

[pinterf]

For those who are intested in what happens in the background, this is what Visual Studio performance profiler shows, Avs+ x86.

Script
SetMemoryMax(3000)
SetFilterMTMode("DEFAULT_MT_MODE",2)
lsmashvideosource("test107frame.mp4", format="YUV420P8").Loop(10)
Crop(0, 140, 0, -140)
QTGMC(EdiThreads=1, fftThreads=1).SelectEven()
Trim(0,999)
Prefetch(6)


Function Name Inclusive Samples % Exclusive Samples % Module Name
[nnedi3.dll]
6,76 6,76 nnedi3.dll
Filtering::MaskTools::Filters::Lut::Dual::lut_c
5,82 5,82 masktools2.dll
[LSMASHSource.dll]
5,83 5,79 LSMASHSource.dll
resizer_h_ssse3_generic
5,65 5,65 avisynth.dll
Degrain1to6_sse2<16,16,0,1>
5,09 5,09 mvtools2.dll
_Overlaps16x16_sse2
4,60 4,60 mvtools2.dll
memcpy
4,32 4,32 vcruntime140.dll
_VerticalWiener_iSSE
4,12 4,12 mvtools2.dll
Short2Bytes
4,00 4,00 mvtools2.dll
PlaneOfBlocks::PseudoEPZSearch<unsigned char>
3,44 3,44 mvtools2.dll
_HorizontalWiener_iSSE
3,28 3,28 mvtools2.dll
_x264_pixel_sad_16x16_sse2
2,81 2,81 mvtools2.dll
_Overlaps8x8_sse2
2,50 2,50 mvtools2.dll
_x264_pixel_sad_8x8_mmx2
2,32 2,32 mvtools2.dll
resize_v_ssse3_planar<&simd_load_streaming>
2,31 2,31 avisynth.dll
Degrain1to6_sse2<8,8,0,1>
2,10 2,10 mvtools2.dll
MVDegrainX::process_chroma
4,19 2,10 mvtools2.dll
PlaneOfBlocks::search_mv_slice<unsigned char>
1,95 1,94 mvtools2.dll
PlaneOfBlocks::ExpandingSearch<unsigned char>
1,89 1,89 mvtools2.dll
PlaneOfBlocks::FetchPredictors<unsigned char>
1,76 1,76 mvtools2.dll
_Copy16x16_sse2
1,71 1,71 mvtools2.dll
_Thread32Next@8
1,59 1,59 kernel32.dll
process_plane_sse<unsigned char,&rg_mode20_sse<0,1>,&rg_mode20_sse<1,1> >
1,43 1,43 RgTools.dll
MVDegrainX::GetFrame
37,15 1,28 mvtools2.dll
Filtering::MaskTools::Filters::Morphologic::xxpand_sse2_vertical
<&expand_operator_sse2,&Filtering::MaskTools::Filters::Morphologic::limit_up_sse2,1>
1,26 1,26 masktools2.dll
weighted_merge_planar_sse2
1,26 1,26 avisynth.dll
Filtering::MaskTools::Filters::Morphologic::xxpand_sse2_vertical
<&inpand_operator_sse2,&Filtering::MaskTools::Filters::Morphologic::limit_down_sse2,1>
1,22 1,22 masktools2.dll
PlaneOfBlocks::InterpolatePrediction<unsigned char>
1,20 1,20 mvtools2.dll
_Copy8x8_sse2
1,19 1,19 mvtools2.dll
calculate_sad_sse2<0>
0,76 0,76 avisynth.dll
PlaneOfBlocks::Hex2Search<unsigned char>
0,69 0,69 mvtools2.dll
accumulate_line_sse2<1,1>
0,66 0,66 avisynth.dll
MVCompensate::compensate_slice_overlap
0,65 0,65 mvtools2.dll
logic_t_sse2<1,&max_t_sse2<&nop_sse2,&nop_sse2>,&max_t<&nop,&nop> >
0,62 0,62 masktools2.dll
process_plane_sse<unsigned char,&rg_mode11_sse<0,1>,&rg_mode11_sse<1,1> >
0,62 0,62 RgTools.dll
Filtering::MaskTools::Filters::Lut::Single::lut_c
0,60 0,60 masktools2.dll
norm_weights<1>
0,57 0,57 mvtools2.dll
logic_t_sse2<1,&min_t_sse2<&nop_sse2,&nop_sse2>,&min_t<&nop,&nop> >
0,57 0,57 masktools2.dll
Filtering::MaskTools::Filters::Support::MakeDiff::makediff_sse2_t<1>
0,48 0,48 masktools2.dll
_RB2BilinearFilteredVerticalLine_SSE
0,41 0,41 mvtools2.dll

[videoFred]

It's a bug in AvsPmod, I just posted a build with a fix here (https://forum.doom9.org/showpost.php?p=1801766&postcount=1202).

Thank you!

Fred.

[MysteryX]

Pinterf, here's a bug in Avisynth+. Better if I leave this one for you so it's done the right way instead of hacking around the issue.
https://forum.doom9.org/showthread.php?t=174459

[real.finder]

hi Pinterf

ColorYUV not work with float yet

I usually use it with ColorYUV(autogain=true)

and levels="TV->PC"

[pinterf]

Yes. This is a lut using filter, which is not available in float. O.k. I will make it work realtime.
Now I'm still working on masktools, finally decided to implement dup and swap in expressions as you have requested.

[olex99]

Thanks, I was just wondering whether the processor has AVX or better capabilities (but not, it has only SSE4.2), because Avs+ can report AVX or better CPU flags to plugins, and that may result in a different code path. And if that code path would contain bug that can explain the different.

Another question for olex99, please set SetMemoryMax to 5000, and run the x64 avsmeter64 process to see how much memory is needed actually (it tops at a maximum, I don't expect to reach 5000). Maybe even 3000 is not enough (though you have said that no cache warning was seen in your logs). What are the frame dimensions (and format YV12?) of your clip?


Hi Pinterf, I've finally got back to the computer and managed to run some more tests. I upped the Max Memory to 6000 as at 3000 it was still showing the cache warning (although I'm sure I checked that), and they are definitely much closer to AVS 2.6 MT now. The source clup is 1080i/25 recording, it is reported as YUV in MediaInfo, however Avisynth reports it as YV12 using both DGSource and LWLibAVVideoSource.

Here are my results:


AviSynth 2.6 x86 (6000 Memory/6 Threads)

AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: i420
Active MT Mode: 2
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 0.746 | 54568 | 4.025
Memory usage (phys | virt): 3669 | 3800 MiB
Thread count: 33
CPU usage (average): 42%

Time (elapsed): 00:04:08.668




AviSynth+ x64 (6000 Memory/6 Threads)

AviSynth+ 0.1 (r2455, MT, x86_64) (0.1.0.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 0.323 | 33870 | 3.846
Memory usage (phys | virt): 3511 | 3589 MiB
Thread count: 45
CPU usage (average): 43%

Time (elapsed): 00:04:20.292



Avisynth+ x86 (6000 Memory/6 Threads)

AviSynth+ 0.1 (r2455, MT, i386) (0.1.0.0)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: i420
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 0.371 | 34464 | 4.083
Memory usage (phys | virt): 3536 | 3635 MiB
Thread count: 45
CPU usage (average): 43%

Time (elapsed): 00:04:05.167



It seems AviSynth+ is much more susceptible to low memory than AviSynth is so looks like I've just got to give it more to keep it happy, interestingly too AviSynth+ uses 12 more threads than AviSynth.

Is there anything I can do to get the x64 version running faster, even with a SetMaxMemory of 6000, x64 is slower than AVS 2.6MT with a SetMaxMemory of 2000. On the plus side, it is much more stable as I was regularly getting crashes with AVS 2.6MT, most likely due to running out of memory.

Here is my log for the AVS 2.6MT at SetMaxMemory 2000

AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)

Number of frames: 1001
Length (hh:mm:ss.ms): 00:00:40.040
Frame width: 1920
Frame height: 1080
Framerate: 25.000 (25/1)
Colorspace: i420
Active MT Mode: 2
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a

Frames processed: 1001 (0 - 1000)
FPS (min | max | average): 0.717 | 60444 | 4.093
Memory usage (phys | virt): 2620 | 2715 MiB
Thread count: 33
CPU usage (average): 43%

Time (elapsed): 00:04:04.555

Thanks for your help

[tuanden0]

I'm using this chain here (https://forum.doom9.org/showthread.php?p=1091224#post1091224) to upscale my 576p video to 720p and change some filter.
Here's my script:
SetMemoryMax(8000)
SetFilterMtMode("MP_Pipeline", MT_SPECIAL_MT)
MP_Pipeline("""
### platform: win64
LWLibavVideoSource("E:\Download\test.mkv")
AssumeFPS(24000, 1001)
### ###
### platform: win32
Toon()
### ###
### platform: win64
Deblock(quant=33)
FluxSmoothST()
Spline64ResizeMT(1536,864)
### ###
### platform: win32
aWarpSharp(depth=12,blurlevel=4,thresh=0.3,cm=1)
LSFmod(edgemode=1,strength=200)
### ###
### platform: win64
FFT3dFilter(sigma=3.2, bt=1, ncpu=4)
### ###
### platform: win32
Dehalo_alpha()
### ###
### platform: win64
Spline64ResizeMT(1280,720)
### ###
""")
Then, Can someone help me to put Prefetch(4) to this script? :thanks:
I tried to put it into my script but it crashed.

[ChaosKing]

mp_pipeline has it's own prefetch function, see example here: https://forum.doom9.org/showthread.php?t=163281

btw aWarpSharp, dehalo_alpha and probably some other filters are x64 compatible...

[djonline]

I also have problem with deshaker on second pass, both x32 and x64. AvisynthPlus-r2455-MT.
1. If I simple call deshaker plugin, there is only one repeated frame in final video.
00114.MTS-pass2-64.avs

SetMemoryMax(3000)
vid="00114.MTS"
o=DirectShowSource(vid).ConvertToRgb32(matrix="Rec709")
o+o.Trim(0,29)
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub64\plugins\Deshaker_64.vdf", "deshaker",0)
deshaker ("18|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|0|2|8|30|300|3|00114.MTS.0.1000.1000.2000.2000.log|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|0|20|5000|100|20|1")

If I call SetMemoryMax(6000), there is only blank screen.

If I call this avs from another avs to trim first 30 frames, vdub is crashed.
DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

UPDATE: Sorry, I forgot that MTS in avisynth not work with LAV splitter, so I install Haali media splitter and now all work ok, both x32 and x64 Deshaker in Avisynth+. Benchamark at https://forum.doom9.org/showpost.php?p=1802602&postcount=3192

[StainlessS]

@ djonline

I have a very OLD version of Deshaker, and it is version 19 [first arg in your list is 18].

Why do you think that you need SetMemoryMax(3000) with that script, [god forbid SetMemoryMax(6000)] ?
Script as given would not work (something like "Script does not return a clip" would be issued).
Where is the rest of the script ? (aint nobody gonna be able to help unless they see the script).

EDIT: https://forum.doom9.org/newreply.php?do=newreply&p=1645218

And the SetMemoryMax(2048) is a ridiculous value. As I keep telling people setting the size of the Avisynth frame cache bigger than what the current script needs is a waste.

EDIT: Also, on XP32 with 4GB, SetMemoryMax(2000) can sometime run out of memory (seldom), [or SetMemoryMax(1000), or SetMemoryMax(500)]
strangely, on P4 XP32 with 1GB, I've never once had an OMEM, ever (with defaulted memory max, EDIT: Unless down to eg plugin bug).

EDIT: At the very least you need a return o at end of script, also, good idea to wrap your script in CODE tags, click Advanced, select the script, click on hash (#).

EDIT: Just noticed this :)

If I call this avs from another avs to trim first 30 frames, vdub is crashed.
DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

Dont think you would have too much luck loading an Avisynth script via DirectShowSource, Try Import() instead.
Also, you add 30 frames to END of original clip with o+trim(0,29)
and then DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0) which trims off the FIRST 30 frames, is that intentional ?

[djonline]

There is last Deshaker 3.1. I think first argument, 18 or 19, is not used.
Of course I try with and without SetMemoryMax.
This is full script, no any other lines. May be you don't have 00114.MTS.0.1000.1000.2000.2000.log on this second pass when you try it.
I have windows 10.
vdub.vcf

VirtualDub.Open("00114.MTS-loader.avs", 0, 0);
VirtualDub.audio.SetSource("00114.MTS.ac3");
VirtualDub.audio.SetMode(0);
VirtualDub.audio.SetClipMode(1, 1);
VirtualDub.audio.SetConversion(0, 0, 0, 0, 0);
VirtualDub.audio.SetVolume();
VirtualDub.audio.SetCompression();
VirtualDub.audio.EnableFilterGraph(0);
VirtualDub.audio.filters.Clear();
VirtualDub.audio.SetInterleave(1, 500, 1, 0, 0);
VirtualDub.video.SetDepth(24, 24);
VirtualDub.video.SetOutputFormat(0);
VirtualDub.video.SetMode(1);
VirtualDub.video.SetFrameRate2(0,0,1);
VirtualDub.video.SetIVTC(0, 0, -1, 0);
VirtualDub.video.SetCompression(0x7967616d,0,10000,0);
VirtualDub.video.SetCompData(68,"CAAAAAgAAAABAAAABAAAAAIAAAD/////AAAAAAIAAABpAAAAAAAAABkAAAAJAAAAAQAAAAEAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAABAAAA");
VirtualDub.video.filters.Clear(); VirtualDub.SaveAVI("00114.MTS-deshaked.1.2000.2000.2000.2000.avi");
VirtualDub.Close();


00114.MTS-loader.avs

DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

I use option "Use previous and future frames to fill in borders", so I must trim first 30 frames and add last 30 frames. But there is no way to do this in ony avs script, Deshaker always add first 30 empty frames, even I if add Trim(30,0) after Deshaker call, so I must use another script named 'loader'.
Vdub crush info in attach.

[LigH]

So you use VirtualDub to load an AviSynth script that loads another AviSynth script via DirectShowSource... :eek: :confused:

[StainlessS]

There is last Deshaker 3.1. I think first argument, 18 or 19, is not used.

The version number tells Deshaker what version script it is, so it will complain if wrong version, it should be for the version that you use,
which apparently is version 18 (not latest for sure).

Suggest that you change

DirectShowSource("00114.MTS-pass2-64.avs").Trim(30,0)

to

Import("00114.MTS-pass2-64.avs").Trim(30,0)

We still dont know what is in that 00114.MTS-pass2-64.avs script, if it is a Deshaker pass 1 script, it aint gonna work,
because pass 1 create Deshaker log for 2nd pass of Deshaker, and is not available until pass 1 has completed.

Also, note, if you have

o=DirectShowSource(vid).ConvertToRgb32(matrix="Rec709")
o+o.Trim(0,29)

in your first pass, and then use add a Trim(30,0) to end first pass before doing 2nd pass, then you Deshaker log will be 30 frames in error
and deshaker will dehake almost everything wrongly (as its using deshaker data for the wrong frames).

EDIT: Sorry, you said that this is the script,

SetMemoryMax(3000)
vid="00114.MTS"
o=DirectShowSource(vid).ConvertToRgb32(matrix="Rec709")
o+o.Trim(0,29)
LoadVirtualDubPlugin ("c:\Program Files\Vdub\vdub32\plugins32\Deshaker.vdf", "deshaker",0) deshaker
("18|2|30|4|1|0|1|0|640|480|1|2|1000|1000|2000|2000|4|0|0|2|8|30|300|3|00114.MTS.0.1000.1000.2000.2000.log"
"|0|0|0|0|0|0|0|0|0|0|0|0|0|1|70|70|10|30|1|1|30|30|0|0|0|0|1|0|1|10|1000|1|88|1|0|20|5000|100|20|1")


NOTE, That is a PASS 2 Script.

EDIT: Can you just state in words what it is that you are trying to do.

EDIT: OK, re-read everything, think I understand. Just Load the script above into VirtualDub and forget altogether about the "00114.MTS-loader.avs" script (But reduce the massive SetMemoryMax thing)

[djonline]

Sorry, I forgot that MTS in avisynth not work with LAV splitter, so I install Haali media splitter and now all work ok, both x32 and x64 Deshaker in Avisynth+.
So now I can post my benchmarks of x32 and x64 Deshaker:
1 pass: x32 - 36s, x64 - 21s, speedup 71%
2 pass :x32 - 30s, x64 - 20s, speedup 50%

Source 1080/60p from Sony RX100 28mbit, 8s length, output to MagicYUV 4:2:0 lossless.

[real.finder]

I get error like this https://forum.doom9.org/showpost.php?p=1779374&postcount=2372

with TDecimate and MT, is this bug didn't fixed yet?

[DJATOM]

I confirm that.
As a temporary solution I do tfm/tdecimate filtering via x86 avs+ and w/o Prefetch, transmit output with TCPDeliver, process anything else with x64 avs+ (and Prefetch).

[real.finder]

I confirm that.
As a temporary solution I do tfm/tdecimate filtering via x86 avs+ and w/o Prefetch, transmit output with TCPDeliver, process anything else with x64 avs+ (and Prefetch).

I am do same thing but with mp_pipeline

[yup]

Hi all!
I am new in high bit conversion, advice how convert from avs+ 16 bit to Avisynth 16 bit hack (for use inside KNLMeansCL plugin) and back. I could use dither or last avs+ make this by self?
yup.

[DJATOM]

Do your 16bit native filtering
Converttostacked()
Do stacked filtering
Convertfromstacked()
Do another HBD native filtering

It's simple as that.

[yup]

DJATOM! :thanks: yup.

[yup]

Hi all!
Advice also easy way for import hi bit image to Avisynth+.
yup.

[LigH]

You mean, reading a (sequence of) 48 bit PNG/TIFF as source (like raw footage of Blender render movies)?

[yup]

LigH!
Yes! For starting point I want filtering film scanned grey scale 16 bit image using non local means filter.
yup.

[videoh]

I have Avisynth+ 1576 in my SysWOW64 directory. I open a script with just Version() in it in VirtualDub. It opens fine. I replace Avisynth.dll with the x86 DLL from Avisnth+ 2455. Now VirtualDub says import error. What stupid mistake am I making?

Win10 64

Thank you.

[Reel.Deel]

I have Avisynth+ 1576 in my SysWOW64 directory. I open a script with just Version() in it in VirtualDub. It opens fine. I replace Avisynth.dll with the x86 DLL from Avisnth+ 2455. Now VirtualDub says import error. What stupid mistake am I making?

Win10 64

Thank you.

Did you update the plugins with the new ones from the latest release?

[videoh]

I just did now and it still fails.

Do you know how to do a clean install of 2455, i.e., what installer version should I use before copying over all the files.

[videoh]

I cleaned everything out and installed Groucho's last installer for 2294, checking both x32 and x64. Loading version.avs in VirtualDub 64 works, loading it in VirtualDub 32 fails. Then, just replacing the x32 avisynth.dll with the r1576 makes x32 work again. Any ideas?

[yup]

videoh!
Try
https://forum.doom9.org/showthread.php?p=1585008#post1585008
and post log.
yup.

[videoh]

yup, you're my hero, thank you so much!

I didn't have the 32-bit runtime installed, only the x64 one.

EDIT: AOK now.

[yup]

videoh!
Installing avisynth tricky process :D.
yup.

[StainlessS]

@videoh, you might want to thank Groucho2004 too, is theguy that provided the app that sorted you, and same guy that you not so long ago barred from your forum for no concrete reason.

Mobile.

[yup]

I try load 16 bit image (grey scale) to Avisynth+.
1. I prepare stacked version of image:
"C:\Program Files\ImageMagick-7.0.5-Q16\magick" "film7 1.tif" -depth 16 ( +clone -evaluate and 255 -evaluate multiply 256 ) -append stacked001.png
2. try load to Avisynth:
ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
ConvertToYV24()
ConvertFromStacked()
And do not see my image, if remove ConvertFromStacked I see stacked image.
yup.

[LigH]

Converting each significant bit part in RGB representation to YUV does not result in each significant bits for the YUV representation. This is caused by the specific PC-affine color representation in different YUV color space matrices (8 bit integer per component, instead of floating point values).

Trivial case: You create an RGB image in 8 bit depth for the more significant half, and the less significant half is kept at $000000 (black in RGB). Converting this to YCbCr (Rec.601, TV scale) will return (16, 128, 128) as "TV black". Combining LSB and MSB to a 16-bit value now will result in garbage colors.

To do the conversion correctly, I believe you would first need to ConvertFromStacked(), and then ConvertToYUV... with 16 bit depth. But I am not sure if that is supported, and which functions are available if.

[yup]

Converting each significant bit part in RGB representation to YUV does not result in each significant bits for the YUV representation. This is caused by the specific PC-affine color representation in different YUV color space matrices (8 bit integer per component, instead of floating point values).

Trivial case: You create an RGB image in 8 bit depth for the more significant half, and the less significant half is kept at $000000 (black in RGB). Converting this to YCbCr (Rec.601, TV scale) will return (16, 128, 128) as "TV black". Combining LSB and MSB to a 16-bit value now will result in garbage colors.

To do the conversion correctly, I believe you would first need to ConvertFromStacked(), and then ConvertToYUV... with 16 bit depth. But I am not sure if that is supported, and which functions are available if.
Easy way do not exist?
Right?
New Devil.dll, ImageSeq.dll in last avs+ builds do not support 16 bit?
yup.

[pinterf]

I try load 16 bit image (grey scale) to Avisynth+.
1. I prepare stacked version of image:
"C:\Program Files\ImageMagick-7.0.5-Q16\magick" "film7 1.tif" -depth 16 ( +clone -evaluate and 255 -evaluate multiply 256 ) -append stacked001.png
2. try load to Avisynth:
ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
ConvertToYV24()
ConvertFromStacked()
And do not see my image, if remove ConvertFromStacked I see stacked image.
yup.

ConvertFromStacked cannot have RGB input, we have to play with lossless format conversions (data is unchanged, planes are copied as-is). Once we have YUV, we can use ConvertFromStacked, than go back to planar RGB.
At this stage we have the original 16 bit RGB, in planar RGB format (RGBP16).

You can convert it further if you wish.

This works for me
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")
#here we have 16 bit planar RGB
rgbp_16.ConvertToYUV444() # convert to YUV444P16
# or rgbp_16.ConvertToRGB64() # convert to packed RGB64

[real.finder]

FFImageSource should load HBD without hack

[Reel.Deel]

FFImageSource should load HBD without hack

Not necessarily, FFMS2 v2.23.1 used SWScale and could not load HBD images. This issue affected both AVS+ and VS. I told Myrloik about it some time ago: https://github.com/FFMS/ffms2/issues/277

I have not tried it yet but the latest test version of FFMS2000 might support it since it has FFmpeg compiled with zlib (http://forum.doom9.org/showpost.php?p=1802287&postcount=19).


@pinterf

Any plans to add HDB support to ImageReader/Writer? If I understand correctly Wilbert said he had already written the code for that: http://forum.doom9.org/showthread.php?p=1773088#post1773088

[pinterf]

@pinterf

Any plans to add HDB support to ImageReader/Writer? If I understand correctly Wilbert said he had already written the code for that: http://forum.doom9.org/showthread.php?p=1773088#post1773088
It was forgotten, that was at the very beginning.

Wilbert's link needs authentication, anyway I have tried something quickly and this works fine for my 48 bit tiff sample.
ImageSource("img010.tif", start=1, end=1, use_DevIL=true, pixel_type ="RGB64") # or RGB48

A bit nicer that my previous stacked workaround.

[yup]

pinterf!
I try Your first script:
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24")
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")
#here we have 16 bit planar RGB
rgbp_16.ConvertToYUV444() # convert to YUV444P16
# or rgbp_16.ConvertToRGB64() # convert to packed RGB64
Without success using shekh VirtualDub. Exist restriction for image size? My image (stacked) 6639x8062 pixels.
Second also not work, error about not support RGB48.
yup.

[pinterf]

pinterf!
I try Your first script:
[...]
Without success using shekh VirtualDub. Exist restriction for image size? My image (stacked) 6639x8062 pixels.
yup.
As a stress test, I set the a final size (not stacked) to 6640x8062. (my stacked size is 2320x6670)

One final frame (as RGB64) needs almost 500 MBytes.

I had to raise the default memory for 32 bit Avisynth+ (because Avisynth+ complained for low memory, default is 1GBytes), and when I have set it to 3000, then 32 bit Virtualdub was showing memory error (could not allocate x bytes)

In 64 bit virtualdub (and thus 64 bit Avisynth+), I was able to open and view the script (see below) producing rgb64 image.

SetMemoryMax(3000)
stacked_rgb24 = ImageSource("stacked001.png", start=1, end=1, use_DevIL=true, pixel_type ="RGB24").Loop(100)
stacked_fakeyuv = CombinePlanes(stacked_rgb24,"YUV","RGB","YV24")
fakeyuv16 = ConvertFromStacked(stacked_fakeyuv)
rgbp_16=CombinePlanes(fakeyuv16,"RGB","YUV","RGBP16")#.Histogram("levels",bits=11)
#here we have 16 bit planar RGB
rgbp_16.ConvertToRGB64()
#just to have a big input for virtualdub
Spline64Resize(6640,8062)

[yup]

pinterf! :thanks:
Work under avs+ 64 bit.
Problem loading 16 bit image solved.
How now organize conversion for KNLMeans plugin? ConvertToStacked?
yup.

[pinterf]

pinterf! :thanks:
Work under avs+ 64 bit.
Problem loading 16 bit image solved.
How now organize conversion for KNLMeans plugin? ConvertToStacked?
yup.
Probably yes, but you have to consider which format you are using.

Once you have the 16 bit/channel RGB clip, you can convert it to YUV444P16 with ConvertToYUV444(), then use ConvertToStacked, and you can feed it into KNLMeansCL (in YUV mode only Y channel is denoised by default).

Or you can leave the RGB clip in a fake_yuv format, convert to stacked, and request processing all Y, U and V planes. Then back to non-stacked, and back to RGB with CombinePlanes.

Remember that when using CombinePlanes we avoid the real RGB->YUV->RGB conversions (only format is changed), still we can feed the clip to the filter.

(I don't know if there is any difference in processing, depending on plane origin (Y or U or G, anything))

[yup]

Hi pinterf!

I am add code
ConvertToYUV444()
ConvertToStacked()
KNLMeansCL(device_type="GPU",h=6, lsb_inout=true)
ConvertFromStacked()
ConvertToRGB64()
to Your first script and now all work.
:thanks:
yup.

[pinterf]

dev news: ImageReader and ImageWriter got RGB48, RGB64 and Y16 support through devIL.
Strange, saving greyscale (8 or 16 bit) TIFF is corrupted, while PNG is O.K.

[Reel.Deel]

dev news: ImageReader and ImageWriter got RGB48, RGB64 and Y16 support through devIL.
Strange, saving greyscale (8 or 16 bit) TIFF is corrupted, while PNG is O.K.

Awesome.

Don't know if you have any interest in fixing this but a while back I reported an issue with ImageWriter and Y8 colorspace: https://github.com/AviSynth/AviSynthPlus/issues/58

Feature request:
Is it possible to add a parameter to ImageWriter to be able to specify DPI? And also add the ability to save B/W 1-bit images?

I don't know the ins and outs of DevIL so if it's something complicated, please ignore me. :)

[pinterf]

I recognized the vertical flipping at greyscale, and corrected it already, I flip always. Or is raw format an exception?

[Reel.Deel]

I recognized the vertical flipping at greyscale, and corrected it already, I flip always. Or is raw format an exception?l

IIRC, raw format did not need flipping. I'll test again when you release the update.

[yup]

Hi all!
Thanks for support!
I am trying filtering grey scale image 6639x4032 using
KNLMeansCL(device_type="GPU",h=2, lsb_inout=true,a=32,s=4)
and image was ready after 30 seconds with my GTX 960, using Ximagic filter, CPU based with (a=16,s=2) need 20-30 minutes.
yup.

[pinterf]

More dev news:
- avs scripts with unicode filenames can be opened though the VfW interface (VirtualDub, MPC-HC)
- SubTitle: new parameter bool "utf8" to allow rendering an UTF8 encoded text. Something like this:
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
I don't know whether this was a huge demand or not, but someone probably can use it.

[StainlessS]

- avs scripts with unicode filenames can be opened though the VfW interface (VirtualDub, MPC-HC)


In Docs, maybe should point out failure caveat of ScriptName(), ScriptFile() and ScriptDir() if UniCode used in script names in such cases.
(Also other functions using filenames, builtin or plugin [EDIT: where filenames generated from eg ScripName()]).

[pinterf]

In Docs, maybe should point out failure caveat of ScriptName(), ScriptFile() and ScriptDir() if UniCode used in script names in such cases.
(Also other functions using filenames, builtin or plugin [EDIT: where filenames generated from eg ScripName()]).
Yes, this fix only helps opening such scripts.
The plugin directories, reading them from registry, adding them through LoadPlugin and SCRIPTxxx macro expansion is not effected yet.
Now there are ScriptNameUtf8(), ScriptFileUtf8() and ScriptDirUtf8() functions.
All functions working with file names and path would be nice to have an utf8 version, maybe we'll need functions converting to and from utf8 as well. ImageSource, etc. have to be extended too. Nice plans anyway, but sticking with the idea of "keep it compatible with everything existed so far" makes it harder.

[jmac698]

Thanks for adding support to read 16bit images. I use this also for processing of raw stills in avisynth, for filtering and to make time lapse.

filed under: finally in 2017

[blaze077]

I have a few questions regarding Stacked16, its interleaved counterpart and "Native" bit depth.
First off, how is a Stacked format converted to and from "native" bit depth and likewise for interleaved formats? I also do not understand what native bitdepth. Is it when both the MSB and the LSb are at the same place in memory?
Secondly, let's say you have a piece of code like this:
ConvertToStacked()
StackVertical(dither_get_msb().mt_lut("x 20 +"), dither_get_lsb().mt_lut("x 0.8 ^")).ConvertFromStacked()
Is there a way to perform this in "native" bit depth rather than utilizing the Stack16 format?
Sorry if I don't make much sense.

Thank you.

[real.finder]

I have a few questions regarding Stacked16, its interleaved counterpart and "Native" bit depth.
First off, how is a Stacked format converted to and from "native" bit depth and likewise for interleaved formats? I also do not understand what native bitdepth. Is it when both the MSB and the LSb are at the same place in memory?
Secondly, let's say you have a piece of code like this:
ConvertToStacked()
StackVertical(dither_get_msb().mt_lut("x 20 +"), dither_get_lsb().mt_lut("x 0.8 ^")).ConvertFromStacked()
Is there a way to perform this in "native" bit depth rather than utilizing the Stack16 format?
Sorry if I don't make much sense.

Thank you.

Stacked16 hack and interleaved16 hack both 8bit (will be yv12 or yv24 or y8 or so) but some plugins can read them with some Parameters (like lsb), Stacked16 is slow and interleaved is fast like native one

native in memory will be like interleaved, but it's not use any hack, so no extra parameters will needed to tell the filter what is the bitdepth

[raffriff42]

With pinterf's masktools v2.2.x (http://avisynth.nl/index.php/MaskTools2), stacking is not needed. The following statements are equivalent (or very close):## 8-bit gamma 0.8, TV range:
mt_lut("x 16 - 219 / 1 0.8 / ^ 219 * 16 +")
## 16-bit gamma 0.8, TV range:
ConvertBits(16) ## (if needed)
mt_lut(x 16 @B - 219 @B / 1 0.8 / ^ 219 @B * 16 @B +")
ConvertBits(8) ## (if needed)

You might have other reasons for using stack16, but masktools ain't one of them.

[blaze077]

I am aware of what you both said but I guess I'm looking for a description of the method to convert from stack16 to native 16 bits and vice versa and the same thing for stack16 and interleaved. As in when converting from stack16 to native 16 bits, is it the average of the MSB and LSB then bitshifted [((MSB+LSB)/2) >> 8]. It's probably not that easy so I would just like to know. Again, sorry if I do not make much sense.

Thank you.

[raffriff42]

when converting from stack16 to native 16 bits, is it the average of the MSB and LSB then bitshifted [((MSB+LSB)/2) >> 8]. They are added together, like this: [MSB<<8 + LSB]

[blaze077]

They are added together, like this: [MSB<<8 + LSB]
That's what I was looking for. Thank you.

[real.finder]

so this will do same thing

mt_lut("x 256 / Floor 20 + 0 255 clip 8 << x 256 % 0.8 ^ +")

it only work on 16 bit native

and this

mt_lut("i16 clamp_f_i16 x 256 scalef / Floor 20 + 0 255 clip 256 scalef * x 256 scalef % 0.8 ^ +")

will work on all

[blaze077]

mt_lut("i16 clamp_f_i16 x 256 scalef / Floor 20 + 0 255 clip 256 scalef * x 256 scalef % 0.8 ^ +")
Thanks, this is quite useful too. Now I understand the usage of the scaling operators better.

[vcmohan]

i am on r2420_MT 64 bit version. I have problem if I convertto YUY2()
my script is

imagesource(....)
#converttoYV24()
#converttoYUY2()
a = stackhorizontal(last, last)
b = stackhorizontal(last, last)
stackvertical(a,b)
# reduceby2 does take back last to image with YUY2
reduceby2()
return(last)

It appears reduceby2() call is the problem. If I convertto YV24 it works OK. If I remove reduceby2 it works ok for YUY2 also

[LigH]

The planar equivalent of YUY2 is YV16. How does it look if you try this (and in addition, convert to YUY2 as last step before the return)?

[pinterf]

What's the problem exactly? YUY2 looks identical to the other formats for me.

[LigH]

Might be related to the image he loaded?

[pinterf]

Wow, thanks for quick reply. Looking fwd to fix. Unfortch I've just discovered that TDecimate does not work with MT enabled, whether using tritical's original TIVTC.dll or groucho2004's build. Works fine in r1858_pfmod, quits with "internal error during prebuffering!" in r2085, r2161, r2172.
and
I get error like this https://forum.doom9.org/showpost.php?p=1779374&postcount=2372

with TDecimate and MT, is this bug didn't fixed yet?
There are two different things.

The right-side error window in the first quote (from August, 2016) is showing very big numbers. That problem was fixed, it had the same reason as the garbage text error messages.

The second problem comes from TIVTC, now with proper numbers:
TDecimate: internal error during pre-buffering (n1=19,n2=20,pos=0)
This error occurs in MT, when the two filters (TFM and TDecimate) are set to MT_MULTI and MT_SERIALIZED, respectively. I have copied these lines from the file containing MT modes for popular filters.
FFMS2("sample.m2v")
SetFilterMTMode("TFM", MT_MULTI_INSTANCE) #2 is faster. 1 crashes randomly.
SetFilterMTMode("TDecimate", MT_SERIALIZED) #1 gave error, 2 was slower than 3

TFM()
TDecimate()
Prefetch(8)
The internal error came in seconds. (I was using Prefetch(8))

When I have set the filter TDecimate to MT_MULTI_INSTANCE, the script has run without error.
SetFilterMTMode("TFM", MT_MULTI_INSTANCE)
SetFilterMTMode("TDecimate", MT_MULTI_INSTANCE)
I think this must be an internal bug of TIVTC, it is receiving the frames in some special order, that is not handled or checked properly and is different than other versions of Avisynth.

Anyway, in the last couple of weeks I was working on TIVTC x64 port (just because x64-less basic filters are annoying me). Hey, it's crazy, quite a lot of work. Hundreds of lines of magically optimized inline asm (really, really professional), but sometimes without any C equivalent. I am moving all asm stuff to simd intrinsics, write functions in SSE2 where only MMX or ISSE is implemented, replace non-vectorized inline asm with C code.
TFM and TDecimate is working already in YV12. There are still two longer asm-only sections in YUY2 that have to be reverse engineered and moved to C.

And found a bug (buffer overwrite) that occured with AVS+, since the code allocated a buffer assuming 16 byte alignment (Avs+ alignes frames and rows to 32 bytes)

[vcmohan]

What's the problem exactly? YUY2 looks identical to the other formats for me.
I get proper stacked images with YUY2 also if I comment out reduceby2() call. With reduceby2() call it looks all the stackhorizontal and stackvertical calls are bypassed and only converttoYUY2() result is output without even reducing image.. With YV24 it works OK.

[Myrsloik]

Find a slightly older tivtc version if tou want c code for everything. That's what I did. Obviously the c code doesn't match the asm because real men don't test things.

[Reel.Deel]

Find a slightly older tivtc version if tou want c code for everything. That's what I did. Obviously the c code doesn't match the asm because real men don't test things.

You mentioned this a long time ago and IIRC that version is no longer publicly available. At least not from here: https://web.archive.org/web/20081017060943/http://bengal.missouri.edu/~kes25c/old_stuff/

Maybe this?
https://www.dropbox.com/s/35pzwufzw7w8d0g/tivtcv09110.zip?dl=1

[Myrsloik]

Why is isyuv() true for y16? Why? Whyyyyyyyyyyyyyy? Makes no sneeze!

[pinterf]

Haha. Y8 heritage. Compatibility :)

[StainlessS]

Makes no sneeze!

Perchance typo, "Makes no senze!" (or sense).

[LigH]

Surely on purpose; or blame the autocorrection. Bless you!

Looks like "IsYUV" mainly means "is not RGB".

[Myrsloik]

Can we have "isreallyyuv"?

[Reel.Deel]

Not sure if this is a bug in avs+ or in shekh's VDub, or maybe I'm doing something wrong.

Using FFMS2000 test 3 (https://forum.doom9.org/showthread.php?t=174469) to load this 16-bit png (https://www.dropbox.com/s/jmfgenfq9hl797a/IMG_4699-16bit.png?dl=1).

FFImageSource("IMG_4699-16bit.png", colorspace="RGBP16")
Info()
ConvertBits(8)

I get this error is VDub:
Couldn't locate decompressor for format '8BPS' (unknown)

VirtualDub requires a Video for Windows (VFW) compatible codec to decompress video. DirectShow codecs, such as those used by Windows Media Player, are not suitable.

If I set FFimageSource to colorspace="RGBAP16" then there's no error message but I get a corrupted image: https://www.dropbox.com/s/d5dz4v6be3ueox8/IMG_4699-16bit_output.png?dl=1
Adding ConvertToRGB24/32 after ConvertBits(8) works without a problem.

Edit : added Enable_PlanarToPackedRGB = true to the beginning of the script, still the same problem.

[LigH]

Can we have "isreallyyuv"?

So, like, ... mysql_real_escape_string() ? :p

[shekh]

@Reel.Deel

8BPS is not implemented in vd, correct response
corrupted image is maybe error in avisynth
working way: use ConvertToRGB64()

[Yanak]

Hello all,

Sorry to ask if it's a simple thing but i used to add a logo as overlay on my videos using this code :

AVISource("F:movie.avi", audio=false).AssumeFPS(60,1)
ConvertToYV12(interlaced=False)
logo=ImageSource("F:\logo.png")
Overlay(logo, x=3, y=2, opacity=0.45, mode="luma")


Now after updating to the last r2455 x64 avs+ ( had a version of avs+ from the last trimester of last year if i recall correctly ) i try this and i get an error message saying :
"filter error ; Attempted to request a planar frame that wasn't mod2 in height!"

My logo picture is 90x 55px, if i resize it to 90x 56px it works.

But i don't understand what have changed to not accept the logo picture as overlay if it is not resized now.

Thanks in advance.

[LigH]

In YV12, chrominance difference values (U and V in YUV) are valid for a square of 2x2 pixels. Therefore, all clips need to have even (multiple of 2) dimensions, both width and height.

[Yanak]

Hello and thanks for the reply,

I guessed that now it needed to be a multiple of 2 for the overlay picture but was not sure why it worked before and not now.
Will keep this in mind for future uses and start to resize all logos i use or add transparent borders to png's so they get the proper sizes now.

Thank you


Also seems like i have an issue with something else, this used to work not so long ago :

AviSource("F:movie.avi", audio = false)
ConvertToYV12()
logo=ImageSource("F:\logo.png").Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma")

Now if i leave the dot just before "Overlay" it returns me an error message " I don't know what 'logo' means "

I have now to leave a space instead of the dot to get it work :

logo=ImageSource("F:\logo.png") Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma")

or of course like this in 2 lines :

logo=ImageSource("F:\logo.png")
Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma")

But leaving all in one line with the dot between them doesn't seems to work anymore for the overlay command, still seems to works with other stuff like .Crop, .ChangeFPS, .Subtitle , all in a single line.

Thanks a lot for the help.

[stax76]

If you use the dot the logo variable is used in the overlay function before it was created so it makes sense that it don't work.

[Yanak]

Thanks Stax,
i'm a bit lost now, will have one of those days to install an older PC backup i have and see how i managed to get this working in the past, probably missing or mixing up something on this.

Anyways the thing I'm sure about is the logo size never asked to be resized before, but got this fixed now so it isn't an issue anymore.

Thank a lot for the answers guys, really appreciate.

[StainlessS]

AviSource("F:movie.avi", audio = false)
ConvertToYV24() # NOTE 24

# Fail, logo only asigned to AFTER whole line is processed, ie you try to use logo before assinging a value to it.
# logo=ImageSource("F:\logo.png").Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma")

logo=ImageSource("F:\logo.png") # Logo now exist, has been assigned to
Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma") # OK logo exists

# SomeClip.SomeFilter().Crop() works because you are not referenceing a clip that does not yet exist, assuming SomeClip exists.
# Someclip is passed through SomeFilter and on to Crop.


I hope some of that makes sense, was in a hurry to catch my bus, I missed it.

[jpsdr]

Can we have "isreallyyuv"?
IsYUV() && !IsY()

And i think that IsYUV is false for YUVA, don't know if it can bother you.

[yup]

Hi all!
Where can load last version Devil.dll?
I am try registering on SF, but can not access to files.
yup.

[pinterf]

https://sourceforge.net/projects/openil/files/DevIL%20Win32%20and%20Win64/
But 1.78 is included in the usual avisynth+ binary package.

[pinterf]

Find a slightly older tivtc version if tou want c code for everything. That's what I did. Obviously the c code doesn't match the asm because real men don't test things.
Thanks, I will do a post-check I think.

[tormento]

I have formatted PC after infinite inline updates of Win10 previews.

Is too much to ask for a installer with latest version? ;)

[ajp_anton]

Just a thought... why not have the Info() function return everything as a string instead of overlaying it onto a clip, with potential problems involving the clip resolution and text size. The user could then modify it and manually subtitle it into the video using more easily visible styling or colors.
You could add a bool parameter "return_string" or something, false by default.

[yup]

https://sourceforge.net/projects/openil/files/DevIL%20Win32%20and%20Win64/
But 1.78 is included in the usual avisynth+ binary package.
This package support high bit depth image? Y16 for example?
yup.

[pinterf]

This package support high bit depth image? Y16 for example?
yup.
DevIL DLL itself is capable to do that, but you need a new ImageSeq.dll which I have not released yet.

[StainlessS]

Just a thought... why not have the Info() function return everything as a string instead of overlaying it onto a clip, with potential problems involving the clip resolution and text size. The user could then modify it and manually subtitle it into the video using more easily visible styling or colors.
You could add a bool parameter "return_string" or something, false by default.

That was requested about a year or so ago.

EDIT: Further request, how about allowing YUV color of eg $008080 for both LetterBox and Addborders. (for masks)

[yup]

DevIL DLL itself is capable to do that, but you need a new ImageSeq.dll which I have not released yet.
:thanks:
Will be waiting.
yup.

[qyot27]

Just a thought... why not have the Info() function return everything as a string instead of overlaying it onto a clip, with potential problems involving the clip resolution and text size. The user could then modify it and manually subtitle it into the video using more easily visible styling or colors.
You could add a bool parameter "return_string" or something, false by default.
Styling...you mean like the font, size, text_color, and halo_color parameters (https://github.com/pinterf/AviSynthPlus/commit/1d561ea662311a47a3788820c62d405f5983091c) that were added to Info() back in August before the in-between bit depths were?

[Yanak]

AviSource("F:movie.avi", audio = false)
ConvertToYV24() # NOTE 24

# Fail, logo only asigned to AFTER whole line is processed, ie you try to use logo before assinging a value to it.
# logo=ImageSource("F:\logo.png").Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma")

logo=ImageSource("F:\logo.png") # Logo now exist, has been assigned to
Overlay(logo, x = 3, y=3, opacity=0.45, mode="luma") # OK logo exists

# SomeClip.SomeFilter().Crop() works because you are not referenceing a clip that does not yet exist, assuming SomeClip exists.
# Someclip is passed through SomeFilter and on to Crop.


I hope some of that makes sense, was in a hurry to catch my bus, I missed it.
Sorry for the late reply and thank you,

ConvertToYV24() works with the old logo size of 90x 55px, perfect.

For the rest I don't know what what happened, feeling silly, probably mixed up some stuff or messed up somewhere when copying old avs parts of code i used before, had in mind it always worked before but nope, don't know what happened with my brain.

Thanks again.

[ajp_anton]

Styling...you mean like the font, size, text_color, and halo_color parameters (https://github.com/pinterf/AviSynthPlus/commit/1d561ea662311a47a3788820c62d405f5983091c) that were added to Info() back in August before the in-between bit depths were?
Sorry, is there an updated wiki/manual somewhere that includes all the new stuff?
Also, it still doesn't let you modify the info string, which I find unnecessary and feels like an easy fix (could be wrong, not a programming guru).

[raffriff42]

Sorry, is there an updated wiki/manual somewhere that includes all the new stuff?For now, see:
Oct 2016 Avisynth Plus Quick reference guide (https://forum.doom9.org/showthread.php?p=1783714#post1783714)
Nov 2016 New functions (https://forum.doom9.org/showthread.php?p=1785533#post1785533)
Apr 2017 AVS 2.60 vs. AVS+ r2455 (https://forum.doom9.org/showthread.php?p=1803414#post1803414)
(Are there other good resources? I'd like to know about them.)

Reel.Deel said he was starting a new documentation site; I don't know what's happening with it.Sounds great! I'll note any changes in the wiki (http://avisynth.nl/index.php/Special:Contributions/Raffriff42) for you....I don't know if listing all AVS+ changes alongside the 'official' documentation is a good idea. Might be a tad confusing.

[MysteryX]

There isn't just an issue with ScriptClip, but also with ConditionalFilter


vid = AviSource("file")
vid_blur = vid.Blur(1.5)
ConditionalFilter(vid, vid_blur, vid, "AverageLuma()", "lessthan", "20")
Prefetch(2)


This results in a message showing up in the video: "Average Plane: this filter can only be used within run-time filters". Without prefetch, it works fine.

Since these are purely internal filters, nothing prevents you from having AverageLuma as a local function called by ConditionalFilter instead of trying to handle it as a separate special plugin.

[pinterf]

(Are there other good resources? I'd like to know about them.)

Check the readme.txt in the binary package.

I was already practicing a bit on editing things on avisynth wiki pages, I have updated the masktools sections, worked a bit on mvtools and other references of my plugin updates.

But I still need help on the new function pages, at least to have a good hierarchy and dummy skeleton article pages to be fill up.
At the moment Avisynth+ has only one dedicated page on wiki (http://avisynth.nl/index.php/AviSynth%2B). I'd better not put all the readme stuff there as a flat section. Nor I want to edit the filter section of the classic Avisynth pages.
If someone would create a good (even dummy) layout for the new functions, it would help a lot on bringing the knowledge base online.

[raffriff42]

Personally, I'd like to see an AVS+ Infobox (https://en.wikipedia.org/wiki/Help:Infobox) on each classic filter page, explaining the differences in some standardized form. Something similar in appearance to the "Abstract" box currently seen on external filter pages like MaskTools2 (http://avisynth.nl/index.php/MaskTools2).

>If someone would create a good (even dummy) layout for the new functions, it would help a lot on bringing the knowledge base online.
I really don't feel like working on a site that is about to be made obsolescent by a fork (https://en.wikipedia.org/wiki/Wikipedia:Content_forking) site.
(If you didn't know, I have been one of the very few active content contributors there - I have made hundreds of edits (http://avisynth.nl/index.php/Special:Contributions/Raffriff42), maybe thousands. The only other users that active are Reel.Deel (http://avisynth.nl/index.php/Special:Contributions/Reel.Deal) and Wilbert (http://avisynth.nl/index.php/Special:Contributions/Admin), the administrator of the site. So that 'someone' would probably be me.)

EDIT okay, I'm reconsidering my position. Whatever Reel.Deal does or doesn't do, I will begin (oh god) the rather large task of documenting AVS+ on the mainstream Avisynth wiki, as time permits. Crudely at first, as you describe. And as always, subject to Wilbert's approval.

[MysteryX]

When I build Avisynth+ from the Pinterf's source, I get this error when opening a script:

Avisynth open failure:
Script error: There is no function named 'Prefetch'.

What's going on here?

btw, there is code here that doesn't compile (Visual Studio 2017) because of 'y' being defined several times. It's easy to fix, you just have to rename the 2nd 'y'.
focus.cpp - af_horizontal_yuy2_c

[qyot27]

git checkout MT

[pinterf]

EDIT okay, I'm reconsidering my position. Whatever Reel.Deal does or doesn't do, I will begin (oh god) the rather large task of documenting AVS+ on the mainstream Avisynth wiki, as time permits. Crudely at first, as you describe. And as always, subject to Wilbert's approval.
Thank you "someone" :) It's really not too much people who keep this documentation site live, I appreciate your efforts.

[pinterf]

git checkout MT
Btw, I have to mention another news from the past weeks; with the patient help of qyot27, we were able to successfully compile the project with gcc (under Linux but not for Linux, which was a nightmare and a hard learning curve for me, thanks again qyot27). I don't know if this is good or not, we are by far not on par with Vapoursynth's multiplatform design and I guess we'll never be.

[MysteryX]

I looked at the code of ConditionalFilter and now I understand what the fuss is about in regards to ScriptClip and MT -- with current_frame not being found.

I don't like the design of it, but then, it supports complex scripting that can't be done otherwise.

I'm working on ConditionalFilterMT, which will be a limited subset of ConditionalFilter code that won't support complex expressions but that will work with MT. It's a hack, so not a solution for the core.

Btw, does VapourSynth support ScriptClip-like evaluation of expressions at run-time? How is it designed there?

[TheFluff]

Btw, does VapourSynth support ScriptClip-like evaluation of expressions at run-time? How is it designed there?

Yes it does (http://www.vapoursynth.com/doc/functions/frameeval.html). Since you can attach metadata to frames in VS you don't need the silly "runtime functions" that inspect the state of a shared variable to figure out which frame to use.

Really, I think the fundamental issue with a lot of things tacked onto Avisynth over the years is that the people who added them didn't understand functional programming.

[MysteryX]

Storing the frame number in a shared variable isn't viable in a MT environment no matter how we look at it.

Since that's what VS is doing... any way to support frame metadata without breaking old code?

Wait -- frame metadata won't help if we don't know the frame number!

[gonca]

I've installed AvisynthPlus-r2455-MT x86 and x64
My x64 tool chain works as it should so far
However the x86 has not
I have two apps that require AVISynth and they report Avisynth is not installed
When I put the AVISynth.dll from version 2.60 (regular AVISynth) everything is good
I know, from other forums, that AVS+ x86 will work with these apps
Can someone check my avsinfo log and tell me if I am missing any dependencies

Log created with: AVSMeter 2.5.4 (x86)

[OS/Hardware info]
Operating system: Windows 10 (x64) (Build 14393)
CPU: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
CPU features: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, FMA3


[Avisynth info]
VersionString: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
VersionNumber: 2.60
File version: 2.6.0.6
Interface Version: 6
Multi-threading support: No
Avisynth.dll location: C:\Windows\SysWoW64\avisynth.dll
Avisynth.dll time stamp: 2015-03-31, 06:40:57 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth\plugins


[CPP 2.5 / 32 Bit plugins]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll
C:\Program Files (x86)\AviSynth\plugins\Decomb521.dll
C:\Program Files (x86)\AviSynth\plugins\Deen.dll
C:\Program Files (x86)\AviSynth\plugins\hqdn3d.dll
C:\Program Files (x86)\AviSynth\plugins\nicaudio.dll
C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll
C:\Program Files (x86)\AviSynth\plugins\UnDot.dll [0.0.1.1]


[DLL dependencies (x86)]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\Decomb521.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\Deen.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\hqdn3d.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\nicaudio.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\UnDot.dll:
KERNEL32.dll



[Internal (core) functions]
AVIFileSource
AVISource
AddBorders
AlignedSplice
Amplify
AmplifydB
Animate
Apply
ApplyRange
Assert
AssumeBFF
AssumeFPS
AssumeFieldBased
AssumeFrameBased
AssumeSampleRate
AssumeScaledFPS
AssumeTFF
AudioDub
AudioDubEx
AudioTrim
AverageChromaU
AverageChromaV
AverageLuma
BicubicResize
BilinearResize
BlackmanResize
Blackness
BlankClip
Blur
Bob
Cache
ChangeFPS
Chr
ChromaUDifference
ChromaVDifference
ColorBars
ColorBarsHD
ColorKeyMask
ColorYUV
Compare
ComplementParity
ConditionalFilter
ConditionalReader
ConditionalSelect
ContinuedDenominator
ContinuedNumerator
ConvertAudio
ConvertAudioTo16bit
ConvertAudioTo24bit
ConvertAudioTo32bit
ConvertAudioTo8bit
ConvertAudioToFloat
ConvertBackToYUY2
ConvertFPS
ConvertToMono
ConvertToRGB
ConvertToRGB24
ConvertToRGB32
ConvertToY8
ConvertToYUY2
ConvertToYV12
ConvertToYV16
ConvertToYV24
ConvertToYV411
Crop
CropBottom
Default
Defined
DelayAudio
DeleteFrame
DirectShowSource
Dissolve
DoubleWeave
DuplicateFrame
Echo
EnsureVBRMP3Sync
Eval
Exist
FadeIO
FadeIO0
FadeIO2
FadeIn
FadeIn0
FadeIn2
FadeOut
FadeOut0
FadeOut2
FixBrokenChromaUpsampling
FixLuminance
FlipHorizontal
FlipVertical
FrameEvaluate
FreezeFrame
GaussResize
GeneralConvolution
GetChannel
GetChannels
GetLeftChannel
GetParity
GetRightChannel
Grayscale
Greyscale
HasAudio
HasVideo
Hex
Histogram
HorizontalReduceBy2
ImageReader
ImageSource
ImageSourceAnim
ImageWriter
Import
Info
Interleave
InternalCache
Invert
IsAudioFloat
IsAudioInt
IsBool
IsClip
IsFieldBased
IsFloat
IsFrameBased
IsInt
IsInterleaved
IsPlanar
IsRGB
IsRGB24
IsRGB32
IsString
IsY8
IsYUV
IsYUY2
IsYV12
IsYV16
IsYV24
IsYV411
KillAudio
KillVideo
Lanczos4Resize
LanczosResize
Layer
Letterbox
Levels
Limiter
LoadCPlugin
LoadPlugin
LoadVFAPIPlugin
LoadVirtualdubPlugin
Load_Stdcall_Plugin
Loop
LumaDifference
Mask
MaskHS
Max
Merge
MergeARGB
MergeChannels
MergeChroma
MergeLuma
MergeRGB
MessageClip
Min
MixAudio
MonoToStereo
Normalize
Null
OpenDMLSource
Ord
Overlay
PeculiarBlend
PixelType
PointResize
Preroll
Pulldown
RGBAdjust
RGBDifference
RGBDifferenceFromPrevious
RGBDifferenceToNext
ReduceBy2
ResampleAudio
ResetMask
Reverse
SSRC
ScriptClip
ScriptDir
ScriptFile
ScriptName
SegmentedAVISource
SegmentedDirectShowSource
Select
SelectEven
SelectEvery
SelectOdd
SelectRangeEvery
SeparateColumns
SeparateFields
SeparateRows
SetMemoryMax
SetPlanarLegacyAlignment
SetWorkingDir
Sharpen
ShowAlpha
ShowBlue
ShowFiveVersions
ShowFrameNumber
ShowGreen
ShowRed
ShowSMPTE
ShowTime
SincResize
SkewRows
SpatialSoften
Spline
Spline16Resize
Spline36Resize
Spline64Resize
StackHorizontal
StackVertical
String
Subtitle
Subtract
SuperEQ
SwapFields
SwapUV
TCPServer
TCPSource
TemporalSoften
Time
TimeStretch
Tone
Trim
Turn180
TurnLeft
TurnRight
Tweak
UDifferenceFromPrevious
UDifferenceToNext
UPlaneMax
UPlaneMedian
UPlaneMin
UPlaneMinMaxDifference
UToY
UToY8
UnalignedSplice
VDifferenceFromPrevious
VDifferenceToNext
VPlaneMax
VPlaneMedian
VPlaneMin
VPlaneMinMaxDifference
VToY
VToY8
Version
VersionNumber
VersionString
VerticalReduceBy2
WAVSource
Weave
WeaveColumns
WeaveRows
WriteFile
WriteFileEnd
WriteFileIf
WriteFileStart
YDifferenceFromPrevious
YDifferenceToNext
YPlaneMax
YPlaneMedian
YPlaneMin
YPlaneMinMaxDifference
YToUV
abs
acos
asin
atan
atan2
audiobits
audiochannels
audioduration
audiolength
audiolengthf
audiolengthhi
audiolengthlo
audiolengths
audiorate
bitand
bitchange
bitchg
bitclear
bitclr
bitlrotate
bitlshift
bitlshifta
bitlshiftl
bitlshifts
bitlshiftu
bitnot
bitor
bitrol
bitror
bitrrotate
bitrshifta
bitrshiftl
bitrshifts
bitrshiftu
bitsal
bitsar
bitset
bitshl
bitshr
bittest
bittst
bitxor
ceil
cos
cosh
exp
fillstr
findstr
float
floor
fmod
frac
framecount
framerate
frameratedenominator
frameratenumerator
height
hexvalue
int
lcase
leftstr
log
log10
midstr
muldiv
nop
pi
pow
rand
revstr
rightstr
round
sign
sin
sinh
sqrt
strcmp
strcmpi
strlen
tan
tanh
ucase
undefined
value
width


[External (plugin) functions]
BackwardClense
Clense
Decimate
Decomb521_Decimate
Decomb521_FieldDeinterlace
Decomb521_IsCombed
Decomb521_Telecide
Decomb_Decimate
Decomb_FieldDeinterlace
Decomb_IsCombed
Decomb_Telecide
Deen
Deen_Deen
FieldDeinterlace
ForwardClense
IsCombed
MCClense
NicAC3Source
NicBufferAudio
NicDTSSource
NicLPCMSource
NicMPASource
NicMPG123Source
NicRawPCMSource
RemoveGrain
RemoveGrainSSE2_BackwardClense
RemoveGrainSSE2_Clense
RemoveGrainSSE2_ForwardClense
RemoveGrainSSE2_MCClense
RemoveGrainSSE2_RemoveGrain
Telecide
UnDot
UnDot_UnDot
hqdn3d
hqdn3d_hqdn3d
nicaudio_NicAC3Source
nicaudio_NicBufferAudio
nicaudio_NicDTSSource
nicaudio_NicLPCMSource
nicaudio_NicMPASource
nicaudio_NicMPG123Source
nicaudio_NicRawPCMSource

[Groucho2004]

Can someone check my avsinfo log and tell me if I am missing any dependencies
Nothing missing. However, the log shows that you have Avisynth 2.6 in syswow64, not Avisynth+.

[gonca]

That is the only way I can make X86 version work with these apps
I'll redo the log with the AVS+ dll

Here is the new log

Log created with: AVSMeter 2.5.4 (x86)

[OS/Hardware info]
Operating system: Windows 10 (x64) (Build 14393)
CPU: Intel(R) Core(TM) i7-6900K CPU @ 3.20GHz
CPU features: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, FMA3


[Avisynth info]
VersionString: AviSynth+ 0.1 (r2455, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SysWoW64\avisynth.dll
Avisynth.dll time stamp: 2017-03-16, 16:29:52 (UTC)
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth\plugins


[CPP 2.5 / 32 Bit plugins]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll
C:\Program Files (x86)\AviSynth\plugins\Decomb521.dll
C:\Program Files (x86)\AviSynth\plugins\Deen.dll
C:\Program Files (x86)\AviSynth\plugins\hqdn3d.dll
C:\Program Files (x86)\AviSynth\plugins\nicaudio.dll
C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll
C:\Program Files (x86)\AviSynth\plugins\UnDot.dll [0.0.1.1]

[CPP 2.6 / 32 Bit plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll


[DLL dependencies (x86)]
C:\Program Files (x86)\AviSynth\plugins\Decomb.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\Decomb521.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\Deen.dll:
KERNEL32.dll
MSVCRT.dll

C:\Program Files (x86)\AviSynth\plugins\hqdn3d.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\nicaudio.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\RemoveGrainSSE2.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth\plugins\UnDot.dll:
KERNEL32.dll

C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll:
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll

C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll:
WINMM.dll
QUARTZ.dll
ole32.dll
USER32.dll
OLEAUT32.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll

C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll:
DevIL.dll
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll

C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll:
MSVCP140.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll

C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll:
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll

C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll:
USER32.dll
KERNEL32.dll
VCRUNTIME140.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll



[Internal (core) functions]
AVIFileSource
AVISource
AddAlphaPlane
AddAutoloadDir
AddBorders
AlignedSplice
Amplify
AmplifydB
Animate
Apply
ApplyRange
Assert
AssumeBFF
AssumeFPS
AssumeFieldBased
AssumeFrameBased
AssumeSampleRate
AssumeScaledFPS
AssumeTFF
AudioDub
AudioDubEx
AudioTrim
AutoloadPlugins
AverageB
AverageChromaU
AverageChromaV
AverageG
AverageLuma
AverageR
BDifference
BDifferenceFromPrevious
BDifferenceToNext
BPlaneMax
BPlaneMedian
BPlaneMin
BPlaneMinMaxDifference
BicubicResize
BilinearResize
BitsPerComponent
BlackmanResize
Blackness
BlankClip
Blur
Bob
Cache
ChangeFPS
Chr
ChromaUDifference
ChromaVDifference
ClearAutoloadDirs
ColorBars
ColorBarsHD
ColorKeyMask
ColorSpaceNameToPixelType
ColorYUV
CombinePlanes
Compare
ComplementParity
ComponentSize
ConditionalFilter
ConditionalReader
ConditionalSelect
ContinuedDenominator
ContinuedNumerator
ConvertAudio
ConvertAudioTo16bit
ConvertAudioTo24bit
ConvertAudioTo32bit
ConvertAudioTo8bit
ConvertAudioToFloat
ConvertBackToYUY2
ConvertBits
ConvertFPS
ConvertTo16bit
ConvertTo8bit
ConvertToFloat
ConvertToMono
ConvertToPlanarRGB
ConvertToPlanarRGBA
ConvertToRGB
ConvertToRGB24
ConvertToRGB32
ConvertToRGB48
ConvertToRGB64
ConvertToY
ConvertToY8
ConvertToYUV411
ConvertToYUV420
ConvertToYUV422
ConvertToYUV444
ConvertToYUY2
ConvertToYV12
ConvertToYV16
ConvertToYV24
ConvertToYV411
Crop
CropBottom
Default
Defined
DelayAudio
DeleteFrame
Dissolve
DoubleWeave
DuplicateFrame
Echo
EnsureVBRMP3Sync
Eval
Exist
ExtractA
ExtractB
ExtractG
ExtractR
ExtractU
ExtractV
ExtractY
FadeIO
FadeIO0
FadeIO2
FadeIn
FadeIn0
FadeIn2
FadeOut
FadeOut0
FadeOut2
FixBrokenChromaUpsampling
FixLuminance
FlipHorizontal
FlipVertical
FrameEvaluate
FreezeFrame
FunctionExists
GDifference
GDifferenceFromPrevious
GDifferenceToNext
GPlaneMax
GPlaneMedian
GPlaneMin
GPlaneMinMaxDifference
GaussResize
GeneralConvolution
GetChannel
GetChannels
GetLeftChannel
GetParity
GetRightChannel
Grayscale
Greyscale
HasAlpha
HasAudio
HasVideo
Hex
Histogram
HorizontalReduceBy2
Import
Info
Interleave
InternalCache
InternalFunctionExists
Invert
Is420
Is422
Is444
IsAudioFloat
IsAudioInt
IsBool
IsClip
IsFieldBased
IsFloat
IsFrameBased
IsInt
IsInterleaved
IsPackedRGB
IsPlanar
IsPlanarRGB
IsPlanarRGBA
IsRGB
IsRGB24
IsRGB32
IsRGB48
IsRGB64
IsString
IsVideoFloat
IsY
IsY8
IsYUV
IsYUVA
IsYUY2
IsYV12
IsYV16
IsYV24
IsYV411
KillAudio
KillVideo
Lanczos4Resize
LanczosResize
Layer
Letterbox
Levels
Limiter
LoadCPlugin
LoadPlugin
Load_Stdcall_Plugin
LogMsg
Loop
LumaDifference
Mask
MaskHS
Max
Merge
MergeARGB
MergeChannels
MergeChroma
MergeLuma
MergeRGB
MessageClip
Min
MixAudio
MonoToStereo
Normalize
Null
NumComponents
OpenDMLSource
Ord
Overlay
PeculiarBlend
PixelType
PlaneToY
PointResize
Prefetch
Preroll
Pulldown
RDifference
RDifferenceFromPrevious
RDifferenceToNext
RGBAdjust
RGBDifference
RGBDifferenceFromPrevious
RGBDifferenceToNext
RPlaneMax
RPlaneMedian
RPlaneMin
RPlaneMinMaxDifference
ReduceBy2
RemoveAlphaPlane
ResampleAudio
ResetMask
Reverse
ScriptClip
ScriptDir
ScriptFile
ScriptName
SegmentedAVISource
SegmentedDirectShowSource
Select
SelectEven
SelectEvery
SelectOdd
SelectRangeEvery
SeparateColumns
SeparateFields
SeparateRows
SetFilterMTMode
SetLogParams
SetMemoryMax
SetPlanarLegacyAlignment
SetWorkingDir
Sharpen
ShowAlpha
ShowBlue
ShowFiveVersions
ShowFrameNumber
ShowGreen
ShowRed
ShowSMPTE
ShowTime
ShowU
ShowV
ShowY
SincResize
SkewRows
SpatialSoften
Spline
Spline16Resize
Spline36Resize
Spline64Resize
StackHorizontal
StackVertical
String
Subtitle
Subtract
SwapFields
SwapUV
TemporalSoften
Time
Tone
Trim
Turn180
TurnLeft
TurnRight
Tweak
UDifferenceFromPrevious
UDifferenceToNext
UPlaneMax
UPlaneMedian
UPlaneMin
UPlaneMinMaxDifference
UToY
UToY8
UnalignedSplice
VDifferenceFromPrevious
VDifferenceToNext
VPlaneMax
VPlaneMedian
VPlaneMin
VPlaneMinMaxDifference
VToY
VToY8
Version
VersionNumber
VersionString
VerticalReduceBy2
WAVSource
Weave
WeaveColumns
WeaveRows
WriteFile
WriteFileEnd
WriteFileIf
WriteFileStart
YDifferenceFromPrevious
YDifferenceToNext
YPlaneMax
YPlaneMedian
YPlaneMin
YPlaneMinMaxDifference
YToUV
abs
acos
asin
atan
atan2
audiobits
audiochannels
audioduration
audiolength
audiolengthf
audiolengthhi
audiolengthlo
audiolengths
audiorate
bitand
bitchange
bitchg
bitclear
bitclr
bitlrotate
bitlshift
bitlshifta
bitlshiftl
bitlshifts
bitlshiftu
bitnot
bitor
bitrol
bitror
bitrrotate
bitrshifta
bitrshiftl
bitrshifts
bitrshiftu
bitsal
bitsar
bitset
bitshl
bitshr
bittest
bittst
bitxor
ceil
cos
cosh
exp
fillstr
findstr
float
floor
fmod
frac
framecount
framerate
frameratedenominator
frameratenumerator
height
hexvalue
int
lcase
leftstr
log
log10
midstr
muldiv
nop
pi
pow
rand
replacestr
revstr
rightstr
round
sign
sin
sinh
sqrt
strcmp
strcmpi
strlen
tan
tanh
ucase
undefined
value
width


[External (plugin) functions]
BackwardClense
Clense
ConvertFromDoubleWidth
ConvertFromStacked
ConvertStacked_ConvertFromDoubleWidth
ConvertStacked_ConvertFromStacked
ConvertStacked_ConvertToDoubleWidth
ConvertStacked_ConvertToStacked
ConvertToDoubleWidth
ConvertToStacked
Decimate
Decomb521_Decimate
Decomb521_FieldDeinterlace
Decomb521_IsCombed
Decomb521_Telecide
Decomb_Decimate
Decomb_FieldDeinterlace
Decomb_IsCombed
Decomb_Telecide
Deen
Deen_Deen
DirectShowSource
DirectShowSource_DirectShowSource
FieldDeinterlace
ForwardClense
ImageReader
ImageSeq_ImageReader
ImageSeq_ImageSource
ImageSeq_ImageSourceAnim
ImageSeq_ImageWriter
ImageSource
ImageSourceAnim
ImageWriter
IsCombed
LoadVirtualdubPlugin
MCClense
NicAC3Source
NicBufferAudio
NicDTSSource
NicLPCMSource
NicMPASource
NicMPG123Source
NicRawPCMSource
RemoveGrain
RemoveGrainSSE2_BackwardClense
RemoveGrainSSE2_Clense
RemoveGrainSSE2_ForwardClense
RemoveGrainSSE2_MCClense
RemoveGrainSSE2_RemoveGrain
SSRC
Shibatch_SSRC
Shibatch_SuperEQ
SuperEQ
Telecide
TimeStretch
TimeStretch_TimeStretch
UnDot
UnDot_UnDot
VDubFilter_LoadVirtualdubPlugin
hqdn3d
hqdn3d_hqdn3d
nicaudio_NicAC3Source
nicaudio_NicBufferAudio
nicaudio_NicDTSSource
nicaudio_NicLPCMSource
nicaudio_NicMPASource
nicaudio_NicMPG123Source
nicaudio_NicRawPCMSource

[Groucho2004]

That is the only way I can make X86 version work with these appsWhich apps?

I'll redo the log with the AVS+ dllOK.

[gonca]

BD_RB and AVStoDVD
The x64 chain is basically my own scripts and command lines, and it works fine

[Groucho2004]

BD_RB and AVStoDVDThe new log doesn't show any problems. If there were any, there would be a section "[Plugin errors/warnings]" after "[Avisynth info]".
There is no reason why the two programs should not work with AVS+, to my knowledge it's fully backward compatible to AVS2.6 except (ancient) v2.0 C/C++ plugins which are not supported by AVS+.

You'll have to pester the authors to change/extend their detection functions. ;) The Avisynth API provides a bunch of functions to determine the version reliably.

[gonca]

OK
Thanks

[MysteryX]

Pinterf, I'll have to fix this for ConditionalMT, but that also needs to be fixed in Avisynth+ core since this needs to work without MT.
https://forum.doom9.org/showthread.php?p=1804874#post1804874

[MysteryX]

I'm getting a weird performance drop with ChangeFps in the middle of FrameRateConverter.


EM = EM.ChangeFPS(NewNum, NewDen)


CPU drops from 80% to 20% if I place a "return EM" after this line than before, with Prefetch(8). My guess is that the change of frame rate is screwing up the thread pool optimizer or something.

[pinterf]

Pinterf, I'll have to fix this for ConditionalMT, but that also needs to be fixed in Avisynth+ core since this needs to work without MT.
https://forum.doom9.org/showthread.php?p=1804874#post1804874
Answered in your other topic, copy code from the MT branch for doing statistics on non-8 bit data.

[MysteryX]

I was thinking about conditional functions. As we know, the problem is passing the current frame number, and storing it in a global var doesn't work in a multi-threaded environment -- and the code can't pass it directly to the functions within the expression because complex expressions are being handled by the Expression Evaluator.

How about passing frame_number to the Expression Evaluator, which when specified, gets passed to the filters through user_data?

It's kind of a hack but it might just work.

Edit: After looking at the code, Evaluate translates into env2->Invoke, which doesn't have user_data as parameter. For per-frame filters, it would make the most sense to take the frame_number as the first standard parameter.

So PExpression.Evaluate could have a second syntax that takes frame_count as parameter for frame-specific expressions. In that function, all function calls receive frame_count as the first parameter during invokes.

The issue isn't with MT really -- but instead of a badly designed per-frame expression evaluator that stored frame_count in a thread-specific global var as a hack.

Now that I'm at it, I might try to dig into the code myself, it doesn't look too hard. If I can't fix it, I'll let Pinterf do it :) Meanwhile Pinterf can look into the other issues I pointed out.

[pinterf]

Edit: After looking at the code, Evaluate translates into env2->Invoke, which doesn't have user_data as parameter. For per-frame filters, it would make the most sense to take the frame_number as the first standard parameter.

This is where the thread-local current_frame is lost, in ScriptEnvirontmentTLS.h

virtual bool __stdcall Invoke(AVSValue *result, const char* name, const AVSValue& args, const char* const* arg_names=0)
{
// This is why e.g. YDifferenceFromPrevious does not see "last" and "current_frame" defined in ScriptClip's GetFrame under MT.
// These variables are thread local to this very TLS but are not seen by core (core has a different subset of variables)
// invoking a runtime function here is losing the TLS scope
if (!_stricmp(name, "YDifferenceFromPrevious")) {
int x = 0; // debug stop
}
return core->Invoke(result, name, args, arg_names=0);
}


This is the "torture script" :)
BlankClip(width=640,height=480,length=50,pixel_type="YV24",color=$000000)
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious))")
Prefetch(2)

[MysteryX]

This is the "torture script" :)
ScriptClip is working :)

Just a few final details and I'll submit changes :)

No "hack" was needed :)

AverageLuma still brings a value of 6653 on ColorBarsHD in 14-bit :(

[MysteryX]

dammit.

I had done the changes over branch MT-pfmod instead of branch MT, and it was working.

Now I've ported the changes over to MT branch and am ready to submit.

**BUT** now there is a thread lock issue -- with something that changed since you merged the pfmod branch.

I'll submit anyway, and you can look at it from there. It *WAS* working!

Pull request submitted. (https://github.com/pinterf/AviSynthPlus/pull/10)

The solution was to treat per-frame functions differently. They now always take frame_number as second argument (after clip). ScriptParser now takes frame_number in its constructor, and automatically passes it to the per-frame functions as needed. It works beautifully.

Now you can also use this to write the average luma value of the 10th frame

Subtitle(string(AverageLuma(10)))

[StainlessS]

Now you can also use this to write the average luma value of the 10th frame

Subtitle(string(AverageLuma(10)))


Again I have not been following too closely, but would that be
AverageLuma(Offset=10) ie relative to current frame (whatever than may mean in this context).

[raffriff42]

>Subtitle(string(AverageLuma(10)))
Yes, that's how it's worked since AVS 2.61.
AverageLuma(clip [, int offset = 0])
http://avisynth.nl/index.php/Internal_functions#Average

>AverageLuma still brings a value of 6653 on ColorBarsHD in 14-bit
Which is fine.
6653/2^(14-8) == 6653/2^6 == 6653/64 == 103.953

[MysteryX]

Again I have not been following too closely, but would that be
AverageLuma(Offset=10) ie relative to current frame (whatever than may mean in this context).
hum.. we have to ensure there is no confusion between function versions.


ScriptClip(last, "Subtitle(String(AverageLuma(10)))")


AverageLuma will try functions in this order
- AverageLuma(10)
- AverageLuma(last, 10) # this version will be taken
- AverageLuma(last, n, 10) # we need to take this version

This will cause problems, as it will return AverageLuma of the 10th frame instead of applying an offset of 10 to the current frame.

If we reverse the order of look-up and check
- AverageLuma(last, n, 10) # we need to take this version
before
- AverageLuma(last, 10) # this version will be taken
when frame_number is specified, then it should fix the problem.

There is also the risk that some other standard function gets passed "frame_number" as its int argument when it shouldn't.

This, in contrast, should specify frame_number instead of offset. Previously, these filters couldn't be used outside of a conditional function.

Subtitle(String(AverageLuma(10)))

[MysteryX]

We just have to call "AverageLuma(last, n, 10)" as the 2nd try IF current_frame is set on the parser (called within a conditional function) AND function_name is in the list of conditional filters.

This should do it.

expression.cpp, line 538, invert the 2 blocks of code.

// first try without implicit "last"
try
{ // Invoke can always throw by calling a constructor of a filter that throws
if (env2->Invoke(&result, name, AVSValue(args.data()+2, arg_expr_count), arg_expr_names+2))
return result;
} catch(const IScriptEnvironment::NotFound&){}

// if that fails, try with implicit "last" (except when OOP notation was used)
if (!oop_notation && env2->GetVar("last", &args[1]))
{
try
{
if (env2->Invoke(&result, name, AVSValue(args.data()+1, arg_expr_count+1), arg_expr_names+1))
return result;
} catch(const IScriptEnvironment::NotFound&){}

// for per-frame expressions, try with implicit "last" and "frame_number"
if (frame_number >= 0)
{
args[0] = args[1]; // "last"
args[1] = AVSValue(frame_number);
try
{
if (env2->Invoke(&result, name, AVSValue(args.data(), arg_expr_count+2), arg_expr_names))
return result;
}
catch (const IScriptEnvironment::NotFound&) {}
}
}

At "frame_number > 0", also check if "name" is in the list of conditional_filters.

TODO for Pinterf:
- Fix the deadlock
- Implement the change mentioned here
- Normalize values for high-bit-depth clips

[MysteryX]

Another issue: LumaDifference takes 2 clips. The function definition is "cic". We can't call "LumaDifference(clip1, clip2)".

The solution may be to make frame_number as the first parameter, so the definition becomes "icc".

Function evaluation then goes in this order for "LumaDifference(clip1, clip2)"
- LumaDifference(clip1, clip2) # not found
- LumaDifference(frame_number, clip1, clip2) # this version will be taken
- LumaDifference(frame_number, last, clip1, clip2)
- LumaDifference(last, clip1, clip2)

This means all functions in conditional_functions.cpp need params to start with "ic" instead of "ci", and all other functions in that page to reflect the parameter change. Then the code in expression.cpp can easily be adapted for that change. This should work perfect then.

Also to take into consideration... with this model, anyone could write custom per-frame functions as long as they respect the parameters order. If they do that, however, we can't check against a hard-coded list of per-frame functions. If frame_number is before the clip in the parameters order, it should avoid confusion between frame_number vs offset being passed as parameter -- are there still cases where it would cause problem?

[pinterf]

TODO for Pinterf:
- Fix the deadlock

Thanks. I have made already (nonpublished because they were dead end) fixes twice during the past months that had been seemed to be a good idea but were causing deadlocks sometimes (the nasty thing is when the tests are run with increasing Prefetch threads and the error appears over Prefetch(7) - timing? frame order dependencies?), so this solution just propagates the error into a deadlock.

Anyway, I will check the code whether the deadlock is of different origin than my ones and will ask if I have questions or requests.

Until then please test further, find other heavy scripts from doom9, I'm sure StainlessS has some - that are using conditional functions (with or without extra parameters).

[pinterf]

Another issue: LumaDifference takes 2 clips. The function definition is "cic". We can't call "LumaDifference(clip1, clip2)".

The solution may be to make frame_number as the first parameter, so the definition becomes "icc".

In OOP syntax the last clip result will turn implicitely into the first parameter of the filter. That's why clip is always at the first place.

[Gavino]

with this model, anyone could write custom per-frame functions as long as they respect the parameters order. If they do that, however, we can't check against a hard-coded list of per-frame functions.
It was always possible to write your own run-time functions, even in classic Avisynth, just by reading the value of the variable 'current_frame'.
In any case, having a list of 'special' function names hard-coded into the parser is ugly.

However, not knowing whether a function being called really wants to be supplied with the current frame number gives rise to the other problem you identified:
There is also the risk that some other standard function gets passed "frame_number" as its int argument when it shouldn't.

A better scheme would be to use a new argument type identifier (eg 'n') in the function template string to mark arguments that expect to be given the current frame number.
That way, the argument can be in any position and you avoid the complications (and performance overhead) of trying different parameter combinations using 'implicit current_frame' with or without 'implicit last'.

[StainlessS]

Here, my way of getting user supplied n, and delta (as in v2.6 AverageLuma Offset).


// Snippet, originally from Gavino
AVSValue __cdecl GetVar(IScriptEnvironment* env, const char* name) {
try {return env->GetVar(name);} catch (IScriptEnvironment::NotFound) {} return AVSValue();}


AVSValue __cdecl RT_YDifference(AVSValue args, void* user_data, IScriptEnvironment* env) {
char * myName="RT_YDifference: ";
if(!args[0].IsClip())
env->ThrowError("%sMust have a clip",myName);
PClip child = args[0].AsClip(); // Clip
int n,n2;
if(args[1].IsInt()) {n = args[1].AsInt(); } // Frame n
else {
AVSValue cn = GetVar(env,"current_frame");
if (!cn.IsInt()) env->ThrowError("%s'current_frame' only available in runtime scripts",myName);
n = cn.AsInt(); // current_frame
}
n2 = args[2].AsInt(1); // Delta: default 1 as YDifferenceFromNext
n2 += n; // n2 relative n --> frame number
const VideoInfo &vi = child->GetVideoInfo();
n = (n<0) ? 0 : (n>=vi.num_frames) ?vi.num_frames-1:n; // Range limit frame n
n2 = (n2<0) ? 0 : (n2>=vi.num_frames)?vi.num_frames-1:n2; // Range limit frame n2

if(!vi.IsPlanar() && !vi.IsYUY2() && !vi.IsRGB24() && !vi.IsRGB32()) {
env->ThrowError("%sPlanar, YUY2, RGB24 and RGB32 Only",myName);
}

if(vi.width==0 || vi.num_frames==0) env->ThrowError("%sclip must have video",myName);

int xx=args[3].AsInt(0);
int yy=args[4].AsInt(0);
int ww=args[5].AsInt(0);
int hh=args[6].AsInt(0);
int xx2=args[7].AsInt(xx);
int yy2=args[8].AsInt(yy);
bool altscan=args[9].AsBool(false);
const int matrix = args[10].AsInt(vi.width>1100 || vi.height>600?3:2); // Matrix: REC601 : 1=REC709 : 2 = PC601 : 3 = PC709

if(ww <= 0) ww += vi.width - xx;
if(hh <= 0) hh += vi.height - yy;
if(altscan && ((hh & 0x01) == 0)) --hh; // If altscan then ensure ODD number of lines, last line other field does not count.
altscan=(altscan && hh!=1);

if(xx < 0 || xx >=vi.width) env->ThrowError("%sInvalid X coord",myName);
if(yy < 0 || yy >=vi.height) env->ThrowError("%sInvalid Y coord",myName);
if(ww <= 0 || xx + ww > vi.width) env->ThrowError("%sInvalid W coord for X",myName);
if(hh <= 0 || yy + hh > vi.height) env->ThrowError("%sInvalid H coord for Y",myName);
if(xx2 < 0 || xx2 >=vi.width) env->ThrowError("%sInvalid X2 coord",myName);
if(yy2 < 0 || yy2 >=vi.height) env->ThrowError("%sInvalid Y2 coord",myName);
if(xx2 + ww >vi.width) env->ThrowError("%sInvalid W coord for X2",myName);
if(yy2 + hh >vi.height) env->ThrowError("%sInvalid H coord for Y2",myName);

PVideoFrame src;
PVideoFrame src2;

// fetch frames in lo->hi order
if(n <= n2) {src = child->GetFrame(n,env); src2 = child->GetFrame(n2,env);
} else {src2 = child->GetFrame(n2,env); src = child->GetFrame(n,env);}

double result = 0.0;
if(vi.IsYUY2()) {
result = PVF_LumaDifference_YUY2(src,src2,xx,yy,ww,hh,xx2,yy2,altscan);
} else if(vi.IsPlanar()) {
result = PVF_LumaDifference_Planar(src,src2,xx,yy,ww,hh,xx2,yy2,altscan);
} else if(vi.IsRGB()) {
if(matrix<0 || matrix > 3) env->ThrowError("%Matrix 0 -> 3",myName);
result = PVF_LumaDifference_RGB(src,src2,xx,yy,ww,hh,xx2,yy2,altscan,matrix,vi.IsRGB32());
}
return result;
}

[MysteryX]

This could be another solution -- and less hacky: adding a named argument called "current_frame" at the end.

Argument "n" runs the risk of creating conflicts with other plugins, and doesn't say what it is.

Function evaluation then goes in this order for "LumaDifference(clip1, clip2)"
- LumaDifference(clip1, clip2, current_frame) # this version will be taken
- LumaDifference(last, clip1, clip2, current_frame)
- LumaDifference(clip1, clip2)
- LumaDifference(last, clip1, clip2)

This could work.

That, or
- LumaDifference(n, clip1, clip2) # if (args[0].IsClip())
- LumaDifference(n, last, clip1, clip2)
- LumaDifference(clip1, clip2)
- LumaDifference(last, clip1, clip2)

This also would work if the 1st is being tried only if args[0] is a clip. Because of OOP syntax, clip is always being placed first, thus there are no functions starting with "int,clip" so trying functions starting with "int,clip" can only succeed on per-frame functions. Personally I like this option better because it imposes no restriction on variable names, and it is cleaner (IMO).


ScriptClip(last, "Subtitle(String(AverageLuma(10)))")

This will call AverageLuma(n, last, 10)


Subtitle(String(AverageLuma(10)))
Subtitle(String(last.AverageLuma(10)))

These two will fail -- but were never meant to work.


Subtitle(String(AverageLuma(50, last, 10)))

This will display the AverageLuma of the 50th frame with offset=10 on every frame

If we instead use a named parameter

Subtitle(String(AverageLuma(10, current_frame=50)))
Subtitle(String(last.AverageLuma(10, current_frame=50)))

These two would work.

Which solution is best? Personally I'd go for "ic" as the first args.

[pinterf]

I was just inspecting the same, that LumaDifference will be broken.

[MysteryX]

I'm updating the code and will re-push.

[MysteryX]

Code updated and submitted. (https://github.com/pinterf/AviSynthPlus/pull/10)

I tried all samples from the ConditionalFilter wiki page and it worked -- except samples about writing current_frame to the screen.

To write a per-frame filter, its definition must start with "ic" for "frame_number|last".

[MysteryX]

For "current_frame", I could create a function "current_frame(n,c)" that returns n. This should make it work.

[MysteryX]

Function "current_frame" added. (https://github.com/pinterf/AviSynthPlus/pull/10/commits/56682b902d60bbc5088472073ddacc6e90316367) Now all samples work :D

[vcmohan]

I am experimenting with a new code for a plugin Balloon. I found that the call BitBlt is causing access violation if used in multi thread mode. I am using vdub to monitor output. If I step frame by frame it works out OK, but if I press the run button the access violation occurs. After checking I found that the BitBlt call is the culprit.i am on r2420_MT 64 bit version.
My simple code to check problem in Get Frame method is
PVideoFrame __stdcall EffectBalloon::GetFrame(int in, IScriptEnvironment* env)
{
// This is the implementation of the constructor.
PVideoFrame Frame = child->GetFrame(in, env);
if(in<StartFrame || in>EndFrame)
return Frame;
int n=in-StartFrame;
int nframes= EndFrame-StartFrame+1;

PVideoFrame dst = env->NewVideoFrame(vi);
const unsigned char *fp= Frame->GetWritePtr();
const int fpitch = Frame->GetPitch();
const int bwd = vi.width;
const int bht = dst->GetHeight();
int dpitch = dst->GetPitch();

unsigned char* dp= dst->GetWritePtr();
const int kb = vi.BytesFromPixels(1) ;
// copy input frame on to output dst. For RGB, YUY2 and Y of Planar formats
env->BitBlt(dp, dpitch, fp, fpitch, Frame->GetRowSize(), bht);// commenting this out runs ok.
return Frame;// return dst;returning dst or frame have same problem ;
If I comment out the BitBlt call it runs OK.

The script used to test is
[code]
loadplugin (---------balloon.dll)
SetFilterMTMode("Balloon", MT_NICE_FILTER)
colorbars()
trim(1,100)
converttoRGB24()
Balloon()
return(last)
prefetch(6)
[\code]

The other problem I posted on 14th and 15th April seems to habeen lost.

[pinterf]

I am experimenting with a new code for a plugin Balloon. I found that the call BitBlt is causing access violation if used in multi thread mode. I am using vdub to monitor output. If I step frame by frame it works out OK, but if I press the run button the access violation occurs. After checking I found that the BitBlt call is the culprit.i am on r2420_MT 64 bit version.
My simple code to check problem in Get Frame method is
PVideoFrame __stdcall EffectBalloon::GetFrame(int in, IScriptEnvironment* env)
{
// This is the implementation of the constructor.
PVideoFrame Frame = child->GetFrame(in, env);
if(in<StartFrame || in>EndFrame)
return Frame;
int n=in-StartFrame;
int nframes= EndFrame-StartFrame+1;

PVideoFrame dst = env->NewVideoFrame(vi);
const unsigned char *fp= Frame->GetWritePtr();
const int fpitch = Frame->GetPitch();
const int bwd = vi.width;
const int bht = dst->GetHeight();
int dpitch = dst->GetPitch();

unsigned char* dp= dst->GetWritePtr();
const int kb = vi.BytesFromPixels(1) ;
// copy input frame on to output dst. For RGB, YUY2 and Y of Planar formats
env->BitBlt(dp, dpitch, fp, fpitch, Frame->GetRowSize(), bht);// commenting this out runs ok.
return Frame;// return dst;returning dst or frame have same problem ;
If I comment out the BitBlt call it runs OK.

Could you check the value of Frame->GetRowsize()? And that the dimensions and format of the source/destination is matching? Does it fail on both debug and release version (filling unused variables may be optimized out).

[pinterf]

@MisteryX: Unfortunately not only "current_frame", but variable "last" is also affected in the MT scope change (I have posted the TLS Invoke code previously).
Usually "last" exists in the main thread (whose variables are visible when the filter is instantiated) so it won't give you instant error.
It is just possible that the filter is working with the wrong "last" value.

We have to solve the whole ScriptClip problem, that is how can an instance use the thread local last and current_frame.

I was experimenting a bit and when it seemed to be working in Prefetch(8), Prefetch(120) failed.

I recommend tests with multiple lines of the same simple "torture" line.
A clip with white-grey-black-white... should result in a given sequence in LumaDifference that we can check.

Then use two or more active clips e.g. YV12/YUV444P16, first with level sequence 16-128-235, the other one 50-128-200 and get the LumaDifference for both, and put the results into a common clip.
The values should follow in the proper order in repeating sequence.
Do it with large Prefetch values, timing and frame request sequence problems may appear under extreme threading conditions but it should be correct anyhow.

[StainlessS]

VideoFrame __stdcall EffectBalloon::GetFrame(int in, IScriptEnvironment* env)
{
// This is the implementation of the constructor.
PVideoFrame Frame = child->GetFrame(in, env);
if(in<StartFrame || in>EndFrame)
return Frame;
// int n=in-StartFrame; // Unused
// int nframes= EndFrame-StartFrame+1; // Unused

PVideoFrame dst = env->NewVideoFrame(vi);
const unsigned char *fp= Frame->GetWritePtr(); // src fp, const unsigned char * to WRITEPTR
const int fpitch = Frame->GetPitch();
// const int bwd = vi.width; // Unused
const int bht = dst->GetHeight();
int dpitch = dst->GetPitch();

unsigned char* dp= dst->GetWritePtr();
// const int kb = vi.BytesFromPixels(1) ; // Unused
// copy input frame on to output dst. For RGB, YUY2 and Y of Planar formats
env->BitBlt(dp, dpitch, fp, fpitch, Frame->GetRowSize(), bht);// commenting this out runs ok.
return Frame;// return dst;returning dst or frame have same problem ;


Just pointing out a few things.

EDIT: What is effect of taking writeptr on non writable src frame ?

[vcmohan]

Could you check the value of Frame->GetRowsize()? And that the dimensions and format of the source/destination is matching? Does it fail on both debug and release version (filling unused variables may be optimized out).
The Frame dimensions and row size are ok. Width 640, rowsize 1920, bytes per pixel 3 (as RGB24).
When I tried compiling in debug mode I ran into problems. (using vs 13 community version update 4). First it complained about not finding avisynth.h file which was placed in include folder, inspite Path of this folder being in the additional include folders. After placing copy of this along with avs folder in my project itself, it started complaining not able to open the files in the avs folder.(#include <avs/config.h>
#include <avs/capi.h>
#include <avs/types.h>) may be <> to be replaced by " in the header file? I gave up trying.
I noted another spooky thing. When I commented out the BitBlt and stepping in vdub I noticed that each frame was getting the previous frame output as dst. So I could see by end all previous frame outputs one over other. (my Balloon traverses a parabolic path and I see it at all stages in the last frame). However if I press run button I see occassionally colorbars frames also.Is this normal behaviour. I thought that the output will not be recycled so soon.

[pinterf]

EDIT: What is effect of taking writeptr on non writable src frame ?
When the reference count for the frame and its framebuffer is not 1 then it returns NULL.

[pinterf]

I noted another spooky thing. When I commented out the BitBlt and stepping in vdub I noticed that each frame was getting the previous frame output as dst. So I could see by end all previous frame outputs one over other. (my Balloon traverses a parabolic path and I see it at all stages in the last frame). However if I press run button I see occassionally colorbars frames also.Is this normal behaviour. I thought that the output will not be recycled so soon.
It's normal :) When I was starting working on masktools I went crazy when remnants from previous random frames appeared in the output until I realized that no U and V processing was done (no copy or fill or whatever, the documentation properly mentioned that the content in such case can be anything for not in-place filters)

[MysteryX]

@MisteryX: Unfortunately not only "current_frame", but variable "last" is also affected in the MT scope change
I was worried about that, but then hadn't seen any issue in my tests. It is very possible it will fail under extreme circumstances, yes.

Any suggestion?

It's not making a difference with the ScriptClip expression -- rather it is to reset "last" after the expression is evaluated. Doesn't Eval have the same issue?

[pinterf]

I think that only runtime is affected. I'd like to see an "elegant" way to solve it, but either this way does not exist (unless we are breaking and rewriting the whole MT internal concepts - which I'm not willing to do :) ) or have to learn on and do more reverse engineering and experimenting.

[MysteryX]

Eval doesn't do this, but EvalOop does the exact same "last" reset as ScriptClip.

It leaves room for bugs -- but has anyone encountered a problem with Clip.Eval ?

Which specific circumstance will be affected by that?

[qyot27]

After placing copy of this along with avs folder in my project itself, it started complaining not able to open the files in the avs folder.(#include <avs/config.h>
#include <avs/capi.h>
#include <avs/types.h>) may be <> to be replaced by " in the header file? I gave up trying.
This has been brought up before. The idea was that the directory avs/ resides in should be added to the project path so it's treated as a system directory like the <> denotes. Of course, it's still a problem because it was generally accepted that the proper install path for the headers would be include/avisynth/ when being installed system-wide.

I've long been in favor of changing the references in avisynth[_c].h to the avs/ subdir from <> to "" - it's not like plugins are going to need to rely on stuff in avs/ without also pulling in avisynth[_c].h as well. Or you know, at all, since avisynth[_c].h should be the single point of contact between the AviSynth+ API and the plugin.

[MysteryX]

I've long been in favor of changing the references in avisynth[_c].h to the avs/ subdir from <> to ""
I'm not familiar with the background of this issue, but that's what I've been doing.

[MysteryX]

FrameRateConverter (https://forum.doom9.org/showthread.php?p=1805171#post1805171) plays weird in Avisynth+, even without MT. It plays a bunch of frames, pauses, then plays another bunch of frames, then pauses again, etc.

With MT, it stalls at low CPU usage, but first it would be good to debug the issue without MT.

[vcmohan]

[CODE]

Just pointing out a few things.

EDIT: What is effect of taking writeptr on non writable src frame ?
Thanks for pointing out. But those variables are used in my subsequent code which I deleted just for checking.
The main culprit is the Frame->GetWritePtr().
I forgot to change this to GetReadPtr after I deleted make writeable which I used earlier. Now it works OK. But wonder how it was working when I was just stepping frame by frame without crashing?
Also problem of compiling under debug and script I pointed out on 14th and 15th April is unresolved.

[pinterf]

Also problem of compiling under debug and script I pointed out on 14th and 15th April is unresolved.
This problem, right? https://forum.doom9.org/showthread.php?p=1803688#post1803688
Could not reproduce. With and without imagesource.
I'd need to have the same conditiones.
So you are on 2420 x64 MT
- Can it be reproduced w/o ImageSource on your machine (just a BlankClip with similar dimensions and format?)
- Processor architecture (though no AVX2 code is used here)
- Does it happen when encoding to e.g. x264 or when viewing from VirtualDub or AvsPMod?
- Clip is of a single image or multiple frames? (e.g. ImageSource(...).Loop(20))

[MysteryX]

new req Grunt, but that should be built-in to Avisynth, along with GScript (GScript is builtin in AVS+, already).

I said the same. GRunT should be built-in to Avisynth.

To put in the TODO list.

[pinterf]

I have mentioned it already, and most of it is done. Except setting current_frame into global variable. But until the basic ScriptClip suffers in MT, I won't put it up in git and release.

[MysteryX]

ScriptClip should be working now.

We just have to see whether "last" causes issues, not only with ScriptClip but with Eval and any other run-time expression evaluation.

Is there any other issue with global variables?

[mariush]

Not sure if something like this is already implemented or not in AviSynth+ but just saying it anyway.

Would there be any interest in adding "native" support for reading and writing PNG files? Seems like a good idea: they support up to 16 bit per channel, so it could store 8 bit, 10bit, 12bit .. all the way up to 16 bit and also supports grayscale. Yeah, it's only RGB but as far as I know, so is BMP and eBMP right?

If speed is a concern (for ImageWriter) you can simply default to compression = 0 or 1 (just copy or ultra fast zlib compression) and the only added cpu cost would be the calculation of a 32bit checksum.

It would be also possible to use a bunch of custom tags (the png format allows for that) like let's say xACy, xACb , xACr for example for planar formats and YCbCr or whatever Rec.2020 uses if it's different (too lazy to search now) .... and maybe store a default generic small image maybe with some text saying "this is a custom png file which stores the image information in custom chunks readable by Avisynth+ ) and the png format also allows and has text chunks where Avisynth+ could store some encoded data required to understand what it actually stored in the png file ( planar or interleaved, color space, full range/limited range etc)

Could be a good replacement for that non-standard ebmp

ps. Just checking the ImageWriter (avisynth.nl/index.php/ImageWriter) wiki page ... also noticed something... seems the function defaults to "c:" if the path is not specified. Windows would most likely block writing directly to C:\ by default (to protect itself and file system, perhaps it would be a good idea to use C:\AviSynth or %AviSynth_Install_Folder\Images instead

Don't know how anyone thought the root of a drive to be a good default setting.

[raffriff42]

RGBAdjust (http://avisynth.nl/index.php/RGBAdjust) - gain arguments autoscale (https://forum.doom9.org/showthread.php?p=1805251#post1805251), but bias does not. Levels - no arguments autoscale. Just noting it in passing.

[vcmohan]

This problem, right? https://forum.doom9.org/showthread.php?p=1803688#post1803688
Could not reproduce. With and without imagesource.
I'd need to have the same conditiones.
So you are on 2420 x64 MT
- Can it be reproduced w/o ImageSource on your machine (just a BlankClip with similar dimensions and format?)
- Processor architecture (though no AVX2 code is used here)
- Does it happen when encoding to e.g. x264 or when viewing from VirtualDub or AvsPMod?
- Clip is of a single image or multiple frames? (e.g. ImageSource(...).Loop(20))

I checked with following script
#imagesource("c:\images\source1_z.jpg",end = 500)
imagereader("c:\images\stamil.jpg",end = 100)
#imagesource("C:\avi_plugins\DeNoise\grainnoise.png", end = 30).converttoYv12()
#imagereader("C:\avi_plugins\varianslim\theoin.jpg", end = 1000)
#colorbars()
converttoYUY2()
stackhorizontal(last,last)
stackvertical(last,last)
reduceby2()
return(last)
I found that it works ok excepting for that particular imagereader (or if replaced by imagesource) uncommented line. Appears that particular jpg is creating the problem. When I step through I get some green screens. File information looks OK.
Still I can not understand what the problem is, for if I comment out reduceby2() it runs ok with the same input. The particular stamil.jpg image is 602 x 566. I use vdub to monitor output. My Samsung laptop runs with windows 10 home edition. Processor intel i7-4500U1.80Ghz 2.4Ghz, 8GB memory.

[pinterf]

The particular stamil.jpg image is 602 x 566.
Thanks, the size the key.
Replaced ImageSource with ColorBars
colorbars().Spline64Resize(610,566)

600 ok, 602 fail, 604 ok, 606 fail, 608 ok, 610 fail

EDIT: fixed (YUY2 HorizontalReduceBy2 did nothing if target width is not mod4)
The constructor of HorizontalReduceBy2 is checking YUY2 clip if the width of source is mod4 (valid YUY2 target width should be mod2). Then it sets output vi.width, divides by 2.
In GetFrame, it checks width again mod4, but the width here is already divided by 2.
It was doing the reduce operation only if width is mod4, which is wrong, here the width is mod2 already (The whole checking is not needed, because it was pre-checked in constructor). Or else it did nothing, frame is undefined content.

[pinterf]

RGBAdjust (http://avisynth.nl/index.php/RGBAdjust) - gain arguments autoscale (https://forum.doom9.org/showthread.php?p=1805251#post1805251), but bias does not. Levels - no arguments autoscale. Just noting it in passing.
Thanks, this is inconsistent, and we can call it bug, that was at the very beginning of the project. For a brand new project I'd choose nothing to scale, but keeping scripts easy to maintain is another aspect. Still I'd like to have an option for expert users providing parameters as-is, by something like "paramscale" in masktools.

[raffriff42]

After thinking about it, I have no preference for or against autoscaling. One the one hand, it is convenient now, while adapting one's thinking in terms of 0-255 to deep color. On the other hand, it sets the current way of thinking into stone, forever.

In a few years people may instead think in terms of normalized (0-1) range, as strange as that may seem to us now. Maybe they will prefer 0-1023, 0-65535, or something else.

Scaling a non-autoscaled argument is easily done by the user. Re-scaling an 0-255 autoscaled argument to a different source range is also easily done. So I don't care which it is.

Here's an example of Levels (not currently autoscaling) with user-side scaling; changes in blue:##################################
### scale 0-255 Levels arguments to clip 'C' bit depth (AVS+)
function ScaledLevels(clip C,
\ int input_low, float gamma, int input_high,
\ int output_low, int output_high,
\ bool "coring", bool "dither")
{
return C.Levels(
\ C.sb8x(input_low),
\ gamma,
\ C.sb8x(input_high),
\ C.sb8x(output_low),
\ C.sb8x(output_high),
\ coring, dither)
}
You see how easy it is. Supporting code is below. (suggested filename 'argscale.avsi')
### manual scaling of arguments from one bit depth to another
## version 28-Apr-2017, raffriff42

#######################################
### scale a value from one bit depth to another
##
## @ bits_in - the bit depth being converted from
## @ bits_out - the bit depth being converted to
## @ cx - clamp output (cf. sbx below)
## @ returns float if not clamped;
## else returns int for int formats, float for float
##
function sbf(int bits_in, int bits_out, float f, bool "cx")
{
clamp = Default(cx, false)
fsi = getFullscale(bits_in)
fso = getFullscale(bits_out)
fsi1 = Float( (bits_in==32) ? 256.0/255.0 : fsi+1 )
fso1 = Float( (bits_out==32) ? 256.0/255.0 : fso+1 )

fr = (bits_in==bits_out) ? f : f * fso1 / fsi1 ## unclamped result

fr = (clamp==false) ? fr : Min(Max(0.0, fr), fso)
fr = (clamp==false) ? fr : (bits_out==32) ? fr : Round(fr)
return fr
}


#######################################
### scale a value from one bit depth to another; clamp output
##
## @ bits_in - the bit depth being converted from
## @ bits_out - the bit depth being converted to
## @ returns int for int formats, float for float
##
function sbx(int bits_in, int bits_out, float f)
{
return sbf(bits_in, bits_out, f, true)
}
#######################################
### scale an 8-bit value for target clip 'T'; clamp output
##
## @ T - clip with target bit depth
## @ returns int for int formats, float for float
##
function sb8x(clip T, float f)
{
return sbf(8, T.BitsPerComponent, f, true)
}
#######################################
### scale a 'normalized' (0 to 1) value for target clip 'T'; clamp output
##
## @ T - clip with target bit depth
## @ returns int for int formats, float for float
##
function sbnx(clip T, float f)
{
return sbf(32, T.BitsPerComponent, f, true)
}


#######################################
### scale a value from one bit depth to another; string result
##
## @ bits_in - the bit depth being converted from
## @ bits_out - the bit depth being converted to
## @ returns String, unclamped
##
function sbs(int bits_in, int bits_out, float f, int "decimals")
{
decimals = Min(Max(0, Default(decimals, 4)), 8)
return String(sbf(bits_in, bits_out, f), "%0."+String(decimals)+"f")
}
#######################################
### scale an 8-bit value for target clip 'T'; string result
## @ T - clip with target bit depth (assume bits_in = 8)
## @ returns String, unclamped
##
function sb8s(clip T, float f, int "decimals")
{
return sbs(8, T.BitsPerComponent, f, decimals)
}
#######################################
### scale a 'normalized' (0 to 1) value for target clip 'T'; string result
## @ T - clip with target bit depth (assume bits_in = 8)
## @ returns String, unclamped
##
function sbns(clip T, float f, int "decimals")
{
return sbs(32, T.BitsPerComponent, f, decimals)
}

#######################################
### return integer fullscale value for given bit depth (mostly for internal use)
function getFullscale(int bits)
{
return (bits==8) ? 255
\ : (bits==10) ? 1023
\ : (bits==12) ? 4095
\ : (bits==14) ? 16383
\ : (bits==16) ? 65535
\ : (bits==32) ? 1
\ : Assert(false,
\ "getFullscale: 'bits' not one of (8|10|12|14|16|32)")
}

## end

[nhope]

Apologies for this but where's the user-friendly document that explains the AviSynth+ MT stuff like SetFilterMTMode() and Prefetch(), and the changes required in scripts? Can't find it anywhere. Google doesn't know. I seem to remember it was on a wiki.

[LigH]

AviSynth Wiki (http://avisynth.nl/index.php/Main_Page)
Multi-Threading (http://avisynth.nl/index.php/MT) (old MT() and v2.x-MT SetMTMode())
AviSynth+ (http://avisynth.nl/index.php/AviSynth%2B) — MT Notes (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes) (SetFilterMTMode() and Prefetch())

[raffriff42]

where's the user-friendly document that explains the AviSynth+ MT stuff like SetFilterMTMode() and Prefetch()Some of it was 'hidden' on the AVS+ developers' page (http://avisynth.nl/index.php/Avisynthplus/Developers) in the wiki; I've moved it to the AVS+ main page (http://avisynth.nl/index.php/AviSynth%2B) as a stopgap until the MT docs can be expanded.

[nhope]

Thank you both. It was http://avisynth.nl/index.php/AviSynth%2B#MT_Notes that I was looking for.

[MysteryX]

I was thinking about the issue with "last" and global vars.

"last" isn't used within script functions so script libraries won't be affected by any issue here. If there are problems, it's going to happen at the main script level. If it works within script functions (without implicit "last"), then it's a huge improvement already. Once that is working, we can give it some more thoughts about how to handle variables like "last", as well as produce bogus scripts for testing. I think we're better to leave that one for later. If we're going to change it, we'll have to do it right, and for now we have no right solution.

Still, that doesn't prevent conditional functions from being supported.

[raffriff42]

"last" isn't used within script functions so script libraries won't be affected by any issue here.What what what!!!

[MysteryX]

What what what!!!

Fct1() # uses implicit last -- possible issue with dynamic evaluation of expressions like Eval which reset "last"
Fct2()

function Fct1(clip c) {
c = c.Fct2() # here we need to define the clip explicitely
return Fct3(c)
}

[raffriff42]

I once told a guy -- can't find the link right now -- about the easy way to create a function from a bunch of script lines. Something like:function foo(clip C)
{
C ## Last==C
Filter1
Filter2
Filter3
return Last
}...and some of my user functions look just like that example. All I'm saying is, don't even think about breaking my preciousss Last.

EDIT - I always use explicit Last with BlankClip and ScriptClip; maybe Eval should get special treatment (from the user) also.

[LigH]

Or so:

function Fct1(clip c) {
c # means explicitly: last = c
Fct2()
return Fct3()
}

Of course, the scope in the function does not use the last clip from the main level inside. It creates an own last variable.

Fortunately, last is not "super-global". At least I hope so.

[MysteryX]

Right -- sorry my mistake.

We're not changing anything to "last". We're just worried it might have some of the same issues as "current_frame" with MT -- although we're not clear on how such problem manifests. We haven't seen any issue so far.

[StainlessS]

function Fct1(clip c) {
c # means explicitly: last = c
Fct2()
x=sin(.5)
sin(.5) # EDIT: added
return Last # return result of Fct2() # Assuming it was a clip
}


Last (so far as I understand it) stores the previous (clip only) return variable that was not assigned to anything else.

[LigH]

That's an interesting question. I really wonder if "return" returns a clip or a number. In my current mental state, I would bet on ... number. I should try it.

[pinterf]

That deadlock thing is hard to catch. I was working on the problem during December, now I have returned to it.

In my test code the variables last and current_frame were passed to the invoke with guards of mutex. That specific TLS (Thread Local Storage) Invoke - I had linked earlier which was doing context switch and made "current_frame" and "last" out of scope - was modified a bit to re-set those variables in the scope of the core. But this was only the first small step which only allowed the script not to fail in YDifferenceFromPrevious's constructor (which so far was complaining "current_frame" does not exists)

ScriptClip MT test script, which I'm using to ensure that last is always right.

Frames should follow each other displaying 16-32-48-96-16-32-48-96 sequence if frame order is OK.

There is a second ScriptClip line, because it makes our life shorter and increases the stress level a bit. We have another parallel work in runtime evaluation.

Case #1 happyness
When the second ScriptClip line is independent from the first ScriptClip(commented out c1=, c2= lines in code below), then there is no problem, I'm doing Prefetch(300) and nothing fails.

Case#2 deadlock
But when the second ScriptClip is using the output of the first ScriptClip, sometimes deadlock occurs.

Depending on the clip size, additional filters at the end, they all modify internal timings, order of cache hits, this "sometimes" can be never or 10 or 100 frames. I have experimented with a few hundred variants. Deadlock can be eliminated when ScriptClip is defined as "DONT_CACHE_ME", but this is no-go of course.

Sometimes Prefetch(80) is OK, but Prefetch(90) deadlocks. In other timing conditions the limit is Prefetch(8), etc.

len=1
w=64
h=48
c1=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$008080)
c2=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$108080) # diff 16
c3=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$308080) # diff 32
c4=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$608080) # diff 48 -> diff (-)96
c=c1+c2+c3+c4
c.Loop(100)
# this will deadlock sooner or later or never, more Prefetch makes deadlock to appear, even more -> deadlock sooner
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
/* This works for any Prefetch, no dependancy between them
c1=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
c2=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
Stackvertical(c1,c2)
*/
ConvertToRGB32() #additional filters modify timing thus, frame evaluation order/cache hit order in MT
ConvertToRGB24()
ConvertToRGB32()
ConvertToRGB24()
Prefetch(60)

[MysteryX]

I tried doing a bit of multi-threading in C++ until I realized how much of a pain it was. I was reading many articles saying how MT was only for experts, and I then understood why.

My recommendation: write the thread management in .NET (no "undefined" state!!) :) but that's not really an option -- if rewriting was an option, it's VapourSynth all the way

so... Good luck :D

[StainlessS]

That's an interesting question. I really wonder if "return" returns a clip or a number. In my current mental state, I would bet on ... number. I should try it.

function Fct2(clip c) {return c.info}

function Fct1(clip c) {
c # means explicitly: last = c
Fct2()
z=c.Invert
x=sin(.5)
sin(.5)
return Last # return result of Fct2(), Colorbars with Info
}

Colorbars.killaudio

Fct1()


EDIT: Also, I would disagree with first comment, # means implicitly: last = c

[TheFluff]

That's an interesting question. I really wonder if "return" returns a clip or a number. In my current mental state, I would bet on ... number. I should try it.
Last only works on clips (more specifically, every expression that isn't an explicit assignment and happens to evaluate to a clip assigns to last). It's a pretty unintuitive mechanism and I'd consider it a pretty awful hack in most languages but it is kinda excusable in a toy DSL like Avisynth script. Perl has something similar with $_, but at least it's more consistent about it and happily admits it's not really intended to write readable programs.

See here (https://forum.doom9.org/showthread.php?p=1651728#post1651728) and the surrounding posts for an extensive earlier discussion on attempting to make it less weird. The tl;dr is that Avisynth script kinda needs an assignment operator that is actually a real operator rather than a special type of expression, but good luck with that.

[LigH]

3) implicit assignments to last (all expressions that aren't one of the two first types and evaluate to a clip)

I see. So the statement "return last" is not ambiguous here. Rather the single "sin(.5)" without assignment is misleading.

Perl has something similar with $_

Pascal has the reserved variable "Result" to explicitly assign a return value in the scope of a function.

[StainlessS]

Whoa, that surprised me when removing the 'Return Last' from Fct1(),
The script's return value was not a video clip, (Is a float, 0.479426).

EDIT: Nice post Fluffy.

[TheFluff]

Pascal has the reserved variable "Result" to explicitly assign a return value in the scope of a function.

That's not the same thing at all. Pascal doesn't have a C-like "return <expression>" mechanism, so instead you assign to a special variable (either "result" or a variable with the same name as the function) to set the return value from a function.

$_ in Perl and last in Avisynth are special in that they act as a default parameter to many functions if no other suitable value is given. For example, in Perl saying "print;" is the same as saying "print($_);" much like how in Avisynth "blur()" is the same as "blur(last)". Since Perl is an imperative language, it doesn't need the implicit assignment part of the equation, though - function calls can just have side effects and mutate $_ with no problems (you still get implicit assignment to $_ when using it as an implicit iterator in loops though, but that's beside the point).

Avisynth script, however, is a quite poor excuse for a functional language that wants to pretend it is imperative, or perhaps more accurately, it's a schizophrenian language that has one data type that is purely functional and lazily evaluated, paired with a bunch of imperative scripting functionality that very much isn't. What you're writing in Avisynth script is a composition of functions (https://en.wikipedia.org/wiki/Function_composition_(computer_science)) (in other words, the filter chain), so from the script's point of view, clip variables are effectively immutable. Hence you get the hack that is the implicit assignment to last based on what the expression evaluates to - the clip data type is effectively living in a different programming language than everything else in Avisynth script and has its own semantics.

Arguably, the entire "assignment" part of clip variables is confusing, since you're not really assigning a value to a variable at all.

[MysteryX]

That deadlock thing is hard to catch. I was working on the problem during December, now I have returned to it.
I applied the latest ConditionalFilter code changes to the MT-pfmod branch, and this works.

Here's the x86 library of MT-pfmod with conditional filters (https://mega.nz/#!yVBk0BzJ!jHiGfGiFAzho2HQX-0kYR4w-UIFX8TXYoZFQ49ums_Q), if anyone wants to play with it (no 16-bit stuff in this version).


len=1
w=64
h=48
c1=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$008080)
c2=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$108080) # diff 16
c3=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$308080) # diff 32
c4=BlankClip(width=w,height=h,length=len,pixel_type="YV24",color_yuv=$608080) # diff 48 -> diff (-)96
c=c1+c2+c3+c4
c.Loop(10000)
# this will deadlock sooner or later or never, more Prefetch makes deadlock to appear, even more -> deadlock sooner
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
/* This works for any Prefetch, no dependancy between them
c1=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()))")
c2=ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious()),X=0,Y=30)")
Stackvertical(c1,c2)
*/
ConvertToRGB32() #additional filters modify timing thus, frame evaluation order/cache hit order in MT
ConvertToRGB24()
ConvertToRGB32()
ConvertToRGB24()
Prefetch(100)


No deadlock or anything, but CPU isn't being well utilized either. No problem found with frame order.

FPS (min | max | average): 87.34 | 14329 | 1564
Memory usage (phys | virt): 32 | 28 MiB
Thread count: 112
CPU usage (average): 17%

Strangely, if I run FrameRateConverter(debug=true) with this version, the texts are displayed correctly for the first frame then only gibberish is displayed for additional frames.

In contrast, the latest release of Avisynth causes occasional crashes even without MT.

[gaak]

Hi,

Cannot get this script to run to completion w/ i386 r2455:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
Import("\MKVideo Encoder NV\AVS Scripts MT\LoadPlugins.avs")
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
Spline64Resize(1280, 720)
RoboCrop(Laced=False, Align=True)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)", strength=200, smode=5, secure=true)
Prefetch(6)

Have tried Prefetch values from 3 to 7. As the value is increased the script completion percentage goes up but never past 85% when it crashes. Any other settings I can try?

Thanks.

[Gavino]

Whoa, that surprised me when removing the 'Return Last' from Fct1(),
The script's return value was not a video clip, (Is a float, 0.479426).

No surprise, really:
http://avisynth.nl/index.php/Grammar

if return is not present in the final executable statement of a script (or script block), it is implied – the statement is treated as if return was present.

So if the last statement of a function is "sin(.5)", that's what will be returned.

[StainlessS]

Clever Cloggs :)

[Gavino]

Also note:
The full AviSynth grammar - Closing_Remarks (http://avisynth.nl/index.php/The_full_AviSynth_grammar#Closing_Remarks)

If there is no (explicit or implicit) return, a void value (ie a value of the 'undefined' type) is returned. For example, this will happen if the last statement is an assignment.

[StainlessS]

Thank you master (slap, slap).

[tebasuna51]

SetFilterMTMode("DGDecodeNV", 3)
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
...

As the value is increased the script completion percentage goes up but never past 85% when it crashes.

Maybe?
SetFilterMTMode("DGSource", 3)

[Reel.Deel]

Maybe?
SetFilterMTMode("DGSource", 3)

I don't think that's the problem, even thought SetFilterMTMode("DGDecodeNV", 3) is incorrect, as you've already pointed out. AviSynth+ automatically recognizes source filters. If it sees a source filter which has no MT-mode specified, it will automatically use mode 3 instead of the default MT mode. This has been the behavior since r2069.

Hi,

Cannot get this script to run to completion w/ i386 r2455:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
Import("\MKVideo Encoder NV\AVS Scripts MT\LoadPlugins.avs")
LoadPlugin("\MKVideo Encoder NV\DGDec\DGDecodeNV.dll")
DGSource("\MKVideo Files\Input_Video_File.dgi")
Spline64Resize(1280, 720)
RoboCrop(Laced=False, Align=True)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)", strength=200, smode=5, secure=true)
Prefetch(6)

Have tried Prefetch values from 3 to 7. As the value is increased the script completion percentage goes up but never past 85% when it crashes. Any other settings I can try?

Thanks.

Try running the script in AVSMeter with SetLogParams("stdout", 4) at the very beginning of your script. The logging facility in AVS+ will automatically log errors, and will issue warnings and notes about potential problems, buggy plugins, suboptimal settings, etc. If that does not show anything useful then try testing RoboCrop and DegrainMedian separately to see if they crash or not. Also make sure you're using the latest MaskTools2 and RgTools.

[gaak]

SetLogParams("stdout", 4)[/FONT] at the very beginning of your script. The logging facility in AVS+ will automatically log errors, and will issue warnings and notes about potential problems, buggy plugins, suboptimal settings, etc. If that does not show anything useful then try testing RoboCrop and DegrainMedian separately to see if they crash or not. Also make sure you're using the latest MaskTools2 and RgTools.

Thanks for the tip. I did what you advised and got this:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\SysWOW64\KERNELBASE.dll
Address: 0x75EAB782

I guess that falls under the "not show anything useful" heading. I'll try running the other filters separately to narrow the field.

[Groucho2004]

Thanks for the tip. I did what you advised and got this:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\SysWOW64\KERNELBASE.dll
Address: 0x75EAB782

I guess that falls under the "not show anything useful" heading. I'll try running the other filters separately to narrow the field.It may be useful to see which filter versions you're using. Run AVSMeter with the switches "-avsinfo -log". This will generate a log file (avsinfo.log). Post the content of that log file.

[gaak]

It may be useful to see which filter versions you're using. Run AVSMeter with the switches "-avsinfo -log". This will generate a log file (avsinfo.log). Post the content of that log file.

Found the problem. It was an old plugin (SplineResize.dll). Run with it, crash. With out it, no crash. Found a replacement: ResizersPack4.5.avsi. Slower but better quality and it works. Thanks to Reel.Deel and Groucho2004 for your guidance and software.

[LigH]

If the resamplers in the AviSynth kernel are not versatile enough for you, you might also be interested in ResampleHQ (http://svn.int64.org/viewvc/int64/resamplehq/doc/index.html). The features in the Resizers Functions Pack 4.5 (https://forum.videohelp.com/threads/369143-ResizersPack-MasksPack-PlaygroundPack-SmoothContrast-Logo-mod-functions#post2364034) by Dogway are rather special, though, and I would not be sure which of them are portable to new color spaces/configurations of AviSynth 2.6 and AviSynth+ without quirks, may require general updates...

[gaak]

If the resamplers in the AviSynth kernel are not versatile enough for you, you might also be interested in ResampleHQ (http://svn.int64.org/viewvc/int64/resamplehq/doc/index.html).

Thank you for the suggestion. Will give it a try. Right now looking into nnedi3_resize16.avsi. Seems to give good results up sizing, now seeing how well it does down sizing.

[LigH]

Probably not remarkably great. You should learn how the parts of each algorithm work, to understand which purpose they serve. "EDI" (Edge Directed Interpolation) functions are especially made to aid upsampling. I see no reason to believe that downsampling would be improved by it, the way it works.

And it is not even specifically related to AviSynth+. Another thread derailing... it's getting common in the last time. Well, this time I am involved... :o

[Groucho2004]

NNEDI / EEDI can't downscale. What they do is double the image height. So, this code will double both image width and height:
nnedi3(dh = true).turnleft().nnedi3(dh = true).turnright()

For downscaling, nnedi3_resize16 uses Dither_resize16, nnedi3 isn't involved at all.

[LigH]

Imagine I want to avoid autoloading for some plugins, prefer explicit loading for specific reasons; and I have such plugins in both 32-bit and 64-bit flavour.

Does AviSynth+ provide a core {function|constant} to check whether my script runs in a 32 or 64 bit environment, to calculate a base plugin directory accordingly? Something like:

MyPluginBase = "D:\AviSynthPlugins\special\" + (Is64bit() ? "x64" : "x86")

[Groucho2004]

Imagine I want to avoid autoloading for some plugins, prefer explicit loading for specific reasons; and I have such plugins in both 32-bit and 64-bit flavour.

Does AviSynth+ provide a core {function|constant} to check whether my script runs in a 32 or 64 bit environment, to calculate a base plugin directory accordingly? Something like:

MyPluginBase = "D:\AviSynthPlugins\special\" + (Is64bit() ? "x64" : "x86")I don't think Avisynth+ has an option to report its bitness. However, this could very easily be added as a function or constant:

if (sizeof(void*) == 8)
//64 bit module on Win64



With a bit more code this could be extended to report a WoW64 process (32 bit process on 64 bit Windows) and consequently a plain 32 bit process (error handling mostly omitted in the example):
#define PROCESS_32_ON_32 0
#define PROCESS_32_ON_64 1
#define PROCESS_64_ON_64 2

...

int ProcessType()
{
if (sizeof(void*) == 8)
return PROCESS_64_ON_64; //64 on 64

BOOL bWoW64Process = FALSE;
typedef BOOL (WINAPI *LPFN_ISWOW64PROCESS) (HANDLE, PBOOL);
LPFN_ISWOW64PROCESS fnIsWow64Process;
HMODULE hKernel32 = GetModuleHandle("kernel32.dll");
if (hKernel32 == NULL)
return -1;

fnIsWow64Process = (LPFN_ISWOW64PROCESS)GetProcAddress(hKernel32, "IsWow64Process");
if (fnIsWow64Process != NULL)
fnIsWow64Process(GetCurrentProcess(), &bWoW64Process);
else
return -1;

if (bWoW64Process)
return PROCESS_32_ON_64; //WoW64

return PROCESS_32_ON_32;
}

[mkver]

I seem to have hit a bug in Overlay, namely the "lighten"-mode:

Maske=BlankClip(1,156,42,pixel_type="YV24",fps=25,color=$000000,channels=0)
Mard=BlankClip(1,56,42,pixel_type="YV24",fps=25,color=$000000,channels=0)
Mard2= Maske.Overlay(Mard,mode="Lighten")
Return Mard2

I expect to get a 156x42 YV24 clip with Y constantly being 16 and U and V 128; instead there is a 56x25 rectangle with top left corner (0,17) in which Y=128 and the chroma values are random garbage (changes every time I open the script, so maybe it is using memory that it shouldn't use).
Info() reported the following CPU instruction sets: SSE4.2, SSE3, AVX, AVX2, FMA3, F16C.
[Edit]: I am using 64bit r2455. It works with standard Avisynth 2.6.

[raffriff42]

re: mkver's issue: if either clip is at least 620px wide (more or less), the problem goes away.

[pinterf]

Thanks for the report. Lighten had this problem since r2290, as a victim of hbd transition. Fixed on git. The problem occured when base and overlay clip had different widths (pitches)

[pinterf]

RGBAdjust (http://avisynth.nl/index.php/RGBAdjust) - gain arguments autoscale (https://forum.doom9.org/showthread.php?p=1805251#post1805251), but bias does not. Levels - no arguments autoscale. Just noting it in passing.
RgbAdjust gain is not related to high-bit-depth scaling. It is simple multiplier, so no action or fix needed here on avs+ side (Slowly I'm processing recent posts)

[pinterf]

I'm still not able to solve the stability of the multithread-ScriptClip-with-nested-ConditionalFunctions problem (deadlock).

But there had been a couple of fixes and small additions since r2455, what's your opinion about a maintenance release soon?

- Fix: Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
- Fix: YUY2 HorizontalReduceBy2 did nothing if target width was not mod4
- ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
- ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
(note: greyscale through devIL can be corrupt with some formats, use png)
- ImageWriter: flip greyscale images vertically (except "raw" format)
- SubTitle: new parameter "font_filename" allows using non-installed fonts
- (project can be compiled using gcc)
- Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
- Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
(not the script text!)
- SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
- New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(),
they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively

What other (small) issues or feature requests do you know?

[LigH]

Implement a core function / variable reporting whether the current process uses 32 or 64 bit code (maybe even WoW64)... not urgent, only if you get immediately a good idea how to realize it sensibly.

[mkver]

And I ran into another issue with weird chroma: The blur filter doesn't seem to like input that is 32 pixel wide:

Return BlankClip(1,32,62,pixel_type="YV12",fps=25,color=$000000,channels=0).Blur(1.4)

As before: Info() reported the following CPU instruction sets: SSE4.2, SSE3, AVX, AVX2, FMA3, F16C; 64bit r2455.

[LigH]

Are you sure the reason is not the height of 62 pixels, which is not a multiple of 4, so the chroma planes in YV12 would have an odd height?

[MysteryX]

Normalizing AverageLuma and other such functions between various bit depths.

[mkver]

Are you sure the reason is not the height of 62 pixels, which is not a multiple of 4, so the chroma planes in YV12 would have an odd height?
I checked different sizes and this happens e.g. on 32x32 or 32x40, too. But I couldn't reproduce it if the width is different than 32.
I have also not checked other pixel formats than YV12 (8 bit).

[pinterf]

And I ran into another issue with weird chroma: The blur filter doesn't seem to like input that is 32 pixel wide:

Return BlankClip(1,32,62,pixel_type="YV12",fps=25,color=$000000,channels=0).Blur(1.4)


Thanks, I see the same issue with YV24, width=16. Will look at it.
EDIT: edge case. fixed on github

[tuanden0]

I got pink screen when I use prefetch for dfttest x64 (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins), can someone help me?
Here's my error: http://i.imgur.com/nGHLi5j.png
Here's dfttestMC: https://forum.doom9.org/showthread.php?p=1725400#post1725400
Here's my script:
LWLibavVideoSource("E:\Download\banding anime test script.mkv") #LoadSource
AssumeFPS(24000, 1001)
Trim(24478,28000)
RemoveGrain() #get rid of light banding
dfttestMC(sigma=2, lsb=true)
SmoothGrad()
DitherPost ()
flash3kyuu_deband(dither_algo=2)
Toon() #Line darken
Prefetch(4)

[DJATOM]

Setfiltermtmode("dfttest", 2)

[tuanden0]

Setfiltermtmode("dfttest", 2)

Still pink screen :(
I tried setfiltermtmode 1 2 3 and 4 but the problem still there :(

[DJATOM]

Try dfttest(sigma=2, lsb=true) with MT mode 2 and check if it fails. It might be dfttestMC problem.

[tuanden0]

Try dfttest(sigma=2, lsb=true) with MT mode 2 and check if it fails. It might be dfttestMC problem.

I tried what you said and the dfttest x64 has problem, i tested dfttestMC and using dfttest x86 + prefetch and It's OK :(

[MysteryX]

More bugs in VirtualDubFilter
https://forum.doom9.org/showthread.php?p=1807621#post1807621

[pinterf]

Thanks, registered. I will dig into the problem later, I wish I had 48 hours in a day.

[Groucho2004]

I tried what you said and the dfttest x64 has problemJust curious, could you try with this 64 bit version (https://www.dropbox.com/s/hm7t5yqvyzu9kk6/dfttest194_64.7z?dl=0) of dfttest? If that fails too, try setting "threads" to "1" in the dtftest parameters.

[manolito]

@Groucho

So you are not occasionally cantankerous any longer? How did you achieve that? I've been trying to overcome this character flaw a couple of times, but never succeeded... :devil:

[Groucho2004]

@Groucho

So you are not occasionally cantankerous any longer?Of course I am. I just felt like changing the wallpaper.

[tuanden0]

Just curious, could you try with this 64 bit version (https://www.dropbox.com/s/hm7t5yqvyzu9kk6/dfttest194_64.7z?dl=0) of dfttest? If that fails too, try setting "threads" to "1" in the dtftest parameters.

It'w not work :(
Frames still pink and sometime there're blue frames or red frames ?_?
Maybe I try to find another way, thank you Groucho2004

Fixed *yay*
I tried to set dfttest with force=true and it's work :)
SetFilterMTMode("dfttest", 2, force=true)

[pinterf]

r2069 (http://avs-plus.net/builds) is out, and this build should be fun :) I encourage you all to take a look at it, as it brings some serious enhancements to MT, and then some. Let's see...
[...]
- The behavior of MT_SERIALIZED (mode 3) changed. While the earlier implementation caused all filters that are called from the serialized filter to be also serialized, now it only serializes the one and only filter that it is specified for. This has a couple of important consequences:
-- If you have a mode 3 filter towards the end of your script, the speed penalty is much-much less, since earlier basically your whole script went into mode 3, whereas now other filters can still execute in parallel. The placement of mode 3 filters in your script just got un-critical!
-- This also means it is now a really bad idea to have a big lock/mutex inside your GetFrame() instead of marking it as mode 3, because your plugin will exhibit the old behavior and you won't be able to benefit from the potential improvements at all.
-- There is also a downside: The new mode 3 theoretically does not provide the same amount of MT-protection as the old one. However, I'm not sure it matters to many plugins at all. If it does, the old mode will be re-introduced as mode 4. So keep me up-to-date!
[...]
Edit: Despite my obvious enthusiasm, this build is still a test build. Please treat it as such.
I encountered this downside.
In MT mode MT_SERIALIZED filters are really getting parallel request for the same instance, that means that their GetFrame is called in a reentrant way, just if they were MT_NICE_FILTER.

That means that the internal working buffers allocated in filter's constructor are used parallel, which is not good at all.

When you encounter strange behaviour for a filter that specify itself as MT_SERIALIZABLE (such as my FFT3DFilter version does), then try a forced mode selection for it.
SetFilterMTMode("FFT3DFilter",MT_MULTI_INSTANCE,force=true)

Or if no autoregistering happens, just specify MT_MULTI_INSTANCE and look if it makes your process any better.

[MysteryX]

Perhaps this could explain KNLMeans' image corruption with MT_SERIALIZE

[bxyhxyh]

I think many people asked partial multi-threading and partial single-threading.
So Can Avisynth+ can do them without problems?

Sometimes most part of my script don't need multithreading.
But xsharpen slows it so much when I use it with 5x super sampling.
or sometimes TDecimate crashes saying "major internal error, report this to tritical" when I try multi-thread all functions.

[pinterf]

New release, smaller bug fixes, interesting additions.

Download Avisynth+ r2287-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2487-MT)

2487 (20170528), changes since v2455
-------------------------------------
# Fixes
Blur width=16 (YV12 width=32)
Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
YUY2 HorizontalReduceBy2 did nothing if target width was not mod4

# optimizations
Blur, Sharpen 10-16 bits planar and RGB64: SSE2/SSE4 (2x-4x speed)

# other modification, additions
- New script function: int GetProcessInfo([int type = 0])
Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
With type=1 the function can return a bit more detailed info:
-1: error, can't establish
0: 32 bit DLL on 32 bit OS
1: 32 bit DLL on 64 bit OS (WoW64 process)
2: 64 bit DLL
- ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
- ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
(note: greyscale through devIL can be corrupt with some formats, use png)
- ImageWriter: flip greyscale images vertically (except "raw" format)
- SubTitle: new parameter "font_filename" allows using non-installed fonts
- Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
- Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
(not the script text!)
- SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
- New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(),
they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively


And now I have to dig into those nasty MT things.

[raffriff42]

I'm having a lot of problems with this version on both vdub 1.10 and vdubFM, even with the simplest script, namely, "Version()" AVI: Opening file "E:\Data\Downloads\_test.avs"

[i] AVI: Avisynth detected. Extended error handling enabled.

Beginning dub operation.

[i] Dub: Input (decompression) format is: RGB888.

[i] Dub: Output (compression) format is: RGB888.

Ending operation.

[E] Error: Avisynth read error:
Avisynth: script open failed!

I loaded the Version script and selected File, Run video analysis pass to check framerate. I suspected a problem because another movie I had opened with both FFMpegSource and LibAVSource played verrry slowly and then crashed.[E] Error: Avisynth read error:
Could not allocate video frame. Out of memory. memory_max = 536870912,
memory_used = 3686451 Request=3686431
(E:\Data\Downloads\_misc.avs, line 1023)

[MysteryX]

And now I have to dig into those nasty MT things.
The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?

[pinterf]

I'm having a lot of problems with this version on both vdub 1.10 and vdubFM, even with the simplest script, namely, "Version()" AVI: Opening file "E:\Data\Downloads\_test.avs"

[i] AVI: Avisynth detected. Extended error handling enabled.

Beginning dub operation.

[i] Dub: Input (decompression) format is: RGB888.

[i] Dub: Output (compression) format is: RGB888.

Ending operation.

[E] Error: Avisynth read error:
Avisynth: script open failed!

I loaded the Version script and selected File, Run video analysis pass to check framerate. I suspected a problem because another movie I had opened with both FFMpegSource and LibAVSource played verrry slowly and then crashed.[E] Error: Avisynth read error:
Could not allocate video frame. Out of memory. memory_max = 536870912,
memory_used = 3686451 Request=3686431
(E:\Data\Downloads\_misc.avs, line 1023)

I can see that memory consumption is growing frame by frame when serving vdub. Something leaks in outputting through VfW... Checking.

[yup]

Hi pinterf!
:thanks: for new release.
I am waiting Y16 support in Imagereader.
I am updating Avisynth, plugins64+ and Devil.dll.
Script simple
ImageSource("film7 1.png", start=1, end=1, use_DevIL=true, pixel_type ="Y16")
When open in VirtualDub (shekh mod) I see colour image. I am testing tif and png files.
Please advice.
When I added string ConverttoRGB64() I see grayscale image.
yup.

[pinterf]

Memory leak found, I'll release the fix soon.
@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64

[pinterf]

Hotfix is out, thanks for the patience.

Avisynth Plus r2489-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT)

20170529 r2489
- fix: memory leak in CAVIStreamSynth (e.g. feeding vdub)
- fix: ConvertToY for RGB64 and RGB48

20170528 r2487
- Blur, Sharpen 10-16 bits planar and RGB64: SSE2/SSE4 (2x-4x speed)
- New script function: int GetProcessInfo([int type = 0])
Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
With type=1 the function can return a bit more detailed info:
-1: error, can't establish
0: 32 bit DLL on 32 bit OS
1: 32 bit DLL on 64 bit OS (WoW64 process)
2: 64 bit DLL
- Fix: Blur width=16 (YV12 width=32)
- Fix: Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
- Fix: YUY2 HorizontalReduceBy2 did nothing if target width was not mod4
- ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
- ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
(note: greyscale through devIL can be corrupt with some formats, use png)
- ImageWriter: flip greyscale images vertically (except "raw" format)
- SubTitle: new parameter "font_filename" allows using non-installed fonts
- (project can be compiled using gcc)
- Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
- Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
(not the script text!)
- SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
- New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(),
they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively

[pinterf]

The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?
Probably the only reason that this is a project done in our free time.

[Groucho2004]

@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:
BOOL Is64BitDLL(std::string sDLL, BOOL &bIs64BitDLL)
{
bIs64BitDLL = FALSE;
LOADED_IMAGE li;

if (!MapAndLoad((LPSTR)sDLL.c_str(), NULL, &li, TRUE, TRUE))
{
//error handling (check GetLastError())
return FALSE;
}

if (li.FileHeader->FileHeader.Machine != IMAGE_FILE_MACHINE_I386) //64 bit image
bIs64BitDLL = TRUE;

UnMapAndLoad(&li);

return TRUE;
}

[pinterf]

@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:

LoadPlugin function is already throwing an exception.
Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?

[LigH]

I believe the idea here is not just "throwing any exception", but "throwing a specific 'wrong bitness' exception which can be handled according to its type". Maybe.

[yup]

@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64
Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.

[Groucho2004]

LoadPlugin function is already throwing an exception.
If I use an implicit "LoadPlugin" in the script it does indeed throw "%1 is not a valid Win32 application".
If I put the 64 bit plugin in the auto-load directory and call one of its functions in the script it throws "there is no function named...".

I have not looked at the plugin manager code but I thought the auto-load enumeration at the start would call "LoadPlugin" on each plugin which does not appear to be the case.

Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.

Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.

[pinterf]

Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.


This is the source or error message:
// Load the dll into memory
plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
if (plugin.Library == NULL)
{
if (throwOnError)
{
DWORD errCode = GetLastError();
Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
}
else
return false;
}



If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.
Only the function name is known, but we don't know, which DLL should be loaded. After autoloading and the function is still not found, Avisynth+ can't tell which was the failing plugin exactly, maybe just in general: during autoload there were problems with some DLLs.

[pinterf]

Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.
Most of the color spaces unavaliable on VfW interface are autoconverted, such as Planar RGB 10 bit autoconverted to 16 bit RGB64, 12 bit YUV is autoconverted to 16 bits.
10+bit greyscale is an exception, it is not autoconverted at all.

[Groucho2004]

This is the source or error message:
// Load the dll into memory
plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
if (plugin.Library == NULL)
{
if (throwOnError)
{
DWORD errCode = GetLastError();
Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
}
else
return false;
}
OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:

void PluginManager::AutoloadPlugins()
{
...
// Try to load plugin
AVSValue dummy;
LoadPlugin(p, false, &dummy);
...
}

[tuanden0]

I got this error when use Imagewriter filter after update AVS+ 2489
System exception - Accsess Violation
(E:\Download\makeimagesequence.avs, line 6)

Here's my script:
LWLibavVideoSource("E:\Download\FF8.mkv")
AssumeFPS(24000, 1001)
Spline64ResizeMT(848, 480)
Trim(14583,14702)
ConvertToRGB()
ImageWriter("E:\Download\gif", type="png")

[Groucho2004]

I got this error when use Imagewriter filter after update AVS+ 2489

Try this:
ImageWriter("E:\Download\gif\%09d.png", type="png")

[pinterf]

I got this error when use Imagewriter filter after update AVS+ 2489

Bug. ImageWriter is searching a dot for getting the extension in the filename, and since the dot does not exist, the check fails with that nice AV error. I'll fix it. (The extension comes from another parameter. The extension check is new, because if 'raw' is found then it does not flip the image upside down)

And in the meanwhile with a magic '//' I have probably healed the infamous MT_SERIALIZABLE problem (which was intended to optimize the speed of the script a bit).

So there will be a new release in some days.

[tuanden0]

@Groucho2004: :thanks: IT's work now :D

@pinterf: luv you :D

[pinterf]

And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.

[Groucho2004]

And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.I'm wondering if we even need SetMemoryMax(). Can this not be done dynamically depending on script requirements, possibly with a warning if Avisynth tries to allocate more than a certain percentage of the available memory?

[pinterf]

OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?

For manual LoadPlugin I have applied the checking you have proposed to give a clean error message
avs [error]: Cannot load a 32 bit DLL in 64 bit Avisynth: 'c:/Test20160220/dll32mix64/etwas32.dll'

[Groucho2004]

For manual LoadPlugin I have applied the checking you have proposed to give a clean error message
avs [error]: Cannot load a 32 bit DLL in 64 bit Avisynth: 'c:/Test20160220/dll32mix64/etwas32.dll'
OK, but does Avisynth throw the same error when a user tries to use a function from a plugin that does not have the correct bitness?

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?
The answer to this is connected to my question above. If the bitness check is omitted during auto-load enumeration, the same cryptic message will be thrown ("no function named...") and the user is confused since he/she sees the DLL in the auto-load directory but it won't work.

[LigH]

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?

AviSynth+ supports separate autoload directories per bitness. But people sometimes make mistakes, thus a sensible, specific, and verbose error message will help debugging in case of mistakes.

[stax76]

should we force users to keep their autoload directories logical and clean

I vote for yes.

[amayra]

The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?

i already mentioned this problem in AvsFilterNet about MT after i tested in the first time
i think C++ not designed to deal with thread in in general leave alone Avisynth
new programming languages is different stores
PS: please correct me if i am wrong

[Groucho2004]

i think C++ not designed to deal with thread in in generalApart from the statement being nonsense, how did you come to that opinion?

new programming languages is different stores "New" programming languages are simply a different layer of abstraction of the underlying OS API and allow faster development which is important when you're working in a professional environment.

If you need fast code there is still nothing better than C/C++/ASM.

As a side note, since you mentioned AvsFilterNet, bringing the .NET monstrosity into Avisynth plugin development is just blasphemy. :sly:

[TheFluff]

i already mentioned this problem in AvsFilterNet about MT after i tested in the first time
i think C++ not designed to deal with thread in in general leave alone Avisynth
new programming languages is different stores
PS: please correct me if i am wrong

The fundamental reason Avisynth's multithreading is so broken is that people insisted on trying to shoehorn it into the existing API, which is highly unsuited for a multithreaded environment. It's not bad because it's written in C++, it's bad because there's a ton of complexity and hacked-up code piled up in an attempt to shove a square peg into a round hole.

In the Avisynth API every single function call is synchronous and blocking, and that's exactly what you don't want in a multithreaded environment (it makes scheduling and cooperating around shared resources really obnoxious and difficult). There are many different mechanisms for designing asynchronous API's, and while C++ doesn't have some of the fancier ones that some higher level languages do (for example promises/futures, the async/await keywords, etc) I always found that while simple callback-based interfaces tend to tempt lazy programmers into writing spaghetti code, they are simple, work in most languages and are easy to reason about and understand.

[mcjordan]

I've a problem. Dear pinterf, help me!
Last night I compiled a 2500 build, but today...
See screenshot below:
https://postimg.org/image/772vwju35/

[pinterf]

Try deleting CMakeCache.txt and do it again?

[mcjordan]

Yes. But cmake configured to generate project for VS2017 not working anymore (аs opposed to earlier). For VS2015 - working.

P.S. Hmmm... After updating Visual Studio to version 15.2 26430.12 all working again as before...
I'm confused. Sorry for disturbance.

[pinterf]

New build.

Download Avisynth+ r2502 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2502-MT)

20170602 r2502
- fix: (Important!) MT_SERIALIZED mode did not always protect filters (regression since r2069)
Such filters sometimes were called in a reentrant way (like being MT_NICE_FILTER), which
possibly resulted in using their internal buffers parallel.
- Fix: ImageWriter crash when no '.' in provided filename
- Fix: Overlay: correct masked blend: keep exact clip1 or clip2 pixel values for mask extremes 255 or 0.
Previously 0 became 1 for zero mask, similarly 255 changed into 254 for full transparency (255) mask
- New: script functions: StrToUtf8, StrFromUtf8: Converting a 8 bit (Ansi) string to UTF8 and back.
- New: PluginManager always throws error on finding wrong bitness DLL in the autoload directories
- Modified: increased x64 default MemoryMax from 1GB to 4GB, but physicalRAM/4 is still limiting
- Modified: allow conversions between RGB24/32/48/64 (8<->16 bits) w/o ConvertBits
- Added VS2017 and v141_xp to CMakeList.txt


Please report if this build fixed any of your unexplainable problems, image corruptions, that happened only in MT mode.

[tuanden0]

@pinterf:
I got this error from avs+ 2502. The AVSP said some 64bit filters were 32bit and AVSmeter can't get info from the avsisynth.
Then, I getback to 2489 and everything works again.

avs+ 2502: http://i.imgur.com/QfyD2Ux.png

avs+ 2489: http://i.imgur.com/jmSX2Es.png

[real.finder]

last build (r2502) didn't work in xp, test done by using VirtualBox

[tuanden0]

last build (r2502) didn't work in xp, test done by using VirtualBox

I'm using windows 7 64bit, Sir :D

[sneaker_ger]

@pinterf:
I got this error from avs+ 2502. The AVSP said some 64bit filters were 32bit and AVSmeter can't get info from the avsisynth.
Then, I getback to 2489 and everything works again.

avs+ 2502: http://i.imgur.com/QfyD2Ux.png

avs+ 2489: http://i.imgur.com/jmSX2Es.png
Delete the two .dll files. In the past they just wouldn't be loaded even if there was no error message.

[Groucho2004]

@tuanden0
Could you please upload the VSFilter.dll from your second screen shot somewhere?

[Groucho2004]

last build (r2502) didn't work in xp, test done by using VirtualBoxThe 64 bit build does work (XP64) but there's something wrong with the 32 bit version, I'm getting random exceptions.

[real.finder]

I'm using windows 7 64bit, Sir :D

seems there are confuse, I report that to pinterf :)

[Groucho2004]

In the past they just wouldn't be loaded even if there was no error message.Yes, but AVSMeter would have thrown the error instead. Also, look at the second screen shot, there is only one plugin listed. Something's weird.

Edit: @tuanden0: The complete AVSMeter logs would help find the problem (AVSMeter -avsinfo -log).

[tuanden0]

@tuanden0
Could you please upload the VSFilter.dll from your second screen shot somewhere?

@Groucho2004:
Here is it :D I take it from test server of MeGUI :D
http://megui.tmebi.de/test/vsfilter.1.5.0.2827_x64.7z

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?
Then, after deleted filter folder, i have a logs

[Groucho2004]

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?I highly doubt that it says to delete folders. You're supposed to remove the 64 bit DLL(s) from the 32 bit plugin folder(s) and the 32 bit DLL(s) from the 64 bit plugin folder(s).

Also, post the logs somewhere else. It could take a long time before the attachment is approved.

[pinterf]

I'm on the XP problem, so far no success.
EDIT:
Arggh. It was a compiler setting problem: /Zc:threadSafeInit- was missing.

But now I see what happens.
During autoload, these DLLs called GetCPUFlags in their Init, after AddFunction and caused Avisynth+ to crash.

VerticalCleanerSSE2.dll
RepairSSE2.dll
RemoveGrainSSE2.dll
RemoveDirtSSE2.dll
SSE2Tools.dll


e.g. in old RemoveGrain source
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env)
{
#ifdef MODIFYPLUGIN
env->AddFunction("Repair", "cc[mode]i[modeU]i[modeV]i[planar]b", CreateRemoveGrain, 0);
env->AddFunction("TemporalRepair", "cc[smooth]i[grey]b[planar]b", CreateTemporalRepair, 0);
#else // MODIFYPLUGIN
env->AddFunction("RemoveGrain", "c[mode]i[modeU]i[modeV]i[planar]b", CreateRemoveGrain, 0);
env->AddFunction("Clense", "c[grey]b[reduceflicker]b[planar]b[cache]i", CreateClense, 0);
env->AddFunction("MCClense", "ccc[grey]b[planar]b", CreateMCClense, 0);
env->AddFunction("BackwardClense", clenseargs, CreateBackwardClense, 0);
env->AddFunction("ForwardClense", clenseargs, CreateForwardClense, 0);
#endif // MODIFYPLUGIN
AVSenvironment = env;
if( (CPUFLAGS & env->GetCPUFlags()) != CPUFLAGS )
#if ISSE > 1
env->ThrowError("RemoveGrain needs an SSE2 capable cpu!\n");
#else
env->ThrowError("RemoveGrain needs an SSE capable cpu!\n");
#endif
#if 0
debug_printf(LOGO);
#endif
return "RemoveGrain: remove grain from film";
}

The GetCPUFlags gave access violation.

From the two debug lines in GetCPUFlags, only the first one was displayed, seems that calling CPUCheckForExtensions gave an instant crash.

In cpuid.cpp
static int CPUCheckForExtensions()
{
...
}

int GetCPUFlags() {
_RPT0(0, "GetCPUFlags() called\n");
static int lCPUExtensionsAvailable = CPUCheckForExtensions();
_RPT0(0, "GetCPUFlags() called 2\n");
return lCPUExtensionsAvailable;
}

This static initialization fails under XP w/o the /Zc:threadSafeInit- flag.

Rebuild later, it's already dark here, and I have get home w/o police affairs (forgot to put front lamp on my bike)

[pinterf]

Thank you for your patience, here come the fixed binaries

Download Avisynth+ r2504-MT (broken XP support hotfix) (https://github.com/pinterf/AviSynthPlus/releases/tag/r2504-MT)

[Groucho2004]

Thank you for your patiance, here come the fixed binariesThank you, this seems to work fine now.

[Groucho2004]

@Groucho2004:
Here is it :D I take it from test server of MeGUI :D
http://megui.tmebi.de/test/vsfilter.1.5.0.2827_x64.7z

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?
Then, after deleted filter folder, i have a logs
According to your logs, there are no plugins in the listed auto-load directories which makes sense since you apparently deleted all auto-load directories. Judging by the auto-load entries in the registry it seems that you installed several Avisynth versions on top of each other without un-installing first.

You should clean this up and re-install:

- Delete "C:\Program Files (x86)\AviSynth+" and subdirs
- Delete these registry keys:
HKEY_CURRENT_USER\Software\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth

[tuanden0]

You should clean this up and re-install:

- Delete "C:\Program Files (x86)\AviSynth+" and subdirs
- Delete these registry keys:
HKEY_CURRENT_USER\Software\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth

How can I say "I love you" Groucho2004 :thanks:

[jpsdr]

@Pinterf : Are-you using VS2017 ? If i haven't try for now to update to VS2017, is that i don't know if XP is still supported. When your new version didn't work, i thought i was the case, i said to myself "No... He didn't forget the /Zc:threadSafeInit-, it's probably not so easy... ;)".
Another thing, i don't know if the it can be installed under a 32bits OS (bad surprise with last Intel Compiler which doesn't install under a 32bits OS... :().

[StainlessS]

Jpsdr, see here:- https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs

XP supported as target, but last VS to support compilation on XP was vs 2010.
(Not sure, I think XP tool set was not provided until quite recently on vs 2017, I guess that they
finally realized that not everyone was willing to drop support for some millions of the old OS users).

[qyot27]

Jpsdr, see here:- https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs

XP supported as target, but last VS to support compilation on XP was vs 2010.
(Not sure, I think XP tool set was not provided until quite recently on vs 2017, I guess that they
finally realized that not everyone was willing to drop support for some millions of the old OS users).
IIRC, when installing VS2017, you can also install VS2015's compilers/toolsets, so it could be configured to use v140_xp. The difference would be that there's also a v141_xp now (specifically for VS2017, apparently) too.

But I installed it a couple months ago and don't remember too well.

[pinterf]

@Pinterf : Are-you using VS2017 ? If i haven't try for now to update to VS2017, is that i don't know if XP is still supported. When your new version didn't work, i thought i was the case, i said to myself "No... He didn't forget the /Zc:threadSafeInit-, it's probably not so easy... ;)".
Another thing, i don't know if the it can be installed under a 32bits OS (bad surprise with last Intel Compiler which doesn't install under a 32bits OS... :().
I'm not using it for production releases yet. When I have edited the cmake list file for vs2017, the XP support switch was moved (and not copied) from the vs2015 section so vs2015 build missed that option.

[VS_Fan]

FFmpegSource2(source="MVI_2038.avi")

#ConvertToYV12()
c0 = last

Y8=ExtractY()
U8=ExtractU()
V8=ExtractV()

Y8= <luma Separate filter(s)>
U8= <chroma Separate filter(s)>
V8= <chroma Separate filter(s)>

CombinePlanes(Y8, U8, V8, planes="YUV", sample_clip=c0) #, pixel_type="YUV420P8" #, source_planes="YYY")

This will work if I convert to YV12 (YUV420P8), but my source is YV16 (YUV422P8), and I would of course prefer to keep it that way.

Am I doing anything wrong?

This is the error message I get when trying it with YUV422 material:

"CombinePlanes: source and target plane dimensions are different"

[raffriff42]

"CombinePlanes: source and target plane dimensions are different"I think I found it:
avs_core\filters\planeswap.cpp, Line 870
int target_plane_width = vi_default.width >> vi_default.GetPlaneWidthSubsampling(current_target_plane);
int target_plane_height = vi_default.height >> vi_default.GetPlaneWidthSubsampling(current_target_plane);

[pinterf]

I think I found it:
avs_core\filters\planeswap.cpp, Line 870
int target_plane_width = vi_default.width >> vi_default.GetPlaneWidthSubsampling(current_target_plane);
int target_plane_height = vi_default.height >> vi_default.GetPlaneWidthSubsampling(current_target_plane);

Oops, thanks.

[pinterf]

CombinePlanes fixed, thanks for the report.

Download Avisynth+ r2506 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2506-MT)

20170608 r2506
- Fix CombinePlanes: feeding YV16 or YV411 target with Y8 sources

[edcrfv94]

after r1858 update to r2506.
r2506 will not load libfftw3f-3.dll under plugins+/plugins64+, libfftw3f-3.dll must under System32/SysWOW64.
It is a bug?

[Groucho2004]

after r1858 update to r2506.
r2506 will not load libfftw3f-3.dll under plugins+/plugins64+, libfftw3f-3.dll must under System32/SysWOW64.
It is a bug?No, it's a feature. :D

libfftw3f-3.dll is not a plugin, it's not supposed to be in the auto-load directory. It has to be either in the current directory, the same directory of the calling program or in a directory to which the "PATH" environment variable points. For simplicity, just put it in System32/SysWOW64.

[Sharc]

For the same source, same script and same x264 encoder settings (1-pass crf) I am getting about 45% bigger file size (and more noise) for AVS+ (x86) compared to AVS 2.6.0. How is this possible? :confused:

[sneaker_ger]

High bitdepth/dithering?

Show sample, scripts, program versions and logs.

[MysteryX]

I'm running FrameRateConverter with 1 thread

FrameRateConverter(60, output="auto")



FPS (min | max | average): 2.044 | 68778 | 12.90
Memory usage (phys | virt): 353 | 349 MiB
Thread count: 21
CPU usage (average): 13%


and with 8 threads

FPS (min | max | average): 2.332 | 129914 | 31.80
Memory usage (phys | virt): 785 | 784 MiB
Thread count: 29
CPU usage (average): 42%

What is causing such a bottleneck at 42% CPU usage?

[pinterf]

What is causing such a bottleneck at 42% CPU usage?
Are you using 32 or 64 bit Avisynth? What is your SetMemoryMax?
Perhaps try SetLogParams("log.txt", LOG_DEBUG) and look at the output. Is there any serialized mt mode filter in between?

[Sharc]

High bitdepth/dithering?

Show sample, scripts, program versions and logs.
I think I found the culprit. I am using in my script
temporalsoften(4,4,8,10,mode=2)
It seems to have no effect with AVS+ r2506, while it works as expected in AVS260.

[Groucho2004]

What is causing such a bottleneck at 42% CPU usage?I've noticed the same with John Meyer's simpler script. It has to be one (or a combination) of the mvtools2 functions that does not scale well with MT.

Edit: Throwing more threads at it seems to improve things without compromising efficiency (CPU with 4 cores/threads):

Prefetch(4):
FPS (min | max | average): 4.755 | 275350 | 48.26
Memory usage (phys | virt): 310 | 409 MiB
Thread count: 15
CPU usage (average): 66%
Efficiency index: 0.7312


Prefetch(6):
FPS (min | max | average): 17.36 | 167.1 | 57.60
Memory usage (phys | virt): 413 | 514 MiB
Thread count: 17
CPU usage (average): 79%
Efficiency index: 0.7292


Prefetch(8):
FPS (min | max | average): 14.93 | 4436 | 69.60
Memory usage (phys | virt): 527 | 628 MiB
Thread count: 19
CPU usage (average): 95%
Efficiency index: 0.7326


Prefetch(10):
FPS (min | max | average): 15.04 | 158387 | 72.15
Memory usage (phys | virt): 654 | 756 MiB
Thread count: 21
CPU usage (average): 99%
Efficiency index: 0.7288


Please note that this was done with John Meyer's script and an older version of mvtools2 (2.5.11.22) but the trend should be similar with your FrameRateConverter and pinterf's latest mvtools.

[pinterf]

I think I found the culprit. I am using in my script
temporalsoften(4,4,8,10,mode=2)
It seems to have no effect with AVS+ r2506, while it works as expected in AVS260.
r2506 is giving identical results to the very early (1576) avs+ versions.
Maybe this (https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/filters/focus.cpp#L1148) sse2 part was a bit overoptimized, because now I replaced it with something I could understand and it is giving the same result as classic Avisynth 2.6.
I think using max thresholds (like QTGMC does) there is no problem with latest avs+ versions, I have put that special case in a separate optimized code path earlier.

So expect a fix for this.

And until then read this (http://www.vapoursynth.com/2016/09/blindly-copying-avisynth-considered-harmful/) comment from Myrsloik.

[Sharc]

.... So expect a fix for this.

And until then read this (http://www.vapoursynth.com/2016/09/blindly-copying-avisynth-considered-harmful/) comment from Myrsloik.
Excellent, thanks!
Well, maybe there exist better substitutes for temporalsoften(). I found it however to be a very useful and effective filter for VHS sources.

[MysteryX]

There is no SetMemory. I'm using x86.

The only thing that comes into the log is

INFO: LSMASHSource_LWLibavVideoSource() does not have any MT-mode specification.
Because it is a source filter, it will use MT_SERIALIZED instead of the default MT mode.

until it ran out of memory with 8 threads and crashed.

Here's the code, running on a 1080p source

file="Female President.mp4"
SetLogParams("log.txt", LOG_DEBUG)
LWLibavVideoSource(file, cache=False)
ConvertToYV12()
FrameRateConverter(60)
Prefetch(8)



FPS (min | max | average): 1.157 | 101672 | 13.12
Memory usage (phys | virt): 1446 | 1451 MiB
Thread count: 29
CPU usage (average): 52%

Output="flow"

FPS (min | max | average): 2.674 | 93538 | 18.11
Memory usage (phys | virt): 1423 | 1434 MiB
Thread count: 29
CPU usage (average): 64%


jm_fps alone

FPS (min | max | average): 3.096 | 97436 | 16.91
Memory usage (phys | virt): 1457 | 1465 MiB
Thread count: 29
CPU usage (average): 63%


I was wondering whether unused script filters were being initiated and causing performance or memory problems. I can see it's not an issue.

Yes, the issue is in MvTools2 and should be tested on jm_fps. In my case, I can't fix performance by increasing threads (8 cores). 12 gives a slight performance increase, and 16 gives a performance decrease.

and here's performance on a 1080p source with DCT=1 (preset="slow")

FPS (min | max | average): 0.083 | 83516 | 0.484
Memory usage (phys | virt): 1168 | 1166 MiB
Thread count: 26
CPU usage (average): 26%

I'd get a nice 1.5fps if CPU would work fully.

[chummy]

I'm facing a problem with specific source VP9 file with single keyframe. FFMS2 cause error and Directshowsource change clip duration by few millliseconds and cause framecount to change, this is enough to audio come out of sync.

[avisynth @ 0358ba40] FFVideoSource: Out of bounds frame requestede=16629.7kbits/s speed=0.247x
Unknown error occurred

Input check with FFMpeg:
Duration: 00:02:02.56, start: -0.007000, bitrate: 11360 kb/s
Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)

When feeding Avisynth+(ffms2) script to FFMpeg:
Duration: 00:02:02.12, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

When feeding with Avs+ and Directshowsource:
Input #0, avisynth, from 'GTA5 1600mhz low.avs':
Duration: 00:02:02.59, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc

Directshowsource is only changing by 3ms, but for videos longer than 5 minutes there is noticeable out of sync audio.

Encoding the video directly with FFMpeg cause no such issue.

[MysteryX]

Under Avisynth 2.6, BitsPerComponent returns 0 instead of 8. Seems like a bug to me.

[Groucho2004]

Under Avisynth 2.6, BitsPerComponent returns 0 instead of 8. Seems like a bug to me.I checked your FramerateConverter git repository, the avisynth.h you're using does not have the fallback mechanism. Update to the latest headers and it will work correctly.

[hello_hello]

I'm facing a problem with specific source VP9 file with single keyframe. FFMS2 cause error and Directshowsource change clip duration by few millliseconds and cause framecount to change, this is enough to audio come out of sync.

I think DirectShowSource uses 29.970fps as the frame rate. Maybe adding AssumeFPS(3000,1001) to the end of the script will fix it, although the difference is very small.

There'd probably be minor differences in the way the timing is rounded, as at 29.970fps (3000/1001) each frame has a duration of 33.366666_ ms.
If my maths is correct your clip's duration should be 00:02:02.53.4666666 ms (at frame number 3658). I checked a clip with Avisynth using Info() and at frame 3658 it reports 00:02:02.55 ms. Maybe ffmpeg uses a slightly different pattern for rounding frames to the nearest ms.

Try this:
DirectShowSource("E:\video.mkv", audio=false, fps=29.970, convertfps=true).AssumeFPS(3000,1001)

Or this:
FFVideoSource("E:\video.mkv", threads=1, fpsnum=30000, fpsden=1001)

[stax76]

FFVideoSource fpsnum/fpsden drops/adds frame though

[sneaker_ger]

You guys realize a/v sync is about video and audio, right?

[MysteryX]

I've noticed the same with John Meyer's simpler script. It has to be one (or a combination) of the mvtools2 functions that does not scale well with MT.
I've just done an encoding test and it ran at about ~15% CPU usage which is unacceptable.

If I were to guess, it looks like incorrect mutex locks preventing proper MT execution.

[Groucho2004]

If I were to guess, it looks like incorrect mutex locks preventing proper MT execution.What mutex? Where?

[MysteryX]

What mutex? Where?
jm_fps has that issue, so in MvTools2. I haven't looked at the code.

[hello_hello]

FFVideoSource fpsnum/fpsden drops/adds frame though

So does convertfps=true for DirectShowSource, but if the frame rate is just a little off that might be enough to fix it (I've never understood why it isn't changefps=true for DirectShowSource, given it behaves the same ways as Avisynth's ChangeFPS).

chummy probably needs to add Info() to a script and preview the output to determine the frame rate and whether adding any sort of frame rate conversion would fix the audio sync.

Assuming that's actually the problem. We don't know how chummy is extracting/muxing the audio or whether it's being converted etc.

[Groucho2004]

jm_fps has that issue, so in MvTools2. I haven't looked at the code.MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.

[MysteryX]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.
What temporal range does it have? What's different in this plugin that could make it function worse than other filters?

Or is it requesting frames in the wrong order or something? Perhaps something is getting mixed up in the buffers or something.

[MysteryX]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose. SEt's AVS MT is even worse with this script.

Maybe the large temporal range and non-linear frame requests wreak havoc with the multi-threading.
SVP has the same temporal range as MvTools2 and performs extremely well, so it cannot explain the performance issues -- unless it requests them in a different order.

[Groucho2004]

SVP has the same temporal range as MvTools2 and performs extremely well, so it cannot explain the performance issues -- unless it requests them in a different order.Apples and oranges.

If you really want to find out run a profiler.

[MysteryX]

Here's an interesting case.


file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)

FPS (min | max | average): 70.50 | 168.0 | 113.8
Memory usage (phys | virt): 108 | 105 MiB
Thread count: 21
CPU usage (average): 25%



file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)
Prefetch(8)

FPS (min | max | average): 1.816 | 212585 | 42.70
Memory usage (phys | virt): 160 | 157 MiB
Thread count: 29
CPU usage (average): 67%
Adding Threads=1 to LWLibavVideoSource makes fps drop to 16


file="1080p.mp4"
LWLibavVideoSource(file, cache=False)
Spline36Resize(Width/2, Height/2)
jm_fps() # Without Recalculate
Prefetch(8)

FPS (min | max | average): 1.844 | 101671 | 77.29
Memory usage (phys | virt): 650 | 648 MiB
Thread count: 29
CPU usage (average): 71%
Going from 42.7 to 77.3 fps by adding jm_fps, really? This doesn't happen if we remove SplineResize.

replacing jm_fps with
FrameRateConverter(60, Output="Flow")

FPS (min | max | average): 3.539 | 129914 | 49.19
Memory usage (phys | virt): 956 | 955 MiB
Thread count: 29
CPU usage (average): 60%

FrameRateConverter(60)

FPS (min | max | average): 2.222 | 137555 | 33.69
Memory usage (phys | virt): 735 | 735 MiB
Thread count: 29
CPU usage (average): 42%

If I replace the source with ColorBarsHD, jm_fps with Recalculate runs at 75% CPU which isn't bad. FrameRateConverter runs at 54% CPU.

Here's the jm_fps function I'm using. Note: I did the test with super=superfilt line which isn't correct but that's how I ran the tests.

function jm_fps(clip C) {
Blksize=16
BlkSizeV=16
Dct=0
NewNum=60
NewDen=1
Recalculate = true
Prefilter = C.RemoveGrain(22)
superfilt = MSuper(prefilter, hpad=16, vpad=16) # all levels for MAnalyse
super = superfilt #MSuper(C, hpad=16, vpad=16, levels=1)
bak = MAnalyse(superfilt, isb=true, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, overlapv = BlkSizeV>4?(BlkSizeV/4+1)/2*2:0, search=3, dct=Dct)
fwd = MAnalyse(superfilt, isb=false, blksize=BlkSize, blksizev=BlkSizeV, overlap = BlkSize>4?(BlkSize/4+1)/2*2:0, search=3, dct=Dct)
fwd = Recalculate ? MRecalculate(super, fwd, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : fwd
bak = Recalculate ? MRecalculate(super, bak, blksize=BlkSize/2, blksizev=BlkSizeV/2, overlap = BlkSize/2>4?(BlkSize/8+1)/2*2:0, overlapv = BlkSizeV/2>4?(BlkSizeV/8+1)/2*2:0, thSAD=100) : bak
Flow = MFlowFps(C, super, bak, fwd, num=NewNum, den=NewDen, blend=false, ml=200, mask=2, thSCD2=255)
return Flow
}

[Groucho2004]

MVTools2 is single-threaded so any thread synchronisation issues would be within Avisynth itself I suppose.I should mention that pinterf's latest mvtools2 still supports multi-threading through avstp.dll and that it is enabled by default (mt = true).
Adding avstp.dll to your plugin directory may improve things - or not.

[LigH]

Some time ago, I had issues with threading in complex functions (probably QTGMC?) and was recommended to remove avstp.dll from the auto-load directory, but that was with AviSynth 2.6 MT (SEt). Unfortunately, I do not remember the details of the circumstances, only the conclusion. Is the cooperation different under AviSynth+?

[Groucho2004]

Is the cooperation different under AviSynth+?Since AVS+ has a different multi-threading implementation I would say yes, it's different. If it's better or worse, I don't know.

Either way, I don't think it's a good idea to mix Avisynth's multi-threading with plugins that have internal MT. It's not only less efficient because of increased scheduling overhead, it also adds unnecessary complexity.

[LigH]

One reason why QTGMC exposes the parameter EDIThreads...

[MysteryX]

I should mention that pinterf's latest mvtools2 still supports multi-threading through avstp.dll and that it is enabled by default (mt = true).
Adding avstp.dll to your plugin directory may improve things - or not.
Which function(s) exposes mt parameter?

Perhaps if avstp.dll is using internal multi-threading and was never meant to be called several times, and it is being called multiple times, then the various threads lock each other.

[Groucho2004]

which function(s) exposes mt parameter?rtfm :)

[Groucho2004]

Perhaps if avstp.dll is using internal multi-threading and was never meant to be called several times, and it is being called multiple times, then the various threads lock each other.You should really read the documentation (https://forum.doom9.org/showthread.php?t=164407).

[MysteryX]

Adding and loading avstp.dll really doesn't change much at all -- and if it's not loaded, then I assume it's using single-threaded mode.

[postscripter]

Hello, guys. I've switched from AVS 2.6 to AVS+ and got my plugin broken. It can not even load the dll and says this:
---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
'D:/Личные папки/Projects/Ретранслятор/Osd/MyOSD.dll' cannot be used as a plugin for AviSynth.
(D:\Личные папки\Projects\Ретранслятор\Измерения\Скрипт.avs, line 29)
---------------------------

The plugin is C-plugin written in Delphi (forum.doom9.org/showthread.php?t=98327), and the classic AVS 2,5 - 2,6 had no problem with it.

The error I mentioned can be found on the line 534 (https://github.com/AviSynth/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp) and next on the 659. And the only check there is this:
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
if (AvisynthCPluginInit == NULL) return false;

In russian we say that the dog is buried somewhere here, meaning the heart of the matter, which is close enough. As close, as the symbol [@], which is the dog in russian :) C-dlls usually have this @4 in export table after the name of the function, but delphi does not know about such things, and so do I. Google says, it's called function decoration. This is the first time I see such notation. Could anyone explain, what is it for and what to do with it? I can just recompile my plugin, of course, but wouldn't it be better to submit an issue (or the developers are already here)? Looks like a regression.

[Groucho2004]

Hello, guys. I've switched from AVS 2.6 to AVS+ and got my plugin broken.Avisynth+ does not support C/CPP 2.0 plugins.

[pinterf]

Yes, you are using probably the old, not supported interface.

The error I mentioned can be found on the line 534 (https://github.com/AviSynth/AviSynthPlus/blob/2d3cb6c011f520fc9433d6bff61a6d697cb09ecb/avs_core/core/PluginManager.cpp) and next on the 659. And the only check there is this:
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
if (AvisynthCPluginInit == NULL) return false;

The same part in current version looks like this:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L942

#ifdef _WIN64
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init");
if (!AvisynthCPluginInit)
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
#else // _WIN32
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
if (!AvisynthCPluginInit)
AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");
#endif

[postscripter]

Avisynth+ does not support C/CPP 2.0 plugins.

Absolutely no idea what 2.0 means, but I've just changed the export name and have it usable now. Magic?

The same part in current version looks like this:

Well.. yeah. By the way. About current versions. Which one is the latest? Which is the latest for those, who need MT (http://forum.doom9.org/showthread.php?p=1666364#post1666364)? What happened with the original AviSynth repo (https://github.com/AviSynth/AviSynthPlus), which is referred by in Wiki (http://avisynth.nl/index.php/Main_Page)and on avs-plus.net (http://www.avs-plus.net/)? I can see the same contributors there and last activity in 2014'th... Did they lost the password?


looks like this
Looks the same for me) I see changes for 64 bit only. I reckon, you did it for Studio compiler, which introduce a big mess, adding @x for 32-bit DLLs only (https://stackoverflow.com/questions/28062446/x64-dll-export-function-names). But Delphi compiler does not add @x at all, unless you write it by yourself. Why don't you keep it simple, like this:
AvisynthCPluginInitFunc AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "_avisynth_c_plugin_init@4");
if (!AvisynthCPluginInit) AvisynthCPluginInit = (AvisynthCPluginInitFunc)GetProcAddress(plugin.Library, "avisynth_c_plugin_init@4");

Or you can make an array of names))

[Groucho2004]

Absolutely no idea what 2.0 meansThe Avisynth C 2.0 API was the first C implementation by Kevin Atkinson. See here (https://forum.doom9.org/showthread.php?t=58840).

I've just changed the export name and have it usable now. Magic?Right now I don't have a reference table that lists the differences between the 2.0, 2.5 and 2.6 APIs but I suppose it's possible that just changing the export name might do the trick. Here's (http://avisynth.nl/index.php/Avisynth_Plugin_Development_in_C) some documentation but I'm not sure how helpful this is for your Delphi plugin thingy.

[Groucho2004]

Adding and loading avstp.dll really doesn't change much at all
It works better with something "simple" such as MDegrainN().

[qyot27]

Well.. yeah. By the way. About current versions. Which one is the latest? Which is the latest for those, who need MT (http://forum.doom9.org/showthread.php?p=1666364#post1666364)? What happened with the original AviSynth repo (https://github.com/AviSynth/AviSynthPlus), which is referred by in Wiki (http://avisynth.nl/index.php/Main_Page)and on avs-plus.net (http://www.avs-plus.net/)? I can see the same contributors there and last activity in 2014'th... Did they lost the password?
The MT branch is the most up-to-date on the upstream repo:
https://github.com/AviSynth/AviSynthPlus/commits/MT

The stuff pinterf is working on is currently being treated as an ad hoc development HEAD, there's an open pull request for it (https://github.com/AviSynth/AviSynthPlus/pull/101).

The reason MT hasn't been merged into the master branch has less to do with stability (to wit, you have to use builds from the MT branch if you want to use AviSynth+ with FFmpeg, since only the MT branch is synced up with AviSynth 2.6.0/2.6.1), and more to do with ultim going on hiatus every so often and wanting bugs that had existed in the MT branch to be resolved first. They mostly have*, but like I previously mentioned, hiatus. The same largely applies to pinterf's pull request, although the recent Unicode fixes broke GCC again.

*save for the problems inherent to synchronous access, as discussed at length over the last few pages of this thread.

Supported compilers are Visual Studio 2015 and higher, and GCC (experimental). I was in the middle of testing weird function decoration stuff with GCC and the C plugin back in April, but since I can only use 64-bit Wine or take a huge performance hit and run 64-bit Windows in a VM, that stalled out somewhat.

[pinterf]

New release with TemporalSoften fix.
Thanks to Sharc for the report (https://forum.doom9.org/showthread.php?p=1810075#post1810075).

Download Avisynth+ r2508-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2508-MT)

20170629 r2508
- Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)

[Sharc]

New release with TemporalSoften fix.
Thanks to Sharc for the report (https://forum.doom9.org/showthread.php?p=1810075#post1810075).

Download Avisynth+ r2508-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2508-MT)

20170629 r2508
- Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)
I confirm it's working now. Thank you.

[mkver]

Is it normal that using Levels with high-bitdepth input and enabled dithering eats incredibly much RAM? Is this a gigantic LUT?

Video = BlankClip(10000,pixel_type="YUV420P10")

Return Video.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
/*.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)\
.Levels(0,1.0,1023,0,1023,coring=false,dither=true)*/

uses 82 MB. Each Levels that I uncomment adds about 64 MB to that. This does not happen without dither or with 8bit input.
On a related note: Would it be possible to add a switch to avsmeter to disable the "Script runtime is too short for meaningful measurements" error? I needed to increase the framecount of the blankclip

[MysteryX]

Is it normal that using Levels with high-bitdepth input and enabled dithering eats incredibly much RAM? Is this a gigantic LUT?
That's the reason LUT is disabled for 14-16 bit clips and it is using runtime evaluation.

[mkver]

That's the reason LUT is disabled for 14-16 bit clips and it is using runtime evaluation.
Are you sure about this? avsmeter reports exactly the same memory usage for 10, 12, 14 and 16 bits. And strangely: It doesn't matter if it is a greyscale format or what chroma subsampling it uses, the difference is negligible. I always thought that Levels treats Luma and Chroma differently (i.e. knows that luma should be scaled normally, but that chroma should be scaled from 128 so that one should need two LUTs for them).

[MysteryX]

Take a look at release notes of v2.2.2 (https://github.com/pinterf/masktools/releases/tag/2.2.2) and play with realtime argument.

When realtime is enabled is well documented here (http://avisynth.nl/index.php/MaskTools2)

[mkver]

Are you telling me I should use MaskTools instead of Levels (I have already thought about it, but I wanted to know whether this is a bug in Levels or not first)? Or are you thinking that Levels is part of MaskTools?
Anyway, thanks for answering.

[MysteryX]

Sorry I didn't read correctly and mixed things up when you mentioned LUT. Forget what I said. I'll leave Pinterf answer.

If it uses a LUT table, however, it's likely it might use a similar logic.

[TheFluff]

Levels always uses a LUT currently. There's a comment (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L159) in the code that says runtime evaluation is todo for 32-bit float input.

The reason it eats so much memory with dithering enabled is that enabling dithering multiplies the LUT size by 256; see line 179 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L179) and the subsequent allocation on line 195 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L195).

[mkver]

Thanks for pointing to the source. And what's the logic that makes a 10bit LUT use the same memory as a 16bit LUT? Is it because of the "garbage" (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L199) mentioned here? (Garbage means that the most significant bits aren't necessarily zero, although they should be, or?)
And because IsYUV is true for Y8-Y16, line 193 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L193) and line 203 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L203) imply that a chroma LUT is created for monochrome formats.

[tebasuna51]

I found a difference between Avs+ and AviSynth 2.60 behaviour.

This script with Avs+:

WavSource("16-bit-int.wav")
SSRC(44100)

don't work with Avs+ and show a error: Input audio sample format to SSRC must be float.

Work fine with AviSynth 2.60 and output a Float wav like be expected by documentation (http://avisynth.nl/index.php/SSRC) :

"Audio is always converted to Float."

Please, instead show the error, do the conversion automatically.

[qyot27]

I found a difference between Avs+ and AviSynth 2.60 behaviour.

This script with Avs+:

WavSource("16-bit-int.wav")
SSRC(44100)

don't work with Avs+ and show a error: Input audio sample format to SSRC must be float.

Work fine with AviSynth 2.60 and output a Float wav like be expected by documentation (http://avisynth.nl/index.php/SSRC) :

"Audio is always converted to Float."

Please, instead show the error, do the conversion automatically.
That change was done deliberately (https://github.com/AviSynth/AviSynthPlus/commit/d40f4a2e833998199dec0e0e4737cf69c4607b6c), and is a long-acknowledged difference in behavior, because it was a conscious choice to enforce that AviSynth+ won't do implicit conversions between formats. Erroring out here isn't any different from other errors regarding filters not supporting X pixel format for video. You have to use ConvertTo there if you try giving a filter the wrong format, if you have int audio and want to give it to SSRC, then use ConvertAudioToFloat on it first. Either that, or the SSRC filter itself should be extended to actually support int audio input.

This should instead be mentioned in the AviSynth+ page on the wiki, since you can't expect other AviSynth+ changes to be true for 2.6's doc entries either, save for Plus revisions to be explicitly noted (there are some places it is, right?). I thought the 'no implicit conversions' decision was mentioned on the AviSynth+ page at some point, but may have gotten lost in the updates and that page getting split up.

[tebasuna51]

I can't understand for what introduce unnecesary differences with the standard Avisynth behavior.

Is only a way to obtain bug reports, like mine.

I think I read all Avs+ docs and don't see nothing about it.

[manolito]

I totally agree with tebasuna. The "+" in AVS+ stands for "Everything which standard AVS has, and then plus a lot of other things". At least this is how it should be.

Breaking backward compatibility is a BAD thing, and it's even worse if it is not a bug, but a deliberate design decision. Even if you think that the standard AVS design is wrong, you cannot just change it because of the huge installed standard AVS user base. If you want to change the design then do something completely different like VapourSynth.


Cheers
manolito

[Sharc]

Agree, +1

[TheFluff]

If you want bug-for-bug compatibility with Avisynth 2.5.8 until the heat death of the universe, then maybe what you want to use is... Avisynth 2.5.8? But then again, adding an explicit ConvertToFloat call is hardly back-breaking labor for any of you, now is it? In fact, I'd wager it's less work than downgrading to 2.5.8. I mean, yeah, it should be documented that it doesn't implicitly convert anymore, but the presence of implicit conversions has a far greater potential for Surprise and Confusion than removing them does. Yes I know you're used to the old behavior but that doesn't mean it's any less confusing for new users.

I totally agree with tebasuna. The "+" in AVS+ stands for "Everything which standard AVS has, and then plus a lot of other things". At least this is how it should be.

Breaking backward compatibility is a BAD thing, and it's even worse if it is not a bug, but a deliberate design decision. Even if you think that the standard AVS design is wrong, you cannot just change it because of the huge installed standard AVS user base. If you want to change the design then do something completely different like VapourSynth.

If people actually consistently applied this logic then Avs+ would never have happened, because like it or not it is a substantial design departure from OG Avisynth in many respects. It maintains a user interface that is mostly similar, but even that is not the same.

Either way though, "once you've got a design that a lot of people use you can't ever change it" is a fundamentally brain damaged position to take in software design.

[stax76]

There is always something between black and white..., like a option both on system and file level.

[vcmohan]

To satisfy both, may be, have a separate section in doom9 forum like vapoursynth has.

[Motenai Yoda]

iirc the strict check about variables type was introduced with 2.6 vanilla branch

[raffriff42]

That change was done deliberately, and is a long-acknowledged difference in behavior, because it was a conscious choice to enforce that AviSynth+ won't do implicit conversions between formats. Erroring out here isn't any different from other errors regarding filters not supporting X pixel format for video.Makes sense to me. If the conversion must be made, do so explicitly.

[LigH]

An explicit conversion may be necessary for newer AviSynth versions; but at least it doesn't break compatibility to older versions.

[MysteryX]

An explicit conversion may be necessary for newer AviSynth versions; but at least it doesn't break compatibility to older versions.
If you have an old script that was doing an implicit conversion, it will break.

Same as here.

I see no difference.

In both cases you need to do explicit conversion.

[LigH]

I just meant, you don't need explicit for one version and implicit for the other; only explicit for all. Be a good example, be verbose. ;) Sorry, I started learning serious programming with Pascal, I am used to be a bit more explicit, due to the stricter type checks. At least I don't rate a small one-line addition as desaster. Incompatibilities between PHP versions 4.x, 5.2, 5.4 and 5.6 are a lot worse (e.g. HTML entity conversion functions silently returning an empty string when one character is in the wrong character set, instead of throwing an error, which you can avoid by explicitly stating the character set, which is incompatible to earlier PHP versions not knowing this parameter).

[manolito]

Sorry I do not understand this whole fuss about explicit converttoflow or do it automatically..

SSRC is a filter which is integrated into AviSynth, but which is basically separate code which is not related to AviSynth. SSRC happens to require float input. If the input is not float then it must be converted to float somehow, I don't care if Avisynth does the conversion or if SSRC does it. Since the user obviously wants SSRC, it is safe to assume that he just forgot to do the conversion explicitly. Instead of throwing an error (which is the equivalent of telling the user that he is stupid), why can't SSRC (or AviSynth) do this conversion automatically? It has worked this way for many years, nothing about it is confusing, it just makes my life easier AND IT WORKS! The most important principle for software development is to make it easy to get working results, not to teach the developer about correct programming habits.

If Fluffy calls this a "brain damaged approach", I couldn't care less. He can apply his principles when he does Bible studies, there is no room for such principles in the real word.


Cheers
manolito

[StainlessS]

it is safe to assume that he just forgot to do the conversion explicitly

Yep, dont matter whether intentional or otherwise, the output IS gonna be Float (assuming it succeeds) so throwing error if input
not of type float is just a nuisance and of zero benefit at all, but will for sure break some scripts.

EDIT: I cannot think of any positive result coming from being pernickety here.

[raffriff42]

Yep, dont matter whether intentional or otherwise, the output IS gonna be Float (assuming it succeeds) so throwing error if input not of type float is just a nuisanceThis would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

EDIT correction, SuperEQ does not accept 16-bit.

[StainlessS]

OK, I accede to your wisdom [no need to look so smug about it Douglas] :)

You look so so smug in every single pic of you:- https://www.google.co.uk/search?q=&tbm=isch&tbs=rimg:CSJIstBG2cOwIjggUE5UMpFKMz0T4UmMLj0CfXMF0VZGVfdXxpr40SvOptEd_16D6Za4dHHg0W9c6hcnV1vfisq_1gsioSCSBQTlQykUozEW7zY36NY5E3KhIJPRPhSYwuPQIRSiX2oCo2BjAqEgl9cwXRVkZV9xFKRTZf8CfsGyoSCVfGmvjRK86mEctSbu_1_1iM_16KhIJ0R3_1oPplrh0RtshhNBBhseUqEgkceDRb1zqFyRFTSE4t9zOIVCoSCdXW9-Kyr-CyEeiwTK8XA2o2&tbo=u&sa=X&ved=0ahUKEwj667rz4fHUAhWKWhQKHaK5AakQ9C8IHw&biw=1280&bih=821&dpr=1

[tebasuna51]

This would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

Don't have sense for me.

SSRC, TimeStretch and SuperEQ need work internally with float samples, to accept other format need convert the input to float.

Like AviSynth support 8, 16, 24 and 32 bit int need the 4 conversions in each plugin. For what don't use the already exist conversions inside AviSynth?

And what do at end?

1) Reconvert the float to input precission?
Lossy conversion to 8 or 16 bits?
Upsample to 32 bits int?
Normalize if some peaks go over 0dB?
Thats need a lot of duplicated rutines in all plugins.

2) Or output the float samples?
That is also a problem, the user supply a format and recover other without notice.
It is not a good purist software.

The user must know the change like is informed when read:

"Audio is always converted to Float"

The "AVS+ no conversion is performed. Accepts 16-bit or Float audio (although Float is recommended)" behavior is usseless.
If audio is 8, 24 (frequently) or 32 bits int we need explicit conversion.

And, what is the output format?

[hello_hello]

This would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

I'm struggling with that one a little. Maybe I'm being dumb but why would you want SSRC or TimeStretch to support 16 bit input if they support 32 bit float and Avisynth always converts to float?

If you want bug-for-bug compatibility with Avisynth 2.5.8 until the heat death of the universe, then maybe what you want to use is... Avisynth 2.5.8? But then again, adding an explicit ConvertToFloat call is hardly back-breaking labor for any of you, now is it? In fact, I'd wager it's less work than downgrading to 2.5.8. I mean, yeah, it should be documented that it doesn't implicitly convert anymore, but the presence of implicit conversions has a far greater potential for Surprise and Confusion than removing them does. Yes I know you're used to the old behavior but that doesn't mean it's any less confusing for new users.

It's a bit over the top to describe what was obviously a design choice as a bug, and none of that tells me why the new way is better.

As a user I'd expect the lack of implicit conversion to mean the output will be the same as the input. Will that be the case if I use multiple plugins that accept 16 bit audio? For a 16 bit input will the audio be converted to float and back by each plug-in? Is there an argument to prevent that? ie SuperEQ(OutputConversion=false) or how does it work? I'm confused if not surprised.

Personally I think a better idea would be to keep the old method and have AVS+ automatically convert the output to the same format as the input as long as ConvertAudioTo() wasn't used in a script, although even then many lossy encoders accept 32 bit float, so it'd probably still require user input to prevent an unnecessary conversion at times.
Another method might be to always output the same format as the input when the audio isn't being processed, and to always output a particular format when it is..... oh..... wait a minute....

What's the worst that can result from an automatic conversion to float, which I don't think happens anyway unless the audio is being processed in some way. Sometimes having to add ConvertAudioTo() to a script?

[TheFluff]

It's a bit over the top to describe what was obviously a design choice as a bug
A bug is really no more than undesired or unintended behavior. If you change what is desired or intended (like Avs+ did) without changing the code, then you have (by definition) created a bug, which you can then fix. I called the OG Avisynth behavior a bug because I think the Avs+ intent is better, and that's all there is to it.

none of that tells me why the new way is better.
Is this really that hard to understand? At the very least it should be easy to see that it's inconsistent with everything else in Avisynth.

As a user I'd expect the lack of implicit conversion to mean the output will be the same as the input. Will that be the case if I use multiple plugins that accept 16 bit audio? For a 16 bit input will the audio be converted to float and back by each plug-in? Is there an argument to prevent that? ie SuperEQ(OutputConversion=false) or how does it work? I'm confused if not surprised.
In OG Avisynth, if you pass a 16-bit int audio clip to SSRC you will get a clip back with your new sample rate as desired, but it will also be converted to 32-bit float. It's kinda like if you called BicubicResize(1280,720) on a standard 8-bit YV12 clip but along with the resizing you also got your video upconverted to 16-bit YUV444. Which is fine if that's what you wanted, but it might not've been, and I certainly would not expect it.

If you pass 16-bit to SuperEQ in Avs+ I believe you will get 16-bit back.

Personally I think a better idea would be to keep the old method and have AVS+ automatically convert the output to the same format as the input as long as ConvertAudioTo() wasn't used in a script
This possibly the most backwards thing I've read in several months. You want two implicit conversions instead of one?

What's the worst that can result from an automatic conversion to float
If your input is 32-bit int you're gonna suffer a (usually meaningless) precision loss, because 32-bit float only has 24 bits of mantissa.

The problem here though isn't actually the conversion to float itself since nobody ever actually inputs anything but 16-bit int audio anyway, and upconverting that to float is relatively harmless. The problem is that it's directly opposite to what the video filters do (where nothing does implicit format conversion, for reasons that are apparently less hard to understand when it's video). There are even video filters that do temporary conversions to some special internal format for processing (see: Overlay) but even those do not come with an output conversion as a side effect. Consistency is nice, y'all.

[qyot27]

Just to put this in perspective, as well: the change in question occurred nearly four years ago. It was one of the earliest things that got committed to the nascent fork; I can't remember if the project had even accepted the 'AviSynth+' name yet, that's how old this is. And in all that time and now-89 pages of this thread, the 'no implicit conversion' behavior has been brought up only three or four times, and this latest time is the only one that's involved a heated back-and-forth.

Why do I think there's been an obvious silence on the issue?
A) After hearing the explanation for the change, users agreed that the new behavior is correct and adapted their scripts accordingly.
B) They weren't doing anything that would bring them into contact with the new behavior, because they were already working with float audio. WAVSource is the most likely place to hit this issue, because FFMS2 and LSMASHSource both output whatever libavcodec's decoder for the audio format decodes to. Which in the case of AAC (and who knows what other common formats*), is single precision float, not int. So users just didn't see it, because there was nothing for SSRC to complain about.

*MP3 still decoded to 16-bit integer the last time I checked, but that was a few months ago. I've not checked most of the other ones I come across more often, because I usually don't use those inside video files.

[hello_hello]

A bug is really no more than undesired or unintended behavior. If you change what is desired or intended (like Avs+ did) without changing the code, then you have (by definition) created a bug, which you can then fix. I called the OG Avisynth behavior a bug because I think the Avs+ intent is better, and that's all there is to it.

I think you'd have to be fairly self absorbed to equate changing a default behaviour to fixing a bug simply because the new behaviour is your personal preference.
If I add ConvertAudioToFloat() to a script am I introducing a bug or changing the default behaviour?.

Is this really that hard to understand? At the very least it should be easy to see that it's inconsistent with everything else in Avisynth.

Not really, because the video analogy doesn't work for me. There's a huge difference between changing audio bitdepth and changing video format.

In OG Avisynth, if you pass a 16-bit int audio clip to SSRC you will get a clip back with your new sample rate as desired, but it will also be converted to 32-bit float. It's kinda like if you called BicubicResize(1280,720) on a standard 8-bit YV12 clip but along with the resizing you also got your video upconverted to 16-bit YUV444.

You're not feeding a plugin PCM and having it output DSD.
It might be like resizing a standard 8 bit YV12 clip and having the resizer output 16 bit YV12 (or P016 or whatever it's called).

If you pass 16-bit to SuperEQ in Avs+ I believe you will get 16-bit back.

This possibly the most backwards thing I've read in several months. You want two implicit conversions instead of one?

If super EQ converts to 16 bit float internally, please explain the difference. I only suggested two implicit conversions, one to float if the audio is being processed and one back to the original format for the final output unless I specify something else, but do you really want every plugin to be doing it?

If your input is 32-bit int you're gonna suffer a (usually meaningless) precision loss, because 32-bit float only has 24 bits of mantissa.

If the audio is going in and out without being processed nothing is converted. If it is, how many plugins/filters wouldn't require a conversion to 32 bit float?

The problem here though isn't actually the conversion to float itself since nobody ever actually inputs anything but 16-bit int audio anyway, and upconverting that to float is relatively harmless.

I might find myself disputing that because I assumed most decoders would decode lossy audio to float or the highest bitdepth possible, so unless you're converting everything to 16 bit wave files first.....
I'm a GUI kind of guy and I actually don't use Avisynth for processing audio much, but Avisynth says this is 16 bit:

LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll")
RaWavSource("D:\audio.wav")

And this is 32 bit:

LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll")
NicMPG123Source("D:\audio.mp3")

The problem is that it's directly opposite to what the video filters do (where nothing does implicit format conversion, for reasons that are apparently less hard to understand when it's video). There are even video filters that do temporary conversions to some special internal format for processing (see: Overlay) but even those do not come with an output conversion as a side effect. Consistency is nice, y'all.

I'm the first to complain about inconstancy, but I can distinguish between a change of format and a change of bitdepth.

It just seems logical to me. Once you move up in bitdepth, you stay there till the bitter end or as long as possible, whichever comes first. If a plugin is going to move you up in bitdepth, it doesn't seem an issue to me if it's expected behaviour, and I assume all audio filters/plugins do for AVS? Having to manually convert to float at the beginning and back to integer at the end of a script to prevent a succession of filters up-converting and down-converting doesn't seem like a better idea.

I have no idea how high bitdpeth video processing works for AVS+. I've only had experience with the AVS hack, and there manually specifying bitdepth changes is unavoidable, but in a high bitdepth environment if it's upconverted once wouldn't you want to keep it that way until the final output?

[wonkey_monkey]

Okay, so... is SSRC like an internalised plugin that comes with AviSynth, right? And was it Avisynth itself which was making a special case out of it by looking out for calls to SSRC and converting audio to float beforehand? Or was it in the internal version of SSRC itself which was converting audio?

[raffriff42]

SSRC, TimeStretch and SuperEQ need work internally with float samples, to accept other format need convert the input to float.There is a bug in SuperEQ that I missed:
As tebasuna51 points out, SuperEQ works with float samples only, but unlike SSRC and TimeStretch, does not check the input sample type -- and crashes with non-Float input. Tested w/ r2489, r2506.

So SuperEQ does not actually accept 16-bit. Not sure how my 16-bit test didn't fail before (I have a clue though)

EDITwas it Avisynth itself which was making a special case out of it by looking out for calls to SSRC and converting audio to float beforehand? Yes (ssrc-convert.cpp line 56)

[tebasuna51]

Just to put this in perspective, as well: the change in question occurred nearly four years ago. It was one of the earliest things that got committed to the nascent fork; I can't remember if the project had even accepted the 'AviSynth+' name yet, that's how old this is. And in all that time and now-89 pages of this thread, the 'no implicit conversion' behavior has been brought up only three or four times, and this latest time is the only one that's involved a heated back-and-forth.

Why do I think there's been an obvious silence on the issue?
A) After hearing the explanation for the change, users agreed that the new behavior is correct and adapted their scripts accordingly.
I'm a new Avs+ user and is the first time I know the change after read Avs+ docs.

B) They weren't doing anything that would bring them into contact with the new behavior, because they were already working with float audio. WAVSource is the most likely place to hit this issue, because FFMS2 and LSMASHSource both output whatever libavcodec's decoder for the audio format decodes to. Which in the case of AAC (and who knows what other common formats*), is single precision float, not int. So users just didn't see it, because there was nothing for SSRC to complain about.

Yes, all (or most of them) lossy decoders output float samples without issues with SSRC.

The problem is with lossless decoders (FLAC, DTS-MA, TrueHD, ... or WAV input) most the times with 24 bit int samples.
Even is not normal need a SSRC over these sources.

I detected the behavior change (I was thinking a bug) when a user try a SSRC(48000) over a already 48000 source and MeGUI crash.

At least I hope than first verify if the resample is needed before than send the format error.

[raffriff42]

At least I hope than first verify if the resample is needed before than send the format error.Actually it does not!
https://github.com/pinterf/AviSynthPlus/blob/master/plugins/Shibatch/ssrc-convert.cpp#L175

[Zathor]

I am using r2508 (32bit) with an 10-bit input file and FFMS2 2.23.1 and getting an error:
ConvertToRGB: conversion is allowed only from 8 bit colorspace


source = "C:\TEMP\bug_890\clip10s.avi"
LoadPlugin("D:\MEGUI\tools\ffms\ffms2.dll")
V = FFVideoSource(source, fpsnum=30, fpsden=1, threads=1).Lanczos4Resize(1280, 720)
A1 = FFAudioSource(source, track=1).AmplifyDB(10) #.Normalize(volume=1.0, show=false)
A2 = FFAudioSource(source, track=2).Normalize(volume=1.0, show=false)
commentary = MonoToStereo(A1, A1) #.AmplifyDB(1.5)
audio = MixAudio(commentary, A2, 0.9, 0.1)
AudioDub(V, audio)
return last

The strange thing is I had the error from the beginning with this sources and then I played a bit with it (to narrow down which function is returning the error) till it vanished. And now also the exact same avs from the beginning does not throw the error anymore. While the error was there VirtualDub with AVS 2.6 (vanilla) did not throw this error.

Another user reported a similar thing:
https://sourceforge.net/p/megui/bugs/888/

Any thoughts what may causing this?

[sneaker_ger]

Vanilla AviSynth does not support >8 bit natively so ffms2 dithers down to 8 bit automatically. Then there's no error, of course. High bitdepth was only added in ffms2 2.23.1. So if you have older version or different source filter it will probably not happen either. (VirtualDub won't add ConvertToRGB() which I think is a MeGUI "feature". But VfW support for high bitdepth YUV ... ).

[raffriff42]

ConvertToRGB: conversion is allowed only from 8 bit colorspaceRGB24 & RGB32 are 8bit only in AviSynthPlus. For >8bit (high bit depth) RGB processing, you normally use:## source=YUV
ConvertBits(16) ## bits=10,12,14,16,32 (always upconvert bits *before* RGB<>YUV conversion)
ConvertToPlanarRGBA (http://avisynth.nl/index.php/Convert#RGB_planar)(matrix="Rec709")
Most >8bit RGB formats are planar (http://avisynth.nl/index.php/Planar).

If you need >8bit interleaved (http://avisynth.nl/index.php/Interleaved), you have 16bit RGB48 and RGB64:## source=YUV
ConvertBits(16)
ConvertToRGB64 (http://avisynth.nl/index.php/Convert#RGB_interleaved)(matrix="Rec709")

If you want to downconvert to 8bit RGB, use:
ConvertBits(8, dither (http://avisynth.nl/index.php/ConvertBits#dither)=0) ## (dither is optional)
ConvertToRGB32

[ajp_anton]

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.

[tebasuna51]

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.

No problem, seems the audio AviSynth behaviour is don't know very well.

AviSynth always downconvert float audio to 16 int at output.

Unless you use (v2.57):

global OPT_AllowFloatAudio=True

The users than add this global variable know very well than SSRC always convert audio to float.

Using MeGUI or BeHappy is not needed that
global OPT_AllowFloatAudio=True
because a special interface with AviSynth: AvisynthWrapper.dll

But MeGUI/BeHappy always convert the output samples to the best precission suported by the encoder than go after.
The users don't need care about it.

-----------------------------

I can accept a diferent behaviour betwen AViSynth and Avs+ but the first improvement than audio management need is:

Replace the audio property nchannels by maskchannels.
In AviSynth.h instead:

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int nchannels; // as of 2.5

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int maskchannels; // New

where nchannels can be calculated easily with maskchannels.
Now decoders, than know maskchannels, can pass that value to AviSynth.

[qyot27]

No problem, seems the audio AviSynth behaviour is don't know very well.

AviSynth always downconvert float audio to 16 int at output.

Unless you use (v2.57):

global OPT_AllowFloatAudio=True
It only downconverts to 16-bit automatically or require OPT_AllowFloatAudio when serving through ACM. The docs need to be updated to be more precise about that.

>cat test.avs
ColorBars()

>ffmpeg -i test.avs
ffmpeg version r86337 git-39c8e0dd8e Copyright (c) 2000-2017 the FFmpeg developers
built on May 31 2017 19:37:35 with gcc 7.1.0 (GCC)
libavutil 55. 63.100 / 55. 63.100
libavcodec 57. 96.101 / 57. 96.101
libavformat 57. 72.101 / 57. 72.101
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 90.100 / 6. 90.100
libavresample 3. 6. 0 / 3. 6. 0
libswscale 4. 7.101 / 4. 7.101
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test.avs':
Duration: 01:00:00.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 640x480, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
At least one output file must be specified
This is true of classic AviSynth 2.6 as well as AviSynth+.

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.
Already exists:
http://avisynth.nl/index.php/AviSynth%2B#Logging_Facility

But it still depends on the filter/plugin emitting those warnings and other informational messages, which almost nothing does because it wasn't historically possible to do this.

[tebasuna51]

It only downconverts to 16-bit automatically or require OPT_AllowFloatAudio when serving through ACM. The docs need to be updated to be more precise about that.

Like was designed AviSynth initially. You still can see the behaviour with VirtualDub, wavi, ...

The question here is:

A automatic conversion to float is not a problem, if serving through ACM there are a downconvert to 16 int, other modern soft like MeGUI, BeHappy, ffmpeg, avs2pipemod, ... can manage float samples without lose precission downconverting the samples to initial format.

[Zathor]

RGB24 & RGB32 are 8bit only in AviSynthPlus.

Thank you very much. MeGUI - or to be more specific the AvISynthWrapper.dll - does a
res = pstr->env->Invoke("ConvertToRGB24", AVSValue(&res, 1));
for each script which will be serviced within MeGUI. This has been done way before my time so I had to search a bit. I assume the reason is that then the function to return a single video frame bitmap returns something which can be easily used in MeGUI:
PVideoFrame f = pstr->clp->GetFrame(frm, pstr->env);
if (buf && stride)
{
pstr->env->BitBlt((BYTE*)buf, stride, f->GetReadPtr(), f->GetPitch(), f->GetRowSize(), f->GetHeight());
}

[LigH]

As just an AviSynth user, not a developer, I care little about whether audio gets converted to float samples implicitly for filters which need that; I just need this feature to be both reliable and well documented, and optimally with verbose and specific enough error messages if my script doesn't fulfill the requirements. As already said: I am used to be forced to adapt existing scripts upon updates in a much worse way by PHP. How bad can it get with AviSynth, knowing that you developers out there care so much about us users?

[qyot27]

Like was designed AviSynth initially. You still can see the behaviour with VirtualDub, wavi, ...
Like I said, ACM. But that is not 'default' behavior, it's just a compatibility hack for a Microsoft media framework because IanB didn't want to start throwing WAVE_FORMAT_IEEE_FLOAT around back then due to a presumed lack of support for float audio in receiving programs (in 2017 this should now be a minority, even if it was true in 2006); just because ACM access was the most likely way of a program accessing AviSynth 10+ years ago is irrelevant when not only is it now a lot more common for programs to talk to the library directly without the ACM go-between, but it honestly wouldn't surprise me if Microsoft phases out ACM entirely at some point.

It has nothing to do at all with how AviSynth as a library behaves (or any media library behaves), and I'm certain that's why anything using direct access to AviSynth as a regular library is not subject to this and never has been.

A automatic conversion to float is not a problem, if serving through ACM there are a downconvert to 16 int, other modern soft like MeGUI, BeHappy, ffmpeg, avs2pipemod, ... can manage float samples without lose precission downconverting the samples to initial format.
So suddenly start forcing modern software that access AviSynth directly to invoke a pointless downconversion with inherent rounding errors just to satisfy people that want it to behave like ACM is sitting between them when it isn't?

FFmpeg is likely going to be that standard bearer now, considering the number of media software projects that utilize libavformat for their file format support, and so anything that uses libavformat potentially has access to AviSynth. FFmpeg will automatically reject any patch that introduces a downconversion like that, guaranteed.

[tebasuna51]

So suddenly start forcing modern software that access AviSynth directly to invoke a pointless downconversion with inherent rounding errors just to satisfy people that want it to behave like ACM is sitting between them when it isn't

Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.

And, for what introduce a problem when is clear in AviSynth docs?

"Audio is always converted to Float"

Point.

[qyot27]

Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.
Then you're at a fundamental disagreement with AviSynth+. The idea that users should be ignorant of format changes being done without their explicit consent is flatly and absolutely rejected. It's been like that from the start.

The output behavior isn't something AviSynth+ did, all I did was point out that OPT_AllowFloatAudio and the downconvert were not absolute. If I had my druthers, we'd do away with OPT_AllowFloatAudio entirely so that ACM behavior matches direct library access. In 2017 most programs should not have issues taking Float audio, and in the rare case one does, that should be the user's responsibility to make the script comply with it, not make the correct behavior an opt-in because some vague notion of undisclosed program names 10 years ago maybe couldn't handle Float audio.

Direct library access is the proper and preferred method to use AviSynth (explicitly so for AviSynth+, but classic AviSynth had been moving in that direction for years). It's not a bug that direct library access has only ever output the final processed format rather than forcing a downconversion. The docs not being clear about that isn't AviSynth+'s fault.

[hello_hello]

What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?

http://avisynth.nl/index.php/Amplify
"8bit and 24bit audio is converted to float; the other audio formats are kept as they are."

Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?

When it comes to audio bit depth, I'm not sure I'd care about converting to a higher bitdepth automatically. You don't lose quality, and a higher bit depth output generally wouldn't be a problem. If the output is being converted to a lossy format and float is acceptable, (why is LAME still limited to 24 bit?) the user gets to be ignorant of no harm having been done.
If AVS did convert to float when a filter needed it, there's a possibility user intervention would be being required at the output stage rather than prior to the filter, but if it doesn't, user intervention is required each time a similar filter is used.
.
Automatically converting video from one type to another is one thing, but I'm not sure converting "type" and converting "bit depth" necessarily have to follow the same rules. If I was ruler of the world, the law would require the same bit depth in and out when there's no processing involved, and float when there is, as all filters would be required to accept float.

How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?

[qyot27]

What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?
When a filter is written, the formats it supports are based on how the methodology of the algorithm it uses to do the processing was written. Fixed-point (integer) math is often fastest, especially because there's a lot more useful SIMD instructions designed for fixed-point than there are for floating point. This is true for audio or video filters.

Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?
No, the filter doesn't support processing in 8 or 24 bit, so it converts the file's depth in order to process in 16 bit. Some filters support both 16 bit or Float, in which case it probably prefers 16 bit if the file is already integer, but keeps it in Float if it was Float. Most of the audio filters in the core support all the formats, which implies there are codepaths for each format to be processed natively.

How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?
Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.

[Wilbert]

@qyot27, i changed the online documentation to reflect the actual behaviour.

[hello_hello]

Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.

So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.

On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?

Thanks.

[qyot27]

So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.
That...depends. Supersampling is generally understood more in the vein of 'resize up, filter at the higher resolution, then resize back down', but that's staying inside of the same bit depth. Running filters on high bit depth input might provide a smoother gradient scale, and you might be able to retain *some* of that when you dither back down to 8 bit and use a lossy encoder on it, but it may also be possible to get similar results without processing it in >8bit. That's why the LSB hack is typically intended to be input to programs that can stitch it back into a proper high bit depth stream, since at least then it can keep the same >8bit gradient scale.

There's also the question of how much CPU and memory all of that would eat and whether whatever benefit you do end up seeing is worth it, or whether keeping it all in the same bit depth is faster for the same general perceptual quality (and a lot of that is naturally subjective).

On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?
The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know. Also whether you'd even need to worry about clipping, depending on what filter(s) you're using.

If there's no obvious difference in quality, whichever is faster.
If neither is distinctly faster, use what the encoder you're giving it to supports.

Regarding the encoder part, if you're dealing with something like ffmpeg, ffmpeg as a command line program is distinct from the libavcodec encoders you'd be feeding the stream to. For instance, with MP3: LAME supports multiple formats including 16-bit integer, 32-bit integer, and float, whereas libshine only supports 16-bit integer. So optimally, even though ffmpeg has no problems opening float audio (and will perform the conversion prior to handing it to the encoder), if you wanted to encode with libshine, it would be more streamlined to output 16-bit int from AviSynth, so ffmpeg wouldn't have to convert it first. But if you were going to use LAME, you could use any of the three formats it allows.

@qyot27, i changed the online documentation to reflect the actual behaviour.
Thanks.

[hello_hello]

qyot27,
Thanks for the info.

Previously when I asked why LAME is still limited to 24 bit, I appear to have put myself in the completely wrong category.

When foobar2000 creates a LAME encoder preset itself, it sets 24 as the maximum input bit depth, and I would've bet copious amounts of money I'd tested that, but I tried setting the maximum input bitdepth to 32 (which I assume is always float for foobar2000) and had no problem encoding with LAME. I'll have to ask about it in the foobar2000 forum.
(Edit: I asked and apparently 32 bit float support was added to LAME with version 3.99)

Thanks for the info regarding high bitdepth processing of 8 bitdepth video. As processing in 16 bit is very slow using my old PC and I'd not seen much visible benefit compared to 8 bit, or realistically any benefit at all most of the time, I've not bothered filtering in 16 bit. I'd assumed "technically" it'd still be better, even if in practice it often appears not to be.

So I guess "preventing clipping" would be the only remaining argument for always converting audio to float for processing, especially when multiple filters are daisy-chained. I assume that's why foobar2000 always converts to float when a DSP is used, which seems reasonable (at least that's my understanding).
I'd be close to admitting I was wrong when it comes to the implicit vs explicit conversion of bit depth, except for the possibility of clipping avoidance. To my way of thinking if converting to float prevents it, it should be prevented, and if a filter is capable of inducing clipping, processing the audio in anything but float seems like a bad idea, and therefore accepting anything but float as the input would also be less good.
It doesn't eliminate the need for checking for clipping at the output stage, but at least you don't have to worry about it until then.

Cheers.

[tebasuna51]

The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know.

Float values can't have clipping because support volume values over 0dB, the clip occurs when are converted to int samples and any value over 0dB are truncated.

Precission of float 32 values is equivalent (more or less) to 24 bit int because 32 float have 24 bits for mantissa (+ 8 for exponent).
Downsample to 16 bits int lose precission, and the average human ear can distinguish up to 20-bit differences.

Math operations must be do always in float format to preserve precission even with low values.
Int maths:
(3/2)x2 = 2
float maths:
(3.0/2.0)x2.0= 3.0

[pinterf]

Thanks for pointing to the source. And what's the logic that makes a 10bit LUT use the same memory as a 16bit LUT? Is it because of the "garbage" (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L199) mentioned here? (Garbage means that the most significant bits aren't necessarily zero, although they should be, or?)
And because IsYUV is true for Y8-Y16, line 193 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L193) and line 203 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L203) imply that a chroma LUT is created for monochrome formats.
Yes, because of the possible garbage.
Anyway, Levels was among the first filters that was ported and the code is probably a bit messy and not finished (float support).
Nor did I benchmark that a safety check on over-10-bits garbage before applying LUT (and thus allowing smaller 10 bit LUT tables) has any significant effect on execution time. Sure, Levels is on my todo list.

[wonkey_monkey]

Just out of curiousity, if this okay to ask here - as a quick straw poll, which would people prefer vis a vis Avisynth+: existing plugins updated to x64, or existing plugins updated to handle the new colourspaces?

[DJATOM]

x64 ports preferred. Although I'd like to have eedi3 with 16-bit and AVX2 support.

[burfadel]

x64 ports would be a lot more useful. I guess in general, and especially looking forward, colourspace support is irrelevant if you can't use the 32-bit filter in your 64-bit script.

[Reel.Deel]

x64 ports preferred. Although I'd like to have eedi3 with 16-bit and AVX2 support.

Ditto, according to cretindesalpes eedi3 is 16-bit ready. This has been the case since late 2013.


The SSE2 code is 16-bit ready, although the glue code to pass stack16 clips hasn’t been implemented yet. It will probably come in a next update.

[qyot27]

At least judging by the changes made to AviSynth+ itself in order to work on 64-bit, doing so would generally make the code more portable and easier to maintain, which is always a good thing. All the new pixel formats are much more purpose-oriented, and adding them after doing the work to make the plugins 64-bit compatible would be more efficient.

[Metal]

New release with TemporalSoften fix.
Thanks to Sharc for the report (https://forum.doom9.org/showthread.php?p=1810075#post1810075).

Download Avisynth+ r2508-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2508-MT)

20170629 r2508
- Fix TemporalSoften: threshold < 255 (bug exists probably since r1576)

Hello

I have a problem, could you please help me solve it?
When ever I try to install any Avisynth + other than version r1576 i get this error message http://imgur.com/1xkIhGL
I tried to locate the folder, but it didn't work even when I installed r2294 I got the same error!

[LigH]

Do you possibly mix up 64 bit DLL and 32 bit system folder? Which Windows version do you have? Which file manager do you use? (If it's anything else than Windows Explorer: A 32-bit version of a custom file manager won't have access to the 64-bit system area.) In general: More facts! More details! More quotes of error messages!

P.S.: I guess it's time to build a recent installer again. Moving DLL's manually into sensitive areas is not everyone's favourite challenge. The Avisynth Universal Installer (https://forum.doom9.org/showthread.php?t=172124) (run "as Administrator") would be a helpful alternative; unfortunately you have to edit it correctly to maintain plugin paths, or possibly copy all your plugins around, so it's not really straightforward and easy-to-use either for people with less experience. Handling paths with spaces and even parentheses is tricky in Batch.

[Metal]

Do you possibly mix up 64 bit DLL and 32 bit system folder? Which Windows version do you have? Which file manager do you use? (If it's anything else than Windows Explorer: A 32-bit version of a custom file manager won't have access to the 64-bit system area.) In general: More facts! More details! More quotes of error messages!

No, I checked again and again I followed the instructions very well, but it didn't work!
Even with a normal installer by Groucho2004 which I got from here: http://avisynth.nl/index.php/Avisynthplus/Downloads
won't work :( only r1576 works.
I'm on windows server 2012 64-bit and I'm using windows explorer.

[LigH]

Then, next steps: download and unpack AVSMeter (https://forum.doom9.org/showthread.php?t=173259&highlight=avsmeter), and check

AVSMeter.exe -avsinfo
AVSMeter64.exe -avsinfo
AVSMeter.exe yourscript.avs
AVSMeter64.exe yourscript.avs

for error messages. I guess "the specified module" which is missing may be the Microsoft Visual C++ Runtime in the required version.

[Metal]

Then, next steps: download and unpack AVSMeter (https://forum.doom9.org/showthread.php?t=173259&highlight=avsmeter), and check

AVSMeter.exe -avsinfo
AVSMeter64.exe -avsinfo
AVSMeter.exe yourscript.avs
AVSMeter64.exe yourscript.avs

for error messages. I guess "the specified module" which is missing may be the Microsoft Visual C++ Runtime in the required version.

Yes!!! Finally!!!
Thank you so much LigH, I updated the Microsoft Visual C++ Runtime and it worked.

[edcrfv94]

Maybe auto one processes for each C/C++ filter(auto switch 32bit if 64bit not available) and auto adjustment prefetch and keep frames cache, can temporarily solve the multi-threaded problem until a new method appears.


colorbars(width = 1920, height = 1080, pixel_type = "yv12")

src = last
mcdn = src.kf_MCDegrainN(clip c, int "tr")

rfs(src, mcdn, mappings="[1000 2000] [3000 4000]") #Remap Frames

function kf_MCDegrainN(clip c, int "tr")
{

tr = default(tr, 6)

super = MSuper(levels=0)

multi_vec = MAnalyse(super, multi=true, delta=tr)

c.MDeGrainN(super, multi_vec, tr)

return last
}



colorbars(width = 1920, height = 1080, pixel_type = "yv12")

src = last

#1 processes prefetch 16 keep 14
#export last, src
#pass

mcdn = src.kf_MCDegrainN(clip c, int "tr")
function kf_MCDegrainN(clip c, int "tr")
{

tr = default(tr, 6)

super = MSuper(levels=0)
#2 processes prefetch 14 keep 12
#export super
#pass last, c

multi_vec = MAnalyse(super, multi=true, delta=tr)
#3 processes prefetch 12 keep 10
#export multi_vec
#pass last, c, super

c.MDeGrainN(super, multi_vec, tr)
#4 processes prefetch 10 keep 8
#export last
#pass

return last
}

rfs(src, mcdn, mappings="[1000 2000] [3000 4000]") #Remap Frames
#5 processes prefetch 8 keep 6
#export last


MP_Pipeline cann't pass audio, just for example.

MP_Pipeline("""

SetMemoryMax(500)

colorbars(width = 1920, height = 1080, pixel_type = "yv12")
src = last

### export clip:src
### prefetch: 14,12
### ###

SetMemoryMax(500)

c = src
super = MSuper(levels=0)

### export clip:c, super
### pass clip:src
### prefetch: 12,10
### ###

SetMemoryMax(500)

multi_vec = MAnalyse(super, multi=true, delta=tr)

### export clip:multi_vec
### pass clip:src, c, super
### prefetch: 10,8
### ###

SetMemoryMax(500)

mcdn = c.MDeGrainN(super, multi_vec, tr)

### export clip:mcdn
### pass clip:src
### prefetch: 8,6
### ###

SetMemoryMax(500)

rfs(src, mcdn, mappings="[1000 2000] [3000 4000]") #Remap Frames

""")

[real.finder]

MP_Pipeline cann't pass audio, just for example.


yes, Unfortunately

I wish someone did these changes https://github.com/SAPikachu/MP_Pipeline/issues/1#issuecomment-269108878

[real.finder]

hi pinterf

when you back can you check this (https://forum.doom9.org/showpost.php?p=1714618&postcount=1045), I didn't note it before since I use mpp(MP_Pipeline) most of the time and by using mpp it seems to work!

edit: this one too https://forum.doom9.org/showpost.php?p=1789860&postcount=2709 since you will touch the autoload things

edit2: this one too https://forum.doom9.org/showthread.php?p=1814912#post1814912

[junh1024]

Really, how hard is it 2 make SSRC accept int16 in? Most of the audio tools (DAWs, VSTs, outside of avs) I use happily do format/bitdepth conversions silently.

[fenarinarsa]

Hello everyone,

Since AVS+ 2502 the AddAutoLoadDir behavior changed.

Before this version, I could add 32bits and 64 bits DLLs (in two different folders) and AviSynth would load the correct ones depending on the environment it's working on. Because I currently must use an old x86 software and ffmpeg x64 at the same time from the same script.

Now it fires an error (cannot load DLL...) and stops there.

That a real issue for me since I generate an AVS+ script that should work in 32bits *and* 64bits and that I don't use the AVS+ default plugins dir (we have in-house developments).

In other word, this change in behavior breaks everything that was working quite well until now :)

I looked for a way of having conditionnal loading, but I couldn't find a variable that returns the current environment. Another way would be to add an optional argument to AddAutoLoadDir like "errors=false".

Am I missing something there ?


BTW I'm the technical director of a cable/DSL French TV channel and we've been using AviSynth and AVS+ for 9 years to generate our on-air & VOD/catch-up video graphics :)
I must say you're doing an awesome work. Last year I was thinking about ditching AVS because we had a lot of issues relating to memory management, HD, ffmpeg and QuickTime, but AVS+ saved it :)
demo => http://www.youtube.com/watch?v=ZbHMMxTcgec

[Groucho2004]

Since AVS+ 2502 the AddAutoLoadDir behavior changed.

Before this version, I could add 32bits and 64 bits DLLs (in two different folders) and AviSynth would load the correct ones depending on the environment it's working on. Because I currently must use an old x86 software and ffmpeg x64 at the same time from the same script.
I guess you can blame me (https://forum.doom9.org/showthread.php?p=1808210#post1808210) for this since I suggested to pinterf to add a check for the correct bitness of plugins in the auto-load directories.
A possible solution for this could be to modify the AddAutoLoadDir() functionality so the bitness check is omitted on the script level. This way, only the "hard coded" auto-load directories to which the registry entries point will be checked.

[pinterf]

I looked for a way of having conditionnal loading, but I couldn't find a variable that returns the current environment. Another way would be to add an optional argument to AddAutoLoadDir like "errors=false".

Am I missing something there ?


Sorry for the inconvenience.

From version r2487 there is a new script function:

int GetProcessInfo([int type = 0])
Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
With type=1 the function can return a bit more detailed info:
-1: error, can't establish
0: 32 bit DLL on 32 bit OS
1: 32 bit DLL on 64 bit OS (WoW64 process)
2: 64 bit DLL

Usage:
LoadPlugin(GetProcessInfo == 32 ? "This32.dll" : "This64.dll")

[Groucho2004]

Usage:
LoadPlugin(GetProcessInfo == 32 ? "This32.dll" : "This64.dll")I don't think this is exactly what he's looking for, he want's to use auto-load. However, something like this maybe:
(GetProcessInfo == 32) ? AddAutoLoadDir("32BitplugsDir") : AddAutoLoadDir("64BitplugsDir")

[fenarinarsa]

I don't think this is exactly what he's looking for, he want's to use auto-load. However, something like this maybe:
(GetProcessInfo == 32) ? AddAutoLoadDir("32BitplugsDir") : AddAutoLoadDir("64BitplugsDir")


Thanks a lot! That's what I was looking for.
I read a few months ago that a function to return the bitness was added, but I couldn't find it in the documentation.

So it works now, time to deploy r2508 :D

BTW I still didn't activate MT because I found some bugs. I suppose I can do bug reports here ? (it usually takes time because I do full reports with sample files)

[pinterf]

Yes, we all like well documented bug reports :) Thanks.

[tebasuna51]

Last OT posts moved to https://forum.doom9.org/showthread.php?t=174847

[Atak_Snajpera]

I must be doing something wrong because I don't see any change with or without Prefetch(8). Speed,number of threads and memory consumption is identical.

script
#MT
Import("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Scripts\MTmodes.avs")

#VideoSource

video=DirectShowSource("E:\_Video_Samples\mkv\drive_video_10min.mkv",audio=false).ConvertToYV12(matrix="rec709")

#Crop
video=Crop(video,0,140,-0,-140)


#Denoise
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)

return video

prefetch(8)

AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 14751
Length (hh:mm:ss.ms): 00:10:15.117
Frame width: 1920
Frame height: 800
Framerate: 23.981 (10000/417)
Colorspace: YV12

Frame (current | last): 144 | 14750
FPS (cur | min | max | avg): 1.985 | 1.946 | 4.142 | 2.407
Memory usage (phys | virt): 287 | 336 MiB
Thread count: 37
CPU usage (current | average): 8% | 6%

Time (elapsed | estimated): 00:01:00.231 | 01:42:07.361

without prefetch

AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 14751
Length (hh:mm:ss.ms): 00:10:15.117
Frame width: 1920
Frame height: 800
Framerate: 23.981 (10000/417)
Colorspace: YV12

Frame (current | last): 144 | 14750
FPS (cur | min | max | avg): 1.981 | 1.945 | 4.097 | 2.401
Memory usage (phys | virt): 287 | 336 MiB
Thread count: 37
CPU usage (current | average): 7% | 6%

Time (elapsed | estimated): 00:01:00.384 | 01:42:22.926

[TheFluff]

You have "return video" above prefetch in the filter chain. I think prefetch actually kinda is a pseudo-filter of its own, so it might matter - not sure though.

[Atak_Snajpera]

I think prefetch actually kinda is a pseudo-filter of its own, so it might matter - not sure though.
Yes! You are right! Prefetch acts like filter so this works now

#MT
Import("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Scripts\MTmodes.avs")

#VideoSource

video=DirectShowSource("E:\_Video_Samples\mkv\drive_video_10min.mkv",audio=false).ConvertToYV12(matrix="rec709")

#Crop
video=Crop(video,0,140,-0,-140)


#Denoise
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)

video=prefetch(video,8)
return video

[Groucho2004]

@Mod
Posts #3576 and onwards should be moved to the fft3dfilter thread (https://forum.doom9.org/showthread.php?t=174347).

[tebasuna51]

Posts moved.

[MysteryX]

With the latest version of Avisynth+, I'm still unable to open script files names containing international character in MPC-HC; but the same files open fine in VirtualDub.

I thought this had been solved? Here's an example of file name: おどるポンポコリン.mp4

[Groucho2004]

With the latest version of Avisynth+, I'm still unable to open script files names containing international character in MPC-HC; but the same files open fine in VirtualDub.

I thought this had been solved? Here's an example of file name: おどるポンポコリン.mp4Not sure why your example has a .mp4 extension but opening a script "おどるポンポコリン.avs" works fine in mpc-hc even without switching the locale to Japanese. This is on XP.

[Atak_Snajpera]

Source: 3840x2160 AVC
CPU: E5-2690 (8C/16T)
RAM: 64 GiB
OS: Win7 x64
Avisynth+: r2508 x86
#MT
Import("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\Scripts\MTmodes.avs")

#VideoSource
video=DirectShowSource("E:\_Video_Samples\mp4\UHD_0035.MP4",audio=false).ConvertToYV12(matrix="rec709")

#Resize
video=Spline36Resize(video,1920,1080).Sharpen(0.2)

#Denoise
Loadplugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
fv2=MAnalyse(super,isb=false,delta=2,overlap=4)
bv2=MAnalyse(super,isb=true,delta=2,overlap=4)
video=MDegrain2(video,super,bv1,fv1,bv2,fv2,thSAD=400)

#Prefetch
video=Prefetch(video,X)

#Return
return video


I wonder why performance drops so heavily when process uses more than 2000 MiB of memory?

8 Threads
AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.581 | 472300 | 10.53
Memory usage (phys | virt): 1609 | 1800 MiB
Thread count: 45
CPU usage (average): 52%

Time (elapsed): 00:00:39.880
-------------------------------------------------------
14 Threads
AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.181 | 566759 | 12.38
Memory usage (phys | virt): 1784 | 1984 MiB
Thread count: 51
CPU usage (average): 89%

Time (elapsed): 00:00:33.925
-------------------------------------------------------
15 Threads
AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.196 | 472300 | 7.495
Memory usage (phys | virt): 1826 | 2016 MiB
Thread count: 52
CPU usage (average): 57%

Time (elapsed): 00:00:56.034
-------------------------------------------------------
16 Threads
AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.170 | 566760 | 6.253
Memory usage (phys | virt): 1850 | 2045 MiB
Thread count: 53
CPU usage (average): 39%

Time (elapsed): 00:01:07.169

[StainlessS]

Atak_Snajpera,

What happens if you get virtual memory use over 2048MiB ?

[MysteryX]

Not sure why your example has a .mp4 extension but opening a script "おどるポンポコリン.avs" works fine in mpc-hc even without switching the locale to Japanese. This is on XP.
Sorry I meant "おどるポンポコリン.avs" :) I'm using Windows 10 x64. Anything I could look for to debug the issue?

[Groucho2004]

Sorry I meant "おどるポンポコリン.avs" :) I'm using Windows 10 x64. Anything I could look for to debug the issue?Maybe this (https://en.wikipedia.org/wiki/Help:Multilingual_support_(East_Asian)#Windows_10) could be the problem?

Edit: Alternatively, change the system locale to Japanese and check if you still can't load the file in mpc-hc.

[Atak_Snajpera]

Atak_Snajpera,

What happens if you get virtual memory use over 2048MiB ?

Speed progressively drops after 2000 MiB mark. AVS meter silently crashes or terminates around 3.5 GiB (around 32 bit memory limit) . Speed drops to 0.5 fps before silent crash.

[StainlessS]

I've always thought that there was something not quite right with either avs or windows use of pagefile (dont know which).

EDIT: What do the 'big guns' think could be wrong ?

[Groucho2004]

Speed progressively drops after 2000 MiB mark. AVS meter silently crashes or terminates around 3.5 GiB (around 32 bit memory limit) . Speed drops to 0.5 fps before silent crash.There have been a lot of improvements regarding exception handling in AVSMeter since 2.2.6. This won't prevent the crash but it might provide more info as to where it occurs.

[Atak_Snajpera]

More data but this time on nice graph
http://i.cubeupload.com/0bq5xY.png


There have been a lot of improvements regarding exception handling in AVSMeter since 2.2.6. This won't prevent the crash but it might provide more info as to where it occurs.

Just generic Access Violation after 3.5 GiB mark
http://i.cubeupload.com/6BfsAZ.png

[LigH]

Well, you used AVSMeter 2.6.2 (x86), so, a 32-bit process.

AVSMeter64 will run a 64-bit process.

Yet ... if you have LAA binaries, utilizing above 2.0 and up to 3.5 GB RAM should not cause so much speed penalty, that's a different issue (bold guess: maybe using a plugin which is not really LAA compatible, thus system calls occur a lot to try to prevent issues?).

[Groucho2004]

Well, you used AVSMeter 2.6.2 (x86), so, a 32-bit process.

AVSMeter64 will run a 64-bit process.

Yet ... if you have LAA binaries, utilizing above 2.0 and up to 3.5 GB RAM should not cause so much speed penalty, that's a different issue (bold guess: maybe using a plugin which is not really LAA compatible, thus system calls occur a lot to try to prevent issues?).
I'm a bit puzzled by your post. What makes a plugin LAA compatible? LAA only applies to the calling executable (AVSMeter, x264, VDUB, ...). Setting that linker flag in Avisynth.dll or plugins is pointless.

I have no idea why Avisynth+ doesn't exit gracefully with a proper out of memory message, I guess it's a plugin misbehaving in combination with multi-threaded AVS+.

[LigH]

I'm sorry about my lack of in-depth knowledge here ... long ago, I read a brief remark about compilers or linkers abusing the most significant bit of addresses (which will be unused in a 32-bit process environment) as a behavioral flag, which I did not understand in detail, but since then I am unsure if there might be code – even in a DLL – which might rely on this bit serving as a flag, rather than being ignored. Very vague, I know. But some people use strange memory addressing trickery. I would not be able to exclude this as "half-wit nightmares", unless pointed to a convincing reason why I don't need to bother. :o

On the other hand, I can easily imagine issues regarding threading, despite the list of default plugin functions threading modes being so much tuned already.

[Groucho2004]

I'm sorry about my lack of in-depth knowledge here ... long ago, I read a brief remark about compilers or linkers abusing the most significant bit of addresses (which will be unused in a 32-bit process environment) as a behavioral flag, which I did not understand in detail, but since then I am unsure if there might be code – even in a DLL – which might rely on this bit serving as a flag, rather than being ignored. Very vague, I know. But some people use strange memory addressing trickery. I would not be able to exclude this as "half-wit nightmares", unless pointed to a convincing reason why I don't need to bother. :o
Don't sell yourself short, there are indeed risks involved (https://stackoverflow.com/questions/2288728/drawbacks-of-using-largeaddressaware-for-32-bit-windows-executables) although I think that following simple coding guidelines should avoid these.

[pinterf]

@Atak_Snajpera: could you please put this line at the beginning of the script?
SetLogParams("log.txt", LOG_DEBUG)

Then look into the generated file. When there are a lot of messages for shrinking caches, it can cause heavy slow down.

And another question: what are your speed numbers when you specify e.g. SetMemoryMax(2000) or SetMemoryMax(3000)?

[Atak_Snajpera]

@Atak_Snajpera: could you please put this line at the beginning of the script?
SetLogParams("log.txt", LOG_DEBUG)

Default
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MSuper() by script.
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MAnalyse() by script.
---------------------------------------------------------------------
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().
---------------------------------------------------------------------
WARNING: A plugin or the host application might be causing memory leaks.

2000
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MSuper() by script.
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MAnalyse() by script.
---------------------------------------------------------------------
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().
---------------------------------------------------------------------
WARNING: A plugin or the host application might be causing memory leaks.

AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.397 | 472295 | 12.13
Memory usage (phys | virt): 2686 | 2880 MiB
Thread count: 53
CPU usage (average): 87%

Time (elapsed): 00:00:34.632

3000
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MSuper() by script.
---------------------------------------------------------------------
INFO: Ignoring unnecessary MT-mode specification for mvtools2_MAnalyse() by script.
---------------------------------------------------------------------
WARNING: A plugin or the host application might be causing memory leaks.

AVSMeter 2.2.6 (x86)
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)
Loading script...

Number of frames: 420
Length (hh:mm:ss.ms): 00:00:14.014
Frame width: 1920
Frame height: 1080
Framerate: 29.970 (5000000/166833)
Colorspace: YV12

Frames processed: 420 (0 - 419)
FPS (min | max | average): 0.300 | 472295 | 13.40
Memory usage (phys | virt): 2627 | 2819 MiB
Thread count: 53
CPU usage (average): 92%

Time (elapsed): 00:00:31.334

What is max safe value for SetMemoryMax in 32 bit? 3500 or 4000?

[Groucho2004]

@Atak_Snajpera
Which version of mvtools2 are you using?

[Atak_Snajpera]

http://i.cubeupload.com/4QiaRv.png

[Groucho2004]

You might get some speedup by using the latest version from pinterf.

[pinterf]

You might get some speedup by using the latest version from pinterf.
Yes, there were many fixes and changes since mvtools2 2.7.13.22 and the latest 2.7.22 probably fixes this one as well:
"WARNING: A plugin or the host application might be causing memory leaks."

I'd say the safe limit is 3000, but you have to experiment. AviSynth+ maintains its own memory consumption (frames, caches) internally but cannot count with a situation when a plugin is allocating so much memory that the total consumption is over limit.

[Atak_Snajpera]

Your version of mvtools2 solves performance drop after 2000 MiB mark. I don't even have to specify SetMemoryMax values at all :)

[Atak_Snajpera]

Simple question. Which one is better?

#Prefetch
video=Prefetch(video,16)

#Triming
video=Trim(video,0,1771)


or


#Triming
video=Trim(video,0,1771)

#Prefetch
video=Prefetch(video,16)

[Groucho2004]

Simple question. Which one is better?

#Prefetch
video=Prefetch(video,16)

#Triming
video=Trim(video,0,1771)


or


#Triming
video=Trim(video,0,1771)

#Prefetch
video=Prefetch(video,16)

Whatever gives you more performance and/or less memory usage. AVSMeter is your friend. :)

It may not matter at all.

[MysteryX]

This isn't working with Avisynth 2.6

if (!vi.IsY() && !vi.Is420() && !vi.Is422() && !vi.Is444() && !vi.IsRGB())
env->ThrowError("ConvertToShader: Source format is not supported.");


Is420 returns false, but IsYV12 works. I made sure to update headers to the latest version.

[Groucho2004]

This isn't working with Avisynth 2.6

if (!vi.IsY() && !vi.Is420() && !vi.Is422() && !vi.Is444() && !vi.IsRGB())
env->ThrowError("ConvertToShader: Source format is not supported.");


Is420 returns false, but IsYV12 works. I made sure to update headers to the latest version.
From avisynth.h:
// YV12 must be 0xA000008 2.5 Baked API will see all new planar as YV12
// I420 must be 0xA000010

Run the debugger and check the actual value that is returned.

[MysteryX]

hum... now it works. Perhaps it didn't recompile properly after updating the headers.

[burfadel]

I made a post regarding an issue with Avisynth and pixel types in combination with different bit depths here:
https://forum.doom9.org/showpost.php?p=1817968&postcount=160

Updated the first post with version 1.6.

If you extract the luminance channel such it is just the Y channel, obviously it is a different format to the YUV clip such as output from the chroma filtering. You first have to convert back to the same format before combining. This is fine, however when you are in more than 8 bits, the commands such as isYV12() etc do not work since it is expecting a YUV420Y8 clip for it to be true. Since it is a YUV420P10 clip (for example) the command isYV12() seems to give back false. If you run convertToYV12(), it keeps the higher bitdepth of 10 etc, so isYV12() still doesn't work. This, and possibly other little issues, are problematic when you want to have the output clip the same format as the input clip and it isn't 8-bit etc. This is why I put back the 'do not process' flags to the luma commands, it was either that or dropping support for YV16 and YV24, which obviously isn't desirable.

It works fine as is because the bit depths can be matched easily and the pixel type hasn't changed. I could do a convertbits() just so isYV12() etc works, but then it's an extra unnecessary bit of processing that will probably affect speed more than what was gained by converting it to Y8 and going back to the desired pixel type.

Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.

[MysteryX]

Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.
Use IsYUV420(), IsYUV422() and IsYUV444()

Was looking for a link but can't find those commands in the docs!

EDIT: Is420 :) in clip properties

[raffriff42]

I made a post regarding an issue with Avisynth and pixel types in combination with different bit depths here:
https://forum.doom9.org/showpost.php?p=1817968&postcount=160



Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.
See my response to your first issue here (https://forum.doom9.org/showthread.php?p=1817994#post1817994). (oh hi MysteryX)
Yes, you can do a direct merge chroma, with CombinePlanes (http://avisynth.nl/index.php/CombinePlanes) (MergeChroma (http://avisynth.nl/index.php/Merge#MergeChroma)should also work)
To get the format of the original clip, use Is420, Is444 etc, with BitsPerComponent (http://avisynth.nl/index.php/Clip_properties#Color_Format).

[burfadel]

Mergechroma didn't work, since one clip is Y8 and the other YV12 , formats have to match. Combineplanes should work though. I should have realised about the is422() etc! I'll fix this later today my time and hopefully works. Thanks for the info!

[george84]

The Readme says

- 64 bit OS:
copy Avisynth.dll from x86 folder to the windows SysWOW64 folder
copy Avisynth.dll from x64 folder to the windows System32 folder

I think x86 goes to System32 and x64 goes to SysWOW64

[LigH]

No, that's the common mis-assumption. For every Windows flavour, "system32" is the place where the DLL for the native architecture goes. For compatibility reasons.

If you have a 32-bit Windows, the 32-bit DLL goes to system32. Logical.
If you have a 64-bit Windows, the 64-bit DLL goes to system32. Because of compatibility reasons.

And because a 32-bit DLL is not native to a 64-bit Windows, it goes to a special directory "SysWOW64", which is mapped to "system32" for 32-bit applications running on a 64-bit Windows in a compatibility layer.

Germans would comment: "Klingt komisch, ist aber so." (Sounds strange but is true.)

[george84]

Germans would comment: "Klingt komisch, ist aber so." (Sounds strange but is true.)

Also swiss would comment this.

Is it right to deduce (When looking at referenced installer for r2294) that this installer will handle things correctly, so no manual copying of dll is needed, and it even includes newest version of avisynth?

[Groucho2004]

Is it right to deduce (When looking at referenced installer for r2294) that this installer will handle things correctly, so no manual copying of dll is needed, and it even includes newest version of avisynth?No, it does not have the latest version so you would have to copy the DLLs and plugins.
I suggest you use my universal installer (http://forum.doom9.org/showthread.php?t=172124), it has the latest version of AVS+.

[george84]

Thank you. But on the download page http://avisynth.nl/index.php/Avisynthplus/Downloads, yours is referenced. So I had the correct one.

[Groucho2004]

Thank you. But on the download page http://avisynth.nl/index.php/Avisynthplus/Downloads, yours is referenced. So I had the correct one.As I mentioned, if you use the r2294 installer you'll have to copy the DLLs (r2408) manually.

[george84]

Yes, but of course one would use AvisynthUniversalInstaller_2017-09-02.7z · 4.79 MB
which is in same directory.

[george84]

Plugins for high bit depth support.
Here in Forum I find docs on support of high bit depth. How can I know which plugins support this feature. In http://avisynth.nl/index.php/AviSynth%2B I find the newest version but no mention of bitdepth support.

[sneaker_ger]

Test if they support such input. Look into their changelogs/documentation. If they are old you know they don't.

[george84]

If they are old you know they don't.

What is old? Older than first Avisynth+ version which had high bit depth support?

[sneaker_ger]

Yes, that's what I meant. (I didn't mention an actual date because I don't know it from the top of my head. Maybe someone else knows.)

[Groucho2004]

Yes, but of course one would use AvisynthUniversalInstaller_2017-09-02.7z which is in same directory.That's a different kind of installer. I suggest you read the first post in the thread to which I linked in post #3611.

[george84]

I need
TransAll.dll
vsfilter.dll
zoom.dll
freeframe.dll
ffms2.dll
NicAudio.dll
FFMS2.avs

vsfilter and NicAudio are probably independent of bit depth.
ffms2 seems to be the only one working, but for transall there seems to exist an alternative on vcmohans page.
freeframe is not mandatory
zoom is available as source and it should be easy to adapt it.

So I might give it a try.

[george84]

@Groucho2004
Your link via post 3611 goes to https://www.dropbox.com/sh/oxx5cm9hkbpj5oz/AAD0QBnTlczv7xW3jEdSjenHa?dl=0

The link on page http://avisynth.nl/index.php/Avisynthplus/Downloads goes to https://www.dropbox.com/sh/oxx5cm9hkbpj5oz/AAD0QBnTlczv7xW3jEdSjenHa?dl=0

So where is the difference? Anyway, thank you for the installer. It works well.

[LigH]

Did you accidently paste the same URL twice, or are they exactly the same?

[george84]

Did you accidently paste the same URL twice, or are they exactly the same?

They are the same.

[Groucho2004]

So where is the difference?The "Universal Installer" hosts 7 different Avisynth versions from which you can choose via batch file. Switching from one version to another is very simple. Even if you don't want to play around with various versions, the installer has the latest AVS+ version and you don't have to mess around with copying files to the system directories.

The r2294 installer is a "classic" installer which only installs AVS+.

[george84]

The r2294 installer is a "classic" installer which only installs AVS+.

I see now our misunderstanding. I assume you talk about file AviSynth+ r2294.7z · 2.85 MB. I didn't even realize this was an installer because in same directory there was this file AvisynthUniversalInstaller_2017-09-02.7z · 4.79 MB and I talked about the later.

[george84]

x = ImageSource("C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/ColorCheck/colorcheckerchart4kElleV4Big2.tif", use_DevIL = true, pixel_type = "RGB48")
z = ConvertToYUV444(x, matrix="Rec2020")
z = Info(z,size=100)
x

I use avisynth+ 32bit newest version and tested above script in AvsPmod newest version. It correctly displays picture. In info it says for x: colorspace= RGB48, Bitdepth = 16.

When doing output of z instead of x:

1. there is an error message in AvsPmod "Error trying to display the clip..."

2. When encoding with RipBot264 I get strange colors and the video shows only the left half (stretched) of original tif picture. In info it says for z: colorspace=YUV444P16

So I assume there is one problem in AvsPmod and another one in Avisynth+.

Edit1

Insert z = ConvertToStacked(z) after ConvertToYUV444 it displays in AvsPmod. Whatever that means?

[Groucho2004]

When doing output of z instead of x:

1. there is an error message in AvsPmod "Error trying to display the clip..."

2. When encoding with RipBot264 I get strange colors and the video shows only the left half (stretched) of original tif picture. In info it says for z: colorspace=YUV444P16

So I assume there is one problem in AvsPmod and another one in Avisynth+.

Edit1

Insert after ConvertToYUV444 it displays in AvsPmod. Whatever that means?
Nothing wrong with AVS+. AVSPmod simply cannot identify this colorspace (it does know about the stacked variants, that's why ConvertToStacked() worked).

As for ripbot, no idea. Can it even encode 444P16?

[george84]

Thank you for fast response. It is really AvsPmod which confused me.
Actually I need 10 bits. So I inserted
z = ConvertBits(z,10)

and checked result with AVSMeter. Resulting color space is YUV444P10.

I now did the encoding without RipBot, reimported the result with vapoursynth to check the precision of colors. Everything is perfect.

For further work and test, I plan to use AvsPmod and on the very last output statement I will create a stack. I have huge avs scripts and want to adapt them for Rec2020 and high bit depth. I was evaluating vapoursynth but currently prefer Avisynth+.

[Atak_Snajpera]

In case if you need simple installer here is my installation script.
http://www.mediafire.com/file/489x44ql11m3u6e/AviSynthPlus_MT_Installer.7z

[george84]

AVSMeter 2.5.5 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
Address: 0x61AAA393

C:\Users\Walter\Downloads\AVSMeter255>SHIFT

Not sure if this is right place to post. Above violation occurs on a script of 1400 lines. The script displays well in AvsPmod which gives Video Information correctly (CS = RGB24)

Problem is not important for me.

[LigH]

Might be placed better in the thread for AVSMeter if it is specific (well, leave it here, no need to double) ... but the author (Groucho2004) would surely be interested in the script, possibly as well in the output of "AVSMeter -avsinfo" (which checks DLL dependencies first).

[george84]

I didn't find AVSmeter thread. Here is output of -avsinfo. Script > 1400 lines. So would be difficult to isolate error.

C:\Users\Walter\Downloads\AVSMeter255>"AVSMeter.exe" -avsinfo

AVSMeter 2.5.5 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2508, MT, i386)
VersionNumber: 2.60000
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2017-06-29, 09:00:22 (UTC)
PluginDir+ (HKLM, x86): C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins
PluginDir2_5 (HKLM, x86): C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins


[CPP 2.6 / 32 Bit plugins]
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll

C:\Users\Walter\Downloads\AVSMeter255>SHIFT

[jpsdr]

Maybe the first thing to do is to update avsmeter to the last version (actualy 2.6.5) and test your script with it to see if tge access violation still occurs.

[LigH]

I didn't find AVSmeter thread.

» AVSMeter 2.6.5 (https://forum.doom9.org/showthread.php?t=174797) «

It's also included in Groucho's Avisynth Stuff (https://forum.doom9.org/showthread.php?t=173259)... :o

[george84]

Continued in thread » AVSMeter 2.6.5 « (https://forum.doom9.org/showthread.php?t=174797)

[qyot27]

So in the interest of trying to resolve this issue that's been (at least partially) holding up the Linux work, here's a few builds:

FFmpeg r87486 (http://www.mediafire.com/file/r7tz60eunq8wv7m/ffmpeg_r87486.7z)
FFMS2 C-plugin r1145+104 (http://www.mediafire.com/file/ndpzuqq3m64m0rc/ffms2_r1145%2B104-avs%2Bvsp.7z)
AviSynth+ r2510 (VS2017) (http://www.mediafire.com/file/bmh4t99pc7apk95/avisynth__r2510-g6831004b-20170930.7z)
AviSynth+ r2509 (GCC 7.2.0/MinGW-w64 5.0.2) (http://www.mediafire.com/file/ku2an85e7gjf7cp/avisynth__r2509-gcctest.7z)

Includes both 32-bit and 64-bit in all packages. Windows XP supported by all builds. The 32-bit MSVC build of AviSynth+ and the FFMS2 C-plugin can be used on non-SSE2. The GCC builds of AviSynth+ require SSE2.

THE GCC BUILD IS FOR TESTING. The issue I was referring to above is that the 32-bit GCC build cannot be used by FFmpeg, because of the weirdness that comes with 32-bit builds, calling convention differences on Windows, and function decorations between GCC and MSVC. It's even a tiny lie that the 32-bit build can't be used by FFmpeg; there is a way that it can be made to work, but doing so would make that build of FFmpeg incompatible with the MSVC builds of AviSynth+ (with the possible exception of MSVC builds of FFmpeg being able to use MSVC builds of AviSynth+, but I don't know that for sure). The build of FFmpeg above is a standard build, and will work with the standard MSVC builds of AviSynth+ as well as the 64-bit GCC build of AviSynth+. This only ever affects Windows, since the underlying problems causing this are Windows-specific.

Additionally, the GCC builds of AviSynth+ shouldn't be able to use MSVC-built C++ plugins just due to the incompatibility between C++ implementations, but it is possible for the 64-bit build to use the 64-bit FFMS2 C-plugin (and likely, any other C plugins with 64-bit versions). AVISource also works, so there are at least two source filters that can be used with it. My ability to test under 64-bit Windows is almost non-existent, because I have to run it under a VM on a Silvermont under Ubuntu, running off an external USB 2.0 port. My tests with it under 64-bit Wine are what this information was gleaned from.

I'd like to be able to fix this properly so 32-bit GCC builds can be used with FFmpeg without breaking compatibility with MSVC. My attempts at forcing this have failed thus far. Trying to build as 32-bit with __stdcall ends up breaking compilation, and nothing I tried to force the function decorations into line worked. I'd assume it's actually that if we can fix the code so GCC doesn't choke when using __stdcall on 32-bit builds, it'd probably be okay (so long as I could get the decorations correct, and it wouldn't screw up building under MSVC or the 64-bit GCC build). I'm also really tired of trying to do so, so there's also a part of me that would probably be totally okay with it if we don't support building 32-bit AviSynth+ with GCC on Windows (as I said before, it's a Windows-specific issue; any future Linux support could use 32-bit with no problem, even if the market share for 32-bit Linux is dwindling pretty fast too).

[real.finder]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that

[tuanden0]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that

Here's my test with GTX 1060 3GB:
Without CUDA: https://i.imgur.com/W2WFT9R.png
With CUDA: https://i.imgur.com/aE1SbfM.png

I tried to remove DumpfilterGraph and it still work but no FPS change.
If I remove Prefetch then FPS go down to 48 and time go up to 2 min.
I put "OnCUDA" on all filteres but it's not work, except "OnCPU" work with source filter and FPS not change.

[poisondeathray]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that




Thanks, looks interesting!


Just a suggestion, but should this fork and it's testing be moved to a separate thread ?

The readme's are in Japanese ,but google translate does an ok job I think

[poisondeathray]

I got the kqtgmc , knnedi3 , working with avisynth+cuda .

Some quick tests on a gtx860 were consistently slower than avisynth+mt for KQTGMC, and KNNEDI3 (ie. avisynth+mt on CPU was about 1.2-1.4x faster using the normal CPU versions QTGMC and NNEDI3), maybe a faster card would put it over the top . I didn't test validity/quality results yet.

The same .dll was able to run the "normal" avisynth+mt script as is too (ie. with prefetch(x) ), with the same speed



Here's my test with GTX 1060 3GB:
Without CUDA: https://i.imgur.com/W2WFT9R.png
With CUDA: https://i.imgur.com/aE1SbfM.png

I tried to remove DumpfilterGraph and it still work but no FPS change.
If I remove Prefetch then FPS go down to 48 and time go up to 2 min.
I put "OnCUDA" on all filteres but it's not work, except "OnCPU" work with source filter and FPS not change.

Look at the readme (use google translate) . You need to wrap in OnCPU, OnCUDA

Did you notice no speed change ? What about GPU-z ? monitor GPU card usage, or try device_index=x to swap GPU# (take out KNLMeansCL for testing now, because that will use GPU too)

Im guessing not all filters are accelerated, or maybe your card is as fast as CPU processing ?

[poisondeathray]

@tuanden0 - you have the same card as the developer, but a 3GB model instead of 6GB. He got 83.43fps vs. 27.33fps for QTGMC on "fast" preset

Just try the exact same script for now, to see if there is a speed difference for you

[vivan]

i5-4670k + gtx 1080
88 fps CPU, 430 fps CUDA

But script results do differ.
I need to upgrade my QTGMC...

[tuanden0]

@tuanden0 - you have the same card as the developer, but a 3GB model instead of 6GB. He got 83.43fps vs. 27.33fps for QTGMC on "fast" preset

Just try the exact same script for now, to see if there is a speed difference for you

Here you are :cool:
Without CUDA: https://i.imgur.com/TuO78nY.png
With CUDA: https://i.imgur.com/TUSWvuO.png
With CUDA 2: https://i.imgur.com/c06mL6c.png

:devil:

[real.finder]

I hope someone port that to use opencl (maybe Khanattila since he has experience in it)

so many people can use it

[poisondeathray]

i5-4670k + gtx 1080
88 fps CPU, 430 fps CUDA

But script results do differ.
I need to upgrade my QTGMC...


differ - did you mean qualitatively different results ?

[vivan]

differ - did you mean qualitatively different results ?They are just different, it's hard to say which one is better.
https://i.imgur.com/JRM9vJb.png
https://i.imgur.com/8AsGgNL.png

134 fps on 1920x1080 video ("Fast" Preset) :eek:

[jpsdr]

The following line works in standard avisynth but not in avs+ x64.

black = BlankClip(last, width=64, height=32, Color_yuv=color_black)

and probably the next (forgot to test, and i'm under standard avisynth without avs+ access while writing these lines).

white = BlankClip(last, width=64, height=32, Color_yuv=color_white)

[LigH]

In which way does it "not work"? Do you have any error messages?

I suppose it doesn't know color constants?

---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
I don't know what 'color_black' means.
(H:\Video\black-white.avs, line 1)
---------------------------
OK
---------------------------


That should be fixable by providing a color names import scriptlet (colors_rgb.avsi (https://github.com/dcherian/tools/blob/master/misc/avisynth-reader/avisynth/distrib/color_presets/colors_rgb.avsi) in plugins+ / plugins64+).

My former AviSynth 2.56 installation seems to have provided this file in AviSynth 2.5\plugins already.

But the color constants known in legacy AviSynth 2.55+ (http://avisynth.nl/index.php/Color_presets) are RGB colors, not YUV.
__

Actually, nope ... sorry. The file "colors_rgb.avsi" does exist in all my plugin directories for all AviSynth flavours, but is not auto-loaded. I have to Import() it explicitly to make it work.

[Yanak]

Already had similar issues with avs+ x64

blankclip(color=color_black) # doesn't work, " I don't know what color_black means "
blankclip(color=$000000) #works

Switched for Hex values when i needed it but did not suspected this could be a bug

[LigH]

Well, if you explicitly
Import("colors_rgb.avsi")
it works as well; it's just strange that auto-importing from the plugins auto-load directory doesn't work ... anymore? I thought it did, once.

[Groucho2004]

Well, if you explicitly
Import("colors_rgb.avsi")
it works as well; it's just strange that auto-importing from the plugins auto-load directory doesn't work ... anymore? I thought it did, once.See here (https://forum.doom9.org/showthread.php?p=1714618#post1714618).

[LigH]

Oh, that one is quite old (2015).

Of course, "loading plugins" is not the same as "importing scripts". Still, some automation would be appreciated here.

[pinterf]

Yes, the autoload issue is registered but not fixed yet.

[bxyhxyh]

Hello
I'm stabilizing shaky video with deshaker.
Converting it to 16-bit so I could reduce rounding errors.
Like this

Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
convertto8bit()
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
ConvertToYUV444(matrix="Rec709")
convertto8bit()
}

s = source()
s.yv12torgb32().dehsaker().RGB32toYV24()


I noticed bit difference on brightness.
It was clear it's caused by color convertion.
So I just typed
s.yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24().yv12torgb32().RGB32toYV24()
Then this is the result
source - https://i.imgur.com/V3aioqT.png
converted - https://i.imgur.com/kddpb3i.png
Is it a bug or something? (Pictures are resized since it doesn't matter for what we're talking anyway.)

[raffriff42]

Then this is the result ...is it a bug or something?It does look like a bug. The problem seems to be in ConvertTo8bit; its output is aprox. 1 step darker after each pass, probably a rounding issue. Using dither seems to fix it:Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
convertto8bit(dither=0)
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
ConvertToYUV444(matrix="Rec709")
convertto8bit(dither=0)
}
however this does add a dither pattern, invisible in normal footage but apparent in Colorbars etc. Adding a fixed offset also seems to work:Function YV12toRGB32(clip c)
{
c.convertTo16bit()
converttorgb64(matrix="Rec709")
RGBAdjust(rb=127, gb=127, bb=127)
convertto8bit()
}

Function RGB32toYV24(clip c)
{
c.ConvertTo16bit()
RGBAdjust(rb=127, gb=127, bb=127)
ConvertToYUV444(matrix="Rec709")
convertto8bit()
}
Offset set to 127 because 0.5 (8bit) ≈ 127 (16bit).

[bxyhxyh]

Ah, so this might be also yet another "256 or 257" thing.

[Weirdo]

Probably trivial but can't find the workaround. My little script gives There is no function named 'SetMTMode' (line 3), while it works with the older Avisynth 2.6 MT (https://forum.doom9.org/showthread.php?t=148782) from SEt. Using Avisynth+ r2508, QTGMC 3.357s with its updated plugins, W10 x64. Thanks for any tips.

global MeGUI_darx = 143
global MeGUI_dary = 80
SetMTMode(5, 4)
SetMemoryMax(1000)
LoadPlugin("F:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("G:\source.d2v")
SetMTMode(2)
QTGMC( Preset="Slow", EdiThreads=2 )
Distributor()
crop(14, 4, -10, -4)

[Reel.Deel]

Probably trivial but can't find the workaround. My little script gives There is no function named 'SetMTMode' (line 3), while it works with the older Avisynth 2.6 MT (https://forum.doom9.org/showthread.php?t=148782) from SEt. Using Avisynth+ r2508, QTGMC 3.357s with its updated plugins, W10 x64. Thanks for any tips.


Multi-threading syntax in AviSynth+ is different, see wiki pages for more information: http://avisynth.nl/index.php/AviSynth%2B#MT_Notes

[LigH]

There is indeed no function named "SetMTMode" in AviSynth+.

See AviSynth Wiki: AviSynth+ – 4. MT notes (http://avisynth.nl/index.php/AviSynth%2B#MT_Notes)

Furthermore, use Distributor() only when you are really sure you know why. If not, it may multiply threads unexpectedly.

[Weirdo]

Thank you both, I made the corrections and it works fine.

[wonkey_monkey]

Can someone give me a dumbed-down summary of the different MT modes? I've read this:

http://avisynth.nl/index.php/AviSynth%2B#Guidelines_on_choosing_the_correct_MT_mode

But it's not very clear to me. It doesn't really state how the modes work, and especially the bit for MT_NICE_FILTER isn't clear at all on when it should be used, instead focusing on when it shouldn't.

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?

[Reel.Deel]

@davidhorman

See here for more info. http://avisynth.nl/index.php/Avisynthplus/Developers

There's a few post in this thread with a bit more info, unfortunately I'm away from my home computer ATM.

[wonkey_monkey]

I've read that, but I'm still none-the-wiser as to what actually happens. I am 99% sure my current filter can never be MT-friendly, at least...

[MysteryX]

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?
Yes, if you're using Prefetch(8), MT_NICE_FILTER has 1 instance and 8 threads calling that one instance. That means the code must be thread-safe and you can't have class-level writable variables and buffers. Any work buffer must be initiated and destroyed within each GetFrame call.

MT_MULTI_INSTANCE creates 8 instances, and I'm not sure the thread creating the class is always the same as the thread calling GetFrame, in fact I think it can be any thread but always only 1 call at once.

MT_SERIALIZED, it will have 1 instance and only 1 call at once. However, there is currently a bug in the latest AVS+ where it can actually receive 2 calls at once in certain cases. Pinterf is working on fixing that, but for now, MT_SERIALIZED is broken.

[wonkey_monkey]

but for now, MT_SERIALIZED is broken.

Which is the only one my filter can work under. Oh well! It's working for now on whatever version of AVS+ I'm using.

[pinterf]

MT_SERIALIZED, it will have 1 instance and only 1 call at once. However, there is currently a bug in the latest AVS+ where it can actually receive 2 calls at once in certain cases. Pinterf is working on fixing that, but for now, MT_SERIALIZED is broken.
It's not broken, fixed since r2502

20170602 r2502
- fix: (Important!) MT_SERIALIZED mode did not always protect filters (regression since r2069)
Such filters sometimes were called in a reentrant way (like being MT_NICE_FILTER), which
possibly resulted in using their internal buffers parallel.
[...]

[pinterf]

It does look like a bug. The problem seems to be in ConvertTo8bit; its output is aprox. 1 step darker after each pass, probably a rounding issue.
While YUV 8<->16 conversion is a simple bit-shift, RGB conversion is full-scale, e.g. 8->16 bit conversion is something like x*65535/255. 255 becomes 65535. Similarly for 16->8 bits the formula is x*255/65535. Anyway, I'll check it (Sorry, I still have limited time for a couple of weeks).

Remark: do not worry about rounding errors in 8 bit conversions and in 8 bit filters in general. Most of the 8 bit functions work internally with 13-15 bits precision (like in classic Avisynth)

[bxyhxyh]

While YUV 8<->16 conversion is a simple bit-shift, RGB conversion is full-scale, e.g. 8->16 bit conversion is something like x*65535/255. 255 becomes 65535. Similarly for 16->8 bits the formula is x*255/65535. Anyway, I'll check it (Sorry, I still have limited time for a couple of weeks).
Is it bit-shifting or that (something like x*65535/255) arithmetic formula?
Bit shifting wouldn't work correct since 255 bit-shifted is not 65535.
But in avisynth they are equal white.

I'm pretty sure you know it, just pointing to it.

[wonkey_monkey]

Is it bit-shifting or that (something like x*65535/255) arithmetic formula?

You can bitshift, and then OR in the original bits as well. It would be equivalent to the arithmetic formula (since 65535/255 = 257).

(x << 8) | x

Where does the convention that only a bitshift is used for YUV come from?

[TheFluff]

Can someone give me a dumbed-down summary of the different MT modes? I've read this:

http://avisynth.nl/index.php/AviSynth%2B#Guidelines_on_choosing_the_correct_MT_mode

But it's not very clear to me. It doesn't really state how the modes work, and especially the bit for MT_NICE_FILTER isn't clear at all on when it should be used, instead focusing on when it shouldn't.

I'm guessing that MT_NICE_FILTER requests multiple frames in multiple threads, but only one instance of the filter, and that MT_MULTI_INSTANCE makes multiple instances, so it's a bit like calling the same plugin multiple times on trimmed/selecteveryed subclips and then joining or interleaving them? Or does it crop frames up into smaller frames then stack them back together, or something? (probably not) And that MT_SERIALIZED is the same as plain old single-threaded AviSynth?

I wrote this (https://forum.doom9.org/showthread.php?t=174437) a while ago. May or may not help.

The tl;dr is that as a rule of thumb:

if your filter's GetFrame is threadsafe (basically, does not attempt to write to any memory that is not explicitly associated with this specific frame request) => MT_NICE_FILTER
if your GetFrame does depend on shared state of some kind, but your filter supports things like interleave(yourfilter().selecteven(), yourfilter().selectodd()) in vanilla Avisynth => MT_MULTI_INSTANCE
if you are a source filter, or rely on frame request order (i.e. stuff with side effects outside Avisynth such as writing to a file), or rely on internal state that changes with every frame request (i.e. pattern-tracking decimation filters) => MT_SERIALIZED


It also may or may not be relevant to note that all GetFrame calls that need to happen to produce a given output frame at the end of the script happen in the same single thread, regardless of what MT modes are in use. You probably shouldn't rely on this for anything, though.

[wonkey_monkey]

Thanks TheFluff - that helps. I'm certain my filter will never be able to be MT'd. It's internally multi-threaded though.

[Myrsloik]

Is the avs+ api stable now? I really don't want to waste time adding compatibility for it if I'm going to have to change things later.

[pinterf]

I'm not planning to change it.

[real.finder]

I'm not planning to change it.

what about add support for vs api in avs+ to load vs plugins (dll) in avs+?

We discussed this in irc years ago and Myrsloik said it's possible

[pinterf]

Short developer news, I hope I'll have less busy months from now (finished a marathon with 2:55, this year I was preparing on this race instead of coding)

- "Levels" now allows 32 bit float inputs
- today I have successfully ported Expr (http://www.vapoursynth.com/doc/functions/expr.html) filter from the VapourSynth project, with some additions (masktools syntax of built-in constants and some of the scaling helper functions).

[pinterf]

what about add support for vs api in avs+ to load vs plugins (dll) in avs+?

We discussed this in irc years ago and Myrsloik said it's possible
If he says it's possible then it's the question of someone's time :) isn't it? Not planning in the near future either, to tell the truth I cannot imagine the magnitude of the effort at the moment.

[real.finder]

Short developer news, I hope I'll have less busy months from now (finished a marathon with 2:55, this year I was preparing on this race instead of coding)

- "Levels" now allows 32 bit float inputs
- today I have successfully ported Expr (http://www.vapoursynth.com/doc/functions/expr.html) filter from the VapourSynth project, with some additions (masktools syntax of built-in constants and some of the scaling helper functions).

good news :)

Expr will be part of internal avs+ functions?

[pinterf]

good news :)

Expr will be part of internal avs+ functions?
Yes, it was more convenient and faster for me than putting it in a separate dll (masktools).

[MysteryX]

and Expr really has nothing to do with masks, it's more of a core feature

[Myrsloik]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.

And speaking of formats... are only formats with a pre-combined constant allowed or can I have some 16bit yuv with insanely high subsampling?

Btw, do any filters have meaningful planar YUVA or RGBA support or can I skip implementing it properly for now?

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?

[ChaosKing]

Maybe AVSMeter (src included) can help you for the detection part: https://forum.doom9.org/showthread.php?t=174797

[Groucho2004]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.I'm not aware of any way to extract that information. For a compiled plugin DLL you can query the type and the version (C 2.0, C 2.5, CPP 2.0, CPP 2.5, CPP 2.6) by checking the DLL exports but that's about it.

[TheFluff]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.

Is that actually strictly necessary in practice? Most plugins tend to check for the colorspaces they can handle in the constructor, and I think the colorspace checking functions in 2.6 won't misdetect new stuff as something old, although 2.5 plugins will pretty much think everything is YV12 AFAIK.

[Myrsloik]

Is that actually strictly necessary in practice? Most plugins tend to check for the colorspaces they can handle in the constructor, and I think the colorspace checking functions in 2.6 won't misdetect new stuff as something old, although 2.5 plugins will pretty much think everything is YV12 AFAIK.

I don't trust plugin code to handle it properly. Never trust plugins.

[pinterf]

What's the proper way to detect if a plugin is compiled for the avs 2.6 or avs+ api? By whether or not it calls SetFilterMTMode() on init? Is there some other way? I want to make sure 2.6 plugins don't get exposed to avs+ only formats.
Avs+ filters can only provide a hint about their MT modes when avisynth core requests for it, by returning the proper mt enum on the CACHE_GET_MTMODE poll. So they do not actively set multithreading modes.
int __stdcall SetCacheHints(int cachehints, int frame_range) override {
return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
}


And speaking of formats... are only formats with a pre-combined constant allowed or can I have some 16bit yuv with insanely high subsampling?
Only those pre-combined constants are allowed. NewVideoFrame explicitly checks against them (Btw., that was the reason when I was starting to mod 8-bit only avs+, because NewVideoFrame did not allow me to create a video frame with arbitrary set bit-mask flags. Nor allows arbitrary flags today but the list of the preset video format was hugely expanded wiht 10+bit and planar-with-alpha constants)

Btw, do any filters have meaningful planar YUVA or RGBA support or can I skip implementing it properly for now?Masktools, Rgtools accepts planar formats with alpha. But you asked meaningful, I suppose you mean when a filter is using the clip's alpha channel for mask operation for example. I'm not aware such filter.

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?
No. Nor have I studied that part of avs+ in deep. I don't know whether ultim treated them as a finalized chapter in avs+ development, but since he left the scene, we'll never know.

[jpsdr]

Oh, and is the threadpool and jobcompletion stuff actually documented somewhere?

Probably the most important documentation you can find is here (http://forum.doom9.org/showpost.php?p=1778346&postcount=53).

[Myrsloik]

Probably the most important documentation you can find is here (http://forum.doom9.org/showpost.php?p=1778346&postcount=53).

Interesting, with that description I could actually implement it if an interesting plugin using it is found.

[jpsdr]

Personnaly i don't because i don't want my plugins be "avs+ only", and unfortunately i don't think any plugin is using it actualy.

[sausuke]

can I ask why the thread count of avisynth+ is always at 37? I don't use MT in the script and on avs meter why my CPU usage is only 2%? I used avisynth MT too and the CPU usage is only 8% max>

script:
AVISource("E:\2Encoded Files\klsdjfjklfdsakjlfdsa.avi", audio=false).AssumeFPS(60000,1001)
ConvertToYV12(matrix="PC.709")


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

I'm frameserving from Sony Vegas 15. It uses all the cores 99% with no speed benefit (with MT when using MEGUI). I even used the ultrafast preset on x264 same 49fps. Is this a bug?

PS: when I used Prefetch(4) the thread count goes to 41

[tuanden0]

@sausuke:
I think they not yet optimize for your CPU. Almost people using AMD Ryzen TR have same issue with you.

[sausuke]

@sausuke:
I think they not yet optimize for your CPU. Almost people using AMD Ryzen TR have same issue with you.

yeah same with Avisynth MT, when I used high threads on SetMTMode the speed is faster but sometimes the video jitters randomly on the first seconds. Some encodes are not. Still testing...

[Groucho2004]

can I ask why the thread count of avisynth+ is always at 37?
It's not always 37 threads, just in your specific scenario.


I don't use MT in the script and on avs meter why my CPU usage is only 2%? I used avisynth MT too and the CPU usage is only 8% max>
I think that Vegas simply doesn't serve frames to Avisynth fast enough and therefore creating a bottleneck. That also explains the low CPU usage.

[sausuke]

It's not always 37 threads, just in your specific scenario.


I think that Vegas simply doesn't serve frames to Avisynth fast enough and therefore creating a bottleneck. That also explains the low CPU usage.

the video preview on sony vegas is so fast though even the video realtime in frameserver (100%+) when using avsmeter (100-150fps) using other scripts and avisynth.

the thing is all the avisynth I used (MT,avs+MT) I need to push the Queue button on MEGUI many times (1x to 3x) to get a fast FPS, when I pushed it and the video is slow they have the same cpu usage too, so I abort again and push then pray that it will be fast (40fps=slow 75fps=fast)

here's the screenshot using this script with avsmeter:

script:

SetMemoryMax(1536)
SetMTMode(5,4)
AVISource("E:\2Encoded Files\kljsdfkjlfdskjlfds.avi", audio=false).AssumeFPS(60000,1001)
SetMTMode(2,4)
ConvertToYV12(matrix="PC.709")
return last



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

same scenario on avsmeter, in that screenshot that is the fastest, I first drag the script and it only have 50fps so I close avsmeter and drag again then that's the fastest (I always look on Vegas Preview too and the frameserver percentage). Dunno if it's the architecture of the threadripper though first time experiencing this.

EDIT:

here's what I'm saying

Slow: 30+ FPS

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

Fast: 70+ FPS (too lazy to wait) xD

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

That's the two scenario when I want to encode either get the 30fps one or the 70fps one. When using the normal avisynth always 40fps

PS: Look also the jobs, 11 to 13 hence I aborted in Job 12 'cause I get the same slow fps and get the fast FPS in Job 13

[Yanak]

What is the pixel format for the ouput , 8bits or 32bits floating ?
Also if not already done disable the preview rendering in vegas before frameserving, this make it run like a turtle when frameserving.

I don't have this CPU ( 3770k@4Ghz here) but I frameserve from vegas14 my output file directly to a 4GB Ramdisk , vegas temp folder is also set on the Ramdrive. On AVSmeter I usually get around 10-12% CPU usage for 1080p60fps footage and 20-25% CPU usage for 720p30FPS footage with average 250frames output according to avsmeter.

When i have the possibility, when it's not too big i put my source video on the Ramdisk too and work from there on vegas and also output to the ramdrive the frameseved and avisynth created files, wish i had more RAM to make bigger ramdisk tho.

Edit: took me time to answer with window opened, just seen the previous post after i sent mine.

[sausuke]

What is the pixel format for the ouput , 8bits or 32bits floating ?
Also if not already done disable the preview rendering in vegas before frameserving, this make it run like a turtle when frameserving.

I don't have this CPU ( 3770k@4Ghz here) but I frameserve from vegas14 my output file directly to a 4BG Ramdisk , vegas temp folder is also set on the Ramdrive. On AVSmeter I usually get around 10-12% CPU usage for 1080p60fps footage and 20-25% CPU usage for 720p30FPS footage with average 250frames output according to avsmeter.

When i have the possibility, when it's not too big i put my source video on the Ramdisk too and work from there on vegas and also output to the ramdrive the frameseved and avisynth created files, wish i had more RAM to make bigger ramdisk tho.

Edit: took me time to answer with window opened, just seen the previous post after i sent mine.

8bits only, afaik the encoding suffers when I do 32bit floating in sony vegas. (same when I'm using my i7-5960x) so I always use 8bits.

Gonna test that preview rendering thank you

EDIT:

Same even the preview rendering is disabled. It goes slow or fast fps when encoding.

[Yanak]

I don't know what is the bottleneck for you, preview screw up my speed on my system :/

Made a quick test and using aviynth x64 that is not compatible with the frame-server output format from debugmodeserver but under MP_Pipeline and a win32
process inside it i got this for the cpu usage:
https://s14.postimg.org/ky6r5akc1/34575520171026142337.png

Was a short 1080p video, stored on the ramdisk and debugmodeframserver was outputting it at 211% speed into avisynth.

Like Groucho said i think the problem is not avisynth itself, or not totally at least, maybe the HDD speed vs me using a Ramdisk mostly, or some vegas performances parameters maybe, hard to say more on this.

Edit : forgot i had megui installed on my machine, using only Staxrip since a while, but made a test in native x86 with it :

https://s14.postimg.org/4zy1f5xtt/81718320171026194158.png
Output from frameserver was 230 to 238% ...

[sausuke]

hmm I've tried a normal avi and the normal speed is 400fps (not frame serving) but I've tried my nvenc codec recordings and it will not have preview on megui so I can't test (megui crashing). Maybe the nvenc codec is the bottleneck problem? I can't try the avi on sony vegas 'cause it can't accept now which is weird.

EDIT:

oh my it seems the nvenc codec (in MP4) is the bottleneck, I run a test using avi file and it's so fast in sony vegas (frameserver/avisynth+without mt), the problem is now I will use AVI on my recordings on bandicam though (have problems in sounds)

will test the other option though

EDIT:

Finally solved it, it seems the source is the culprit all along (should have read the bandicam faq) I've been using H264 on the settings all these years and not X264 in FourCC code options. Thank you guys for the comments, Groucho2004 for avsmeter (helps alot), Yanak (got the idea of using other source because of your screenshots) xD

EDIT:

Can I ask if avsmeter preset is the ultrafast of x264 which why is it fast? thank you

[Groucho2004]

Can I ask if avsmeter preset is the ultrafast of x264 which why is it fast? thank youAVSMeter simply reads the frames from your script, there's no encoding involved. It measures how fast Avisynth can serve frames to your encoder (x264).

[sausuke]

AVSMeter simply reads the frames from your script, there's no encoding involved. It measures how fast Avisynth can serve frames to your encoder (x264).

now I understand, hmm the problem appears again but not as bad, the script on avs meter is fast now

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

now it's either the Sony vegas or my computer, dunno if my it's my ram or my overclock, the speed is random when encoding (more on fast now) I always check avsmeter it's always on that speed so I already have fast frameserver.

what did I do:

Increased Sony vegas 15 threads to 48 (already tried only 1 and the encoding slows down)

I've already done the ramdisk and the slow fps does happen too so I think I don't have bottleneck on my HDD, I checked the taskmanager too

Gonna reset all the parameters on BIOS if it will help

EDIT:

Alright I finally know what the cause, 100% fix. This is all about the ram. I thought my 1 of my 4 ram is busted (can't boot with XMP on) so I've removed it then my computer runs in triple channel (2666Mhz XMP On). Yesterday I'm googling about threadripper performance problem and it said that low speed and not quad channel ram causes performance decrease up to 50% and infinity fabric relies on faster ram speed. So I put again my 1 8gb ram (for quadchannel again), overclock all my 32gb to 3000Mhz and it boots. I test it on all my .veg files with MEGUI and wallahh: always fast encoding, no more abort and pray to be faster.

It seems the ram speed needed to communicate to the processor, I have feeling about this though cause why sometimes it only uses the other half of the die

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

Hope this will help who gonna buy Ryzen or Threadrippers, buy high speed rams or overclock it (if you want to save money with previous ram). Didn't know this can affect the CPU performance that match in AMD (first time using AMD) haven't research much about this I always thought it's the same with intel, all about CPU not affecting by ram specification

[TheFluff]

Continuing the discussion from here (https://forum.doom9.org/showthread.php?p=1823329#post1823329), let's talk about those nasty memory offsets again.

In avisynth.h from 2.6:
size_t (VideoFrameBuffer::*GetDataSize)() const;
size_t (VideoFrame::*GetOffset)(int plane) const;
class VideoFrameBuffer {
BYTE* const data;
const size_t data_size;
(...)
protected:
VideoFrameBuffer(size_t size);
(...)
public:
size_t GetDataSize() const AVS_BakedCode( return AVS_LinkCall(GetDataSize)() )

class VideoFrame {
(...)
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
(...)
VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height);
VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height,
size_t _offsetU, size_t _offsetV, int _pitchUV, int _row_sizeUV, int _heightUV);

void* operator new(size_t size);

// generally you shouldn't use these three
(...)
size_t GetOffset(int plane=0) const AVS_BakedCode( return AVS_LinkCall(GetOffset)(plane) )

In Avs+ all these size_t's are (32-bit signed) int instead. In Avisynth it doesn't really matter in practice because a frame is always allocated as one big chunk of memory, and nobody really has any use for more than 2^31 bytes of vfb. If you ever wanted to stop doing this though and use one individual pointer per plane like VS does, this won't fly because you can't reliably stuff a 64-bit pointer in a 32-bit integer, and it's generally bad coding practice to not use size_t (or ptrdiff_t) for these things.

Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue.

[enctac]

r2508 RGB->Y8 [incorrect]
r2508 RGB->YV24->Y8 [correct]
2.6MT RGB->Y8 [correct]

OS: Win10 CU
CPU：i7-4702MQ(Haswell)


function LumaBlock(int n){
return BlankClip(width=60,height=400,pixel_type="RGB32",color=n*(65536+256+1)).Subtitle(String(n),align=2).KillAudio()
}

StackHorizontal( LumaBlock(0), LumaBlock(8), LumaBlock(16), LumaBlock(32), LumaBlock(64), LumaBlock(96), LumaBlock(128), \
LumaBlock(160), LumaBlock(192), LumaBlock(224), LumaBlock(235), LumaBlock(245), LumaBlock(255) )

# Avisynth+ r2508 needs ConvertToYV24()
# ConvertToYV24()

ConvertToY8()
Subtitle(VersionString,align=9)

# Show Histogram
ConvertToYV24()
Histogram("levels")

Subtitle("r2508 RGB32------->Y8",align=7)
#Subtitle("r2508 RGB32->YV24->Y8",align=7)
#Subtitle("2.6MT RGB32------->Y8",align=7)

ConvertToRGB()

[pinterf]

Continuing the discussion from here (https://forum.doom9.org/showthread.php?p=1823329#post1823329), let's talk about those nasty memory offsets again.


In Avs+ all these size_t's are (32-bit signed) int instead. In Avisynth it doesn't really matter in practice because a frame is always allocated as one big chunk of memory, and nobody really has any use for more than 2^31 bytes of vfb. If you ever wanted to stop doing this though and use one individual pointer per plane like VS does, this won't fly because you can't reliably stuff a 64-bit pointer in a 32-bit integer, and it's generally bad coding practice to not use size_t (or ptrdiff_t) for these things.

Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue.

Thanks, then it's worth a try.

[Myrsloik]

Since we're on the subject of changes. Why was the return type of GetCPUFlags() changed from long to int? That one makes absolutely no sense to me.

[pinterf]

Since we're on the subject of changes. Why was the return type of GetCPUFlags() changed from long to int? That one makes absolutely no sense to me.
Another piece of history:
"Standardize some type usage to prevent confusion of devs with GCC background."
https://github.com/AviSynth/AviSynthPlus/commit/a6ced5b4b16e666d09b1d24c16269c2a15028712#diff-987740f99567909b32dd60d203ea9504

[pinterf]

r2508 RGB->Y8 [incorrect]
r2508 RGB->YV24->Y8 [correct]
2.6MT RGB->Y8 [correct]

Thanks for the report, fixed. Rec601, Rec709 (limited range) RGB->Y conversion was affected. Regression since r2266 (a lot of high bit depth work at that time)

[pinterf]

Continuing the discussion from here (https://forum.doom9.org/showthread.php?p=1823329#post1823329), let's talk about those nasty memory offsets again.


In Avs+ all these size_t's are (32-bit signed) int instead. In Avisynth it doesn't really matter in practice because a frame is always allocated as one big chunk of memory, and nobody really has any use for more than 2^31 bytes of vfb. If you ever wanted to stop doing this though and use one individual pointer per plane like VS does, this won't fly because you can't reliably stuff a 64-bit pointer in a 32-bit integer, and it's generally bad coding practice to not use size_t (or ptrdiff_t) for these things.

Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue.

Thanks, then it's worth a try.

Turned out that programs using C interface could be broken.

Current x264 is one of such programs, it fails, because it reads zero pitches (strides).

x264 [error]: Input picture width (640) is greater than stride (0)
x264 [error]: x264_encoder_encode failed

Having a look at the x264 source code, it contains a hybride avisynth_c.h (I guess that it is a mix of some previous headers from the "classic" avs line, inserted new high bit depth stuff from current avs+) in which the function avs_get_read_ptr_p (http://git.videolan.org/?p=x264.git;a=blob;f=extras/avisynth_c.h;h=81598790b1217e839eac01dffffd9ca540381f41;hb=HEAD#l491) is inlined and directly accesses the fields of AVS_VideoFrame struct (http://git.videolan.org/?p=x264.git;a=blob;f=extras/avisynth_c.h;h=81598790b1217e839eac01dffffd9ca540381f41;hb=HEAD#l480)
It fails because when we change the type of offset-like variables from int (32 bits) to size_t (64 bits on x64), the positions of fields in AVS_VideoFrame are shifted and a "baked" reference to the "pitch" now becomes the higher 32 bits of "offset", which is usually zero.

And that's only for x264. Anyway, when I'll make a test build, I will provide this "offsets are size_t instead of int" version as a separate test version.

If it could be changed it may work for current (int) and future (size_t) version of avisynth. Maybe it was inlined purposely, because older avisynth versions did not support avs_get_read_ptr_p through C interface (did not have time to dig into its history)?

To tell the truth, I had a look at the current avisynth_c.h from avs+ project, and although this specific call is O.K. in current version, there are two other problematic functions, namely
avs_get_row_size and avs_get_height (the ones without a "plane" parameter) so they apply on plane 0 (PLANAR_Y).

These functions are still directly accessing the AVS_VideoFrame contrary to the big warning "DO NOT USE THIS STRUCTURE DIRECTLY", so c interface header in avs+ is still inconsistent, at least for AVS_VideoFrame.

[TheFluff]

Ah, I hadn't considered that. Tricky.

[Shirtfull]

Thanks for the report, fixed. Rec601, Rec709 (limited range) RGB->Y conversion was affected. Regression since r2266 (a lot of high bit depth work at that time)

Rgb24 to yv12 seems incorrect as well, Frame served Progressive/interlaced testcube RGB24 from Virtualdub/VirtualDub_FilterMod to AvsPmod.

Rgb>yv12

https://s1.postimg.org/3m4qzr6lij/Test_avi000000a.jpg (http://postimg.org/image/3m4qzr6lij/)

Rgb>yv16

https://s1.postimg.org/5vnrj8rrez/Test_avi000000b.jpg (http://postimg.org/image/5vnrj8rrez/)

[pinterf]

Rgb24 to yv12 seems incorrect as well, Frame served Progressive/interlaced testcube RGB24 from Virtualdub/VirtualDub_FilterMod to AvsPmod.

Rgb>yv12

Rgb>yv16


I can see something like a rotation blur on the yv12 sample. How did you achieve that exactly?

[Shirtfull]

SetFilterMTMode("AVISource", x) #2or3
AVISource("Path to frameserve file.avi").ConvertToYv12() #12 or 16
bob()
Prefetch (4)

Only difference between pics was the conversion.

Take out bob, they both look the same.

[pinterf]

SetFilterMTMode("AVISource", x) #2or3
AVISource("Path to frameserve file.avi").ConvertToYv12() #12 or 16
bob()
Prefetch (4)

Only difference between pics was the conversion.

Take out bob, they both look the same.
Specify interlaced=true in ConvertToYV12.
RGB->YV12 conversion is a two-phase conversion. First comes RGB->YV24, then YV24->YV12. This latter needs the hint that the clip is an interlaced one.
(remark: parameter "interlaced" is used only in conversions where yv12 is involved either as source or target)

[Shirtfull]

Thanks, that fixed it.

[wonkey_monkey]

SetFilterMTMode("AVISource", x) #2or3
AVISource("Path to frameserve file.avi").ConvertToYv12() #12 or 16
bob()
Prefetch (4)

Only difference between pics was the conversion.

Take out bob, they both look the same.

Anyone know why it looks like some kind of rotation with the bob() in there? Seems weird.

[shekh]

Anyone know why it looks like some kind of rotation with the bob() in there? Seems weird.

I think VD does not have way to request interlaced conversion to YV12.
Looks better:
deinterlace (unfold)
convert format (yv12)
deinterlace (fold)

[Shirtfull]

The other way round, using VDFiltermod to generate cube and then frame-serving to avisynth. I recall it can only serve RGB.
https://s1.postimg.org/43ibe01o97/Create_test_video.jpg (https://postimg.org/image/43ibe01o97/)

[johnmeyer]

It appears that Prefetch cannot be used in a script which uses Return.

Here is my test. The following script runs at the same speed with, or without, the Prefetch statement. It is clear that multi-threading is NOT being used.

LoadPlugin("E:\Documents\My Videos\AVISynth\AVISynth Plugins\plugins\Film Restoration\Script_and_Plugins\RemoveGrainSSE2.dll")
source=AVISource("E:\fs.avi").killaudio().ConvertToYV12()
output=MDegrain2i2(source,8,4,400,0)
return output
Prefetch(5)

If I move Prefetch to the line before the "return output" statement, the script throws an error, "Invalid arguments to function 'Prefetch' ".

If I re-code so the script ends with the implied "last," as shown below, I get a 4x speedup (i.e., multi-threading is working), and don't get an error message. In other words, this works. However, it is a PITA to have to re-write scripts to avoid the return statement because I often want to do comparisons between the initial and final states of a denoising script, so it is useful to have a final "output" variable.

Is there a way to get Prefetch to work with Return, or I have I just found the only way?

LoadPlugin("E:\Documents\My Videos\AVISynth\AVISynth Plugins\plugins\Film Restoration\Script_and_Plugins\RemoveGrainSSE2.dll")
source=AVISource("E:\fs.avi").killaudio().ConvertToYV12()
MDegrain2i2(source,8,4,400,0)
Prefetch(5)

[poisondeathray]

Is there a way to get Prefetch to work with Return, or I have I just found the only way?


Don't use "return" , just call the variable directly

eg.


source = whateversource()
A = source().filter1()
B = source().filter2()

#source
A
#B
prefetch(5)


If you wanted "B" , comment out "A" and uncomment out B. If you wanted "source" - same idea, uncomment out source, comment out A and B

[johnmeyer]

Don't use "return" , just call the variable directly

eg.


source = whateversource()
A = source().filter1()
B = source().filter2()

#source
A
#B
prefetch(5)


If you wanted "B" , comment out "A" and uncomment out B. If you wanted "source" - same idea, uncomment out source, comment out A and BI just learned something: I thought I had to use "return." I need to re-read the AVISynth doc. Thanks!

[TheFluff]

return output.prefetch(5)

may or may not work

[LigH]

AviSynth (plus as well as legacy) internally uses a clip variable "last" where an explicit assignment is omitted (and an implicit "return last" where any return was omitted). Explicitly, this would act like:

source = whateversource()
A = source().filter1()
B = source().filter2()

#source
last = A
#last = B
last.prefetch(5)
return last

AviSynth will probably even detect that B is never used, therefore never execute "B = source().filter2()".

[StainlessS]

I nearly suggested same as Fluffy, but as I've never used MT/Avs+, thought it might be daft.

Perhaps docs could be updated to reflect that Prefetch takes a [EDIT: compulsory] clip arg (if indeed it does), docs as given on Avisynth.org/Avs+ below.

Enabling MT

The other difference is how you actually enable multithreading. Calling SetFilterMTMode() is not enough, it sets the MT mode, but the MT mode only has an effect if MT is enabled at all. Note this means you can safely include/import/autoload your SetFilterMTMode() calls in even single-threaded scripts, and they will not be messed up. Uhm, onto the point: 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.
Example



# This line causes all filters that don't have an MT mode explicitly use mode 2 by default.
# Mode 2 is a relatively safe choice until you don't know most of your calls to be either mode 1 or 3.
# Compared with mode 1, mode 2 trades memory for MT-safety, but only a select few filters will work with mode 1.
SetFilterMTMode("DEFAULT_MT_MODE", 2)
or
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)

# FFVideoSource(), like most of all source filters, needs MT mode 3.
# Note: starting with AviSynth+ r2069, it will now automatically recognize source filters.
# If it sees a source filter which has no MT-mode specified at all, it will automatically use
# mode 3 instead of the default MT mode.
SetFilterMTMode("FFVideoSource", 3)
or
SetFilterMTMode("FFVideoSource", MT_SERIALIZED)

# Now comes your script as usual
FFVideoSource(...)
Trim(...)
QTGMC(...)
...

# Enable MT!
Prefetch(4)

[LigH]

But important, when following StainlessS' form: Do not use "return" before "Prefetch". In case you do, the "return" statement is "the end of the script", not the last character.

[StainlessS]

But important, when following StainlessS' form: Do not use "return" before "Prefetch". In case you do, the "return" statement is "the end of the script", not the last character.

Are you saying that

return Last.Prefetch(4)

is equivalent to [EDIT: of course it dont work]

return
Last.Prefetch(4)

???

EDIT: OK, I think I get what you mean, simlar to John's earlier not working script.

Use eg

return output.Prefetch(4)
OR
output.Prefetch(4)
at the end of script (where no further parsing will occur on subsequent lines).

[LigH]

No, it would be equivalent to:

last = last.Prefetch(4)
return last

With "before", I mean "at least one line above, one linebreak in between"; "return" in the same line, just in front of the Prefetch result, would work.

[StainlessS]

OK, but both of my last two above code blocks would work, yes ?

EDIT: or that below will NOT work as planned.
return output.Prefetch(4)

EDIT: OK, thank you sir.

[LigH]

Using a variable "output" only works if you actually assigned the currently filtered clip to this clip variable; it is not an existing global symbol (but "last" is).

[pinterf]

A short question.
Lately moved to Visual Studio 2017.
Now Avisynth+ is built with v141_xp toolset instead of v140_xp (VS 2015).

I have put it to an xp virtual machine, which did not have Microsoft Visual C++ Redistributable for Visual Studio 2017 (https://www.visualstudio.com/downloads/).
I expected that it would crash with a nice exception but it was running instead. What function call should I use that would crash this vs2017-built dll with no new redistributables?

[Groucho2004]

What function call should I use that would crash this vs2017-built dll with no new redistributables?
No idea. Have you read through this (https://docs.microsoft.com/en-us/cpp/what-s-new-for-visual-cpp-in-visual-studio) (paragraph "Standard Library improvements")? You might also want to look at this (https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp).

[pinterf]

No idea. Have you read through this (https://docs.microsoft.com/en-us/cpp/what-s-new-for-visual-cpp-in-visual-studio) (paragraph "Standard Library improvements")? You might also want to look at this (https://docs.microsoft.com/en-us/cpp/porting/overview-of-potential-upgrade-issues-visual-cpp).
Thanks. I reached here:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017 (https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017)
It says that in our case they are compatible, because the major number is to the toolsets (v140, v141) is 14.
(Does it mean that for a freshly installed system, it's enough to have the VS2017 redistributables for our old dlls that would need VS2015 redist in the past?)

[Myrsloik]

Thanks. I reached here:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2017 (https://docs.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017)
It says that in our case they are compatible, because the major number is to the toolsets (v140, v141) is 14.
(Does it mean that for a freshly installed system, it's enough to have the VS2017 redistributables for our old dlls that would need VS2015 redist in the past?)

Yes, if you look at installed programs the 2017 runtime actually replaces the 2015 one

[real.finder]

since there are many plugins dll's that didn't port to x64 including the closed source plugins, is there some ways to make the 32 bit one work in 64 processes? I note this http://www.dllwrapper.com/ but couldn't build wrapped dll successfully, and even if I did, it will work one day only (need to buy it)

[LigH]

I guess it might be possible in a separate 32-bit sub process (with a "bridge" EXE in between), but that would probably be quite inefficient, possibly requiring frame data to be piped (like the avs2yuv or avs4x26x bridges do).

Could you name any "priceless" plugins you know some users can't live without?

[real.finder]

I guess it might be possible in a separate 32-bit sub process (with a "bridge" EXE in between), but that would probably be quite inefficient, possibly requiring frame data to be piped (like the avs2yuv or avs4x26x bridges do).

Could you name any "priceless" plugins you know some users can't live without?

I think that dllwrapper use bridge EXE for that

about the "priceless" plugins, it depend on the source you work with it, but there are many, mostly used in avsi script functions

[TheFluff]

People keep saying that but they never cite any actual examples. If you actually say what you want maybe someone will actually modernize it!

[LigH]

Somehow I think about "glorified anime miracle scripts" right now...

[real.finder]

ok then, like removedirt, deen, TBilateral, removegrainT, LGhost

edit: and AVSInpaint (for FillBorders() in Stabilization Tools Pack by Dogway)

[Yanak]

ok then, like removedirt, deen, TBilateral, removegrainT, LGhost

edit: and AVSInpaint (for FillBorders() in Stabilization Tools Pack by Dogway)
AvsInpaint.dll used also with InpaintFunc.avs which is the logo remover i get best results with, many Vdub Plugins not natively supported in x64 too, hopefully MP_Pipeline exists and can run some parts of a .avs in win32 mode + some good souls managed to port some other very nice plugins on x64 recently.

This said i gave up on many x86 plug-ins that looked interesting on the paper for some specific tasks i had to do and needed a solution for but did not bothered with long processing and headache of not being able to pass some variables from one process mode to the other and in the end found other ways to do what i needed using other tools outside avisytnh or simply gave up on those projects.

Being able to run natively and more smoothly some x86 stuff like MP_Pipeline allows it will be a dream, but i keep this as a dream :)

[real.finder]

AvsInpaint.dll used also with InpaintFunc.avs which is the logo remover i get best results with, many Vdub Plugins not natively supported in x64 too, hopefully MP_Pipeline exists and can run some parts of a in win32 mode + some good souls managed to port some other very nice plugins on x64 recently.

This said i gave up on many x86 plug-ins that looked interesting on the paper for some specific tasks i had to do and needed a solution for but did not bothered with long processing and headache of not being able to pass some variables from one process mode to the other and in the end found other ways to do what i needed using other tools outside avisytnh or simply gave up on those projects.

Being able to run natively and more smoothly some x86 stuff like MP_Pipeline allows it will be a dream, but i keep this as a dream :)

mpp is good but it's complicated for some people, has some limit like you can't use """ """ and you can't use some avs+ Features in it (https://github.com/SAPikachu/MP_Pipeline/issues/1), no audio support, and has some overhead ofc

and aside from mpp downside, if there are one plugin that lacking x64 port in some function then you have to use the x86 just for it!

[pinterf]

All good things must come to an end: now I stopped optimizing Expr so have fun with this release.

This version - along with fixing some annoying bugs - features the Expr filter, which was ported from the Vapoursynth project. Although it was ported in one day, tweaking it further took a _lot_ more time and of course, a good entertainment.

Download Avisynth+ r2542 (20171114) (https://github.com/pinterf/AviSynthPlus/releases/tag/r2542-MT)

Questions, testing are welcome.

Please read the "readme.txt" for details about Expr, until the documentation appears in the avisynth webpage.

# Avisynth+ r2542 (20171114)

## Fixes
- Fix: RGB (full scale) conversion: 10-16 bits to 8 bits rounding issue; pic got darker in repeated 16<->8 bit conversion chain
- Fix: ConvertToY: remove unnecessary clamp for Planar RGB 32 bit float
- Fix: RGB ConvertToY when rec601, rec709 (limited range) matrix. Regression since r2266

## modification, additions
- Add: Expr filter
- Add: Levels: 32 bit float format support
- Optimized: Faster RGB (full scale) 10-16 bits to 8 bits conversion when dithering
- Other: Default frame alignment is 64 bytes (was: 32 bytes). (independently of AVX512 support)
- Built with Visual Studio 2017, v141_xp toolset
- some fixes in avisynth_c.h (C interface header file)
- experimental x64 build with size_t frame offsets for testing more properly written C interfaces


edit: quick info about Expr (from readme):
Expr filter

Syntax ("c+s+[format]s[optAvx2]b[optSingleMode]b[optSSE2]b")
clip Expr(clip c[,clip c2, ...], string expr [, string expr2[, string expr3[, string expr4]]] [, string format]
[, bool optSSE2][, bool optAVX2][, bool optSingleMode])

Clip and Expr parameters are unnamed
'format' overrides the output video format
'optSSE2' to disable simd optimizations (use C code)
'optAVX2' to disable AVX2 optimizations (use SSE2 code)
'optSingleMode' default false, to generate simd instructions for one XMM/YMM wide data instead of two. Experimental.
One simd cycle processes 8 pixels (SSE2) or 16 pixels (AVX2) at a time by using two XMM/YMM registers as working set.
Very-very complex expressions would use too many XMM/YMM registers which are then "swapped" to memory slots, that can be slow.
Using optSingleMode = true may result in using less registers with no need for swapping them to memory slots.

Expr accepts 1 to 26 clips as inputs and up to four expression strings, an optional video format overrider, and some debug parameters.
Output video format is inherited from the first clip, when no format override.
All clips have to match their dimensions and plane subsamplings.

Expressions are evaluated on each plane, Y, U, V (and A) or R, G, B (,A).
When an expression string is not specified, the previous expression is used for that plane. Except for plane A (alpha) which is copied by default.
When an expression is an empty string ("") then the relevant plane will be copied (if the output clip bit depth is similar).
When an expression is a single clip reference letter ("x") and the source/target bit depth is similar, then the relevant plane will be copied.
When an expression is constant, then the relevant plane will be filled with an optimized memory fill method.
Expressions are written in Reverse Polish Notation (RPN).

Expressions use 32 bit float precision internally

For 8..16 bit formats output is rounded and clamped from the internal 32 bit float representation to valid 8, 10, ... 16 bits range.
32 bit float output is not clamped at all.

- Clips: letters x, y, z, a, ... w. x is the first clip parameter, y is the second one, etc.
- Math: * / + -
- Math constant: pi
- Functions: min, max, sqrt, abs, neg, exp, log, pow ^ (synonyms: "pow" and "^")
- Logical: > < = >= <= and or xor not == & | != (synonyms: "==" and "=", "&" and "and", "|" and "or")
- Ternary operator: ?
- Duplicate stack: dup, dupN (dup1, dup2, ...)
- Swap stack elements: swap, swapN (swap1, swap2, ...)
- Scale by bit shift: scaleb (operand is treated as being a number in 8 bit range unless i8..i16 or f32 is specified)
- Scale by full scale stretch: scalef (operand is treated as being a number in 8 bit range unless i8..i16 or f32 is specified)
- Bit-depth aware constants
ymin, ymax (ymin_a .. ymin_z for individual clips) - the usual luma limits (16..235 or scaled equivalents)
cmin, cmax (cmin_a .. cmin_z) - chroma limits (16..240 or scaled equivalents)
range_half (range_half_a .. range_half_z) - half of the range, (128 or scaled equivalents)
range_size, range_half, range_max (range_size_a .. range_size_z , etc..)
- Keywords for modifying base bit depth for scaleb and scalef: i8, i10, i12, i14, i16, f32
- Spatial input variables in expr syntax:
sx, sy (absolute x and y coordinates, 0 to width-1 and 0 to height-1)
sxr, syr (relative x and y coordinates, from 0 to 1.0)

Additions and differences to VS r39 version:
------------------------------
(similar features to the masktools mt_lut family syntax)

Aliases:
introduced "^", "==", "&", "|"
New operator: != (not equal)
Built-in constants
ymin, ymax (ymin_a .. ymin_z for individual clips) - the usual luma limits (16..235 or scaled equivalents)
cmin, cmax (cmin_a .. cmin_z) - chroma limits (16..240 or scaled equivalents)
range_half (range_half_a .. range_half_z) - half of the range, (128 or scaled equivalents)
range_size, range_half, range_max (range_size_a .. range_size_z , etc..)
Autoscale helper functions (operand is treated as being a number in 8 bit range unless i8..i16 or f32 is specified)
scaleb (scale by bit shift - mul or div by 2, 4, 6, 8...)
scalef (scale by stretch full scale - mul or div by source_max/target_max
Keywords for modifying base bit depth for scaleb and scalef
: i8, i10, i12, i14, i16, f32
Built-in math constant
pi
Alpha plane handling. When no separate expression is supplied for alpha, plane is copied instead of reusing last expression parameter.
Proper clamping when storing 10, 12 or 14 bit outputs
(Faster storing of results for 8 and 10-16 bit outputs, fixed in VS r40)
16 pixels/cycle instead of 8 when avx2, with fallback to 8-pixel case on the right edge. Thus no need for 64 byte alignment for 32 bit float.
(Load zeros for nonvisible pixels, when simd block size goes beyond image width, to prevent garbage input for simd calculation)

Optimizations for pow: x^0.5 is sqrt, ^2, ^3, ^4 is done by faster and more precise multiplication
Spatial input variables in expr syntax:
sx, sy (absolute x and y coordinates, 0 to width-1 and 0 to height-1)
sxr, syr (relative x and y coordinates, from 0 to 1.0)
Optimize: recognize constant plane expression: use fast memset instead of generic simd process. Approx. 3-4x (32 bits) to 10-12x (8 bits) speedup
Optimize: Recognize single clip letter in expression: use fast plane copy (BitBlt)
(e.g. for 8-16 bits: instead of load-convert_to_float-clamp-convert_to_int-store). Approx. 1.4x (32 bits), 3x (16 bits), 8-9x (8 bits) speedup
Optimize: do not call GetFrame for input clips that are not referenced or plane-copied
Recognize constant expression: use fast memset instead of generic simd process. Approx. 3-4x (32 bits) to 10-12x (8 bits) speedup
Example: Expr(clip,"128","128,"128")

Differences from masktools 2.2.10
--------------------------------
Up to 26 clips are allowed (x,y,z,a,b,...w). Masktools handles only up to 4 clips with its mt_lut, my_lutxy, mt_lutxyz, mt_lutxyza

- Clips with different bit depths are allowed
- Works with 32 bit floats instead of 64 bit double internally
- Less functions (e.g. no bit shifts)
- No float clamping and float-to-8bit-and-back load/store autoscale magic (yet)
- Logical 'false' is 0 instead of -1
- The ymin, ymax, etc built-in constants can have a _X suffix, where X is the corresponding clip designator letter. E.g. cmax_z, range_half_x
- mt_lutspa-like functionality is available through "sx", "sy", "sxr", "syr"
- No y= u= v= parameters with negative values for filling plane with constant value, constant expressions are changed into optimized "fill" mode

Sample:

Average three clips:
c = Expr(clip1, clip2, clip3, "x y + z + 3 /")

using spatial feature:
c = Expr(clip1, clip2, clip3, "sxr syr 1 sxr - 1 syr - * * * 4096 scaleb *", "", "")

[Myrsloik]

About how much faster is avx2 vs sse2 on a modern cpu in your expr version?

[real.finder]

thanks pinterf

- Clips with different bit depths are allowed

some friend that use vs said that float <- -> int is broken in vs expr, did you note that and fix it?

[pinterf]

About how much faster is avx2 vs sse2 on a modern cpu in your expr version?

I had to do that in blind mode, I have no AVX2, only through SDE emulator. I could test it only two days ago on a 2 yr old i5 notebook and the results show that it was worth to implement.
Other speed tests are welcome, that's why there are optXXX parameters.


results in fps
avx2: set it only in Expr through optAvx2 parameter
bits i5 sse2 32/64 bit i5Avx2 32/64 bit
8 17.00 19.30 24.63 28.98
16 15.69 17.59 20.38 23.26
32 12.70 13.59 16.03 17.14


The script was something like this (deleted my debug experimental commented out lines)
lsmashvideosource("13HoursCUT.mp4", format="YUV444P8")
Spline64Resize(486,240) #resize, result is a multistacked image
src=last
# expr
c8 = CalcTest(src,8, False)
c16 = CalcTest(src,16, False)
c32 = CalcTest(src,32, False)

# lutxy
c8e = CalcTest(src,8, True)
c16e = CalcTest(src,16, True)
c32e = CalcTest(src,32, True)

res8=Diff(c8,src)
res16=Diff(c16,src)
res32=Diff(c32,src)

res8e=Diff(c8e,src)
res16e=Diff(c16e,src)
res32e=Diff(c32e,src)

col1=StackVertical(c8,c16.convertbits(8),c32.convertbits(8))
col2=StackVertical(res8, res16, res32)
col3=StackVertical(c8e,c16e.convertbits(8),c32e.convertbits(8))
col4=StackVertical(res8e, res16e, res32e)
StackHorizontal(col1, col2, col3, col4)

#used only c8, c16 or c32 output for speed test from the clips above.
# change parameters. e.g. optSSE2=true, optSingleMode=false, optAvx2=false
c8

Function Diff(clip src1, clip src2)
{
return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

Function CalcTest(clip src, int bits, bool lut)
{
src
convertbits(bits)
tmp=last
method=Blur(1)

szrp=16
spwr=4
str=100/100.0
sdmplo=4
sdmphi=48
expr_pow = "x y == x x x y - abs "+string(Szrp) +" scaleb / 1 "+string(Spwr)+" / ^ "+string(Szrp) +" scaleb * "+string(str)+" * x y - 2 ^ x y - 2 ^ "
\+string(SdmpLo)+" scaleb scaleb + / * x y - x y - abs / * 1 "+string(SdmpHi)+" scaleb 0 == 0 x y - abs "+string(SdmpHi)+" scaleb / 4 ^ ? + / + ?"

ret=lut ? mt_lutxy(tmp,method, yexpr=expr_pow, U=1,V=1 ) : Expr(tmp,method,expr_pow,"","", optSSE2=true, optSingleMode=false, optAvx2=false)
return ret
}

[pinterf]

thanks pinterf



some friend that use vs said that float <- -> int is broken in vs expr, did you note that and fix it?

Yes, fixed and noted.

[ryrynz]

Any idea when your commits going to merge officially? You're the only one spearheading code in right now.

[wonkey_monkey]

sxr, syr (relative x and y coordinates, from 0 to 1.0)

Aren't those normalised, rather than relative?

[pinterf]

Aren't those normalised, rather than relative?
Yes, normalized but I took the terminology from here:
http://avisynth.nl/index.php/MaskTools2/mt_lutspa

[edcrfv94]

I change mt_lutxy to Expr then limit function no work any more.


Function kf_limit_dif8_expr(clip filtered, clip original, bool "smooth", float "thr", float "elast", float "darkthr", int "Y", int "U", int "V")
{
sCSP = filtered.kf_GetCSP()
IsY8 = sCSP == "Y8"

smooth = Default(smooth, True )
thr = Default(thr, 1.0 )
elast = Default(elast, smooth ? 3.0 : 255./thr)
darkthr = Default(darkthr,thr )
Y = Default(Y, 3 )
U = Default(U, 3 )
V = Default(V, 3 )

Y = min(Y, 4)
U = min(U, 4)
V = min(V, 4)

thr = max(min( thr, 255.0), 0.0)
darkthr = max(min(darkthr, 255.0), 0.0)
elast = max(elast, 1.0)
mode = thr == 0 && darkthr == 0 ? 4 : thr == 255 && darkthr == 255 ? 2 : 3
smooth = elast==1 ? False : smooth

diffstr = " x y - "
elaststr = " "+string(elast)+" "

thrstr = diffstr+" 0 > "+string(darkthr)+" scalef "+string(thr)+" scalef ? "
alphastr = elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstr+" * / ? "
betastr = thrstr+elaststr+" * "
sexpr = smooth ? alphastr+diffstr+" * "+betastr+diffstr+" abs - * y + "
\ : thrstr+diffstr+diffstr+" abs / * y + "
expr = diffstr+" abs "+thrstr+" <= x "+diffstr+" abs "+betastr+" >= y "+sexpr+" ? ? "

thrstrc = " "+string(thr)+" scalef "
alphastrc= elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstrc+" * / ? "
betastrc = thrstrc+elaststr+" * "
sexprc = smooth ? alphastrc+diffstr+" * "+betastrc+diffstr+" abs - * y + "
\ : thrstrc+diffstr+diffstr+" abs / * y + "
exprc = diffstr+" abs "+thrstrc+" <= x "+diffstr+" abs "+betastrc+" >= y "+sexprc+" ? ? "

# diff = filtered - original
# alpha = 1 / (thr * (elast - 1))
# beta = elast * thr
# When smooth=True :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + alpha * diff * (beta - abs(diff))
# When smooth=False :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + thr * (diff / abs(diff))

expry = (Y == 3) ? expr : ""
expru = (U == 3) ? exprc : ""
exprv = (V == 3) ? exprc : ""

return (mode == 4) ? original
\ : (mode == 2) ? filtered
\ : IsY8 ? Expr(filtered, original, expry, optSSE2=true, optSingleMode=false, optAvx2=true)
\ : Expr(filtered, original, expry, expru, exprv, optSSE2=true, optSingleMode=false, optAvx2=true)
}



Function kf_limit_dif8_mt(clip filtered, clip original, bool "smooth", float "thr", float "elast", float "darkthr", int "Y", int "U", int "V")
{

smooth = Default(smooth, True )
thr = Default(thr, 1.0 )
elast = Default(elast, smooth ? 3.0 : 255./thr)
darkthr = Default(darkthr,thr )
Y = Default(Y, 3 )
U = Default(U, 3 )
V = Default(V, 3 )

Y = min(Y, 4)
U = min(U, 4)
V = min(V, 4)

thr = max(min( thr, 255.0), 0.0)
darkthr = max(min(darkthr, 255.0), 0.0)
elast = max(elast, 1.0)
mode = thr == 0 && darkthr == 0 ? 4 : thr == 255 && darkthr == 255 ? 2 : 3
smooth = elast==1 ? False : smooth

diffstr = " x y - "
elaststr = " "+string(elast)+" "

thrstr = diffstr+" 0 > "+string(darkthr)+" scalef "+string(thr)+" scalef ? "
alphastr = elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstr+" * / ? "
betastr = thrstr+elaststr+" * "
sexpr = smooth ? alphastr+diffstr+" * "+betastr+diffstr+" abs - * y + "
\ : thrstr+diffstr+diffstr+" abs / * y + "
expr = diffstr+" abs "+thrstr+" <= x "+diffstr+" abs "+betastr+" >= y "+sexpr+" ? ? "

thrstrc = " "+string(thr)+" scalef "
alphastrc= elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstrc+" * / ? "
betastrc = thrstrc+elaststr+" * "
sexprc = smooth ? alphastrc+diffstr+" * "+betastrc+diffstr+" abs - * y + "
\ : thrstrc+diffstr+diffstr+" abs / * y + "
exprc = diffstr+" abs "+thrstrc+" <= x "+diffstr+" abs "+betastrc+" >= y "+sexprc+" ? ? "

# diff = filtered - original
# alpha = 1 / (thr * (elast - 1))
# beta = elast * thr
# When smooth=True :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + alpha * diff * (beta - abs(diff))
# When smooth=False :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + thr * (diff / abs(diff))

return mode == 4 ? original
\ : mode == 2 ? filtered
\ : mt_lutxy(filtered, original, yExpr=expr, uExpr=exprc, vExpr=exprc, Y=Y, U=U, V=V)
}

[pinterf]

I change mt_lutxy to Expr then limit function no work any more.

Could you specify your calling parameters and what should I look for in the results?

[edcrfv94]

Could you specify your calling parameters and what should I look for in the results?

The result is very different.


SetMemoryMax(3000)

#colorbars(width=1920, height=1080, pixel_type="yv12").killaudio().assumefps(25, 1)
ImageSource("1.png", end=0).Dither_convert_rgb_to_yuv(lsb=true,output="YV12").DitherPost(mode=6)

ConvertToY8()
trim(0, 5000)
#Limiter()
#InvertNeg()
#VToY()

src = last.ConvertBits(bits=16)

sharp = src.Sharpen(1.0).Sharpen(1.0)

kf_limit_dif8_mt_test(sharp, src, thr=1, elast=42, y=3, u=1, v=1)
#kf_limit_dif8_expr_test(sharp, src, thr=1, elast=42, y=3, u=1, v=1)

ConvertToStacked().DitherPost(mode=6, ampo=1)

Function kf_limit_dif8_expr_test(clip filtered, clip original, bool "smooth", float "thr", float "elast", float "darkthr", int "Y", int "U", int "V")
{
sCSP = filtered.kf_GetCSP()
IsY8 = sCSP == "Y8"

smooth = Default(smooth, True )
thr = Default(thr, 1.0 )
elast = Default(elast, smooth ? 3.0 : 255./thr)
darkthr = Default(darkthr,thr )
Y = Default(Y, 3 )
U = Default(U, 3 )
V = Default(V, 3 )

Y = min(Y, 4)
U = min(U, 4)
V = min(V, 4)

thr = max(min( thr, 255.0), 0.0)
darkthr = max(min(darkthr, 255.0), 0.0)
elast = max(elast, 1.0)
mode = thr == 0 && darkthr == 0 ? 4 : thr == 255 && darkthr == 255 ? 2 : 3
smooth = elast==1 ? False : smooth

diffstr = " x y - "
elaststr = " "+string(elast)+" "

thrstr = diffstr+" 0 > "+string(darkthr)+" scalef "+string(thr)+" scalef ? "
alphastr = elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstr+" * / ? "
betastr = thrstr+elaststr+" * "
sexpr = smooth ? alphastr+diffstr+" * "+betastr+diffstr+" abs - * y + "
\ : thrstr+diffstr+diffstr+" abs / * y + "
expr = diffstr+" abs "+thrstr+" <= x "+diffstr+" abs "+betastr+" >= y "+sexpr+" ? ? "

thrstrc = " "+string(thr)+" scalef "
alphastrc= elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstrc+" * / ? "
betastrc = thrstrc+elaststr+" * "
sexprc = smooth ? alphastrc+diffstr+" * "+betastrc+diffstr+" abs - * y + "
\ : thrstrc+diffstr+diffstr+" abs / * y + "
exprc = diffstr+" abs "+thrstrc+" <= x "+diffstr+" abs "+betastrc+" >= y "+sexprc+" ? ? "

# diff = filtered - original
# alpha = 1 / (thr * (elast - 1))
# beta = elast * thr
# When smooth=True :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + alpha * diff * (beta - abs(diff))
# When smooth=False :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + thr * (diff / abs(diff))

expry = (Y == 3) ? expr : ""
expru = (U == 3) ? exprc : ""
exprv = (V == 3) ? exprc : ""

return (mode == 4) ? original
\ : (mode == 2) ? filtered
\ : IsY8 ? Expr(filtered, original, expry, optSSE2=true, optSingleMode=false, optAvx2=true)
\ : Expr(filtered, original, expry, expru, exprv, optSSE2=true, optSingleMode=false, optAvx2=true)
}

Function kf_limit_dif8_mt_test(clip filtered, clip original, bool "smooth", float "thr", float "elast", float "darkthr", int "Y", int "U", int "V")
{

smooth = Default(smooth, True )
thr = Default(thr, 1.0 )
elast = Default(elast, smooth ? 3.0 : 255./thr)
darkthr = Default(darkthr,thr )
Y = Default(Y, 3 )
U = Default(U, 3 )
V = Default(V, 3 )

Y = min(Y, 4)
U = min(U, 4)
V = min(V, 4)

thr = max(min( thr, 255.0), 0.0)
darkthr = max(min(darkthr, 255.0), 0.0)
elast = max(elast, 1.0)
mode = thr == 0 && darkthr == 0 ? 4 : thr == 255 && darkthr == 255 ? 2 : 3
smooth = elast==1 ? False : smooth

diffstr = " x y - "
elaststr = " "+string(elast)+" "

thrstr = diffstr+" 0 > "+string(darkthr)+" scalef "+string(thr)+" scalef ? "
alphastr = elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstr+" * / ? "
betastr = thrstr+elaststr+" * "
sexpr = smooth ? alphastr+diffstr+" * "+betastr+diffstr+" abs - * y + "
\ : thrstr+diffstr+diffstr+" abs / * y + "
expr = diffstr+" abs "+thrstr+" <= x "+diffstr+" abs "+betastr+" >= y "+sexpr+" ? ? "

thrstrc = " "+string(thr)+" scalef "
alphastrc= elaststr+" 1 <= 0 1 "+elaststr+" 1 - "+thrstrc+" * / ? "
betastrc = thrstrc+elaststr+" * "
sexprc = smooth ? alphastrc+diffstr+" * "+betastrc+diffstr+" abs - * y + "
\ : thrstrc+diffstr+diffstr+" abs / * y + "
exprc = diffstr+" abs "+thrstrc+" <= x "+diffstr+" abs "+betastrc+" >= y "+sexprc+" ? ? "

# diff = filtered - original
# alpha = 1 / (thr * (elast - 1))
# beta = elast * thr
# When smooth=True :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + alpha * diff * (beta - abs(diff))
# When smooth=False :
# output = diff <= thr ? filtered : \
# diff >= beta ? original : \
# original + thr * (diff / abs(diff))

return mode == 4 ? original
\ : mode == 2 ? filtered
\ : mt_lutxy(filtered, original, yExpr=expr, uExpr=exprc, vExpr=exprc, Y=Y, U=U, V=V)
}

Function kf_GetCSP(clip c)
{
try {
csp = c.kf_GetCSP_avsPlus()
} catch (error_msg) {
csp = c.kf_GetCSP_avs()
}
return csp
}


Function kf_GetCSP_avs(clip c)
{
return c.IsPlanar ? c.IsYV12 ? "YV12" :
\ c.IsYV16 ? "YV16" :
\ c.IsYV24 ? "YV24" : c.kf_GetCSP_Y8_YV411() :
\ c.IsYUY2 ? "YUY2" :
\ c.IsRGB32 ? "RGB32" :
\ c.IsRGB24 ? "RGB24" : "Unknown"

Function kf_GetCSP_Y8_YV411(clip c) {
try {
c.UtoY
csp = "YV411"
} catch (error_msg) {
csp = "Y8"
}
return csp
}
}

Function kf_GetCSP_avsPlus(clip c)
{
return c.Is420 ? "YV12" :
\ c.IsY ? "Y8" :
\ c.Is422 ? "YV16" :
\ c.Is444 ? "YV24" :
\ c.IsYUVA ? "YUVA" :
\ c.IsYV411 ? "YV411" :
\ c.IsYUY2 ? "YUY2" :
\ c.IsRGB32 ? "RGB32" :
\ c.IsRGB24 ? "RGB24" :
\ c.IsPackedRGB ? "RGB32/RGB24" :
\ c.IsPlanarRGB ? "RGB48" :
\ c.IsPlanarRGBA ? "RGB64" : "Unknown"
}

[pinterf]

The result is very different.
...code...

Thanks, scalef bug in 10-16 bits. scaleb was o.k.
I'll wait a bit before make the new version with the fix.

[pinterf]

New build with a hotfix

Download Avisynth+ r2544 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2544-MT)

20171115 r2544
- Expr: fix "scalef" for 10-16 bits
- Expr optimization: eliminate ^1 +0 -0 *1 /1

[ryrynz]

Gave the sizetmod a try but have it crash every time. Tried a simple script through ffdshow raw.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
ffdshow_source()
aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel.aBlur(), depth=2)
Prefetch(4)

MadVR ends up crashing, no issues with the normal build.

[pinterf]

Gave the sizetmod a try but have it crash every time. Tried a simple script through ffdshow raw.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
ffdshow_source()
aWarp4(Spline36Resize(width*4, height*4, 0.375, 0.375), aSobel.aBlur(), depth=2)
Prefetch(4)

MadVR ends up crashing, no issues with the normal build.
Thanks. Do you know if anything in this chain is using CPP 2.5 or C interface?

For me they (x64 plugins with CPP 2.5 interface) are crashing with the sizetmod build. No wonder, 2.5 is the "baked" code interface.

I don't like them. For example supporting 2.5 prevented me last year to introduce the array type. Now this.

They badly need at least a recompile for 2.6.

[tormento]

Experimental x64 crashing here.

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\1_37 Swiss Army man — Un amico multiuso\swiss.dgi")

#CompTest(1)

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=0)

Prefetch(6)

[ryrynz]

Thanks. Do you know if anything in this chain is using CPP 2.5 or C interface?


Shouldn't be. Awarp4, asobel and a blur are all part of the x64 build of Awarpsharp you compiled and is the latest version you released, it should be compatible.

[pinterf]

Shouldn't be. Awarp4, asobel and a blur are all part of the x64 build of Awarpsharp you compiled and is the latest version you released, it should be compatible.
Perhaps the source filter?

For example LSmashSource (CPP v2.5 as Avsmeter64 reports) is crashing for me. ffms2 is OK.

[pinterf]

Experimental x64 crashing here.

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\1_37 Swiss Army man — Un amico multiuso\swiss.dgi")

#CompTest(1)

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=0)

Prefetch(6)
Thanks.
I don't know about the source filter, I have replaced it with ffms2.
The script still crashed with lsb=true.
Unfortunately dither.dll is a 2.5 style plugin.
With lsb=false the script is working properly with the given parameters.

Edit: rebuilt dither.dll, replaced the 2.5-style avisynth.h with the 2.6-style avs+ header (not even the size_t mod version) and no more crash with lsb=true.

[tormento]

Edit: rebuilt dither.dll, replaced the 2.5-style avisynth.h with the 2.6-style avs+ header (not even the size_t mod version) and no more crash with lsb=true.

Ahem... post new dither here :)

[pinterf]

Ahem... post new dither here :)
It does not help at the moment.
LSmashSource, dither, AddGrainC, x264_64, and a lot more cpp 2.5 plugins and 2.5 c interface user apps are out there.
Just have a look at the CPP 2.5 list of avsmeter -avsinfo.

[tormento]

It does not help at the moment.
LSmashSource, dither, AddGrainC, x264_64, and a lot more cpp 2.5 plugins and 2.5 c interface user apps are out there.
Just have a look at the CPP 2.5 list of avsmeter -avsinfo.

[CPP 2.5 / 64 Bit Plugins]
D:\Programmi\Media\AviSynth+\plugins64\Dither-1.27.2.dll
D:\Programmi\Media\AviSynth+\plugins64\f3kdb-2.020140721-SAPikachu.dll
To me is more than enough! It's the only filter I use still 2.5!

[Yanak]

https://s14.postimg.org/60ya489nl/81555120171117110558cr.png

Not sure if my used plugins are all up to date and /or if some others could be replaced by something else tho but things like LSmashSource, Avsinpaint, MP_Pipeline are essential for me and i don't think there is any alternative to those :/

[Myrsloik]

Sigh, I was actually about to do some proper avx2 speed tests. Then I saw that there's no installer and I'm going to go eat cookies instead. That is all.

[real.finder]

Sigh, I was actually about to do some proper avx2 speed tests. Then I saw that there's no installer and I'm going to go eat cookies instead. That is all.

put the Avisynth dll in same folder as avsmeter and it will work

iirc avsmeter allow you to use Avisynth dll from specific path too

[LigH]

Also there is the Universal Avisynth Installer (https://forum.doom9.org/showthread.php?t=172124) which is just as regularly updated as the github releases. Just check at least twice how to set up the batch file with custom installation directories before use, especially when the path may contain spaces.

[Groucho2004]

especially when the path may contain spaces.There's no problem with spaces. However, some special characters such as parentheses and ampersands need an escape character.

[jinkazuya]

Just get a question for pinterf or anybody else who has experience with avisynth+ MT. Just wonder if it is ok to add support for using more than 10 threads in the next avisynth+ MT build. In other word, will CPU like intel Intel® Core™ i9 series or AMD Ryzen or Threadripper be fully taken advantages of all their cores? Cuz right now whenever I use more than 10 or 11 threads, then MEGUI or the x264 will crash or freeze and cannot use over 10 threads.

[DJATOM]

jinkazuya
Just set reasonable Prefetch() and SetMemoryMax() and you will have near 100% CPU usage.

[pinterf]

Yes, as the memory usage (cache) is somewhat linear to the number of Prefetch threads, you are probably experiencing memory full issues. You can try AvsMeter with your script to see whether the memory usage is the bottleneck.
As DJATOM said you can experiment with SetMemoryMax and Prefetch count to see where it saturates your available memory. x64 version is recommended however (I don't know which version you are using)

[sneaker_ger]

Question.

Script:
ffVideoSource("cut.mkv")
mask=MaskHS(160,180, 100,80).mt_expand().BilinearResize(last.width, last.height)
overlay(last, GreyScale().ColorYUV(cont_y=50), 0, 0, mask)
Sample: https://mega.nz/#!tpUhhSZR!6g1OSKRzZAuu9pYL_t03O32PRlGgPeQwTRxU2dkuTbo

AviSynth 2.6.0:
https://forum.videohelp.com/attachment.php?attachmentid=25221&d=1478969615&thumb=1

AvisynthPlus-r2544-MT:
https://forum.videohelp.com/attachment.php?attachmentid=43857


Why does it become grey?

[pinterf]

Question.

Script:
ffVideoSource("cut.mkv")
mask=MaskHS(160,180, 100,80).mt_expand().BilinearResize(last.width, last.height)
overlay(last, GreyScale().ColorYUV(cont_y=50), 0, 0, mask)
Sample: https://mega.nz/#!tpUhhSZR!6g1OSKRzZAuu9pYL_t03O32PRlGgPeQwTRxU2dkuTbo

AviSynth 2.6.0:

AvisynthPlus-r2544-MT:



Why does it become grey?
MaskHS is giving a black clip for me on classic avs, and white on current avs+. And the whiteish mask makes the greyscale clip dominant.
Checked: r2173 was still o.k.

Edit: fixed on github. MaskHS was giving the inverse mask.

[sneaker_ger]

Thank you.

[jinkazuya]

Yes, as the memory usage (cache) is somewhat linear to the number of Prefetch threads, you are probably experiencing memory full issues. You can try AvsMeter with your script to see whether the memory usage is the bottleneck.
As DJATOM said you can experiment with SetMemoryMax and Prefetch count to see where it saturates your available memory. x64 version is recommended however (I don't know which version you are using)

Ok, What do you guys suggest I do for the prefetch and setMemoryMax?

I have 32GB of ram and 16 cores? Even if I boost the setMemoryMax to higher number, checking and monitoring the RAM, the computer uses only about 3GB or 5GB most. But if I set prefetch over 10 to 11, then MEGUI crashes.

I uses x86 version cuz if I use the x64, most of the older plugins won't work.

[DJATOM]

I'm using setmemorymax(32000) and prefetch(24) on dual socket Xeon 5675 server with ~50 GB RAM, average load near 99%.

>I uses x86 version cuz if I use the x64, most of the older plugins won't work.
Just forget about high prefetch values with 32 bit avisynth. You will hit 32 bit app memory limit.

[jinkazuya]

I'm using setmemorymax(32000) and prefetch(24) on dual socket Xeon 5675 server with ~50 GB RAM, average load near 99%.

>I uses x86 version cuz if I use the x64, most of the older plugins won't work.
Just forget about high prefetch values with 32 bit avisynth. You will hit 32 bit app memory limit.

Then I guess you must encode 4k or 1080 bluray videos then. Is there a way for the 32bit plugins work with the x64 avisynth+? Or a way to make them backward compatible?

[real.finder]

Then I guess you must encode 4k or 1080 bluray videos then. Is there a way for the 32bit plugins work with the x64 avisynth+? Or a way to make them backward compatible?

that already discussed https://forum.doom9.org/showthread.php?p=1824330#post1824330

[edcrfv94]

Then I guess you must encode 4k or 1080 bluray videos then. Is there a way for the 32bit plugins work with the x64 avisynth+? Or a way to make them backward compatible?

MP_Pipeline
But if you direct export or pass 9-32 bit clip will has green line on top, So need ConvertToStacked first.

[real.finder]

MP_Pipeline
But if you direct export or pass 9-32 bit clip will has green line on top, So need ConvertToStacked first.

ConvertToDoubleWidth ConvertFromDoubleWidth will be faster

[jinkazuya]

Just wonder how to use the universal batch to set up avisynth+ x64...It is so confusing. Cuz whenever I used the regular avisynth+ installer, it always install avisynth+ into the "C:\Program Files (x86)", even I chose the x64 for avisynth+ installation. Then when I loaded the plugins for x64, the pop up appeared saying "cannot load x64 bit plugins dll into x86 avisynth+" something like that.

[LigH]

^ You already asked that in the UAI thread where it belongs. This is an installer (usage) issue, not an AviSynth+ issue (the installer is not maintained primarily by AviSynth+ developers).

[jinkazuya]

Not sure if somebody could port RedAverage plugin or some other plugins to x64. It would be awesome if somebody could maintain or port most of the old 32 avisynth or avisynth+ plugins to x64. Thanks.

[LigH]

This may be impossible in all the cases where the original authors did not provide sources of their plugins, or did not document their algorithms detailed enough to reprogram them. But where it is possible, a lot of efforts were already invested to implement them. The AviSynth Wiki lists many successful attempts (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins). If you know some missing ones, always provide links to their original location, optimally with sources. A few special plugins may even be easily resembled using very generic tools like convolution or LUT functions.

Specifically regarding "RedAverage", Average (http://avisynth.nl/index.php/Average) is reported to do the same, just faster.

[jinkazuya]

This may be impossible in all the cases where the original authors did not provide sources of their plugins, or did not document their algorithms detailed enough to reprogram them. But where it is possible, a lot of efforts were already invested to implement them. The AviSynth Wiki lists many successful attempts (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins). If you know some missing ones, always provide links to their original location, optimally with sources. A few special plugins may even be easily resembled using very generic tools like convolution or LUT functions.

Specifically regarding "RedAverage", Average (http://avisynth.nl/index.php/Average) is reported to do the same, just faster.

I know, but I would like to use the detailsharpen function. Unfortunately that function requires the RedAverage plugin.

[LigH]

You mean this script function (https://forum.doom9.org/showthread.php?t=163598)? I bet this could be rewritten to use more portable/compatible kernel or plugin functions.

[jinkazuya]

You mean this script function (https://forum.doom9.org/showthread.php?t=163598)? I bet this could be rewritten to use more portable/compatible kernel or plugin functions.

Yes...This is the one I am talking about. I am a noob when it comes to scripting. But it seems nowadays less people are creating new scripts or plugins for video encodes. There used to be a lot more.

[Myrsloik]

I just tried to compile avisynth.h with /permissive- in Visual Studio 15.5. It fails. When are you going to change it to be valid C++ code?

Fun fact: this is now the default setting for new projects

[pinterf]

I have read about it but not yet tried.

[pinterf]

I just tried to compile avisynth.h with /permissive- in Visual Studio 15.5. It fails. When are you going to change it to be valid C++ code?

Fun fact: this is now the default setting for new projects
I have tried. So what's your problem?

[Myrsloik]

I have tried. So what's your problem?

4>C:\VapourSynth\AviSynthPlus\avs_core\include\avisynth.h(670): error C3447: third operand to the conditional operator ?: is of type 'void', but the second operand is neither a throw-expression nor of type 'void'

Basically a wall of this whenever you compile a plugin, compiling the core will obviously work since then the proper functions are provided. I even checked out the latest version from your MT branch to test it.

AVFS (and probably any plugin/api user) shows this problem.

[pinterf]

Ah. Then will try with a plugin. I only had syntax error in a win 7.1 sdk header which i commented out (because the 141xp toolset uses this sdk).

[pinterf]

4>C:\VapourSynth\AviSynthPlus\avs_core\include\avisynth.h(670): error C3447: third operand to the conditional operator ?: is of type 'void', but the second operand is neither a throw-expression nor of type 'void'

Basically a wall of this whenever you compile a plugin, compiling the core will obviously work since then the proper functions are provided. I even checked out the latest version from your MT branch to test it.

AVFS (and probably any plugin/api user) shows this problem.
Thanks, now it should be OK. There were other surprises as well.

[Myrsloik]

Thanks, now it should be OK. There were other surprises as well.

Works. As a bonus you can now easily use clang-cl to compile plugins too.

[lordsmurf]

I had to reinstall 2.6, and use SEt's MT dll.
I could never get the 32-bit + MT to work, and then tmedian2 was not available. That was a deal breaker.

The + x64 worked perfectly.

[pinterf]

I had to reinstall 2.6, and use SEt's MT dll.
I could never get the 32-bit + MT to work, and then tmedian2 was not available. That was a deal breaker.

The + x64 worked perfectly.What was the problem? Memory issues at large thread count?

[ryrynz]

Anyone compiled a new build?

[pinterf]

New version.
Avisynth Plus r2574 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2574)

- Finally with an installer (x86/x64 in one package), thanks to Groucho2004. This is the first time I'm providing installer, there can be glitches. One of the installer comes with the current Visual Studio C++ x86 and x64 Redistributables. In theory the VS2017 redistributables superseed and are compatible with the VS2015 one. Please note that original Avisynth documentation and filter SDK is not provided, they are not up to date.

- A fix for MaskHS, reported by sneaker_ger, thanks for the report.

- The other things are mainly Expr related.

There was a bugfix in jit that took some time to understand and caused many grey hairs.
And new "why not" features to have my entertainment as well :)

The idea for introducing variables came for an earlier test Expr script, in which abs(x-y) was used and computed at least four times. Variables are temporary registers inside an Expr that can be saved, saved and popped from stack and reused many times. A variable is an uppercase letter from A to Z.

The other feature is the pixel-relative addressing. Clip variables can be shifted by (constant) x and y offset.

Both of this two features were found later in davidhorman's great rgba_rpn/y8_rpn filter: https://forum.doom9.org/showthread.php?t=172601

Two other Expr feature idea then was adopted from his filter: 'frameno' and 'time' ('n' and 't' in his version - in Expr lowercase letters are clip references)

Example: Mandelbrot zoomer, syntax rewritten from the above topic (https://forum.doom9.org/showthread.php?p=1738391#post1738391)
a="X dup * Y dup * - A + T^ X Y 2 * * B + 2 min Y^ T 2 min X^ "
b=a+a
c=b+b

blankclip(width=960,height=640,length=1600,pixel_type="YUV420P8")

Expr("sxr 3 * 2 - -1.2947627 - 1.01 frameno ^ / -1.2947627 + A@ X^ syr 2 * 1 - 0.4399695 "+\
"- 1.01 frameno ^ / 0.4399695 + B@ Y^ "+c+c+c+c+c+b+a+"X dup * Y dup * + 4 < 0 255 ?","128","128")


Changes since r2544
# Fix
Fix: MaskHS created inverse mask. Regression after r2173
Fix: jitasm code generation at specific circumstances in Expr filter

# Build
Build: changed avisynth.h, strict C++ conformity with Visual Studio 2017 /permissive- flag

# Other
Installer in two flavours: simple or full (with Microsoft Visual C++ Redistributables)

# New
Expr tweaks:
- Indexable source clip pixels by relative x,y positions.
Syntax: x[a,b] where
'x': source clip letter a..z
'a': horizontal shift. -width < a < width
'b': vertical shift. -height < b < height
'a' and 'b' should be constant. e.g.: "x[-1,-1] x[-1,0] x[-1,1] y[0,-10] + + + 4 /"
When requested pixels come from off-screen the off-screen values are cloned from the appropriate top-bottom-left-right edge.
Optimized version requires SSSE3 (and no AVX2 version is available). On non-SSSE3 CPUs falls back to C.

- sin cos tan asin acos atan (no SSE2/AVX2 optimization, when they appear in Expr a slower C code runs the expression)

- % (modulo). result = x - trunc(x/d)*d.
Note: internally everything is calculated as a 32 bit float.
A float can only hold a 24 bit integer number, don't expect 32 bit accuracy here.

- Variables: uppercase letters A..Z for storing and reuse temporary results, frequently used computations.
Store, result can still be used from stack: A@ .. Z@
Store and remove from stack: A^ .. Z^
Use: A..Z
Example: "x y - A^ x y 0.5 + + B^ A B / C@ x +"

- 'frameno' : use current frame number in expression. 0 <= frameno < clip_frame_count

- 'time' : calculation: time = frameno/clip_frame_count. Use relative time position in expression. 0 <= time < frameno/clip_frame_count

- 'width', 'height': currently processed plane width and height

[LigH]

Example: Mandelbrot zoomer...

:eek: Bringing another level of "Synth" into AviSynth. :sly:

And installers! :p

[Groucho2004]

New version.
Avisynth Plus r2574 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2574)
Thank you.

Finally with an installer (x86/x64 in one package)Nice, I can retire my installer. :)

[real.finder]

Thanks pinterf

Fix: jitasm code generation at specific circumstances in Expr filter

so now it's time for lut/expr upscale things? :)

[pinterf]

Maybe. As you see I have implemented many masktools syntax elements in Expr: missing functions, modulo, similarly looking operators, basic scaling support. They are mostly similar but by now masktools lut is a bit behind Expr (e.g. variables).

[real.finder]

Maybe. As you see I have implemented many masktools syntax elements in Expr: missing functions, modulo, similarly looking operators, basic scaling support. They are mostly similar but by now masktools lut is a bit behind Expr (e.g. variables).

masktools syntax especially for float need to change

https://github.com/pinterf/masktools/issues/1

[GMJCZP]

Thank you pinterf!

A small observation: the only difference I notice with the old avisynth installer is that had by default activated "Select Association", while this installer does not have it.

EDIT: When I tried to directly open a script, instead of starting notepad the Windows Media Player was opened.
As I set the default program the notepad, the file icon naturally changed. To fix it I had to use a program called FileTypesMan, but I suppose the idea is for the installer to do it just like the old avisynth.

[StainlessS]

GMJCZP,

As a recommendation, I suggest you forget NotePad (standard) and right click and select "Open With" to maybe PsPad or NotePad+ (NotePadPlus),
which both supports Edit of Avisynth script (with keyword hi-lite) and Play of the script, really quite a lot more useful than NotePad standard.

As Pinterf mentions in Avs Usage, MPlayer2 is still supplied, even in Win10, I always quite hated WMVxxx, really horrible, whereas MPlayer2 is very
usable and what I use (together with MPC-HC in PsPad) to view/test scripts.

Give'it a whirl, you might like it.

EDIT:
and select "Open With"
You can actually set that inside both PsPad and NotePad+ settings.

EDIT: In XP, some clips do not play in MPlayer2.exe, but for most, I much prefer over WMVxxx.
In XP, MPlayer2, is located in same directory as WMVxx (C:\Program Files\Windows Media Player\).

EDIT: It is a bit peculiar that MPlayer2 is still provided, another weird little thing is that from W98 onwards, there was always
a DVD player included (REALLY basic) , just not an MPEG2 decoder, called DVDPlay.exe (I think, in system32), dont know if it is still there.

[GMJCZP]

TinMan, the idea is that when opening a script open the notepad, as with the old avisynth, if not then I do not understand the idea of file associations, using FileTypesMan was not what I had in mind with AVS+. :(

EDIT: I use "Open With" for VirtualDub/ VirtualDubMod or WMP/ MPC-HC

[StainlessS]

'Open With', (and tick the 'Always' [or whatever its called] tick box).

EDIT: You can still then use "Open With" on the odd occasion for VDub.

[nhope]

Thanks for the update pinterf.

Regarding this screen...

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus1.png

...I got a little confused/concerned because I thought a) maybe it would now install the Avisynth.dll file itself in that folder, and b) I might be about to get only the x86 version.

Of course, it did neither, but I think it would be useful to explicitly state at that stage of the installation that it will install both x86 AviSynth+ in C:\WINDOWS\System32 and x64 AviSynth+ in C:\WINDOWS\SysWOW64, and that the folder being chosen at this stage of the installation is just for the plugins for both versions, along with the license and uninstaller etc..

Another thing the installer did was detect that I had AviSynth installed in d:\Documents\AvisynthRepositor\AVSPLUS_x86:

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus2.png

Actually I didn't. That was just a "dumb" folder, with no files in it being used in my existing AviSynth installation. When I renamed it and ran the installer again, it was ignored.

[Groucho2004]

Of course, it did neither, but I think it would be useful to explicitly state at that stage of the installation that it will install both x86 AviSynth+ in C:\WINDOWS\System32 and x64 AviSynth+ in C:\WINDOWS\SysWOW64It's the other way around (x86 to SysWoW64, x64 to System32). :D




Another thing the installer did was detect that I had AviSynth installed in d:\Documents\AvisynthRepositor\AVSPLUS_x86:

http://shared-photos-for-embedding.s3.amazonaws.com/Avsplus2.png

Actually I didn't. That was just a "dumb" folder, with no files in it being used in my existing AviSynth installation. When I renamed it and ran the installer again, it was ignored.
Yes you did. The detected directory is the "default" value in "HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth". Although not strictly necessary, some programs use this registry value to determine if Avisynth is installed (that's why the Universal Installer writes it too). This entry is also written by the classic Avisynth installer.

[mcjordan]

FYI: thru Avisynth+ r2575 compilation

..\avs_core\filters\limiter.cpp ->
#include <core/internal.h> is wrong
right is:
#include <../core/internal.h>

[pinterf]

FYI: thru Avisynth+ r2575 compilation

..\avs_core\filters\limiter.cpp ->
#include <core/internal.h> is wrong
right is:
#include <../core/internal.h>
Modified, thanks. (Why did it work for me and not for you)

[mcjordan]

Hmm... I don't know. I'm under Win7 and VS2017 15.5.2

Another (non-fatal) error that occurs during a compilation of a long time ago:
...
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(384): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(455): note: see reference to function template instantiation 'void overlay_blend_sse2_plane_masked<uint8_t,8,false>(BYTE *,const BYTE *,const BYTE *,const int,const int,const int,const int,const int)' being compiled
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(405): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(957): warning C4309: 'argument': truncation of constant value
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(1012): note: see reference to function template instantiation 'void overlay_blend_sse2_plane_masked_opacity<uint16_t,16,true>(BYTE *,const BYTE *,const BYTE *,const int,const int,const int,const int,const int,const int,const float)' being compiled

[pinterf]

Hmm... I don't know. I'm under Win7 and VS2017 15.5.2

Another (non-fatal) error that occurs during a compilation of a long time ago:
...
3>C:\AviSynthPlus\avs_core\filters\overlay\blend_common.cpp(384): warning C4309: 'argument': truncation of constant value

Yes, I know, fortunately it's only a warning, usually this type of warning is switched off temporarily by pragmas, which I have not done yet. (Like setting a 16 bit word to 0xFFFF while the parameter is "short" (signed 16 bit) type)

[mcjordan]

Thank you, pinterf. Sorry for disturbance.
And wish you a happy Мerry Christmas.

[GMJCZP]

Excuse me pinterf, did you read by chance post # 3800? Thanks.

[pinterf]

Excuse me pinterf, did you read by chance post # 3800? Thanks.Yes, but I placed the editor option into "Open With" intentionally in order not to overwrite notepad++ or other existing associations. I could still use rightclick on avs file and select notepad and tick "always use this program" (I'm on win10). I'm not near a computer but I think the reinstall will keep the setting of that checkbox.

[GMJCZP]

Thanks pinterf for answering.

The problem is that if you use "always use this program" the script icon will be notepad and not AVS+, which does not happen with the old avisynth.

[StainlessS]

Cant you just (on XP at least), select Windows Explorer, "Folder Options/File Types" and find "File Extension"
'AVS', click "Advanced", "Change Icon", "Browse", find "Avisynth.dll" (wherever it is located), select your
chosen icon, then "OK" and "Close".

I guess if you change avs version a lot, & havta do it every time it could get a bit tedious.

EDIT: After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions. (not affected by "Do Not Cache Thumbnails"
in folder options).

EDIT: Cant say that I've ever noticed what icon avs came up under. [I ALWAYS have it on Details WITH EXTENSIONS, except in Control Panel
or Administrators Tools [where all icons are different, no point at all in icons when a folder full of identical file types].

I tried to find similar on windows 10 (not quite as horrid as I thought it would be, but hate those damn long
timeouts when it updated to Creators Update [or whatever its called]), but seems like change file icon functionality
has died out. Seems you have to be an IT Pro to want to change file icons, here suggests using ShellExView utility.
https://social.technet.microsoft.com/Forums/windows/en-US/8463dbfe-52f3-4cd2-9118-f07323a83d6e/change-file-types-program-associated-to-an-extensionfile-type?forum=w7itproui

[Groucho2004]

After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions.You can delete the cache manually by deleting "IconCache.db" in "%USERPROFILE%\Local Settings\Application Data".

[GMJCZP]

Cant you just (on XP at least), select Windows Explorer, "Folder Options/File Types" and find "File Extension"
'AVS', click "Advanced", "Change Icon", "Browse", find "Avisynth.dll" (wherever it is located), select your
chosen icon, then "OK" and "Close".

I guess if you change avs version a lot, & havta do it every time it could get a bit tedious.

EDIT: After deleting the avisynth.dll, icon still remains, I think it goes into an Icon Cache, which is
sometimes cleared, but I cant remember under what conditions. (not affected by "Do Not Cache Thumbnails"
in folder options).

EDIT: Cant say that I've ever noticed what icon avs came up under.

That's why I prefer the installer of the old avisynth, which already does everything automatic. I only ask that if it is possible to emulate this with the AVS+ installer and not have to resort to a program like FileTypesMan to do things manually.

[StainlessS]

Thanx Grouchy, knew I'de seen it somewhere. :) [EDIT: also forgot about Thumbs.db, I always Do Not Cache Thumbnails].

That's why I prefer the installer of the old avisynth, which already does everything automatic. I only ask that if it is possible to emulate this with the AVS+ installer and not have to resort to a program like FileTypesMan to do things manually.

Computers are not intended to make life easy, just more interesting :)

[GMJCZP]

TinMan, your enigmatic words do not make me feel better :rolleyes: :)

[THEAST]

I decided to give Avisynth x64 a try after a very long time; however, I am not sure how I can use Avisynth x86 and x64 at the same time. I used the latest installer for AVisynth+ MT (r2574) which installs the 32-bit DLLs into SysWOW64, and the 64-bit DLLs to System32. With this configuration, MeGUI x64 can load my existing Avisynth scripts correctly; however, MeGUI x86 and VirtualDub x86 do not work (MeGUI crashes with C:\WINDOWS\SYSTEM32\avisynth.dll as faulting module path, and VDub generates an illegal instruction error). If I move the 32-bit DLLs to System32 and overwrite the 64-bit ones, then the x86 apps work correctly (but MeGUI x64 obviously does not). It seems all these apps default to System32 to find avisynth.dll. Am I missing something here? Is there any way I can use Avisynth x86 and x64 at the same time and choose which one to be loaded depending on the application?

[ajp_anton]

I decided to give Avisynth x64 a try after a very long time; however, I am not sure how I can use Avisynth x86 and x64 at the same time. I used the latest installer for AVisynth+ MT (r2574) which installs the 32-bit DLLs into SysWOW64, and the 64-bit DLLs to System32. With this configuration, MeGUI x64 can load my existing Avisynth scripts correctly; however, MeGUI x86 and VirtualDub x86 do not work (MeGUI crashes with C:\WINDOWS\SYSTEM32\avisynth.dll as faulting module path, and VDub generates an illegal instruction error). If I move the 32-bit DLLs to System32 and overwrite the 64-bit ones, then the x86 apps work correctly (but MeGUI x64 obviously does not). It seems all these apps default to System32 to find avisynth.dll. Am I missing something here? Is there any way I can use Avisynth x86 and x64 at the same time and choose which one to be loaded depending on the application?I didn't even know 32-bit applications could access the System32-folder on a 64-bit Windows. I thought Windows just silently mapped them to SysWOW64 instead.

[Groucho2004]

I didn't even know 32-bit applications could access the System32-folder on a 64-bit Windows. I thought Windows just silently mapped them to SysWOW64 instead.Using the standard LoadLibrary() call or going through the VfW API, 32 bit programs will not be able to access System32 on a 64 bit OS. The OS redirection functionionality takes care of that.

AVSMeter (and AVSMeter64) with the "-avsinfo" switch would probably shed some light on THEAST's problem.

[LigH]

If I move the 32-bit DLLs to System32...

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").

[real.finder]

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").

yes, I see same problem when I enter by TeamViewer in my friend pc that use teracopy, remove the teracopy fix it, I was think it was teracopy bug or limit

[THEAST]

Actually my initial observation was incorrect and it seems the problem is with the latest build of Avisynth+. My script is as follows:

LoadPlugin("*RELEVANT_PATH*\ffms2.dll")
FFVideoSource(*INPUT_FILE*, threads=1)
Spline36Resize(640,480)
QTGMC( Preset="Very Fast", InputType=2)
crop(4, 0, -4, 0)

Using build 2574, this script works fine with Avisynth x64, but with Avisynth x86, both VDub and AVSMeter x86 generate an illegal instruction error and MeGUI x86 crashes. If QTGMC is removed from the script, then all of them work.
Using build 2544, the script works with Avisynth x86 without any issues. I think there might be some incompatibility between the latest version of Avisynth+ in x86 mode and QTGMC (or of the filters it depends on).

The following is the output of AVSMeter x86 on my machine:
AVSMeter 2.7.0 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2574, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2017-12-19, 08:05:06 (UTC)
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+


[CPP 2.5 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth+\plugins\ChromaShift.dll [2003-11-04]

[CPP 2.6 / 32 Bit Plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll [2017-12-19]
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp.dll [2016-06-24]
C:\Program Files (x86)\AviSynth+\plugins\DePan.dll [2.13.1.3]
C:\Program Files (x86)\AviSynth+\plugins\DePanEstimate.dll [2.10.0.2]
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll [2.2.10.0]
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll [2.7.24.0]
C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll [0.9.4.48]
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll [0.96.0.0]

[Scripts / AVSI]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.avsi [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins\BlindDehalo3_MT2.avsi [2006-03-22]
C:\Program Files (x86)\AviSynth+\plugins\EdgeCleaner.avsi [2015-01-02]
C:\Program Files (x86)\AviSynth+\plugins\MtModes.avsi [2017-12-24]
C:\Program Files (x86)\AviSynth+\plugins\QTGMC-3.357.avsi [2017-04-02]
C:\Program Files (x86)\AviSynth+\plugins\SMDegrain_v3.1.2.93s.avsi [2017-12-24]

[Uncategorized / Other]
C:\Program Files (x86)\AviSynth+\plugins+\colors_rgb.txt [2016-07-05]
C:\Program Files (x86)\AviSynth+\plugins\chromashift.html [2003-11-04]
C:\Program Files (x86)\AviSynth+\plugins\QTGMC-3.33.html [2011-05-05]

Which file manager do you use to copy files into the system directories? I hope they are not 32-bit executables. They "lie" to you, as the previous users explained. Trying to enter System32 or SysWOW64, you will probably end in the same directory when you use a file manager as 32-bit executable. Only a 64-bit file manager will have access to these directories separately (if started "as Administrator").
The standard windows explorer. I don't think it suffers from this issue.

yes, I see same problem when I enter by TeamViewer in my friend pc that use teracopy, remove the teracopy fix it, I was think it was teracopy bug or limit
That is a limitation/bug in Teracopy which has been confirmed and is on the roadmap to be possibly fixed in the next version:

http://bugs.codesector.com/view.php?id=63

P.S. I am using Windows 10 x64 and my processor is Intel i7-5820k.

[LigH]

I wonder if one of your AviSynth import scripts might explicitly load plugins from a specific directory, so either 32-bit or 64-bit plugins. But that should be less probable if you used them from the URLs in the AviSynth Wiki page of QTGMC and its plugin packs, they should rely on plugins being auto-loaded or explicitly loaded in the calling script ... :o

Try to run both AVSMeter and AVSMeter64 with your script as parameter to "benchmark" it in 32-bit and 64-bit mode, that may produce more verbose error messages in case of a crash.

Furthermore ... MeGUI may use an own copy of AviSynth+ instead of the one installed in your system, depending on its configuration. MeGUI log files should reveal that.

[Groucho2004]

Considering the "illegal instruction" error and the fact that it works with r2544 it seems reasonable to assume that the Avisynth core is to blame. Let's see what pinterf has to say about it.

[THEAST]

I updated all the DLLs from the Github links provided in QTGMC Wiki before updating to the new version; other than QTGMC and SMDegrain, the rest of the "avsi" files should not be loaded in my script.

With build Avisynth+ 2574 x86 and AVSMeter x86, I get the following output if QTGMC is included:

AVSMeter 2.7.0 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2574, MT, i386) (0.1.0.0)

Exception 0xC000001D [STATUS_ILLEGAL_INSTRUCTION]
Module: C:\WINDOWS\SysWOW64\avisynth.DLL
Address: 0x69F0F3A8

If QTGMC is removed, or the 64-bit version of Avisynth and AVSMeter is used, then the benchmark runs correctly.

To use build 2544, I just overwrote the build 2574 x86 DLLs in SysWOW64 with the ones from build 2544 and did not at all touch the x64 or the plugin DLLs; that seems to solve the issue.

P.S. If anyone has other Avisynth+ builds between 2544 and 2574, I can try finding the exact build that causes the problem.

[pinterf]

@THEAST: what processor type are you using?

[THEAST]

@THEAST: what processor type are you using?

Intel i7-5820k.

[pinterf]

I can see the crash. Cannot imagine what has happened. Debug build is not crashing. Nothing has been changed related to this report. I have avx2. Maybe VS updated itself.

[THEAST]

It is a bug in the compiler, then?

[pinterf]

Don't know if vmovntdqa reg,reg is valid or not but it seems to be not. The crash occurs in merge_avx2:

00070 8d 40 20 lea eax, DWORD PTR [eax+32]

; 70 : __m256i src1 = _mm256_stream_load_si256(reinterpret_cast<__m256i*>(p1+x));

00073 c5 fe 6f 40 e0 vmovdqu ymm0, YMMWORD PTR [eax-32]
00078 c4 e2 7d 2a c8 vmovntdqa ymm1, ymm0 ****CRASH HERE! ILLEGAL INSTRUCTION VS15.5.1!!!****

; 71 : __m256i src2 = _mm256_stream_load_si256(const_cast<__m256i*>(reinterpret_cast<const __m256i*>(p2+x)));
0007d c5 fe 6f 44 02 e0 vmovdqu ymm0, YMMWORD PTR [edx+eax-32]
00083 c4 e2 7d 2a c0 vmovntdqa ymm0, ymm0


Will update to 15.5.2 and see what happens.

EDIT:
With VS 15.5.2 the code still fails. Replaced stream_load with normal load, it's O.K.

[VS_Fan]

The guy offering binaries for x265 at http://msystem.waw.pl/x265/ switched from VS 2017 to VS 2015.2 claiming the update 15.5 of VS 2017 is giving serious problems: From version 2.6+17 there are no VS 2017 builds – update 15.5 of VS 2017 is so wrong (and it is not possible to install VS 2017 15.4) that I switched to VS 2015.2

[wonkey_monkey]

vmovntdqa reg,reg seems invalid. I think it should be vmovdqa. Then again I'm not sure what that second use, vmovntdqa ymm0, ymm0, is meant to achieve...

[pinterf]

Compiler bug. Second parameter is an aligned memory address (this instruction is a non-cache-polluting load)

[pinterf]

New release.
Avisynth Plus r2580-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2580-MT)

..and let's hope the best (compiler-quality-wise). I didn't have a machine with Visual Studio 2015 right now, I have just moved to a new computer (finally a one with AVX2 capable processor)

Edit: dates are 26th December inside. Today is 27th. Nevermind. I got one more day in holiday to finish reading Rama II :)

- (workaround): Merge: Visual Studio 2017 15.5.1/2 generated invalid AVX2 code (x86 crashed)
- Temporalsoften 10-14 bits: an SSE 4.1 instruction was used for SSE2-only CPU-s (Illegal Instruction on Athlon XP)

[THEAST]

@pinterf, thank you for the quick update despite the holidays. I can confirm that the new build works correctly on my environment both in x86 and x64 mode.

I performed a few speed tests using AVSMeter with both 6 and 12 threads (6-core Intel i7-5820k, Windows 10 x64). I can reliably get 10-12% FPS improvement on the same script (the main filter being QTGMC) when going from Avisynth+ x86 to x64. I also tested the ICC SSE4.2 and AVX2 versions of NNEDI and compared with the VS version; the ICC version is actually around 1% slower.

Happy holidays to everyone.

[Groucho2004]

Edit: dates are 26th December inside. Today is 27th. Nevermind.
[Avisynth info]
VersionString: AviSynth+ 0.1 (r2580, MT, i386)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: D:\WINNT\system32\avisynth.dll
Avisynth.dll time stamp: 2017-12-27, 19:51:55 (UTC)
PluginDir2_5 (HKLM, x86): E:\Apps\VideoTools\AVSPlugins\AutoLoad
PluginDir+ (HKLM, x86): E:\Apps\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins

[pinterf]

Then in the readme of the files-only pack.

[Groucho2004]

Then in the readme of the files-only pack.I see, didn't look at the readme.

[wonkey_monkey]

Quick question: when creating a NewVideoFrame, is pitch guaranteed to always be rowsize rounded up to a 32-byte boundary?

[Myrsloik]

Quick question: when creating a NewVideoFrame, is pitch guaranteed to always be rowsize rounded up to a 32-byte boundary?

Nope. If you end up running in vapoursynth's compatibility it can be 64 byte alignment too. Sometimes. There are also some cpu cache reasons to avoid row sizes that are a certain multiple. So a future implementation may pad the rowsize to avoid that.

Don't assume anything, it'll break future compatibility.

[wonkey_monkey]

But it will be consistent for a particular clip? So if I call NewVideoFrame(vi), get the pitch, and immediately discard the frame, is it safe to assume the pitch will be the same for all future frames created?

I'm trying to be extremely efficient with something.

[Myrsloik]

But it will be consistent for a particular clip? So if I call NewVideoFrame(vi), get the pitch, and immediately discard the frame, is it safe to assume the pitch will be the same for all future frames created?

I'm trying to be extremely efficient with something.

In vapoursynth it's guaranteed that the stride/pitch is the same. For all frames if they have the same type.

I checked the Avisynth source and the stride will always be the same there too. For NewVideoFrame, not for frames returned from GetFrame obviously.

[pinterf]

Since r2544 the frame alignment is 64 bytes, and pitch/stride size is padded to 64 as well, independently of possible AVX512 support.

[bilditup1]

Does the KAISER patch have any implications for avs performance?

[LigH]

It will probably delay every call to a Windows system function which switches from user space to kernel space.

[pinterf]

There was no change, what happens when you call Eval with the clip as the first parameter? (not tried, I hope syntax is OK)
AVSValue eval_args[] = { clip, env->SaveString("Subtitle(\"Hello world!\")") };
AVSValue val = env->Invoke("Eval", AVSValue(eval_args, 2));

[pinterf]

Eval does not take a clip argument: http://avisynth.nl/index.php/Internal_functions#Eval. The issue seems to be variable scoping.
Then it's not documented.
This other form is for OOP notation, that is clip.Eval("....").
Saves current "last", sets "last" to clip, calls Eval then restores previous "last".
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L191
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L416

But I agree, this is scoping problem, similar to the earlier (still not solved) issue with conditional/runtime functions setting "current_frame" and "last" in a multithreading environment.

[Gavino]

Eval does not take a clip argument: http://avisynth.nl/index.php/Internal_functions#Eval. The issue seems to be variable scoping.
This was added in Avisynth 2.6.0 Alpha 5.

Here is the 5th official release of Avisynth 2.6

========================
Changelist

Additions
* Added Eval(clip, string name, string) alias for oop processing of argument.

[pinterf]

Thanks to raffriff42, who provided me a nice skeleton page, Expr got an info page.
It's still ugly, I'll format it properly when I'm fiddling out how to do that. Now I only poured some infos there.
Enjoy (or not :) ) http://avisynth.nl/index.php?title=Expr

[wonkey_monkey]

With a YUVA clip, IsY() and IsYUV() seem to return false. Is that intended behaviour? I've been relying on https://forum.doom9.org/showthread.php?p=1783714 as a reference on colour spaces, but it's not clear on this point.

---

Also that page makes reference to ComponentCount but the latest avisynth.h only seems to have NumComponents...? Is the latter the eventual form of the former, I guess?

If anybody ever thinks of it, HasY(), HasU(), HasG(), HasA() etc would be awesome...

[raffriff42]

YUV444P8 is YUV but not YUVA or Y-only
YUVA444P8 is YUVA but not YUV or Y-only
Y8 is Y and YUV but not YUVA

I tried to create a hierarchy (tree view) on the Avisynthplus_color_formats (http://avisynth.nl/index.php/Avisynthplus_color_formats) page.
See also the Clip_properties (http://avisynth.nl/index.php/Clip_properties#Video:_Color_Format) page.

HasA() exists and it's called HasAlpha.
HasU() does not exist, but you can call try { ExtractU (http://avisynth.nl/index.php/Extract) } catch { ...}

[wonkey_monkey]

Thanks - seems a little messy but I think it's clearer. Do all Y-only formats return IsYUV()=true? Or just Y8?

[raffriff42]

All the tests hold true regardless of bit depth.

If you want more confusion, consider that the new RGB(A) formats are planar; you can't call ConvertBits(x) on an RGB32 clip, you must call ConvertToPlanarRGBA first. I have posted a utilities script, called Utils-r41.avsi (http://avisynth.nl/images/Utils-r41.avsi), that (among other things) hides this complexity behind To16bit and ToHibit(bits)

[qyot27]

I tried to create a hierarchy (tree view) on the Avisynthplus_color_formats (http://avisynth.nl/index.php/Avisynthplus_color_formats) page.
See also the Clip_properties (http://avisynth.nl/index.php/Clip_properties#Video:_Color_Format) page.
Two nitpicks:
There's a typo on YUVA444P claiming classic AviSynth has it.

The YUV422P10 entry is showing v210's data. IMO, v210 being interleaved and VfW-only should only be mentioned in the footnotes at the bottom, not in the table itself. The notes column could read like:
aka P210 (special-case: V210 output available via override§)
(or 'global OPT_Enable_V210()' instead of 'override'). But as it is right now, it's highly misleading since YUV422P10 is planar, is used internally in AviSynth+, and isn't VfW-only.


If you want more confusion, consider that the new RGB(A) formats are planar; you can't call ConvertBits(x) on an RGB32 clip, you must call ConvertToPlanarRGBA first. I have posted a utilities script, called Utils-r41.avsi, that (among other things) hides this complexity behind To16bit and ToHibit(bits)
Well, for ConvertBits(16) you'd get RGBA64 - and as far as I'm aware, that should preserve the alpha. The question is whether RGBA64 is actually useful, or whether most destination programs expect 16-bit planar RGBA if working with >8bit and alpha.

[raffriff42]

qyot27, thanks for fact-checking, I'll fix.

>for ConvertBits(16) you'd get RGBA64
IIRC I used to get an error trying that, but you're right, it works.

[wonkey_monkey]

HasA() exists and it's called HasAlpha.


I don't see it in the avisynth.h dated 20171207. I'll use NumComponents()==4, it seems like that should work.

[pinterf]

I don't see it in the avisynth.h dated 20171207. I'll use NumComponents()==4, it seems like that should work.
HasAlpha is an Avisynth+ script function and has no direct mapping to a VideoInfo helper function.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/parser/script.cpp#L1400

[pinterf]

Don't know if vmovntdqa reg,reg is valid or not but it seems to be not. The crash occurs in merge_avx2:

00070 8d 40 20 lea eax, DWORD PTR [eax+32]

; 70 : __m256i src1 = _mm256_stream_load_si256(reinterpret_cast<__m256i*>(p1+x));

00073 c5 fe 6f 40 e0 vmovdqu ymm0, YMMWORD PTR [eax-32]
00078 c4 e2 7d 2a c8 vmovntdqa ymm1, ymm0 ****CRASH HERE! ILLEGAL INSTRUCTION VS15.5.1!!!****

; 71 : __m256i src2 = _mm256_stream_load_si256(const_cast<__m256i*>(reinterpret_cast<const __m256i*>(p2+x)));
0007d c5 fe 6f 44 02 e0 vmovdqu ymm0, YMMWORD PTR [edx+eax-32]
00083 c4 e2 7d 2a c0 vmovntdqa ymm0, ymm0


Will update to 15.5.2 and see what happens.

EDIT:
With VS 15.5.2 the code still fails. Replaced stream_load with normal load, it's O.K.
Two weeks ago I have reported it and made a minimal project for MS which still exhibited the problem. And they fixed. One less bug.
https://developercommunity.visualstudio.com/content/problem/174767/illegal-avx2-instruction-by-c-for-mm256-stream-loa.html

[kuchikirukia]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

[real.finder]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

avs+ 2.6.0.5 ?

[raffriff42]

On a hunch, try the latest MaskTools (https://github.com/pinterf/masktools/releases/). (I've seen artifacts with 3.357 that seem to be gone now)

[real.finder]

since there are many plugins dll's that didn't port to x64 including the closed source plugins, is there some ways to make the 32 bit one work in 64 processes? I note this http://www.dllwrapper.com/ but couldn't build wrapped dll successfully, and even if I did, it will work one day only (need to buy it)

Then I guess you must encode 4k or 1080 bluray videos then. Is there a way for the 32bit plugins work with the x64 avisynth+? Or a way to make them backward compatible?

let's back to this, I note that squid_80 did build some close source plugins for x64 back then https://forum.doom9.org/showthread.php?p=1104481#post1104481

since there are some doom9 members that has Intel's compiler like Groucho2004, I think they can did build some too at least for many plugins that needed

[Dion]

I'm seeing some very strong halos using QTGMC 3.357 with Avisynth+ r2580-MT that's not in avs+ 2.6.0.5 or regular avs 2.6.

Seeing this too.. Same plugins versions.

[LigH]

A screenshot and an AVSMeter report about available plugins may be helpful. Guessing without facts is so uncertain. Just imagine several plugins providing functions with the same name (like RemoveGrain + RGTools), and an older plugin being preferred over a newer one.

[Aktan]

Did StackHorizontal/StackVertical change in AVS+? Using this simple script, the shorter clip still continues for whatever reason:

left = AVISource("test1.avi", pixel_type="YUY2").trim(2000, 3000)
right = AVISource("test1.avi", pixel_type="YUY2").trim(3000, 3500)
StackHorizontal(left, right)

test1.avi is over 5000 frames long.

[LigH]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?

[pinterf]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?
left is 1000 frames, right is 500 frames long.
The resulting clip length is the maximum of the input clip lengths.
The question: what happens when in the above samples Trim(3000,3500) is requested with frame numbers over 500?

Trim (at least in Avs+) does not check the requested frame number, it passes over the task to its child filter:
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/edit.cpp#L258

The question that this is a planned behaviour or not?

[wonkey_monkey]

The question that this is a planned behaviour or not?

I like it, whether it's planned or not. It's something I was thinking of suggesting, but is probably too niche and too open-ended a task to properly implement - for clips to keep track of their true starts and ends, so that you can untrim. It would make things like dissolves easier (for me, anyway) - just trim the to the right lengths, and dissolve will extend them as much as needed to keep the result the same length as a plain splice no matter what length dissolve is used.

[Aktan]

AviSynth Wiki: Filters with multiple input clips (http://avisynth.nl/index.php/Filters_with_multiple_input_clips)

StackHorizontal, StackVertical: Framecount – longest clip: the last frame(s) of the shorter clip(s) are repeated until the end

Is it different for AviSynth+ that the shorter clip keeps playing, instead of freezing its last frame?

Yep, this is what is happening. What is weird is, my friend got it that it will keep playing on the first StackHorizontal but the 2nd one will freeze the frame. In fact all StackHorizontals after his first one does freeze the frame. I have not figured out a simple script to show this behavior yet, but I'm working on it.

[raffriff42]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

[StainlessS]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

Would this be better

StackHorizontal(A, B, C)
Trim(0, - Min(A.FrameCount, B.FrameCount, C.FrameCount))
# ^


ie minus, meaning number of frames, rather than end at minimum end frame + 1

[raffriff42]

Yup, that would be better.

[Aktan]

If you don't want repeating frames, you need to trim the resulting clip:StackHorizontal(A, B, C)
Trim(0, Min(A.FrameCount, B.FrameCount, C.FrameCount))

Thanks for your help, but what my friend and I want is actually to keep the longer length and freeze the shorter clip. You see, it helps in comparison videos. The workaround is to use FreezeFrame, but it be nice if we didn't need to use that.

[StainlessS]

Yep, that is a bug, B not truncated. (ornamental trim EndFrame/Framecount/Length, leastwise when in stack)


A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
B=A.Trim(0,-1) # 1 Frame

StackHorizontal(A,B) # Comment one of these out
#Stackvertical(A,B)


EDIT: This gives an even more interesting result (Start trimmed but end not).

B=A.Trim(5,-1) # 1 Frame


EDIT: Makes no difference if specifying End Frame (+ve end) or FrameCount (-ve end), or length (Length=n).


Trim (at least in Avs+) does not check the requested frame number, it passes over the task to its child filter:


In this case Trim() is the child/source filter that StackXXX expects to check for valid frames.
Current standard AVS method must remain the default, if changing as per DavidHorman, then would require additional
args to both StackXXX and trim, methinks (or passed by StackXXX to trim child).

EDIT: It always confused me as to why child clip is source to a filter, I'm assuming that child filter is also the source filter to current filter.
[It always seemed a bit more sensible to me if it were the other way around].

EDIT: OK, think I figured it out, child is the child of the previous filter, but to current filter it is the parent, or maybe not, who knows.

[Aktan]

Here is something interesting, if you add Info() to the trim on B, it works fine:

A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
B=A.Trim(0,-1).Info() # 1 Frame

StackHorizontal(A,B) # Comment one of these out
#Stackvertical(A,B)

Edit: Even replacing Info() with AddBorders(0,0,0,0) would fix it.

[StainlessS]

Obviously, there Info is checking valid range for end frame [vi.num_frames], and doing Trim's job for it.

Trim must currently set vi.num_frames in its result clip, but then ignore it.
It always has to be the filter nearer to source that judges what range is valid, with ultimate responibilty being with the
source fliter itself (eg AviSource or Colorbars), but in this case trim assumes (or should assume) that resonsibility for all following
filters, quite a lot of filters (all of mine, unless bugged), check for valid frame as provided in vi.num_frames by its source
filter. If no filters check (and some dont) for valid frame, then source (eg AviSource) must do it for them, trim must take on that
role if added to filter chain, indeed, it is its raison d'être.

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

[real.finder]

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

Agreed, or even better, added new parameter in the last of parameters list with Default vale that not break old behavior

[wonkey_monkey]

If some other functionality added, then probably best if a totally new filtername is chosen, DavidHormam_Trim(), or something :)

That sounds like a fantastic idea. I also propose that davidhorman_trim(100,200) would return frames 100-199 (100 frames) just to confuse people even further.

(I do think it makes more sense but I'm not such an optimist that I'd expect it to change now)

[raffriff42]

Lots of filters added to clip B eliminate the phantom frames:A=Colorbars.KillAudio.Trim(0,-10).ShowFrameNumber # 10 frames
#[[
#B=A.Trim(0, -1) ## broken
#B=A.Trim(0, -1).Info ## fixed
#B=A.Trim(0, -1).Invert.Invert ## fixed
#B=A.Trim(0, -1).TurnLeft.TurnRight ## fixed
#B=A.Trim(0, -1).AssumeFrameBased ## broken
#B=A.Trim(0, -1).AssumeFPS(A) ## broken
B=A.Trim(0, -1).ChangeFPS(A) ## fixed
#]]
StackHorizontal(A,B)

[StainlessS]

That sounds like a fantastic idea. I also propose that davidhorman_trim(100,200) would return frames 100-199 (100 frames)

Sounds great, could give it a monika of DavidHorman_VirtualDub_Compatible_Trim().

[LigH]

@raffriff42:

So, which of them is the most performant "NOP filter" preserving the specified behaviour? ... :o J/K

[StainlessS]

I would think that the raw elegance of current AVS+ trim is the most performant NOP, really need more tests from those willing to partisipate.

EDIT: Above, guess I misinterpreted Ligh's post, 8 or 9 pints of bitter seem to have that effect on me.

[wonkey_monkey]

It must be ChangeFPS, since it has no need to do anything to the actual video except pass the frame through, just as trim() does. There's just the trivial overhead of determining which frame to pass.

[raffriff42]

I've heard tell ChangeFPS does some caching; maybe that's the reason it works here -https://forum.doom9.org/showthread.php?p=1473320#post1473320
ffvideosource("source.mkv")
changefps(last,last,true) # cache a few frames of input - dont ask, just do. ;-)

[tormento]

I've heard tell ChangeFPS does some caching; maybe that's the reason it works here -
Always present in my scripts. Don't ask why, I don't know :D

[LigH]

To cache explicitly, you may use RequestLinear (TIVTC.dll) (http://avisynth.nl/index.php/TIVTC); AviSynth MT also provided Preroll (http://avisynth.nl/index.php/Preroll) (or even any AviSynth v2.6+?). Does AviSynth+ offer anything similar in its kernel?

[kuchikirukia]

On a hunch, try the latest MaskTools (https://github.com/pinterf/masktools/releases/). (I've seen artifacts with 3.357 that seem to be gone now)

That's what I am using.

avs+ 2.6.0.5 ?

913,920 byte version from March 7, 2016. Reports itself as 2.6.0.5 in properties.

[raffriff42]

AviSynth+ version number is currently 2.60, the same as AviSynth. The way to tell AVS+ versions apart is with the Version & VersionString functions.
For example, the current VersionString is:
"AviSynth+ 0.1 (r2580, MT, i386)" (32-bit)
"AviSynth+ 0.1 (r2580, MT, x86_64)" (64-bit)

[LigH]

Use AVSMeter(64) to discover the version string of your currently installed AviSynth.

[ryrynz]

Or read the 'product name' line under the details tab when you right click -> properties.

[StainlessS]

This is pretty easy too
Version.avs

Version

https://s20.postimg.cc/feuqxdkgd/version.jpg (https://postimages.cc/)

[pinterf]

This is pretty easy too
Version.avs

Version


2016? Then it's time for a change.

[wonkey_monkey]

Whose site is this, which comes up as first Google result for AviSynth+?

http://avs-plus.net/

[ChaosKing]

The git link on the page links to https://github.com/pylorak/avisynth so I would assume it's ultims site aka the thread creator.

[Myrsloik]

Whose site is this, which comes up as first Google result for AviSynth+?

http://avs-plus.net/

This is funny, avs+ creators so bad at making releases the official site is forgotten...

[ryrynz]

Like I said earlier with Ultim basically out of it and with the commits that have been done long since stabilizing things it's about time things got tidied up and merged.
Need a proper version number release.

[wonkey_monkey]

I'm confused by the convertbits Wiki page:

bool truerange = true

Use the default value unless you know what you are doing.
(TODO if false, seems to either do nothing or corrupt output)
Only allowed with Planar color formats.
If true (default), convert 10-16 bit formats without re-scaling underlying pixel data. For example,
clip10bit.ConvertBits(16, truerange=false)
will leave pixel data in the 0..1023 range, but will change the color format from YUVxxxP10 to YUVxxxP16.


It says true will not "re-scale underlying pixel data" but then says false will leave pixel data in the original 10-bit range. Is this a mistake, or ambiguous terminology?

I'd also argue that "truerange" is not a good name for the parameter anyway, as it gives little hint as to what it does, either as false or true.

[poisondeathray]

I'm confused by the convertbits Wiki page:

bool truerange = true

Use the default value unless you know what you are doing.
(TODO if false, seems to either do nothing or corrupt output)
Only allowed with Planar color formats.
If true (default), convert 10-16 bit formats without re-scaling underlying pixel data. For example,
clip10bit.ConvertBits(16, truerange=false)
will leave pixel data in the 0..1023 range, but will change the color format from YUVxxxP10 to YUVxxxP16.


It says true will not "re-scale underlying pixel data" but then says false will leave pixel data in the original 10-bit range. Is this a mistake, or ambiguous terminology?

I'd also argue that "truerange" is not a good name for the parameter anyway, as it gives little hint as to what it does, either as false or true.

nice catch , it is contradictory

What would be a better "name" ? Maybe "scalerange" ?

[wonkey_monkey]

resample? rescale? I think in general true/false parameters like that should be verbs, not nouns, since it indicates what it will do (or not do).

[raffriff42]

Well I did some tests ...results are not exactly what I was expecting
(I was expecting truerange=true to be left-shifted and truerange=false to be left-padded)

baseline --
https://www.dropbox.com/s/xv7o4sosomxahqf/avsplus-convertbits-truerange-test-00.png?raw=1

8bit in, convert to 10bit, back to 8bit:
https://www.dropbox.com/s/v9imv1acge27068/avsplus-convertbits-truerange-test-01.png?raw=1

https://www.dropbox.com/s/lhrgtqkxo2f1epk/avsplus-convertbits-truerange-test-02.png?raw=1

https://www.dropbox.com/s/1al0h996s6g5lt9/avsplus-convertbits-truerange-test-03.png?raw=1

...any ideas?

Here's the script; requires Utils-r41.avsi (http://avisynth.nl/images/Utils-r41.avsi) for EvalShow functionColorbarsHD(width=480, height=320, pixel_type="YUV444P8")
Subtitle("Source PixelType = '" + PixelType + "'", y=24)

#[[ choose one (or none) - convert bit depth
#EvalShow("ConvertBits(10, truerange=true)")
#EvalShow("ConvertBits(10, truerange=false)")
#]]

Subtitle("Converted PixelType = '" + PixelType + "'", y=48)

ScriptClip("""
Subtitle(
\ "Y min = " + String(YPlaneMin, "%0.2f") + ", max = " + String(YPlaneMax, "%0.2f") + "\n"
\+"U min = " + String(UPlaneMin, "%0.2f") + ", max = " + String(UPlaneMax, "%0.2f") + "\n"
\+"V min = " + String(VPlaneMin, "%0.2f") + ", max = " + String(VPlaneMax, "%0.2f"),
\ lsp=0, y=80)
""")

#[[ choose one (or none) - downconvert for viewing purposes
#EvalShow("ConvertBits(8, truerange=true)", align=1)
#EvalShow("ConvertBits(8, truerange=false)", align=1)
#]]

[poisondeathray]

@rr42 - Maybe that's only for "10bit in 16bit" ? and might not apply to "8bit in 10bit" ?

I'm just trying to think of what usage scenarios would you NOT want to scale the values for 8 to 10bit? I can't think of any

The docs (which obviously could be wrong at this point) say "convert 10-16 bit formats without re-scaling underlying pixel data." I think that means source 10 to 16 . The example given is ConvertBits(16, truerange=false)

But for the 10bit case, "10bit in 16bit code words" is still used by some people using dither tools workflows

[wonkey_monkey]

The docs (which obviously could be wrong at this point) say "convert 10-16 bit formats without re-scaling underlying pixel data." I think that means source 10 to 16 .

I think it means "convert to/from formats with between 10 and 16 bits without rescaling."

When converting up, should there be an option to rescale and copy in the upper bits to the new lower bits? So that full white remains full white? E.g, from 8 to 12 bits:


11111111 => 111111111111
11010011 => 110100111101
01101111 => 011011110110


This can be shifted back down and still return to the original value.

[raffriff42]

poisondeathray,
>The docs (which obviously could be wrong at this point)

"The docs" were typed in by me, using whatever information I could gather at the time. :) :o

Note the big red TODO which is my way of saying I don't have a frickin clue here.

If you scroll down to scale, fulls and fulld you will see more confusion. Fact-finding assistance is welcome.

Your mention of 10bit in 16bit data sounds plausible.

[pinterf]

This parameter, whatever stupid name it has, was introduced at the very beginning of the high bit depth project. Its only purpose was to 'typecast' a 16 bit video format over an existing 10 bit content.
Probably in those times native 10 bit support by plugins or external applications was practically non-existing, some external programs could handle 16 bits or one could use stacked 16 bit format.
I guess these were the reasons.

[raffriff42]

pinterf, it's okay to take a wrong turn or two in such an undertaking. Overall, AVS+ is a huge step forward, and thanks again for the work you've done.

Maybe truerange, scale, fulls and fulld can be left undocumented - labeled "deprecated/experimental" (or something) for the time being?

[pinterf]

Yes, truerange and scale should surely die silently.

[pinterf]

Meanwhile I accidentally observed a bug, which appeared on the right-side of a clip as random color blocks/lines.
It was appearing only in 32bit float test clips and only at specific sequence of resizing.

Check and encode this script and look at the right side of the bottom right clip (32 bit float)

x=ColorBarsHD.ConvertToYUV444().Trim(0,100)
Function Resize(clip c)
{
Return c.Spline64Resize(2802,1501).\
Spline16Resize(904,487).\
BilinearResize(402,500).\
Spline36Resize(200,489).\
LanczosResize(400,300).ConvertBits(8)
}
a8 = x.ConvertBits(8).Resize()
a10 = x.ConvertBits(10).Resize()
a16 = x.ConvertBits(16).Resize()
a32 = x.ConvertBits(32).Resize()
Stackvertical(StackHorizontal(a8,a10),StackHorizontal(a16,a32))


Unfortunately it was perfect when I encoded float-only clips. The uglyness in the reproduction was that there had to be a 8-16 bit clip in the script (I usually do the tests for 8-10-16-32 bits then stack it together in 8 bits to see any difference) Obviously there had to be something that had left other patterns in memory than a 32bit float format clip.

Narrowing the problem down, it turned out that the SIMD code that handles the pixels in 4/8 units was run into some garbage at the right side, where not all the 4/8 units are visible pixels, depending of the clip width (modulo 4 or 8).

During the resizing process, the unused pixels are masked out with a zero multiplier - existing 8-16 bit code worked fine like that -, but it was not enough for 32 bit float pixels. When such a pixel is undefined, the processor would report it NaN (Not a Number), and multiplying it by 0 would still result in NaN.
Thus such pixel in the resized clip turned into undefined (garbage)

So I had to fix the float resizer code - uhh, it was old, one of my early attempts.
Since the 10-16 bit resizer parts were affected as well, they had to be touched, too.
Finally whe whole 10-16 and float resizer code got rewritten - unfortunately I couldn't see the time that the bug chasing needed, sure, with less effort I could port Zimg resizers into avs+.

Btw zimg.
Since I had to benchmark the new code if it is any better than the one in r2580, I have included the z_XXX resizers.
https://forum.doom9.org/showthread.php?t=173986

Results are interesting.
Look at the 400x2800 -> 900x400 case (16 bit)

Resizing always happens in one horizontal and one vertical pass. Or first vertical resizing, then horizontal. it depends.

In Avisynth - probably for quality reasons - there is a strategy: "// ensure that the intermediate area is maximal"

Avs resizer gave a 103 fps, while zimg had 402 fps. What?

Then it was made clear that Avs chose the 400x2800->900x2800->900x400 sequence,
while zimg chose
400x2800->400x400->900x400.

When I turned the resizing command into two resizing (first V then H), avisynth+ gave a quite comparable result of 427 fps.
First three columns (AVX2, SSE4, noSSE4 contains results of the new resizers) Code was run on an i7-7700, Avs+ x64. I built specific avs+ versions for the test to ignore AVX2..SSE4.1 CPU flags.

EDIT: this benchmark data contains the comparison of a current "under construction" version avs+ and the z-lib resizer I had access (r1a, from 2016).
They both have faster variants since then.

#32bit float AVX2 SSE4 noSSE4 v2580 Zimg
#400x2800 -> 900x400: 103 64.3 64.3 65.9 Lanczos
#1920x1080-> 1280x720 143.1 83.7 83.2 95.7 158.4 Spline64

#16 bit AVX2 SSE4 noSSE4 v2580 Zimg
#400x2800 -> 900x400: 103.9 84 75.8 56.2 402.6 Lanczos **see comment
#400x2800 -> 400x400->
# 900x400: 427.2 315.3 289.9 243.4 405.1 Lanczos

#1920x1080-> 1280x720 152.2 125.0 118.9 80.6 129 Spline64
#1920x1080-> 1280x720 160.6 134.3 129.4 85.9 134.5 Lanczos
#1920x1080-> 1280x1080 240.2 190.6 185.2 113.2 191.8 Lanczos H
#1920x1080-> 1920x720 335.5 320.8 281 272.2 203.0 Lanczos V

#10 bit AVX2 SSE4 noSSE4 v2580 Zimg
#400x2800 -> 900x400: 105.4 77.5 53.5 Lanczos
#1920x1080-> 1280x720 155.2 146.6 120.4 78.9 133 Spline64
#1920x1080-> 1280x720 163.6 156.2 Lanczos

#8 AVX2 SSE4 noSSE4 Old Zimg
#400x2800 -> 900x400: 93.8 93.4 96.2 93.8 402 **see comment
#1920x1080-> 1280x720 104.7 105.1 106.0 105.5 120.2

# ** Avisynth - unlike zimg - always orders H/V resizers for max intermediate area!

(8 bit resizer code is untouched by me, there is no avx2 option there but I included their measurements)

Now it's to be decided that the slower H/V or V/H decision strategy should be kept or not. Is the difference really visible and when?

[poisondeathray]

Were those tests based on the old zimg , or a recompiled one ? There are quite a few commits to z.lib since that avisynth version posted in Nov 2016, but I don't know offhand if any changes were made to performance (except I think he added AVX-512) or resizing strategies

If there was a noticable qualitative difference, I would imagine it should be more noticable on upscaling. But maybe with some extreme cases , where you have a few pixel width or height src e.g. a 3840x4 strip. There might be some more noticable differences. I guess we can do some tests

But end user can still separate the W, V steps manually if they needed to...



BTW, how are can you load native float formats into avs+ ? (e.g EXR) ? vapoursynth got a bunch of imagemagick updates, but I don't see equivalent method in avs+ ? ffmpeg related options load at 16bit int

[jpsdr]

@Stephen R. Savage
Have you, like pinterf, turn the resizing command into two resizing (first V then H) to ensure that AVS+ and z.Lib have the same "resize path", to make the benchmark realy accurate ?

@Pinterf
Does it mean there is a new code for resizer, so i have to update my ResizeMT...? :sly: ;)

[jpsdr]

Now it's to be decided that the slower H/V or V/H decision strategy should be kept or not. Is the difference really visible and when?
You can still add a new parameter at the end, this will keep compatibility with old script, with something like this :
0 : (default) current behavior
1 : Fastest (so will probably result in opposite of current behavior)
2 : Vertical first
3 : Horizontal first

[pinterf]

Anyway I will rebuild zimg and do the comparison again, at least I have a look at the code and get familiar with a possible integration.

[raffriff42]

Now it's to be decided that the slower h/v or v/h decision strategy should be kept or not.
Is the difference really visible and when?
Huh! I thought AVS's rationale made sense, but now that I think about it,
how is the visible result of the AVS sequence
400x2800->900x2800 // scale rows, copy columns
900x2800->900x400 // copy rows, scale columns

any different from zimg's
400x2800->400x400 // copy rows, scale columns
400x400->900x400 // scale rows, copy columns

Unless the two resize operations are not actually separable (https://en.wikipedia.org/wiki/Separable_filter)?
Does scale row n ever use pixels from the row(s) above or below? I assumed not.

(dumb question?)

[VS_Fan]

... In Avisynth - probably for quality reasons - there is a strategy: "// ensure that the intermediate area is maximal" ...

Now it's to be decided that the slower H/V or V/H decision strategy should be kept or not. Is the difference really visible and when?... how is the visible result of the AVS sequence ... any different from zimg's ...

One can imagine the larger intermediate resolution would keep more original information for the second stage filtering: The more resolution/information as input would yield a better output from any filter.

An “objective” test could be done to measure the quality of the results of either strategy: Produce the results of both strategies: scale the original to whatever size (up/down), then scale them back to the original size, and finally measure the quality of both strategies, with say SSIM, against the original

[poisondeathray]

Huh! I thought AVS's rationale made sense, but now that I think about it,
how is the visible result of the AVS sequence
400x2800->900x2800 // scale rows, copy columns
900x2800->900x400 // copy rows, scale columns

any different from zimg's
400x2800->400x400 // copy rows, scale columns
400x400->900x400 // scale rows, copy columns

Unless the two resize operations are not actually separable (https://en.wikipedia.org/wiki/Separable_filter)?
Does scale row n ever use pixels from the row(s) above or below? I assumed not.

(dumb question?)





It would depend on the scaling algorithm. For example, bilinear looks at a 2x2 grid, bicubic 4x4 grid. Bicubic should be more adversely affected if you scale the lower dimension first

Computing width first vs. height or, vice versa are not bitexact, identical operations if image dimensions are not identical to begin with (square) . You can detect differences or visualize with amplified differences in the end result on any test. The question is whether or not they are significant, or under what conditions do they become significant

You can see issues on various test patterns .

(apologies, this was done in vapoursynth with zimg/z.lib, but the example should still apply to resizing order)

eg.
Test source 10bit RGB 2048x960 dpx patttern 0-1023 gradients for R,G,B,greyscale used the other vapoursynth thread .
http://www.mediafire.com/file/71x5rz8feku2bku/RGB_10bit_grad.7z

Convert/resize to YUV420P8, resize (width/2 then height/2) , or (height/2 then width/2)


v = core.imwri.Read(r'F:\_Video Tests\10bit Pattern Tests\RGB_10bit_grad.dpx')

v1 = core.resize.Bicubic(v, width=1024 , height=960, format=vs.YUV420P8, matrix_s="709", range_s="full")
v1 = core.resize.Bicubic(v1, width=1024 , height=480, format=vs.YUV420P8, matrix_s="709", range_s="full")

v2 = core.resize.Bicubic(v, width=2048 , height=480, format=vs.YUV420P8, matrix_s="709", range_s="full")
v2 = core.resize.Bicubic(v2, width=1024 , height=480, format=vs.YUV420P8, matrix_s="709", range_s="full")

i = core.std.Interleave(clips=[v1,v2])
i = core.hist.Luma(i)
i.set_output()


You can use MakeDiff to see the diff but I chose histogram.luma for this exagerrated look, but you can see the issue on the native image as well if you zoom in and have good eyes. You can see the alignment is "off" when resizing height first . The height first strategy will predispose you to more "banding" in post production, encoding later etc...

Quality wise, it makes more sense to me to resize the dimension with more pixels first - better for sampling


This is a 1:1 center crop , nearest neighbor x2 to show the issue
https://s9.postimg.org/40qqq6mdr/stack.png (https://postimages.org/)

[poisondeathray]

Did you consider that the "issue" goes away if you just do it normally?


core.resize.Bicubic(c, width=1024, height=480, format=vs.YUV420P8, matrix_s="709", range_s="full")



But the problem is... it does not go away


v3 = core.resize.Bicubic(v, width=1024 , height=480, format=vs.YUV420P8, matrix_s="709", range_s="full")

i = core.std.Interleave(clips=[v1,v2,v3])



Here are the full images after the histogram luma

In case it's not clear look at the intersections between the rows
http://www.mediafire.com/file/ehrjjjfigzbulc0/scalingtests.7z


again, a crop , 2x point resize

stackvertical (widthfirst, heightfirst, both)
https://s9.postimg.org/rwygvqlun/stack.png (https://postimages.org/)

[poisondeathray]

I am sure if you rotated the image, you would see the opposite "finding."


I used transpose, and it's not quite the "opposite" finding

But there are difference between all 3 - why wouldn't v2 and v3 be equivalent ?

For now, let's leave dithering out for a separate discussion. Just evaluate the order of operations on end result


By the way, 1024x960 and 2048x480 are exactly the same "area."

Yes, good point



See how there is no "problem" in "c"? All your observations are the artificial result of rounding.



Your "c" is the same as my "v3" . It's not the same. I even tried ffms2

So you're saying everything here is from rounding ?

[poisondeathray]

It does not matter if it is the same.


I'm saying horizontal first vs. vertical first is not the same. It's just an observation

You said "See how there is no "problem" in "c"? "

In this example, there is a "problem", or at least a difference. In this specific case, the bars at the intersections don't even line up when you resize height first, or if you do it "normally" . I would expect "doing it normally" in z.lib would be = resize height first, but that isn't the case here either.

ie. there is a difference between resizing horizontal first, vs vertical resizing. They do not produce bit identical results. ie. They are not the same. In this specific case, it happens that resizing horizontal first is clearly better . That might not be true for other cases. But clearly there is a difference.


If you use "core.register_format(vs.YUV, vs.FLOAT, 32, 1, 1)" as the intermediate, everything is bit-exact. But it doesn't matter to begin with.

No difference here. Maybe you're using a different version ?

EDIT: or did you mean just using float as the intermediate e.g. YUV444PS - in that case yes, all 3 cases are identical . Then your point about rounding errors makes more sense

[poisondeathray]

How can you "leave out" dithering when discussing rounding errors?


Because it's possible dithering can obscure underlying issues


You observe discrepancies in ordering because your image is constant in one direction. After you rotate the image, vertical-first becomes the "better" direction...
resize_h->round->resize_v->round
resize_v->round->resize_h->round
resize_v->resize_h->round

These are not the same operations... You are observing a discrepancy because resizing a constant image produces a constant result. It is not the resizing but the rounding that "moves" the bars in the first pass. The reason they do not move again in the second pass is because the image has been quantized to 8 bits already.


Ok this makes sense to me now, thanks


As for the rotate/transpose test:

vertical first was slightly better in some of the patterns, but the intersections were still bad in all 3.

The premise was resizing the "larger" dimension first would be better because of more information (although as you pointed out same area) so you would expect it to be "better" to resize vertical first in the rotated version, just like you would "expect" it to be "better" the horizontal in the 1st case . But this was just 1 test case, i think it' s just happenstance here and as you say a result of the quantizing/rounding errors

[tormento]

@pinterf

Do you remember this (https://forum.doom9.org/showthread.php?p=1771397#post1771397) topic about image corruption on pure white and regional settings that you solved?

Well, it happened again.

Yesterday night I was watching an encoded version of Hitman's bodyguard and it showed again, mostly on scene changes. I dunno if it still AviSynth+ fault. Let me grab it again from BD and will provide some raw material to work with and script.

[pinterf]

It was a decimal point or comma issue? I don't think we have the same problems here.

[real.finder]

@pinterf

Do you remember this (https://forum.doom9.org/showthread.php?p=1771397#post1771397) topic about image corruption on pure white and regional settings that you solved?

Well, it happened again.

Yesterday night I was watching an encoded version of Hitman's bodyguard and it showed again, mostly on scene changes. I dunno if it still AviSynth+ fault. Let me grab it again from BD and will provide some raw material to work with and script.

what masktools you use?

[tormento]

It was a decimal point or comma issue? I don't think we have the same problems here.
Here we go.

OS: Windows 10 ent x64 rs4 17083 italian

Environment:

VersionString: AviSynth+ 0.1 (r2580, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2017-12-27, 19:55:46 (UTC)
PluginDir2_5 (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64
PluginDir+ (HKLM, x64): D:\Programmi\Media\AviSynth+\plugins64+


[CPP 2.5 Plugins (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64\Dither-1.27.2.dll [2015-12-30]
D:\Programmi\Media\AviSynth+\plugins64\f3kdb-2.020140721-SAPikachu.dll [2015-02-19]

[CPP 2.6 Plugins (64 Bit)]
D:\Programmi\Media\AviSynth+\plugins64+\AutoAdjust-2.60.dll [2.6.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\ConvertStacked.dll [2016-10-20]
D:\Programmi\Media\AviSynth+\plugins64+\DCTFilter-0.5.0-chikuzen.dll [0.5.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\DirectShowSource.dll [2016-10-26]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.4-pinterf.dll [2.4.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\ImageSeq.dll [2016-10-20]
D:\Programmi\Media\AviSynth+\plugins64+\KNLMeansCL-1.1.0.dll [2017-05-04]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.12-pinterf.dll [2.2.12.0]
D:\Programmi\Media\AviSynth+\plugins64+\MedianBlur2-0.94-tp7.dll [2014-02-10]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.24-pinterf.dll [2.7.24.0]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.96-pinterf.dll [0.96.0.0]
D:\Programmi\Media\AviSynth+\plugins64+\Shibatch.dll [2016-10-20]
D:\Programmi\Media\AviSynth+\plugins64+\TimeStretch.dll [2016-10-20]
D:\Programmi\Media\AviSynth+\plugins64+\VDubFilter.dll [2016-10-20]

[Scripts (AVSI)]
D:\Programmi\Media\AviSynth+\plugins64+\colors_rgb.avsi [2015-03-21]
D:\Programmi\Media\AviSynth+\plugins64\CompTest.avsi [2010-09-05]
D:\Programmi\Media\AviSynth+\plugins64\DeHalo_alpha-realfinder.avsi [2017-02-26]
D:\Programmi\Media\AviSynth+\plugins64\Dither-1.27.2.avsi [2015-12-30]
D:\Programmi\Media\AviSynth+\plugins64\MT_xxpand_multi.avsi [2010-09-11]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2ú94-realfinder.avsi [2017-11-15]
D:\Programmi\Media\AviSynth+\plugins64\VHSHaloremover.avsi [2017-02-25]

[Uncategorized files]
D:\Programmi\Media\AviSynth+\plugins64+\AutoAdjust-2.60.txt [2015-11-15]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64+\colors_rgb.txt [2015-03-21]
D:\Programmi\Media\AviSynth+\plugins64+\DCTFilter-0.5.0-chikuzen.md [2016-08-03]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.4-pinterf.gif [2005-04-04]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.4-pinterf.htm [2017-10-31]
D:\Programmi\Media\AviSynth+\plugins64+\FFT3dFilter-2.4-pinterf.txt [2017-06-08]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.0a48.htm [2010-12-31]
D:\Programmi\Media\AviSynth+\plugins64+\MaskTools-2.2.12-pinterf.md [2018-01-07]
D:\Programmi\Media\AviSynth+\plugins64+\MedianBlur-0.84.txt [2004-12-07]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.24-pinterf.htm [2017-12-05]
D:\Programmi\Media\AviSynth+\plugins64+\MVTools-2.7.24-pinterf.md [2017-12-05]
D:\Programmi\Media\AviSynth+\plugins64+\RgTools-0.96-pinterf.md [2017-06-09]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth-new.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\AviSynth.css [2016-03-31]
D:\Programmi\Media\AviSynth+\plugins64\Dither-1.27.2.htm [2015-12-30]
D:\Programmi\Media\AviSynth+\plugins64\f3kdb-2.020140721-SAPikachu.htm [2015-02-19]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2ú93-realfinder_avsi [2017-05-05]
D:\Programmi\Media\AviSynth+\plugins64\SMDegrain-3.1.2d.htm [2015-07-21]

Script:
SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\1_58 Hitman's bodyguard\hitman01.dgi")

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,truemotion=true,plane=4,chroma=true,lsb=true,mode=0)

Prefetch(6)

Hitman's raw.7z (http://www21.zippyshare.com/v/uxocHvV9/file.html)
Hitman's enc.7z (http://www21.zippyshare.com/v/PmudiFm7/file.html)
Hitman's dgi.7z (http://www21.zippyshare.com/v/bLaD6Iz1/file.html)
Hitman's dgi avs.7z (http://www21.zippyshare.com/v/FE0IOf0W/file.html)

Enjoy. ;)

[real.finder]

Hitman's raw.7z (http://www21.zippyshare.com/v/uxocHvV9/file.html)
Hitman's enc.7z (http://www21.zippyshare.com/v/PmudiFm7/file.html)
Hitman's dgi.7z (http://www21.zippyshare.com/v/bLaD6Iz1/file.html)
Hitman's dgi avs.7z (http://www21.zippyshare.com/v/FE0IOf0W/file.html)

Enjoy. ;)

I just see hitman01.mkv and hitman02.mkv they not same as old bug, I think they are new bug in mvtools or something, try with older versions of mvtools

edit: after see the others, it's kinda like the old one, try with older masktools too, and then try with tv_range=false if even old masktools not work

[tormento]

I just see hitman01.mkv and hitman02.mkv they not same as old bug, I think they are new bug in mvtools or something, try with older versions of mvtools

edit: after see the others, it's kinda like the old one, try with older masktools too, and then try with tv_range=false if even old masktools not work
Reverting to previous versions of MVTools and MaskTools did not solve, tv_range=false yes.
Something wrong in avisynth again or SMDegrain? Strange 264 input?
Tried also with up to 2 versions of AviSynth back, i.e. up to 2544.

[real.finder]

if only tv_range=false solve it then yes the old bug is back, try with many avs+ versions until you get the one that work

[tormento]

if only tv_range=false solve it then yes the old bug is back, try with many avs+ versions until you get the one that work
Using too old AviSynth versions throws no ExtractU function. Can't remember since when it was introduced.

We definitely need Pinterf help :)

EDIT: I have tried every version back to 2420 and got same error. From 2294 and before, I get no ExtractU function and can't test.

[raffriff42]

In all RGB Planar modes, Subtitle colors appear with R and G swapped
Colorbars
ConvertToPlanarRGBA
tc = $ff00 ## green
Subtitle(Hex(tc), text_color=tc, size=56, align=5)
return ConvertToRGB32 ## for viewing purposes
https://www.dropbox.com/s/nkcx847vfo9mxl9/subtitle-RGPx-2018-01.png?raw=1

[pinterf]

In all RGB Planar modes, Subtitle colors appear with R and G swapped
Thanks, fixed.

[pinterf]

Here we go.
OS: Windows 10 ent x64 rs4 17083 italian
Enjoy. ;)
Thanks, almost as enjoyable as the 8th hour in an ultra running race :)
This one is different though.

In the old (fixed) problem the String(1.04) yielded "1,04" instead of "1.04" in our windows input local. It was fixed to always using decimal _point_ for separator (input local = "C language"), because dither tools' lut interpreter could not recognize constants with commas as decimal separator. Now it's s different problem since I can see only decimal points in the expression.
Since then I was also moving to Win10 and see the problem (I'm testing with another clip): greyish/burnt out parts in fast moving scenes.

[pinterf]

if only tv_range=false solve it then yes the old bug is back, try with many avs+ versions until you get the one that work

The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.

Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)

[...]
}

And one more remark. When you want to scale the YUV TV range limits 16-235, 16-240, or their difference (like 112 = (240-16)/2), use scaleb instead of scalef. scaleb correctly converts "official" bit-shifted limits (e.g. 16*4, 235*4: 64-940 for 10 bits), while scalef (Scale _F_ull range) is for stretching a range of 0-255,1023,4095,16383,65535 to another bit-depth's full range of 0..255,1023,4095,16383,65535. So 235 in a 8bit world would become 235*1023/255 = 942 in 10 bits, which is not correct.

[real.finder]

The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.

Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)

[...]
}

And one more remark. When you want to scale the YUV TV range limits 16-235, 16-240, or their difference (like 112 = (240-16)/2), use scaleb instead of scalef. scaleb correctly converts "official" bit-shifted limits (e.g. 16*4, 235*4: 64-940 for 10 bits), while scalef (Scale _F_ull range) is for stretching a range of 0-255,1023,4095,16383,65535 to another bit-depth's full range of 0..255,1023,4095,16383,65535. So 235 in a 8bit world would become 235*1023/255 = 942 in 10 bits, which is not correct.

yes that right, will did next time when do update, in fact I stopped updating scripts waiting for the new changes of bit convert, even if SMDegrain don't need those changes, I will do adding some parameters that come with the next update of masktools to make sure that no one will run it with older masktools and get some wrong outputs like https://forum.doom9.org/showthread.php?p=1813270#post1813270

[tormento]

I stopped updating scripts waiting for the new changes of bit convert
Could you please release an intermediate version to make things usable now? :p

I applied the fix proposed from Pinterf and things are working. Dunno if other mods are needed.

[real.finder]

Could you please release an intermediate version to make things usable now? :p

I applied the fix proposed from Pinterf and things are working. Dunno if other mods are needed.

find and replace what Pinterf edit in his last post then

[Aktan]

I find that these two return different Stack16 clips, am I missing something?

#YV16 Source 8-bit
ConvertBits(bits=32)
ConvertBits(bits=16)
ConvertToStacked()

#YV16 Source 8-bit
ConvertBits(bits=16)
ConvertBits(bits=32)
ConvertBits(bits=16)
ConvertToStacked()

[StainlessS]

This would be nice addition to +.


RT_BitSetCount(int)
Return an int, the count of the number of set bits (1's) in arg int.
NOTE, Previous Bit functions are similar to the v2.6 bit manipulation functions, however this one has no equivalent in v2.6
[perhaps it should, it is quite handy, as used in the ApparentFPS() script prototype)]

BitClrCount easily calc'd from above.

EDIT: Here, S_ApparentFPS(), ApparentFPS prototype script function, would have been difficult/impossibly_slow without RT_BitSetCount.
https://forum.doom9.org/showthread.php?p=1698788#post1698788
EDIT: This line, about 80% of the way through the script function.

Unique = RT_BitSetCount(BITS0) + RT_BitSetCount(BITS1) + RT_BitSetCount(BITS2) + RT_BitSetCount(BITS3) +
\ RT_BitSetCount(BITS4) + RT_BitSetCount(BITS5) + RT_BitSetCount(BITS6) + RT_BitSetCount(BITS7)

Above script function limited to 256 frame sample spread, was later increased to 1024 frames for plugin only (@ request of Scharfis_Brain, would maybe be a bit much for the script function, even with BitSetCount).

[pinterf]

This would be nice addition to +.


RT_BitSetCount(int)
Return an int, the count of the number of set bits (1's) in arg int.
NOTE, Previous Bit functions are similar to the v2.6 bit manipulation functions, however this one has no equivalent in v2.6
[perhaps it should, it is quite handy, as used in the ApparentFPS() script prototype)]

BitClrCount easily calc'd from above.


This one?
https://stackoverflow.com/questions/109023/how-to-count-the-number-of-set-bits-in-a-32-bit-integer

RT_xxx collection have quite a few useful function, do you (or others) recommend to cherry-pick some of them, which are worth of integration and futureproof?

Edit:
- New script function: int BitSetCount(int[,int, int, ...])
Function accepts one or more integer parameters
Returns the number of bits set to 1 in the number or the total number of '1' bits in the supplied integers.

[real.finder]

since the topic now is runtime, pinterf can you have a look at https://forum.doom9.org/showthread.php?t=175212

and any news about fix the old mt problem with runtime?

[StainlessS]

This one?
https://stackoverflow.com/questions/109023/how-to-count-the-number-of-set-bits-in-a-32-bit-integer

From StackOverflow: (Looks more efficient than my naive effort).

int numberOfSetBits(int i)
{
// Java: use >>> instead of >>
// C or C++: use uint32_t
i = i - ((i >> 1) & 0x55555555);
i = (i & 0x33333333) + ((i >> 2) & 0x33333333);
return (((i + (i >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24;
}


From RT_Logic.cpp (my naive effort)

env->AddFunction("RT_BitSetCount","i",RT_BitSetCount, 0);
AVSValue __cdecl RT_BitSetCount(AVSValue args, void* user_data, IScriptEnvironment* env) {
unsigned int n = (unsigned int)args[0].AsInt();
int cnt=0;
for(int i=0;i<32;n>>=1,++i)
if(n&0x01) ++cnt;
return (int)cnt;
}

I think I recently saw some Intrinsic to count number of set bits, not sure, might have been for 64 bit only.

I dont think avs 2.6 implements Arithmetic Shift Left, just Logical Shift Left, probably not needed but I also
implemented in RT_.


Edit:
- New script function: int BitSetCount(int[,int, int, ...])
Function accepts one or more integer parameters
Returns the number of bits set to 1 in the number or the total number of '1' bits in the supplied integers.
Oh My, I had not even considered multiple args to BitSetCount, very nice :)

This one?
RT_xxx collection have quite a few useful function, do you (or others) recommend to cherry-pick some of them, which are worth of integration and futureproof?


Here, some suggested additions.

From RT_File.cpp

env->AddFunction("RT_FileDelete", "s",RT_FileDelete, 0);

env->AddFunction("RT_WriteFile", "ss.*[Append]b",RT_WriteFile, 0);


From RT_Call.cpp, call external command [EDIT: Most often used to delete a file, prior to RT_FileDelete.]

env->AddFunction("RT_Call", "s[Hide]b[Debug]b", RT_Call, 0);



From RT_Debug.cpp [EDIT: In desparate need of this one, probably the singularly most useful function]

env->AddFunction("RT_DebugF", "s.*[name]s[tabsz]i", RT_DebugF, 0);


From RT_Func.cpp,

# Mod, add width arg.
env->AddFunction("RT_Hex", "i[width]i",RT_Hex, 0);

RT_Hex(int , int "width"=0)
First arg is an integer to convert to a hexadecimal string.
Width, (0, 0 -> 8) is the minimum width of the returned string.
eg RT_Hex(255,4) returns "00FF".

AVSValue __cdecl RT_Hex(AVSValue args, void* user_data, IScriptEnvironment* env) {
int n = args[0].AsInt();
int wid = args[1].AsInt(0);
wid=(wid<0) ? 0 : (wid > 8) ? 8 : wid;
char buf[8+1];
sprintf(buf,"%0*X",wid,n);
return env->SaveString(buf); // Get pointer to Avisynth saved string
}

# Mod, add pos arg.
RT_HexValue(String,"pos"=1)
Returns an int conversion of the supplied hexadecimal string.
Conversion will cease at the first non legal number base digit, without producing an error
Fixes HexValue bug in 2.58 & 2.6a3. eg "FFFFFFFF" returns 2147483647 (0x7FFFFFFF) instead of the correct -1 (As most/all calculators)
Bug is fixed in Avisynth v2.6a4.
v1.14, Added optional pos arg default=1, start position in string of the HexString, 1 denotes the string beginning. Will return 0
if error in 'pos' ie if pos is less than 1 or greater than string length.

env->AddFunction("RT_HexValue", "s[pos]i",RT_HexValue, 0);

AVSValue RT_HexValue(AVSValue args, void*, IScriptEnvironment* env) {
const char *str = args[0].AsString();
int pos = args[1].AsInt(1) - 1;
int sz=strlen(str);
if(pos<0 || pos>=sz)
return 0;
str+=pos;
char *stopstring;
return (int)(strtoul(str,&stopstring,16));
}

# Mod
env->AddFunction("RT_NumberString", "i[base]i[width]i",RT_NumberString, 0);

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.

# Mod
env->AddFunction("RT_NumberValue", "s[base]i[pos]i",RT_NumberValue, 0);

RT_NumberValue(String,int "base"=10,int "pos"=1)
Returns an int conversion of the supplied number base string.
Base, (10, 2 -> 36) is the number base that the string uses.
To convert a Decimal string to a Float, use Avisynth native "Value()" func.
Conversion will cease at the first non legal number base digit, without producing an error.
eg RT_NumberValue("1100",2) returns 12 from the binary string.
v1.14, Added optional pos arg default=1, start position in string of the number string, 1 denotes the string beginning. Will return 0
if error in 'pos' ie if pos is less than 1 or greater than string length.



from RT_Odds.cpp

env->AddFunction("RT_VarExist", "s",RT_VarExist, 0);

env->AddFunction("RT_VarType", ".",RT_VarType, 0);

env->AddFunction("RT_Ord", "s[pos]i",RT_Ord, 0);

env->AddFunction("RT_TimerHP", "",RT_TimerHP, 0);

env->AddFunction("RT_GetSystemEnv", "s",RT_GetSystemEnv, 0);

env->AddFunction("RT_GetFileTime", "si",RT_GetFileTime, 0);

env->AddFunction("RT_LocalTimeString", "[file]b",RT_LocalTimeString, 0);


from RT_String.cpp

env->AddFunction("RT_StrReplace", "sss[sig]b",RT_StrReplace, 0);

# Replace multiple strings, not so often used but is very powerful, allows for a sort of macro language where
# strings can replace substrings of already replaced strings.

env->AddFunction("RT_StrReplaceMulti", "sss[sig]b",RT_StrReplaceMulti, 0);

env->AddFunction("RT_StrPad", "si[c]s",RT_StrPad, 0);

# Mod,
env->AddFunction("RT_FindStr", "ss[sig]b[pos]i",RT_FindStr, 0);

# Must have. Although take source from RT_Stats v2.0, with bug fix. Or from StrFmt() plugins, also suggest StrFmt as name.
AVSValue __cdecl RT_String(AVSValue args, void* user_data, IScriptEnvironment* env);

env->AddFunction("RT_String", "s.*[esc]i",RT_String, 0);

StrFmt():- https://forum.doom9.org/showthread.php?t=174649&highlight=StrFmt
EDIT: StrFmt does not support the Esc arg, probably best omitted as StrFmt does (Esc arg, very demanding on script developer).

from RT_Sundry.cpp

env->AddFunction("RT_ColorSpaceXMod", "c",RT_ColorSpaceXMod, 0);

env->AddFunction("RT_ColorSpaceYMod", "c[Laced]b",RT_ColorSpaceYMod, 0);


EDIT: Additional from RT_String.cpp

env->AddFunction("RT_TxtAddStr", "ss+",RT_TxtAddStr, 0);

RT_TxtAddStr(String, String s1, ... , String sn)
Non-clip function.
Function to concatenate (join together) 2 or more strings with Chr(10) line separators.
If the first string is an empty string ("") it will not have a newline [Chr(10)] appended.
All other strings even empty strings will have a newline [Chr(10)] inserted after them
(if they dont already have a trailing newline).
Any source string containing carriage return Chr(13) will have them converted to Chr(10).
X = RT_TxtAddStr("A","B","C") same as X = "A" + Chr(10) + "B" + Chr(10) +"C" + Chr(10)
X = RT_TxtAddStr("","A","B","C") same as X = "" + "A" + Chr(10) + "B" + Chr(10) + "C" + Chr(10)

env->AddFunction("RT_TxtQueryLines", "s",RT_TxtQueryLines, 0);

RT_TxtQueryLines(String)
Non-clip function.
String, the multiline string that you require a line count from.
Returns the number of Newline [Chr(10)] separated lines in a multiline string.
The last line does not have to be Chr(10) terminated, it still counts. [EDIT: awkward/slow to do in script alone]

env->AddFunction("RT_TxtGetLine", "s[Line]i",RT_TxtGetLine, 0);

RT_TxtGetLine(String, Int "Line"=0)
Non-clip function.
Extract a single line from a multiline Newline[Chr(10)] separated string. Default=0 == first line.
The Line index is Zero Relative like frame number versus FrameCount.
The returned string has trailing Newlines and carriage returns stripped from it.
Throws an error if your requested line is >= to the number of lines in the multiline string.

EDIT: Above stuff for use where strings can be used as a sort of simple array.

[pinterf]

I think I recently saw some Intrinsic to count number of set bits, not sure, might have been for 64 bit only.


POPCNT, don't think it's our bottleneck if I'm omitting that


I dont think avs 2.6 implements Arithmetic Shift Left, just Logical Shift Left, probably not needed but I also
implemented in RT_.

No difference for left shift. Right is arithmetic because it copies MSB instead of filling in zeros.


RT_Hex(int , int "width"=0)

Done. Did you know that in avs+ the hex string was in lowercase?


# Mod, add pos arg.
RT_HexValue(String,"pos"=1)

Done. -1 bug was not present, probably the fix was pulled from classic avs


from RT_String.cpp
env->AddFunction("RT_StrReplace", "sss[sig]b",RT_StrReplace, 0);

ReplaceStr exists already in avs+, and I was just about adding a 'case insensitive' parameter. Probably I'll keep your parameter naming.

I'll look at the rest later.

[StainlessS]

Yep, PopCnt looks familiar.

No difference for left shift. Right is arithmetic because it copies MSB instead of filling in zeros.
Yep, I sort of remembered that, but not sure, long since I've done Z80, M68K assembler.

Done. Did you know that in avs+ the hex string was in lowercase?
Yeh, think I remember that avs uses lower case, I dont like that and would almost always output uppercase (personal prefs).
[EDIT: Almost obligatory to use uppercase for hex on M68K machines]

I'll look at the rest later.
Cool :cool:

[raffriff42]

I have been working on some AVS+ enhancement routines for months without promoting it.
http://avisynth.nl/images/Utils-r41.avsi

The more useful ones (they're essential, to me anyway) are listed below.

The single most useful function (if I had to pick one) is MatchColorFormat - match color format to a template clip.
Use this before splicing or stacking two clips when you're not sure of their current color formats.


### MISCELLANEOUS FUNCTIONS

### return true if running in Avisynth+, false otherwise
#@ function IsAvsPlus()

### return AVS+ build number, if present; else 0
#@ function VersionBuildNumber()

### return basic clip properties as a string
## Example | Assert(false, InfoString) ## show info about current Last variable
#@ function InfoString(val C, string "label")

### STRING FUNCTIONS

### count the number of line breaks (for multi-line Subtitle(align=1|2|3)
#@ function CountLines(string s, bool "lsp")

### Split long lines for [[Subtitle]] line wrap
#@ function SplitLines(string s, int "lastcol", bool "reflow")

### trim spaces from both ends of string
#@ function Trim(string s)

### trim spaces from left end of string
#@ function TrimLeft(string s)

### Get part of a full path to right of last '\'
#@ function GetNameFromPath(string path)

### Get part of a full path to left of last '\'
#@ function GetParentFolder(string path)

### format seconds as hh:mm:ss.ddd
#@ function FormatTime(float fsec, int "decimals")

### format hours/minutes/seconds as hh:mm:ss.ddd
#@ function FormatTime(int t_hours, int t_mins, float t_secs, int "decimals")

### for bits==32, return "S", else return String(bits)
#@ function BitsToPixelType(int bits)

### NUMERIC FUNCTIONS

### return argument 'f' as integer and ensure it is modulo 'm'
#@ function modx(int m, float f, int "dir")

### Hex() with leading "0" if less than 2 chars long
#@ function Hex2(int i)

### scale [[ColorYUV]]'s 'gain_x', 'gamma_x' & 'cont_x'
### to more intuitive values (like [[Tweak]]'s)
#@ function f2c(float f)

### calculate new width, given height, for preserving aspect ratio
#@ function CalcWidth(clip C, float fhgt, int "mod", int "lim")

### calculate new height, given width, for preserving aspect ratio
#@ function CalcHeight(clip C, float fwid, int "mod", int "lim")

### DEEP COLOR ARGUMENT SCALING FUNCTIONS

### scale an 8-bit value for target clip 'T'
#@ function sc8f(clip T, float f, bool "cx")

### scale an 8-bit value for target clip 'T'; clamp output
#@ function sc8x(clip T, float f)

### scale an 8-bit value for target clip 'T'; string result
#@ function sc8s(clip T, float f, int "decimals")

### UTILITY FILTERS

### Convert from anything to planar RGB(A)
#@ function ToRGB(clip C, string "matrix", int "bits_out", val "A")

### Convert from anything to YUV(A)444
#@ function To444(clip C, string "matrix", int "bits_out", val "A")

### Convert from anything to YUV(A)422
#@ function To422(clip C, string "matrix", int "bits_out", val "A")

### Convert from anything to YUV(A)420
#@ function To420(clip C, string "matrix", int "bits_out", val "A")

### Convert from anything to best equivalent 16-bit version
#@ function To16bit(clip C, clip "A")

### Convert from anything to best equivalent higher-bit-depth version
#@ function ToHibit(clip C, int bits, clip "A")

### Convert from anything to best equivalent lower-bit-depth version
#@ function ToLobit(clip C, int bits, bool "dither", clip "A")

### Convert from anything to 'best' (v2.6x compatible) equivalent 8-bit version
#@ function To8bit(clip C, bool "dither")

### make changes needed to display on vdubFM (VirtualDub FilterMod)
#@ function ToVdubFM(clip C, bool "dither")

### Match color format of source 'C' to template 'T'
#@ function MatchColorFormat(clip C, clip T, string "matrix", bool "keepbits", bool "dither")

### Match audio properties of source 'C' to template 'T'
#@ function MatchAudioFormat(clip C, clip T, bool "allowresample")

### convert levels from 'TV' (black=16d, white=235d) to 'PC' (black=0, white=255d)
#@ function ToPC(clip C)

### convert levels from 'PC' (black=0, white=255d) to 'TV' (black=16d, white=235d)
#@ function ToTV(clip C)

### 709->601 (less green, more red)
#@ function To601(clip C)

### 601->709 (more green, less red)
#@ function To709(clip C)

### remove sRGB gamma transfer function (if bit depth > 8) for linear-light processing
### ( used in [[#ScaleZoom]], [[#ScaleSize]] )
#@ function remove_gamma(clip C, bool "enable", string "matrix")

### apply standard gamma transfer function (if bit depth > 8)
#@ function restore_gamma(clip C, bool "enable", string "matrix")

### COLOR AND OVERLAY FILTERS

### scale 0-255 [[Levels]] arguments to current bit depth
#@ function Levelsc(clip C,
##\ float input_low, float gamma, float input_high,
##\ float output_low, float output_high, bool "coring",
##\ bool "dither", bool "chroma")

### Enhanced [[SGradation]]; semi-independent control of highlights & lowlights
#@ function SGradation2D(clip C,
##\ float loBoost, float hiCut,
##\ float "bluSat", float "yelSat",
##\ float "redSat", float "grnSat", bool "tvrange")

### [[Layer]] with support for 'mask', 'opacity' and 'align' parameters
#@ function LayerAligned(clip base, clip over, string "op", int "level",
##\ clip "mask", float "opacity", int "align")

### [[Overlay]] with support for 'align' parameter
### supports adding borders to, or letterboxing, inset clip
#@ function OverlayAligned(clip base, clip over,
##\ int "x", int "y", clip "mask", float "opacity", string "mode",
##\ bool "greymask", string "output", bool "ignore_conditional",
##\ bool "pc_range", int "align", int "borderwidth", int "bordercolor")


### CROP, RESIZE AND TRANSFORM FILTERS

### alias for [[#Cropd]] with argument order: Left, Right, Top, Bottom
#@ function CropLRTB(clip C, int left, int right, int top, int bottom, bool "align", int "mod")

### alias for [[#Cropd]] with argument order: Left, Top, Width, Height
#@ function CropLTWH(clip C, int left, int top, int width, int height, bool "align", int "mod")

### show a helpful diagnostic string on [[Crop]] failure; optionally enforce [[Mod]]
#@ function Cropd(clip C, int x, int y, int wid, int hgt, bool "align", int "mod")

### switch (or fade) between three [[Resize]] clips depending on scale factor
### (overridable with user-specified resizers e.g. nnedi3 etc)
### (ScaleZoom sizes by percent; ScaleSize by width and/or height)
#@ function ScaleZoom(clip C, float factor, int mod,
##\ string "sm", string "med", string "lg",
##\ float "thrSm", float "thrLg", bool "fade", bool "ident",
##\ bool "gamma", bool "hibit")

### switch (or fade) between three [[Resize]] clips depending on scale factor
### (overridable with user-specified resizers e.g. nnedi3 etc)
### (ScaleZoom sizes by percent; ScaleSize by width and/or height)
#@ function ScaleSize(clip C, float fwid, float fhgt, int mod,
##\ string "sm", string "med", string "lg",
##\ float "thrSm", float "thrLg", bool "fade", bool "ident",
##\ bool "gamma", bool "hibit")

### crop or expand a clip to ensure it is a certain size (symmetrically by default)
#@ function CropEx(clip C, float wid, float hgt, int "mod",
##\ int "align", int "dx", int "dy", bool "debug")

### quick Gaussian blur
#@ function QGaussBlur(clip C, float radx, float "rady")

### DEBUGGING FILTERS

### [[Eval]] a script snippet; show script & its return value (clip or nonclip)
#@ function EvalShow(clip C, string s, string "font", float "size",
##\ int "text_color", int "halo_color",
##\ float "x", float "y", int "align", string "name")

### return color ramp clip w/ same specs as template clip 'T'
#@ function ColorRampEx(clip T, int "left_color", int "right_color", int "height",
##\ bool "zigs", bool "stack", int "noise")

### return grayscale ramp clip w/ same specs as template clip 'T'
#@ function Grayramp(clip T, int "height", bool "zigs", bool "stack", int "noise")

### YUV/RGB vectorscope (inverted so red is top-left and hue increases counter-clockwise)
#@ function Vector2(clip C, string "matrix", bool "bottom")

### Classic [[Histogram]], waveform on top (or on bottom); supports RGB
### many little enhancements; accepts both YUV & RGB
#@ function HistogramTurn(clip C, bool "parade", bool "shrink", bool "bottom")

### show video waveform + vectorscope; many little enhancements; accepts both YUV & RGB
#@ function ScopeR(clip C, bool "shrink", bool "vector", string "matrix", bool "parade", bool "bottom")

### Simple waveform + vectorscope. Accepts 8-bit, YUV(A) only.
#@ function ScopeY(clip C, bool "shrink", bool "vector", bool "levels", bool "bottom")

### print color channel statistics on the screen
### (auto switch between RGBAdjust(analyze=true) and ColorYUV(analyze=true)
### @ format - optional nicer formatting
#@ function Analyze(clip C, bool "format")

### show original & 3 channels (Y, U, V or R, G, B) in quad split
#@ function ShowChannels(clip C, bool "analyze", bool "uinvert", bool "chroffset")

### [[ShowFrameNumber]] with support for 'opacity' and 'align'
#@ function ShowFrameNumberAligned(
##\ clip C, bool "scroll", int "offset",
##\ float "x", float "y", string "font", int "size",
##\ int "text_color", int "halo_color",
##\ float "font_width", float "font_angle",
##\ float "opacity", int "align")

[StainlessS]

### show original & 3 channels (Y, U, V or R, G, B) in quad split
#@ function ShowChannels(clip C, bool "analyze", bool "uinvert", bool "chroffset")

Presumably in honour of my plugin ShowChannels :)

EDIT: https://forum.doom9.org/showthread.php?t=163829&highlight=ShowChannels

ShowChannels:-

Typical output for a YUV clip:-
---------------------------

347 ] Frames Visited = 348

This Frame Accumulated
Y U V Y U V
Ave 77.00 125.52 125.42 70.91 125.87 125.78
Min 4 80 95 0 69 83
Max 255 177 165 255 190 174
~Min 14 95 101 12 92 101
~Max 234 167 148 235 167 151

---------------------------

where
'AVE' shows average for current frame and accumulated average for all visited frames.

'MIN' shows minimum value for a channel, this frame and accumulated.

'MAX' shows maximum value for a channel, this frame and accumulated.

'~MIN' shows loose minimum value for a channel, this frame and accumulated.

'~MAX' shows loose maximum value for a channel, this frame and accumulated.

Loose minimum uses the filter arg float MinPerc, a percentage of total pixels to ignore
when finding the loose minimum, allows to ignore extreme stray pixels (noise).

Loose maximum uses the filter arg float MaxPerc, a percentage of total pixels to ignore
when finding the loose maximum, allows to ignore extreme stray pixels (noise).

The "loose" values are made to filter out very bright
or very dark noise creating an artificially low or high minimum / maximum.

The Accumulated Ave is a "Average of Averages", or "Average Mean" or "Mean Average", take your pick but accumulated seemed more appropriate
considering that it was not restricted to describing just the averages. Accumulated Min is the minimum of all minimums so far, etc.

[pinterf]

I have been working on some AVS+ enhancement routines for months without promoting it.
http://avisynth.nl/images/Utils-r41.avsi

Really nice collection.

Note#1
Why do you need to ##HACK in function GBR2YUV(clip C, bool "yuva")? Packed RGB is upside down (unlike planar RGB), but you are flipping not all the three 'planes', why?

Note#2
In restore_gamma (and where luts are used) you can use the Expr function for 32bit float case. Single 8-16bit lut is faster now with mt_lut, but for 32bit float would help (rare use case nowadays). In general I recommend using scalef and scaleb instead of @F @B, Expr supports only the word ones.
Another comment: 255 @F (255 scalef) is better written as 'range_max'

I'm planning to make Expr to automatically recognise fast (8-16 bit mt_lut and 8 bit mt_lutxy-like) cases and automatically turn them into real LUT working mode).

Note#others.. later, too much new stuff for today :)

[Atak_Snajpera]

Sorry for interrupting but can somebody tell me why Prefetch does not like my subtitle rendering script on YUV420P10? Image flashes and eventually script crashes my player (MPC-HC).
If I remove video=Prefetch(video,8) then everything is ok.

Test script (video.avs)
http://www.mediafire.com/file/c9n8ml9gr1rby1v/AviSynth%20MT%20Prefetch%20issues.7z

[LigH]

@StainlessS:

Would you consider providing a CHM documentation for a recent AviSynth+ state again if collecting all the differences to AviSynth 2.60 doesn't mean too much efforts?

[pinterf]

Sorry for interrupting but can somebody tell me why Prefetch does not like my subtitle rendering script on YUV420P10? Image flashes and eventually script crashes my player (MPC-HC).
If I remove video=Prefetch(video,8) then everything is ok.

Test script (video.avs)
http://www.mediafire.com/file/c9n8ml9gr1rby1v/AviSynth%20MT%20Prefetch%20issues.7z
Thanks, good report. For me it crashed after 41-42 seconds: 6399, 6319, 6369 are the frame numbers that avsmeter64 is showing before the crash.
When using Trim(5000,..) the crash occurs at around frame 1400.
I suspect something in the subtitle text around that spot.

EDIT: debugging in avs+ (arrrgh, perhaps because the debug build is slower, it was the 5th run until it gave error, unlike the release build which crashed 100%)

It stopped at
frame = ChildFilters[env2->GetProperty(AEP_THREAD_ID)]->GetFrame(n, env);
with message: Exception thrown at 0x00007FFCBBB6C909 (VSFilter.dll) in AVSMeter64.exe: 0xC0000005: Access violation writing location 0x0000000000000000. occurred

[Atak_Snajpera]

Script won't crash if we use SetFilterMTMode("TextSub",MT_SERIALIZED) but this still does not fix flashing (frame corruption) of the whole frame.
It is more noticeable if you put real video instead of BlankClip

http://i.cubeupload.com/TscvHT.png

[pinterf]

Does it have a source? Searched on it and there is VsFilter, xy-vsfilter, etc.. I'm not familiar with them.

[Atak_Snajpera]

Here version 306
https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.0.0.306

[pinterf]

Have you tried the newer betas? 3.1.0.746
https://forum.doom9.org/showthread.php?t=168282

[raffriff42]

Really nice collection.

Note#1
Why do you need to ##HACK in function GBR2YUV(clip C, bool "yuva")? P

Note#2
In restore_gamma (and where luts are used) you can use the Expr function for 32bit float case.Thanks a lot, pinterf.
#1 Marked HACK, because not tested thoroughly.
#2 Masktools stuff not updated to use Expr yet, will fix.
Will start a new thread on this (soon) to avoid yet more hijacking of the current thread...

[Groucho2004]

@StainlessS:

Would you consider providing a CHM documentation for a recent AviSynth+ state again if collecting all the differences to AviSynth 2.60 doesn't mean too much efforts?
The up-to-date documentation for Avisynth and Avisynth+ is here (http://avisynth.nl/index.php/Main_Page) which even highlights functionality differences between the two (see example here (http://avisynth.nl/index.php/Colorbars)) thanks to raffriff42 spending countless hours editing the pages.

There's probably a way to cram all that into an offline thingy, be it CHM or plain HTML although I prefer the online version since it always has the latest changes.

[pinterf]

Huh, it comes with a 2.5x avisynth header, and compiled to x64? Not a life insurance.
EDIT: I mean xy-vsfilter. Not an easy thing to recompile. Cannot find afx.h. One of the uglyest message a machine can say.

[StainlessS]

@StainlessS:

Would you consider providing a CHM documentation for a recent AviSynth+ state again if collecting all the differences to AviSynth 2.60 doesn't mean too much efforts?

I might need a few months to mentally prepare for the task. :)

Raff, did you see my prev post ? (#3944)

[Groucho2004]

Huh, it comes with a 2.5x avisynth header, and compiled to x64? Not a life insurance.Yes, there is a 2.5 header floating around. I think it originates from SEt's (JoshyD's?) 2.5.8 x64 version.

[Groucho2004]

Cannot find afx.h. One of the uglyest message a machine can say.Wow, MFC. It uses CString (and probably some other MFC stuff)!

[pinterf]

I have MFC / ATL as an installed feature though.

[qyot27]

The up-to-date documentation for Avisynth and Avisynth+ is here (http://avisynth.nl/index.php/Main_Page) which even highlights functionality differences between the two (see example here (http://avisynth.nl/index.php/Colorbars)) thanks to raffriff42 spending countless hours editing the pages.

There's probably a way to cram all that into an offline thingy, be it CHM or plain HTML although I prefer the online version since it always has the latest changes.

I might need a few months to mentally prepare for the task. :)
I migrated AviSynth+'s documentation to Sphinx a few years ago, although the distinct changes or comparison pages that got into the Wiki haven't been added. It's up-to-date with the 2.6 HTML documentation, at least. The instructions to build the docs exist on the MT branch's README.md file.

The benefit of moving the docs to Sphinx is that it can be easily edited (the source files are now virtually plain-text) and once rendered, it's searchable.

Basically, whatever benefit CHM docs provide, I'm confident that Sphinx is superior to it in virtually every way. You can output to HTML, PDF, ePub, latex, and several other formats (I only did testing with HTML, though, so the nice formatting of the HTML output isn't guaranteed or even there for any of the others).

[Atak_Snajpera]

Have you tried the newer betas? 3.1.0.746
https://forum.doom9.org/showthread.php?t=168282

Support for AviSynth has been dropped after 306
http://i.cubeupload.com/lIxKW1.png

[raffriff42]

Here's a strange one.BlankClip
_aaa
return Last

function aaa(clip C) {
return C.Subtitle("HOW DID I GET HERE??", align=5)
}
It shouldn't work, but it does (note leading underscore on function call)

[pinterf]

Seems that empty dll name plus underscore plus aaa works here
EDIT: When a function is not coming from a dll, the plugin_base_name is empty, the internal secondary 'canon_name' is simply _functionname.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L209

[pinterf]

Looking at raffriff42's stuff (convert Tweak-like parameters for ColorYUV), plus because I have finally implemented ColorYUV for 32 bit float, I realized that gain, contrast and gramma parameter are not really convenient and intuitive.
So I have made a ColorYUV2 with the same parameter names but accepting the Tweak-like numbers instead.
My question is about the naming - I don't like this one with 2 suffix. AdjustYUV? YUVYUV? YUVYUVYUV? :)
Or should we add a new parameter to the existing ColorYUV list as a hint to treat the parameter ranges Tweak-like?
EDIT: ColorYUV2 is an existing one so is ruled out from the contest (StainlessS)

[StainlessS]

ColorYUV2(), Hmmm, https://forum.doom9.org/showthread.php?t=156774

https://forum.doom9.org/showthread.php?p=1378126&highlight=Coloyuv2#post1378126

http://www.mediafire.com/file/875czvfnigu72ds/ColorYUV2_25_dll_20120529.zip

[raffriff42]

For a name, I think maybe ColorYUVs (s for scaled).
In a similar way, I have made (http://avisynth.nl/images/Utils-r41.avsi) Levelsc where sc means scaled - I didn't want Levelss because someday StainLessS might want the name :devil:

[StainlessS]

LevelsS, fine with me. :)

Raff, did you see the ShowChannels post, ie #3944
### show original & 3 channels (Y, U, V or R, G, B) in quad split
#@ function ShowChannels(clip C, bool "analyze", bool "uinvert", bool "chroffset")

Presumably in honour of my plugin ShowChannels :)

ShowChannels:- https://forum.doom9.org/showthread.php?t=163829&highlight=ShowChannels


EDIT: Perhaps Viewchannels().

EDIT: To below Raff post, Thanx, Raff, just wanted to ensure that you had seen that post.

[VS_Fan]

TweakYUV

[raffriff42]

StainLessS, OK, I get your drift - I'm hijacking your filter name. Henceforth, my filter will be called ShowChannelsQuad.

[real.finder]

adding a new parameter to the existing ColorYUV list is better option in my opinion

[pinterf]

I have been working on some AVS+ enhancement routines for months without promoting it.
http://avisynth.nl/images/Utils-r41.avsi

Some comments and clarifications.
- I have just checked, displaying YUV444P16 (Y416) now works with the latest (v41106) VdFilterMod.
- in AnalyzeFmt: "Note stats labeled "99%" actually 99.6% (255/256)"
This is true only for 8 bits.
For bit depths over 8 the resolution is finer, because pixel population is gathered into an array of 1024/4096...65536 entries. For float the population is also counted: using 65536 levels.
- float fullscale max is 1.0
(note: in the near future (I've already done some preparations) chroma in 32 bit float will go to -0.5..0.5 instead of current early decided 0..1.0. It'll solve the possible problems about "what is neutral grey chroma in float for a 0..1.0 range".
- when converting to float, we stretch 0..255, 0..1023.. 0..65535 into the 0..1 range. The conversion factor is not simply 2^N, but 2^N - 1.

[pinterf]

adding a new parameter to the existing ColorYUV list is better option in my opinion
Yes, let's not duplicate the very same function. f2c=true will do it.

[raffriff42]

pinterf, I appreciate the clarifications. I've noticed unexpected chroma output when converting float32 TV<->PC and now I see why.


Regarding ColorYUV, gamma has an issue - gamma is calculated between 0-255 instead of 16-235.

Here are some screenshots which (by the way) demo some Utils-r41 (http://avisynth.nl/images/Utils-r41.avsi) filters:

https://www.dropbox.com/s/kg8h4cif2s9zm4t/ColorYUV-gamma-test-21.png?raw=1
(linear response for comparison)

https://www.dropbox.com/s/bcmeekid3fp9nhc/ColorYUV-gamma-test-22.png?raw=1
(note elevated black and white levels)


https://www.dropbox.com/s/0slmrgwea9ur0k8/ColorYUV-gamma-test-23.png?raw=1
(black and white correctly unchanged)


Import(p + "Utils-r41.avsi")
s="""
BlankClip(pixel_type="YV12")
Grayramp(height=80, zigs=true)
ToPC
ColorYUV(gamma_y=f2c(1.5))
ToTV
HistogramTurn
"""
r=Eval(s)
ShowSnippet(s, r, size=24)

[raffriff42]

RGB48 & RGB64 : IsInterleaved property = false
(IsPlanar = false also)

[pinterf]

Thanks, that gamma thing found, classic avs is ok, for couriousity I'll check when it disappeared.

EDIT:
nothing has been disappeared.

The biggest difference I found is that in AVS+ the "PC->TV" and "TV->PC" conversion happens at the end of the gain-contrast-offset-gamma conversion, while classic Avisynth is doing that the the beginning of the process.

There is no correction before applying gamma in either versions. Assumes PC range.
This is why it worked for you with an input having PC levels.

Now when you want to have proper black levels you have to do similar like this:
ColorYUV(levels="TV->PC").ColorYUV(....,gamma_y=-40).ColorYUV(levels="PC->TV")
Which is obviously not a nice solution.

In theory, the ColorYUV function (after modification) would know that it should apply gamma on TV level.
We surely know that input is PC or TV range when levels="TV->PC" or "PC->TV" is given.
When none of the above levels parameters exist, coring=true would also indicate that the clip is TV range.

Probably levels="TV" (a newly allowed value for "levels") would help clarifying if none of the above mentioned options are set. (Why cannot we have frame properties in avs?)

[pinterf]

New build. So many things has been changed, now I really need feedback.

Download Avisynth+ r2636 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2636-MT)

EDIT: 2632 link replaced


20180302 r2636
--------------
- Fix: Blur/Sharpen crashed when YUY2.width<8, RGB32.width<4, RGB64.width<2 (StainlessS)
- Fix: ColorYUV: don't apply TV range gamma for opt="coring" when explicit "PC->TV" is given
- Fix: ColorbarsHD: 32bit float properly zero(0.5)-centered chroma

20180301 r2632
--------------
- Fix: IsInterleaved returned false for RGB48 and RGB64 (raffriff42)
- Fix: SubTitle for Planar RGB/RGBA: wrong text colors (raffriff42)
- Fix: Packed->Planar RGB conversion failed on SSE2-only computers (SSSE3 instruction used)
- Enhanced: Blur, Sharpen
AVX2 for 8-16 bit planar colorspaces (>1.35x speed on i7-7770)
SSE2 for 32 bit float formats (>1.5x speed on i7-7770)
- Fix: Resizers for 32 bit float rare random garbage on right pixels (simd code NaN issue)
- Enhanced: Completely rewritten 16bit and float resizers, much faster (and not only with AVX2)
- Enhanced: 8 bit resizers: AVX2 support
- Enhanced: Speed up converting from RGB24/RGB48 to Planar RGB(A) - SSSE3, approx. doubled fps
- New: ConvertFPS supports 10-32 bits, planar RGB(A), YUV(A)
- New script function: int BitSetCount(int[, int, int, ...])
Function accepts one or more integer parameters
Returns the number of bits set to 1 in the number or the total number of '1' bits in the supplied integers.
- Cherry-picking from StainlessS' great RT_xxxx collection/and raffriff42 utils
- Modded script function: Hex(int , int "width"=0)
- New "width" parameter
- result is in uppercase
Width is 0 to 8, the _minimum_ width of the returned string. (8 hex digit is the max of Avisynth32 bit integer)
When width is 0 or not supplied then string length is a minimum needed.
Function now returns hex string in uppercase, instead of lowercase.
Example: Hex(255,4) returns "00FF".
- Modded script function: HexValue(String, "pos"=1)
- new pos parameter
Returns an int conversion of the supplied hexadecimal string.
Conversion will cease at the first non legal number base digit, without producing an error
Added optional pos arg default=1, start position in string of the HexString, 1 denotes the string beginning.
Will return 0 if error in 'pos' ie if pos is less than 1 or greater than string length.
- Modded script function: ReplaceStr(String, String, String[, Boolean "sig"=false])
- New parameter: sig for case insensitive search (Default false: exact search)
The uppercase/lowercase rules come from the current active code page of the OS.
- New script functions: TrimLeft, TrimRight, TrimAll for removing beginning/trailing whitespaces from a string.
Whitespaces: Tab (9), space (32), nbsp (160)
- New in ColorYUV:
New parameter: bool f2c="false".
When f2c=true, the function accepts the Tweak-like parameters for gain, gamma and contrast
E.g. use 0/0.5/1.0/1.5/2.0/3.0 instead of -256/-128/0/128/256/512
- New/Fixed in ColorYUV:
Parameter "levels" accepts "TV". (can be "TV->PC", "PC->TV", "PC->TV.Y")
Now gamma calculation is TV-range aware when either
- levels is "TV->PC" or
- coring = true or
- levels is "TV" (new - no level conversion but gamma will know proper handling)
Previously gamma was properly calculated only for PC range.
- New in ColorYUV:
32 bit float support.
- 32 bit float uses the Expr filter (8-16 bits is LUT-based). The expression is dynamically assembled for each plane, internal precision is float.
- One can specify bits=32 when showyuv=true -> test clip in YUV420PS format
For 32 bit clips "loose min" and "loose_max" (omitting the extreme 1/256 population from dark and bright pixels) statistics are computed
by splitting the 0..1 into 65536 uniform ranges.
- Modded: remove "scale" parameter from ConvertBits.
It was introduced at the very beginning of the 10+bit development, for 32bit float conversion - never used
- Enhanced: VfW: exporting Y416 (YUV444P16) to SSE2.
- 8-16 bit YUV chroma to 32 bit float: keep middle chroma level (e.g. 128 in 8 bits) at 0.5.
Calculate chroma as (x-128)/255.0 + 0.5 and not x/255.0 (Note: 32 bit float chroma center will be 0.0 in the future)
- New: Histogram parameter "keepsource"=true (raffriff42)
keepsource = false returns only the Histogram w/o the original picture.
Affects "classic", "levels" and "color", "color2", ignored (n/a) for the other modes
- New: Histogram type "color" to accept 10-32bit input and "bits"=8,9,..12 display range
- New: Histogram parameter "markers"=true
When markers = false:
For "classic": no "half" level line and no invalid luma zone coloring
For "levels": no "half" dotted line, no coloring (neither for YUV nor for RGB)
Ignored for the others at the moment.

[StainlessS]

ColorYUV(levels="TV->PC").ColorYUV(....,gamma_y=-40).ColorYUV(levels="PC->TV")
Which is obviously not a nice solution.


I used to always do like that.

- New/Fixed in ColorYUV:
Parameter "levels" accepts "TV". (can be "TV->PC", "PC->TV", "PC->TV.Y")
Now gamma calculation is TV-range aware when either
- levels is "TV->PC" or
- coring = true or
- levels is "TV" (new - no level conversion but gamma will know proper handling)
Previously gamma was properly calculated only for PC range.

Long time needed.

Lots of lovely new toys, thanx muchly :)

[LigH]

muchly

:confused: Does that exist at all?

[StainlessS]

Does that exist at all?

Muchly:- http://www.yourdictionary.com/muchly

adverb
Muchly is defined as a very informal way to say very much.
An example of muchly is when you really want something.


Informal very much: used mainly in the humorous phrase thanks muchly


Usage notes
Often regarded as a misconstruction of adverbial much.


From The Concise Oxford Dictionary, Ninth Edition, 1995. [EDIT: Before the avalanche of weird new words added to dictionaries]
Muchly: Adverb. jocular [Middle English from muchel].
Gandalf might have used it muchly, then again, he might not have.

EDIT: And yet this one got by unmentioned,
thanx muchly

EDIT: Ref below post (for LigH).
Methinks: (dated or humorous) it seems to me. [EDIT: Methinks that Bill Shakespeare probably oft used both Muchly and Methinks, and also Oft]

[pinterf]

Methinks you are right ;)

[StainlessS]

BugRep.

Was playing with S_Exlogo() v1.1, Script:- https://forum.doom9.org/showthread.php?t=154559&highlight=S_Exlogo

and was getting some kind of crash, isolated to this producing error in new avs+ (ok in avs standard).


BlankClip(Width=4,height=100,Pixel_type="YUY2",color=$808080)
Blur(1.0,0.0) # Oh no, the humanity, Error
# EDIT ADDED Alternatives
Blur(1.0) # Error
Blur(0.5) # Error


Dont know how long it has been a prob.

EDIT: Seems to be Access Violation in VDFM.
EDIT: YV12, no prob.

EDIT: This S_Exlogo() line produced error (when pat_v string is evaluated).

pat_v= ( \
Select(ok_v, \
("NoneDummy" ) , \
( (HBlur==0.0) ? "Crop(PX-4,PY,4,PH).BilinearResize(PW*4,PH).Crop(PW*3,0,PW,PH)" \
: "Crop(PX-4,PY,4,PH).Blur(HBlur,0.0).BilinearResize(PW*4,PH).Crop(PW*3,0,PW,PH)" ) , \
( (HBlur==0.0) ? "Crop(PX2, PY,4,PH).BilinearResize(PW*4,PH).Crop(0,0,PW,PH)" \
: "Crop(PX2, PY,4,PH).Blur(HBlur,0.0).BilinearResize(PW*4,PH).Crop(0,0,PW,PH)" ) , \
( (HBlur==0.0) ? "StackHorizontal(Crop(PX-2,PY,2,PH),Crop(PX2,PY,2,PH)).BilinearResize(PW*3,PH).Crop(PW,0,PW,PH)" \
: "StackHorizontal(Crop(PX-2,PY,2,PH),Crop(PX2,PY,2,PH)).Blur(HBlur,0.0)" + \
".BilinearResize(PW*3,PH).Crop(PW,0,PW,PH)" ) \
) \
)

[pinterf]

Thanks. Will look at it soon.
EDIT: This YUY2 bug probably exists since forever (quicky tested with r2266), occurs when width is less than 8.
EDIT2: Crash happens when RGB32 has width<4, and RGB64 width<2

[pinterf]

New build r2636, original post edited. Thanks StainlessS for the report.
https://forum.doom9.org/showthread.php?p=1835248#post1835248

[TomArrow]

Hello guys, new here.

I've been using AviSynth 32bit, now upgraded to AviSynth+ with that "use my old plugins" option.

Now my problem is, any time an error occurs, it seems I only get "Avisynth open failure: System exception - Access Violation". (Opening with VirtualDub or VirtualDub FilterMod)

64 Bit seems to output proper messages, for example when using with ffmpeg, but I am dependent on many 32 bit plugins from the old AviSynth.

Somewhere I read that the older release r1858-pfmod might work. I tried it (by replacing the dlls) and indeed now I got reasonable error messages like "function does not exist". I was even able to use loadPlugin to load ffms2 and load a clip with FFmpegsource2. The sad thing is, that version does not yet support deep color apparently, as it says it can't find the function ConvertBits.

Deep color is important to me and is the main reason I upgraded.

I am not sure what I'm doing wrong. I also tried running VirtualDub Filtermod as an administrator, no difference.

Interestingly, the error message does show the correct line in the script. When I move the loadPlugin for ffms2.dll down 2 lines, the error is shown as line 3 instead of 1.

But no matter what error it is, it's always just that System Exception. I can write "blahblurp" in there and still get a System Exception. This is not very helpful for debugging or finding errors.

I have a Windows 7 Ultimate 64 bit pc with an i7-3930k, 32GB RAM and a GTX 1070 on a Sabertooth X79, if it's any use.

Hope this can be resolved, as I have already tested the deep color functionality with the internal AVISource and it was pretty good! I hope to now be able to also use all my old plugins and get proper error messages.

Edit: I was able to avoid the error message altogether by calling ClearAutoloadDirs() in the beginning. Probably because I was using LoadPlugin anyway? Still, would be nice to resolve it.

[LigH]

As usual in case of problems: Use
AVSMeter.exe -avsinfo -log
to check for the availability of and possible issues with plugins.

[StainlessS]

TomArrow, At a guess, I might think plugin problem. Try Groucho2004 (on current avs+, forget older one)

AvsMeter -avsinfo -log

Post results.

EDIT: Arh, that pest LigH, is just too fast :)

EDIT: 64 bit provides error messages because it is not having a 32 bit plugin autoload problem.
Might also want to put ffms2 dll in autoload plugins directory, just to view the AvsMeter results relating to it. (can later remove)

EDIT: Some avs v2.6 plugins compiled with old avisynth header (prior to avisynth 2.6 Alpha 4) will crash if used on Avisynth v2.6 Alpha 4
and later, guessin that this may be the problem (because the older avs+ works ok, probably from pre alpha 4 era).

EDIT: Was your previous Avisynth version, before Avs 2.6 Alpha 4 ?

[TomArrow]

Damn you guys are fast. Thanks for the answers!

I tried what you said and entered that commandline, but all I get is a "Query Avisynth info..." stuck for minutes with CPU at 17% or so (probably one core).

Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)

[StainlessS]

v2.6 Alpha 4 and later sets some linkage stuff (below in blue), which is not done in plugins compiled before alpha 4.
When plugin accesses avisynth v2.6 Alpha 4 (and later) internal routines then below blue stuff not properly prepared and bang !!!


#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
#else
const AVS_Linkage *AVS_linkage = 0;
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
#endif
env->AddFunction("DeCrack", "c[[Fade]f",Create_DeCrack, 0);
return "`DeCrack' DeCrack plugin";
// A freeform name of the plugin.
}


EDIT: AvsMeter will probably not be able to tell you anything about bad plugin that is not compiled with later avisynth header,
Avsmeter might well crash for same reason as avisynth with old plugin in plugins directory. [EDIT: dont know if it checks AVS_linkage for NULL]
You may have to manually pinpoint bad plugins by trial and error (clear plugins, then add in batches of maybe 10 and test, then remove and try next batch, until problem batch located, then narrow down to bad plug [there may be more than 1 bad plug])

EDIT:
Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)
Yes.

EDIT: Not sure, perhaps AVS_linkage=NULL, only produces a problem on last autoloaded bad plugin,
EDIT: Maybe not, I guess that AVS_linkage is private copy for each individual plugin.

EDIT: Found the problem thing here:- https://forum.doom9.org/showthread.php?p=1703427#post1703427
@Jenyok,
Are you using an old version of Avisynth v2.6, If so, you need to update as ClipClop uses new AvisynthPluginInit3() only available in Alpha 4+ ?
(Or alternatively use the v2.58 dll).
There will (I think) be a reciprocal problem if plugin compiled with pre-Alpha 4 header, and not using AvisynthPluginInit3().
[So as previously posted in this thread, I was on the 'right track', but a bit back-to-front :) ]

[TomArrow]

Okay that makes sense, I will do that try-and-error for the batch of plugins when I find some time to do that. Meanwhile I'll just load manually. Thanks a lot!

[pinterf]

@raffriff42: Big thanks for the documentation update, I was just about to do that for recent r2636 changes and saw that you have already done that.
I have added one or two things (e.g. ColorYUV supports float, levels "TV", gamma handling, Histogram "bits") and clarified AddAlphaPlane that it can use a single Y clip or a number as the source for Alpha plane.
I hope I kept the standard formatting.

[raffriff42]

Yes, good work! You also caught an omission I made re: classic AviSynth - ColorYUV(levels="TV.Y")

[StainlessS]

EDIT: Oops, moved to Mvtools, then moved to here.
EDIT: Moved here from thread in Avisynth Usage

EDIT: Does NOT occur in AVS v2.61 standard.

Weird Colors in YUY2.

If using MPeg2source with UpConv=1 (YUY2) then wierd colors after MCDegrainSharp, OK if UpConv=0(YV12).

What is causing the problem (easy to solve, just dont use UpConv=1).

test.demuxed.log

Stream Type: Elementary
Profile: main@main
Frame Size: 720x576
Display Size: [not specified]
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Progressive
Coding Type: B
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Field Order:
Coded Number: 252
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Timestamp:
Elapsed: 0:00:00
Remain: FINISH
FPS:
Info:


test.demuxed.d2v (I modified path to .\test.demuxed.m2v so that it works from any path)

DGIndexProjectFile16
1
.\test.demuxed.m2v

Stream_Type=0
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x576
Field_Operation=0
Frame_Rate=25000 (25/1)
Location=0,0,0,c65

900 5 0 0 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 340612 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 661168 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 985564 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1305512 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1621368 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1937628 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2253180 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2569228 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2883316 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3193184 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3499688 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3807236 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4115012 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4424460 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4726408 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5023844 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5317740 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5616652 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5912792 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 6198648 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 ff

FINISHED 100.00% VIDEO


test.demuxed.avs

VideoFileName = ".\test.demuxed.d2v"

# YV12 OK, YUY2 produces weird output
UPCONV=1 # 0=YV12, 1 = YUY2

MPEG2Source(VideoFileName,UpConv=UPCONV)

MCDegrainSharp_MOD() # simplified version 1 frame radius only, blocksize 8

return last

Function MCDegrainSharp_MOD(clip c) {
BS=8
OS=4
c2 = c.blur(0.6)
super = c2.MSuper(pel=2, sharp=1)
super_rend = c.sharpen(0.6).MSuper(pel=2, sharp=1,levels=1)
bvec = MAnalyse(super, isb = true, delta = 1, blksize=BS, overlap=OS)
fvec = MAnalyse(super, isb = false, delta = 1, blksize=BS, overlap=OS)
Return c2.MDegrain1(super_rend, bvec,fvec,thSAD=400)
}


Upconv=0 (YV12, OK)
https://s20.postimg.cc/5otpzz9zx/test.demuxed_YV12.jpg (https://postimages.cc/)

Upconv=1 (YUY2, BAD)
https://s20.postimg.cc/9xyg27q4t/test.demuxed_YUY2.jpg (https://postimages.cc/)

Anybody any ideas as to the cause (just curious). [EDIT: Ignore this line, looks like avs+ prob]

Thanx in advance for any answers. [EDIT: Also ignore]

7z (~5.6MB) with about 10 secs m2v + d2v + log + avs)
http://www.mediafire.com/file/pjc49ynwxbpgjb0/WeirdText.7z

EDIT: Maybe Avs+ YUY2 blur still has problems (Still occurs with mvtools v2.5).
EDIT: I dont really notice any problem on live video, only came to light on subtitles[EDIT: credits].

EDIT: Replacing MCDegrainSharp_MOD with blur(0.6) removes problem, maybe its the Sharpen inside MCDegrainSharp that is the problem.

[pinterf]

EDIT: Maybe Avs+ YUY2 blur still has problems[EDIT: credits].
Thanks.
sharpen(0.6) does it.

[StainlessS]

Yep, thanx I just figured that out too. :)

[pinterf]

Found an old comment
// sse2/mmx versions are not identical to C. Sharpen(1.0, 1.0) has ugly artifacts
I removed the sse/mmx code to run it in plain C and it became O.K. Now let's find the bug in the SIMD code.
EDIT: YUY2 sharpen overflow fixed on Github

[real.finder]

The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.

Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)

[...]
}


btw, will this make the systems that use dot has wrong outputs?

[LigH]

Of course.

Systems with a locale using a decimal dot need a decimal dot. If there are locale-independent functions to process numbers, they should default to this syntax.
Systems with a locale using a decimal comma need a decimal comma if numbers are processed depending on the locale.

It would be pretty strange if there were no more locale-independent number functions available under Windows 10, that would interrupt international data exchange in text form.

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.

[tormento]

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.
It should be AVS+ to work accordingly to windows local settings, not the script itself.

[Motenai Yoda]

I do no agree, it should indipendent from windows locale

also 666 posts on post #3999 :devil:

[LigH]

Resist the dark side you must.

And an international portability of scripts can only work when the syntax (here: of numbers) is locale-independent.

Locale-dependent handling of numbers is fine in user interfaces, where an immediate relation between the widget a user fills with a value and the layout of the keyboard the user utilizes can be assumed.