Avisynth+

[dREV]

Not related to the Access Violation, but to the quality instead.
You are bringing everything to 16bit stacked, filtering with f3kdb with 16bit precision, then you are using DitherPost as default to bring everything to 8bit to filter with maa2, lastly you're using DitherPost(mode=6) which is dithering with the Floyd Steinberg error diffusion, then you're converting it again from 8bit dithered to 16bit planar, then you're bringing it to stacked MSB and LSB again, you apply your denoise and then you convert from 16bit stacked to 16bit interleaved and you output it as interleaved.

Why?


Doesn't this make more sense?


#Here we're telling f3kdb to take your 8bit source, filter it with 16bit precision and output 16bit stacked

#Debanding 16bit stacked

f3kdb(input_depth=8, output_mode=1, output_depth=16)

#Now we're gonna truncate everything to 8bit,
#apply anti-aliasing with maa2 and then use the original 16bit stacked we received from f3kdb
#and apply only the changes made by maa2 thus retaining 16bit precision

#antialiasing 8bit, 16bit stacked output
s16 = last
DitherPost (mode=-1)
maa2()
Dither_convert_8_to_16 ()
s16.Dither_limit_dif16 (last, thr=1.0, elast=2.0)

#16bit stacked resize and debanding

ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)


#your 16bit stacked degrain filter

Something()

#16bit planar output (your target is x265 which will handle 16bit planar just fine; just remember to add --dither to the command line)

ConvertFromStacked()


Thanks for your critique of my script. It's really helpful and will be looking at it more intently to better my script in the hopes I can speed up my encoding time or get better quality or both. However, sorry seems I took out the s16 code from my script example. Could you let me know if your critique still applies or not? I've indicated it with the color red (and some others) and yes I do use --dither. Link is here (https://forum.doom9.org/showthread.php?p=1892169#post1892169).

Also, would like to know why I cannot use Prefetch(2) for 720p or if I even need it or if 1 is good enough. For my DVD's in 480p it runs just fine with Prefetch(2) but if a source requires anti-aliasing using maa2() even at 480p I have no choice but to use Prefetch(1) as I get Access Violation.

I don't get it. With 8 gigs I thought that should be enough. Could it be that AviSynth issue running out of memory?

[LigH]

To access most of your RAM, do you execute it with a 64-bit application? Apart from that, an access violation can have different reasons, maybe also a code error in one of the used plugins, so it's probably worth a closer investigation. Try running it in AVSMeter64, this tool should produce quite verbose error messages. Also don't underestimate that an encoder itself needs RAM too (in this regard, 8 GB can already be "rather low" when processing FullHD content, too little for x265 already).

[StainlessS]

What LigH said,
+, have a look at your Windows logs for both Application and System errors.
My Computer/Properties/Manage/Event Viewer/Windows Logs/
Application, & System


It's AviSynth+ 0.1.0 r2772 using the 32 bit version with the 10 bit hack pipeline for HEVC in MeGUI 2525.

Best update to avs+ v3.4.0:- https://github.com/AviSynth/AviSynthPlus/releases

[FranceBB]

Definitely update Avisynth+ like StainlessS said.
As to the lack of RAM, if you're using x86, you might wanna take a look at this: https://forum.doom9.org/showthread.php?t=163281
I successfully made Avisynth x86 use more than 7 GB of RAM on my 32 GB system by splitting each filter into a separate process so that each process can allocate 2 GB of RAM and Avisynth as a whole can allocate as much RAM as possible.
As to the modifications in red, I'll take a look at it later as I'm really in a hurry right now.

[dREV]

To access most of your RAM, do you execute it with a 64-bit application? Apart from that, an access violation can have different reasons, maybe also a code error in one of the used plugins, so it's probably worth a closer investigation. Try running it in AVSMeter64, this tool should produce quite verbose error messages. Also don't underestimate that an encoder itself needs RAM too (in this regard, 8 GB can already be "rather low" when processing FullHD content, too little for x265 already).

You mean AviSynth+ 64 bit? No, I'm using the 32 bit version but I use the 64 bit HEVC and H264 encoders using the 10 bit hack pipeline. I lost detail when using jpsdr's ResampleMT/Desample (https://forum.doom9.org/showthread.php?t=174248) with real.finder's updated DebilinearM (https://forum.doom9.org/showthread.php?t=174121)script 2-3 months ago. No clue if it's like the 32 bit now have not done any testings. My RAM is around 70% to 95% depending if I'm idle or watching YouTube (and having opened too many tabs) waiting on my encode to finish and other things. My issue is that if I don't take the precautions when using maa2 I have to wait for the indexing of lsmash to finish and that could take an hour or two and then go into each script and edit out/in "Prefetch(0)" to "Prefetch(1)" which adds to my annoyance and wastes my time especially when I wanna go to sleep.

I've only gotten this Access Violation majority of times when using real.finder's maa2 script (https://forum.doom9.org/showthread.php?t=174121) in combination with Prefetch(1). It never fails. With older versions of maa2 this issue is non-existent. Maybe cuz real.finder's updated maa2 script uses HBD or something? I've used AVSMeter 32 bit version and it gives no errors just does it as if no issues.

Encoder needs RAM? That's news to me I never heard this before. I'm content with just 720p sources at the moment.

What LigH said,
+, have a look at your Windows logs for both Application and System errors.
My Computer/Properties/Manage/Event Viewer/Windows Logs/
Application, & System

Best update to avs+ v3.4.0:- https://github.com/AviSynth/AviSynthPlus/releases

I'm not sure what that first one is about. My thing says it's not working maybe cuz I turned it off or something when I was turning/blocking telemetry on my PC. What does that have to do with the issue tho? Also, thanks I had no idea there was an update to Avisynth+. I thought pinterf was still doing but nothing kept turning up on his GitHub page and I haven't kept up to reading the AviSynth+ thread. Not sure why but got a lil bit more better details with this and seems the new AviSynth+ updater has included stuff for AMD users like me. I can't tell if I'm getting better speeds since I'm encoding using maa2 at the moment and that usually fluctuates. Ranging from 64 fps to 82 fps at the moment.

Definitely update Avisynth+ like StainlessS said.
As to the lack of RAM, if you're using x86, you might wanna take a look at this: https://forum.doom9.org/showthread.php?t=163281
I successfully made Avisynth x86 use more than 7 GB of RAM on my 32 GB system by splitting each filter into a separate process so that each process can allocate 2 GB of RAM and Avisynth as a whole can allocate as much RAM as possible.
As to the modifications in red, I'll take a look at it later as I'm really in a hurry right now.

Nah, I'm on a 64 bit OS but using 32 bit AviSynth+ as mentioned above and my reasoning.

I've did a few tweaks using your critique if I understood it correctly. However, I cannot use your f3kdb settings cuz I get errors. MeGUI complains that the resolution is not the same plus there was some things that wasn't working out right like when I would use Gradfun3 with mask using lsb as I need it to be the first thing done before applying any other filter to lessen any detail loss. Anyways here's what I been using

dither_convert_8_to_16()

#Debanding - Gradfun3 16bit lsb with mask=0
#misc filter(s) 16 bit lsb - only if needed like smdegrain
s16 = last
DitherPost(mode=-1)

#line darkening (sometimes)
maa2()

dither_convert_8_to_16())
s16.Dither_limit_dif16 ()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=-1)

ConvertBits(bits=16) #I want this here to get more bitrate but at first I did some tests using what you wrote
ConvertToStacked()

# grain
ConvertFromStacked().ConvertToDoubleWidth()

What you think? I got a lil bit more detail like this and not sure on the fps since taking out TurnRight and Left since I didn't know maa2 had it in the script. Could you let me know what this is that you wrote? #Now we're gonna truncate everything to 8bit,
#apply anti-aliasing with maa2 and then use the original 16bit stacked we received from f3kdb
#and apply only the changes made by maa2 thus retaining 16bit precision

#antialiasing 8bit, 16bit stacked output
What do you mean by using the original 16 bit stacked received from f3kdb and apply only the changes made by maa2 retaining 16 bit precision? I understand the 16 bit precision but not the rest you wrote. And the "antialiasing 8 bit, 16 bit stacked output" part? Like adding dither 8 to 16 after maa2? I'm not understanding this if it's not that as I don't think maa2 has 16 bit. :)

[hello_hello]

Also, would like to know why I cannot use Prefetch(2) for 720p or if I even need it or if 1 is good enough. For my DVD's in 480p it runs just fine with Prefetch(2) but if a source requires anti-aliasing using maa2() even at 480p I have no choice but to use Prefetch(1) as I get Access Violation.

Lsmash taking an hour or two to index seems completely mental, unless it's indexing a large number of files first before MeGUI encodes.

If I add maa2() to a script in MeGUI's Script Creator and preview it, when I close the Script Creator MeGUI invariably complains about an error and wants to close. MeGUI doesn't use Avisynth+ 3.4 as it's portable Avisynth yet and I haven't tested 3.4 as I still have Avisynth 2.6 installed, but it happens when using Avisynth 2.6 too. If I comment out maa2() before loading a script to add it to the job queue (as from memory, the same thing happens) then uncomment maa2() before running the encoding job, it's usually fine from there. I'm not using MeGUI's OneClick encoder. I'm running XP.

Maybe there's some weird problem with maa2() that only effects MeGUI, but I have no idea what could cause it. Have you tried opening a script containing maa2() with another program such as MPC-HC to see if there's still an access violation, assuming you have Avisynth installed? You can tell MeGUI to use the installed Avisynth to see if anything changes. I'm pretty sure for me, opening the script with a different program is not a problem, but don't quote me on that because I haven't used maa2() for a while and my memory is terrible.

[FranceBB]

Could you let me know what this is that you wrote?
What do you mean by using the original 16 bit stacked received from f3kdb and apply only the changes made by maa2 retaining 16 bit precision? I understand the 16 bit precision but not the rest you wrote. And the "antialiasing 8 bit, 16 bit stacked output" part? Like adding dither 8 to 16 after maa2? I'm not understanding this if it's not that as I don't think maa2 has 16 bit. :)

Well, you were filtering with 16bit precision, however maa2 works in 8bit planar only. The thing is that there's a "trick" to avoid losing 16bit precision when using an 8bit filter. Instead of either truncating or dithering down to 8bit, use maa2 and then bring it back to 16bit, we can do the following:


s16 = last

With this command we're basically gonna tell Avisynth to store into our variable "s16" our 16bit stacked output that we've received from f3kdb.

Now we're going to brutally truncate everything to 8bit planar so that maa2 can work, but don't worry, we're NOT gonna use it directly!

DitherPost (mode=-1)

Ok, now that we have a truncated 8bit planar result, we can use maa2 since it only supports this bit depth:

maa2()

Now that we have filtered with maa2, we're gonna bring it back to 16bit stacked.

Dither_convert_8_to_16 ()

Now, here's the tricky part.
If we go on with our filterchain like this we would lose precision 'cause we have brutally truncated our original 16bit stacked to 8bit planar in order to use maa2, so the 16bit stacked we ended up with at the end is "fake" in the sense that it has gone through a loss of precision.
But... remember what I wrote at the very beginning? We stored our original 16bit stacked BEFORE the anti-aliasing in our variable "s16". So now the idea is to tell Avisynth "Hey, take the original 16bit stacked clip, compare it with the anti-aliased 8bit planar one that we brought to the "fake" 16bit stacked and subtract the changes". This way it's as if we applied anti-aliasing with 16bit precision.


Nah, I'm on a 64 bit OS but using 32 bit AviSynth+ as mentioned above and my reasoning.

That's exactly what I'm saying: since you're using 32bit Avisynth+ on a 64bit OS, you can allocate 4 GB maximum, however if you use MPPipeline you can allocate 4GB per process so if you split your script in as many processes as the filters you have, you can allocate 4GB per scrip, so if you have like 3 filters you can allocate 12 GB of RAM instead of 4GB.

I cannot use your f3kdb settings cuz I get errors.

I see...

[dREV]

Lsmash taking an hour or two to index seems completely mental, unless it's indexing a large number of files first before MeGUI encodes.

That was on the one included in MeGUI and it's from 2017. It takes that long because I use trim to look for banding scenes per episode could be a lot. I've had files where I had to encode over 75 times to get all the banding scenes maybe cuz I'm being too much of a perfectionist.

If I add maa2() to a script in MeGUI's Script Creator and preview it, when I close the Script Creator MeGUI invariably complains about an error and wants to close. MeGUI doesn't use Avisynth+ 3.4 as it's portable Avisynth yet and I haven't tested 3.4 as I still have Avisynth 2.6 installed, but it happens when using Avisynth 2.6 too. If I comment out maa2() before loading a script to add it to the job queue (as from memory, the same thing happens) then uncomment maa2() before running the encoding job, it's usually fine from there. I'm not using MeGUI's OneClick encoder. I'm running XP.

Maybe there's some weird problem with maa2() that only effects MeGUI, but I have no idea what could cause it. Have you tried opening a script containing maa2() with another program such as MPC-HC to see if there's still an access violation, assuming you have Avisynth installed? You can tell MeGUI to use the installed Avisynth to see if anything changes. I'm pretty sure for me, opening the script with a different program is not a problem, but don't quote me on that because I haven't used maa2() for a while and my memory is terrible.

What I did was take the AviSynth+ dll from either the System32 folder or the SysWOW64 folder (dunno which one) and put it in the MeGUI root folder and in the MeGUI/Tools/avs folder to replace the old one. Open MeGUI go to the log tab under Versions it should say this:

--[Information] [12/16/2019 4:46:35 PM] AviSynth+: 3.4 (20-10-2019) (inactive)
--[Information] [12/16/2019 4:46:35 PM] AviSynth+ portable: 3.4 (20-10-2019) (active)

There might be more AviSynth dll's in MeGUI in other folders so may wanna use the search function to find em.

No, I haven't opened it in MPC-HC cuz I dunno how you guys do that. I've seen YouTube videos do that but no steps exactly what they did to get it to be viewed on MPC-HC. I'm using k-lite too codec pack. Would like to know how to do it on AVSPmod as well.


Well, you were filtering with 16bit precision, however maa2 works in 8bit planar only. The thing is that there's a "trick" to avoid losing 16bit precision when using an 8bit filter. Instead of either truncating or dithering down to 8bit, use maa2 and then bring it back to 16bit, we can do the following:


s16 = last

With this command we're basically gonna tell Avisynth to store into our variable "s16" our 16bit stacked output that we've received from f3kdb.

Now we're going to brutally truncate everything to 8bit planar so that maa2 can work, but don't worry, we're NOT gonna use it directly!

DitherPost (mode=-1)

Ok, now that we have a truncated 8bit planar result, we can use maa2 since it only supports this bit depth:

maa2()

Now that we have filtered with maa2, we're gonna bring it back to 16bit stacked.

Dither_convert_8_to_16 ()

Now, here's the tricky part.
If we go on with our filterchain like this we would lose precision 'cause we have brutally truncated our original 16bit stacked to 8bit planar in order to use maa2, so the 16bit stacked we ended up with at the end is "fake" in the sense that it has gone through a loss of precision.
But... remember what I wrote at the very beginning? We stored our original 16bit stacked BEFORE the anti-aliasing in our variable "s16". So now the idea is to tell Avisynth "Hey, take the original 16bit stacked clip, compare it with the anti-aliased 8bit planar one that we brought to the "fake" 16bit stacked and subtract the changes". This way it's as if we applied anti-aliasing with 16bit precision.

Isn't that what I did with my script? It sounds like it.

Also, I worked out the error as I was confused how to implement dither_convert_8_to_16() with Gradfun3 deband filter as I need that. I had no idea that f3kdb(input_depth=8, output_mode=1, output_depth=16) can replace dither_convert_8_to_16() in avspmod and did a test encode and worked out. It's basically the same as above just the removal of the first dither 8 to 16 code.

f3kdb(input_depth=8, output_mode=1, output_depth=16)

#Debanding - Gradfun3 16bit lsb with mask=0
#misc filter(s) 16 bit lsb - only if needed like smdegrain
s16 = last
DitherPost(mode=-1)

#line darkening (sometimes)
maa2()

dither_convert_8_to_16()
s16.Dither_limit_dif16 ()
ly = GradFun3mod(thr=0.35,yuv444=true, resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)

DitherPost(mode=-1)

ConvertBits(bits=16) #I want this here to get more bitrate but at first I did some tests using what you wrote
ConvertToStacked()

# grain
ConvertFromStacked().ConvertToDoubleWidth()

What do you think now? Is it 16 precision fully even with the HDB 16 code after resize? I wasn't certain if this is what you were telling me a page ago of your first critique of my script. Would it matter if I add dither mode 6 in the DitherPost? Overall I got more bitrate with the above combination then the previous and looking forward to doing some more testings.

That's exactly what I'm saying: since you're using 32bit Avisynth+ on a 64bit OS, you can allocate 4 GB maximum, however if you use MPPipeline you can allocate 4GB per process so if you split your script in as many processes as the filters you have, you can allocate 4GB per scrip, so if you have like 3 filters you can allocate 12 GB of RAM instead of 4GB.

I'll take a better look at it when I can. Thanks hoping for good things from it.

[hello_hello]

What I did was take the AviSynth+ dll from either the System32 folder or the SysWOW64 folder (dunno which one) and put it in the MeGUI root folder and in the MeGUI/Tools/avs folder to replace the old one.

Did you check again after closing and re-opening MeGUI to make sure it doesn't replace them with the old Avisynth each time it starts?

No, I haven't opened it in MPC-HC cuz I dunno how you guys do that. I've seen YouTube videos do that but no steps exactly what they did to get it to be viewed on MPC-HC. I'm using k-lite too codec pack. Would like to know how to do it on AVSPmod as well.

I put a shortcut to MPC-HC in the Windows SendTo folder so I can right click on a script and choose SendTo/MPC-HC. You can open scripts via MPC-HC's "File/Quick Open File" menu, but for some reason you can't see scripts by default. You have to select "All Files" from the drop down list of file types in the window for opening files.
For AvsPmod you either open an existing script or create a new one and it has a preview. I don't recall any special requirements for either, other than to have Avisynth installed, but I haven't installed Windows and programs from scratch in quite a while.

By the way, for MPC-HC, Ctrl+E re-opens the current video, so you can modify scripts and re-open them to view the change quite easily, or you can open the script in a second instance of the player to preview the difference. If you can't save changes to scripts because they're locked after MPC-HC opens them, try disabling the Avisynth source filter under Internal Filters in MPC-HC's options, or use Notepad to edit the the scripts. It ignores the locked status and lets you save changes, whereas other editors probably won't.
If a script is too slow MPC-HC will skip frames when you play it before possibly giving up completely, but you can still use the step button on the navigation bar to slowly step through frames etc.

[StainlessS]

Not sure if this has been flagged before. EDIT: v3.4.0


BITS=16
BlankClip.ConvertToYV12.ConvertBits(BITS)
X = 16
Y = 16
W = 128
H = 128
#COL=$00FFFFFF # No Alpha
COL=$FFFFFFFF # Full Alpha
WHT=BlankClip(Width=W,Height=H,Color=COL) # Prob if RGB32 or YV12, but not YUV420P16
WHT=WHT.ConvertToYV12
#WHT=WHT.ConvertBits(BITS)
Overlay(WHT,x=X,y=Y)
crop(0,0,W+2*X,H+2*Y) # Crop Overlayed with 16 pixels border
PointResize(512,512) # for view


Rubbish at bottom of white
https://i.postimg.cc/PJkDdQYd/Overlay.png (https://postimages.org/)

[gpower2]

Hey guys! I just installed AviSynth+ v3.4 and I am looking for the pdb file to load symbolas for AviSynth.dll but unfortunately they are not included in the release assets. :(

Any chance one of the devs could upload them somewhere?

PS.
I am trying to debug a custom application that uses AviSynth, however currently it fails to clear the resources, specifically when trying to delete the environment pointer:

IScriptEnvironment* environment;
...
delete environment;
environment = NULL;

It used to work with previous versions of AviSynth and AviSynth+ but now for some reason it gets stuck in an infinite loop when executing the delete statement...

Edit:
For any guru out there that can understand assembly, the instruction that gets stuck is:

07333830 mov dword ptr [ebp-48h],eax

[Groucho2004]

For reference, this is how I initialise (and destroy) IScriptEnvironment for AVS 2.6 (AVISYNTH_INTERFACE_VERSION 5/6):

const AVS_Linkage *AVS_linkage = 0;
typedef IScriptEnvironment * __stdcall CREATE_ENV(int);

int main()
{
int iInterfaceVersion;
IScriptEnvironment *AVS_env = 0;

HINSTANCE hDLL = ::LoadLibrary("avisynth");
if (!hDLL)
{
//Cannot load avisynth.dll
return -1;
}

try
{
CREATE_ENV *CreateEnvironment = (CREATE_ENV *)GetProcAddress(hDLL, "CreateScriptEnvironment");
if (!CreateEnvironment)
{
//Cannot load CreateScriptEnvironment()
::FreeLibrary(hDLL);
return -1;
}

iInterfaceVersion = 7;
while (!AVS_env)
{
iInterfaceVersion--;

if (iInterfaceVersion < 5)
{
//Cannot create IScriptenvironment (AVSVersion too old)
::FreeLibrary(hDLL);
return -1;
}

AVS_env = CreateEnvironment(iInterfaceVersion);
}

AVS_linkage = AVS_env->GetAVSLinkage();


//Do your stuff



//destroy
AVS_env->DeleteScriptEnvironment();
AVS_env = 0;
AVS_linkage = 0;
}
catch (AvisynthError err)
{
printf("%s", (PCSTR)err.msg);
}

::FreeLibrary(hDLL);
}

Note: This does not work for Avisynth 2.5!

There are additional checks I do, for example making sure avisynth.dll exports "AVS_linkage". If you're interested, look at the code of AVSMeter and/or avsr (link in my sig).

[gpower2]

Thank you very much for your suggestions guys!

To be honest, I am using a patched version of AvisynthWrapper that MeGUI used (I am not sure if it still uses the same), for a C# application.

If I find the time, I may "play" with IScriptEnvironment2, although I am not sure if it's compatible with Avs 2.5 and Avs+ 3.4

But it would be nice to have the pdb files either way for such edge cases. ;)

[Groucho2004]

If I find the time, I may "play" with IScriptEnvironment2, although I am not sure if it's compatible with Avs 2.5 and Avs+ 3.4It's compatible with AVS+ only but still experimental as far as I know.

[wonkey_monkey]

I deleted my post as I realised I don't really know what I'm talking about, but in any case I use IScriptEnvironment2 in conjunction with ->DeleteScriptEnvironment() to delete it, not just calling regular delete, so maybe that's the problem.

[qyot27]

Hey guys! I just installed AviSynth+ v3.4 and I am looking for the pdb file to load symbolas for AviSynth.dll but unfortunately they are not included in the release assets. :(

Any chance one of the devs could upload them somewhere?

PS.
I am trying to debug a custom application that uses AviSynth, however currently it fails to clear the resources, specifically when trying to delete the environment pointer:

IScriptEnvironment* environment;
...
delete environment;
environment = NULL;

It used to work with previous versions of AviSynth and AviSynth+ but now for some reason it gets stuck in an infinite loop when executing the delete statement...

Edit:
For any guru out there that can understand assembly, the instruction that gets stuck is:

07333830 mov dword ptr [ebp-48h],eax
Shouldn't you set environment to NULL before you delete it? I'm not surprised if it crashes when done the other way; I'm pretty sure I had to hammer such a case out of the FFMS2 C-plugin once after changing how the AviSynth library got allocated.

But anyway, the reason is that 3.4 was built as Release, no *.pdb files were generated at all. Also, the packaging in CMakeLists.txt doesn't copy them over to Output/ even if they are generated.

http://www.mediafire.com/file/01xgi9wc87a12pk/avisynth%252B_r2936_20191227.7z/file

The current git HEAD hasn't changed too much since 3.4, so here's a build with the *.pdb and *.ilk files included.

[Groucho2004]

...I use IScriptEnvironment2 in conjunction with ->DeleteScriptEnvironment() to delete it...Not sure if you need the new interface for additional functionality but you don't need IScriptEnvironment2 to use DeleteScriptEnvironment(), it works fine with IScriptEnvironment.

[Groucho2004]

Shouldn't you set environment to NULL before you delete it? I'm not surprised if it crashes when done the other way; I'm pretty sure I had to hammer such a case out of the FFMS2 C-plugin once after changing how the AviSynth library got allocated.Some info on the old 'delete' for AVS 2.5:
https://forum.doom9.org/showthread.php?p=1631151&highlight=delete#post1631151

And the benefit of the newer DeleteScriptEnvironment():
https://forum.doom9.org/showthread.php?p=1512400&highlight=delete#post1512400

When AVSMeter still used the 2.5 interface, I used this to destroy IScriptEnvironment:

AVS_env->~IScriptEnvironment();
AVS_env = 0;

[gpower2]

Shouldn't you set environment to NULL before you delete it? I'm not surprised if it crashes when done the other way; I'm pretty sure I had to hammer such a case out of the FFMS2 C-plugin once after changing how the AviSynth library got allocated.

But anyway, the reason is that 3.4 was built as Release, no *.pdb files were generated at all. Also, the packaging in CMakeLists.txt doesn't copy them over to Output/ even if they are generated.

http://www.mediafire.com/file/01xgi9wc87a12pk/avisynth%252B_r2936_20191227.7z/file

The current git HEAD hasn't changed too much since 3.4, so here's a build with the *.pdb and *.ilk files included.

Actually the avisynth.h I am using doesn't contain a DeleteEnvironment definition in IScriptEnvironment class, so I can't use it.
Also, if I first assign it to NULL, how can I delete it afterwards? :confused: I am a bit of a n00b regarding C++ since I've never written anything at a professional level...

The code is posted in GitHub (really messy stuff, I just created a repo to have a versioning system while updating/cleaning it) and the relevant code is here (https://github.com/Gpower2/AcTools/blob/120ff3cfb4c561067590c0f7a9573e6096ef567e/AcAvisynthWrapper/AcAvisynthWrapper.cpp#L189) in case anyone wants to take a peek.

Thanks for the debug build qyot27, I'll post any results here if I manage to have any! :p

[gpower2]

Some info on the old 'delete' for AVS 2.5:
https://forum.doom9.org/showthread.php?p=1631151&highlight=delete#post1631151

And the benefit of the newer DeleteScriptEnvironment():
https://forum.doom9.org/showthread.php?p=1512400&highlight=delete#post1512400

When AVSMeter still used the 2.5 interface, I used this to destroy IScriptEnvironment (which was a tip IanB gave me and worked fine):

AVS_env->~IScriptEnvironment();
AVS_env = 0;

Wow, crazy stuff! Thanks for the tip Groucho, I think that might solve my problem permanently!

[wonkey_monkey]

Shouldn't you set environment to NULL before you delete it?

If you set a pointer to NULL before you delete it, you've lost the reference to it so you can't delete it. Smart pointers may be a different matter...

[qyot27]

Yeah, I was mistaking that for a situation where the entire library struct was being freed and then the code tried to set it to NULL when it was already gone. And this was in C.

[Cyorter]

Hello! I don't know if this hasn't really reported before but in case of not... (I google-searched it but found nothing else than a little post without reply (https://forum.doom9.org/showthread.php?p=1866733)).

For some reason in the latest release of AviSynthPlus (printerf version), when using Trim and Stack (Vertical/Horizontal), it does not Trim! All clips continue until longest clip is finished.
Also for some reason, when using StackVertical(StackHorizontal(a,b),StackHorizontal(c,d)) to make 2x2 stacked videos, is the audio returned and not a!

[StainlessS]

For some reason in the latest release of AviSynthPlus (printerf version)
You do not say which version you have, "latest release" dont cut it.
Latest version is v3.4.0 (r2923), here:- https://github.com/AviSynth/AviSynthPlus/releases
v3.4.0 is the latest stable until Pinterf publishes new one, some fixes are applied since then, but only in source, not in complied release.
Here, Changes in v3.4.0:- https://forum.doom9.org/showthread.php?p=1892037#post1892037
Also, from post before "Changes" post,
You have to check the master branch.
Either at my repo or the central avs+ repo (which is now a bit behind my repo, since I have some open work on my side)

No idea what that means, I 'dont do' github, but seems to mean that new releases will be appended to the original Ultim releases
[loads of users were downloading a 4 year old version of avs+ because it was linked in first post by Ultim].

That bug seems to have been fixed, I'm assuming that you are using Pinterf r2772-MT here[DONT USE, STILL HAS THE BUG]:- https://github.com/pinterf/AviSynthPlus/releases
There were also a few test versions after r2772.

[Cyorter]

You do not say which version you have, "latest release" dont cut it.
Latest version is v3.4.0 (r2923), here:- https://github.com/AviSynth/AviSynthPlus/releases
v3.4.0 is the latest stable until Pinterf publishes new one, some fixes are applied since then, but only in source, not in complied release.
Here, Changes in v3.4.0:- https://forum.doom9.org/showthread.php?p=1892037#post1892037
Also, from post before "Changes" post,

No idea what that means, I 'dont do' github, but seems to mean that new releases will be appended to the original Ultim releases
[loads of users were downloading a 4 year old version of avs+ because it was linked in first post by Ultim].

That bug seems to have been fixed, I'm assuming that you are using Pinterf r2772-MT here[DONT USE, STILL HAS THE BUG]:- https://github.com/pinterf/AviSynthPlus/releases
There were also a few test versions after r2772.

I was using Pinterf r2772-MT version yes, I thought https://github.com/AviSynth/AviSynthPlus/releases was dead, thanks!

[qyot27]

While videohelp and avisynth.nl both point to the correct download areas and 3.4, the software infobox on the Wikipedia entry for AviSynth still points to r2772 and pinterf's repo, which is probably one source of continuing confusion and people grabbing r2772 instead of 3.4. I'm also not sure if the '(unofficial)' they've appended onto r2772 in the infobox is supposed to indicate that pinterf's builds weren't official x.x releases of Plus, or if it's more of an awkward way of saying Plus itself is 'unofficial' as related to Classic (given the 'preview release' is 2.6.1 Alpha). Granted, the entire lower half of that article is kind of a mess as well, but still.

[Richard1485]

At present in one of the development branches, nearly all of the AviSynth+ core and filters can compile natively on Linux. The missing bits are critical for it actually working on there, but basically, that leap to being fully cross-platform is tantalizingly close now - and a significant reason is because GCC compliance was added 3 years ago.

It would be amazing if AviSynth were to run natively on Linux at some point. Is the GCC version more likely to run smoothly under Wine, or does it not work like that?

[Sharc]

The filter temporalsoften produces an access violation in avisynth+ 3.4.0 x86 r2827.
It still works as expected in avisynth 2.6.0.

[StainlessS]

Colorbars.convertToYV12
TemporalSoften(4,4,8,15,2)


v3.4.0, Works ok, maybe ALWAYS post bombing script.

EDITED due to Wonkey_Monkey chiding.

[wonkey_monkey]

maybe post bombing script.

Always post bombing script.

[qyot27]

It would be amazing if AviSynth were to run natively on Linux at some point. Is the GCC version more likely to run smoothly under Wine, or does it not work like that?
No, MinGW-w64/GCC builds are really just more for experimenting for the hell of it. Nothing to do with working better under Wine (which doesn't make much difference now, the VC 2015-2019 redist actually installs and gets used in Wine pretty easily).

[Sharc]

Colorbars.convertToYV12
TemporalSoften(4,4,8,15,2)


v3.4.0, Works ok, maybe ALWAYS post bombing script.

EDITED due to Wonkey_Monkey chiding.
Here the script:
AviSource("h:\Tape 1\capture_1.avi")
converttoyv12(interlaced=true)
assumeTFF()
separatefields()
temporalsoften(4,4,8,10,mode=2)
fluxsmoothST(3,3)
weave()
assumefps(25)
It works when I put temporalsoften AFTER fluxsmooth.

Edit:
It also works when I put crop(2,0,-0,-0) before temporalsoften. (The frame then becomes 718x576).

Edit2:
It looks like temporalsoften must not be the first filter after separatefields() :confused:

[hello_hello]

Should the following return false, given YUY2 is a 4:2:2 format? I can't see anything on the wiki to indicate YUY2 would be an exception.

Avisynth+ 3.4

Video = AnyEightBitSource
Video = Video.ConvertToYUY2()
return Is422(Video)

Cheers.

[qyot27]

Is422 is for Planar formats. YUY2 isn't planar, and has its own special IsYUY2 function.

And http://avisynth.nl/index.php/Avisynthplus_color_formats shows the entire breakdown.

[hello_hello]

I assumed it must be an interleaved/planar related thing, but still, it would hurt if someone with Wiki access could add the "planar" qualification to the Is422() description to make it clear. http://avisynth.nl/index.php/Clip_properties

Thanks.

PS. What about Is444()? Does it cover RGB formats too? It wouldn't be unreasonable to assume so. I'll test that one myself later.

[StainlessS]

What about Is444()? Does it cover RGB formats too?


# uncomment 1

#colorbars.ConverttoYV24 subtitle(String(Is444)) # true
#colorbars.ConvertToPlanarRGB subtitle(String(Is444)) # false


Is422, Is420, Is444, Planar and YUV ONLY.
IsY, single plane luma (incl Y8).

EDIT:

Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!= 0||FindStr(VersionString," Neo")!=0 }
Function AvsPlusVersionNumber() { IsAvsNeo?Eval(MidStr(VersionString,20,4)):IsAvsPlus?Eval(MidStr(VersionString,17,4)):0}
Function IsAvs26() { VersionNumber>=2.6 }
#
Function X_PixelType(clip c) { c IsAvs26 ? PixelType : IsYV12?"YV12":IsYUY2?"YUY2":IsRGB32?"RGB32":"RGB24" } # Eg "RGB32" or "YUV420P10"
Function X_IsYV411(clip c) { c IsAvs26 ? IsYV411 : False }
Function X_IsY(clip c) { c IsAvsPlus ? IsY : IsAvs26 ? IsY8 : False } # True=Single Plane : (!IsRGB)=True = Any type with Y, YUY2/YUVA/Y8 etc.
Function X_Is420(clip c) { c IsAvsPlus ? Is420 : IsYV12 }
Function X_Is422(clip c) { c IsAvsPlus ? Is422 : False } # YUY2_Clip.Is422=False [ie not Planar]
Function X_Is444(clip c) { c IsAvsPlus ? Is444 : IsAvs26 ? IsYV24 : False }
Function X_IsRGB48(clip c) { c IsAvsPlus ? IsRGB48 : False }
Function X_IsRGB64(clip c) { c IsAvsPlus ? IsRGB64 : False }
Function X_HasAlpha(clip c) { c IsAvsPlus ? HasAlpha : IsRGB32 }
Function X_NumComponents(clip c) { c IsAvsPlus ? NumComponents : IsAvs26&&IsY8 ? 1 : IsRGB32 ?4 : 3 } # Num of channels
Function X_Bpc(clip c) { c IsAvsPlus ? BitsPerComponent : 8 } # Bits per channel, 32 = Float
Function X_YMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Height/ExtractU.Height):(IsYV12 ?2:1) } # Y Min crop multiple for Progressive
Function X_XMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Width/ExtractU.Width):IsAvs26?(IsYV411?4:IsY8||IsRGB?1:2):(IsRGB?1:2)} # X Min crop multiple


EDIT: I'll probably at some point add above + a few more to AvsInit.avsi. [AvsiInit.avsi]:- https://forum.doom9.org/showthread.php?t=176749

[Richard1485]

No, MinGW-w64/GCC builds are really just more for experimenting for the hell of it. Nothing to do with working better under Wine (which doesn't make much difference now, the VC 2015-2019 redist actually installs and gets used in Wine pretty easily).

Thanks for the clarification! I don't want Wine on my main machine, but I might try it on an old rig at some point. Even if AviSynth+ were to run natively on Linux at some point, it occurs to me that some means of previewing scripts would be needed as well.

[qyot27]

Thanks for the clarification! I don't want Wine on my main machine, but I might try it on an old rig at some point. Even if AviSynth+ were to run natively on Linux at some point, it occurs to me that some means of previewing scripts would be needed as well.
Previewing scripts is extremely trivial, libavformat just needs to be directed to look for AviSynth+ instead of AvxSynth (I have a patch locally to do that, even). But like I said, disabling/working around some of the Windows-specific bits means that the compiled libavisynth.so won't load.

[Richard1485]

Previewing scripts is extremely trivial, libavformat just needs to be directed to look for AviSynth+ instead of AvxSynth (I have a patch locally to do that, even).

It's great to hear that it would be trivial, but I've always used VDub or (occasionally) AvsPMod to preview AviSynth scripts, so its not obvious to me how redirecting libavformat would help. To be clear, the means of previewing the script wouldn't matter to me as long as I could step back and forth frame by frame and see the effect of changes. (Yes, I realize that at present this is all hypothetical and that there are Windows-specific parts that won't work.)

[qyot27]

It's not really hypothetical; it's already possible to do that right now* using AvxSynth. Because FFmpeg forms the backbone of practically every video tool of note on Linux, as long as the FFmpeg libraries the tool links against were built with --enable-avisynth, said tool should be able to open and play the scripts just fine so long as it doesn't restrict file extensions (ffplay and mpv have no problem playing scripts; VLC needs to let *.avs be an accepted extension for it to do so). Stepping frame-by-frame is possible in several of the more NLE-esque offerings (I tried with kdenlive; worked fine).

So swapping AvxSynth out for AviSynth+ basically just means the capabilities of the core library massively expand because of the significant differences between AviSynth 2.5.8 (what AvxSynth essentially is) and Plus. The main thing being that AviSynth+ is actually up-to-date, so there's a greater likelihood of newer tools being developed around it that don't have to be as hefty as a full NLE suite. Not to mention that very very few plugins were ever ported to AvxSynth, so AviSynth+ would just naturally attract more plugins getting ported.

*read: since 2013, actually.

[Richard1485]

In that case, I wish that somebody would do it now, because all I really need is the core (by which I mean "built in", no external plugins) functionality of AviSynth(+), especially audio (as long as there would be a way to render it). It wouldn't matter to me that the only way of loading something would be to use ffmpeg, because (as you say) virtually everything on Linux uses that in the background anyway.

[videoh]

Seems like qyot27 recommended you to switch to Avisynth+. That is something you can do right now; you don't need to wait for somebody to do something.

[Richard1485]

Seems like qyot27 recommended you to switch to Avisynth+. That is something you can do right now; you don't need to wait for somebody to do something.

But I don't know how to get AviSynth+ working on Linux: I'd need instructions. If I were on Windows, I'd run the installer, but I'm not on Windows.

[qyot27]

AvxSynth is what is currently available. As long as the stuff you need isn't AviSynth 2.6- or Plus-specific, it can suffice for the time being.

These instructions were written on Ubuntu 19.10. Whether Debian's basal repos use the same package names, I don't know. The version of FFmpeg provided with at least Debian Stretch has --enable-avisynth active by default, and this will also apply to anything built against it (like the kdenlive example above).

# Dependencies:
sudo apt-get install build-essential checkinstall git yasm liblog4cpp5-dev liblog4cpp5v5 libcairo2-dev libpango1.0-dev libjpeg-dev

# Build AvxSynth:
git clone git://github.com/avxsynth/avxsynth.git && \
cd avxsynth

# The following are necessary because avxframeserver fails to build:
sed -i '433d' configure.ac && \
sed -i -e '31d' -e '29d' Makefile.am

# Continue:
autoreconf -fiv && \
CPPFLAGS="-fpermissive -march=native" ./configure --enable-silent-rules --disable-avxedit --disable-ffms2 --with-pic && \
make -j$(nproc) && \
sudo checkinstall --pkgname=avxsynth --pkgversion="1:$(grep "Version" \
avxsynth.pc | cut -f2 -d " ")+$(git rev-list --count HEAD)-g$(git rev-parse \
--short HEAD)-$(date +%Y%m%d)" --backup=no --deldoc=yes --delspec=yes \
--deldesc=yes --strip=yes --stripso=yes --addso=yes --fstrans=no --default

# Build FFmpeg or install the -dev libraries relating to it (avcodec, avformat, avutil, avfilter, avdevice, swscale, postproc, swresample):


# Build FFMS2 for AvxSynth (and retain plugin compatibility with VapourSynth):
git clone git://github.com/qyot27/ffms2_cplugin.git ffms2 && \
cd ffms2 && \
git checkout c_plugin && \
./configure --enable-vapoursynth --enable-avxsynth --enable-shared --extra-cppflags="-march=native" --enable-pic && \
make -j$(nproc) && \
sudo checkinstall --pkgname=ffms2 --pkgversion="1:$(./version.sh)-git" \
--backup=no --deldoc=yes --delspec=yes --deldesc=yes --strip=yes --stripso=yes \
--addso=yes --fstrans=no --default

[videoh]

I would use Vapoursynth on Linux.

[stax76]

I've looked at the code from avs2pipemod, avsr and AvisynthWrapper and they all create a global variable to save the return value from GetAVSLinkage but they are not really doing anything with this variable, what's the point?

[Richard1485]

These instructions were written on Ubuntu 19.10.

Many thanks! That's what I'm running as well. I hope that instructions for AviSynth+ might appear at some point, but I'm very grateful for these.

# Build FFmpeg or install the -dev libraries relating to it (avcodec, avformat, avutil, avfilter, avdevice, swscale, postproc, swresample):

I don't know how to do the latter, so I'll try the former. The static binaries don't seem to have been built with -enable-avisynth.
I would use Vapoursynth on Linux.
Doubtless, and I know what VapourSynth is, but there are still advantages to AviSynth, so it would be beneficial to have both.

[qyot27]

I don't know how to do the latter, so I'll try the former. The static binaries don't seem to have been built with -enable-avisynth.

sudo apt-get install libavcodec-dev libavformat-dev libavutil-dev libavfilter-dev libavdevice-dev libswscale-dev libpostproc-dev libswresample-dev

Should work.

[Groucho2004]

I've looked at the code from avs2pipemod, avsr and AvisynthWrapper and they all create a global variable to save the return value from GetAVSLinkage but they are not really doing anything with this variable, what's the point?See here (https://forum.doom9.org/showthread.php?t=101730).

[stax76]

See here (https://forum.doom9.org/showthread.php?t=101730).

So this variable is really needed and it's some advanced C++ feature I do not understand?

I've forgotten half I knew about C++, so I'm reading this tutorial to refresh it, so far am here:

https://www.learncpp.com/cpp-tutorial/6-7a-null-pointers/

In managed code it might be necessary to use a variable so the GC don't collect it but since there is no GC in native code I don't understand why this variable exists.

[Richard1485]

sudo apt-get install libavcodec-dev libavformat-dev libavutil-dev libavfilter-dev libavdevice-dev libswscale-dev libpostproc-dev libswresample-dev

Oh, so they are just packages! Sorry: for some reason, imagined that there was more to it than that. :D Thanks!

[stax76]

I notice now it produces a linker error without this AVS_linkage variable...

[StainlessS]

stax, look in avs 2.6, or avs+ header.

The OLD v2.58 BAKED code that existed in v2.58 header was not very portable between avs versions, plugins compiled with such were basically
locked to the code in the header. The avs 2.60 header [after v2.60Alpha 4] implemented AVS_Linkage stuff when using the new AvisynthPluginInit3(), so that code is no longer BAKED into the plugin from the header,
but instead it can use code from within avisynth itself, and so is able to better adapt.
A plugin using eg Avs+ header but running under avs 2.60 standard, can still inquire stuff like bit depth, even though such functionality does not exist in avs 2.6 std(nor exists in 2.58).
[EDIT: There are kludges in the avs+ header to implement code not existing in the active version of avisynth]
For this more flexible whatsit to work proper, it is necessary to initialize AVS_Linkage with the pointer to vectors [EDIT: which is supplied by the server, usually avisynth] when
calling the instance of AvisynthPluginInit3() coded within a plugin, this replaces most of the previously BAKED-in code.

avs+ header

/*
* Avisynth C++ plugin API code function pointers.
*
* In order to maintain binary compatibility with
* future version do not change the order of the
* existing function pointers. It will be baked
* into all existing plugins.
*
* Add new function pointers to the end of the
* structure. The linkage macros generate some
* protection code to ensure newer plugin do not
* call non-existing functions in an older host.
*/

struct AVS_Linkage { // const AVS_Linkage *AVS_linkage is a pointer to struct of (mostly) function pointers to call

int Size;

/**********************************************************************/

// struct VideoInfo
bool (VideoInfo::*HasVideo)() const;
bool (VideoInfo::*HasAudio)() const;
bool (VideoInfo::*IsRGB)() const;
bool (VideoInfo::*IsRGB24)() const;
bool (VideoInfo::*IsRGB32)() const;
bool (VideoInfo::*IsYUV)() const;

// ... much more



Usual AvisynthPluginInit3() initializing [avisynth calls AvisynthPluginInit3() embedded into a plugin, to initialize that plugin]

/* New 2.6 requirement!!! */
// Declare and initialise server pointers static storage.
const AVS_Linkage *AVS_linkage = 0; // UNSET as yet for current plugin, each plugin has its own instance

/* New 2.6 requirement!!! */
// DLL entry point called from LoadPlugin() to setup a user plugin.
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
// Above vectors, pointer provided by avisynth server (v2.6, avs+ or std) enabling non baked-in stuff

/* New 2.6 requirment!!! */
// Save the server pointers.
AVS_linkage = vectors; // make everything work like magic, plug vectors into AVS_linkage
env->AddFunction("TitleBar", "c[Tit]s[ShowFrameNo]b[Col]i[ColChr]s[Esc]b", Create_TitleBar, 0); // Some plugin, can now use avisynth server funcs via AVS_linkage
return "'TitleBar' TitleBar plugin"; // A freeform name of the plugin.
}



hope that 'above sort of' explains it [it is likely that it could be explained better if anyone cares to - I'm happy to accept that 'it works'].

EDIT:
Some of the Kludgy stuff in avs+ header

// AVS+ extensions
// 20161005:
// Mapping of AVS+ extensions to classic 2.6 functions.
// In order to use these extended AVS+ functions for plugins that should work
// either with AVS+ or with Classic (8 bit) Avs 2.6 ans earlier AVS+ versions, there is an
// automatic fallback mechanism.
// From AVS+'s point of view these are not "baked" codes, the primary functions should exist.
// Examples:
// Is444() is mapped to IsYV24() for classic AVS2.6
// ComponentSize() returns constant 1 (1 bytes per pixel component)
// BitsPerComponent() returns constant 8 (Classic AVS2.6 is 8 bit only)

// Returns the number of color channels or planes in a frame
int NumComponents() const AVS_BakedCode(return AVS_LinkCallOptDefault(NumComponents, (((AVS_LinkCall(IsYUV)()) && !(AVS_LinkCall(IsY8)())) ? 3 : AVS_LinkCall(BytesFromPixels)(1)) ) )

// Returns the size in bytes of a single component of a pixel
int ComponentSize() const AVS_BakedCode(return AVS_LinkCallOptDefault(ComponentSize, 1))

// Returns the bit depth of a single component of a pixel
int BitsPerComponent() const AVS_BakedCode(return AVS_LinkCallOptDefault(BitsPerComponent, 8)) // simply return 8 if avs std (provided as default if non avs+ avisynth)


To better understand, maybe peruse link pointed to by Groucho [not just that post, entire thread]:- https://forum.doom9.org/showthread.php?t=101730

EDIT: Also take a peek at these two later posts in same thread by IanB some years later,
https://forum.doom9.org/showthread.php?p=1567792#post1567792
https://forum.doom9.org/showthread.php?p=1580772#post1580772
There may be more on same subject when avs+ was introduced.

EDIT: And avisynth v2.60Alpha4 thread, where AVS_linkage and AvisynthPluginInit3() introduced for real:- https://forum.doom9.org/showthread.php?t=166951

[stax76]

@StainlessS

Thanks for the explanation! If I remember right then host apps like MeGUI or avs2pipemod set the variable to null on shutdown, that does not seem to be necessary, I think MeGUI sets it to null even if there are still instances active, isn't that wrong?

https://sourceforge.net/p/megui/code/HEAD/tree/AvisynthWrapper/trunk/AvisynthWrapper.cpp

[StainlessS]

No idea, I aint not played with host apps [maybe Grouchy nose] https://www.cosgan.de/images/midi/verschiedene/s070.gif

[Groucho2004]

I think MeGUI sets it to null even if there are still instances active, isn't that wrong?Instances of what? You can have more than one script environment running in separate processes/threads.

In the code to which you linked, the "AVS_linkage = 0;" statement is preceded by the proper "DeleteScriptEnvironment()" which is correct.

The "delete pstr->env;" statement for Avisynth 2.5x is however not recommended, see here (https://forum.doom9.org/showthread.php?p=1631151#post1631151).

[stax76]

Instances of what? You can have more than one script environment running in separate processes/threads.

Instances of script environments, GUIs usually have the requirement using multiple environments in parallel.

I think this thing is too complicated for me to fully understand it. I understand that it's a static variable and that it holds function pointers, aren't those function pointers related to a particular script environment? In that case to me it appears that it should be set to null after the script is loaded and not when the script environment is shut down.

[Groucho2004]

I think this thing is too complicated for me to fully understand it.I'm not far behind you in that regard. I just did in my programs what IanB recommended in various posts spread across this forum. That was years ago, I have not thought about it since.

[stax76]

I've built a sample application for learning and testing purpose, maybe the code can help somebody. What it does is render a AviSynth script using Direct2D, it uses a trackbar/slider, no playback. I don't think Direct2D can render YV12 so it invokes ConvertToRGB32, it also invokes FlipVertical, no clue why AviSynth/VapourSynth RGB32 isn't directly D2D compatible without FlipVertical.

Code:

https://pastebin.com/59f8xUqA


I'll also build a VapourSynth equivalent of this sample in case somebody is interested in code for that.

[wonkey_monkey]

Have you tried creating the Bitmap with a negative height or pitch? I think something like that works under GDI.

[stax76]

Yes, I tried negative pitch, causes a crash, height is defined as UINT32.

edit:

I can research if Direct2D can flip it faster.

[StainlessS]

it also invokes FlipVertical, no clue why AviSynth/VapourSynth RGB32 isn't directly D2D compatible without FlipVertical.
RGB is upside down compared to YUV, top line is usually got via something like

int x=0,y=0;
int step =( vi.IsRGB24() ) ? 3 : 4; // RGB24 or RGB32
BYTE *dp = dst->GetWritePtr() + ((height-1 - y) * pitch) + (x*step);
// ...
dp -= pitch; // down 1 line

[stax76]

The pixel array is a block of 32-bit DWORDs, that describes the image pixel by pixel. Usually pixels are stored "bottom-up", starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image.[4] Unless BITMAPCOREHEADER is used, uncompressed Windows bitmaps also can be stored from the top to bottom, when the Image Height value is negative.

https://en.wikipedia.org/wiki/BMP_file_format#Pixel_storage

I tried negative height in source and target rect and everywhere else where a height is defined and it's not working. On StackOverflow it's unanswered:

https://stackoverflow.com/questions/31566239/cant-flip-bitmap-when-calling-id2d1devicecontextdrawbitmap

[v0lt]

Hello.

Now if I open the script in video players, I get the wrong colors in many situations.

Is it possible to use the structure VIDEOINFOHEADER2 (https://docs.microsoft.com/ru-ru/previous-versions/windows/desktop/api/dvdmedia/ns-dvdmedia-videoinfoheader2) instead of VIDEOINFOHEADER? This will make it possible to use the dwControlFlags field. If you set AMCONTROL_COLORINFO_PRESENT, you can use DXVA_ExtendedFormat (https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/dxva/ns-dxva-_dxva_extendedformat) to specify additional parameters (nominal range, transfer matrix) for the video stream.

[StainlessS]

V0lt,
Now if I open the script in video players, I get the wrong colors in many situations.
What script ???

Here the script:
AviSource("h:\Tape 1\capture_1.avi")
converttoyv12(interlaced=true)
assumeTFF()
separatefields()
temporalsoften(4,4,8,10,mode=2)
fluxsmoothST(3,3)
weave()
assumefps(25)
It works when I put temporalsoften AFTER fluxsmooth.

Edit:
It also works when I put crop(2,0,-0,-0) before temporalsoften. (The frame then becomes 718x576).

Edit2:
It looks like temporalsoften must not be the first filter after separatefields() :confused:

Verified Access Violation with below script.

Colorbars(pixel_type="YV12")
#BilinearResize(720,576)
#converttoyv12(interlaced=true)
#assumeTFF()
separatefields()
temporalsoften(4,4,8,10,mode=2)
#fluxsmoothST(3,3)
#weave()
#assumefps(25)


removing comments (Access Violation)

Colorbars(pixel_type="YV12") # 640x480
separatefields() # 640x240
temporalsoften(4,4,8,10,mode=2)


EDIT: Avs+ v3.4.0

EDIT: No Access Violation

BlankClip(width=640,height=240,pixel_type="YV12")
AssumeFieldBased
temporalsoften(4,4,8,10,mode=2)


EDIT: Also Access Violation

BlankClip(pixel_type="YV12") # 640x480
separatefields() # 640x240
temporalsoften(4,4,8,10,mode=2)


EDIT: Also Access Violation

BlankClip(pixel_type="YV12") # 640x480
separatefields() # 640x240
AssumeFrameBased
temporalsoften(4,4,8,10,mode=2)

[v0lt]

What script ???

ImageSource("1000px-SMPTE_Color_Bars_16x9.png")
AddBorders(0, 3, 0, 2)
ConvertToYUV420(matrix="Rec601")
# or
#ConvertToYUV420(matrix="Rec709")
# or
#ConvertToYUV420(matrix="Rec2020")
I get different colors on the player depending on the matrix parameter in the script. The video player is not able to find out what parameters were used when converting the frame from RGB to YV12.

[poisondeathray]

ImageSource("1000px-SMPTE_Color_Bars_16x9.png")
AddBorders(0, 3, 0, 2)
ConvertToYUV420(matrix="Rec601")
# or
#ConvertToYUV420(matrix="Rec709")
# or
#ConvertToYUV420(matrix="Rec2020")
I get different colors on the player depending on the matrix parameter in the script. The video player is not able to find out what parameters were used when converting the frame from RGB to YV12.



Avisynth frameserves uncompressed audio and video. No metadata is passed . Also, the video player does not "see" what is in the script; it only "sees" the final output as uncompressed video

How the video converts from YUV to RGB for display varies by the player, and renderer setup, sometimes drivers. Many assume Rec709 for height >576

[StainlessS]

There is no colorspace matrix info embedded in AVI.
I guess defaults are player dependant (I dont ever bother with such stuff).

Here looks like relevant for PotPlayer
https://i.postimg.cc/WFNwQKM6/Untitled-00.jpg (https://postimg.cc/WFNwQKM6)

EDIT: PDR beat me.

[stax76]

Avisynth frameserves uncompressed audio and video. No metadata is passed . Also, the video player does not "see" what is in the script; it only "sees" the final output as uncompressed video

A video player can't know what exactly a script does (at least not easily), it could however parse the script to find out some basic parameters like the original source file or even a matrix parameter, with regex that's not 100% reliable but fairly simple to do. VapourSynth maybe has better metadata capabilities.

[v0lt]

When AviSynth converts the color space from RGB to YUV, then another filter can find out which matrix was used for this?

[poisondeathray]

When AviSynth converts the color space from RGB to YUV, then another filter can find out which matrix was used for this?

Not automatically .

You have to do it "manually" with something like colorbars or known colors. If you get back the original colors when you convert back to RGB (or very close, due to rounding errors , and RGB<=>YUV gamut errors, clipping) then it's the correct matrix

This is true for any RGB<=>YUV conversion with any program, not just avisynth

[poisondeathray]

VapourSynth maybe has better metadata capabilities.

It does... but it's pros/cons IMO . Easy to get burned if not careful

If file is tagged correctly, the source filters read and pass on various metadata as clip "props" or properites

All manipulations "automatically" assume or take on those values, unless otherwise specified . e.g. if you resize or RGB preview ,everything is done correctly as per the metadata. e.g. if file was interlaced, tagged interlaced, then the resizing and conversion to RGB will be done interlaced aware

If file was tagged correctly, great. Everything just works(TM)

If it's not, trouble. e.g. if you get file from somewhere else. e.g handbrake often tags incorrectly . eg. progressive PAL DVD's are tagged interlaced. You end up having to double check everything.

[TheFluff]

https://en.wikipedia.org/wiki/BMP_file_format#Pixel_storage

I tried negative height in source and target rect and everywhere else where a height is defined and it's not working. On StackOverflow it's unanswered:

https://stackoverflow.com/questions/31566239/cant-flip-bitmap-when-calling-id2d1devicecontextdrawbitmap

BITMAPINFOHEADER and friends are old GDI stuff. D2D exclusively uses unsigned coordinates growing left to right, top to bottom. You're not supposed to use clever tricks like negative pitch or height anymore, presumably because these coordinates are getting increasingly abstract and they don't want you to think in terms of pointers and offsets anymore, even though it happens to make sense in the context of plain old RGB bitmaps. You don't really just push raw memory areas to the screen anymore anyway at this high of an API level - D2D supports UI scaling, for example.

Instead the intended way of doing it (https://docs.microsoft.com/en-gb/windows/win32/direct2d/direct2d-transforms-overview) is manipulating how the input coordinates are mapped to the output coordinates by setting a transformation matrix on the render target using ID2D1RenderTarget::SetTransform().

D2D doesn't come with a vertical mirroring matrix convenience method (rotation around a point isn't the same thing), but you can just create your own 3x2 transform, like so:

1 0
0 -1
0 0

which should give you a vertical flip.

no clue why AviSynth/VapourSynth RGB32 isn't directly D2D compatible without FlipVertical.

Avisynth predates D2D by over a decade, so that's sort of a silly question. Avisynth directly supports VfW and GDI, which is what was available at the time. VS on the other hand only supports packed RGB32 as a backwards compatibility thing, where the thing it's backwards compatible with is mostly Avisynth.

[stax76]

@TheFluff

Thanks for the hint, I will have to do some math research to understand it.

[TheFluff]

Here's a quick cheat sheet, first hit on duckduckgo: https://code-industry.net/masterpdfeditor-help/transformation-matrix/

e: It's not really necessary to confuse yourself with cross products in this case if you don't want to. Basically what you're doing here is just multiplying horizontal coordinates (X axis) by 1 (top left of the matrix) and vertical coordinates (Y axis) by -1 (middle right of the matrix). This is effectively the same thing as setting a negative height, so the topmost row of pixels in the input becomes the bottom row in the output - a vertical flip, in other words.

[pinterf]

Here the script:
AviSource("h:\Tape 1\capture_1.avi")
converttoyv12(interlaced=true)
assumeTFF()
separatefields()
temporalsoften(4,4,8,10,mode=2)
fluxsmoothST(3,3)
weave()
assumefps(25)
It works when I put temporalsoften AFTER fluxsmooth.

Edit:
It also works when I put crop(2,0,-0,-0) before temporalsoften. (The frame then becomes 718x576).

Edit2:
It looks like temporalsoften must not be the first filter after separatefields() :confused:
Happy New Year!
Temporalsoften bug is fixed. Changes are merged into main repository.

[Sharc]

Happy New Year!
Temporalsoften bug is fixed. Changes are merged into main repository.
Happy New Year! Thank you for the fix :)

[StainlessS]

Cheers P, you are a sweetie. :)

[qyot27]

Test build (http://www.mediafire.com/file/qusmn2h3pitllkx/avisynth%252B_r2983-g30f48068-20200126.7z/file)

The hope with the above build is that you don't see/feel anything different from the most recent builds from the master branch (plus the fixes pinterf mentioned above, re: temporalsoften).

[pinterf]

Test build (http://www.mediafire.com/file/qusmn2h3pitllkx/avisynth%252B_r2983-g30f48068-20200126.7z/file)

The hope with the above build is that you don't see/feel anything different from the most recent builds from the master branch (plus the fixes pinterf mentioned above, re: temporalsoften).
Thanks, there are other changes are in progress, mainly a long-time requested helper parameter for Expr - along with masktools. (real.finder)

Btw. as I have changed the test version to 3.4.1 instead of 3.5, scripts that were parsing VersionString to get the build number at the exact 17th position no longer worked. Aside from this fact, is there any other reason why the 3rd part of the version (BUGFIX_VERSION) was not included in AVS_FULLVERSION?
E.g. now it reports 3.4 even for 3.4.1?
I've done the modification to include this 3rd part in it but real.finder noted me the problem, so I temporarily reversed the change.

Anyway, I have included (not commited yet) a new IsVersionOrGreater function which is checking the current version against the given parameters (similar to a Windows API function)
e.g.
if IsVersionOrGreater(3, 4) or IsVersionOrGreater(3, 5, 8)
and results in true if the current version is equal or greater than the required one in the parameters.

[StainlessS]

Thanx P & Q. (No not Uma & Quentin).

This bug persists.

https://forum.doom9.org/showthread.php?p=1893529#post1893529



BITS=16
BlankClip.ConvertToYV12.ConvertBits(BITS)
X = 16
Y = 16
W = 128
H = 128
#COL=$00FFFFFF # No Alpha
COL=$FFFFFFFF # Full Alpha
WHT=BlankClip(Width=W,Height=H,Color=COL) # Prob if RGB32 or YV12, but not YUV420P16
WHT=WHT.ConvertToYV12
#WHT=WHT.ConvertBits(BITS)
Overlay(WHT,x=X,y=Y)
crop(0,0,W+2*X,H+2*Y) # Crop Overlayed with 16 pixels border
PointResize(512,512) # for view


Rubbish at bottom of white
https://i.postimg.cc/PJkDdQYd/Overlay.png (https://postimages.org/)

[pinterf]

Thanx P & Q. (No not Uma & Quentin).

This bug persists.

https://forum.doom9.org/showthread.php?p=1893529#post1893529



BITS=16
BlankClip.ConvertToYV12.ConvertBits(BITS)
X = 16
Y = 16
W = 128
H = 128
#COL=$00FFFFFF # No Alpha
COL=$FFFFFFFF # Full Alpha
WHT=BlankClip(Width=W,Height=H,Color=COL) # Prob if RGB32 or YV12, but not YUV420P16
WHT=WHT.ConvertToYV12
#WHT=WHT.ConvertBits(BITS)
Overlay(WHT,x=X,y=Y)
crop(0,0,W+2*X,H+2*Y) # Crop Overlayed with 16 pixels border
PointResize(512,512) # for view



Yikes! Ugly like hell.

[StainlessS]

Version Strings [3.4]

3.4 x86
https://i.postimg.cc/90Y4FPy1/3-4-x86.jpg (https://postimages.org/)

3.4 x64
https://i.postimg.cc/WpXWHmP2/3-4-x64.jpg (https://postimages.org/)

Version Strings [3.4.1] (well, as current)

3.4.1_x86
https://i.postimg.cc/SNGy5vxn/3-4-1-x86.jpg (https://postimages.org/)

3.4.1_x64
https://i.postimg.cc/RVmK5hwX/3-4-1-x64.jpg (https://postimages.org/)

Its a bit linuxy [but is 2020, nice] :)

[pinterf]

Thanx P & Q. (No not Uma & Quentin).

This bug persists.

https://forum.doom9.org/showthread.php?p=1893529#post1893529



BITS=16
BlankClip.ConvertToYV12.ConvertBits(BITS)
X = 16
Y = 16
W = 128
H = 128
#COL=$00FFFFFF # No Alpha
COL=$FFFFFFFF # Full Alpha
WHT=BlankClip(Width=W,Height=H,Color=COL) # Prob if RGB32 or YV12, but not YUV420P16
WHT=WHT.ConvertToYV12
#WHT=WHT.ConvertBits(BITS)
Overlay(WHT,x=X,y=Y)
crop(0,0,W+2*X,H+2*Y) # Crop Overlayed with 16 pixels border
PointResize(512,512) # for view


Rubbish at bottom of white
https://i.postimg.cc/PJkDdQYd/Overlay.png (https://postimages.org/)
I can see no bug save a missing sanity-check.
The script is using a 8 bit mask over a 16 bit base clip. Since no automatic bit-depth conversion happens, the result is undefined.
Unfortunately there is no error message for this case. I'll put one there later.

[StainlessS]

Yeh well, I need lots of sanity checks. [and maybe a few sobriety checks too] :)

scripts that were parsing VersionString to get the build number at the exact 17th position no longer worked.

I'm doin' a Version/Build Number fix now, will detect "(r" as build number intro, and scan till non digit.

[pinterf]

I'm doin' a Version/Build Number fix now, will detect "(r" as build number intro, and scan till non digit.
Yep, present method probably fails even at 3.10

[StainlessS]

Maybe I also add, "AvsPlusBugfixVersionNumber()", for the 3rd '.' separated part.
Then you can do mods when and where you like.

EDIT: I hate them there daft multiple dot version numbers, they are insane.

[real.finder]

Anyway, I have included (not commited yet) a new IsVersionOrGreater function which is checking the current version against the given parameters (similar to a Windows API function)
e.g.
if IsVersionOrGreater(3, 4) or IsVersionOrGreater(3, 5, 8)
and results in true if the current version is equal or greater than the required one in the parameters.

adding AvsPlusVersionNumber() to avs+ core (or any better name like VersionReleaseNumber()) will also welcome, will be better than add more code to old AvsPlusVersionNumber script function :)

[StainlessS]

The script is using a 8 bit mask over a 16 bit base clip. Since no automatic bit-depth conversion happens, the result is undefined.
The fact that it worked at all, made me think that it was supposed to work [8 bit Overlay normally works with any colorspace].
Kudos that it worked at all and did not go BANG! :)

# ...

Something like this (I've used PlusBuildNumber, maybe version number should return the 3.4 bit, dont know)


Function IsAvs26() { VersionNumber>=2.6}
Function IsAvsNeo() { FindStr(VersionString," Neo")!=0}
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!=0||IsAvsNeo}
Function PlusBuildNumber() { V=VersionString Off=(!IsAvsPlus)?0:FindStr(V,"(r") return (Off==0)?0:V.MidStr(Off+2).Value.Int } # OK Avs+ & Neo, up to build about 16Million
Function AvsPlusVersionNumber() { Return PlusBuildNumber } # Stub for PlusBuildNumber(), suggest AvsPlusVersionNumber is deprecated.

ADDED

EDIT: Eval("2983,") would fail due to trailing comma, "2983,".Value.Int, Value ignores comma but produces float, Int converts to integer. [supports more than 4 digits, max 24 bit, ~16M]

EDIT: Version Strings

# AviSynth v2.58
AviSynth 2.58, build:Dec 22 2008 [08:46:51]

# AviSynth v2.60
AviSynth 2.60, build:Mar 31 2015 [16:38:54]

# AviSynth v2.61 Alpha
AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp

# Avisynth v2.60 ICL
AviSynth 2.60 (ICL10)

# Avisynth V2.60 MT
AviSynth 2.60, build:Feb 20 2015 [03:16:45]

# Avisynth NEO
AviSynth Neo 0.1 (r2822, Neo, i386)
AviSynth Neo 0.1 (r2822, Neo, x86_64)

# Avisynth NEO Forerunner Avisynth+ CUDA
AviSynth+ 0.1 (r2533, CUDA, i386)
AviSynth+ 0.1 (r2533, CUDA, x86_64)


# Avisynth+ v2.60 (older)
AviSynth+ 0.1 (r2772, MT, i386)
AviSynth+ 0.1 (r2772, MT, x86_64)

# Avisynth+ v3.4 (Prev)
AviSynth+ 3.4 (r2923, 3.4, i386)
AviSynth+ 3.4 (r2923, 3.4, x86_64)

# Avisynth+ v3.4.1 (NOW)
AviSynth+ 3.4 (r2983, linux3, i386)
AviSynth+ 3.4 (r2983, linux3, x86_64)


So, VersionNumber is 2.60, PlusBuildNumber is 2983 [ Previously known as AvsPlusVersionNumber(), see above in BLUE] , what do we call the 3.4.1 stuff ?
[ Something_MAJOR, Something_MINOR, something_BUGFIX ??? ]

[qyot27]

Btw. as I have changed the test version to 3.4.1 instead of 3.5, scripts that were parsing VersionString to get the build number at the exact 17th position no longer worked. Aside from this fact, is there any other reason why the 3rd part of the version (BUGFIX_VERSION) was not included in AVS_FULLVERSION?
E.g. now it reports 3.4 even for 3.4.1?
I've done the modification to include this 3rd part in it but real.finder noted me the problem, so I temporarily reversed the change.
I think it was just an oversight, as one of my main concerns was getting a bugfix version into the pkg-config file. The lack of it when using Version had been bugging me too.

The test build's huge revision jump is due to the Linux support commits, shielding the Windows-only parts behind ifdefs and [amongst other changes to get it to build] switching the vast majority of the MSVC-specific types to stdint in places that aren't specific to one OS or the other. I just wasn't sure if any of those sorts of changes might end up impacting operations in any way, is all.

Oh, and I added the VersionEx() function, which - eventually - would be intended to provide a verbose list of different internal versioning or values thatan end user may want to check. It's still nearly identical to Version(), save for also including the compiler info (currently only tested with MSVC and GCC, not Clang, and definitely not ICL).

[qyot27]

So, VersionNumber is 2.60, BuildNumber is 2983 [ Previously known as AvsPlusVersionNumber() ] , what do we call the 3.4.1 stuff ?
[ Something_MAJOR, Something_MINOR, something_BUGFIX ??? ]
VersionNumber returning 2.60 is pretty much just for legacy applications that expect to find 2.6 (and I'm not really sure how prevalent that ever was, vs. checking the AVISYNTH_INTERFACE_VERSION or some such). Honestly, if there's not a real threat of breaking anything if we actually bump it up to what the version number currently is, I wouldn't be opposed to it.

[StainlessS]

I use versionNumber only like so, [below originally posted here:- https://forum.doom9.org/showthread.php?p=1894699#post1894699 ]


Function IsAvs26() { VersionNumber>=2.6 }
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!= 0||FindStr(VersionString," Neo")!=0 }
# Function AvsPlusVersionNumber() { IsAvsNeo?Eval(MidStr(VersionString,20,4)):IsAvsPlus?Eval(MidStr(VersionString,17,4)):0}
Function PlusBuildNumber() { V=VersionString Off=(!IsAvsPlus)?0:FindStr(V,"(r") return (Off==0)?0:V.MidStr(Off+2).Value.Int } # Avs+ & Neo
Function AvsPlusVersionNumber() { Return PlusBuildNumber } # Stub for PlusBuildNumber(), suggest AvsPlusVersionNumber is deprecated.

#
Function X_PixelType(clip c) { c IsAvs26 ? PixelType : IsYV12?"YV12":IsYUY2?"YUY2":IsRGB32?"RGB32":"RGB24" } # Eg "RGB32" or "YUV420P10"
Function X_IsYV411(clip c) { c IsAvs26 ? IsYV411 : False }
Function X_IsY(clip c) { c IsAvsPlus ? IsY : IsAvs26 ? IsY8 : False } # True=Single Plane : (!IsRGB)=True = Any type with Y, YUY2/YUVA/Y8 etc.
Function X_Is420(clip c) { c IsAvsPlus ? Is420 : IsYV12 }
Function X_Is422(clip c) { c IsAvsPlus ? Is422 : False } # YUY2_Clip.Is422=False [ie not Planar]
Function X_Is444(clip c) { c IsAvsPlus ? Is444 : IsAvs26 ? IsYV24 : False }
Function X_IsRGB48(clip c) { c IsAvsPlus ? IsRGB48 : False }
Function X_IsRGB64(clip c) { c IsAvsPlus ? IsRGB64 : False }
Function X_HasAlpha(clip c) { c IsAvsPlus ? HasAlpha : IsRGB32 }
Function X_NumComponents(clip c) { c IsAvsPlus ? NumComponents : IsAvs26&&IsY8 ? 1 : IsRGB32 ?4 : 3 } # Num of channels
Function X_Bpc(clip c) { c IsAvsPlus ? BitsPerComponent : 8 } # Bits per channel, 32 = Float
Function X_YMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Height/ExtractU.Height):(IsYV12 ?2:1) } # Y Min crop multiple for Progressive
Function X_XMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Width/ExtractU.Width):IsAvs26?(IsYV411?4:IsY8||IsRGB?1:2):(IsRGB?1:2)} # X Min crop multiple


I dont see any obvious problem using VersionNumber as eg 3.4 [with maybe something like AvsPlusBugfixVersion=1, where full version is 3.4.1]

[real.finder]

what about adding PlusVersionNumber?

and PlusBuildNumber or PlusReleaseNumber

[real.finder]

VersionNumber returning 2.60 is pretty much just for legacy applications that expect to find 2.6 (and I'm not really sure how prevalent that ever was, vs. checking the AVISYNTH_INTERFACE_VERSION or some such). Honestly, if there's not a real threat of breaking anything if we actually bump it up to what the version number currently is, I wouldn't be opposed to it.

it will not breaking scripts as StainlessS said but if for some reason the classic avs lived in the future it will be "real threat"

[StainlessS]

but if for some reason the classic avs lived in the future it will be "real threat"
Something to worry about if it ever happens, we could always get around that [somehow].

EDIT: I'll change to PlusBuildNumber() [its shorter]

[real.finder]

Something to worry about if it ever happens, we could always get around that [somehow].

but isn't better to add new one as I suggested? maybe avs neo will have it own Version (so maybe it will using something like this NeoVersionNumber etc...), or yet another Forks will show, who knows?

edit: Regarding PlusVersionNumber and (PlusBuildNumber or PlusReleaseNumber)

both can be merge in one function like PlusVersion(string "type")

PlusVersion("ReleaseNumber") and PlusVersion("VersionNumber")

[StainlessS]

Function IsAvs26() { VersionNumber>=2.6}
Function IsAvsNeo() { FindStr(VersionString," Neo")!=0}
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!=0||IsAvsNeo}
Function PlusBuildNumber() { V=VersionString Off=(!IsAvsPlus)?0:FindStr(V,"(r") return (Off==0)?0:V.MidStr(Off+2).Value.Int } # Avs+ & Neo, (Max 24 bit, ~16M)
Function AvsPlusVersionNumber() { Return PlusBuildNumber } # Stub for AvsPlusBuildNumber(), suggest AvsPlusVersionNumber is deprecated.
# Return extent of string s that matches any chr in pat. Enter with n=0
Function StrMatchExtent(String s,String Pat,int n) { c=s.MidStr(n+1,1) Return (((c=="")?0:Pat.FindStr(c))==0) ? n : s.StrMatchExtent(Pat,n+1) }
Function AvsVersionNumberString() {
v=VersionString off=(FindStr(V,"AviSynth+ ")!=0)?FindStr(V,"AviSynth+ ")+10:(FindStr(V," Neo ")!=0)?FindStr(V," Neo ")+5:10
v=v.MidStr(Off) return v.LeftStr(StrMatchExtent(v,"0123456789.",0))
}


client

s=AvsVersionNumberString() # Returns string eg "3.4.1" from "AviSynth+ 3.4.1 (r2983, linux3, x86_64)", works with ALL previous/current versions, can extract numbers from the string
BlankClip
subtitle(String(s)) # "3.4" for current, "3.4.1" if was implemented as such, "2.58" if old v2.58 AVS, "2.60" for AvsStd 2.6, "2.61" Latest avs std, "0.1" if NEO or avs+ build r2772.

[Groucho2004]

These string parsing acrobatics are making me dizzy.

[StainlessS]

Some more acrobatics [might need a bit of testing, I'm gonna get some shut eye]

EDIT: Moved to new thread in Usage, here- https://forum.doom9.org/showthread.php?t=178243

See Post #5103 for Versioning ONLY routines:- https://forum.doom9.org/showthread.php?p=1897680#post1897680

[pinterf]

Something to worry about if it ever happens, we could always get around that [somehow].

EDIT: I'll change to PlusBuildNumber() [its shorter]
I wouldn't use the build number from now.
Our aim should be just using a plain 2 or three digits version number such as 3.4, 3.4.1, 3.5.0.

[pinterf]

Yeh well, I need lots of sanity checks. [and maybe a few sobriety checks too] :)

Bit depth similarity check done (Overlay). On my git atm.

[StainlessS]

I wouldn't use the build number from now.
Our aim should be just using a plain 2 or three digits version number such as 3.4, 3.4.1, 3.5.0.

Ideally yes, but might/will maybe need some fix to figure out what to do for,

AviSynth Neo 0.1 (r2822, Neo, i386)
AviSynth+ 0.1 (r2772, MT, i386)

Maybe should in future just Demand 3.4 minimum (where Avs+, partially forget Neo for now).

Bit depth similarity check done (Overlay). On my git atm.

Ooooh lovely https://www.cosgan.de/images/smilie/froehlich/s072.gif

I added this edit some posts ago, maybe you missed it.
The fact that it worked at all, made me think that it was supposed to work [8 bit Overlay normally works with any colorspace].
Kudos that it worked at all and did not go BANG! :)

EDIT: IIRC, I noticed that result was not full white (probably due to 8 bit overlay'ed clip), and investigating further found the rubbish at bottom of white.

[StainlessS]

Updated post #5099 with full set of string matching routines:-
EDIT: Moved full set of string matching routines to new thread in Usage here:- https://forum.doom9.org/showthread.php?t=178243

No requirements except Groucho2004 SysInfo where indicated, should work in v2.58

AvsVersion.avsi

# AvsVersion.avsi # https://forum.doom9.org/showthread.php?p=1897680#post1897680

/*
These 3 require Groucho2004 SysInfo v0.119+, otherwise no requirements.
AvsVersionNumberString(Type=1)
AvsVersionNumberPartNo(Type=1)
IsAvsVerOrGreater(Type=1)
*/

# Handy stuff [No requirements]
Function SystemInfoVersion() { try{v=SysInfoVersion}catch(msg){v=-1.0} v } # v = -1.0, Groucho SysInfo not installed
Function RT_StatsVersion() { try{v=RT_Version}catch(msg){v=-1.0} v } # v = -1.0, RT_Stats not installed
Function GScriptExists() { ret=false try{ GScript(123,42.0,false,"") } catch(msg){ret = FindStr(msg,"Invalid arguments")>=1 } Return ret }
Function FuncNameExists(String Fn) { Try{Eval(Fn+"()")B=True}catch(e){Assert(e.FindStr("syntax")==0,"FuncNameExists: Error in Function Name '"+Fn+"'")B=(e.FindStr("no function named")==0)}Return B}
###
Function IsAvs26() { Return VersionNumber>=2.6}
Function IsAvsPlus() { Return FindStr(VersionString,"AviSynth+")!=0||FindStr(VersionString," Neo")!=0 }
# Deprecated:
Function PlusBuildNumber() { V=VersionString Off=(!IsAvsPlus)?0:FindStr(V,"(r") Return (Off==0)?0:V.MidStr(Off+2).Value.Int } # Avs+ & Neo, (More than 4 digits, Max 24 bit, ~16M)
Function AvsPlusVersionNumber() { Return PlusBuildNumber } # Deprecated, Stub for AvsPlusBuildNumber()
Function IsAvsNeo() { Return FindStr(VersionString," Neo")!=0 } # Deprecated

######

# Return length of string S that matches any character in Chars set of characters [Default case insignificant]. # StrMatchChrLen("1234.567abcd","0123456789.") = 8
Function StrMatchChrLen(String s,String Chars,Bool "Sig") {
Function __StrMatchChrLen_LOW(String s,String Chars,int n) { c=s.MidStr(n+1,1) Return(c==""||Chars.FindStr(c)==0) ? n : s.__StrMatchChrLen_LOW(Chars,n+1) }
Sig=Default(sig,False) # Default Case Insignificant
s=(Sig)?s:s.UCASE Chars=(Sig)?Chars:Chars.UCASE
Return __StrMatchChrLen_LOW(s,Chars,0)
}

# Return length of string s that DOES NOT match any character in Chars set of characters [Default case insignificant]. # StrBrkChrLen("1234.567,abcd",",.") = 4
# If 1st character of s matches any in Chars set, then returns 0. # StrBrkChrLen("1234.567,abcd","321") = 0
# If no characters in s match any character in Chars set, then returns length of string s. # StrBrkChrLen("1234.567,abcd","NOP") = 13
Function StrBrkChrLen(String s,String Chars,Bool "Sig") {
Function __StrBrkChrLen_LOW(String s,String Chars,int n) {c=s.MidStr(n+1,1) Return(c==""||Chars.FindStr(c)!=0)?n:s.__StrBrkChrLen_LOW(Chars,n+1)}
Sig=Default(sig,False) # Default Case Insignificant
s=(Sig)?s:s.UCASE Chars=(Sig)?Chars:Chars.UCASE
Return __StrBrkChrLen_LOW(s,Chars,0)
}

Function AvsVersionNumberString(Int "Type") {
/*
Type = Default 0.
Get version string from VersionString [Type=0] OR SysInfo::AI_AvsProductVersion [Type=1] # Type=1, Requires Groucho SysInfo v0.119+
Return string guaranteed 4 dot separated digits, eg "1.23" becomes "1.23.0.0"
*/
myName="AvsVersionNumberString: "
Type=Default(Type,0) # Default is version number from VersionString
Assert(0 <= Type <= 1,myName+"0 <= Type <= 1 ("+String(Type,"%.f")+")")
Assert(Type!=1 || SystemInfoVersion>=0.119,myName+"Groucho2004 SysInfo v0.119+ required")
s = (Type==0) ? VersionString : AI_AvsProductVersion
s = (Type==0) ? s.MidStr(s.StrBrkChrLen("0123456789.",True)+1) : s
s = (Type==0) ? s.LeftStr(s.StrMatchChrLen("0123456789.",True)) : s
d=s.FindStr(".") n1=(d==0)?s:s.LeftStr(d-1) s=(d==0)?"":s.MidStr(d+1)
d=s.FindStr(".") n2=(d==0)?s:s.LeftStr(d-1) s=(d==0)?"":s.MidStr(d+1)
d=s.FindStr(".") n3=(d==0)?s:s.LeftStr(d-1) s=(d==0)?"":s.MidStr(d+1)
d=s.FindStr(".") n4=(d==0)?s:s.LeftStr(d-1)
(n1==""?"0":n1)+"."+(n2==""?"0":n2)+"."+(n3==""?"0":n3)+"."+(n4==""?"0":n4)
}

Function AvsVersionNumberPartNo(int PartNo, Int "Type") {
/*
Type, Default 0 [0 -> 1].
Get dot separated Version Part number as Int from AvsVersionNumberString(type=Type). [eg "1.2.3.4"]
Where PartNo=1->4. 1=MAJOR version: 2=MINOR version : 3=Part3 version : 4=Part4 version
*/
PartNo=Min(Max(PartNo,1),4) # Limit Range 1->4
s=AvsVersionNumberString(Type) # eg "1.2.3.4", guaranteed 4 dot separated digit strings.
d=s.FindStr(".") n1=s.LeftStr(d-1) s=s.MidStr(d+1) d=s.FindStr(".") n2=s.LeftStr(d-1) s=s.MidStr(d+1)
d=s.FindStr(".") n3=s.LeftStr(d-1) n4=s.MidStr(d+1)
Return ((PartNo==1)?n1:(PartNo==2)?n2:(PartNo==3)?n3:n4).Eval
}

Function IsAvsVerOrGreater(int a,int "b",int "c",int "d", Int "Type") {
/*
Type, Default 0 [0 -> 1].
Compares with dot separated version number obtained from VersionString[Type=0] OR SysInfo::AI_AvsProductVersion[Type=1]
*/
b=Default(b,0) c=Default(c,0) d=Default(d,0)
aa=AvsVersionNumberPartNo(1, Type) bb=AvsVersionNumberPartNo(2, Type)
cc=AvsVersionNumberPartNo(3, Type) dd=AvsVersionNumberPartNo(4, Type)
return (aa>a) || (aa==a && (bb>b || (bb==b && (cc>c || (cc==c && dd>=d)))))
}


Client

# AvsVersion_Client.avs

#Import(".\AvsVersion.avsi")
######################################
### UnComment ONE of Below ####
######################################
###
#s=StrMatchChrLen("1234.567abcd","0123456789.") # = 8
#s=StrMatchChrLen("1234.567abcd","") # = 0 ## BUG CHK: Nul length Chars
#s=StrMatchChrLen("","0123456789.") # = 0 ## BUG CHK: Nul length S
#s=StrMatchChrLen("","") # = 0 ## BUG CHK: Nul length S & Chars
#
#s=StrBrkChrLen("1234.567,abcd",",.") # = 4
#s=StrBrkChrLen("1234.567,abcd","321") # = 0
#s=StrBrkChrLen("1234.567,abcd","NOP") # = 13
#s=StrBrkChrLen("1234.567,abcd","") # = 13 ## BUG CHK: Nul length Chars
#s=StrBrkChrLen("","123") # = 0 ## BUG CHK: Nul length S
#s=StrBrkChrLen("","") # = 0 ## BUG CHK: Nul length S & Chars
### EDIT: Above probably not of General Interest
#s=PlusBuildNumber # = 2983 for Avs+ 3.4
s=AvsVersionNumberString # = 3.5.2.0 for current Avs+ 3.5.2 [From VersionString]
#s=AvsVersionNumberString(Type=1) # = 3.5.2.0 for current Avs+ 3.5.2 [From SysInfo::AI_AvsProductVersion]
#s=AvsVersionNumberPartNo(1) # = 3 for current Avs+ 3.5.2 [From VersionString]
#s=AvsVersionNumberPartNo(2) # = 5 for current Avs+ 3.5.2 [From VersionString]
#s=AvsVersionNumberPartNo(3) # = 2 for current Avs+ 3.5.2 [From VersionString]
#s=AvsVersionNumberPartNo(4) # = 0 for current Avs+ 3.5.2 [From VersionString]
#s=AvsVersionNumberPartNo(1,Type=1) # = 3 for current Avs+ 3.5.2 [From SysInfo::AI_AvsProductVersion]
#s=AvsVersionNumberPartNo(2,Type=1) # = 5 for current Avs+ 3.5.2 [From SysInfo::AI_AvsProductVersion]
#s=AvsVersionNumberPartNo(3,Type=1) # = 2 for current Avs+ 3.5.2 [From SysInfo::AI_AvsProductVersion]
#s=AvsVersionNumberPartNo(4,Type=1) # = 0 for current Avs+ 3.5.2 [From SysInfo::AI_AvsProductVersion]
#s=IsAvsVerOrGreater(3,5) # = True, for current Avs+ 3.5 [From VersionString]
#s=IsAvsVerOrGreater(3,5,Type=1) # = True, for current Avs+ 3.5 [From SysInfo::AI_AvsProductVersion]
#s=IsAvsVerOrGreater(10,0,0) # = False, for Avs+ 10.0.0, not yet implemented. [From VersionString]
#s=IsAvsVerOrGreater(10,0,0,Type=1) # = False, for Avs+ 10.0.0, not yet implemented. [From SysInfo::AI_AvsProductVersion]

Return BlankClip.subtitle("'"+String(s)+"'")

[poisondeathray]

This is a RGB24 => YUV444P10 => RGB24 conversion

Why is 10bit sufficient for avsresize(zimg/zlib) or vapoursynth for losslessness (at least for this image), but not avisynth internal conversion? But ConvertBits(12) instead of 10 makes it work for the internal

https://www.mediafire.com/view/izsc2060vxvnp93/yuv_exprm_02_bird.png/file

avs internal
PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

avsresize or vpy
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

or you can visualize with subtract or overlay (difference mdoe)

a=ImageSource("yuv_exprm_02_bird.png", pixel_type="RGB24")

a
ConvertToPlanarRGB()
ConvertBits(10) #12bits work
ConvertToYUV444(matrix="rec601")
ConvertToPlanarRGB()
ConvertToRGB24()
b=last

a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last #RGBP10 step before RGB24 works

a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP")
ConvertToRGB24()
z2=last #RGBP8 step before RGB24 also works

#comparing in RGB24 against original RGB24, amplify differences with levels
Overlay(a,b , mode="Difference", pc_range=true) #or subtract(a,b)
#Overlay(a,z1 , mode="Difference", pc_range=true) #or subtract(a,z1)
#Overlay(a,z2 , mode="Difference", pc_range=true) #or subtract(a,z2)
Levels(127, 1, 129, 0, 255, false)
da=last

return da



This is RGB24<=>YUV444 ; so no chroma resampling and chroma location interpretation is not applicable either

[pinterf]

This is a RGB24 => YUV444P10 => RGB24 conversion

Why is 10bit sufficient for avsresize(zimg/zlib) or vapoursynth for losslessness (at least for this image), but not avisynth internal conversion? But ConvertBits(12) instead of 10 makes it work for the internal


Good catch. Thanks for noticing that.
There was a missing rounder in the V channel calculation at planar RGB -> YUV transform, 8 to 14 bits and SSE2 code.

[StainlessS]

Bit more fiddle with VersionString stuff, Post #5103 updated:- https://forum.doom9.org/showthread.php?p=1897680#post1897680

Removed full string matching stuff script from Post #5099 to thread in Usage forum [ StrMatchDemo.avsi v1.00 ] :- https://forum.doom9.org/showthread.php?t=178243

EDIT: Added nul string BUG CHK's to Clients

[StainlessS]

Is me doin' summick rong agen :(


W=86 # Even non multiple of 8, BAD
H=64 # Any Even OK (above some size)
BlankClip(Length=1,Width=W,Height=H,Pixel_Type="RGBAP") # Planar RGBA 8 bit [ Same prob if "RGBP" ]
#Return PointResize(512,512) # OK always
ConvertToYV12 # Same prob if ConvertToYUY2 [ ConvertToRGB32/ConvertToRGB24 OK ]
#ConvertToY8
Return PointResize(512,512)

Click on Image for PointResize(512,512)
https://i.postimg.cc/vgsHHVJG/t-00.jpg (https://postimg.cc/vgsHHVJG)

EDIT: Even Heights OK
W Mulitples of 8, +0=GUD, +2=Bad, +4=Wurse, +6=Orful[as in image].

EDIT: With ConvertToY8 UnCommented [Problem not just in result ConvertToYV12 chroma channels]
https://i.postimg.cc/RqDCWhn5/t-01.jpg (https://postimg.cc/RqDCWhn5)

EDIT: Same problem with Pixel_Type="RGBP" [No Alpha channel]

EDIT: Cant find any more bugs until this is fixed, I'm stuck at this. [Working on S_ExLogo2() script, target all avs versions(v2.58, v2.60/61, avs+), decent blurring, working in all colorspaces/depths (except YV411)].

[pinterf]

Is me doin' summick rong agen :(


W=86 # Even non multiple of 8, BAD
H=64 # Any Even OK (above some size)
BlankClip(Length=1,Width=W,Height=H,Pixel_Type="RGBAP") # Planar RGBA 8 bit [ Same prob if "RGBP" ]
#Return PointResize(512,512) # OK always
ConvertToYV12 # Same prob if ConvertToYUY2 [ ConvertToRGB32/ConvertToRGB24 OK ]
#ConvertToY8
Return PointResize(512,512)

Click on Image for PointResize(512,512)
https://i.postimg.cc/vgsHHVJG/t-00.jpg (https://postimg.cc/vgsHHVJG)

EDIT: Even Heights OK
W Mulitples of 8, +0=GUD, +2=Bad, +4=Wurse, +6=Orful[as in image].

EDIT: With ConvertToY8 UnCommented [Problem not just in result ConvertToYV12 chroma channels]
https://i.postimg.cc/RqDCWhn5/t-01.jpg (https://postimg.cc/RqDCWhn5)

EDIT: Same problem with Pixel_Type="RGBP" [No Alpha channel]

EDIT: Cant find any more bugs until this is fixed, I'm stuck at this. [Working on S_ExLogo2() script, target all avs versions(v2.58, v2.60/61, avs+), decent blurring, working in all colorspaces/depths (except YV411)].
The good the bad and the ugly. I got it, sir.
EDIT: Fixed

[pinterf]

If no other problems found, mainly in Expr by real.finder or others, I'll prepare a release in some days (3.5)
Btw: is there anybody still using XP? (for those who are younger and haven't heard of this OS: XP wiki (https://hu.wikipedia.org/wiki/Windows_XP))
(ha-ha :) )

edit:
3.5 test build, files only
https://drive.google.com/open?id=10QyJQRPwyHx40gW5mbQoUJIyX9jOAfD4
See readme.txt for changes

[Groucho2004]

Btw: is there anybody still using XP?I guess you're asking because you consider dropping XP support. That's a tough one. I know that there are still folks out there using XP and they'd be quite upset if XP support was dropped. I suppose it depends on things such as how many of those XP fossils are out there (I used to be one until just a few months ago) and will dropping XP support make things easier for you? Maybe the poll I started will shed a little light.

[pinterf]

I guess you're asking because you consider dropping XP support. That's a tough one. I know that there are still folks out there using XP and they'd be quite upset if XP support was dropped. I suppose it depends on things such as how many of those XP fossils are out there (I used to be one until just a few months ago) and will dropping XP support make things easier for you? Maybe the poll I started will shed a little light.
VS2019 is still supporting XP, but you have to download the extra v141_xp toolset. With XP support in our mind, releasing an LLVM clang build is impossible as well, LLVM dropped XP support three (?) years ago. (Though not considering it at the moment, I did not test for speed difference yet)
Of course I can make installers for all different flavours, but I'd prefer only one version, I don't have infinite time and to tell the truth it's quite inconveniant.

[manolito]

Even though my main computer still runs WinXP, in the case of AVS+ I would not mind if XP support was dropped. For a very simple reason:

AVS+ 32 is way slower than classic AVS 2.61 Alpha on this machine. Probably because I have only 576 MB of RAM, and AVS+ needs a lot more RAM to become faster than classic AVS.

[StainlessS]

Maybe lets get all bugs fixed first, yes :)

EDIT: And for those of you that do not sprechen die Hungarian:- https://en.wikipedia.org/wiki/Windows_XP

EDIT: I gots it P, Ill give it a whirl, thanx :)

[real.finder]

Even though my main computer still runs WinXP, in the case of AVS+ I would not mind if XP support was dropped. For a very simple reason:

AVS+ 32 is way slower than classic AVS 2.61 Alpha on this machine. Probably because I have only 576 MB of RAM, and AVS+ needs a lot more RAM to become faster than classic AVS.

I think the main reason for the slow down is dropping any old asm code in avs+ (minimum asm in avs+ is SSE2)

[Groucho2004]

AVS+ 32 is way slower than classic AVS 2.61 Alpha on this machine.real.finder got the cause for this right. Also, just curious - why are you using 2.6.1 Alpha and not 2.6.0?

Probably because I have only 576 MB of RAM, and AVS+ needs a lot more RAM to become faster than classic AVS.My experience is the exact opposite. AVS+ uses less memory than classic. Have you verified this with AVSMeter?

Edit: QED:
Script

LoadCPlugin("E:\Apps\VideoTools\AVSPlugins\CPlugs\ffms2_32.dll")
FFVideoSource("TestDenoise.mkv", threads = 1)
MCD()

function MCD(clip video, int "threshold")
{
last = video
threshold = default(threshold, 200)

bs = (width() > 960) ? 16 : 8
sc = MSuper(pel = 2, sharp = 1, hpad = 16, vpad = 16)
backward_vector = MAnalyse(sc, isb = true, delta = 1, blksize = bs, overlap = bs / 2, sadx264 = 4)
forward_vector = MAnalyse(sc, isb = false, delta = 1, blksize = bs, overlap = bs / 2, sadx264 = 4)
backward_vector = MRecalculate(sc, backward_vector, blksize = bs / 2, overlap = bs / 4, thSAD = 100)
forward_vector = MRecalculate(sc, forward_vector , blksize = bs / 2, overlap = bs / 4, thSAD = 100)
MDegrain1(sc, backward_vector, forward_vector, thSAD = threshold)

return last
}

AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp
Frames processed: 310 (0 - 309)
FPS (min | max | average): 1.108 | 16.57 | 4.395
Process memory usage (max): 701 MiB
Thread count: 1
CPU usage (average): 24.9%


AviSynth+ 3.4 (r2923, 3.4, i386)
Frames processed: 310 (0 - 309)
FPS (min | max | average): 0.763 | 16.65 | 4.414
Process memory usage (max): 281 MiB
Thread count: 5
CPU usage (average): 24.9%

[StainlessS]

My experience is the exact opposite
Mine too, but did not have any stats handy.

Mobile:

[manolito]

real.finder got the cause for this right. Also, just curious - why are you using 2.6.1 Alpha and not 2.6.0?
Just 1 reason:
Version 2.61 contains a newer and much better version of TimeStretch.

My experience is the exact opposite. AVS+ uses less memory than classic. Have you verified this with AVSMeter?

We had this discussion before, no need to test it again. Look here:
https://forum.doom9.org/showthread.php?p=1863768#post1863768

Of course I had to use a Non-SSE2 version of AVS+ for my machine. And AvsMeter clearly shows that there is no advantage whatsoever using AVS+ on this computer. All the new features of AVS+ are not for me, I have no interest in high bitdepth or hi colors, and UHD or even HD clips are not usable on this machine anyways.

[Groucho2004]

We had this discussion beforeForgot about that. Excuse an old fart for not committing each of his Doom9 posts to memory. :)

[StainlessS]

Me only really uses 8 bit output, but high bitdepth maintains precision across many transitions/filters not such a bad thing really. [EDIT: I'm not quite there yet, but aiming for it ].

[real.finder]

Of course I had to use a Non-SSE2 version of AVS+ for my machine. And AvsMeter clearly shows that there is no advantage whatsoever using AVS+ on this computer. All the new features of AVS+ are not for me, I have no interest in high bitdepth or hi colors, and UHD or even HD clips are not usable on this machine anyways.

Non-SSE2 version of AVS+ done by c/c++ code only, that why it's slower than old avs 2.6 that still has Non-SSE2 asm

[manolito]

Non-SSE2 version of AVS+ done by c/c++ code only, that why it's slower than old avs 2.6 that still has Non-SSE2 asm
Yes I know...
Don't get me wrong, I kinda like AVS+, and I do use it on at least one of my Win7 notebooks. But I also have to say that it was way too much trouble to get MT mode halfway stable with my preferred plugins. I think I got it now, but my speed gain dropped to a meager 2 to 3 fps. Not really worth the effort...

[jpsdr]

Btw: is there anybody still using XP?
I'm not using XP anymore, but one suggestion or possible thing, is for "version with XP support" just provide the "files only" version (like you did for testing), and the installer and all stuff for the "version without XP support".

[pinterf]

Non-SSE2 version of AVS+ done by c/c++ code only, that why it's slower than old avs 2.6 that still has Non-SSE2 asm
Most old functions do have mmx version, which still work in 32 bit SSE-only builds. Where you may encounter significant difference between avs+ and classic avs, it's because of the low-memory scenarios. Internal frame caching is completely different, the main differences come from this fact.

On the other hand, I've seen cases in the past where compiler produced faster code from C and was optimizing better than the original hand-made assembly code.

Anyway, I added a 32bit non-SSE2 (SSE only) build to the yesterday's package.

Download Avisynth+ 3.5 test build (x86, x64, x86 SSE only) from here:
https://drive.google.com/open?id=1ShnOCqBuuxWoBzfB1QnV_niHBT0zRcZO

[StainlessS]

Lil bit Errata for Layer on Wiki,


Layer

Layer (aka overlay, blend, merge) two clips of possibly different sizes, but with the same color format.

For pixel-wise transparency information, the alpha channel of an RGBA overlay_clip is used as a mask.

AVS+ Before Avisynth+ 3.4.0 Layer was working only for RGB32 and YUY2.
Filter "Overlay" was used primarily for YUV. Now Layer accepts practically all formats (no RGB24).

Also no RGB48, so no 3 channel Interleaved RGB without Alpha, supported.

Planar RGBP10 works OK
Planar RGBP12 works OK
Planar RGBP14 works OK
Planar RGBP16 works OK
Planar 32 bit Float No Alpha RGBPS OK
Planar 32 bit Float with Alpha RGBAPS OK

EDIT: Also, Maybe should throw Error if trying to use Layer on RGB24/RGB48, it just does nothing. (no change to target clip)
Sort of got S_ExLogo2() working for all colorspaces [barring YV411], no more bugs found (as yet).

[pinterf]

Lil bit Errata for Layer on Wiki,
Also no RGB48, so no 3 channel Interleaved RGB without Alpha, supported.
EDIT: Also, Maybe should throw Error if trying to use Layer on RGB24/RGB48, it just does nothing. (no change to target clip)

I've made Layer to support rgb24/48. (by processing them as planar rgb behind the scenes)
Download Avisynth+ 3.5 test build (r2947) x64, x86, x86-SSE-only
https://drive.google.com/open?id=1J4yqWEk7Trs_3h--PwF_u4pDdnk_E7Em

[StainlessS]

OOooo... lovely P, will save a little bit of jumping through hoops for special cases, thanx awfully :)

[2ndR]

YV12Source
ConvertTo16bit ()
ConvertToRGB48 ("Rec709")
ConvertTo8bit (dither = 1)

Does not work

[poisondeathray]

ConvertTo16bit ()
ConvertToRGB48 ("Rec709")
ConvertTo8bit (dither = 1)
Does not work


Starting from YV12? Try going through planarRGB


ConvertTo16bit ()
ConvertToPlanarRGB(matrix="Rec709")
ConvertTo8bit (dither = 1)
#ConvertToRGB24 # (if packed required)

[FranceBB]

is there anybody still using XP?


Me! And many other people here I think.
Although I have Windows 10 x64 at work, at home I have Fedora (Linux), but I still use Windows XP for pretty much everything from chatting to surfing the web and so on as long as it's not work-related.
My CPU does actually support instructions set up to AVX2 however XP supports 'till SSE4.2. The thing is that it would be a shame to drop XP Support. Is there any specific reason why it couldn't be targeted other than downloading the additional compiling tool for Visual Studio 2019 to target XP?

[Stephen R. Savage]

Is there a plan to merge the latest Expr improvements from VS?

[wonkey_monkey]

Out of curiosity, is interleaved RGB (either in AviSynth or just in general) on its way to being deprecated? Or at least sidelined by Planar RGB?

[qyot27]

Out of curiosity, is interleaved RGB (either in AviSynth or just in general) on its way to being deprecated? Or at least sidelined by Planar RGB?
Sidelined, I would say yes.

Consider the interleaved RGB formats there for compatibility and because they - and YUY2 - were essentially grandfathered in. We're not adding new interleaved formats (save for possibly doing stuff like outputting v210 through the VfW layer, but that's not internal processing), but I can't see any reason we'd remove the ones that are already there.

[2ndR]

Starting from YV12? Try going through planarRGB

Thank you very much. Recent worries have been resolved

[pinterf]

Is there a plan to merge the latest Expr improvements from VS?
I've examined the changes but unfortunately had no time for porting them.

[pinterf]

Me! And many other people here I think.
Although I have Windows 10 x64 at work, at home I have Fedora (Linux), but I still use Windows XP for pretty much everything from chatting to surfing the web and so on as long as it's not work-related.
My CPU does actually support instructions set up to AVX2 however XP supports 'till SSE4.2. The thing is that it would be a shame to drop XP Support. Is there any specific reason why it couldn't be targeted other than downloading the additional compiling tool for Visual Studio 2019 to target XP?
Yep, I've seen the usage statistics in the latest poll over there, which was showing the demand for XP - I don't know whether it comes from the typical age tree of the visitors of forum-like social media :), anyway as long as there is a relatively effortless option for building xp-friendly stuff, I'll keep it for a while.

[pinterf]

Out of curiosity, is interleaved RGB (either in AviSynth or just in general) on its way to being deprecated? Or at least sidelined by Planar RGB?
Sidelined. And like I did in Layer, instead of supporting RGB24/48 directly and implement another set of code paths, the filter seamlessly converts them to planar RGB do the filter core and convert it back to the old format. Soon you'll even forget to put the word "planar" when mentioning RGB.

[StainlessS]

Hi P, can you confirm this please:- https://forum.doom9.org/showthread.php?p=1899154#post1899154

Limitations and Known Issues
1. VLC playback parameters are identified upon start of playback.
Therefore AviSynth script should provide video with constant resolution and fps, as well as audio with constant sample rate,
number of channels and bit-depth. Otherwise VLC will probably crash.
Need to remark that scripts with varying resolution and audio parameters are very rare.



Dont think is possible for Avisynth to change any of above during playback. [EDIT: Perhaps someone else can confirm this]


Thanks in advance. :thanks:

[Stereodude]

Yep, I've seen the usage statistics in the latest poll over there, which was showing the demand for XP - I don't know whether it comes from the typical age tree of the visitors of forum-like social media :), anyway as long as there is a relatively effortless option for building xp-friendly stuff, I'll keep it for a while.
Windows 7 is already out of mainline support and people are still using XP? I wouldn't advocate dropping it just to spite XP users, but at this point you can barely even run Windows 7 on the latest hardware (definitely not officially supported). Encoding has to be quite painfully slow on the most recent hardware that actually supports XP.

Are there really people trying to use their ~20 year old P4 with their nearly 20 year old OS to work with modern video formats and processing techniques? Given the hardware and OS they're using it seems like they shouldn't have any issues with running an old version of AVIsynth(+) too. They should be used to it since pretty much every application has already left them behind.

[StainlessS]

Encoding has to be quite painfully slow on the most recent hardware that actually supports XP.
Who cares, set it going and tell it to auto shutdown when done, easy peasy. [I prefer not to encode on my No1 Machine].

[Groucho2004]

at this point you can barely even run Windows 7 on the latest hardware (definitely not officially supported).Not true. I just checked Asus support page, most AM4 boards support W7 and these Ryzen CPUs are very fast when it comes to encoding video.

Are there really people trying to use their ~20 year old P4There's a bloke here who still uses a P3. :)

[qyot27]

Windows 7 is already out of mainline support and people are still using XP? I wouldn't advocate dropping it just to spite XP users, but at this point you can barely even run Windows 7 on the latest hardware (definitely not officially supported). Encoding has to be quite painfully slow on the most recent hardware that actually supports XP.

Are there really people trying to use their ~20 year old P4 with their nearly 20 year old OS to work with modern video formats and processing techniques? Given the hardware and OS they're using it seems like they shouldn't have any issues with running an old version of AVIsynth(+) too. They should be used to it since pretty much every application has already left them behind.
Let's also be fairly clear, too: anyone with one of those setups could just as easily install a 32-bit version of Linux (or 64-bit, if after the advent of Athlon64/Core 2) and run current versions of AviSynth+ using Wine.

For the ancient systems, like the Coppermine-128 that's gathering dust¹ under my desk, the Win7 or Win10 targetting isn't the problem (under Linux); it's the lack of SSE2. And as far as that goes, AviSynth+ has the MSVC_ARCH configuration option to set the C++ code optimization and generate builds compatible with that if you so choose (or you could go nuts and make builds for 64-bit that require AVX2, the option swings both ways).

¹I barely turn the thing on anymore, since the Byte3 on top of my desk runs circles around it. For a while it served as an archival system due to having a large hard drive in it, but if I continue doing anything with it, it'll probably be as a ReactOS testbed.

[Groucho2004]

... as long as there is a relatively effortless option for building xp-friendly stuff, I'll keep it for a while.Sounds reasonable.

[FranceBB]

Yep, I've seen the usage statistics in the latest poll over there, which was showing the demand for XP - I don't know whether it comes from the typical age tree of the visitors of forum-like social media :), anyway as long as there is a relatively effortless option for building xp-friendly stuff, I'll keep it for a while.

Thank you, Ferenc! :)

Windows 7 is already out of mainline support and people are still using XP?

Yes we are, besides with the extended support we kept it updated 'till April 2019. By the way, companies paying Microsoft for "Premium Support" still receive updates every second Tuesday of the month; it's called "Patch Tuesday", but unfortunately there has been no one that shared those across the web (for obvious legally binding reasons :( ).

at this point you can barely even run Windows 7 on the latest hardware (definitely not officially supported). Encoding has to be quite painfully slow on the most recent hardware that actually supports XP.

Not really. For instance I have Windows 10 at work, but I keep my Windows XP VM at home since I use Fedora + XP and I hate Windows 10 (truth to be told I have it but I fire it up only when I have to use Visual Studio, Matlab, Davinci Resolve, AVID and then I quickly shut it down).
There are countless of people on VMs with XP for many different reasons.

Are there really people trying to use their ~20 year old P4 with their nearly 20 year old OS to work with modern video formats and processing techniques?

Look at Manolino! He's absolutely happy with his setup and nothing is stopping him from encoding files and that's the way it is! ;)
(If I remember correctly even StainlessS was happily on XP up 'till few months ago).

Given the hardware and OS they're using it seems like they shouldn't have any issues with running an old version of AVIsynth(+) too. They should be used to it since pretty much every application has already left them behind.

Not true. As I said there are many people running XP in VMs on modern hardware and there's a hugely active community on MSFN of XP users (https://msfn.org/board/forum/34-windows-xp/) and I'm proudly part of it. As a matter of fact there are custom build of x265, custom builds of ffmpeg, custom builds of modern browsers based on Firefox and some official programs that still support XP like PotPlayer, AnyDesk, Miranda and so on. Life on XP is still not impossible.
As you can see from the net market share, XP doesn't lag so far behind many popular OS and is still worth it:

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



The only problem I see for Windows XP encoding-wise is the lack of modern indexers. LSMash is several years old and the latest build that is XP compatible is limited to 16bit stack or interleaved (I don't remember which one) not even planar 16bit.
ffms2 kept support for way longer, however in the end even qyot27 decided to drop XP support for the C plugin, eventually.
In case of foreign weird new codecs, people running XP are left with the very last version of ffmpeg so that they can decode the file, save it to something lossless like huffyuv, ffv1, utvideo and so on and then index and work with it in Avisynth, which is not exactly the best thing ever but it works.
Anyway, I still forecast a not-so-bad future for XP die-hard, especially 'cause there are many people willing to help and there's a very good community which I'm happily part of, so I thank Ferenc for keeping XP-Support. :)

[Stereodude]

Who cares, set it going and tell it to auto shutdown when done, easy peasy. [I prefer not to encode on my No1 Machine].
So in a month or two your encoding job will be done? A 3.06gHz P4 with HT is likely 40-50x slower (extrapolating from Passmark scores) than my E5-2687W v2, which I think is too slow to be practical. I don't consider x265 encoding at 0.00625fps to be viable. At some point the cost of just the electricity to run the job on an old system vs. modern HW would pay for the new system.

Not true. I just checked Asus support page, most AM4 boards support W7 and these Ryzen CPUs are very fast when it comes to encoding video.
Which is great, but Ryzen 3000 and the Intel 9xxx stuff doesn't work with Windows 7 (unless you somehow count not having USB as working) regardless of whether there are Windows 7 drivers for a motherboard that will take the CPU. I stand by my comment that the latest HW barely works under Windows 7.

[tormento]

With XP support in our mind, releasing an LLVM clang build is impossible as well, LLVM dropped XP support three (?) years ago. (Though not considering it at the moment, I did not test for speed difference yet) Of course I can make installers for all different flavours, but I'd prefer only one version, I don't have infinite time and to tell the truth it's quite inconveniant.
I clearly understand.

I find, anyway, unreasonable to keep on dragging a useless weight for 1.34% of the users when the other ~98% would benefit from CLANG compiles of Avisynth+, MVTools2, MaskTools and RGTools.

[pinterf]

Clang is not magic.
There are cases when clang is better, but sometimes msvc build is quicker. The race result even depends on whether we are seeing SSE4 or AVX2 code paths or just a different function.
In RgTools for example one mode is quicker with clang build, others are better with microsoft compiler.

[StainlessS]

I find, anyway, unreasonable to keep on dragging a useless weight for 1.34% of the users when the other ~98% would benefit from CLANG compiles of Avisynth+, MVTools2, MaskTools and RGTools.
Usage Poll, 10 XP users versus 29 W10 users of Avisynth, is a bit more than 1.34%.

EDIT: Current total OS usage sample 58.
I use 2 * XP, 1 * W7, 1*W10, and voted for all 3, [was only supposed to vote for 1]

[real.finder]

expr don't have >> like lut? I got error with expr("x 100 scalef <= x 1 >> x 1.4 ^ ?",scale_inputs="floatf")

[pinterf]

No binary shifts. You have to use /2 or *0.5 instead. Plus an integer truncation if being integer is important.

[TheFluff]

expr don't have >> like lut? I got error with expr("x 100 scalef <= x 1 >> x 1.4 ^ ?",scale_inputs="floatf")

expr converts all inputs to single precision float and works with that internally, so binary left/right shift isn't really meaningful in the way it is for integers.

[real.finder]

thank you both pinterf and TheFluff

Currently I work on port ContraSharpen_mod (https://web.archive.org/web/20140711175720/https://www.nmm-hd.org/upload/get~n1nycx8X7qw/ContraSharpen_mod.avsi) for Nnedi3_resize16 both by mawen1250 to avs+ and it has this expr, I will leave it in mt_lut for now until I fully complete the script

[real.finder]

if I go from out-of-range float clip (not 0..1.0 luma nor -0.5..0.5 chroma) to 8 bit int I got kinda wrong output unless I use mt_lut("x -0.5 0.5 clip",yexpr="x 0 1 clip",u=3,v=3) or Limiter(0,1,-0.5,0.5) before I convert to 8 bit, is this bug or this is normal?

[pinterf]

if I go from out-of-range float clip (not 0..1.0 luma nor -0.5..0.5 chroma) to 8 bit int I got kinda wrong output unless I use mt_lut("x -0.5 0.5 clip",yexpr="x 0 1 clip",u=3,v=3) or Limiter(0,1,-0.5,0.5) before I convert to 8 bit, is this bug or this is normal?
If it does not even fit into a 32 bit integer, there may be problems, but I'll check it when you specify how much it is out of range.

[real.finder]

If it does not even fit into a 32 bit integer, there may be problems, but I'll check it when you specify how much it is out of range.

test with this fat lut/expr from ContraSharpen_mod


ColorBars(width=640, height=480).converttoyv12
ConvertBits(32)
mt_lut("x 128 == x x 128 - abs 11 / 22 ^ 11 * "+string(33/100.0)+" * x 128 > 1 -1 ? * x 128 - 2 ^ 11 2 ^ 44 + * x 128 - 2 ^ 44 + 11 2 ^ * / * 1 55 0 == 0 11 55 / 4 ^ ? + 1 55 0 == 0 x 128 - abs 55 / 4 ^ ? + / * 128 + ?",scale_inputs="allf",use_expr=2, U=3, V=3)
ConvertBits(8) #ok with isvideofloat? Limiter(0,1,-0.5,0.5).ConvertBits(8) : ConvertBits(8)

[pinterf]

Thanks for the sample. When the pixel value is greater 128 (float format) - not that the usual max. is 1.0 - then the 8 bit conversion will not clamp to 255. Rare case, nevertheless I have fixed it on my side.

[amichaelt]

Usage Poll, 10 XP users versus 29 W10 users of Avisynth, is a bit more than 1.34%.

EDIT: Current total OS usage sample 58.
I use 2 * XP, 1 * W7, 1*W10, and voted for all 3, [was only supposed to vote for 1]

https://en.wikipedia.org/wiki/Selection_bias

[StainlessS]

Yep I see what you mean, I should have only voted for XP, as that is the one I use on most machines.

[tormento]

Usage Poll, 10 XP users versus 29 W10 users of Avisynth, is a bit more than 1.34%.
This forum is everything but a representative sample.

[StainlessS]

Yep you are correct, there will be MANY more XP users than show up on Internet Stats, many are totally offline (One of mine is occasionally given Internet access [several months since] the other one NEVER).

[StainlessS]

Dont know if below is bugged, or misleading error message, or both.


# OK
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").PointResize(256,256)

# Resize: source image too small for this resize method. Width=1, Support=1.
Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").BilinearResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV12").BicubicResize(256,256) # NOTE, YV12, Presumably error for chroma

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").BicubicResize(256,256) # NOTE, YV24

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").Lanczos4Resize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").GaussResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").BlackmanResize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").LanczosResize(256,256)

# Resize: source image too small for this resize method. Width=4, Support=4.
Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").sincResize(256,256)

# Resize: source image too small for this resize method. Width=2, Support=2.
Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").Spline16Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

# Resize: source image too small for this resize method. Width=3, Support=3.
Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256)

Return Last

For eg YV24, width=2, height=2, Says width = 2, Support=2 (when it clearly produces an error message, ie seems not to support 2).

Think its been like this 4E4 (believe it exists as above in avs standard).

EDIT: Presume similar on height, untried.
Above still happens.

Also,

W=1
H=1
CS="RGB32"
BlankClip(Width=256,Height=256,pixel_type=CS)
#BiLinearResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=256.
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=512.
Return Last

Presume same for Height [and other Resizers/colorspaces], untested.
EDIT: "AviSynth+ 3.5 (r2947, master, i386)"

EDIT: Even chasing the error message is fun :)

W=1
H=1
CS="RGB32"
#BlankClip(Width=256,Height=256,pixel_type=CS)
#BiLinearResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=256.
#BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=256, Support=512.

# Even chasing the error message is fun
#BlankClip(Width=512,Height=512,pixel_type=CS)
#BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=512, Support=1024.

BlankClip(Width=1024,Height=1024,pixel_type=CS)
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=1024, Support=2048.

Return Last

[pinterf]

BlankClip(Width=1024,Height=1024,pixel_type=CS)
BicubicResize(W,H) # Resize: Source image too small for this resize method. Width=1024, Support=2048.

Return Last
[...]

I will definitely kill that error message about "support". Filter property, original and target size, crop size are all involved in the calculation.

filter_support = support() / min(target_width / crop_width, 1.0)
if (width_original < filter_support) --> error

support() values are
4 - Gaussian, sinc, Spline64, lanczos4
4 (or taps) - Blackman
3 (or taps) - Lanczos
3 - Spline36
2 - Spline16, bicubic
1 - bilinear

[StainlessS]

This calcs for 2.58, 2.60, and avs+


Function IsAvs26() { VersionNumber>=2.6}
Function IsAvsNeo() { FindStr(VersionString," Neo")!=0}
Function IsAvsPlus() { FindStr(VersionString,"AviSynth+")!=0||IsAvsNeo}
Function X_YMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Height/ExtractU.Height):(IsYV12 ?2:1) } # Y Min crop multiple for Progressive
Function X_XMod(clip c) { c IsAvsPlus ? (NumComponents==1||IsRGB?1:Width/ExtractU.Width):IsAvs26?(IsYV411?4:IsYUY2||IsYV16||IsYV12?2:1):(IsRGB?1:2)} # X Min crop multiple
Function X_CsXMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsXMod: CSP Clip or Pixel_Type string ONLY") Return X_XMod }
Function X_CsYMod(Val CSP) { (CSP.IsClip)?CSP:(CSP.IsString)?Blankclip(Length=1,Width=16,height=16,Pixel_type=CSP):Assert(False,"X_CsYMod: CSP Clip or Pixel_Type string ONLY") Return X_YMod }

Function X_MinResize(String Resizer,Val CSP,Bool "Wid",Bool "Src",Int "Taps") { # Minimum required Width or Height, Source or Dest, for Resizer and Colorspace, CSP can be Clip or String eg "RGB32"
S=Resizer.UCase I=FindStr(S,"RESIZE") S=(I==0) ? S : S.LeftStr(I-1) # Can use eg Resizer either "BiLinearResize or just BiLinear"
Ix=(S=="POINT")?0:(S=="BILINEAR")?1:(S=="BICUBIC")?2:(S=="SPLINE16")?3:(S=="SPLINE36")?4:(S=="SPLINE64")?5:(S=="GAUSS")?6:(S=="LANCZOS4")?7:(S=="LANCZOS")?8:(S=="BLACKMAN")?9:(S=="SINC")?10:-1
Assert(0 <= IX <= (IsAvs26?10:9), "X_MinResize: No such Resizer filter (" + S + "Resize)")
defT=Select(Ix, 0,-1,-2,-2,-3,-4,-4,-4,3,4,4)
Wid=Default(Wid,True) # True = Inquire Width, else Height
Src=Default(Src,True) # True = Inquire Upscale Src, else DownScale Dest
Assert(defT>0 || !Taps.Defined,"X_MinResize: "+S+"RESIZE Does not have a Taps arg")
Taps=(defT>0) ? Default(Taps,defT) : Abs(defT)
Assert(CSP.IsClip || CSP.IsString,"X_MinResize: CSP clip or Pixel_Type string ONLY")
Return (Wid) ? (Taps+1) * CSP.X_CsXMod : (IsAvs26) ? (Taps+1) * CSP.X_CsYMod
\ : (Src) ? (Taps+1) * 2 : Max((Taps+1)*2,4) # Fix for v2.58 Peculiarities
}


From here:- https://forum.doom9.org/showthread.php?p=1901605#post1901605

EDIT:
I do not take into account Dest size when inquiring min Src size, or Src size when inquiring min Dest size, it dont seem to matter, maybe I need more checks.
Also do not take into account src_left, Src_top etc, we assume full src.

EDIT:
filter_support = support() / min(target_width / crop_width, 1.0)
if (width_original < filter_support) --> error

# ...

1 - bilinear

If say Bilinear [support=1], and upsizing, so "min(target_width / crop_width, 1.0)" = 1.0, and filter_support = 1.0/1.0 = 1, so error if width_original < 1.0, however,
bilinear always fails unless width_original = 2, ie support + 1. Same with all of the others, and the reason for the "(Taps+1) * CSP.X_CsXMod" type stuff above,
you can substitute support where says Taps above.
Maybe there is some kind of float precision thing going on, where something like width_original < 1.00000000000001 provides error where it is intended not to.
Same happens when downsize, taps + 1 minimum.


S=1
BlankClip(Length=1,Width=S,Height=S,Pixel_type="RGB32")
Z=2
BiLinearResize(Z,Z) # Width=1 support = 1 error


EDIT: This looks like it
ResamplingProgram* ResamplingFunction::GetResamplingProgram(int source_size, double crop_start, double crop_size, int target_size, int bits_per_pixel, IScriptEnvironment2* env)
{
double filter_scale = double(target_size) / crop_size;
double filter_step = min(filter_scale, 1.0);
double filter_support = support() / filter_step;
int fir_filter_size = int(ceil(filter_support*2));

ResamplingProgram* program = new ResamplingProgram(fir_filter_size, source_size, target_size, crop_start, crop_size, bits_per_pixel, env);

// this variable translates such that the image center remains fixed
double pos;
double pos_step = crop_size / target_size;

if (source_size <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method. Width=%d, Support=%d", source_size, int(ceil(filter_support)));
}

Actually <= not <, so support actually means not supported ???
[Actually, I think qyot27 might have said something about < versus <= last time subject came up]
EDIT: Yep, RaffRiff42 and qyot27 both made mention:- https://forum.doom9.org/showthread.php?p=1836752#post1836752

[stax76]

Made some simple wrapper library for AviSynth and VapourSynth, it was necessary because AviSynth has no C or COM interface...

https://github.com/staxrip/staxrip/tree/master/FrameServer

https://github.com/staxrip/staxrip/blob/master/General/FrameServer.vb

https://github.com/staxrip/staxrip/blob/master/General/VideoRenderer.vb

[gpower2]

Made some simple wrapper library for AviSynth and VapourSynth, it was necessary because AviSynth has no C or COM interface...

https://github.com/staxrip/staxrip/tree/master/FrameServer

https://github.com/staxrip/staxrip/blob/master/General/FrameServer.vb

https://github.com/staxrip/staxrip/blob/master/General/VideoRenderer.vb

Good job m8!
I was experimenting myself recently on something similar for my C# projects!

[stax76]

@gpower2

No problem, I've committed a vs text encoding fix today. To convert from VB.NET to C# there is http://converter.telerik.com or if that don't work the jetbrains dotpeek decompiler can be used.

MysteryX has written code to access VapourSynth directly in C#, that would have been an alternative route I could have taken.

https://github.com/mysteryx93?tab=repositories

[qyot27]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)

The big, shiny new feature this time around: native support for Linux, macOS, and BSD. Full list of changes:

New:
New: Native Linux, macOS, and BSD support.
New function:
bool IsVersionOrGreater(int majorVersion, int minorVersion [,int bugfixVersion]) function
Returns true if the current version is equal or greater than the required one in the parameters.
The function is checking the current version against the given parameters (similar to a Windows API function)
e.g. IsVersionOrGreater(3, 4) or IsVersionOrGreater(3, 5, 8)
New: "Expr" helpers:
Constants "yrange_min", "yrange_half", "yrange_max"
Unlike the luma/chroma plane adaptive "range_min", "range_half", "range_max" these constants always report the luma (Y) values
new parameter: bool clamp_float_UV (default false)
this parameter affects clamping of chroma planes: chroma is clamped between 0..1.0 instead of -0.5..0.5s
"clamp_float" is not ignored (and set to true) when parameter "scale_inputs" auto-scales 32 bit float type pixels
New "yscalef" and "yscaleb" keywords similar to "scalef" and "scaleb" but scaling is forced to use rules for Y (non-UV) planes
new allowed value "floatUV" for scale_inputs.
In short: chroma pre-shift by 0.5 for 32 bit float pixels
Affects the chroma plane expressions of 32 bit float formats.
Shifts the input up by 0.5 before processing it in the expression, thus values from -0.5..0.5 (zero centered) range are converted to the 0..1 (0.5 centered) one.
Since the expression result internally has 0..1.0 range, this then is shifted back to the original -0.5..0.5 range. (since 2.2.20)
Note: predefined constants such as cmin, cmax, range_min, range_max and range_half will be shifted as well, e.g. the expression will see range_half = 0.5

These modifications are similar to Masktools2 2.2.20+
New: AddBorders, LetterBox: new color_yuv parameter like in BlankClip


Fixes:
Fix: ConvertBits 32->8 for extremely out of range float pixel values.
When pixel value in a 32 bit float format video was way out of range and greater than 128 (e.g. instead of 0 to 1.0 for Y plane) then the ConvertBits(8) had artifacts.
Fix potential crash on exit or cache shrink (linux/gcc only?)
Layer: support RGB24 and RGB48 (internally processed as Planar RGB - lossless pre and post conversion)
Fix: RGBP to 444 8-14bit right side artifacts at specific widths
Fix: "scalef" and "scaleb" for 32 bit input, when scale_inputs="floatf" produced wrong result
Fix: missing rounder in V channel calculation of PlanarRGB->YUV 8-14bits SSE2 code
Overlay: show error when Overlay is fed with clips with different bit depths
Fix: TemporalSoften possible access violation after SeparateFields (in general: after filters that only change frame pitch)
Fix: Shibatch.DLL Access Violation crash when exit when target rate is the same as vi.audio_samples_per_second or audio_samples_per_second is 0
Build system: Cmake: use platform toolset "ClangCL" for using built-in Clang support of Visual Studio.
Since VS2019 v16.4 there is LLVM 9.0 support.
Use: Tools|Get Tools and Features|Add Individual Components|Compilers, build tools, and runtimes
[X] C++ Clang compiler for Windows
[X] C++ Clang-cl for v142 build tools (x64/x86)
(for LLVM Clang installed separately, please use llvm or LLVM - no change in its usage)

[StainlessS]

Lovely and shiny, thanx muchly :)

[ChaosKing]

Linux + mac support, nice! So it does not rely on vfw anymore? Are there already tools what supports "native" avs files on linux?

Happy avs filter recompiling :D

[DJATOM]

It seems like ffmpeg is the only available software that supports avs+ on linux. Probably it's possible to compile avs2yuv/avs2pipemod, but I'm not interested to do so right now.

[FranceBB]

Introducing Linux and Mac OSX Support is a very important achievement!
Some people (including me) never thought this day was going to happen, but here it is...!
Kudos to all of you, guys!
And as always, it also works like a charm on Windows XP as well! (I just tested it) :)

[Groucho2004]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)Nice work. :thanks:

[wonkey_monkey]

So is this, not pinterf's, now the Avisynth+?

[qyot27]

So was 3.4; development moved back to the original AviSynth/AviSynthPlus git repo last summer.

[qyot27]

Linux + mac support, nice! So it does not rely on vfw anymore? Are there already tools what supports "native" avs files on linux?

Happy avs filter recompiling :D

x264 and FFmpeg on Windows have used the C interface for talking to AviSynth.dll directly for ages (x264 = 2009, FFmpeg = 2013). VfW was just a provided interface; on Windows it still is. This does mean that the AviSource/WAVSource/SegmentedFileSource filters don't exist on non-Windows OSes, though.

But yes, a patch exists to be able to use AviSynth+ in FFmpeg on Linux, et al. (https://github.com/qyot27/FFmpeg/commits/avsplus_linux). It getting into FFmpeg upstream is dependent on whether they want a deprecation message to tell people to upgrade from AvxSynth or not (and then delay the actual switch until after the next release of FFmpeg).

[LigH]

This is this now the Avisynth+, and not pinterf's?

It is our AviSynth+ now :cool:

[pinterf]

qyot27 never gives up :), thank you for pushing this through and answering my very basic questions. Supporting multiple platforms is a bit more difficult though. At least for someone (me) who is using linux in every five years for only a day or two. All I can say that Midnight Commander rulez :)

And a missing thing from the change log (I'll put it on Wiki)

Since on Linux we do not have Windows font rendering engine, as a quick solution a filter named "Text" was created with the same parameters as SubTitle.
"Text" is available on Windows as well.
It is using a simple 10x20 matrix fixed font (planned to have some more), similar to what debug text in some Avisynth external filters are using, but with color and halocolor for outline.
Size and orientations related parameters are simply ignored. SubTitle on linux is simply redirected to this new filter.

[real.finder]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)


:thanks: but why there are no "filesonly" aka portable? :)

[poisondeathray]

:thanks: but why there are no "filesonly" aka portable? :)

You can extract them from Groucho2004's installer using 7zip
https://forum.doom9.org/showthread.php?t=172124

[StainlessS]

filter named "SimpleText"
Nearly, close but no cigar :)


Blankclip(width=120,height=120,Color=$808080)
/*
Text "cs[x]f[y]f[first_frame]i[last_frame]i[font]s[size]f[text_color]i[halo_color]i[align]i[spc]i[lsp]i[font_width]f[font_angle]f[interlaced]b[font_filename]s[utf8]b"
*/

Text("Hello\nWorld",lsp=0,align=5)


https://i.postimg.cc/6pVvr9Hh/Text.jpg (https://postimages.org/)

[poisondeathray]

pinterf's test version had fixed the errors in this post with the internal avs conversion
https://forum.doom9.org/showthread.php?p=1897686

pinterf test version
https://forum.doom9.org/showthread.php?p=1898860

But using the recent 3.5, r3043 , some differences are back. 12bits again "fixes" it

avsresize/zimg/zlib works using 10bits with either version

[Reel.Deel]

Thank you pinterf and qyot27. Awesome job! :thanks:

[pinterf]

Nearly :)


Blankclip(width=120,height=120,Color=$808080)
/*
Text "cs[x]f[y]f[first_frame]i[last_frame]i[font]s[size]f[text_color]i[halo_color]i[align]i[spc]i[lsp]i[font_width]f[font_angle]f[interlaced]b[font_filename]s[utf8]b"
*/

Text("Hello\nWorld",lsp=0,align=5)


https://i.postimg.cc/6pVvr9Hh/Text.jpg (https://postimages.org/)
You are so right. I'm getting old. Seems that I have really done it :)

[pinterf]

pinterf's test version had fixed the errors in this post with the internal avs conversion
https://forum.doom9.org/showthread.php?p=1897686

pinterf test version
https://forum.doom9.org/showthread.php?p=1898860

But using the recent 3.5, r3043 , some differences are back. 12bits again "fixes" it

avsresize/zimg/zlib works using 10bits with either version
I can see the same small differences which are normal I think. The big differences are over.

[poisondeathray]

I can see the same small differences which are normal I think. The big differences are over.

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

[StainlessS]

You are so right. I'm getting old. Seems that I have really done it :)

Good memory :) you did really do it.


class SimpleText : public GenericVideoFilter
/**
* SimpleText creation class
**/
{
public:
SimpleText(PClip _child, const char _text[], int _x, int _y, int _firstframe, int _lastframe,
const char _fontname[], int _size, int _textcolor, int _halocolor, int _align,
int _spc, bool _multiline, int _lsp, int _font_width, int _font_angle, bool _interlaced, const char _font_filename[], const bool _utf8, IScriptEnvironment* env);
virtual ~SimpleText(void);
PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);

static AVSValue __cdecl Create(AVSValue args, void*, IScriptEnvironment* env);

int __stdcall SetCacheHints(int cachehints, int frame_range) override {
AVS_UNUSED(frame_range);
return cachehints == CACHE_GET_MTMODE ? MT_NICE_FILTER : 0;
}

private:
const int x, y, firstframe, lastframe;
const int size; // n/a
const int lsp;
const int font_width, font_angle; // n/a
const bool multiline;
const bool interlaced; // n/a
const int textcolor, halocolor, align;
const int spc; // n/a
const int halocolor_orig;
const char* const fontname; // n/a
const char* const text;
const char* const font_filename; // n/a
const bool utf8;
};


Only the names were changed to protect the innocent :)

[pinterf]

It's an improvement, but it should be lossless

PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

infinity with vapoursynth / avsresize / zlib/zimg
PSNR r:inf g:inf b:inf average:inf min:inf max:inf

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

[poisondeathray]

The algorithm has no more flaws I think. I have to check the coefficient accuracy.

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609

It's "inf" with vapoursynth or avsresize in all cases
[Parsed_psnr_4 @ 00000014ab642a00] PSNR r:inf g:inf b:inf average:inf min:inf max:inf

Results do not change if I test a written out bmp, or pipe into ffmpeg




Historically, ffmpeg swscale had many issues in the past with YUV/RGB conversions; but even it gets this 8bit RGB => 10bit YUV444 => 8bit RGB conversion correct now (at least with this test image)


ffmpeg -i yuv_exprm_02_bird.png -vf scale=out_color_matrix=bt709,format=yuv444p10le,scale=in_color_matrix=bt709,format=gbrp ffmpeg_swscale.bmp



ffmpeg -r 24 -i ffmpeg_swscale.bmp -r 24 -i yuv_exprm_02_bird.png -lavfi "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]psnr="stats_file=ff_psnr_ffmpeg_swscale.log"" -f null -


[Parsed_psnr_4 @ 00000098089e2140] PSNR r:inf g:inf b:inf average:inf min:inf max:inf



Thanks for your work pinterf and qyot27

[frencher]

Hi all,

I search for works my two plugins x86 HDR_AGC and svpflow :o

With only HDR it's works :)
With only svpflow works :)
With both HDR_AGC and svpflow WMP crash :(

How fix it :(

Thank's for all :thanks:

Plugins is
HDR > https://github.com/Anime4000/IFME/wiki/AviSynth--HDR-Video
SVP > https://www.svp-team.com/forum/viewtopic.php?pid=57410#p57410

https://www.zupimages.net/up/20/10/di6j.jpg

[LigH]

All I can say that Midnight Commander rulez :)

For Windows, the Far manager (https://farmanager.com) is my choice.

[pinterf]

PSNR (according to ffmpeg psnr) it's actually the same value with r2944 test version or r3043 (neither were lossless) ; so I was wrong , it wasn't "fixed" with that test version

pre r2944
[Parsed_psnr_4 @ 000000f905391940] PSNR r:59.321403 g:87.953516 b:73.777761 average:63.933949 min:63.933949 max:63.933949

r2944, r3043 - improved
[Parsed_psnr_4 @ 00000049feda2dc0] PSNR r:99.994716 g:inf b:73.777761 average:78.538609 min:78.538609 max:78.538609


VapourSynth and avsresize is using the same library, they have to have the same results.

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless

a
ConvertToPlanarRGB()
ConvertBits(10) # Z advantage: single step 8 bit rgb 10 bit yuv
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last #RGBP10 step before RGB24 works


And finally: avsresize is possibly using float arithmetic internally.

There are several types of converters, their usage depends on bit depth and processor capability.

One method (SSE2) is using the usual 15 bit integer arithmetic. I'm using it for 10-14 bit targets.

The other is converting the pixels to float, do the matrix multiplication and then converts the result back to the integer domain. Now I'm using it only for 16 bit case because the first method's SIMD intrinsics support only signed data without any tricks (16 bit is unsigned).

Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.

[pinterf]

With only HDR it's works :)
With only svpflow works :)
With both HDR_AGC and svpflow WMP crash :(

How fix it :(

Possibly HDRAGC source code is needed which is unfortunately not available (never published)

[TheFluff]

Avsresize has the advantage that it can convert _directly_ from 8 bit rgb to 10 bit YUV. I suppose that there is no 10 bit intermediate rgb result.

I don't think that's true, but this is:

And finally: avsresize is possibly using float arithmetic internally.

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want. Depending on what you're doing, the graph builder may decide to start the processing by increasing the bitdepth, to reduce intermediate losses. Converting colorspace is one such case - if you do that, the first thing it'll do is convert the pixel type to float, then upscale the chroma if necessary, and only then proceed to convert to whatever target format and resolution you want.

See https://github.com/sekrit-twc/zimg/blob/master/src/zimg/graph/graphbuilder.cpp#L669 for details, it has comments describing the process of building a filter chain for doing arbitrary conversions.

[poisondeathray]

VapourSynth and avsresize is using the same library, they have to have the same results.



I have seen implementation differences between vapoursynth's resize, ffmpeg -vf zscale, and avsresize. Despite being based the same library. It might be that the "snapshot" was based on different build or commits, I didn't look too closely. But this occurs for certain.



Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless



And ConvertBits(12) was NOT enough to "fix" it, yet 12bits is "enough" for internal resizer (for amplified visual differences, I didn't check PSNR). It doesn't entirely make sense, could something else be going on there?



Test2:
So I built a test version, where I was using the 32 bit float way for 10 bit data instead of the above mentioned integer arithmetics. Result: I only looked at the difference clips and visually (looking at rare dot distribution showing the non-losslessness) it had the same output as z_ConvertXXX (latter with the 10 bit input in order to compare apples to apples)

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

But Avisynth resizer is not capable to chain bit depth conversion with rgb->yuv conversion so I'd say it'll never give such losslessness.


Thanks for taking the time to investigate this

Does that imply ffmpeg swscale is using float internally too? I'd imagine that it didn't for speed purposes

My memory is a bit rusty, but once upon a time, I recall someone did some matlab calculations and +2 bits was supposedly enough to cover this conversion (just like 12bit YUV444 was sufficient to cover 10bit RGB), but I should have looked into the details more thoroughly

[poisondeathray]

Test 1: I have tried ConvertBits(10) right before avsresize
Result: mixed ConvertBits - Avsresize chain stopped being lossless


Actually, double checking this with PSNR, Z1 was not lossless to begin with .

[Parsed_psnr_4 @ 00000062fb042cc0] PSNR r:inf g:inf b:92.591089 average:97.362301 min:97.362301 max:97.362301


a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP10")
ConvertToRGB24()
z1=last





Z2 was lossless
[Parsed_psnr_4 @ 0000005dfa5d2cc0] PSNR r:inf g:inf b:inf average:inf min:inf max:inf


a
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV444P10")
z_ConvertFormat(pixel_type="RGBP")
ConvertToRGB24()
z2=last


If you add ConvertBits(10) after ConvertToPlanarRGB(), it's no longer lossless either

[zeropc]

AviSynth+ 3.5.0 has been released. (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.5.0)

The big, shiny new feature this time around: native support for Linux, macOS, and BSD. Full list of changes:

New: Native macOS support.


Nice ... Where can I get the macOS version? :)

[Richard1485]

There are build instructions here (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/docs/english/source/avisynthdoc/contributing/posix.rst) and a separate thread in this subforum for cross-platform support.

[pinterf]

As far as I know zimg (avsresize) has no special direct conversions between any formats at all. Bitdepth changes, colorspace changes and resolution changes are separate filters internally and it builds a filter graph automatically to do the conversion you want.
Thanks, I see. So the advantage there is simply not having an integer (e.g. 10 bit) intermediate result but rather a 32 bit float one?

[pinterf]

If I enable the internally float version for 10-14 bits, it can be a little bit slower* but of greater precision.
*no AVX implementation yet only SSE2/SSE4.1 so there is room for improvement to compensate the slowdown (which I think is not that much considering a whole big script)

Anyway, there are some RGBP->YUV444 enhancements in my development branch:
- Internal calculation method is changed to use floats for 10-14 bits as well (16 bit was already working like this) for greater precision
- much quicker AVX2 implementation for 10-16 bits (was: SSE2/SSE4)

[StainlessS]

BugRep:

From here[EDIT: LINK FIXED]:- https://forum.doom9.org/showthread.php?p=1728455#post1728455
@Martin53,

For your version StrReplace,

s=StrReplace("abc","","1")

ie replace "" with "1",
Causes silent crash due to stack exhaustion.
(Problem due to FindStr("abc","") returning result 1 [bit of a daft result, 0 not found would perhaps be more sensible]).
Should return source string s where StrLen(find)==0

Same here for Avs+ ReplaceStr().

Colorbars
S=ReplaceStr("hello","","1")
Subtitle(s)


EDIT: Script fix for StrReplace()


Function StrReplace(string base, string sought, string rep) { # http://avisynth.nl/index.php/HDColorBars
pos = FindStr(base, sought)
return (sought=="")||(pos==0)?base:StrReplace(LeftStr(base,pos-1)+rep+MidStr(base,pos+StrLen(sought)),sought,rep)
}


EDIT: Maybe this line on Wiki could stand some attention [meaning is inverted]:- http://avisynth.nl/index.php/Internal_functions#ReplaceStr
sig if false (the default), search is case-sensitive; if true, search is not case-sensitive.
EDIT: By the way, RT_Stats RT_StrReplace has default Sig=True, but of course choice is yours.

[StainlessS]

New types.h prevents plugin compile on older versions of visual studio [missing header files].
Mine is VS 2008 Express with Windows SDK 7.0.

Previous Types.h

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll

#ifdef __cplusplus
#include <cstddef>
#else
#include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef unsigned int Pixel32;
typedef unsigned char BYTE;

// Audio Sample information
typedef float SFLOAT;

#ifdef __GNUC__
typedef long long int INT64;
#else
typedef __int64 INT64;
#endif

#endif //AVS_TYPES_H


New one

#ifndef AVS_TYPES_H
#define AVS_TYPES_H

// Define all types necessary for interfacing with avisynth.dll
#include <stdint.h>
#include <stdbool.h>
#ifdef __cplusplus
#include <cstddef>
#else
#include <stddef.h>
#endif

// Raster types used by VirtualDub & Avisynth
typedef uint32_t Pixel32;
typedef uint8_t BYTE;

// Audio Sample information
typedef float SFLOAT;

#endif //AVS_TYPES_H

What is minimum compiler/SDK required for plugin builds for Avs+ and avs Std v2.60 using avs+ headers.

(You can probably get headers from eg VS 2017 community)

EDIT: stdint.h on github:- https://github.com/glfw/glfw/blob/master/deps/vs2008/stdint.h

[qyot27]

We dropped VS2008 ages ago. stdint and stdbool are part of C99, which Microsoft wasn't sufficiently compliant with until VS2013 (2015 added more support for C99). That's probably the earliest for plugins (although the core requires at least¹ VS 2015).

¹std::filesystem is a C++17 feature, but it looks like VS 2015 might have added it early.

[StainlessS]

So plugins also will not compile now with avs+ headers and older compiler, guess that means loads of plugins
will now revert to avs Std headers. [EDIT: Ones that only support v2.60 std colorspaces anyway, and that is most plugins]

EDIT: One plugin (by someone else) that I fixed up (maybe Watermark plugin not sure) used stdint.h and simply adding that
to include directory worked just fine, I have not as yet found the (M$) stdbool.h and dont know if adding that to include
would cause any problems, I do have VS2015, VS2017 community and also 2019, I guess I could get stdbool from any one of them,
but have no idea if would work properly for vs2008.
I have not really used either 2015, or 2017 or 2019, did not like the telemetry and need to register thing [I also like the ability to compile on XP on occasion, hence VS2008].

std::filesystem is a C++17 feature
Not though neccesary for plugins ???

EDIT: If avs+ headers are supposed to be compatible with avs std, then would not stdtype.h and stdbool.h only be needed by the core and not for [any/most] plugins ???

[pinterf]

So plugins also will not compile now with avs+ headers and older compiler, guess that means loads of plugins
will now revert to avs Std headers. [EDIT: Ones that only support v2.60 std colorspaces anyway, and that is most plugins]

EDIT: One plugin (by someone else) that I fixed up (maybe Watermark plugin not sure) used stdint.h and simply adding that
to include directory worked just fine, I have not as yet found the (M$) stdbool.h and dont know if adding that to include
would cause any problems, I do have VS2015, VS2017 community and also 2019, I guess I could get stdbool from any one of them,
but have no idea if would work properly for vs2008.
I have not really used either 2015, or 2017 or 2019, did not like the telemetry and need to register thing [I also like the ability to compile on XP on occasion, hence VS2008].


Not though neccesary for plugins ???

EDIT: If avs+ headers are supposed to be compatible with avs std, then would not stdtype.h and stdbool.h only be needed by the core and not for [any/most] plugins ???

Header and thus plugins are still compatible, the only thing that we are using standard types instead of Microsoft specific ones, e.g. int64_t instead of __int64. You can simply typedef them if you insist on your old compiler in 2020.
typedef __int16 int16_t;
typedef unsigned __int16 uint16_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;

[StainlessS]

What is it that is required from stdbool.h, similar easy fix ?

[also need edit avs+ types.h whenever updated]

[pinterf]

What is it that is required from stdbool.h, similar easy fix ?

[also need edit avs+ types.h whenever updated]
Dunno, probably I put a check in the header against compiler version and define those types if compiler is Microsoft and compiler version is below a specific value. (A conditional ifdef'd section for typedefing the new types mentioned above)

[StainlessS]

Cheers P.

EDIT: Maybe stdbool.h for C interface, C does not have bool.

[qyot27]

Considering that a refusal to update from outdated compilers was one of the main reasons AviSynth+ was started in the first place, I don't consider that a convincing argument. Requiring C99 is not an unreasonable baseline in any way, shape, or form.

VS2013 is 7 years old at this point (the C99 standard itself is 21 years old), and systems that can't run at least that version are in a very small minority. That's not 'the runtime of vc2013', required to use stuff it produces, that's the compiler itself. Most devs interested in keeping their plugins up-to-date with AviSynth+ are not on Pentium IIIs running Windows XP.

The alternatives are Clang-cl, use the MSVC Build Tools without the IDE (https://docs.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=vs-2019) or in conjunction with non-branded VSCode (https://vscodium.com/) (probably; still requires a newer CPU/OS, though), or switch the plugin to the C interface and build with GCC.

C++17 features aren't used in the headers, no.

[StainlessS]

I understand that Avs+ core requires recent compiler and have no problem with that.
But seems that one should require later version compiler for plugins, for no other reason than "it is hip" to do so,
I dont wanna update just because it is fashionable.
I mainly now use VS2008 on W7x64 Q9550, sometimes use XPx64 on quad core Q6600, got rid of my PIII's some time ago, I have one P4 XP32.
I also on occasion use VS2008 x86 on W10x86(Baytrail) Tablet/Laptop 2_in_1 thingy, with only 2GB RAM, 32GB storage, no way I am gonna use 2015, 2017 or 2019 on that.
[I also have x64 4GB RAM 64GB storage CherryTrail W10, dont want to swamp that with 2015/17/19 either]

EDIT: Of course the worst thing is that existing plugin source will no longer compile using the compilers that they were developed with
(unless you switch to avs 2.60 std header, making all of the avs+ compatible header stuff a pointless exercise).

EDIT: OK, reverted to older Avs+ headers, can compile again.

[qyot27]

Dunno, probably I put a check in the header against compiler version and define those types if compiler is Microsoft and compiler version is below a specific value. (A conditional ifdef'd section for typedefing the new types mentioned above)
The issue isn't so much the absence of those types, it's that for the AviSynth+ core to properly use stdint, #include <stdint.h> is in the avs/types.h header. So anyone wanting to use versions of MSVC prior to 2013 to build plugins will have it choke on the header include.

It'd be something like this:
#include "config.h"

// Define all types necessary for interfacing with avisynth.dll
#if defined(AVS_WINDOWS)
#if _MSC_VER >= 1800 // C99 stdint.h is only supported by MSVC 2013 or higher
#include <stdint.h>
#include <stdbool.h>
#endif
#else // AVS_POSIX
#include <stdint.h>
#include <stdbool.h>
#endif

I don't personally care about us maintaining compatibility with versions older than MSVC 2013, especially since the core won't even build with 2013. But that block is less obnoxious than us not moving away from MSVC types and instead using a hideous block of #defines to hammer things into working on non-Windows vs. just using standard types and stdint.h.

[StainlessS]

I'm currently just about done with mod to DDigit metrics text renderer for plugin devs, implemented for all Avs+ colorspaces.

I'de just like to check if I'm doin' it right, in particular the chroma calcs.

where, output 32 bit float result required.
c1 is YUV-Y in 0->255 range [EDIT: Text color as YUV 8 bit]
c2 is YUV-U in 0->255 range
c3 is YUV-V in 0->255 range

const float cxy =(float)(c1/255.0);
const float cxu =(float)((c2-127.5)/255.0); # mid 127.5 rather than 128 (seems right for -0.5 to +0.5)
const float cxv =(float)((c3-127.5)/255.0);

Or Maybe

const float cxy =(float)(c1/255.0);
const float cxu =(float)((c2-128)/255.0); # mid 128, possible (but unlikely) lob sided out of -0.5, 0.5 range
const float cxv =(float)((c3-128)/255.0);

Or Limit
const float cxy =(float)(c1/255.0);
const float cxu =(float)(max(c2-128,-127)/255.0); # mid 128, limited
const float cxv =(float)(max(c3-128,-127)/255.0);


Results look ok as above. [EDIT: maybe above first attempt is wrong, 2nd better, just ignore possible lob sidedness, or limit ??? (EDIT: I've changed to 128 limited)]
Thanx in advance.

EDIT: And for 8 bit BYTE RGB to 16 bit RGB48

int cx1=(c1<<8)|c1
int cx2=(c2<<8)|c2
int cx3=(c3<<8)|c3

and 8 bit BYTE RGB to Bpc RGB (10, 12, 14, 16)

int cls=Bpc-8,crs=8-cls;
int cx1=(c1<<cls)|(c1>>crs);
int cx2=(c2<<cls)|(c2>>crs);
int cx3=(c3<<cls)|(c3>>crs);


and 8 bit BYTE YUV to Bpc YUV (10, 12, 14, 16) [simple shift only]

int cxy =c1<<(Bpc-8)
int cxu =c2<<(Bpc-8);
int cxv =c3<<(Bpc-8);

[pinterf]

RGB is always full scale, the ranges should be stretched like
x_new = x_old * target_max / source_max


EDIT: And for 8 bit BYTE RGB to 16 bit RGB48

int cx1=(c1<<8)|c1
int cx2=(c2<<8)|c2
int cx3=(c3<<8)|c3


O.K. x*65535/255 is x*257 exactly


and 8 bit BYTE RGB to Bpc RGB (10, 12, 14, 16)

int cls=Bpc-8,crs=8-cls;
int cx1=(c1<<cls)|(c1>>crs);
int cx2=(c2<<cls)|(c2>>crs);
int cx3=(c3<<cls)|(c3>>crs);


O.K. Good approximation. I met this method earlier but I'm not using it. Now I have checked it again (see Python script)
This python script is showing that this approximation differs only by 1 from the ideal result. The integer mul-add-rounder-div is giving the same results as doing all as float (no difference). This latter method is not too fast, it has an integer division (which can be replaced by multiply using magic-number tricks but using float for precison is better)
When you are using this approximation for font colors, it's more than enough.
sourcebits=10
targetbits=16

sourcemax = (1 << sourcebits) - 1
half_for_rounding = sourcemax // 2
cls = targetbits - sourcebits
crs = sourcebits - cls

targetmax = (1 << targetbits) - 1

errcount_approx = 0
errcount_intmuldiv = 0
maxdiff = 0

for x in range(0, sourcemax):
# reference: float
float32 = int(float(x) * targetmax / sourcemax + 0.5)
approx = (x << cls) | (x >> crs)
intmuldiv = (x * targetmax + half_for_rounding) // sourcemax
intmuldiv_no_round = (x * targetmax) // sourcemax
if approx != float32:
print("FLT_APPROX_DIFF x = {0} approx = {1} exact = {2} intround = {3} intnoround = {4} ".format(x, approx, float32, intmuldiv, intmuldiv_no_round))
errcount_approx = errcount_approx + 1
diff = abs(approx - float32)
if diff > maxdiff:
maxdiff = diff
if float32 != intmuldiv : # or approx != intmuldiv_no_round''':
print("FLT_INT_DIFF x = {0} approx = {1} exact = {2} intround = {3} intnoround = {4} ".format(x, approx, float32, intmuldiv, intmuldiv_no_round))
errcount_intmuldiv = errcount_intmuldiv + 1

print("Difference count (approx): {0}, maxdiff: {1}".format(errcount_approx, maxdiff))
print("Difference count (intmuldiv): {0}".format(errcount_intmuldiv))

# from-to # of differences
# 8->10 42
# 8->12 56
# 8->14 42
# 8->16 0
#10->12 170
#10->14 234
#10->16 234





and 8 bit BYTE YUV to Bpc YUV (10, 12, 14, 16) [simple shift only]

int cxy =c1<<(Bpc-8)
int cxu =c2<<(Bpc-8);
int cxv =c3<<(Bpc-8);

O.K. YUV is always bit-shifting

[pinterf]

I'm currently just about done with mod to DDigit metrics text renderer for plugin devs, implemented for all Avs+ colorspaces.

I'de just like to check if I'm doin' it right, in particular the chroma calcs.

where, output 32 bit float result required.
c1 is YUV-Y in 0->255 range [EDIT: Text color as YUV 8 bit]
c2 is YUV-U in 0->255 range
c3 is YUV-V in 0->255 range

const float cxy =(float)(c1/255.0);
const float cxu =(float)((c2-127.5)/255.0); # mid 127.5 rather than 128 (seems right for -0.5 to +0.5)
const float cxv =(float)((c3-127.5)/255.0);

Or Maybe

const float cxy =(float)(c1/255.0);
const float cxu =(float)((c2-128)/255.0); # mid 128, possible (but unlikely) lob sided out of -0.5, 0.5 range
const float cxv =(float)((c3-128)/255.0);

Or Limit
const float cxy =(float)(c1/255.0);
const float cxu =(float)(max(c2-128,-127)/255.0); # mid 128, limited
const float cxv =(float)(max(c3-128,-127)/255.0);


Results look ok as above. [EDIT: maybe above first attempt is wrong, 2nd better, just ignore possible lob sidedness, or limit ??? (EDIT: I've changed to 128 limited)]
Thanx in advance.


Ideally integer values are never using PC full scale, limited range has no problems, 16-235 Y and 16-240 UV. Latter is definitely symmetric to 128, unlike if one is stretching U and V to 0..255 which will never be exact, since the theoretical center (127.5) does not exist in the integer domain.

Either you are using 32 bit float format with a simple division
For 8 bits:
Y' = Y / 255.0
U' = (U - 128) / 255.0
(replace 255 with the acture max_bit_depth_value)

Internally 8 bit colors (historically we can pass only 8 bit colors using integer parameters e.g. text color or BlankClip) are converted by using this method.

Or you can keep the convention that float formas are always full scale and map Y 16-235 to 0..1.0 and U,V 16-240 to -0.5..0.5

I'm planning rechecking all such occurences when YUV 32 bit floats are used in such a mixed bit depth environment, incl. Colorbars. My opinion that 32 bit float YUV should be treated always as full scale Y=0 to 1 and U/V=-0.5 to +0.5

[StainlessS]

Thanks P, I've taken snap of both posts for posterity, not really that important (I dont think) that absolutely correct, is only for metrics
and colornames chosen (from Colors_Rgb.avsi) were really only so I would not end up making up my own names, eg FishFinger_Orange or Putrid_Puce.
I'll try get as close as I can to optimum, but might just do close to best if it will impact speed too much.
I'm surprised that it was so easy to do the mod, only started it two days ago, still some tinkering to do.

IanB did a re-factor of Info.h where optionally len of text could be given rather than hunting nul term sentinel, this allowed me to write the
utility partner header InfoF.h which allows Info.h metrics text to have embedded control codes eg '\n' and '\r', perhaps a similar arrangment could be used
with your Text() filter (AKA SimpeText class), might also allow for color control codes so that plug progger could use multi-line anti-aliased Text() with better
control of text rendering, and eg sprintf type insertion of variables into strings, as used in eg RT_String().
For this to work properley, would ideally be implemented as a frame renderer rather than a filter [requiring MakeWriteable already done by caller], so as to be
able to control text placement, or maybe the InfoF.h style control with additional sprintf style var to string substitution could be done internally and so the
interface would need be implemented with varidaic args [think thats what them there things are called, same as RT_string(), RT_DebugF(), RT_Subtitle()
and a few more].
As currently implemented as a filter, Text() would not be ideal where placement of multiple strings in different frame positions is needed.

I implemented similar in thread "Avisynth CPP interface for C Proggers":- https://forum.doom9.org/showthread.php?p=1538557#post1538557
Some excerpts from that thread.
#include "Info.h"
// Plugin text rendering header from Avisynth v2.6, (Use Version of 17 April 2011, or later, bugs fixed, OK for v2.5+)
// Provides white only horizontal print at pixel coordinates, no formatting of any kind.
// Obtainable here (look for 'Info.h'):-
// http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/src/core/

#include "InfoF.h" // New in v0.2
// A companion to Info.h, provides screen formatted printing via embedded control codes.
// Also provides stubs for character coord printing as well as pixel coordinates.
// Formatting control codes:-
// '\n', Newline, positioning cursor 1 line down and at left edge of screen.
// '\r', Newline Special, moves 1 line down and positions cursor at on-entry X position.
// '\b', Backspace, obvious, not sure how useful this will be.
// '\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
// '\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
//
// DDigit() from which this header originates, provides horizontal & vertical print at both pixel
// and character coords, 16 color printing and screen formatting (eg '\n') control codes together
// with color control codes. Control codes, vertical print and colorspace code are all controlled
// via compiler directives and so can be excluded from the binary if not required.
//



// DrawFStr() Draw a Formatted string of text at character position, a user defined member function.
// As with all class members defined outside of the class, it is preceded by the class name and scope operator.

void __stdcall INTERNALNAME::DrawFStr(PVideoFrame &dst,int x,int y,const char *format, ...)
{
// This member function added in v0.2, adds BOTH string and screen formatting, eg '%f' for string and '\n' for screen.

// Firstly, string formatting, into the buffer implemented in the class instance, formatted_buf[FMT_BUFSZ].
va_list args;
va_start(args, format);
_vsnprintf(formatted_buf,FMT_BUFSZ-1, format, args);
va_end(args);

// The DrawFStrXXX fn's are implemented in the InfoF.h file and provide screen formatting, eg '\'n and '\t'.
// As string formatting has already been done above (eg floats etc turned to character strings), and the below
// DrawFStrXXX functions provide screen formatting, so full formatting is achieved on the video frame.
//
// Formatting control codes (as provided by InfoF.h):-
// '\n', Newline, positioning cursor 1 line down and at left edge of screen.
// '\r', Newline Special, moves 1 line down and positions cursor at on-entry X position.
// '\b', Backspace, obvious, not sure how useful this will be.
// '\f', Forward Space, again obvious, re-uses formfeed code for this. Again, maybe not so useful.
// '\t', Tab, @ character positions, every 4 characters.(relative screen LHS).
//
if(vi.IsPlanar()) DrawFStrPlanar(dst,x,y,formatted_buf);
else if(vi.IsYUY2()) DrawFStrYUY2(dst,x,y,formatted_buf);
else if(vi.IsRGB32()) DrawFStrRGB32(dst,x,y,formatted_buf);
else if(vi.IsRGB24()) DrawFStrRGB24(dst,x,y,formatted_buf);
}


From InfoF.h

void __stdcall DrawFStringPlanar(PVideoFrame &dst,int x,int y,const char *s,bool pix = true)
{ // Draw formatted string at pixel or character coords, pix == false = character coords
if(pix == false) {x *= 10; y *= 20;} // To Chars
int in_x = x; // REM x for '\r'
const unsigned char *se=(unsigned char*)s; // unsigned
while(*se) { // while, some to do
int n;
for(s=(char*)se; n = *se, n>=' ' && n <= 223; ++se); // Find end+1 of printable
int len = (int)((char*)se - s); // Len of printable
if (len) { // Some to print
DrawStringPlanar(dst,x,y,s,len); // do the biz
x += len * 10; // update x coord
} else { // Ctrl code OR nonsense;
if(n == '\n') {
x = 0; y+=20; // Newline, down 1, LHS
} else if (n == '\r') {
x = in_x; y +=20; // Newline Special, Down 1, orig x coord
} else if(n == '\b') {
x -= 10; // Backward Space
} else if (n == '\f') {
x += 10; // Forward Space
} else if (n == '\t') {
x+= ((4*10)-(x%(4*10))); // H-Tab (step 4)
}
++se; // skip ctrl code (and unknowns, outer loop detects nul sentinel)
}
}
}

void __stdcall DrawFStrPlanar(PVideoFrame &dst,int x,int y,const char *s)
{ // Formatted Print @ character coords
DrawFStringPlanar(dst,x,y,s,false);
}


From Avisynth CPP interface for C Proggers
Using plain white only text using Info.h with InfoF.h layout control and sprintf style arg substitution as from above function.
https://i.postimg.cc/grJTjV5J/Synth-Infoh.jpg (https://postimg.cc/grJTjV5J)

https://i.postimg.cc/7f78P1Gz/Chr-Set-Info.jpg (https://postimg.cc/7f78P1Gz)

A few frames from current DDigitTest dll
https://i.postimg.cc/qNS1NSPM/dd1.jpg (https://postimg.cc/qNS1NSPM)

https://i.postimg.cc/WtYgpgLs/dd2.jpg (https://postimg.cc/WtYgpgLs)

https://i.postimg.cc/njc9pc3s/dd3.jpg (https://postimg.cc/njc9pc3s)

https://i.postimg.cc/4mh7J0Q1/dd4.jpg (https://postimg.cc/4mh7J0Q1)

[pinterf]

So positioning is done like left-right-down joystick movements between prints?
I'm working on further Text filter features which were in my mind but were omitted in the final rush of making linux version work.
Such cursor movements can probably be easily added without much speed penalty. (Though I'm sure that it's not this filter which is the bottleneck, I did some profiling and check of the generated asm code just for couriosity)
You noticed well that I have removed the string length argument, because it was of no use actually.

[StainlessS]

left-right-down joystick
Sort of yes.
I particularly like the ability to return to 'on-entry' X position, so can if required format text with a horizontal Offset to all lines (either pixel or char position).
EDIT: You can use only '\r' n/l special and change on-entry X position and, move the whole damn lot over left or right and maintain all layout.
I also use '\a' as color control code with additional chr code for color, but left one ctrl code free for any future expansion,
(8=\b=backspace, 9=\t=tab, 10=\n=newline, 11=free['\v' I think, cant remember, maybe vertical tab], 12='\f'=forward space, 13=\r=NewLineSpecialOnEntry-X)

You noticed well

Yep, Nobody Expects The Spanish Inquisition. :)

EDIT: From DDigitTest

if(!mono) {
char *ahi=(a1>235||a2>235||a3>235)?"\aA":"\aB";
char *blo=(b1<16||b2<16||b3<16)?"\a6":"\aB";
sprintf(buf,
"\b\b\b\b\f\bTesting Control & Color Codes:-\n\n\r"
"Frame: %-7u( \a2Red\a- / \a4Green\a- / \a1Blue\a- )\r"
" \a8Fred: (%7.2f /%7.2f /%7.2f )\r"
" Ted: (%7.2f /%7.2f /%7.2f )\r"
" Bill: ( %3d / %3d / %3d )\r"
" Ben: ( %3d / %3d / %3d )\r"
" %sJack\aB: ( %s%3d\aB / %s%3d\aB / %s%3d\aB )\r"
" %sJill\aB: ( %s%3d\aB / %s%3d\aB / %s%3d\aB )\r"
"\n\n\a-EVERYTHING VISIBLE (incl this) is 1 single printed string\n"
"\t\t\t\t\aEDATA is RANDOM ONLY"
,n,
rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,
rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,
rand()&255,rand()&255,rand()&255,rand()&255,rand()&255,rand()&255,
ahi,(a1>235)?ahi:"\aB",a1,(a2>235)?ahi:"\aB",a2,(a3>235)?ahi:"\aB",a3,
blo,(b1<16)?blo:"\aB",b1,(b2<16)?blo:"\aB",b2,(b3<16)?blo:"\aB",b3
);
} else {
char *ahi=(a1>235||a2>235||a3>235)?"\aV":"\aO";
char *blo=(b1<16||b2<16||b3<16)?"\aV":"\aO";
sprintf(buf,
"\b\b\b\b\f\bTesting Control & Mono Codes:-\n\n\r"
"Frame: %-7u( \aQBob\a- / \aQAlice\a- / \aQDave\a- )\r"
" \aTFred: (%7.2f /%7.2f /%7.2f )\r"
" Ted: (%7.2f /%7.2f /%7.2f )\r"
" Bill: ( %3d / %3d / %3d )\r"
" Ben: ( %3d / %3d / %3d )\r"
" %sJack\aO: ( %s%3d\aO / %s%3d\aO / %s%3d\aO )\r"
" %sJill\aO: ( %s%3d\aO / %s%3d\aO / %s%3d\aO )\r"
"\n\n\a-EVERYTHING VISIBLE (incl this) is 1 single printed string\n"
"\t\t\t\t\aODATA is RANDOM ONLY"
,n,
rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,
rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,rand()*255.0/RAND_MAX,
rand()&255,rand()&255,rand()&255,rand()&255,rand()&255,rand()&255,
ahi,(a1>235)?ahi:"\aO",a1,(a2>235)?ahi:"\aO",a2,(a3>235)?ahi:"\aO",a3,
blo,(b1<16)?blo:"\aO",b1,(b2<16)?blo:"\aO",b2,(b3<16)?blo:"\aO",b3
);
}
AStr(dst, 4, 0, buf);


EDIT:
DDigit / RT_Subtitle(), also has 16 shades of grey, but I'm not altogether happy with the dark ones on eg black background,
trying to figure out a way to brighten background for those, and with little overhead and hopefully no additional code path.
https://i.postimg.cc/Ffj9P1sM/c-00.jpg (https://postimg.cc/Ffj9P1sM)

Here is code for RGBPS and RGBAPS

} else if(ComponentSize==4) {
if (RGB && Planar) {
#if (defined DDIGIT_ENABLE_SUPPORT_RGB && defined DDIGIT_ENABLE_SUPPORT_PLANAR)
const int pitch = PitchArr[0];
const float cx1=(float)(c1/255.0);
const float cx2=(float)(c2/255.0);
const float cx3=(float)(c3/255.0);
const float cxArr[3]={cx2,cx3,cx1};
for(int pln=0;pln<=2;++pln) {
BYTE *dp=WrPtrArr[pln] + xx*4 + yy*pitch;
const float cx = cxArr[pln];
for (int ty = tytop; ty < tybot;++ty,dp += pitch) {
float* rp = (float*)dp;
unsigned int fbm= FontNum[ty] << txlft;
for (int tx = txlft; tx < txrgt; ++tx,++rp, fbm<<=1) {
if (fbm & 0x8000) { // Character Foreground SET Pixel ?
rp[0] = cx; // Set Luma Foreground Pixel
} else {
DD4_BGF_RGB(rp[0]); // fade background
}
}
}
}
#endif // (defined DDIGIT_ENABLE_SUPPORT_RGB && defined DDIGIT_ENABLE_SUPPORT_PLANAR)



EDIT: And the Fade background thing (opt 0=7/8 opt 1=3/4, there are 5 options) [DD4_BGF_RGB(rp[0]); // fade background]

#elif (DDIGIT_BACKGROUNDFADE == 1)
// Multiply background by 3/4
#if(0)
// Old 8 bit before simplify
#define DD_BGF_Y(dat) (dat)=(unsigned char) (((((dat)-16)*3)>>2)+16)
#define DD_BGF_C(dat) (dat)=(unsigned char) (((((dat)-128)*3)>>2)+128)
#define DD_BGF_RGB(dat) (dat)=(unsigned char) (((dat)*3)>>2)
#else
// ComponentSize=1 (8 bit)
// (dat*3>>2)-(16*3>>2)+16 == (dat*3>>2)+4
#define DD_BGF_Y(dat) (dat)=(unsigned char) ((((dat)*3)>>2)+4)
// (dat*3>>2)-(128*3>>2)+128 == (dat*3>>2)+32
#define DD_BGF_C(dat) (dat)=(unsigned char) ((((dat)*3)>>2)+32)
#define DD_BGF_RGB(dat) (dat)=(unsigned char) (((dat)*3)>>2)
// ComponentSize=2
// (dat*3>>2)-(64 *3>>2)+ 64 == (dat*3>>2)+ 16 10 bit
// (dat*3>>2)-(256 *3>>2)+ 256 == (dat*3>>2)+ 64 12 bit
// (dat*3>>2)-(1024*3>>2)+1024 == (dat*3>>2)+ 256 14 bit
// (dat*3>>2)-(4096*3>>2)+4096 == (dat*3>>2)+1024 16 bit
#define DD2_BGF_Yadd(bpc) (4<<((bpc)-8)) // Precalc add = (4<<(BitsPerComponent-8))
#define DD2_BGF_Y(dat,add) (dat)=(unsigned short) (((dat)*3>>2)+(add)) // Precalc add = (4<<(BitsPerComponent-8))
// (dat*3>>2)-( 512 *3>>2)+ 512 == (dat*3>>2)+ 128 10 bit
// (dat*3>>2)-( 2048 *3>>2)+ 2048 == (dat*3>>2)+ 512 12 bit
// (dat*3>>2)-( 8192 *3>>2)+ 8192 == (dat*3>>2)+ 2048 14 bit
// (dat*3>>2)-(32768 *3>>2)+ 32768 == (dat*3>>2)+ 8192 16 bit
#define DD2_BGF_Cadd(bpc) (32<<((bpc)-8)) // Precalc add = (32<<(BitsPerComponent-8))
#define DD2_BGF_C(dat,add) (dat)=(unsigned short) (((dat)*3>>2)+(add)) // Precalc add = (32<<(BitsPerComponent-8))
#define DD2_BGF_RGB(dat) (dat)=(unsigned short) ((dat)*3>>2)
// ComponentSize=4
#define DD4_BGF_Y(dat) (dat)=(float)((dat)*(3.0/4.0))
#define DD4_BGF_C(dat) (dat)=(float)((dat)*(3.0/4.0))
#define DD4_BGF_RGB(dat) (dat)=(float)((dat)*(3.0/4.0))
#endif
#elif (DDIGIT_BACKGROUNDFADE == 2)

[pinterf]

In Text \n (the control character, not the literal human visible \n) is line separator. When horizontal alignment is set to "center" each separated lines will be centered individually.

[StainlessS]

EDIT:
Yep, the centering thing would upset things

Here my code in DDigit, uses actual codes, RT_Subtitle (If I remember correctly) will take either real control code or human visible eg "\n" or "\a0"
and converts to real control codes "\n" to Chr(10) and then "\a0" to Chr(7)+Chr(48), for DDigit, also RT_Subtitle() does sprintf style arg substitution, and detects whether not will be wholly off frame (misses call to DDigit
when so, DDigit can do that itself, but RT_Subtitle is parsing anyways so avoids duplicate parsing when not necessary). Only on frame subs will be processed
by DDigit via RT_Subtitle. I have script that scroll quite long texts and in real time upwards, downwards, or Kareoke style, and DDigit only gets the valid on frame
text to bother with.

some ctrl code stuff

for (int s_ix=0;s_ix<length ;++s_ix) {
num=((unsigned char*)s)[s_ix]; // Cast to speed up ctrl code detect
#ifdef DDIGIT_ENABLE_SUPPORT_CONTROL_CODES
if(num <= '\r' && num >= '\a' && (ctrl)) { // Control Character ?
if(num == '\a') { // Color control character ?
int cc=s[s_ix+1];
if(cc >= 'a' && cc <= 'v')
cc -= ('a' - 'A'); // Upper Case
char *colstr="0123456789ABCDEFGHIJKLMNOPQRSTUV-!*";
char * ccp=colstr;
while(*ccp && *ccp != cc)
++ccp;
if(*ccp) {
++s_ix; // Color control code parsed with valid arg, skip ctrl code.('\a')
cc=int(ccp - colstr);
if(cc>31) {
if(cc==32) { // '-' = ddigit default color
cc = CMapdef[cmapix][0]; // Default
} else if(cc==33) { // '!' = ddigit hilite
cc = CMapdef[cmapix][1]; // Hilite
} else if(cc==34) { // '*' = Original starting color
cc=color;
}
}

c1=(RGB) ? DDigit_Cmap_RGB[cc] : DDigit_Cmap_YUV[cc];
c3=c1 & 0xFF; c1>>=8U;
c2=c1 & 0xFF; c1>>=8U;
c1 &= 0xFF;
continue;
}
} else if (!vert) { // Horizontal
switch(num) {
case '\n': // NewLine
x = 0; // Screen left
y += DDIGIT_CHAR_HEIGHT; // Next line down
continue;
case '\r': // 1 line down and back to original X position
x = in_x; // Below starting X input postion
y += DDIGIT_CHAR_HEIGHT; // Next line down
continue;
case '\t': // Horizontal Tab
x+= ((DDIGIT_TABCNT*DDIGIT_CHAR_WIDTH)-(x%(DDIGIT_TABCNT*DDIGIT_CHAR_WIDTH)));
continue;
case '\f': // Forward Space
x += DDIGIT_CHAR_WIDTH; // 1 char right
continue;
case '\b': // BackSpace
x -= DDIGIT_CHAR_WIDTH; // 1 char left
continue;
}
} else { // Vertical



EDIT: Try this script, no really try it. [Std v2.6 colorspaces only]

avi = RT_FSelOpen("Please select an AVI file",Filt="*.AVI|*.AVI")
Assert(avi.IsString,"RT_FSelOpen: Error="+String(avi))
AVISource(AVI)
txt = RT_FSelOpen("And now select a Text file",Filt="*.txt|*.txt")
Assert(txt.IsString,"RT_FSelOpen: Error="+String(txt))
Txt=RT_ReadTxtFromFile(txt)
Lines=RT_TxtQueryLines(Txt)
# config
DELAY=100
ALIGN=1 # As Numeric KeyPad
SCROLL=0 # 0 = Upwards : 1 = Downwards : 2 = Right to Left : 3 = Left to right : 4 = Karaoke
#
ORG=Last
Last=(SCROLL==4)? ORG.Blankclip(height=80) : Last
CMD_0 = """RT_Subtitle("%s",Txt,align=ALIGN,y=height+DELAY-current_frame,expx=true,expy=true)"""
CMD_1 = """RT_Subtitle("%s",Txt,align=ALIGN,y=-(Lines*20+DELAY) + current_frame,expx=true,expy=true)"""
CMD_2 = """RT_Subtitle("%s",Txt,align=ALIGN,x=width+DELAY-current_frame,expx=true,vcent=true)"""
CMD_3 = """RT_Subtitle("%s",Txt,align=ALIGN,x=-(width+DELAY)+current_frame,expx=true,vcent=true)"""
CMD_4 = """RT_Subtitle("%s",Txt,align=ALIGN,y=height+DELAY-current_frame,expx=true,expy=true)"""
CMD_5 = """RT_Subtitle("BAD SCROLL COMMAND (0->4)")"""
CMD = (SCROLL<0 || SCROLL>4) ? CMD_5 : Select(Scroll,CMD_0,CMD_1,CMD_2,CMD_3,CMD_4)
ScriptClip(CMD)
Return (SCROLL==4)? StackVertical(ORG,Last) : Last

here a little centered scrolling text that I had handy (its not that good).
https://i.postimg.cc/5jtpfPk6/RT-SCROLLDEMO-00.jpg (https://postimg.cc/5jtpfPk6)


EDIT: Also take peek at this:- https://forum.doom9.org/showthread.php?t=177366

EDIT:

RT_Subtitle(clip source,string format,dat1,...,datn,int "align",int "x","y",bool "vcent"=false,bool "expx"=false,bool "expy"=false,int "esc"=1)
Standard filter function.
This function is a standard filter graph function, not a runtime/compile time function.
v2.5 plugin dll limited to v2.58 colorspaces.
Prints formatted text to clip frame using Avisynth Info.h source font (monospaced) and DDigit font renderer, faster than using
Subtitle system fonts. The unnamed 'format' string and optional unnamed 'dat' args are used to construct the text string that is
printed on frame, uses C/CPP printf() style formatting. The args 'align', 'x', and 'y', work in a similar fashion to
Avisynth Subtitle()
expx and expy control whether x and y are same as in SubTitle when eg y = -1 (vertical centered) or y=height (bottom aligned),
or as explicit coords when expy = true.

esc int, default 1. (0 -> 2). Escape code processing eg '\n' converted to NewLine.
0 = No Escape code processing.
1 = Esc codes processed only in format string. (Default)
2 = Esc codes processed in both format and data strings.

RT_Subtitle(c,"Hello there %s and %s.\nGoodbye %d.","Fred","Ted",2013,align=4,x=100,vcent=true)
would print

Hello there Fred and Ted.
Goodbye 2013.

at x pixel position 100 and y pixel position centered, the vcent=true will vertical center a block of text (align=4 or 5 or 6),
whereas Subtitle() starts at centred position and prints downwards from there (as default vcent=false).

Align, default = 7 ie top left (as on numeric keypad).
x and y allow modification of alignment, eg x= -1, centers x at mid point, x=width, would right align,
y=height would align at bottom of frame.
It is necessary to specify the optional arg names of x,y,align and vcent etc, as the dat args can take 0 or more variables
of any type, so Avisynth cannot tell when the list of dat args ends and the named optional args begins. I did
try to use the dat args last but Avisynth seems to get confused when you use dat= etc, it throws an error
saying something like "dat arg specified more than once", even if it was not.
printf Format spec here:- http://msdn.microsoft.com/en-us/library/56e442dc%28v=vs.71%29.aspx
NOTE, the only support for printing Bool variables is %s as string, ie prints "True" or "False".
To print only 1st letter of type bool:- ColorBars.KillAudio.RT_Subtitle("%.1s",true) prints 'T'

Formatting supported %[flags] [width] [.precision] type
flags, one of "-,+,0, ,#"
width, integer, "*" supported (width supplied via dat arg).
Precision, integer, "*" supported (precision supplied via dat arg).
type,
"c,C,d,i,o,u,x,X", Integer type, c,C=character, d,i=signed, o,u,x,X=unsigned.
"e,E,f,g,G", Floating point type
"s,S", String type (also Bool).

eg
colorbars.killaudio
FMT="%d ] \a%cCurrent_Frame=\a-%d"
ALPHA="0123456789ABCDEFGHIJKLMNOPQRSTUV-!"
ScriptClip("""
RT_Subtitle(FMT,current_frame,RT_Ord(ALPHA,(current_frame/25)%32+1),current_frame,align=5)
""")
return last

In the above example you see the sequence "\a%c" where %c is replaced with a character from ALPHA, "\a0"
selects color 0, "\aV" selects the last color (31). "\a-" selects the default color, and "\a!" selects
the hilite color. You can in Scriptclip() select colors programmatically, perhap selecting red to show an
error or bad metrics condition. The initially selected color will always be the default color (white).
Ripped from DDigit source code:
// Color control codes as strings. ASCII Code of Final char
#define DDIGIT_CC_DARKGRAY "\a0" // 48
#define DDIGIT_CC_DODGERBLUE "\a1" // 49
#define DDIGIT_CC_ORANGERED "\a2" // 50
#define DDIGIT_CC_ORCHID "\a3" // 51
#define DDIGIT_CC_LIME "\a4" // 52
#define DDIGIT_CC_AQUAMARINE "\a5" // 53
#define DDIGIT_CC_YELLOW "\a6" // 54
#define DDIGIT_CC_WHITE "\a7" // 55
#define DDIGIT_CC_SILVER "\a8" // 56
#define DDIGIT_CC_CORNFLOWERBLUE "\a9" // 57
#define DDIGIT_CC_ORANGE "\aA" // 65
#define DDIGIT_CC_PLUM "\aB" // 66
#define DDIGIT_CC_CHARTREUSE "\aC" // 67
#define DDIGIT_CC_POWDERBLUE "\aD" // 68
#define DDIGIT_CC_GOLD "\aE" // 69
#define DDIGIT_CC_GAINSBORO "\aF" // 70
#define DDIGIT_CC_Y_0 "\aG" // 71
#define DDIGIT_CC_Y_1 "\aH" // 72
#define DDIGIT_CC_Y_2 "\aI" // 73
#define DDIGIT_CC_Y_3 "\aJ" // 74
#define DDIGIT_CC_Y_4 "\aK" // 75
#define DDIGIT_CC_Y_5 "\aL" // 76
#define DDIGIT_CC_Y_6 "\aM" // 77
#define DDIGIT_CC_Y_7 "\aN" // 78
#define DDIGIT_CC_Y_8 "\aO" // 79
#define DDIGIT_CC_Y_9 "\aP" // 80
#define DDIGIT_CC_Y_A "\aQ" // 81
#define DDIGIT_CC_Y_B "\aR" // 82
#define DDIGIT_CC_Y_C "\aS" // 83
#define DDIGIT_CC_Y_D "\aT" // 84
#define DDIGIT_CC_Y_E "\aU" // 85
#define DDIGIT_CC_Y_F "\aV" // 86
#define DDIGIT_CC_HILITE "\a!" // 33
#define DDIGIT_CC_DEFAULT "\a-" // 45

In color codes eg "\aV", the 'a' is strictly case sensitive however the color number ('V') can be upper ot lower case.
In addition to color control codes, the filter will accept "\n" (NOT "\N", strictly case sensitive) or "\r"
as newline, and "\f" as forward space (move 1 right without printing anything), no other control codes are supported.
"\t" and TAB control codes are converted to a single space, I could think of no sensible way to handle tab when center or
right aligned, if there is a demand, I could maybe handle tab for left alignment only and replace with single space
for other alignment.
To embed a single BackSplash ("\") into the format string or even an argument dat (when esc=2) string you must insert a double
BackSlash ie "\\". To embed a single percent character ("%") into a format string, you must embed a double percent
sequence ie "%%". Reason is that such characters are used for formatting eg "%f" flags a float arg to embed into
the string and eg "\n" would mean insert newline into string.
Note, the colored text is not great in YV12 and quite awful in YV411, try to avoid YV411 at all times,
tis truly nasty.
To Print contents of multiline text file on frame:
AVISource("D:\AVS\TEST.AVI")
S=RT_ReadTxtFromFile("test.txt")
Scriptclip("""RT_Subtitle("%s",S,align=5,vcent=True)""")
return last

As can be seen from above example, you can also use eg Chr(10) (in the file) instead of "\n" or Chr(13), or Chr(13)+Chr(10)
instead of "\r\n" with identical results, CR, NL and CR/NL pairs are internally replaced by a single Chr(10).
To Print contents of multiline text file on frame, Scrolling upwards as for end credits:
AVISource("D:\AVS\TEST.AVI").ConvertToRGB32()
S=RT_ReadTxtFromFile("D:\avs\avi\test.txt")
DELAY=100
Scriptclip("""RT_Subtitle("%s",S,align=5,y=height+DELAY-current_frame,expy=true)""")

The above example uses the "expy" arg, which tells the filter to NOT interpret y == -1 as screen vertical
center align and to NOT interpret y=height as bottom aligned. ExpX does the same for the x arg. If you change
above to ExpY=false, as the text scrolls on screen and again when text scrolls off top of frame, there will be
a single frame where y==height OR y==-1, will align the text an cause a glitch in the video clip.
You could also embed eg color control codes into any above such scrolling text file for your amusement, eg
embedding "\a!" into the text file would switch on Hi-Lite-ed text. [needs esc=2 for esc codes in data strings]
If you want you can run above script with this text file as "test.txt" and because it has color control codes
embedded into it (eg the ripped DDigit source code earlier) so it will show the file, some lines of which will be
colored. This text file has NOT been prepared for that particular reason but may demo the embedded color codes.
RT_Subtitle() has the advantage of not requiring string memory as the string is created internally and
released on plugin destruction, whereas SubTitle() within ScriptClip will keep accumulating string memory
which is not released until Avisynth closes. Of course any eg concatenated strings supplied to RT_Subtitle
will be accumulated unless eg assigned to string variable external to Scriptclip.
The RT_Subtitle filter is intended to be used in providing on-frame metrics in a script, and not for final
output, use SubTitle() for that.
For any script using standard Subtitle() for metrics, it would not be at all surprising if that script were
to double (or more) in speed when replaced by RT_Subtitle, it really is quite light weight in comparison.


EDIT: Oops, RT_Subtitle Does not process '\r' as described, I did not know how to handle with centering, and so treat either "\r" or "\n" or "\r\n" or even "\n\r" (ctrl code or human readable I think) as newline ctrl code 10.
DDigit handles as described, but RT_Subtitle converts to Chr(10) before it gets there.

[StainlessS]

I get slightly different result from Avs conversion of your (pinterf post #5211) Python script. [assuming that 10->16 234 was correct]
I have added an alternative method of the muldiv whotsit (It dont seem any better than muldiv, at least with the numbers tried, it should though be better occasionally).
Hope I did conversion from Python right.


/* Python AVS script results
# from-to # of differences approx intmuldiv altmuldiv
# 8->10 42 42 0 0
# 8->12 56 56 0 0
# 8->14 42 42 0 0
# 8->16 0 0 0 0
#10->12 170 170 0 0
#10->14 234 234 0 0
#10->16 234 233 1 1

10 -> 16

FLT_APPROX_DIFF x = 818 ALT = 52402 approx = 52403 exact = 52402.000000 intround = 52402 intnoround = 52402
FLT_APPROX_DIFF x = 819 ALT = 52466 approx = 52467 exact = 52466.000000 intround = 52466 intnoround = 52466

*ALT_APPROX_DIFF x = 820 ALT = 52530 approx = 52531 exact = 52531.000000 intround = 52530 intnoround = 52530 ***
!FLT_INT_DIFF x = 820 ALT = 52530 approx = 52531 exact = 52531.000000 intround = 52530 intnoround = 52530 !!!
Altmuldiv and muldiv both wrong above, but approx gets it right

FLT_APPROX_DIFF x = 832 ALT = 53299 approx = 53300 exact = 53299.000000 intround = 53299 intnoround = 53299
FLT_APPROX_DIFF x = 833 ALT = 53363 approx = 53364 exact = 53363.000000 intround = 53363 intnoround = 53363

Difference count (approx): 233, maxdiff: 1
Difference count (intmuldiv): 1
Difference count (altmuldiv): 1 maxdiff 1

*/

sourcebits=10
targetbits=16

sourcemax = BitLShift(1 , sourcebits) - 1
half_for_rounding = sourcemax / 2
cls = targetbits - sourcebits
crs = sourcebits - cls

targetmax = BitLShift(1,targetbits) - 1

errcount_alt = 0
errcount_approx = 0
errcount_intmuldiv = 0
maxdiff = 0
maxdiffalt = 0

for(x=0, sourcemax) {
# reference: float
float32 = int(float(x) * targetmax / sourcemax + 0.5)
approx = BitOr( BitLShift(x,cls) , BitRShiftL(x,crs))
intmuldiv = (x * targetmax + half_for_rounding) / sourcemax
intmuldiv_no_round = (x * targetmax) / sourcemax
altmuldiv = (x * targetmax * 2 + sourcemax) / (sourcemax*2) # new # EDIT: This ALWAYS produces exact same result as intmuldiv, ie no use at all.
if(altmuldiv != float32) {
RT_DebugF("*ALT_APPROX_DIFF x = %d ALT = %d approx = %d exact = %f intround = %d intnoround = %d ***",x,altmuldiv, approx, float32, intmuldiv, intmuldiv_no_round)
errcount_alt = errcount_alt + 1
diff = abs(altmuldiv - float32)
if (diff > maxdiffalt) {
maxdiffalt = diff
}
}
if(approx != float32) {
RT_DebugF(" FLT_APPROX_DIFF x = %d ALT = %d approx = %d exact = %f intround = %d intnoround = %d ",x,altmuldiv, approx, float32, intmuldiv, intmuldiv_no_round)
errcount_approx = errcount_approx + 1
diff = abs(approx - float32)
if (diff > maxdiff) {
maxdiff = diff
}
}
if(float32 != intmuldiv) { # or approx != intmuldiv_no_round''':
RT_DebugF("!FLT_INT_DIFF x = %d ALT = %d approx = %d exact = %f intround = %d intnoround = %d !!!",x, altmuldiv, approx, float32, intmuldiv, intmuldiv_no_round)
errcount_intmuldiv = errcount_intmuldiv + 1
}
}
RT_DebugF("Difference count (approx): %d, maxdiff: %d",errcount_approx, maxdiff)
RT_DebugF("Difference count (intmuldiv): %d",errcount_intmuldiv)
RT_DebugF("Difference count (altmuldiv): %d maxdiff %d",errcount_alt,maxdiffalt)

Return MessageClip("Done")

[pinterf]

I used // operator for integer division

[StainlessS]

Aint that exactly the same where two integers involved ???

EDIT: All these are int

intmuldiv = (x * targetmax + half_for_rounding) / sourcemax


EDIT: And approx is just bit shifts, no divide, but 233 rather than 234 diffs.

[pinterf]

In Python 3 the result is floating point

[StainlessS]

Maybe, and that is why you used integer divide, but not so in Avs,

Aint that exactly the same where two integers involved ???

EDIT: All these are int

intmuldiv = (x * targetmax + half_for_rounding) / sourcemax


EDIT: And approx is just bit shifts, no divide, but 233 rather than 234 diffs.

EDIT: Maybe altmuldiv is no better than intmuldiv, only where numbers involved, multiplier and divider are 2 ^ n - 1,
it should though be generally better [occasionally].


intmuldiv = (x * targetmax + (sourcemax/2)) / sourcemax # intermediate precision loss of least significant bit at stage (sourcemax/2)
altmuldiv = (x * targetmax*2 + sourcemax) / (sourcemax*2)


EDIT: Above is absolute rubbish, altmuldiv always produces same answer as intmuldiv.
Could only possibly work better if sourcemax is odd, and as ((x * targetmax*2) + sourcemax) would be odd, and (sourcemax*2) would be even
so would always lose the same least significant (odd) bit in the final result.
Arh well, it seemed like a good idea at the time.

[qyot27]

So, a general PSA:

In Windows 10, it is possible to actually set the locale to UTF-8 for the entire OS, the way basically every OS other than Windows handles this issue. Apparently this has been possible for close to two years. Doing so will allow AviSynth+ (and probably even classic 2.6, although I haven't tried) to handle international characters without any special workarounds like utf8=true or juggling MultiByteToWideChar/WideCharToMultiByte in the program loader.

[stax76]

Can be enabled at:

Time & Language > Language > Administrative Language > Language for non unicode programs > check UTF-8 checkbox > reboot

Works fine so far.

[pinterf]

Actually I was courious as well and was thinking about a build that would allow omitting 'utf8=true' parameters for Import, SubTitle, Text and AviSource and handle utf8 instead of ANSI.
I suppose classic substring and character position helper functions will not work as they did before for non-ascii-only strings

[foobar2000]

I have a problem regarding .avsi files, you can delete .avsi files during encoding (like by accident)

but you can't delete .dll during encoding (while in use), I'm using Simple x264 Launcher and I've been encoding something, and I deleted QTGMC.avsi but put it back later

the avs script requires QTGMC.avsi, does this (deleted but put it back) affect the output? it doesn't show errors, do I need to worry? thanks

or the .avsi will store and run in RAM once the task starts?

[stax76]

does this (deleted but put it back) affect the output? it doesn't show errors, do I need to worry?

It does not affect the output and you don't have to worry.

[r0lZ]

Can be enabled at:

Time & Language > Language > Administrative Language > Language for non unicode programs > check UTF-8 checkbox > reboot

Works fine so far.
At least one CLI tool crashes with an access violation when that option is enabled: MVCPlanes2OFS.exe (used indirectly by BD3D2MK3D). So, use that beta option with caution !

[stax76]

It has caused a small issue in the stable release of staxrip which I fixed by removing non ASCII chars from the code and adding an automated test to prevent it from happening again.

[Nico8583]

It has caused a small issue in the stable release of staxrip which I fixed by removing non ASCII chars from the code and adding an automated test to prevent it from happening again.
Hi, what kind of non ASCII chars have you removed from your app ? Thank you.

[stax76]

This one was shown in the crop dialog:

±

https://en.wikipedia.org/wiki/Plus%E2%80%93minus_sign


This was in the x265 dialog:

Level 1 + intra/inter modes, ref’s (https://x265.readthedocs.io/en/latest/cli.html#cmdoption-analysis-save-reuse-level)

Changed to ref's


A popular non ASCII char used in apps is this:

©

Using (C) instead.


I know that it's no problem and nothing wrong to use Unicode in apps, Microsoft usually works with Unicode files with BOM but the most popular way nowadays is UTF8 without BOM, I think it's the default everywhere in .NET Core. I usually prefer simple solutions, ASCII and UTF8 without BOM are compatible.

AviSynth headers are part of the staxrip source code so my test applies, it's pure ASCII.

[StainlessS]

Exist() is now broken in 3.5. [on folders]

z.avs

fn="D:\ME" # Directory this file is in
RT_DebugF("%s %s",Exist(fn),fn) # False
fn="D:\ME\z.avs" # This file
RT_DebugF("%s %s",Exist(fn),fn) # True
MessageClip ("Done")



00000265 0.13369642 [3052] RT_DebugF: False D:\ME
00000266 0.13383374 [3052] RT_DebugF: True D:\ME\z.avs


Note, (below in code block so that backslash dont disappear on-site)

"D:\ME\"

also fails, but then it always did [maybe not necessary to fix, current robust scripts will remove trailing slash before Exist() check on folder name with trailing slash].

Heads up, AvsInit.avsi now fails due to above [MACHINE conditional AutoLoad dll stuff].

EDIT: AviSynthPlus_3.4.0_20191020.exe Works ok, AvisynthPlus-r3.5test_20200207-filesonly.7z dont.

[pinterf]

Exist() is now broken in 3.5. [on folders]

z.avs

fn="D:\ME" # Directory this file is in
RT_DebugF("%s %s",Exist(fn),fn) # False
fn="D:\ME\z.avs" # This file
RT_DebugF("%s %s",Exist(fn),fn) # True
MessageClip ("Done")




00000265 0.13369642 [3052] RT_DebugF: False D:\ME
00000266 0.13383374 [3052] RT_DebugF: True D:\ME\z.avs


Note, (below in code block so that backslash dont disappear on-site)

"D:\ME\"

also fails, but then it always did [maybe not necessary to fix, current robust scripts will remove trailing slash before Exist() check on folder name with trailing slash].

Heads up, AvsInit.avsi now fails due to above [MACHINE conditional AutoLoad dll stuff].

EDIT: AviSynthPlus_3.4.0_20191020.exe Works ok, AvisynthPlus-r3.5test_20200207-filesonly.7z dont.
Got it. Perfect task for home office.

[CrendKing]

I'm developing a AviSynth DirectShow filter (similar to what ffdshow does). As you may know, when seeking happens, the whole stream will reset its reference time to 0. This means when the filter recreate the frames, all its frame number starts from 0 again. This completely messes up AviSynth' internal cache, causing it to return those "old" frames (because they have the same old frame numbers).

What I'm asking is that is there an API to invalidate all frame buffers? I read from http://www.avisynth.nl/index.php/Filter_SDK/Cplusplus_API#VideoFrameBuffer:

a VideoFrameBuffer once new'd generally is not released until the IScriptEnvironment is deleted

so I'm currently deleting the clips and IScriptEnvironment and re-instantiating them, which seems unnecessary.

[pinterf]

They are valid until IScriptEnvironment delete.

[pinterf]

Exist() is now broken in 3.5. [on folders]

Behaviour on folders is fixed, plus added a new bool utf8 parameter.

[pinterf]

Test build, because there were huge internal changes along with some bug fixes.

With cherry-picking from Neo's early multithreading and ScriptClip fixes, old problems got solved.
And there was a week that I spent on Text filter having multiple sized fonts (mainly for helping Linux builds)

https://drive.google.com/open?id=1EI34RDOyjq8ilqGce-AP5FF1uqKzWXyy

- Fix: Multithreading enhancements and fixes (Nekopanda, from Neo fork)
- Fix old ScriptClip (runtime filters) issue
In this example "current_frame" variable was not seen by YDifferenceFromPrevious scripted within SubTitle
resulting in "ERROR: Plane Difference: This filter can only be used within run-time filters" message
Now this script finally works:
SetLogParams("log.txt", LOG_DEBUG)
ColorBars(width=640, height=480, pixel_type="yv12")
ScriptClip(last, "Subtitle(String(YDifferenceFromPrevious))")
Prefetch(4)
- Fix deadlock of ScriptClip on MT
- MT improvement
- Allow multiple Prefetchers
- Add argument to Prefetch to change # of prefetch frames without changing # of threads

Prefetch (clip c, int threads, int "frames")

In the original Plus, you could use only one Prefetch, but you can use any number of CUDA versions.
Also, an argument has been added to specify the number of frames to prefetch.
Prefetch (1,4) # Make 1 thread stand and prefetch 4 frames
By doing so, flexible parallelization configuration is possible, such as pipeline parallelization.

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

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

[StainlessS]

Exist(), ReplaceStr(), Prefetch/Global stuff probs all gone, cheers P.

You are clearly self isolating, maybe current COVID-19 situation aint all bad :)

[I've just been coughing a little bit(just a couple of coughs), and throat is a bit dry, maybe just hypochondria, I can feel a bit of paranoia coming on]

EDIT: Gonna gobble up a few raw garlic cloves and a lump of ginger, probably of little use.

EDIT:
World Health Organization: Coronavirus disease (COVID-19) advice for the public: Myth busters
Can eating garlic help prevent infection with the new coronavirus?

Garlic is a healthy food that may have some antimicrobial properties.
However, there is no evidence from the current outbreak that eating garlic has protected people from the new coronavirus.

https://www.who.int/emergencies/diseases/novel-coronavirus-2019/advice-for-public/myth-busters

[DJATOM]

You are clearly self isolating

Me too. Usually sitting at home, sometimes going to local mart to buy fresh food. No covid19 symptoms spotted so far, but last week I felt like I'd get sick soon, fortunately I'm fine now.

[Groucho2004]

I've just been coughing a little bit(just a couple of coughs), and throat is a bit dry, maybe just hypochondria, I can feel a bit of paranoia coming onSame here. :scared:
Gonna gobble up a few raw garlic cloves and a luma of ginger, probably of little use.Some people recommended gargling with bleach. I'm sure it kills the virus but the side effects are apparently severe (death).

[StainlessS]

gargling with bleach
Never tried that one yet, although a few years back I had been using [EDIT: a new] washing up liquid to wash my hands under the tap.
I had previously been thinking that it was a real lousy washing up liquid with hardly any lather (bubbles) and not much use
for washing the dishes. Anyways, this particular day I thought "what is that smell?", turns out it was actually household bleach,
was squirting it directly onto my hands, rubbing it in and then under the tap, never noticed any side effects of that.
Having lousy eyes is quite dangerous, is living 'on the edge'.
Same here.
Yep, well I'll write my Obituary and send it to you, if I go first then post it for me please (say that you wrote it), and I'll do the same for you.

EDIT: Oxo cube, 1 clove of garlic and a lump of ginger, finely chopped and into cup of water, nuked in microwave,
Is tolerable, WHO may say it dont work, but like many on-site I'm goin' for the Placebo Effect.

EDIT: New Avs+ files only fix for Exist() on folders, now AvsInit.avsi works fine again.

EDIT: I just got an old 2012 movie on DVD, "Iron Sky", never seen it before, love it and especially the intro music track, "Take me To Heaven" by Laibach, vocal by 'Severa Gjurin',
its near damned hynotic, love it. Maybe you [G2K4] can arrange to have it played when they shove me into the furnace [perhaps you'de even like to do the shoving].
A piece of it on YouTube [~2:30, Still frame music clip, ending chopped short; download of 360p version allowed; ~5.3MB]:- https://www.youtube.com/watch?v=sL2mF5lhwdk
EDIT: There is also a double feature "Iron Sky directors cut" and "Iron Sky 2 - The Coming Race", #2 aint supposed to be as good as #1,
but #1 is 20 mins longer, so I'm gonna get it for that.

[pinterf]

Exist(), ReplaceStr(), Prefetch/Global stuff probs all gone, cheers P.

You are clearly self isolating, maybe current COVID-19 situation aint all bad :)


With the home office I'm saving the time of 2*65 minutes public transport or 2*40 min commute on bike.

[StainlessS]

And you seem to be spending it all on Avs+ development, much thanks mate :)

[Groucho2004]

Having lousy eyes is quite dangerous, is living 'on the edge'.I recently got myself lens implants, it's like having a new set of eyes.

Maybe you [G2K4] can arrange to have it played when they shove me into the furnace [perhaps you'de even like to do the shoving].I'd be honoured to do the shoving.

"Iron Sky 2 - The Coming Race", #2 aint supposed to be as good as #1,
but #1 is 20 mins longer, so I'm gonna get it for that.That's what we need these days - quantity. It applies to all kinds of things, length of movies, toilet paper, ...

[real.finder]

Test build, because there were huge internal changes along with some bug fixes.

With cherry-picking from Neo's early multithreading and ScriptClip fixes, old problems got solved.


thank you, mt with runtime seems start working now, but I got this

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


ColorBars(width=640, height=480, pixel_type="yv12")
last.ScriptClip("last.dfttest(Sigma=AverageLuma(last)/16)")
Prefetch(4)


and iirc avsneo at least when use with cpu only many runtime filters not working, even StainlessS note this before

[StainlessS]

RF, With your script on x64 into VDub2 I get system exception, seems to be stack corruption

Problem signature:
Problem Event Name: APPCRASH
Application Name: VirtualDub64.exe
Application Version: 2.0.0.0
Application Timestamp: 5de45101
Fault Module Name: StackHash_bf55
Fault Module Version: 6.1.7601.24511
Fault Module Timestamp: 5d3fa9bd
Exception Code: c0000374
Exception Offset: 00000000000bf302
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: bf55
Additional Information 2: bf55d1c52d0a6d38288ab4c5246e8999
Additional Information 3: c72e
Additional Information 4: c72e187c65f9e7299dbd4cad6f92f629

Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt


On x86 into VDub2 I get a sort of blank VDub2, nothing in frame, with 2.6GB ram use [just hangs, maybe some kind of recursive stack exhaustion].
PotPlayer just immediately closes without any indication of error.

This is no problem

ColorBars(width=640, height=480, pixel_type="yv12")
SSS="""
Y=AverageLuma
S=String(Y)
Subtitle(S)
Return Last
"""
ScriptClip(SSS)
Prefetch(4)


EDIT: For Avs Neo, functions within Scriptclip (when Scriptclip @ main script level, ie not within script function) had no access to local vars at main level.
This does not seem to be the same problem as with NEO.

EDIT: OK

ColorBars(width=640, height=480, pixel_type="yv12")

SomeString="Local String Var at Main Level: "

SSS="""
Y=AverageLuma # Testing current_frame
S=String(Y)
Subtitle(SomeString+S)
Return Last
"""
ScriptClip(SSS)
Prefetch(4)


EDIT: For rf scipt on x86, I removed AvsRecursion.dll from SysWOW64 and I get multiple "This Application has requested the to runtime to terminate in an unusual way" message.

In VDub2 error alert I get an "Crash details (best guess as to cause) - An Exception occurred in module libfftw3f-3".

EDIT:
https://i.postimg.cc/529NP252/rferr.jpg (https://postimages.org/)temporary upload image (https://postimages.org/)

[pinterf]

RF, With your script on x64 into VDub2 I get system exception, seems to be stack corruption

Yep, just debugging the same problem, it's inside dfttest.
I have fixed the problem.
Good news: the script is working fine.

A new version of dfttest will be needed, I'll ask DJATOM if he wishes to maintain it further or I can make the update.

Any more wishes on dfttest?

[pinterf]

EDIT: For Avs Neo, functions within Scriptclip (when Scriptclip @ main script level, ie not within script function) had no access to local vars at main level.
This does not seem to be the same problem as with NEO.

Yep, my another test case is srestore, "I don't know what "dm" means" in Neo, it appeared 1.5 years ago, my cherry-pick is some months before that point, thus the problem is not exhibited.

[StainlessS]

Well if already figured out is dfttest, and easy fixed then is looking quite promising for MT stuff.
There was no problem with the fft3d libs then ?, all A.O.K. there.

Yep, halt cherry pickin' where NEO prob is first exhibited, good call :)

EDIT: To Below, thanks P.

[pinterf]

Well if already figured out is dfttest, and easy fixed then is looking quite promising for MT stuff.
There was no problem with the fft3d libs then ?, all A.O.K. there.

Yep, halt cherry pickin' where NEO prob is first exhibited, good call :)
Parts of FFTW3 are not thread-safe

[real.finder]

Parts of FFTW3 are not thread-safe

-Vit- did some changes back then to fix that https://forum.doom9.org/showthread.php?p=1423459#post1423459

[real.finder]

Yep, just debugging the same problem, it's inside dfttest.
I have fixed the problem.
Good news: the script is working fine.

A new version of dfttest will be needed, I'll ask DJATOM if he wishes to maintain it further or I can make the update.

Any more wishes on dfttest?

HBD and Y*, and if it possible to add something to make it easier/faster in motion compensation usage

[real.finder]

Prefetch (clip c, int threads, int "frames")

In the original Plus, you could use only one Prefetch, but you can use any number of CUDA versions.
Also, an argument has been added to specify the number of frames to prefetch.
Prefetch (1,4) # Make 1 thread stand and prefetch 4 frames
By doing so, flexible parallelization configuration is possible, such as pipeline parallelization.

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

frames
Number of frames to prefetch.
Again, if it is 0, it passes without doing anything.


shouldn't Prefetch(threads=0) or Prefetch() did auto use of all cores/threads :) like old avs mt (http://avisynth.nl/index.php/MT#SetMTmode), and only if Prefetch(1) it passes without doing anything.

[StainlessS]

Possibly HDRAGC source code is needed which is unfortunately not available (never published)

Never say never:- http://www.mediafire.com/file/cgvipn95ssiiojt/hdragc_25_dll_20050521.zip/file

EDIT: Source is 0.1.5 alpha (which aint the latest. EDITED: )

Version changes:
Version 0.1.5 alpha - 21.05.2005:
- improvments - 4 times faster with significantly reduced halo artifacts (if you want old behaviour use parameter mode = 0)
Version 0.1.2 alpha - 30.04.2005:
- changed lightness distribution routine (less plastic look - midtones have higher contrast)
- new value for auto control of saturation
- calculated gain is independent of avg_lum parameter
Version 0.1.1 alpha - 29.04.2005:
- fixed bug with avg_lum (thanks to AVIL)
- small c optimization (thanks to tsp)
- new parameters (coef_gain, min_sat, circle)
Version 0.1 alpha - 25.04.2005 - first release


It has ASM, otherwise I probably would have had a go myself to convert to x64.

EDIT: Damn, not latest by a long way. Latest I have is Hdragc-1.8.7.zip.

EDIT: from v1.8.7

Version changes:
Version 1.8.6 - 09.09.2006
- added 'freezer' parameter - number of frame that is choosen to calculate gain parameters
Version 1.8.5 - 10.06.2006
- added auto shifting (black_clip parameter)
- avg_lum parameter is back
- new mode (mode = 2), which is using float precision for some calculations (best quality, now mode = 2 as default)
- fixed behaviour of coef_gain (for coef_gain > 1.0 it works as in previous versions)
- tweaked corrector (by default it's not a bit lower, so if you were using previously x, now try x + 0.1)
Version 1.8.1 - 13.05.2006
- fixed crash for black frame (thanks to Boulder)
Version 1.8 - 13.05.2006
- huge jump in version, huge jump in quality ;)
- improved old algorithm from version 0.2.1 (mode = 0), new algorithm (mode = 1) that even for high gains give natural picture
- added support for YV12 and YUY2, removed RGB32
- 3 times faster (but still without MMX, SSE, SSE2 optimizations)
- 10 times less memory usage
- better handling of saturation
- new parameters for sublte color correction (shift_u, shift_v)
Version 0.2.1 - alpha - 25.10.2005:
- fixed sharpening/denoising (they were turned off when gain was not applied to image)
- fixed protect mode
Version 0.2.0 - alpha - 23.10.2005:
- completely new lighting routin (sigma parameter not needed)
- new mode (mode = 2) in which radius is adaptively choosen, this removes artifacts as much as I was able to do ;). Slow, but faster and much, much better than mode = 0
- mode = 1 is again 2 times faster (and will be faster later, still no MMX, SSE optimization)
- new parameter - protect - for value = 1 it can help in some situation with blowing highlights (default on)
- new parameters - contrast, limit - for denoising/sharpening, almost for free - no slow down (experimental)
Version 0.1.5 alpha - 21.05.2005:
- improvments - 4 times faster with significantly reduced halo artifacts (if you want old behaviour use parameter mode = 0)
Version 0.1.2 alpha - 30.04.2005:
- changed lightness distribution routine (less plastic look - midtones have higher contrast)
- new value for auto control of saturation
- calculated gain is independent of avg_lum parameter
Version 0.1.1 alpha - 29.04.2005:
- fixed bug with avg_lum (thanks to AVIL)
- small c optimization (thanks to tsp)
- new parameters (coef_gain, min_sat, circle)
Version 0.1 alpha - 25.04.2005 - first release

[pinterf]

-Vit- did some changes back then to fix that https://forum.doom9.org/showthread.php?p=1423459#post1423459
I can't see it how.

[pinterf]

HBD and Y*, and if it possible to add something to make it easier/faster in motion compensation usage
So it supports 16 bit only through lsb?

[real.finder]

I can't see it how.

seems only plugins source in the Package, it has only the modded dll's of fftw3 and libfftw3f-3 here if you want to test https://www.solidfiles.com/v/p5eAgABYgRyVV

edit: I just tried, seems it not fix it, I get same as StainlessS


On x86 into VDub2 I get a sort of blank VDub2, nothing in frame, with 2.6GB ram use [just hangs, maybe some kind of recursive stack exhaustion].


but with mpc

So it supports 16 bit only through lsb?

yes, no one added HBD to it yet, there are vs port https://forum.doom9.org/showthread.php?t=171678 maybe it can help

[pinterf]

seems only plugins source in the Package, it has only the modded dll's of fftw3 and libfftw3f-3 here if you want to test https://www.solidfiles.com/v/p5eAgABYgRyVV

yes, no one added HBD to it yet, there are vs port https://forum.doom9.org/showthread.php?t=171678 maybe it can help

Anyway, dfttest itself had to be modded. Nothing to do with fftw3, but calling its plan should be thread safe even if the filter was set to MT_MULTI_INSTANCE.

[pinterf]

real.finder, StainlessS:

pls. test this one.
https://github.com/pinterf/dfttest/releases/tag/1.9.4.4

Just a quick update for MT test.

[StainlessS]

Well it dont crash at all for me, however, I've never actually ever used it, unless as a requirement of some script function,
dont even know how to use it. [Think I'm gonna have a nap, I'm a bit knackered].

[DJATOM]

I'll ask DJATOM if he wishes to maintain it further or I can make the update.
You're free to modify that plugin, I've lost the interest in avisynth once started to tinker with vapoursynth.
avs2yuv update is probably my last work on avisynth software, but who knows... for now avisynth is only useful for me when I have do deal with DVD content. Vapoursynth lacks some plugins, for example VFR mode in VDecimate.

[pinterf]

You're free to modify that plugin, I've lost the interest in avisynth once started to tinker with vapoursynth.
avs2yuv update is probably my last work on avisynth software, but who knows... for now avisynth is only useful for me when I have do deal with DVD content. Vapoursynth lacks some plugins, for example VFR mode in VDecimate.
Thanks, I saw that the repo is "archived"

[Reel.Deel]

@pinterf

Just in case you are not aware, here's an updated dfttest: https://github.com/299792458m/dfttest_mod

[real.finder]

real.finder, StainlessS:

pls. test this one.
https://github.com/pinterf/dfttest/releases/tag/1.9.4.4

Just a quick update for MT test.

quick test and seems not crash/freeze with my admfilter (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Advanced%20Denoising.avsi)()

thank you for make avs better and better :)

even with https://forum.doom9.org/showpost.php?p=1904737&postcount=5245 it work!

[pinterf]

And a quick update
dfttest v1.9.5 with high bit depth support (and an lsb_in fix)

https://github.com/pinterf/dfttest/releases/tag/1.9.5

Now I'm going to have some rest.

edit: Reel.Deel, thanks, bookmarked. I'll look at it later. Just tell me if I forget about it.

[DJATOM]

Nice spotted, pinterf! I tested it on "upscaled" stacked frames so didn't even had a chance to trigger that bug :(

[real.finder]

And a quick update
dfttest v1.9.5 with high bit depth support (and an lsb_in fix)

https://github.com/pinterf/dfttest/releases/tag/1.9.5

Now I'm going to have some rest.

edit: Reel.Deel, thanks, bookmarked. I'll look at it later. Just tell me if I forget about it.

thanks, HBD seems work as quick test :thanks:

[pinterf]

And a final update to have AVX2 routines inside and a further fix
Download dfttest v1.9.6
https://github.com/pinterf/dfttest/releases/tag/1.9.6
(Since this dfttest issue emerged here, I won't open a separate topic for it now)

[Taurus]

@pinterf:
A big :thanks: to you!

[FranceBB]

Once again a big fat thank you for DFTTest as it's one of my favorite denoise filters!
Having native high bit depth is amazing so that I don't have to go back and forth between planar and stacked/interleaved anymore in my filterchain! :D
But most importantly, thank you for keeping 16bit stacked as well, as this way it's gonna be backward compatible with the old scripts as well. :)
I tested it and it works fine on my beloved Windows XP! :D (and it works flawlessly on my Win10 machine with a Xeon that I use at work to encode as well...)

Just a quick note for all of you who use the "opt" parameter:

BEFORE Ferenc's mod, we had:

opt -

Sets which cpu optimizations are used. Possible settings:

0 - auto detect
1 - c routines
2 - sse routines
3 - sse2 routines

default: 0


AFTER Ferenc's mod, we have:

opt -

Sets which cpu optimizations are used. Possible settings:

0 - auto detect
1 - c routines
2 - sse2 routines
3 - avx routines
4 - avx2 routines

There's no SSE now! So, if you're using Windows XP, please set it to 2 or 1 according to your CPU capabilities. Of course you won't be able to use AVX and AVX2 'cause they're not available on XP (even if your CPU supports them), therefore if you had "opt 3" in your old script (which meant SSE2), please make sure to change that to "opt 2" as it means SSE2 now; if you try to use the old "opt 3" it will try to use AVX assembly optimizations and it will not run unless you have Win7 and higher.

[StainlessS]

There's no SSE now! So, if you're using Windows XP, please set it to 2 or 1 according to your CPU capabilities.
Probably best to just use opt=0(auto) or better still just remove any opt arg.
Only force opt if absolutely necessary.

EDIT: Script stuff extracted from AvsInit.avsi, requires Grouchy2004 Sysinfo plug, parts use RT_stats, for RT_Ord().

Function IsWinXP() { Return Findstr(SI_OSVersionString,"Windows XP")!=0}

Function HasSSE() { S=SI_CPUExtensions i=S.Findstr("SSE") Return i!=0&&(S.RT_Ord(i+3)==0||S.RT_Ord(i+3)==RT_Ord(","))}
Function HasSSE2() { Return Findstr(SI_CPUExtensions,"SSE2")!=0}
Function HasSSE3() { Return Findstr(SI_CPUExtensions,"SSE3")!=0}
Function HasSSE41() { Return Findstr(SI_CPUExtensions,"SSE4.1")!=0}
Function HasSSE42() { Return Findstr(SI_CPUExtensions,"SSE4.2")!=0}
Function HasAVX() { S=SI_CPUExtensions i=S.Findstr("AVX")Return i!=0&&(S.RT_Ord(i+3)==0||S.RT_Ord(i+3)==RT_Ord(","))}
Function HasAVX2() { Return Findstr(SI_CPUExtensions,"AVX2")!=0}

[real.finder]

opt arg should be used only for testing, so end users should not use them

[pinterf]

Opt meaning was changed years ago. The bottleneck is fftw however, finding a properly fast build can help.

[real.finder]

there are still some random crash in realtime with MT

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

sometimes it crash from begin, but most of times it work until some random seeking then it crash

admfilter is in Advanced Denoising.avsi (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Advanced%20Denoising.avsi) and it also need this (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/ZS%20AVS%20Shared%20Functions.avsi)

[pinterf]

there are still some random crash in realtime with MT

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")
Prefetch(4)

sometimes it crash from begin, but most of times it work until some random seeking then it crash


There is a default internal MT in dfttest. Could you try with threads=1 parameter, until I get to the topic?

[real.finder]

There is a default internal MT in dfttest. Could you try with threads=1 parameter, until I get to the topic?

well, I don't have avstp.dll in plugins folder (but I load it manually for heavy scripts), but yes threads=1 seems help, the random crash is become harder (with more than 35 random seek until crash) now, but it's still there

[LigH]

@StainlessS:

Will there be an AviSynth+ 3.5 CHM ... or is that Sisyphean labor?

[StainlessS]

It does sound a lot like rolling a big boulder up a hill - repeatedly. (I had to look that up)
lets see how things pan out.

[pinterf]

well, I don't have avstp.dll in plugins folder (but I load it manually for heavy scripts), but yes threads=1 seems help, the random crash is become harder (with more than 35 random seek until crash) now, but it's still there
Not avstp. Plugins with internal MT do not use necessarily avstp. Neither dfttest, nor JPSDR's plugins use it. And perhaps there are others as well.

[real.finder]

Not avstp. Plugins with internal MT do not use necessarily avstp. Neither dfttest, nor JPSDR's plugins use it. And perhaps there are others as well.

yes, I know that, but since dfttest was modded by Firesledge (aka cretindesalpes) who made avstp and add it to mvtools (was modded by him also) and dithertools

[wonkey_monkey]

Quick question: is the horizontally shifting chroma bug from <=2.61 fixed in Avisynth+?

http://avisynth.nl/index.php/Known_Issues#Resizers:_Chroma_Positioning_Bugs

[real.finder]

Quick question: is the horizontally shifting chroma bug from <=2.61 fixed in Avisynth+?

http://avisynth.nl/index.php/Known_Issues#Resizers:_Chroma_Positioning_Bugs

I think no for compatibility reasons, that why there are ResizeX script

[Selur]

sounds strange to keep a bug for compatibility reasons,...

[real.finder]

sounds strange to keep a bug for compatibility reasons,...

for avs+ there are this https://forum.doom9.org/showthread.php?t=173986

it should has no problem even with gamma

[Stereodude]

Am I misreading something or was high bit depth AVIsource support removed from Avisynth+ starting with build 2724?

from http://avisynth.nl/index.php/AviSource#10.2B_bit_inputs
Full support list (* only supported prior to 2724):

I have r2923 and can't open an AVI containing v210 format video with AVIsource. :confused:

[pinterf]

Am I misreading something or was high bit depth AVIsource support removed from Avisynth+ starting with build 2724?

from http://avisynth.nl/index.php/AviSource#10.2B_bit_inputs

I have r2923 and can't open an AVI containing v210 format video with AVIsource. :confused:
Could you check it with 3.5.0?
3.5.0 changelog:
Fix: crash when outputting VfW (e.g. VirtualDub) for YUV444P16, other fixes for r210 ...

[StainlessS]

Could you check it with 3.5.0?
Latest non test (Release) version v3.50:- https://github.com/AviSynth/AviSynthPlus/releases

[Stereodude]

Could you check it with 3.5.0?
3.5.0 changelog:
Fix: crash when outputting VfW (e.g. VirtualDub) for YUV444P16, other fixes for r210 ...

Doesn't work for P010 (saved by VD2) or v210 (saved by Resolve).

"AVISource: couldn't locate a decompressor for fourcc P010"

"AVISource: couldn't locate a decompressor for fourcc v210"

It does the same thing x64 or x86

[poisondeathray]

You would need a VFW codec for v210 to use AVISource() . Something like blackmagic codecs, drastic codecs, or AJA codecs. Matching x86, x64 versions for x86/x64 avisynth

Or use lsmash / ffms2

[Stereodude]

You would need a VFW codec for v210 to use AVISource() . Something like blackmagic codecs, drastic codecs, or AJA codecs. Matching x86, x64 versions for x86/x64 avisynth

Or use lsmash / ffms2
Wait, why can't it read an uncompressed AVI with data in those color formats?

lsmash/ffms2 has to index the entire file and I could do without a long delay to open the file (like 10 minutes for a 150GB file). My journey to find an export format from Resolve that is lossless and can by opened by Avisynth without indexing first continues.

[StainlessS]

Thanks PDR, I was gonna post (ask) about requirement for v210 decompressor aswell.
For anyone that wants a 10 Bit v210 AVI sample (10 secs), there was one posted here (Standard8_Scan_16FPS.avi by SnillorZ) :- https://forum.doom9.org/showthread.php?p=1875247#post1875247
NOTE 830MB, is BIG for a 10 secs clip.

EDIT: Presumably v210 Decompressor required despite uncompressed because above is 10 bit [not standard 8 bit YUV].

EDIT: I think I remember the time when was necessary to install eg HuffYUV or HelixYUV because Windows standard did not include a VFW decompressor/splitter for YV12.
EDIT: Or the Windows YUV decompressor was a bit broken.

[poisondeathray]

Wait, why can't it read an uncompressed AVI with data in those color formats?


I think it's a windows thing.

And some of those "professional" codecs actually send RGB when it's in a AVI container (maybe pixel_type="YUV422P10" can force navigation of proper 10bit 4:2:2, not sure)

AVI does not work very well for higher bit depths in very many programs.

MOV is supported much better for higher bit depths (even though it's an Apple-esque tied format it's preferable here because it works properly)


lsmash/ffms2 has to index the entire file and I could do without a long delay to open the file (like 10 minutes for a 150GB file). My journey to find an export format from Resolve that is lossless and can by opened by Avisynth continues.

You can use v210 in MOV container and that does not require indexing by Lsmash when you use LSmashVideoSource() .

[Stereodude]

Thanks PDR, I was gonna post (ask) about requirement for v210 decompressor aswell.
For anyone that wants a 10 Bit v210 AVI sample (10 secs), there was one posted here (Standard8_Scan_16FPS.avi by SnillorZ) :- https://forum.doom9.org/showthread.php?p=1875247#post1875247
NOTE 830MB, is BIG for a 10 secs clip.

EDIT: Presumably v210 Decompressor required despite uncompressed because above is 10 bit [not standard 8 bit YUV].
You can make a sample. It's really easy.

global OPT_Enable_V210 = true

colorbars(1280,720, "YUV422P10")
trim(0,499)Fast Recompress with VD2 to an AVI while dropping the audio it's 1.15GB (for 500 frames) which you can 7-zip down to all of 180kB.

[StainlessS]

Thanks very much for that SD, 180KB, very petite :)

EDIT: 800MB Standard8_Scan_16FPS.avi , compresses with 7zip v19.0 Ultra Compression = 483MB, not quite as good as colorbars compressed.

[Stereodude]

You can use v210 in MOV container and that does not require indexing by Lsmash when you use LSmashVideoSource() .
Okay, once I went digging in the lsmash thread and found the latest build it seems to work from a .mov without indexing. I had an old version before which returns garbled green video hence why I was using ffms2 for the .mov.

:thanks:

[pinterf]

I was testing Avisource inputs with Magicyuv codec and test files, Avisource could ask for planar rgbp10, r210 or R10k output for the same M0RG fourcc file.
Or P210, v210 or YUV422P10 for UQY2 or M0Y2 fourCC formats.

#AviSource("Sample_UQRA.avi",False) #rgb64
AviSource("Sample_UQRA.avi",False,"rgbp") #cannot req planar rgb output
#AviSource("Sample_UQRG.avi",False/*,"YV12"*/) #rgb48
#AviSource("Sample_UQRG.avi",False,"RGBP") #rgb planar, auto bit depth
#AviSource("Sample_UQY2.avi",False) YUV422P10

#AviSource("Sample_M0RG.avi",False)#.Histogram("levels",bits=10) # RGBP10
#AviSource("Sample_M0RG.avi",False,"RGBP")#.Histogram("levels",bits=10) # RGBP10
#AviSource("Sample_M0RG.avi",False,"RGB64")#.Histogram("levels",bits=10) # RGB64
#AviSource("Sample_UQY2.avi",False,"v210").Info()#.Histogram("levels",bits=10) # YUV422P10
#AviSource("Sample_M0Y2.avi",False,"v210").Info()#.Histogram("levels",bits=10) # YUV422P10
#AviSource("Sample_M0Y2.avi",False,"P210").Info()#.Histogram("levels",bits=10) # YUV422P10
#AviSource("Sample_M0Y2.avi",False,"P216").Info()#.Histogram("levels",bits=10) # YUV422P16
#AviSource("Sample_M0Y2.avi",False,"P010").Info()#.Histogram("levels",bits=10) # YUV420P10
#AviSource("Sample_M0Y2.avi",False,"P016").Info()#.Histogram("levels",bits=10) # YUV420P16
#AviSource("Sample_M0RA.avi",False/*,"RGBAP10"*/)#.Histogram("levels",bits=10) # RGB10
#AviSource("Sample_M0RG.avi",False,"r210")#.Histogram("levels",bits=10) # RGB
#AviSource("Sample_M0RG.avi",False,"R10k")#.Histogram("levels",bits=10) # RGB
#AviSource("Sample_M0RG.avi",False,"RGBP")#.Histogram("levels",bits=10) # RGB

#AviSource("Sample_M0G0.avi",False/*,"RGBP10"*/)
#AviSource("Sample_M0RG.avi",False,"r210")#.Histogram("levels",bits=10) # RGBP10
#AviSource("cbv308.avi",False,"v308") #YV24 aka YUV444P8
#AviSource("cbv308.avi",False,"v408") #YUVA444P8
#AviSource("cbv410.avi",False,"v410") #YUV444P10
#AviSource("cbv308.avi",False,"v410") #error

Info()
ConvertToRgb32()

[Stereodude]

I was testing Avisource inputs with Magicyuv codec and test files, Avisource could ask for planar rgbp10, r210 or R10k output for the same M0RG fourcc file.
Or P210, v210 or YUV422P10 for UQY2 or M0Y2 fourCC formats.
So it is supposed to be able to open uncompressed AVI's with those color formats or not?

[pinterf]

So it is supposed to be able to open uncompressed AVI's with those color formats or not?
For AviSource it depends on the installed codec. No codec, no video. (No GUS, no sound :) )

[StainlessS]

No codec, no video. (No GUS, no sound :) )
Bob Marley fan, eh. [EDIT: No woman, no cry]

[pinterf]

Demoscene, Future Crew, EMF and others :)

[LigH]

Fortunately, DosBox emulates GUS (Gravis Ultrasound) devices nicely.

[Stereodude]

Quick question: is the horizontally shifting chroma bug from <=2.61 fixed in Avisynth+?

http://avisynth.nl/index.php/Known_Issues#Resizers:_Chroma_Positioning_Bugs
No, it's not (or at least something is still wrong with the chroma handling)

You can quickly test for it by doing an integer point resample modification to the chroma and back. It should be lossless, but using the built in avisynth+ functions it's not. Using avsresize (z.lib) it is lossless.

Lossless:
z_ConvertFormat(pixel_type="YUV422P10", resample_filter="point", colorspace_op="170m:601:170m:f=>170m:601:170m:f")
z_ConvertFormat(pixel_type="YV12", resample_filter="point", colorspace_op="170m:601:170m:f=>170m:601:170m:f")

not lossless
ConvertToYUV422(matrix="PC.601", chromaresample="point")
ConvertToYUV420(matrix="PC.601", chromaresample="point")

[real.finder]

can someone add HBD to http://avisynth.nl/index.php/MedianBlur2 and http://avisynth.nl/index.php/AddGrainC ?

they are very basic functions that needed in many scripts

[DJATOM]

AddGrain already have vapoursynth version, probably not that difficult to port back.

[real.finder]

AddGrain already have vapoursynth version, probably not that difficult to port back.

so you will do it? :)

I kinda shy to ask pinterf since he already did many ports and work for avs

if not you then maybe jpsdr or MeteorRain

for MedianBlur2 there are also https://forum.doom9.org/showthread.php?p=1810220#post1810220

[StvG]

can someone add HBD to http://avisynth.nl/index.php/MedianBlur2 and http://avisynth.nl/index.php/AddGrainC ?

they are very basic functions that needed in many scripts
AddGrain (https://cloud.owncube.com/s/WdARWHb9epfGRwM) port of the vs version.

[real.finder]

AddGrain (https://cloud.owncube.com/s/WdARWHb9epfGRwM) port of the vs version.

thanks, it work but even in 8 bit it darker (1/255) than the original input or old AddGrain

[real.finder]

so, anyone will pickup MedianBlur2?

[pinterf]

I'll check how difficult it is. If project can be done in a day then probably ok.

[mcjordan]

Pinterf, i have a try to compile your last build of AviSynthPlus (VC2019),
but several times I encounter the following messages:

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'
and also
C2440 'return': cannot convert from 'AVSMapValue' to 'AVSMapValue &'

It is critical? I read some things in the following forum:
https://cboard.cprogramming.com/c-programming/168424-conditional-operator-second-operand-neither-throw-expression-nor-type-void.html
Thank you in advance and sorry for disturbance. I'm not deep familiar with C/C++ programming.

[pinterf]

Check it again please, work in progress.

[mcjordan]

Thank you. I'll try again later.

[mcjordan]

Also in strings.cpp ->
Warning C4996 'std::codecvt_utf8_utf16<wchar_t,1114111,(std::codecvt_mode)0>': warning STL4017: std::wbuffer_convert, std::wstring_convert, and the <codecvt> header (containing std::codecvt_mode, std::codecvt_utf8, std::codecvt_utf16, and std::codecvt_utf8_utf16) are deprecated in C++17. (The std::codecvt class template is NOT deprecated.) The C++ Standard doesn't provide equivalent non-deprecated functionality; consider using MultiByteToWideChar() and WideCharToMultiByte() from <Windows.h> instead. You can define _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.

and

error C2039: 'unique_ptr': is not a member of 'std'
message : see declaration of 'std'
syntax error: missing ';' before '<'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

Sorry for double post.

[pinterf]

Put an
#include <memory>
in strings.h

rare case when gcc and clang was o.k., but msvc not.

[feisty2]

Put an
#include <memory>
in strings.h

rare case when gcc and clang was o.k., but msvc not.

you could probably write a very high level script-like API wrapper, like I recently did, if you wanna make the coding process painless for people that wish to write their own plugins but with little knowledge of C or C++

[mcjordan]

#include <memory>
in strings.h
works like a charm.

Thank you, Pinterf.

[pinterf]

you could probably write a very high level script-like API wrapper, like I recently did, if you wanna make the coding process painless for people that wish to write their own plugins but with little knowledge of C or C++
:) I enjoy your coding experiments despite the fact that sometimes I feel myself dummy and too old for those abstractions that are allowed by modern C++ syntax. I have the similar feelings when I'm looking into secrit-twc's repos who solves problems in two elegant lines which I'm doing with a half page of code. Probably my son will do it better than me (he's studying informatics), they had already C++ basics, C++11, 14 and 17 are covered by second half-year course, so he cannot help me right now in interpreting those magics you are doing.

[MeteorRain]

I'd really hope someone's gonna write a wrapper like what I did to make a plugin dual interface, but in a more elegant and clean way.

[MeteorRain]

I actually took some time to read F2's code. I'm impressed by how elegant it's done. In my dual interface framework I put wrapper as template parameter, while he put the filter engine as template parameter. Very interesting design.

Lots of features are not supported yet -- lots of C++20 things. So no MSVC at this point == no chance for AviSynth+ for Windows.

[feisty2]

Lots of features are not supported yet -- lots of C++20 things. So no MSVC at this point == no chance for AviSynth+ for Windows.

I actually successfully compiled GCC 10 (trunk ver) from the scratch in Cygwin for windows a few days ago. I'll admit that it was not a pleasant experience...

[pinterf]

for MedianBlur2 there are also https://forum.doom9.org/showthread.php?p=1810220#post1810220
Give it a try, pls.
https://github.com/pinterf/MedianBlur2/releases/tag/1.0

[pinterf]

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)

EDIT: link removed until I check real.finder's bug report
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw

- New function:
SetMaxCPU(string feature)

string "feature"

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

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

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

Examples:
SetMaxCPU("SSE2") reports at most SSE2 processor (even if AVX2 is available)
SetMaxCPU("avx,sse4.1-") limits to avx2 but explicitely removes reporting sse4.1 support
SetMaxCPU("C,avx2+") limits to plain C, then switches on AVX2-only support

- Fix: Mix/Max Runtime function 32bit float chroma: return -0.5..0.5 range (was: 0..1 range)
- Other MT fixes from Neo

[real.finder]

Give it a try, pls.
https://github.com/pinterf/MedianBlur2/releases/tag/1.0

it's seems work fine with HBD :thanks:

but Avisynth+ test, even without using mt

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
#Prefetch(4)

https://i.postimg.cc/4nV1CBmW/Untitled.png (https://postimg.cc/4nV1CBmW)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)

[real.finder]

AddGrain (https://cloud.owncube.com/s/WdARWHb9epfGRwM) port of the vs version.

thanks, it work but even in 8 bit it darker (1/255) than the original input or old AddGrain

anyone know why? is the VS version has the same output?

[pinterf]

it's seems work fine with HBD :thanks:

but Avisynth+ test, even without using mt

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
#Prefetch(4)

https://i.postimg.cc/4nV1CBmW/Untitled.png (https://postimg.cc/4nV1CBmW)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)
Thanks, then I remove the link temporarily.
EDIT: new link posted (silly bug)

[pinterf]

anyone know why? is the VS version has the same output?
Missing rounding at a right shift.

[real.finder]

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)

EDIT: link removed until I check real.finder's bug report
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw


Thanks, then I remove the link temporarily.
EDIT: new link posted (silly bug)

quick test and WOW :eek:

it's seems fix even this (https://forum.doom9.org/showthread.php?p=1904931#post1904931)!

you are a hero for avs+ users :)

[pinterf]

quick test and WOW :eek:

it's seems fix even this (https://forum.doom9.org/showthread.php?p=1904931#post1904931)!

you are a hero for avs+ users :)
Not me, Neo branch fixed it, but he went too far, and I reverted back a bit, though the changes were so huge that I spent a week on the topic. Go on testing with this build then.

[real.finder]

Not me, Neo branch fixed it, but he went too far, and I reverted back a bit, though the changes were so huge that I spent a week on the topic.

yes, I almost forget that from happiness, also a big thanks to him! Although I wished he was chosen opencl than cuda :)

Go on testing with this build then.

indeed, I even make it the main one for now just for MT fix

[MeteorRain]

I actually successfully compiled GCC 10 (trunk ver) from the scratch in Cygwin for windows a few days ago. I'll admit that it was not a pleasant experience...

Doesn't sound fun at all. But then because avs uses C++ either msvc or clang cl can be used. Either way is far to go.

[FranceBB]

it's seems work fine with HBD :thanks:

Confirmed. It works flawlessly on Windows XP with planar high bit depths. :)

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)

EDIT: link removed until I check real.finder's bug report
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw


Something weird is happening with the new version.
I replaced the plugins, the Avisynth.dll in Windows, System32 and also DevIL.dll in System32.
Once I've done that, I tried to open up AVSPmod and it fails to start saying to check and make sure that I don't have any broken plugins or corrupted Avisynth installation. If I try to run AVSMeter to get the info, it prompts me to an access violation:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\system32\avisynth.dll
Address: 0x100863AA

Same goes if I try to open a script with AVSMeter.
If I try to use avs4x264mod on the same script, it crashes with an unknown error, same goes for ffmpeg...
However if I try to load the very same script in VirtualDub, it works fine.
Why...?
According to Dependency Walker, nothing is missing in Avisynth.dll and it's perfectly fine, so... there must be something weird going on under the hood...

[pinterf]

Thanks for the report, it seems to crash with programs using the C interface. It should be easy to reproduce.
EDIT: wasn't easy = couldn't reproduce

[feisty2]

Doesn't sound fun at all. But then because avs uses C++ either msvc or clang cl can be used. Either way is far to go.

I believe clang10 should have supported all the required c++ 20 core language features to compile vsFilterScript

[real.finder]

Thanks for the report, it seems to crash with programs using the C interface. It should be easy to reproduce.

I did encode with x264 and used avspmod with no problem, both are C interface (but they not uptodate though)

edit: even open it with mpc work

[pinterf]

Something weird is happening with the new version.
I replaced the plugins, the Avisynth.dll in Windows, System32 and also DevIL.dll in System32.
Once I've done that, I tried to open up AVSPmod and it fails to start saying to check and make sure that I don't have any broken plugins or corrupted Avisynth installation. If I try to run AVSMeter to get the info, it prompts me to an access violation:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\WINDOWS\system32\avisynth.dll
Address: 0x100863AA

Same goes if I try to open a script with AVSMeter.
If I try to use avs4x264mod on the same script, it crashes with an unknown error, same goes for ffmpeg...
However if I try to load the very same script in VirtualDub, it works fine.
Why...?
According to Dependency Walker, nothing is missing in Avisynth.dll and it's perfectly fine, so... there must be something weird going on under the hood...
No problem on my side. avspmod 32 bit, x264 64 bit, avsmeters all working well. Latest redistributables (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)?

[FranceBB]

No problem on my side. avspmod 32 bit, x264 64 bit, avsmeters all working well. Latest redistributables (https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads)?

Yep, I have C++ from 2005 to 2019 and .NET Framework from 1.0 to 4.0.
It's really weird...

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

Oops. I just noticed that I have the 2019 as 14.24.28127 and the very latest is 14.25.28508.
I'm updating right now.

Nope. Going from 2019 version 14.24.28127 to 14.25.28508 did not solve the problem.

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

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

https://i.imgur.com/9YL2HSL.png

Yet, if I try something stupid like:


clip=ColorBars(width=848, height=479)

my_initial_width=clip.Width()
my_initial_heigth=clip.Height()

i_width = my_initial_width / 2 * 2
i_height = my_initial_heigth / 2 * 2

Spline64Resize(clip, i_width, i_height)


VirtualDub works:

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

And even if I try something more complex which involves external filters and dependencies, it works fine on VirtualDub


video=DGDecode_MPEG2Source("I:\Production\RAW\424-430\opening_ending_textless.d2v")
audio=FFAudioSource("I:\Production\RAW\424-430\opening_ending_textless T80 2_0ch 224Kbps DELAY 0ms.ac3")
Audiook=MergeChannels(audio, audio, audio, audio)
AudioDub(video, audiook)

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3))
tdecimate()

f3kdb(range=15, Y=70, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, opt=3, mt=true, keep_tv_range=true, input_depth=8, output_mode=1, output_depth=16)

nnedi3_resize16(target_width=720, target_height=576, mixed=true, thr=1.0, elast=1.5, nns=4, qual=2, etype=0, pscrn=4, threads=0, tv_range=true, kernel_d="Spline", kernel_u="Spline", taps=6, f_d=1.0, f_u=2.0, sharp=0, lsb_in=true, lsb=false)

Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

ResampleAudio(48000)
AssumeFPS(25, 1, true)
SSRC(48000)

assumeTFF()
separatefields()
selectevery(4,0,3)
weave()


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

and it fails on avs4x264 as well as in AVSPmod and AVSMeter...

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

Even something as simple as this doesn't work with AVSPmod, avs4x264 and ffmpeg:


ColorBars(width=704, height=396)


with the same error...

Even AVSEditPlus crashes as soon as I compile the script (click preview button):

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

And yet, VirtualDub works...

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


I don't get it...

p.s if I can provide you any debug symbols or anything, just let me know how to do that and I'll give you everything.

p.p.s if you don't have an XP VM where you wanna test, I can let you log into mine via Anydesk (no RDP as I'm not a big fan of it for non-intranet connections).

[Groucho2004]

Oops. I just noticed that I have the 2019 as 14.24.28127 and the very latest is 14.25.28508.
I'm updating right now.The latest seems to be 14.26.28720.3 (https://github.com/abbodi1406/vcredist/releases).

[FranceBB]

The latest seems to be 14.26.28720.3 (https://github.com/abbodi1406/vcredist/releases).

Updated again, but it doesn't solve the issue... :(

[stax76]

Software is complex and unofficial and alternative ways have always the potential to cause issues, so I recommend using the official source:

https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads

[pinterf]

I have 15.25.28508.

[Groucho2004]

@FranceBB
Are you testing this on vanilla XP or the one with modified kernel?

[FranceBB]

@FranceBB
Are you testing this on vanilla XP or the one with modified kernel?

Modified kernel, but it didn't really break any programs so far. I can also boot with the normal kernel (since I can select it at boot time) just to be absolutely sure, but I don't think it's One Core API that broke something...
Anyway, I'll reboot with the normal kernel and I'll let you know.

EDIT: Nope, same behavior with the normal kernel...

I also tried with:


SetMaxCPU("C")
ColorBars(width=848, height=480)


just to make sure that it wasn't because of assembly optimizations, but no...
Even specifying C only doesn't make the other programs work... Only VirtualDub works and I have no idea why...

[gispos]

Updated again, but it doesn't solve the issue... :(

You have copied the 32bit dll's into the system 64bit directory (system32)?
I am reading System32 directory and see AvsMeter x86:confused:

Edit: My Error, your on WinXP 32bit correct?

[FranceBB]

You have copied the 32bit dll's into the system 64bit directory (system32)?
I am reading Sytem32 directory and see AvsMeter x86:confused:

No no, 32bit on a 32bit system.
There's "System" which is the old 16bit and System32 which is the 32bit System.

Windows XP x86 with 32 GB of RAM DDR4.

https://tarma.com/support/im9/using/pages/typicalpaths.htm

[MeteorRain]

I believe clang10 should have supported all the required c++ 20 core language features to compile vsFilterScript

Still a long way to go on Windows. (https://github.com/microsoft/STL/pull/475)

[Groucho2004]

Only VirtualDub works and I have no idea why...The only difference I can think of is that VDub uses the VfW interface whereas the others you tried use the native API, either C or C++.

[Groucho2004]

The only difference I can think of is that VDub uses the VfW interface whereas the others you tried use the native API, either C or C++.FranceBB: Here (http://www.mediafire.com/file/8fl4qxzidgs4bgk/AVSMeter.7z/file) is an old AVSMeter test version that uses VfW. Try it.

[StainlessS]

FranceBB, You are using VirtualDub Filtermod, thats an old one. [Been VirtualDub2 for quite some time]

[qyot27]

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

Mostly just bugfixes and tidying up POSIX stuff. Seeing the recent discussion, might want to check against 3.5.1 to see if the issue with C api programs exists.

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

[FranceBB]

FranceBB: Here (http://www.mediafire.com/file/8fl4qxzidgs4bgk/AVSMeter.7z/file) is an old AVSMeter test version that uses VfW. Try it.

I tried to use it, but it failed to analyze the script...

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

FranceBB, You are using VirtualDub Filtermod, thats an old one. [Been VirtualDub2 for quite some time]

Oh, I didn't know that. I just updated it and it works like a charm. I noticed that it now also has some added features like the device capture, the VP8 and VP9 encoding through ffmpeg and so on. Anyway, even with the new version of VirtualDub, the new Avisynth works, however nothing else does...

[Groucho2004]

I tried to use it, but it failed to analyze the script...

https://i.imgur.com/EPrABiS.pngWell, I'm out of ideas for now. :(

[real.finder]

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

Mostly just bugfixes and tidying up POSIX stuff. Seeing the recent discussion, might want to check against 3.5.1 to see if the issue with C api programs exists.


this seems fix MPP problem (https://i.postimg.cc/NM9pyPHf/Untitled.png) with last test one

[real.finder]

this seems fix MPP problem (https://i.postimg.cc/NM9pyPHf/Untitled.png) with last test one

but it not work with MT!

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)

https://i.postimg.cc/Y0Tbkcqw/Untitled.png (https://postimages.org/)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)

[FranceBB]

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

Mostly just bugfixes and tidying up POSIX stuff. Seeing the recent discussion, might want to check against 3.5.1 to see if the issue with C api programs exists.

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

Did you, by any chance, re-compiled with some different option what Ferenc released? Because when I substituted the test build with this one it started working with everything else again, including AVSPmod, AVSMeter etc.
My guess (and it's just a guess) is that the test build wasn't actually compiled with something for XP and the only reason why Dependency Walker was saying that everything was fine was that probably what was "missing" already had an implementation made by the wrapper of my custom kernel but perhaps it wasn't complete and it broke something, I don't know.

Anyway, it works now, so... I guess all's well that ends well :)

[qyot27]

but it not work with MT!

ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)

https://i.postimg.cc/Y0Tbkcqw/Untitled.png (https://postimages.org/)

Zs_RF_Shared (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi) and AdvancedDenoising (https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/AdvancedDenoising.avsi)
3.5.1 does not include the Neo changes in the test build from earlier. I wanted to make sure we had a proper release out before getting into the task of making sure those changes can merge in.

Did you, by any chance, re-compiled with some different option what Ferenc released? Because when I substituted the test build with this one it started working with everything else again, including AVSPmod, AVSMeter etc.
My guess (and it's just a guess) is that the test build wasn't actually compiled with something for XP and the only reason why Dependency Walker was saying that everything was fine was that probably what was "missing" already had an implementation made by the wrapper of my custom kernel but perhaps it wasn't complete and it broke something, I don't know.

Anyway, it works now, so... I guess all's well that ends well :)
I doubt it's the abstraction of XP support to opt-in, since if it wasn't active then the library wouldn't run on XP at all (to see that, just swap in the builds that don't have _xp suffixed to them).

An access violation that only occurs in programs that directly talk to AviSynth, but not in programs that use VfW as a middleman points to it being that something in the Neo patchset changed the API and we need to identify and mitigate that. I haven't taken a look at any of it yet, though, so it may not have anything to do with that.

[real.finder]

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw


I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")

[pinterf]

I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")
Where can I find the latest one?

[real.finder]

Where can I find the latest one?

here https://github.com/realfinder/MP_Pipeline/releases

or last official one mirror https://forum.doom9.org/showthread.php?p=1841228#post1841228

[FranceBB]

An access violation that only occurs in programs that directly talk to AviSynth, but not in programs that use VfW as a middleman points to it being that something in the Neo patchset changed the API and we need to identify and mitigate that. I haven't taken a look at any of it yet, though, so it may not have anything to do with that.

I see... Again, if you need more testing on my end or if you wanna see my computer remotely (if you don't have an XP VM), I'll do everything I can. :)

here https://github.com/realfinder/MP_Pipeline/releases

or last official one mirror https://forum.doom9.org/showthread.php?p=1841228#post1841228

As a side note, it would be great to have audio support for MPP after all these years, along with proper AVS+ colorspaces/bitdepth handling to avoid to make it fail spectacularly like this (https://forum.doom9.org/showpost.php?p=1865072&postcount=273)

[gispos]

I note that if I make it the main avs+ MPP wont work (https://i.postimg.cc/NM9pyPHf/Untitled.png)

but if I use the 3.5.1 as a main and load this from MPP block it work!

mp_pipeline("""
### dll: C:\3.5.test_20200402b\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
""")
MPP requires a 'return last' in the last section for NEO builds.
Have you tried?

Something has changed from the previous version. Could this cause problems for some people?
More information


example 1 (this was still possible without 'return')
------------
LWLibavVideoSource(SourceFile)
return dummy()

function dummy(clip clp){
clp
}

example 2 (This was possible, not now)
------------
LWLibavVideoSource(SourceFile)

#dummy()
function dummy(clip clp){
clp
}

example 3 (MP_Pipeline needs now also return)
------------
MP_Pipeline("""
### inherit start ###
SourceFile = String(ScriptDir()) + "Goblin.mkv"
### inherit end ###
LWLibavVideoSource(SourceFile, cache=False)
### ###
### platform: Win32
HDRAGC()
### platform: Win64
### ###
audio=LWLibavAudioSource(SourceFile, cache=False)
audioDub(last, audio)
return last
""")
sharpen(0.40)

[pinterf]

Just built a new version from mpp, but I will do tests later

[real.finder]

MPP requires a 'return last' in the last section for NEO builds.
Have you tried?

Something has changed from the previous version. Could this cause problems for some people?
More information


example 1 (this was still possible without 'return')
------------
LWLibavVideoSource(SourceFile)
return dummy()

function dummy(clip clp){
clp
}

example 2 (This was possible, not now)
------------
LWLibavVideoSource(SourceFile)

#dummy()
function dummy(clip clp){
clp
}

example 3 (MP_Pipeline needs now also return)
------------
MP_Pipeline("""
### inherit start ###
SourceFile = String(ScriptDir()) + "Goblin.mkv"
### inherit end ###
LWLibavVideoSource(SourceFile, cache=False)
### ###
### platform: Win32
HDRAGC()
### platform: Win64
### ###
audio=LWLibavAudioSource(SourceFile, cache=False)
audioDub(last, audio)
return last
""")
sharpen(0.40)


thanks that seems make it work!

mp_pipeline("""
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter()
Prefetch(4)
### ###
return last
""")

[tormento]

Would you please create an additional autoload folder "AVSI" on next releases?

I probably suffer from OCD but I'd like to put them in a different directory. :D

[StainlessS]

Tormento,
AvsInit.avsi allows you to use a GIMPORT directory where avs/avsi scripts are auto loaded (by AvsInit), and makes it possible to have scripts that will load
under avs v2.58/2.60/2.61 Std with GScript, OR, under Avs+, either x86 or x64, and where all can use Gscript style constructs [for/While/If].
Can have a GIMPORT in plugins directory specifically for a single version of Avs, or where using G2K4 Avisynth Universal Installer, a
universal GIMPORT directory used by all avs versions, dont need same identical scripts in all avs version plugins.
Also some other functionality.

AvsInit.avsi :- https://forum.doom9.org/showthread.php?t=176749&highlight=AvsInit

EDIT: Some functions callable from inside AvsInit or user scripts.

AvsInit_LoadPlugin(fn) Load CPP dll with filename FN, sending debug stuff (success/fail) to DebugView window.
[Avs+ will also load C plugins].
AvsInit_LoadCPlugin(fn) Load C dll with filename FN, sending debug stuff (success/fail) to DebugView window.
AvsInit_Import(fn) Import[GImport() if GScript Present] avs/avsi script with filename FN, sending debug
stuff (success/fail) to DebugView window.
###
Directory of files load/Import functions. Return total number of scripts imported,
or dll's loaded,
AvsInit_DImport(Dir) Import[GImport() if GScript Present] All avs/avsi scripts in folder Dir, sending debug
stuff (success/fail) to DebugView window.
AvsInit_DLoad(Dir) Load all CPP/C plugin dll's in folder Dir, sending debug stuff (success/fail) to
DebugView window.

Both DImport and DLoad, funcs may be of use in user functions to satisfy some script
dependency, where a complex script requires multiple dll's or script loaded.

The Import style functions use GImport() when GScript is available, otherwise Import(). Any scripts imported should have any
GScript style wrappers removed, eg

>>>> CODE >>>>
GScript(""" # <<<<<<<<<<========= REMOVE THIS LINE
...
Some gscript stuff, if/else/for/next while etc
...
""") # <<<<<<<<<<========= REMOVE THIS LINE
<<<< END CODE <<<<

With GScript wrappers removed and imported via this library, then should be able to use same scripts in any version of avs
standard(with Gscript plugin) or avs+, whether it be avs v2.58, avs v2.60/2.61 Standard, avs+ x86 or x64.


EDIT: With AvsInit, you only need the AvsiInit.avsi in plugins, all others can be in local or global GIMPORT (or some other name) directory.

[tormento]

With AvsInit, you only need the AvsiInit.avsi in plugins, all others can be in local or global GIMPORT (or some other name) directory.
Thanks for your kind reply. I already put my AVSI in plugin64 folder, so they are autoloaded.

A question: why to have such a complicate solution as AvsInit when it would be way easier to have a separate AVSI folder?

[tormento]

url=https://cloud.owncube.com/s/WdARWHb9epfGRwM]AddGrain[/url] port of the vs version.
Is it the r7 VS version?

[pinterf]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset

[FranceBB]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset


OMG you have no idea how long I wished for someone to do this.
I tested it on XP as well with 16bit and even 32bit as bit depth along with things like RGBPS and RGBAPS: they all work fine.
Thank you! Thank you! Thank you!! *_*

Now the cherry on the cake would be audio support. After that, MPP is gonna be perfect! Please, I beg you to do that as this way we can leave it as it is for the years to come and it would actually save me time by avoiding to make an additional separate script without MPP, just for the audio.

p.s Ferenc, if you have a LinkedIn account I'll definitely leave you a good recommendation for everything you've done for this community.

[real.finder]

Now the cherry on the cake would be audio support. After that, MPP is gonna be perfect! Please, I beg you to do that as this way we can leave it as it is for the years to come and it would actually save me time by avoiding to make an additional separate script without MPP, just for the audio.

maybe not audio alone, but also with these https://github.com/SAPikachu/MP_Pipeline/issues/1 :goodpost:

[real.finder]

MP_Pipeline with Avisynth+ colorspace support

https://github.com/pinterf/MP_Pipeline/releases/tag/0.20

0.20 (20200404) pinterf
* Avisynth+ support
Add version resource
Build: move to VS2019, v142 and v141_xp toolset


thanks :thanks:

but it's still need return last, so it's avs+ test problem? will it stay like this? there are another examples in gispos post in another cases not only mpp

[StainlessS]

A question: why to have such a complicate solution as AvsInit when it would be way easier to have a separate AVSI folder?

Main reason for AvsiInit is below in BLUE

AvsInit.avsi v1.09 - 27/Jan/2020
Script to perform some tasks before user script is executed.

Also makes a few script functions later available to any other user scripts.
Also assists in removing AVS+ GScript incompatibilites so that an avsi script may run under Avs+, or when Gscript installed, then also v2.58, v2.60.

With GScript wrappers removed and imported via this library, then should be able to use same scripts in any version of avs
standard(with Gscript plugin) or avs+, whether it be avs v2.58, avs v2.60/2.61 Standard, avs+ x86 or x64.

You are looking at it with too limited a view, separate script directory loading is incidental.

[real.finder]

if anyone want to test admfilter (or anything else) with MT, GRunT update is needed http://www.mediafire.com/file/77uromd0j0z56ap/GRunT-1.0.2tst.7z/file

its the one that pinterf made years ago

[pinterf]

p.s Ferenc, if you have a LinkedIn account I'll definitely leave you a good recommendation for everything you've done for this community.
Thanks, but I'm collectiing kudos only on Strava :)

[StvG]

anyone know why? is the VS version has the same output?
VS version has identical output.
Is it the r7 VS version?
It's a port of r7 VS version.

[real.finder]

VS version has identical output.

It's a port of r7 VS version.

so that mean VS one was already has bug

[StvG]

so that mean VS one was already has bug
VS r1 has identical output to AddGrainC 1.71.
The difference comes from here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-AddGrain/commit/8f272c4b7aa3c32e5f6e2b19b20ff4dcb8dad481).

[Music Fan]

Hi,

I'd like to re-install Avisynth+, I still get an old version, but I don't know if I have to select the simple or the vcredist version.
When should the vcredist version be used ?
That's for Win 7 64.
Thanks ;)

[tebasuna51]

When should the vcredist version be used ?

If you don't have Microsoft Visual C++ 2015-2019 Redistributables installed (Control Panel -> Programs...).

[manolito]

Tip:
Always use this All-In-One VC++ redist package from Abbodi and be happy...
https://github.com/abbodi1406/vcredist/releases

[Music Fan]

Thanks ; if I install this package, does it mean I don't have to take the vcredist version ? No risk of conflict if I install it anyway ?

[manolito]

Thanks ; if I install this package, does it mean I don't have to take the vcredist version ? No risk of conflict if I install it anyway ?

Yes and Yes...:D

[Music Fan]

Ok thanks, that seems evident but I prefer to be prudent before to install something ;)

[Music Fan]

Houston, we have a problem :o
Since I re-installed AVS+ (AviSynthPlus-3.5.1_20200402.exe), I get lots of error messages ("can't open avs file", "function does not exist" ...) : I installed all 64 bit dlls in the plugins64+ directory, but Avisynth is installed in C:\Program Files (x86), is that the problem ?
It was the proposed directory during installation.
With the function version(), I see "r3106, 3.5, i386".

I'm a little bit lost now :o, how to install 64 bit version correctly, and which plugin folder to use ? Does it depend on the functions (32 bit in plugins+ and 64 bit in plugins64+) ?

And if it's a 32 bit only version, why are there plugins64 folders ?

[wonkey_monkey]

A long time ago, I pointed out a bug in bicubicresize - well, not so much bicubicresize, but resizing code in general, although by default it only exhibits with bicubicresize.

The problem is that bicubicresize, with its default parameters of b=1/3, c=1/3, is not a "nulll filter" when no resize/shift takes place - it actually blurs the image, because it has non-zero lobes even when the offset is 0.

That's bad already to me, since to me a good resizer should have a null effect if no resize or shift is taking place - and indeed it does, but only because Avisynth tests for and skips resampling in such cases. But it shouldn't, and I seem to remember this skip was removed when I pointed out the problem (I can't remember if pinterf was running the show at the time), which is that doing this skip results in a discontinuity when using bicubicresize.

However it seems that this fix has been reverted somewhere along the way, resulting, once again, in this:

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

This is a very slow scroll of an image by animating the src_top and src_left parameters of bicubicresize. Hopefully you can spot the "jump" when those parameters reach 0,0 and resampling is skipped.

Long story short: resampling should never be skipped - in either direction - just because there is no offset and the scale factor is 1. Not just because bicubicresize has silly default parameters (I know, I know, backwards compatibility...) but because you never know what parameters people may be using with resizers. Actually it may be that Gaussresize is the only other filter currently affected because of its p parameter, but I think it would be good practice to skip this premature optimisation anyway, to protect any future changes.

[StainlessS]

A long time ago, I pointed out ... Bicubicresize,

Post by Colors[I think he's talking bout same thing]:- https://forum.doom9.org/showthread.php?p=1689608#post1689608

Long Time Ago Wonkey Thread:- https://forum.doom9.org/showthread.php?p=1849699

[pinterf]

But it shouldn't, and I seem to remember this skip was removed when I pointed out the problem (I can't remember if pinterf was running the show at the time), which is that doing this skip results in a discontinuity when using bicubicresize.

I have found:

20181218 r2768
- Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces


One single case remained though when frame is unaltered : when starting from exact x = 0 (or y = 0) and use exact width (height).

Horizontal and vertical cases are decided separately.

https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/resample.cpp#L2464

[pinterf]

VS r1 has identical output to AddGrainC 1.71.
The difference comes from here (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-AddGrain/commit/8f272c4b7aa3c32e5f6e2b19b20ff4dcb8dad481).
Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

[MeteorRain]

Do you guys have a list of tools+functions+parameters path combination that you think are critical (widely used by various of scripts) but lack AVX optimization or internal parallelism that I should start looking soon?

I'm thinking about mvtools and mask tools, but then I wonder if there are hot paths that I should focus on first because they are pretty huge.

[ChaosKing]

The only filters I can think of right now would be removegrain + nnedi3, maybe also dfttest.

[pinterf]

Is there any benefit of internal parallelism in real life other than in synthetic single-threaded tests?

[Boulder]

Do you guys have a list of tools+functions+parameters path combination that you think are critical (widely used by various of scripts) but lack AVX optimization or internal parallelism that I should start looking soon?

I'm thinking about mvtools and mask tools, but then I wonder if there are hot paths that I should focus on first because they are pretty huge.

Those two are probably things that are shared by many functions and processes, MaskTools maybe the bigger portion. Maybe you could get some AVX2 things off the Vapoursynth core ported?

[MeteorRain]

Is there any benefit of internal parallelism in real life other than in synthetic single-threaded tests?

You can imagine I'm still not a fan of MT flavor~:devil:

[pinterf]

Well, you could try mvtools2.

- replace existing internal mt of mvtools which is not portable (possible linux build in mind) and requires an external avstp dll.
It was probably written well before that any standard mutex or threading concept appeared in C++ standards.

Supported functions have a bool "mt" parameter, search for them in mvtools2.html in the documentation.

- (portability) where dct 1..4 is used in the analysis, there fftw library is used (except for 8 bit 8x8 blocks which case is using integer fft)

I have done smaller and larger cleanups in the past, even succeeded to build the source with clang just this week.

[Reel.Deel]

Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

Thank you pinterf. You're awesome! :)

I updated the wiki also, I know you always do it but your time is too valuable to be doing those things.


****
Edit: I think the syntax for AddGrain() you be kept as it originally was for compatibility with some older scripts (one example: MCSpuds (http://avisynth.nl/index.php/MC_Spuds)). I don't there are many that use AddGrain(). The VS version was ported and just stuck with the syntax of AddGrainC but without the C. VS started from scratch so it was not a problem since all of the scripts had to be re-written anyways.

[jpsdr]

The only filters I can think of right now would be removegrain + nnedi3, maybe also dfttest.
I've allready added AVX and AVX2 on nnedi3, and it always had internal multi-threading since the begining, even before i work on it.

[FranceBB]

Fixed in AddGrainC 1.8, test it please
https://github.com/pinterf/AddGrainC/releases/tag/v1.8

Version resource and simd optimizations were lost during vs port, I have put them back.

On the changelog I read

"Support Avisynth+ high bit depth"

however when I try to use it with 10bit planar or 16bit planar, it reports an access violation.
This is a pretty silly test, however it makes it crash:

ColorBars(width=848, height=480, pixel_type="YV24")

ConvertBits(10)

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

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

so does this:


ColorBars(width=848, height=480, pixel_type="YV24")

ConvertBits(16)

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


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

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

while the 8bit planar one works like a charm:

ColorBars(width=848, height=480, pixel_type="YV24")

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

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

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

I thought the culprit was the fact that it was 4:4:4, but even specifying 4:2:0 doesn't help with high bit depth:

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

ConvertBits(16)

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

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

however if I use the default values, it works:


ColorBarsHD(width=704, height=396, pixel_type="YV24")

ConvertBits(16)

AddGrainC()


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


Is there something I should be aware of when I use the parameters with high bit depth? Like they don't scale automatically and cause some kind of error or something?

[pinterf]

Investigating

[pinterf]

Cannot reproduce. Is it the same Avisynth version (my second test build) which you had troubles with?

[pinterf]

Thank you pinterf. You're awesome! :)

I updated the wiki also, I know you always do it but your time is too valuable to be doing those things.


****
Edit: I think the syntax for AddGrain() you be kept as it originally was for compatibility with some older scripts (one example: MCSpuds (http://avisynth.nl/index.php/MC_Spuds)). I don't there are many that use AddGrain(). The VS version was ported and just stuck with the syntax of AddGrainC but without the C. VS started from scratch so it was not a problem since all of the scripts had to be re-written anyways.

Thanks, reasonable request.

[pinterf]

Next test please

https://github.com/pinterf/AddGrainC/releases/tag/v1.8.1

Original parameters restored, simd noise blocks use now unaligned load (possible solution to FranceBB's crash?)

[FranceBB]

Is it the same Avisynth version (my second test build) which you had troubles with?

Nope, it's AviSynth+ 3.5 (r3106, 3.5, i386) (3.5.0.0)

Next test please

https://github.com/pinterf/AddGrainC/releases/tag/v1.8.1

Original parameters restored, simd noise blocks use now unaligned load (possible solution to FranceBB's crash?)

You did it. Now it works fine.
Thanks. :)

[MeteorRain]

Had some time looking at mvtools and masktools, they are pretty huge and hard to start. I may try to run QTGMC and MCTD and find the hottest path and see if there's anything I can improve.

Masktools, it's possible I'll start from F2's float version and improve from there. So, likely you'll see neo_masktools in a few weeks if everything goes right.

Another thing that I'm looking is dfttest. dfttest-avs has some WIN32 APIs, and there's vapoursynth-dfttest ported by holy. Maybe it's a good idea to combine them into one that would support AVS on Linux. As usual, I'll find a chance to remove YUY2 support, if there's any. And will change the plugin name if it breaks backward compatibility.

[pinterf]

You mean, mvtools-float? It is full floating point I think, even the hottest path: the SAD calculation.
Latest avs mvtools can do float as well, I separated the motion vector clip format from the format of the clip to process. Do motion vector search on 8 or 10-16 bits and use the results on whatever bit depth clip you have. As mv search is the bottleneck, speed penalty is minimal.
Avs mvtools has finer granularity in block sizes 2-3-6-8-12-16-24...64, vs stayed at original sizes but it has even 128 sized blocks. Avs mdegrain supports 16 bit output from 8 bit inputs.
Vs versions have much nicer code, my next move would be drop yuy2 support, drop stacked (probably there are people who don't even know what it is ) support and re-do the internal MT. Just because this complex codebase is non-maintanable. Four or five years ago I had to keep compatibility with the ancient software infrastructure, but by 2020 things has been changed.

[Stereodude]

If you get really bored > 8-bit support for MCTD would be nice. :)

[MeteorRain]

Thanks, pinterf, for the information. I may take a look at the differences between the 2 before deciding what to do. My plan was to take mvsf as a starting point, gradually adding back functions from the avs version. Considering float version having a higher precision I wonder if it makes sense to have a uint16 internal process variation -- more precise than uint8 but faster than float or double?

At this point, internal MT (C++PSTL), AVX2(Intrinsics), HBD(Template functions) and dual synth interface(wrapper) are the main reasons I'm refactoring these code. I'd like to see MCTD running on AVS+ Linux with zero glitch and at a reasonable speed. A side effect for dual synth interface is of course hopefully reducing the chance of market fragmentation.

BTW I just rewrote the temporal median into dual synth interface early this week. Benchmark speed is amazing with AVX2.

Stereodude, that's definitely what I'm approaching.

[pinterf]

It is even very hard to decide whether 8 or 16 bit clip based motion vector search is better. SAD calculation and comparison is the key, I think it is overkill to use double SADs (note that a 32 bit float may have even less precision at these scales than 32 bit int, double should be used. In classic integer SAD mvtools versions 8 bit SAD code is handcrafted asm which is borrowed from the x264/265 project and I think it has reached its optimization limit. Since the typical blocksize is 8x8 or 16x16 avx2 is not even considered there. Motion vectors however are of greater precision in F2's version, and can cover of greater length, classic mvtools is using s7.8 short precision for them. Still I don't think that it's a deal-breaker difference. But the outer filters that are using the result of the core motion vector search can be optimized, but since the bottleneck is mv search, moving a part from SSE2 to AVX2 can result in <1% benefit if any and even less if looking at a whole qtgmc process. And another difference between integer SAD based vs and avs mvtools: vs version is always using 64 bit for summing up SAD (mainly because of supporting 128x128 blocksize @16bit @3 planes needed it), avs mvtools is using 64 bits ("bigsad_t") when it is needed. Thus avs code is a bit more complex, but is possibly quicker at 8 bit clips.

But since you are not tied to the historical things and I can see clearly that you like the "art" side of programming rather than living with ancient hacks, if I were you I'd take F2's code, as you have said. I can imagine that it would even take less time than to understand and kick away a hack then another hack and another in an infinite loop.

[tormento]

Things are getting interesting here. :)

[MeteorRain]

But since you are not tied to the historical things and I can see clearly that you like the "art" side of programming rather than living with ancient hacks.

:devil: My rule is if there's an ancient alternative running for old folks I'd be happy to ditch the historical part. For example, for those who still need ancient fft3dfilter options they can keep using that, for those who don't, they can migrate to neo_ variant. The fact that my update still keeps pure C and SSE/SSE2 tells a lot about my point of supporting old folks -- if there's no significant overhead.

I'll take your information as a food for though. Let's see if I'll be able to work out something.

[pinterf]

Pure C is essential as a reference. How I hate reverse engineering those many hundred lines inline assembler (which is then able to run faster from C with modern compilers) Other than that I'd target only sse4.1, avx2 and avx512 options

[MeteorRain]

IKR! IT() is one of them and good god that's pure MMX code core functions. Took me days just to extract C code out of MMX, so much pain there.

[tormento]

Somethings buzzes in my mind since yesterday afternoon: what sense has SetMemoryMax now, at least on x64 systems?

We have all at least 8GB of RAM, wouldn't be easier to let AVS+ allocate the RAM it needs with no useless declarations?

[LigH]

Imagine running several processes in parallel ...

[real.finder]

IKR! IT() is one of them and good god that's pure MMX code core functions. Took me days just to extract C code out of MMX, so much pain there.

you can try a new challenge http://forum.doom9.net/showthread.php?p=1882073#post1882073 :D

also Reel.Deel said that the default for the original VerticalCleaner is 2, in RgTools the default is 1.
also here http://avisynth.nl/index.php/RgTools/VerticalCleaner

so RgTools should do same (should back to 2)

[tormento]

Imagine running several processes in parallel ...
Well, tell me a good value for SetMemoryMax and how is it respected.

I use SetMemoryMax(8000) simply because with 16GB of ram, I really don't know what value to put.

From Wiki:

In Avisynth+ this limit for default Memory Max is 1024MB for 32 bits and 4096MB on the x64 version

Well, 8000 seems to be valid too.

@pinterf?

[StainlessS]

SetMemoryMax, Max amount for frame cache, how many frames you reckon you is gonna need cachin' for your mega massive script ?
8000, is probably way overkill [I would think].

Anyways, I aint never played with 4K never mind 8K, but why not try test with (8000) cache, and your script, and then again with (4000, or maybe 2000), any speed diff ?

Setting too high a cache does nothing good, IanB has made many/(well some) posts about overkill where people allocated ridiculous amounts of mem, just
because they felt the need to justify purchase of their huge RAM sticks.

Several Processes In Parallel, might want to limit current script to NOT use all available RAM, because you want to also run another few scripts at same time,
limiting current script usage ensures that subsequent scripts also have some ram to play with.

EDIT Give your script loads of RAM with typical max RAM usage script, and see what RAM usage AvsMeter shows, then set to a little above what AvsMeter shows.

EDIT:
Where are people getting the crazy idea that a big SetMemoryMax is ever a good idea.

I have searched the forum numerous times looking for any fud and misinformational posts and I do not find any, all I find are the occasional post advising to turn it down. and lots of posts with people using insanely high values and having problems.

SetMemoryMax just sets the size of the Avisynth frame cache!

It does not control any other memory usage!

The frame cache only needs to be just large enough to hold the temporal requirements of the script. If a script has no temporal requirements, i.e. a frame that is required more than once in some part of the script then the cache is completely useless and may prevent some other memory usage from being able to malloc the memory that it needs to work.

A 1920x1080 YV12 video frame is ~3meg, as RGB32 it is 8meg, you can hold 64 such frames in 512meg. YV12 720x480 frames are only 0.5meg you can hold 1024 in 512 meg.

It takes some resources to manage the frame cache so doing a SetMemoryMax(2048) for a SD video and having 4000 odd buffers in play is just stupid and will actually slow the script processing down a little bit.

Advise :- SetMemoryMax, Turn it down!

[tormento]

Anyways, I aint never played with 4K never mind 8K, but why not try test with (8000) cache, and your script, and then again with (4000, or maybe 2000), any speed diff ?
To tell you the truth, I am currently limited by video memory, as I extensively use both CUDA and OpenCL. I have to limit multithreading to the number of threads that don't saturate my video card which, unfortunately, has 3GB of DDRx only.

On 4k I have to use 1 thread only, as a single frame process can saturate it. On 2k I can go up to 6 thread.

I will make some trials with AVSMeter and tell you actual used resources.

I know the post of IanB but it was referred to ancient AviSynth. I don't know what happened since AviSynth+ and if his considerations are still valid, higher color spaces given.

[StainlessS]

I don't know what happened since AviSynth+ and if his considerations are still valid
Well HBD frames are of course bigger (size x2 for 16 bit and x4 float) compared to sizes given above by IanB, Avs+ is actually less greedy on cache requirements than Avs Std,
so for same frame size would require less cache than avs std. 32 bit still limited in available memory, I assume you are using x64 else SetMemoryMax(8000) would not even work.
By the way, SetMemoryMax() on its own returns the size that avs is using.

Maybe something like

m=SetMemoryMax()
blankclip
Subtitle(String(m,"MemMax = %.0f"))


would show the default for your memory size. [with old x86 avs std, was I think half available|free RAM limited to max 500MB].

EDIT: You might even try a SetMemoryMax(8000) before above script, to see if Avs+ actually sets the value requested, or limits it assuming that you are daft.
(It probably does not limit it, assuming that you are not daft)

[StainlessS]

Default Memory Max on my machine with 12GB RAM, x86 1024MB, x64 3055MB [seems a bit high but I guess deliberate in case of HBD, probably fine if you got plenty RAM].
x64, 3055MB Looks to be about Available RAM / 3 [9295 / 3 = 3098MB]

Output from AvsInit.avsi (x86)

00000251 0.00000000 [3108] AvsInit:
00000252 0.00005326 [3108] AvsInit: Auto load plugins script ENTRY
00000253 0.00010580 [3108] AvsInit:
00000254 0.00377458 [3108] AvsInit_ShowInfo:
00000255 0.00380937 [3108] AvsInit_ShowInfo: AvsInit_Version = 1.10
00000256 0.00385103 [3108] AvsInit_ShowInfo: RT_Stats Version = 2.00Beta12
00000257 0.00389197 [3108] AvsInit_ShowInfo: SysInfo Version = 0.115000
00000258 0.00393473 [3108] AvsInit_ShowInfo: VersionString = AviSynth+ 3.5 (r3072, master, i386)
00000259 0.00397531 [3108] AvsInit_ShowInfo: SetMemoryMax = 1024
00000260 0.00401733 [3108] AvsInit_ShowInfo: GScript Available = AVS+
00000261 0.00405900 [3108] AvsInit_ShowInfo: OS Bitness = 64
00000262 0.00410175 [3108] AvsInit_ShowInfo: Avisynth Bitness = 32
00000263 0.00414487 [3108] AvsInit_ShowInfo: WorkingDir = C:\VideoTools\AvisynthRepository\AVSPLUS_x86\plugins\
00000264 0.00418545 [3108] AvsInit_ShowInfo: ProcessName = C:\Program Files (x86)\DAUM\PotPlayer\PotPlayerMini.exe
00000265 0.00422784 [3108] AvsInit_ShowInfo: ParentProcessName = PSPad.exe
00000266 0.00426914 [3108] AvsInit_ShowInfo: OSVersionString = Windows 7 (x64) Service Pack 1.0 (Build 7601)
00000267 0.00431045 [3108] AvsInit_ShowInfo: OSVersionNumber = 6.100000
00000268 0.00435139 [3108] AvsInit_ShowInfo: CPUName = Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz / Yorkfield (Core 2 Quad) 6M
00000269 0.00439305 [3108] AvsInit_ShowInfo: Cores = 04:04 (Phy:Log)
00000270 0.00443436 [3108] AvsInit_ShowInfo: CPU Extensions = MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
00000271 0.00447747 [3108] AvsInit_ShowInfo: Total Memory = 12221MB
00000272 0.00452023 [3108] AvsInit_ShowInfo: Avail Memory = 9161MB'
00000273 0.00456153 [3108] AvsInit_ShowInfo: Screen Res = 1920x1080
00000274 0.00460175 [3108] AvsInit_ShowInfo: Screen BitsPerPixel = 32
00000275 0.00464414 [3108] AvsInit_ShowInfo: Time = Saturday 11 April 2020 11:29:21[GMT Standard Time]
00000276 0.00468544 [3108] AvsInit_ShowInfo: User TEMP Dir = C:\Users\LiquoriceRoot\AppData\Local\Temp
00000277 0.00472674 [3108] AvsInit_ShowInfo: ComSpec = C:\Windows\system32\cmd.exe
00000278 0.00476805 [3108] AvsInit_ShowInfo: Computer Name = PLEX-P2
00000279 0.00480899 [3108] AvsInit_ShowInfo: User Name = LiquoriceRoot


EDIT: And x64

00000543 0.00000000 [1952] AvsInit:
00000544 0.00003333 [1952] AvsInit: Auto load plugins script ENTRY
00000545 0.00006703 [1952] AvsInit:
00000546 0.00352278 [1952] AvsInit_ShowInfo:
00000547 0.00355792 [1952] AvsInit_ShowInfo: AvsInit_Version = 1.10
00000548 0.00359596 [1952] AvsInit_ShowInfo: RT_Stats Version = 2.00Beta12
00000549 0.00363364 [1952] AvsInit_ShowInfo: SysInfo Version = 0.115000
00000550 0.00366661 [1952] AvsInit_ShowInfo: VersionString = AviSynth+ 3.5 (r3072, master, x86_64)
00000551 0.00369886 [1952] AvsInit_ShowInfo: SetMemoryMax = 3055
00000552 0.00373111 [1952] AvsInit_ShowInfo: GScript Available = AVS+
00000553 0.00376444 [1952] AvsInit_ShowInfo: OS Bitness = 64
00000554 0.00379705 [1952] AvsInit_ShowInfo: Avisynth Bitness = 64
00000555 0.00382893 [1952] AvsInit_ShowInfo: WorkingDir = C:\VideoTools\AvisynthRepository\AVSPLUS_x64\plugins\
00000556 0.00386154 [1952] AvsInit_ShowInfo: ProcessName = C:\NON-INSTALL\VDUB\VDUB2\VirtualDub64.exe
00000557 0.00389379 [1952] AvsInit_ShowInfo: ParentProcessName = explorer.exe
00000558 0.00392639 [1952] AvsInit_ShowInfo: OSVersionString = Windows 7 (x64) Service Pack 1.0 (Build 7601)
00000559 0.00395828 [1952] AvsInit_ShowInfo: OSVersionNumber = 6.100000
00000560 0.00399125 [1952] AvsInit_ShowInfo: CPUName = Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz / Yorkfield (Core 2 Quad) 6M
00000561 0.00402386 [1952] AvsInit_ShowInfo: Cores = 04:04 (Phy:Log)
00000562 0.00405683 [1952] AvsInit_ShowInfo: CPU Extensions = MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1
00000563 0.00408907 [1952] AvsInit_ShowInfo: Total Memory = 12221MB
00000564 0.00412132 [1952] AvsInit_ShowInfo: Avail Memory = 9295MB'
00000565 0.00415393 [1952] AvsInit_ShowInfo: Screen Res = 1920x1080
00000566 0.00418617 [1952] AvsInit_ShowInfo: Screen BitsPerPixel = 32
00000567 0.00421987 [1952] AvsInit_ShowInfo: Time = Saturday 11 April 2020 11:38:25[GMT Standard Time]
00000568 0.00425211 [1952] AvsInit_ShowInfo: User TEMP Dir = C:\Users\LiquoriceRoot\AppData\Local\Temp
00000569 0.00428400 [1952] AvsInit_ShowInfo: ComSpec = C:\Windows\system32\cmd.exe
00000570 0.00431624 [1952] AvsInit_ShowInfo: Computer Name = PLEX-P2
00000571 0.00434921 [1952] AvsInit_ShowInfo: User Name = LiquoriceRoot
00000572 0.00438146 [1952] AvsInit_ShowInfo:


EDIT: SetMemoryMax(8000) on my system does indeed set memory Max to 8000.

[Groucho2004]

I will make some trials with AVSMeter and tell you actual used resources.

I know the post of IanB but it was referred to ancient AviSynth. I don't know what happened since AviSynth+ and if his considerations are still valid, higher color spaces given.
The proper way to do it with AVS+:

Put your SetMemoryMax() line on top of the script.
Put "SetLogParams("stdout", LOG_WARNING)" on the next line.
Run AVSMeter(64) and watch out for this warning:
"Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax()"

Increase the value for SetMemoryMax() until the warning disappears.

[Selur]

Trying to using ScriptClip with Subtitle to see the current frame number.
I see the frame number, but the align I gets ignored, it's always at the default align=7, even if I use align=4 in my code:
LoadCPlugin("I:\WORKSP~2\Hybrid\debug\32bit\AVISYN~1\ffms2.dll")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\YUV422_sample.avi
# input color sampling YUY2
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\INTERL~1\INTERL~1\YUV422~1.AVI",cachefile="E:\Temp\avi_1deca8d5573c8cb8cd8489678b764f38_853323747_1_0.ffindex",fpsnum=25,colorspace="YUY2")
# current resolution: 720x576
# filtering
# color modifications
Levels(0,1.50,255,0,255)
# adding frame number
ScriptClip("Subtitle(string(current_frame),align=4)")
# Reinterlacing since interlaced output is requested
ConvertToYV12(matrix="Rec601", interlaced=true)
PreFetch(8)
return last
I also tried:
ScriptClip("""Subtitle(string(current_frame),align=4)""")
but I don't see where I go wrong.

-> Can someone tell me how to properly use ScriptClip to show the current frame number in a way that the alignment works?

Thanks

Cu Selur

Ps.: using Avisynth+ 32bit r3106

[StainlessS]

# Stack Overhead Subtitle Text, with optional FrameNumber shown.
Function TSub(clip c,string Tit,Bool "ShowFrameNo",Int "Col"){
c.BlankClip(height=20,Color=Default(Col,0))
(Default(ShowFrameNo,False))?ScriptClip("""Subtitle(String(current_frame,"%.f] """+Tit+""""))"""):Trim(0,-1).Subtitle(Tit)
Return StackVertical(c).AudioDubEx(c)
}

Colorbars

SHOW=True

TIT="Hello World"

#TSub(TIT,SHOW)

ScriptClip("""Subtitle(String(current_frame,"%.f] """+Tit+""""))""")

Prefetch(4)


EDIT: Crap, you are right, align does not work with Prefetch, I guess I forgot about that when I was installing same version Avs as you.

Dont work.

Colorbars
TIT="Hello World"
#ScriptClip("""Subtitle(String(current_frame,"%.f] """+Tit+""""),align=4)""")
ScriptClip("Subtitle(string(current_frame),align=4)") # EDIT: Or shorter without additional subtitle string, still BUG
BUG=True # <<<<<<<< TOGGLE BUG
(BUG) ? Prefetch(4) : NOP
Return Last


EDIT: No align bug in v3.5 r3072.

[real.finder]

try with https://forum.doom9.org/showthread.php?p=1906016#post1906016

seems fine

[Selur]

@real.finder: I can confirm that version works fine. :)

[videoh]

BTW I just rewrote the temporal median into dual synth interface early this week. Thank you, MeteorRain, for giving the code under MIT license. Fabulous. Hoping it can help to eliminate code duplication from DGSource(). Built it in VS17 and it runs fine. Really great stuff!

Have to study it closely, though, because like pinterf it's pure C over here. CUDA has C syntax. :p

[MeteorRain]

My pleasure!

[pinterf]

@real.finder: I can confirm that version works fine. :)
This version is still under development, sometimes I'm leaking an actual test version to have feedback whether common functionalities are still working which will happen next week perhaps.

[tormento]

sometimes I'm leaking an actual test version
I use always your bleeding edge releases. :D

[Nuihc88]

And another Avisynth+ test build, please test it thorougly, I need more testers than myself :)

EDIT: link removed until I check real.finder's bug report
EDIT: test build 2nd edition:
https://drive.google.com/open?id=1iZMtqMsHSQNSehAZdyx1C5FZ7PTd-4qw


I just came here to say that this is the fastest (lowest latency) and most stable AviSynth(+) build for real-time usage that i have ever used. Even with the Neo fixes i never would have expected to see latencies or performance this good.

Under 'average stats' MadVR is reporting latencies between 0.2 - 4 ms, averaging <2ms under load with a relatively heavy SVP script, while playing back a 12bit FullHD HEVC encode on a 1.5 decades old computer; while at idle it would be sitting at ~0.15ms...

It's like there's no longer any bottle-necking on the AviSynth side of things; everything just runs incredibly smoothly with no seek glitching and even frame-drop recovery is near-instantaneous.
This build may have rendered AviSynth.dll based performance tweaking obsolete for anything other than synthetic benchmarks.

[tormento]

And another Avisynth+ test build
Would you please put prerelease too on GitHub?

I find them easier to find and get notifications too :D

:thanks:

[real.finder]

another out of the range float problem


ColorBars(width=640, height=480, pixel_type="yv12")
Convertbits(32)
mt_lutxy(last,Invert(),"x x y - 9.9 * +", use_expr=1)
#~ ConvertBits(8)
Converttorgb24

it's ok with ConvertBits(8) but with Converttorgb24() it's not

[pinterf]

There are 3 conversions there, to 444, to 8 bit then to rgb. I'm not sure in the order. I wonder which one fails?

[tormento]

Default Memory Max on my machine with 12GB RAM, x86 1024MB, x64 3055MB [seems a bit high but I guess deliberate in case of HBD, probably fine if you got plenty RAM].

I did really simple tests, my target is max FPS only.

SD material

Script:SetMemoryMax(xxxx)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV_x64\DGDecodeNV.dll")
DGSource("E:\in\DVD 1_43 Paradiso + inferno\inferno.dgi",ct=12,cb=12,cl=4,cr=4)
CompTest(1)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)
AVSMeter 2.9.8 (x64), 2012-2020, (c) Groucho2004
AviSynth+ 3.5 (r3132, master, x86_64) (3.5.0.0)

Number of frames: 1568
Length (hh:mm:ss.ms): 00:01:02.720
Frame width: 712
Frame height: 552
Framerate: 25.000 (25000/1000)
Colorspace: YV12
SetMemoryMax(128)
FPS (min | max | average): 2.726 | 1000000 | 23.45
Process memory usage (max): 1057 MiB
Thread count: 77
CPU usage (average): 73.6%
SetMemoryMax(256)
FPS (min | max | average): 2.630 | 1000000 | 23.61
Process memory usage (max): 1061 MiB
Thread count: 77
CPU usage (average): 73.9%
SetMemoryMax(512)
FPS (min | max | average): 3.295 | 1000000 | 23.65
Process memory usage (max): 1066 MiB
Thread count: 77
CPU usage (average): 73.8%
SetMemoryMax(1000)
FPS (min | max | average): 3.101 | 1000000 | 23.65
Process memory usage (max): 1064 MiB
Thread count: 77
CPU usage (average): 73.8%
SetMemoryMax(2000)
FPS (min | max | average): 2.826 | 1000000 | 23.65
Process memory usage (max): 1067 MiB
Thread count: 77
CPU usage (average): 73.9%
SetMemoryMax(4000)
FPS (min | max | average): 3.313 | 1000000 | 23.56
Process memory usage (max): 1062 MiB
Thread count: 77
CPU usage (average): 73.6%
SetMemoryMax(8000)
FPS (min | max | average): 3.515 | 1000000 | 23.51
Process memory usage (max): 1062 MiB
Thread count: 77
CPU usage (average): 73.7%

HD material

Script:SetMemoryMax(xxxx)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\eseguibili\media\DGDecNV_x64\DGDecodeNV.dll")
DGSource("E:\in\1_40 Alla ricerca di Nemo\nemo.dgi")
CompTest(1)
SMDegrain (tr=4, thSAD=500, refinemotion=false, n16=true, mode=0, contrasharp=false, PreFilter=4, truemotion=false, plane=4, chroma=true)
Prefetch(6)
AVSMeter 2.9.8 (x64), 2012-2020, (c) Groucho2004
AviSynth+ 3.5 (r3132, master, x86_64) (3.5.0.0)

Number of frames: 1456
Length (hh:mm:ss.ms): 00:01:00.727
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YV12
SetMemoryMax(128)
FPS (min | max | average): 1.308 | 454542 | 11.16
Process memory usage (max): 1243 MiB
Thread count: 77
CPU usage (average): 66.3%
SetMemoryMax(256)
FPS (min | max | average): 1.946 | 285712 | 11.50
Process memory usage (max): 1241 MiB
Thread count: 77
CPU usage (average): 67.8%
SetMemoryMax(512)
FPS (min | max | average): 1.772 | 232556 | 12.43
Process memory usage (max): 1341 MiB
Thread count: 77
CPU usage (average): 69.4%
SetMemoryMax(1000)
FPS (min | max | average): 1.690 | 270268 | 12.38
Process memory usage (max): 1353 MiB
Thread count: 77
CPU usage (average): 69.0%
SetMemoryMax(2000)
FPS (min | max | average): 1.892 | 277780 | 12.17
Process memory usage (max): 1344 MiB
Thread count: 77
CPU usage (average): 69.0%
SetMemoryMax(4000)
FPS (min | max | average): 1.716 | 294115 | 12.16
Process memory usage (max): 1336 MiB
Thread count: 77
CPU usage (average): 68.6%
SetMemoryMax(8000)
FPS (min | max | average): 2.071 | 232560 | 12.24
Process memory usage (max): 1355 MiB
Thread count: 77
CPU usage (average): 68.9%
SetMemoryMax()
FPS (min | max | average): 1.830 | 263160 | 12.38
Process memory usage (max): 1358 MiB
Thread count: 77
CPU usage (average): 69.2%
Well, it seems we have a winner: SetMemoryMax(512). :D

SetMemoryMax have impact on encoding speed too.

HD material (the same above)

x264_x64.exe --output-depth 8 --crf 20.0 --preset slow --tune animation --profile high --level 4.1 --keyint 240 --aq-mode 2 --sar 1:1 --output "nemoxxxx.mkv" --frames 1456 --demuxer y4m --stdin y4m

SetMemoryMax(256): 2.99 FPS
SetMemoryMax(512): 8.95 FPS
SetMemoryMax(1000): 8.28 FPS
SetMemoryMax(2000): 8.44 FPS
SetMemoryMax(4000): 8.65 FPS
SetMemoryMax(8000): 8.80 FPS
SetMemoryMax(): 9.12 FPS

Setting tr=6 in SMDegrain and repeating the three bests:

SetMemoryMax(512): 6.52 FPS
SetMemoryMax(8000): 6.68 FPS
SetMemoryMax(): 6.83 FPS

And, as I perhaps suffer from OCD, I redid the test for SD.

SD material (the same above)

x264_x64.exe" --output-depth 8 --crf 20.0 --preset slow --profile high --level 4.1 --keyint 240 --aq-mode 2 --sar 64:45 --output infernoxxxx.mkv --frames 1568 --demuxer y4m --stdin y4m

tr=4

SetMemoryMax(512): 18.79 FPS
SetMemoryMax(8000): 18.83 FPS
SetMemoryMax(): 19:15 FPS

tr=6

SetMemoryMax(512): 13.30 FPS
SetMemoryMax(8000): 14.22 FPS
SetMemoryMax(): 13.40 FPS

Fluctuations are so small that, apart SetMemoryMax(256), we can't tell who is the real winner. Better to minimize occupied RAM or to leave lot of space for AVS to work?

Anyway, I will leave SetMemoryMax(8000).

[StainlessS]

What is your default [EDIT: x64] SetMemorymax ? [and installed RAM]
Avs+ default is probably gonna be a good all around choice.

Latest updates to Avs+ and Mvtools etc seem to be kicking ass as far as speed goes (nice one guys).

EDIT:

BlankClip.Subtitle(String(SetMemoryMax)) # using x86[1024MB] and x64[???] app

[tormento]

What is your default [EDIT: x64] SetMemorymax ? [and installed RAM]
8000 with 16GB installed on x64 Windows 10 enterprise.
Avs+ default is probably gonna be a good all around choice.
I agree. That's why I keep on using it. :D


BlankClip.Subtitle(String(SetMemoryMax)) # using x86[1024MB] and x64[???] app

Do you want me to execute that? You need some patience as I am encoding a loooooong job :D

[StainlessS]

Do you want me to execute that?
Nope, no point really, just shows Avs default setMemoryMax, and as you are encoding, so available ram reduced and will show
what is available for 2nd instance of Avs+ if you were to create one.

When I said "What is your default", I meant result of that blankclip script which shows the avs+ default, not what you set YOUR chosen SetMemoryMax at.
My default was about 3550MB on 12GB ram/9GB avail .

[tormento]

Nope, no point really
Isn't the AVSMeter a good indicator of how much RAM is used?

The funny thing about SetMemoryMax() is I can't find any reference of what it does when no parameter is given.

Now I am encoding almost everything with SetMemoryMax() instead of SetMemoryMax(8000) as it seems to give a little better speed for the reels and the script I encode.

[MeteorRain]

Do we have arrays as parameters in AVS+ now? Or are we still limited by passing strings? I'm looking at dfttest, and while vapoursynth version has moved to arrays, the original version still uses strings.

[StainlessS]

tormento,
UsedMB=SetMemoryMax() or UsedMB=SetMemoryMax(0) returns the currently used amount, so SetMemoryMax() without assigning to anything is a NOP, well does nothing useful.


SetMemoryMax

SetMemoryMax(amount)
Sets the maximum memory that AviSynth uses (in MB) to the value of amount. Setting to zero just returns the current Memory Max value. In the 2.5 series the default Memory Max value is 25% of the free physical memory, with a minimum of 16MB.
The default Memory Max is also limited to 512MB.
In Avisynth+ this limit for default Memory Max is 1024MB for 32 bits and 4096MB on the x64 version
DefaultMemoryMax = minimum(physical_memory / 4, secondary_memory_max_limit)
for classic Avisynth see the table below

Free memory <64 128 256 512 1024 2048 3072
Default Max 16 32 64 192 448 512 512

In some versions there is a default setting of 5MB, which is quite low. If you encounter problems (e.g. low speed) try to set this values to at least 32MB. Too high values can result in crashes because of 2GB address space limit.
Return value: Actual MemoryMax value set.

Examples:

SetMemoryMax(128)

SetMemoryMax

SetMemoryMax(amount)
Sets the maximum memory that AviSynth uses (in MB) to the value of amount. Setting to zero just returns the current Memory Max value. In the 2.5 series the default Memory Max value is 25% of the free physical memory, with a minimum of 16MB.
The default Memory Max is also limited to 512MB.
In Avisynth+ this limit for default Memory Max is 1024MB for 32 bits and 4096MB on the x64 version
DefaultMemoryMax = minimum(physical_memory / 4, secondary_memory_max_limit)
for classic Avisynth see the table below

Free memory <64 128 256 512 1024 2048 3072
Default Max 16 32 64 192 448 512 512

In some versions there is a default setting of 5MB, which is quite low. If you encounter problems (e.g. low speed) try to set this values to at least 32MB. Too high values can result in crashes because of 2GB address space limit.
Return value: Actual MemoryMax value set.

Examples:

SetMemoryMax(128)

http://avisynth.nl/index.php/Internal_functions#SetMemoryMax

MeteorRain,
Do we have arrays as parameters in AVS+ now?
[EDIT: Below how it was, apparently is changed as per later posts]
Arrays cannot be implemented for script so long as Avs+ supports v2.58 dll loading. [ AvisynthPluginInit2() ]

Arrays have always been usable within C/CPP dll.

So cannot call script or dll function from within script using any arrays.

Exception is where dll accepts any 0 or more, OR 1 or more, args of a type where avisynth converts to array when calling dll (or builtin).
eg

c2=SomeDllFunction(clip, Int1, int2, int3, int4, int5,"Hello") # dll gets array of 5 int.

You cannot create an array in script, nor can a script function accept an array.

From Framesel() source

env->AddFunction("FrameSel", "ci*[SCmd]s[Cmd]s[Show]b[Ver]b[Reject]b[Ordered]b[Debug]b[Extract]i", Create_FrameSel, 0);
// The AddFunction has the following paramters:
// AddFunction(Filtername , Arguments, Function to call,0);

// Arguments is a string that defines the types and optional nicknames of the arguments for you filter.
// c - Video Clip
// i - Integer number
// f - Float number
// s - String
// b - boolean
// . - Any type (dot)
// Array Specifiers
// i* - Integer Array, zero or more
// i+ - Integer Array, one or more
// .* - Any type Array, zero or more
// .+ - Any type Array, one or more
// Etc


So FrameSel dll script documentation prototype as so

FrameSel(Clip, int F1, ... , int Fn, string "scmd"="",string "cmd"="", bool "show"=false, bool "ver"=false,bool "reject"=false,bool "ordered"=true,bool "debug"=false, int "Extract"=1)

Where dll function has variable number of arguements of a type ie Array, then any arg following the array must be of a different type [otherwise Avs does not know where variable number
of args ends] OR, MUST be called using name of the arg following the variable number of args.
eg

SomeFunction(int Int1, ... ,int IntN, Int "Fred"=0)

If above must be called with fred arg, then must call as eg

x=SomeFunction(int1,int2,int3,int4,Fred=42) # Must be called with Fred=42 otherwise 42 added to IntN array and Fred assigned default 0.

[qyot27]

Do we have arrays as parameters in AVS+ now? Or are we still limited by passing strings? I'm looking at dfttest, and while vapoursynth version has moved to arrays, the original version still uses strings.
On Windows, no. Unless you're using a custom build where you passed -DNEW_AVSVALUE to the CXXFLAGS.

On POSIX, yes. NEW_AVSVALUE is on by default on non-Windows.

[pinterf]

On Windows, no. Unless you're using a custom build where you passed -DNEW_AVSVALUE to the CXXFLAGS.

On POSIX, yes. NEW_AVSVALUE is on by default on non-Windows.
Yes, for arrays and other forecoming features I recommend reading the first ~400 lines:
https://github.com/pinterf/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt

edit: if I remember well, in NEW_AVSVALUE build colors can be passed to BlankClip in array-style as well.

[MeteorRain]

So is the code same for getting values from arrays?
_args[idx].IsArray() -> _args[idx].ArraySize() -> _args[idx][i].AsInt()

[pinterf]

Yes. But even if parameter definition allows arrays, for length=1 the parameter will appear as a single non-array of a specific value
(covering such cases when parameter list of variable number of elements is only a single integer for example and it is not put into an array, it remains as a single integer AVSValue)

Plus: even is such single values are not IsArray, ArraySize will report 1, and you can access it as [0].

For example here, in ConditionalSelect, args[2] can be an array of clips or a single clip.
https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/filters/conditional/conditional.cpp#L228

NEW_AVSVALUE considerations:
Arrays in the above form cannot be named parameters, nor can they be provided as the new [] syntax.
Unnamed or named (and even zero sized) array can appear as specific parameter.

With new AVSValue concept arrays can have arbitrary deepness, with mixed type of elements, and are always "deep copy"-ed (except on the plain C interface)

Handling and parameter list
https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/filters/source.cpp#L419
https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/filters/source.cpp#L2020

Definition (using specific 'a' as parameter type):
As NEW_AVSVALUE is no in the mainstream Windows build, this option is not really documented other than in my readme_xxx.txt.

Original BlankClip definitions
"[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[stereo]b[sixteen_bit]b[color]i[color_yuv]i[clip]c
[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c

Extra BlankClip definitions, allow calling with e.g. BlankClip(colors = [4095, 12, 2311])

[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[stereo]b[sixteen_bit]b[color]i[color_yuv]i[clip]c[colors]a
[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]a

[MeteorRain]

I understand that NEW_AVSVALUE is not yet on mainstream Windows, but it is expected to be on Windows at a later time, right?

Regarding to prefix 'a', it doesn't have a type that means it's weak typed, right? So basically I can pass anything in and the filter is responsible for checking the type.

And what happens if I put 'a' in function declaration and filter is loaded by a version not supporting arrays? Do I have to keep 2 DLLs for different AVS version?

And --
(covering such cases when parameter list of variable number of elements is only a single integer for example and it is not put into an array, it remains as a single integer AVSValue)
I assume this does not apply to 'a' parameters, right? If I mark a parameter as 'a' and user pass a 1 element array, I should always get IsArray() true, right?

[pinterf]

I understand that NEW_AVSVALUE is not yet on mainstream Windows, but it is expected to be on Windows at a later time, right?

Regarding to prefix 'a', it doesn't have a type that means it's weak typed, right? So basically I can pass anything in and the filter is responsible for checking the type.

Yes, only requirement that it should be an array.

For an 'a' typed parameter parser will allow explicitely defined constant (using [ and ]) or an array typed variable or function return value.


And what happens if I put 'a' in function declaration and filter is loaded by a version not supporting arrays? Do I have to keep 2 DLLs for different AVS version?

I don't know other that trying it.


I assume this does not apply to 'a' parameters, right? If I mark a parameter as 'a' and user pass a 1 element array, I should always get IsArray() true, right?
Yes, such parameters can even have zero length (like a = [], I think there are examples on that in the readme)

[tormento]

UsedMB=SetMemoryMax() or UsedMB=SetMemoryMax(0) returns the currently used amount, so SetMemoryMax() without assigning to anything is a NOP, well does nothing useful.
It can't be a NOP as it has results on encoding speed usually better than put any value.

[feisty2]

So is the code same for getting values from arrays?
_args[idx].IsArray() -> _args[idx].ArraySize() -> _args[idx][i].AsInt()

this is horrifying, it should be simplified to

for (auto x : _args[key])
// do ur thang

[MeteorRain]

Feisty2, all the API here that we've been talking about would have to maintain enough compatibility all the way back to the date when C++03 was not even a thing.

My wrapper would take and return a std::vector which then should support all the fancy stuff ( for (auto &&item : array_param) ) but then the underlying code -- those doing heavy-lifting, would have to use an interface where technology is much outdated.

[real.finder]

[EDIT: Below how it was, apparently is changed as per later posts]
Arrays cannot be implemented for script so long as Avs+ supports v2.58 dll loading. [ AvisynthPluginInit2() ]

I wonder if avs+ could use some wrapper for AvisynthPluginInit2 to not interfere with avs+ features like HBD and Arrays

[feisty2]

adding begin() and end() doesn't harm compatibility, these are the "magic" functions that automatically enable range-for syntax in c++11 and onwards, in older standards, they are simply regular member functions and do not correspond to any magic syntax.

[StainlessS]

It can't be a NOP as it has results on encoding speed usually better than put any value.

Well it aint supposed to do anything other than return the used value.

I wonder if avs+ could use some wrapper for AvisynthPluginInit2 to not interfere with avs+ features like HBD and Arrays
Well I think that the problem was that could not previously support arrays [EDIT: for script] whilst still supporting v2.58 plugins, judging by above posts that problem seems to have been overcome.

https://www.youtube.com/watch?v=PPvRsLWlDXw

Says it all :)

[pinterf]

This whole story with the arrays was more than 3 years ago. It's time to re-test, next package will come with and without arrays.

[Gavino]

It can't be a NOP as it has results on encoding speed usually better than put any value.
But does it give different results than not using it at all?

Perhaps your results just show that the default value is actually optimal.

[real.finder]

can someone make fmtconv port for avs+? https://forum.doom9.org/showthread.php?p=1907352#post1907352

[MeteorRain]

I don't know other that trying it.

So I tried it. Having 'a' as type, the filter would not be possible to be used on non-AVS-newvalue build.

Checking the avs core I noticed that it's possible to manipulate (i.e. abuse) param name to support array hinting.

For example, dft has this:
c[sstring]s[ssx]s[ssy]s[sst]s.

If we can somehow do:
c[sstring]s[ssx]s[ssy]s[sst]s[sstring()]f[ssx()]f[ssy()]f[sst()]f
then we can make the filter working under both versions.

In legacy version, because param names has () in it, we know it's not a valid name and you can't assign data to it by name. To support assigning values by order, obviously we can keep array declaration at the end of param list.

In modern version, the core now knows that these 4 parameters are array of floats and will accept them as both single string or array of floats. Weak type arrays can be flagged as "[name()]."

So if user writes
v.dfttest("a", "b")
you get [v, "a", "b", -, -] in both versions.

And if user writes
v.dfttest([1.0], [2.0])
you get [v, [1.0], [2.0], -, -] in newer versions.

Within filter, simply check if args[1].isArray() to know if user passed in an array or a string.

What do you think about this proposal?

==========

EDIT: I'm generating parameter hinting like this:

for (auto &&p : params)
{
...
if (p.IsOptional) {
ss << '[' << p.Name << ']';
if (p.IsArray) {
ss_arrays << '[' << p.Name << "()]" << type_name;
type_name = 's';
}
}
ss << type_name;
}
return ss.str() + ss_arrays.str();

c[ftype]i[sigma]f[sigma2]f[pmin]f[pmax]f[sbsize]i[smode]i[sosize]i[tbsize]i[tmode]i[tosize]i[swin]i[twin]i
[sbeta]f[tbeta]f[zmean]b[f0beta]f[nlocation]s[alpha]f[slocation]s[ssx]s[ssy]s[sst]s[ssystem]i[sfile]s[sfile2]s
[dither]i[y]i[u]i[v]i[opt]i[nlocation()]i[slocation()]f[ssx()]f[ssy()]f[sst()]f

[MeteorRain]

Within dfttest, I noticed that, when nstring="0,0,20,40" I get the following error:

Filter error: GetPlaneHeightSubsampling called with supported plane.

Coming from

const int height = proc_height >> vi.GetPlaneHeightSubsampling(b);
const int width = vi_src.width >> vi.GetPlaneWidthSubsampling(b);

where b == 0.

[MeteorRain]

Also within dfttest, threads=0 and threads=1 returns different results, i.e. bit non-identical.

[pinterf]

Within dfttest, I noticed that, when nstring="0,0,20,40" I get the following error:

Filter error: GetPlaneHeightSubsampling called with supported plane.

Coming from

const int height = proc_height >> vi.GetPlaneHeightSubsampling(b);
const int width = vi_src.width >> vi.GetPlaneWidthSubsampling(b);

where b == 0.
Then it probably never worked. 0,1,2 should be translated to actual PLANAR_Y, PLANAR_U, PLANAR_V constants.

[LigH]

It can't be a NOP as it has results on encoding speed usually better than put any value.

Did you also test not using SetMemoryMax at all (opposing to calling it once, but without a value)?

[pinterf]

When your SetMemoryMax parameter is significantly larger than the actual maximum value reported by avsmeter then all results should be identical within an error margin.
Multiple Avsmeter sessions can report fps values within a range. Just have measured a simple script, five runs, no mt, results varied from 6.53 to 6.69. (2,5%)

[tormento]

Did you also test not using SetMemoryMax at all (opposing to calling it once, but without a value)?
Well, now I tried on another, heavier, script and:

SetMemoryMax() 5.83 fps
no SetMemoryMax 5.69 fps

I mean... has with AVS+ and x64 any matter anymore at this point to put SetMemoryMax(xxx)?

[LigH]

A random spread of results is not surprising. Hardware interrupts, file caching, ... if you want to do serious speed tests, don't run each test only once and trust the one result, instead take the minimum of several attempts with the same circumstances.

[magnetite]

I was wondering about something. Some of these filters were built using different compilers, and I'm not sure which compiled version of a filter I should use. In the archive of say, Rgtools 0.98, it lists a clang version and a non-clang version. Does one offer better performance than the other?

[pinterf]

It depends on the usage, RgTools 24 modes are basically 24 different filters. One can be optimized better with clang other modes with msvc.
If you are a poweruser and always measure everything and you find that the mode N which you are frequently using is 4% quicker with clang than with ms version then you can make your decision on clang.
When you are not sure then choose a version with a more sympathic name :)

[MeteorRain]

Yes, they have different ways of optimization and even depth of optimizations.
As I explained before, for example clang would optimize on lower level, so it's possible what you write (even assembly intrinsics) doesn't match what you get, because compiler is smarter than you and emit even better code.
While for example MSVC doesn't do this, and if you write stupid intrinsics it compiles as is.

So it's possible you'll end up with some filters running faster on clang, and some others are faster on msvc.
Only you would know how fast they run.

[wonkey_monkey]

I find that I get better results on the second/third and subsequent runs of Avsmeter. I always discard the first result.

[tormento]

I find that I get better results on the second/third and subsequent runs of Avsmeter. I always discard the first result.
AVSMeter doesn't give the full pie but a slice only.

If you look at my benchmarks, when real encoding is involved, x264/5 can be limited by the cpu time/memory/whatsoever consumed by the script itself.

If it's FPS you are looking for, after an AVSMeter bench, you should go for real ones.

[tormento]

A random spread of results is not surprising.
I took median results.

[Groucho2004]

Remember that AVSMeter is primarily a troubleshooting tool for the frameserving part of an encoding process. For example, if you think your encoding is going too slow, it will help you determine if it's the encoding settings or the script being the bottleneck (or both :scared:).

[wonkey_monkey]

AVSMeter doesn't give the full pie but a slice only.

If you look at my benchmarks, when real encoding is involved, x264/5 can be limited by the cpu time/memory/whatsoever consumed by the script itself.

If it's FPS you are looking for, after an AVSMeter bench, you should go for real ones.

I use it mainly for optimising my filters.

[magnetite]

It depends on the usage, RgTools 24 modes are basically 24 different filters. One can be optimized better with clang other modes with msvc.
If you are a poweruser and always measure everything and you find that the mode N which you are frequently using is 4% quicker with clang than with ms version then you can make your decision on clang.
When you are not sure then choose a version with a more sympathic name :)

I'm someone with very little knowledge of programming other than the complete basics. Sort of like an every day user of Windows instead of the people at Microsoft who programmed it.

[videoh]

You don't have to be a power user or coder, magnetite (love the nick). Just try both ways in your case and see which you like better. Maybe that's all pinterf was trying to say. Lot's of things are empirical because the theory is too hard or things depend on too many factors. Keep us informed about your projects.

[mcjordan]

Dear Pinterf, i have another try to compile your last build of AviSynthPlus (VC2019),
but this time I have two fatal errors that compromise compilation:

3>C:\git\AvisynthPlus_pinterf\avs_core\filters\conditional\conditional_functions.cpp(140,85): error C2653: 'GetPropertyAsArray': is not a class or namespace name
3>C:\git\AvisynthPlus_pinterf\avs_core\filters\conditional\conditional_functions.cpp(140,79): error C2065: 'Create': undeclared identifier

Аs I said earlier I'm not familiar with modern C/C++ programming.
I would be very grateful if you could help me again.

[pinterf]

You are unlucky. This dev branch is still under heavy changes. Pull often. If the problem persists even after I considered my work finished I'll check it.
Edit: I don't know when you had your last successful build, maybe you could regenerate the vs solution from cmake

[mcjordan]

Thank you, Pinterf. Maybe I'm too impatient, but your build is the best.
Happy оrthodox Easter!

[pinterf]

There is no such thing as the best. We know the best. Ha-ha. Long live Avisynth the covideo processing scripting tool

[real.finder]

Is it possible to know if there are duplicate functions in avsi files?

[pinterf]

Just saying that KNLMeansCL (and TMM2 mod by chikuzen) have to be recompiled for the next Avisynth+ since they are is using the non-finalized IScriptEnvironment2 avs+ interface.
KNLMeansCL is using SetFilterMTMode for MT mode hint (sets MT_MULTI_INSTANCE) instead of using the usual cache hints technique.
So it crashes right after adding its functions (AvisynthPluginInit3).
if (env->FunctionExists("SetFilterMTMode")) {
static_cast<IScriptEnvironment2*>(env)->SetFilterMTMode("KNLMeansCL", MT_MULTI_INSTANCE, true);


If there are other plugins that are using IScriptEnvironment2 directly let us know. (But I think you'll recognize that quite soon, even AVSMeter will list it as unusable)

@Groucho2004: could you prepare avsmeter for checking for AVISYNTH_INTERFACE_VERSION 8

[pinterf]

Is it possible to know if there are duplicate functions in avsi files?
If SetLogParams("stderr", 4) is not listing the duplicates (like it does for similarly named DLL functions) than not.
(Or replace stderr with a file name)

[Groucho2004]

@Groucho2004: could you prepare avsmeter for checking for AVISYNTH_INTERFACE_VERSION 8Sure. Are you skipping AVISYNTH_INTERFACE_VERSION 7 or will it serve a different purpose?

[qyot27]

7 exists, er, existed. It just happened about four years late and was true for about a month (it was bumped to 7 between 3.5.0 and 3.5.1, due to the needs of having to declare the SOVERSION for the POSIX builds (https://github.com/AviSynth/AviSynthPlus/commit/40900dc1c54c14ea9f188c7242b88d464d067a44)).

[Groucho2004]

7 exists, er, existed. It just happened about four years late and was true for about a month (it was bumped to 7 between 3.5.0 and 3.5.1, due to the needs of having to declare the SOVERSION for the POSIX builds (https://github.com/AviSynth/AviSynthPlus/commit/40900dc1c54c14ea9f188c7242b88d464d067a44)).Yeah, I only just noticed.

[real.finder]

If SetLogParams("stderr", 4) is not listing the duplicates (like it does for similarly named DLL functions) than not.
(Or replace stderr with a file name)

they not, only one from dll is listed, I asked because when I Analyze some avsi files in order to add HBD to them I note both EdgeCleaner and MC_Spuds has StarMask() with completely differently code but same function name!

[Groucho2004]

I asked because when I Analyze some avsi files in order to add HBD to them I note both EdgeCleaner and MC_Spuds has StarMask() with completely differently code but same function name!So just rename one of them.

[StainlessS]

Suggest either EdgeCleaner_StarMask() or MC_Spuds_StarMask() [or even both].

[real.finder]

that what I will do, but I want to know if there are any others hidden in other avsi functions

[Groucho2004]

that what I will do, but I want to know if there are any others hidden in other avsi functionsThe only way to check this would be to write a small tool that enumerates all functions in a group of avsi files and checks for dups.

Thinking about it, that might be something worth adding to AVSMeter checking not just functions in avsi files but also checking them against internal/external DLL functions.

Any thoughts about the usefulness of this?

[real.finder]

The only way to check this would be to write a small tool that enumerates all functions in a group of avsi files and checks for dups.

Thinking about it, that might be something worth adding to AVSMeter checking not just functions in avsi files but also checking them against internal/external DLL functions.

Any thoughts about the usefulness of this?

I think it is useful if the user has several avsi files, avs+ already has something for DLL functions but make it in AVSMeter will be a useful thing for older avs+ and avs 2.6

[Groucho2004]

I think it is useful if the user has several avsi filesI suppose that there could even be duplicate functions within a single avsi.

avs+ already has something for DLL functionsBut it does not check functions in avsi files against DLL functions, does it?

[real.finder]

But it does not check functions in avsi files against DLL functions, does it?

you mean like Vinverse which has both dll and avsi? yes avs+ don't check this case

[Groucho2004]

you mean like Vinverse which has both dll and avsi? yes avs+ don't check this caseI don't know about Vinverse. However, it's certainly possible for an internal or external (plugin) function having the same name as a function in a loaded avsi in which case I would assume that the DLL function takes precedence.

[StainlessS]

Any thoughts about the usefulness of this?
Yes, Like it.

I would assume that the DLL function takes precedence.
Nope, Script func overrides dll, dll overrides builtin.

Wiki:- http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Name_Precedence
Plugin Autoload and Name Precedence

It is possible to put all plugins and script files with user-defined functions or (global) variables in an autoload directory,
from which all files with the extension .AVSI and .DLL are loaded at startup, then unloaded and reloaded dynamically as the script needs them.

.AVSI scripts in this directory should only contain function definitions and global variables; they should not have a main processing section
(else strange errors may occur). It also is not recommended to put other files in that directory.

The directory is stored in the registry. You can use double-clicking a .REG-file with the following lines to set the path (of course inserting your actual path):

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]
"plugindir2_5"="c:\\program files\\avisynth 2.5\\plugins"

The order in which function names take precedence is as follows:

User-defined function (always have the highest priority)
Plugin (external) function (higher priority than built-in)
Built-in (internal) function

Inside those groups the function loaded last takes precedence; there is no error in a namespace conflict.
It follows that there is no harm in loading the same plugin more than once.[dubious – discuss]


I remember Kassandro dll had a Difference() function, for some reason it took precedence over my script function of same name despite above list (maybe in v2.58).

[Groucho2004]

Nope, Script func overrides dll, dll overrides builtin.I see, who'd a thunk it?

[pinterf]

another out of the range float problem


ColorBars(width=640, height=480, pixel_type="yv12")
Convertbits(32)
mt_lutxy(last,Invert(),"x x y - 9.9 * +", use_expr=1)
#~ ConvertBits(8)
Converttorgb24

it's ok with ConvertBits(8) but with Converttorgb24() it's not

I'd say it's the typical case of garbage in garbage out.

In this case ConvertToRGB24() is the shortcut for ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24()
The problem occurs during 32 bit float 444->RGB conversion.

When you limit Y to 0..1, it all becomes O.K.
Expr("x 0 < 0 x 1.0 > 1 x ? ?","","")
For the same reason, if you convert to lower bit depths, this limitation is automatically done since integer accepts values between 0 and 2^N -1, and out-of-range values are clamped during the conversion.

Note, that in your example at least half of the image have Y<0, even in the-9.0 range, which is way outside of the 0..1.0 range, and of course results in undefined result during YUV->RGB matrix conversion.

[real.finder]

I'd say it's the typical case of garbage in garbage out.

In this case ConvertToRGB24() is the shortcut for ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24()
The problem occurs during 32 bit float 444->RGB conversion.

When you limit Y to 0..1, it all becomes O.K.
Expr("x 0 < 0 x 1.0 > 1 x ? ?","","")
For the same reason, if you convert to lower bit depths, this limitation is automatically done since integer accepts values between 0 and 2^N -1, and out-of-range values are clamped during the conversion.

Note, that in your example at least half of the image have Y<0, even in the-9.0 range, which is way outside of the 0..1.0 range, and of course results in undefined result during YUV->RGB matrix conversion.

but it also ok with
ColorBars(width=640, height=480, pixel_type="yv12")
Convertbits(32)
mt_lutxy(last,Invert(),"x x y - 9.9 * +", use_expr=1)
#~ ConvertBits(8)
Limiter(0,1,-0.5,0.5)
Converttorgb24

[pinterf]

I wonder what's the case with z_ConvertFormat?
Or one could change the order: first convert to 8 bits then to rgb but I chose this processing order to have the more precision for yuv->rgb conversion.

[pinterf]

Does Avisynth have similar thing for RGB like ColorYUV(analyze=true?)

[real.finder]

I wonder what's the case with z_ConvertFormat?
Or one could change the order: first convert to 8 bits then to rgb but I chose this processing order to have the more precision for yuv->rgb conversion.

what about do clamped first? isvideofloat? Limiter(0,1,-0.5,0.5).ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24() : ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24()

at least only for ConvertToRGB24 since it used in preview in avspmod and others

[StvG]

Does Avisynth have similar thing for RGB like ColorYUV(analyze=true?)
RGBAdjust(analyze=true)

[pinterf]

RGBAdjust(analyze=true)
Thanks, seems that there are too many filters for my memory capacity :)

[pinterf]

what about do clamped first? isvideofloat? Limiter(0,1,-0.5,0.5).ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24() : ConvertToYUV444().ConvertToPlanarRGB().ConvertBits(8).ConvertToRGB24()

at least only for ConvertToRGB24 since it used in preview in avspmod and others
Well, I think it was just a good thing, otherwise we could not catch that the mentioned expression is wrong.

[StainlessS]

Thanks, seems that there are too many filters for my memory capacity :)

Suggest 16KB RAM pack upgrade and lump of Bluetack to prevent RAM pack wobble.

[dREV]

Hi, I don't know if this is an AviSynth question or a HEVC one. I wanted to ask is it possible to do a script with both chroma shift and chroma upscale (the tattler I think that's what it does) in 4:2:0 encoding in HEVC similarly with a script below?

This is the script I'm currently using:

dither_convert_8_to_16()
# filter(s)
s16 = last
DitherPost()
# 8 bit filter(s)
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
ly = GradFun3mod(resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

Here's another resize script I also use.

Y = ConvertToY8().dither_resize16(1280,720,kernel="Spline36")src top and left
U = UToY8().dither_resize16(1280,720,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
V = VToY8().dither_resize16(1280,720,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
YToUV(U, V, Y)

I do not understand the language of what it's doing above during resize (ly,lc,lu, yuv) I just like the end results. If someone can either explain or link to an AviSynth wiki so I can sort of understand better I'd appreciate that. I doubt I'll be able to come up with a script.

I get no issues in H264 4:2:0. No issues with HEVC 4:4:4 of course.

Just in case it's asked I am using the correct script in HEVC: --input-depth 16 --profile main10 --input-csp i420 and using AviSynth+ ver 3.5.0. I am also using possibly an out of date avs4x26x (https://astrataro.wordpress.com/2014/08/28/avs4x26x-0-10-0/) if that helps. :D

[real.finder]

Hi, I don't know if this is an AviSynth question or a HEVC one. I wanted to ask is it possible to do a script with both chroma shift and chroma upscale (the tattler I think that's what it does) in 4:2:0 encoding in HEVC similarly with a script below?

This is the script I'm currently using:

dither_convert_8_to_16()
# filter(s)
s16 = last
DitherPost()
# 8 bit filter(s)
dither_convert_8_to_16()
s16.Dither_limit_dif16 (last,)
ly = GradFun3mod(resizer="DebilinearM", lsb_in=true, lsb=true)
lc = nnedi3_resize16(1280*2, 720*2,lsb_in=true,lsb=true,kernel_d="Spline36",kernel_u="Spline36",src_top=0.0,src_left=0.50,nlsb=false)
lu = lc.UtoY()
lv = lc.VtoY()
YtoUV(lu,lv,ly)
Dither_out()

Here's another resize script I also use.

Y = ConvertToY8().dither_resize16(1280,720,kernel="Spline36")src top and left
U = UToY8().dither_resize16(1280,720,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
V = VToY8().dither_resize16(1280,720,kernel="blackmanminlobe",src_top=0.0,src_left=0.25)
YToUV(U, V, Y)

I do not understand the language of what it's doing above during resize (ly,lc,lu, yuv) I just like the end results. If someone can either explain or link to an AviSynth wiki so I can sort of understand better I'd appreciate that. I doubt I'll be able to come up with a script.

I get no issues in H264 4:2:0. No issues with HEVC 4:4:4 of course.

Just in case it's asked I am using the correct script in HEVC: --input-depth 16 --profile main10 --input-csp i420 and using AviSynth+ ver 3.5.0. I am also using possibly an out of date avs4x26x (https://astrataro.wordpress.com/2014/08/28/avs4x26x-0-10-0/) if that helps. :D

seems you missed this post https://forum.doom9.org/showpost.php?p=1906222&postcount=405 :)

also this https://forum.doom9.org/showthread.php?p=1906465#post1906465

[real.finder]

I find something when I try adding HBD for Ylevels by Didée

function Ylevels(clip clp,
\ float "input_low", float "gamma", float "input_high",
\ float "output_low", float "output_high", bool "show_function")
{
sisavs26 = !(VersionNumber() < 2.60)
input_low = Default(input_low, 0)
gamma = Default(gamma, 1.0)
input_high = Default(input_high, 255)
output_low = Default(output_low, 0)
output_high = Default(output_high, 255)
show_function = Default(show_function, false)

wicked = sisavs26 ? "x " +string(input_low)+ " scalef - " +string(input_high)+ " scalef " +string(input_low)+ " scalef - / 1 " +string(gamma)+
\ " / ^ " +string(output_high)+ " scalef " +string(output_low)+ " scalef - * " +string(output_low)+ " scalef +"
\ : "x " +string(input_low)+ " - " +string(input_high)+ " " +string(input_low)+ " - / 1 " +string(gamma)+
\ " / ^ " +string(output_high)+ " " +string(output_low)+ " - * " +string(output_low)+ " +"

return( show_function ? clp.subtitle(wicked) : sisavs26 ? clp.mt_lut(Yexpr = wicked, use_expr=2, U=2,V=2) : clp.mt_lut(Yexpr = wicked, U=2,V=2) )
}


it's ok in 16bit and in float it's ok as I don't set gamma to 1.2

convertbits(32)
Ylevels(40, 1.2, 255, 0, 255, false)
Limiter(0,1,-0.5,0.5)
convertbits(8)

also tried with scale_input="float" but still give white artifacts in dark parts of frame, both with use_expr=2 or without

even if I scale expr with x 255 * and 255 / in the end of expr still same, is there are certain limits if the input is float clip or it's bug?

[pinterf]

How the formula looks like originally that should be implemented with expr?

[real.finder]

How the formula looks like originally that should be implemented with expr?

output = ( (input - input_low) / (input_high - input_low) )^(1 / gamma) * (output_high - output_low) + output_low
as from http://avisynth.nl/index.php/Levels

[StainlessS]

Does mt_Infix() no longer work ? [Win7].


Colorbars(Pixel_type="YV12").ConvertToYV24.ConvertBits(32)
YLevels()
convertToRGB32

# Inside YLevels
RT_DebugF("Wicked = '%s'",wicked)
infix = Mt_Infix(wicked)
RT_DebugF("Infix = '%s'",Infix)



00000315 0.14433271 [4556] RT_DebugF: Wicked = 'x 0 scalef - 255 scalef 0 scalef - / 1 1.000000 / ^ 255 scalef 0 scalef - * 0 scalef +'
00000316 0.14450951 [4556] RT_DebugF: Infix = '(0+)'


EDIT: masktools2_x86(NOT_XP)_2.2.18.dll

EDIT: this works so its not totally broken [error in wicked RPN ? (I dont understand that new scalef stuff) ]

Colorbars
RPN="x y - abs"
IFX=mt_infix(RPN)
RT_DebugF("RPN = '%s'\nIFX = '%s'",RPN,IFX)
Subtitle("RPN = '"+RPN+"'\n"+"IFX = '"+IFX+"'",lsp=0,font="Courier New")

__END__

00000962 0.17500676 [3320] RT_DebugF: RPN = 'x y - abs'
00000963 0.17506003 [3320] RT_DebugF: IFX = 'abs((x-y))'

[pinterf]

1.) We are at 2.2.21 masktools.
2.) I dont remember is scalef is handled in infix.
3.) Probably power 1 is optimized to do nothing. But 1.00001 should give quite similar result. Does it work?
Cannot check, I'm not near my PC

[StainlessS]

1) Yeh, its in my Inbox :(
2.) Seems not in 2.2.18

This looks right after doing scalef thing manually [only for defaults]

Colorbars
RPN="x 0.0 - 1.0 0.0 - / 1 1.0 / ^ 1.0 0.0 - * 0.0 +"
IFX=mt_infix(RPN)
RT_DebugF("RPN = '%s'\nIFX = '%s'",RPN,IFX)
Subtitle("RPN = '"+RPN+"'\n"+"IFX = '"+IFX+"'",lsp=0,font="Courier New")

__END__

00006458 0.14370735 [3704] RT_DebugF: RPN = 'x 0.0 - 1.0 0.0 - / 1 1.0 / ^ 1.0 0.0 - * 0.0 +'
00006459 0.14376387 [3704] RT_DebugF: IFX = '(((((x-0.0)/(1.0-0.0))^(1/1.0))*(1.0-0.0))+0.0)'

#output = ( (input - input_low) / (input_high - input_low) )^(1 / gamma) * (output_high - output_low) + output_low


I'll see bout installing 2.2.21

[pinterf]

(deleted :))

[StainlessS]

(deleted )
Yeh, probably cursing me for not using 2.2.21, sorry :(

Seems ok (InFix scalef thing in 2.2.21, not optimized)

SCRIPT DELETED: See post #5519.

[pinterf]

Regarding the expression, don't apply gamma on negative numbers. Limit it before. " 0 max "

[StainlessS]

EDIT: Oops did not see P Post.

SCRIPT DELETED: See post #5519. [EDIT: Not because of above P post, P was answering RF]

[pinterf]

Checked the code in Levels, there is a proper guard:

if(use_gamma)
p = (float)pow((double)clamp(p, 0.0f, 1.0f), gamma);

[StainlessS]

SCRIPT DELETED: See post #5519.

[real.finder]

the question is why there are no problem when 8-16 bits?

[pinterf]

Masktools and expr is full float inside, there are proper rounding on conversions.

[pinterf]

the question is why there are no problem when 8-16 bits?

Substitute e.g. x=20 and do the same computing as Expr does for both 8 bit and float (20/255.)

[StainlessS]

As in below Pinterf next post.
Just before gamma clamp to 0-1 regardless from the original bit depth. That's why we normalize the range before applying power function.

Just remove these lines to put back the bug [in two places].

\ + "0 max 1 min " [* P = min(max(P , 0.0), 1.0) *]



Function Ylevels(clip clp,
\ float "input_low", float "gamma", float "input_high",
\ float "output_low", float "output_high", bool "show_function")
{
input_low = Default(input_low, 0)
gamma = Default(gamma, 1.0)
input_high = Default(input_high, 255)
output_low = Default(output_low, 0)
output_high = Default(output_high, 255)
show_function = Default(show_function, false)
#
invGam = 1.0 / min(max(0.1,Gamma),10.0) # Sane range, avoid div by zero
divisor = (input_high==input_low) ? 1 : input_high-input_low # Avoid divide by zero
try { bpc = clp.BitsPerComponent } catch(msg) { bpc=8 } # Use scalef only if bpc > 8 (ie Avs+)
#
wicked = (bpc>8) [* Use scalef only if > 8 bit ie Avs+ *]
\ ? "x " +string(input_low)+" scalef - "+string(divisor)+" scalef / " [* P = (input - input_low) / divisor *]
\ + "0 max 1 min " [* P = min(max(P , 0.0), 1.0) *]
\ + string(invGam) + " ^ " [* P = pow(P, 1.0/Gamma) *]
\ + string(output_high)+" scalef " +string(output_low)+" scalef - * "+string(output_low)+" scalef +" [* P = P * (output_high - output_low) + output_low *]
\ : "x " +string(input_low)+" - "+string(divisor)+" / "
\ + "0 max 1 min "
\ + string(invGam) + " ^ "
\ + string(output_high)+" " +string(output_low)+" - * "+string(output_low)+" +"
# UnComment next line to explicitly round & clamp to output range, although Masktools will do this anyway. 32 bit Float NOT rounded. Here as documentation.
# wicked = wicked + ((bpc==32) ? " 0 max 255 scalef min" : (bpc>8) ? " round 0 max 255 scalef min" : " round 0 max 255 min") [* P = min(max(int(P+0.5) , 0.0), 255.0) *]
return( show_function ? clp.subtitle(wicked) : (bpc>8) ? clp.mt_lut(Yexpr = wicked, use_expr=2, U=2,V=2) : clp.mt_lut(Yexpr = wicked, U=2,V=2) )
}


From Levels Docs:-
This is one of those filters for which it would really be nice to have a GUI.
Since I can't offer a GUI (at least not in AviSynth's current form), I decided I could at least make this filter compatible with VirtualDub's
when the clip is RGB. In that case you should be able to take the numbers from VirtualDub's Levels dialog and pass them as parameters
to the Levels filter and get the same results. However, the input and output parameters can be larger than 255.
EDIT: And also less than 0 too.

Here specifying both input and output coords outside of colorspace range,

Ylevels(0-32, 1.0, 255+32, 0-32, 255+32, false)

https://i.postimg.cc/q7T19z5r/Untitled-00.jpg (https://postimages.org/)

Also, you should not artifically limit input or output args to the YLevels function.
[EDIT: Original v2.58 (and Beta 2.60) avs Levels used PixelClip on RGB ouput, this was an (in some caes failed) attempt to clamp output RGB and was a bug, a simple Min,Max clamp fixed it. ]

Client for similar to above image.

SHOW=False
Avisource("D:\Parade.avi")
#Colorbars(width=1920,height=1080,pixel_type="YV12")
#convertbits(16)
convertbits(32)
Ylevels(-32, 1.0, 255+32, 0-32, 255+32, SHOW)
convertbits(8)


Code originating from Levels, AutoLevels and others.

gamma = min(max(gamma,0.1f),10.0f); // ssS: Added sane range limiting (& avoid div by zero on gamma)
gamma = 1/gamma;
int divisor = (in_max == in_min) ? 1 : (in_max - in_min); // avoid zero divide

if (vi.IsYUV()) {
for (int i=0; i<256; ++i) {
float p;
if (coring)
p = ((i-16)*(255.0f/219.0f) - in_min) / divisor;
else
p = float(i - in_min) / divisor; // range 0.0 -> 1.0 of input range

p = pow(min(max(p, 0.0f), 1.0f), gamma); // gamma
p = p * (out_max - out_min) + out_min; // output range with out_min offset
int pp;

if (coring)
pp = int(p*(219.0f/255.0f)+16.5f);
else
pp = int(p+0.5f); // round to nearest luma level

map[i] = min(max(pp, (coring) ? 16 : 0), (coring) ? 235 : 255);

int q = ((i-128) * (out_max-out_min) + (divisor>>1)) / divisor + 128;
mapchroma[i] = min(max(q, (coring) ? 16 : 0), (coring) ? 240 : 255);
}
} else if (vi.IsRGB()) {
for (int i=0; i<256; ++i) {
float p = float(i - in_min) / divisor;
p = pow(min(max(p, 0.0f), 1.0f), gamma);
p = p * (out_max - out_min) + out_min;
int z=int(p+0.5f);
map[i] = (z < 0) ? 0 : (z>255) ? 255 : z; // # EDIT: Was originally bugged PixelClip clamping
}
}

[pinterf]

Just before gamma clamp to 0-1 regardless from the original bit depth. That's why we normalize the range before applying power function.

[StainlessS]

Cleaned up and removed some earlier scripts.
YLevels script in post #5519 Updated, Added Levels originating source code:- https://forum.doom9.org/showthread.php?p=1909075#post1909075
Update, use scalef only if BitsPerComponent > 8 [and also avs+].
Made final clamp to colorspace range optional, uncomment a line to use explicit clamp, Masktools clamps anyway so not necessary, suggest leave in-situ [commented out] as documentation.
EDIT: Original Levels source code, and YLevels script do not include any dithering [was I think added to levels in avs 2.60 Std final]. [ Maybe something for RF to think about :) ]

[real.finder]

Cleaned up and removed some earlier scripts.
YLevels script in post #5519 Updated, Added Levels originating source code:- https://forum.doom9.org/showthread.php?p=1909075#post1909075
Update, use scalef only if BitsPerComponent > 8 [and also avs+].
Made final clamp to colorspace range optional, uncomment a line to use explicit clamp, Masktools clamps anyway so not necessary, suggest leave in-situ [commented out] as documentation.
EDIT: Original Levels source code, and YLevels script do not include any dithering [was I think added to levels in avs 2.60 Std final]. [ Maybe something for RF to think about :) ]

thank you both pinterf and StainlessS

I will add these changes as soon as possible

dithering in 2.60 Std? it mean using lsb or some hack, so it's unlikely, unless you made it dll :) here are the all functions https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/YLevels_mt.avsi

edit: 255 scalef can be replaced with range_max

[StainlessS]

Did not know if some clever stuff could be done for dithering using Expr (I aint really ever looked at Expr).
255 scalef can be replaced with range_max
Very good to know, thanks. [Its your (adopted) baby, mod it as you suggested].
If you need asistance with the other Didee funcs, let me know [but not just now, bit busy].
EDIT:
I had thought about splitting the string into several parts wick1, wick2 etc,
so could provide line wrap for subtitle, and append parts for the actual functionality, maybe you add it.

[real.finder]

Did not know if some clever stuff could be done for dithering using Expr (I aint really ever looked at Expr).

Very good to know, thanks. [Its your (adopted) baby, mod it as you suggested].
If you need asistance with the other Didee funcs, let me know [but not just now, bit busy].
EDIT:
I had thought about splitting the string into several parts wick1, wick2 etc,
so could provide line wrap for subtitle, and append parts for the actual functionality, maybe you add it.

Expr is only for avs+, and dither need use nearby Pixels which mt_lut can't unless if dither parameter added for it

The only thing that can be done for now is add stacked hack for avs 2.6 :devil:

[real.finder]

speaking of expr()

pinterf, seems you forget about this https://forum.doom9.org/showthread.php?p=1899122#post1899122 :)

[dREV]

seems you missed this post https://forum.doom9.org/showpost.php?p=1906222&postcount=405 :)

also this https://forum.doom9.org/showthread.php?p=1906465#post1906465

It's not that I missed it more like I haven't kept up with your thread. Made a post over at your page about your script https://forum.doom9.org/showthread.php?p=1909256#post1909256 It's not working out in 4:2:0 color depth in HEVC.

[real.finder]

It's not that I missed it more like I haven't kept up with your thread. Made a post over at your page about your script https://forum.doom9.org/showthread.php?p=1909256#post1909256 It's not working out in 4:2:0 color depth in HEVC.

you use input dimensions as native but anyway I fix it, but keep in mind it's 4:4:4 output, if you don't need 444 use resizer only

also I forgot to mention that it work in HBD if you want

[pinterf]

speaking of expr()

pinterf, seems you forget about this https://forum.doom9.org/showthread.php?p=1899122#post1899122 :)
I won't do that. We had already had AVX2 and the fma (mul and add in a single step) optimizations were already backported.
It has a more futureproof coding style with even more in-Expr optimizations.
But I think it would offer not real speed benefit at the moment. And since sekrit-twc is thinking about replacing the whole engine let's wait what magic can he do. It won't be a one-week job.

[pinterf]

@real.finder, what about a mode25 test instead? Check rgtools site. This took one week's time including my earlier attempts on it, I do hope there are no other unavoidable modes.

[real.finder]

@real.finder, what about a mode25 test instead? Check rgtools site. This took one week's time including my earlier attempts on it, I do hope there are no other unavoidable modes.

thanks and why not?

ColorBars(width=640, height=480, pixel_type="yv12")
SoftSharpen (http://web.archive.org/web/20160608111758/http://leon1789.perso.sfr.fr/avisynth/SoftSharpen-8.8.zip)

https://i.postimg.cc/NMZPHvg7/Untitled.png (https://postimages.org/)

SoftSharpen need mode 27, I will test mode 25 later :)

[pinterf]

Prove it that it cannot be replaced. Just because someone has put there mode 27 twenty years ago (o.k I'm probably exaggerating, but I hope you understand what I am trying to say in general) Experiment with new, maybe the replacements are even better.

[real.finder]

Prove it that it cannot be replaced. Just because someone has put there mode 27 twenty years ago (o.k I'm probably exaggerating, but I hope you understand what I am trying to say in general) Experiment with new, maybe the replacements are even better.

I don’t know, I don’t have enough knowledge and experience

26 = medianblur. Based off mode 17, but preserves corners, but not thin lines.
27 = medianblur. Same as mode 26 but preserves thin lines.

don't know how 26 preserves corners, and 27 use 26 as a base

and isn't using 17 with mask (if it can be done) to get 26 then 26 with another mask to get 27 will make it slower?

[tormento]

Check rgtools site.
I saw you just released RGTools 0.99.

In the release note, you specify support for SSE2, SSE4.1 and AVX2.

I still have Sandy Bridge, that supports AVX but not AVX2. Can you include this specific optimization too into your releases?

Thanks! :o

[qyot27]

Ask for a hand, get an ARM instead.
https://i.imgur.com/OCNAx9Kh.jpg (https://i.imgur.com/OCNAx9K.jpg)

[real.finder]

Ask for a hand, get an ARM instead.
https://i.imgur.com/OCNAx9K.jpg

I don't use an ARM PC but this is cool

it should work even on RISC-V right?

[qyot27]

It'd need the correct CPU defines in config.h so it could build, but otherwise, maybe? The actual thing you're looking at there is the ability to build a plain C version (with the right toggle in avs/config.h so that it can build on ARM), with the Intel intrinsics disabled. So hypothetically, in the state it's in, if it can be built, it should be able to run so long as it's under an OS it can already handle. But it'll be slow until intrinsics/asm for those platforms get added. And probably due to the reliance on some of the cpuid stuff, Prefetch will segfault, so right now it's single threaded and no asm assist on non-x86.

[StainlessS]

Impressive, Raspberry Pi yum yum.

[pinterf]

I saw you just released RGTools 0.99.

In the release note, you specify support for SSE2, SSE4.1 and AVX2.

I still have Sandy Bridge, that supports AVX but not AVX2. Can you include this specific optimization too into your releases?

Thanks! :o
Unfortunately not.
AVX is not for integer data.

[Reel.Deel]

Hi everyone, I just want to say thanks to all responsible for the continued work on AviSynth+. There are now over 100+ 64-bit plugins available to use and still a handful missing.

http://avisynth.nl/index.php/Category:Plugins_x64

:thanks:

[tormento]

Unfortunately not. AVX is not for integer data.
Understood. And why not the complete set of SSE, i.e. 4.2, but 4.1 only?

[tormento]

I don't use an ARM PC but this is cool
Picture Apple is thinking about switching to ARM...

[tormento]

Ask for a hand, get an ARM instead.
Cool.

Any benchmark for us? Let's say simple denoise script with x264. :D

[MeteorRain]

Understood. And why not the complete set of SSE, i.e. 4.2, but 4.1 only?

Since SIMD is probably a popular dev topic I suggest you to take a look at what each instruction set provides.

For example, usually integer operations are provided after floating points, so SSE=float and SSE2+=int, AVX=float and AVX2=int.

Then because SSE appeared in early days, more and more instructions are added because later they were found useful but not provided. For example SSSE3 added horizontal additions. SSE4.1 is pretty sweet, it added lots of useful tools like extending data width (8bit extending to 16bit, which are useful in high bit depth), min and max on unsigned data (clamping pixel channels), and floating point rounding (used in converting internal floating to integers). As you can see, lots of them are naturally used by lots of filters.

SSE4.2 however is irrelevant to computing. It has instructions for strings (such as comparing strings or get length of a string), and for CRCs. It's close to useless for filters.

That's why most of the filters will use up to SSE4.1. Some can limit their usage under SSE/SSE2 because some SSE4.1 operations can usually be done in SSE/SSE2 at relatively low cost. It's author's discretion to support which one.

[tormento]

Since SIMD is probably a popular dev topic I suggest you to take a look at what each instruction set provides.

Very interesting explanation!

Thank you!!!

[StainlessS]

Understood. And why not the complete set of SSE, i.e. 4.2, but 4.1 only?

Maybe there is not much use for it.
SSE4.2
SSE4.2 added STTNI (String and Text New Instructions),[10] several new instructions that perform character searches and comparison on two operands of 16 bytes at a time. These were designed (among other things) to speed up the parsing of XML documents.[11] It also added a CRC32 instruction to compute cyclic redundancy checks as used in certain data transfer protocols. These instructions were first implemented in the Nehalem-based Intel Core i7 product line and complete the SSE4 instruction set. Support is indicated via the CPUID.01H:ECX.SSE42[Bit 20] flag.
https://en.wikipedia.org/wiki/SSE4#SSE4.2

EDIT: OOPS sorry, was looking at last post on previous page of thread, thought is was the last post in thread. [already answered by MeteorRain] :(

[tormento]

OOPS sorry, was looking at last post on previous page of thread, thought is was the last post in thread. [already answered by MeteorRain] :(

Kindness is never enough. Thank you too!

[pinterf]

Anyway, non SSE4.1 processors are so rare that months pass until someone report a bug on that (executing sse4.1 instruction instead of sse2), lately in VapourSynth Expr, but such bug existed in an old mvtools2 as well and probably once in Avisynth+)

[real.finder]

@real.finder, what about a mode25 test instead? Check rgtools site. This took one week's time including my earlier attempts on it, I do hope there are no other unavoidable modes.

did some tests, mode 25 seems work ok in x64 and HBD

:thanks:

[real.finder]

Cool.

Any benchmark for us? Let's say simple denoise script with x264. :D

You will be lucky if you get 1 fps every 1 minute :p since it's arm and there are only c (no asm)

[pinterf]

did some tests, mode 25 seems work ok in x64 and HBD

:thanks:
And behind the scenes mode 26-28 are ready from C up to avx2. I decided to do the Repair side as well because these things are ugly when done half finished.

[real.finder]

And behind the scenes mode 26-28 are ready from C up to avx2. I decided to do the Repair side as well because these things are ugly when done half finished.

big thanks!

I think I will add SoftSharpen my edits/modeds scripts

[pinterf]

And we have an RgTools of which version no longer starts with zero :)

[real.finder]

And we have an RgTools of which version no longer starts with zero :)

what a happy day :goodpost:

and yes, as you said in github
pinterf: I swear that by seeing the code mode 28 is different from mode 27 but I cannot find a clip where 27 and 28 gave different results :)
seems the output is same for quick test!

SoftSharpen now works! but no x64 since it use asharp :( but in any case I will did some edit for it (later!) to make it HBD ready

[pinterf]

And finally. 3.5.2. test builds, files only.
There are plugins and plugins64 folder inside, not plugins+ and plugins64+, sorry. But I think not much mixed environment (with avs 2.6) are left by now.

Those who cannot wait for the feature explanations please check readme_history.txt for changes.

But until I post about the new features use these builds as usual. If they fail in something test them with other scripts. Thank you.

This one with array support (preferred)
https://drive.google.com/open?id=1_4yCKy1oSpCZQpVPISlTIp3u5jFpAgRW

Without arrays
https://drive.google.com/open?id=1EY1wgsh7pQD7kqj_2suD--nSj12hILX4

[Groucho2004]

And finally. 3.5.2. test builds, files only.
There are plugins and plugins64 folder inside, not plugins+ and plugins64+, sorry. But I think not much mixed environment (with avs 2.6) are left by now.

Those who cannot wait for the feature explanations please check readme_history.txt for changes.

But until I post about the new features use these builds as usual. If they fail in something test them with other scripts. Thank you.

This one with array support (preferred)
https://drive.google.com/open?id=1_4yCKy1oSpCZQpVPISlTIp3u5jFpAgRW

Without arrays
https://drive.google.com/open?id=1EY1wgsh7pQD7kqj_2suD--nSj12hILX4
I just looked at readme_history.txt - Crikey, you've been busy.

:thanks:

[StainlessS]

From Brief comparison with previous issue.


AviSynth+_3.5.2_(r3218,_neo,_i386)_MOD_ADD_Function_List.TXT

NOTE, We cannot tell if more than single modification or addition has been made, some may have been omitted.

######
AlignedSplice "cci"

###### NEW
Array ".*"
ArrayGet "a.+"
ArraySize "a"

######
BlankClip "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]a"

######
ConditionalFilter "cccn[show]b[local]b"

######
ConditionalReader "css[show]b[condvarsuffix]s[local]b"

######
ConditionalSelect "cnc+[show]b[local]b"

###### NEW
DumpFilterGraph "c[outfile]s[mode]i[nframes]i[repeat]b"

###### NEW
Format "s.+"

###### NEW
Func "n"

###### NEW
IsArray "."

###### NEW
IsFunction "."

###### NEW
OnCPU "n"

######
Prefetch "c[threads]i[frames]i"

###### NEW
propClearAll "c"
propDelete "cs"
propGetAll "c[offset]i"
propGetAny "cs[index]i[offset]i"
propGetAsArray "cs[offset]i"
propGetDataSize "cs[index]i[offset]i"
propGetFloat "cs[index]i[offset]i"
propGetInt "cs[index]i[offset]i"
propGetKeyByIndex "c[index]i[offset]i"
propGetString "cs[index]i[offset]i"
propGetType "cs[offset]i"
propNumElements "cs[offset]i"
propNumKeys "c[offset]i"
propSet "csa"
propSetArray "csn"
propSetFloat "csn[mode]i"
propSetInt "csn[mode]i"
propSetString "csn[mode]i"
propShow "c[size]i[showtype]b"

######
ScriptClip "cn[show]b[after_frame]b[local]b"

######
SetFilterMTMode "si[force]b"

###### NEW
SetCacheMode "[mode]i"
SetDeviceOpt "[opt]i[val]i"

###### NEW
SetGraphAnalysis "b"

###### NEW
SetMaxCPU "s"

######
SetMemoryMax "[]i[type]i[index]i"

###### NEW
TypeName "."

######
UnalignedSplice "cci"

###### NEW
UseVar "cs+"

######
WriteFile "c[filename]sn+[append]b[flush]b[local]b"

######
WriteFileEnd "c[filename]sn+[append]b[local]b"

######
WriteFileIf "c[filename]sn+[append]b[flush]b[local]b"

######
WriteFileStart "c[filename]sn+[append]b[local]b"


Top Notch P, thanks :)

[pinterf]

propSets must be of different signatures.
Function with n-function parameter types are from Nekopanda's fork. And filter graph. And the mt fixes. Thanks for him.

[tormento]

Crikey
I think it's 35 years I did not hear that word.

And it was from my 70 yo english teacher reading some XVIII century book.

[pinterf]

If no instant fix is required then I will have time to explain the features, one per day :). Unless you explain them to yourselves.

[tormento]

And finally. 3.5.2. test builds, files only.
Wow, what a work!

Can we use "old" plugins or they won't work as you told us?

[pinterf]

I found no failing plugins so far. But I have only a limited set of them compared to the community.

[tormento]

I found no failing plugins so far. But I have only a limited set of them compared to the community.

The infamous recompile of KNLMeansCL is not necessary?

[pinterf]

Ah yes. I forgot it because I had fixed it for my tests.

[tormento]

Ah yes. I forgot it because I had fixed it for my tests.
[2020-04-28][21:28:30] error: System exception - Access Violation
[2020-04-28][21:28:30] (D:/Programmi/Media/AviSynth+/plugins64/Zs_RF_Shared-1.121.avsi, line 698)
[2020-04-28][21:28:30] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·106.avsi, line 610)
[2020-04-28][21:28:30] (D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.1.2·106.avsi, line 181)
[2020-04-28][21:28:30] (E:\in\2_15 Amabili resti\resti_4_500.avs, line 16)
[2020-04-28][21:28:30]
[2020-04-28][21:28:30] PROCESS EXITED WITH ERROR CODE: 1
I noticed. :rolleyes:

[real.finder]

And finally. 3.5.2. test builds, files only.
There are plugins and plugins64 folder inside, not plugins+ and plugins64+, sorry. But I think not much mixed environment (with avs 2.6) are left by now.

Those who cannot wait for the feature explanations please check readme_history.txt for changes.

But until I post about the new features use these builds as usual. If they fail in something test them with other scripts. Thank you.

This one with array support (preferred)
https://drive.google.com/open?id=1_4yCKy1oSpCZQpVPISlTIp3u5jFpAgRW

Without arrays
https://drive.google.com/open?id=1EY1wgsh7pQD7kqj_2suD--nSj12hILX4

thank you for the update :thanks:

I note MP_Pipeline still need return last, also another cases https://forum.doom9.org/showthread.php?p=1906156#post1906156


and all https://github.com/chikuzen plugins now don't work :devil:

chikuzen, we need you back, please come back!

[pinterf]

thank you for the update :thanks:

I note MP_Pipeline still need return last, also another cases https://forum.doom9.org/showthread.php?p=1906156#post1906156


and all https://github.com/chikuzen plugins now don't work :devil:

chikuzen, we need you back, please come back!
Yes, probably they are using the old avs+ specific IScriptEnvironment2. I found TMM2_avx2 at myself, which ones are actively used?

[real.finder]

Yes, probably they are using the old avs+ specific IScriptEnvironment2. I found TMM2_avx2 at myself, which ones are actively used?

addition to TMM2 (https://github.com/chikuzen/TMM2), I have those

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

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

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

https://github.com/chikuzen/yadifmod2

https://github.com/chikuzen/DCTFilter

https://github.com/chikuzen/PlanarTools

https://github.com/chikuzen/TEMmod

https://github.com/chikuzen/ReduceFlicker

maybe you should wait chikuzen for some time (few days) before update them

[pinterf]

Anyway, the current working branch is here:
https://github.com/AviSynth/AviSynthPlus/tree/neo
I'm using the new AviSynth headers from there.
They are not 100% final but those things that are needed for a rebuild are there.

[pinterf]

addition to TMM2 (https://github.com/chikuzen/TMM2), I have those

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

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

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

https://github.com/chikuzen/yadifmod2

https://github.com/chikuzen/DCTFilter

https://github.com/chikuzen/PlanarTools

https://github.com/chikuzen/TEMmod

https://github.com/chikuzen/ReduceFlicker

maybe you should wait chikuzen for some time (few days) before update them
PlanarTools is for what?

[real.finder]

PlanarTools is for what?

IIRC, it's faster in convert YUY2 to YV16

[jpsdr]

There are plugins and plugins64 folder inside, not plugins+ and plugins64+, sorry. But I think not much mixed environment (with avs 2.6) are left by now.

I think i missed this one.
What do you mean exactly ?
Do you mean that the new version doesn't look anymore for "+" folders, and if i stay with my actual configuration with plugins in "+" and "not +" folders, the plugins within the "+" folders will not be loaded ?

[pinterf]

I think i missed this one.
What do you mean exactly ?
Do you mean that the new version doesn't look anymore for "+" folders, and if i stay with my actual configuration with plugins in "+" and "not +" folders, the plugins within the "+" folders will not be loaded ?
No, no, recently we were asked why the "filesonly" distribution is changing its internal folder names, plus or non-plus. The installer puts them into plugins(64)+ directory, while I provide it sometimes without the plus in the name inside the zip file.
I meant that in an Avisynth+-only system it is not problem if those appear in the main plugin directory and not in the plus (as long as you don't have two sets of the bundled plugins, one in the plugins the other in the plugins+ folder)

[jpsdr]

Ok, fine.

[tormento]

PlanarTools is for what?
KNLMeansCL badly needed here.

Testing purposes, of course. :D

[StainlessS]

31st October 2018, 11:25
I guess thread control means editing the very first post. Good idea, considering.

28th April 2019, 07:08:
Regarding the new thread, yeah, I'll start it, promise, unfortunately my draftsman is on holiday :), I wanted to write a proper intro w/o mis-spelling.
Anyway it's time for a new release but I found way too many other tasks and coding adventures for myself, so it's just a question of weeks.


Wonderful new Avs+ v3.x version with arrays and such, what a great opportunity to have its own thread, or do you need think about it for a little while. :)

[ChaosKing]

With new stuff like arrays, why not make life easier and add also a official scripts folder while we are at it?
We would have then 2 plugins and 1 script folder.

[pinterf]

KNLMeansCL badly needed here.

Testing purposes, of course. :D
Unofficial test, grab it from here
https://github.com/pinterf/KNLMeansCL/releases/download/1.1.1b/KNLMeansCL_1.1.1_test_for_avs3.5.2.7z

[Groucho2004]

Unofficial test, grab it from here
https://github.com/pinterf/KNLMeansCL/releases/download/1.1.1b/KNLMeansCL_1.1.1_test_for_avs3.5.2.7zWorks, thanks!

[tormento]

With new stuff like arrays, why not make life easier and add also a official scripts folder while we are at it?
We would have then 2 plugins and 1 script folder.



+1 to have AVSI folder.

In my dreams a repo where AVS+ automatically downloads needed plugins and AVSI functions to run a script...

[real.finder]

In my dreams a repo where AVS+ automatically downloads needed plugins and AVSI functions to run a script...

there are this already https://forum.doom9.org/showthread.php?t=176443

[tormento]

there are this already https://forum.doom9.org/showthread.php?t=176443
:thanks:

[ChaosKing]

The gui is an older release and has a bug where it can mix up 32 and 64bit plugins (fixed in VS version). Use avsrepo for now to be on the safe side. https://forum.doom9.org/showthread.php?t=175822

[Zetti]

New thread >> AviSynth+ thread Vol.2

https://forum.doom9.org/showthread.php?t=181351

[tormento]

Unofficial test, grab it from here
Tested and working. A bit faster but perhaps it's placebo effect.

[LigH]

^ tormento: So, "imports[64]" like "plugins[64]"?
_

Oops, missed a new page. :o

[real.finder]

Hi everyone, I just want to say thanks to all responsible for the continued work on AviSynth+. There are now over 100+ 64-bit plugins available to use and still a handful missing.

http://avisynth.nl/index.php/Category:Plugins_x64

:thanks:

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

[tormento]

I just note that Asd did backport SmoothUV and DeDot and DeCross from VS, cool :goodpost:
As I wrote in the vol.2 thread it would be better starting to divide plugins into AVS supported interface versions, thus easing programmers to start a revision of the missing plugins.

[Selur]

Using Avisynth+ 3.6 32bit loading:
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\LoadDll.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\AddGrainC.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\dfttest.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\EEDI2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\eedi3.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\FFT3DFilter.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\mvtools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\TDeint.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\RgTools.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\PlanarTools.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MedianBlur2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\nnedi3.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\nnedi2.dll")
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\yadif.dll")
LoadDLL("I:\Hybrid\32bit\avisynthPlugins\libfftw3f-3.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\QTGMC.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\SMDegrain.avsi")
Import("I:\Hybrid\32bit\avisynthPlugins\AnimeIVTC.avsi")
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\files\interlaceAndTelecineSamples\interlaced\YUV422_sample.avi
# input color sampling YUY2@8
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\files\INTERL~1\INTERL~1\YUV422~1.AVI",cachefile="E:\Temp\avi_1deca8d5573c8cb8cd8489678b764f38_853323747_1_0.ffindex",fpsnum=25,colorspace="YUY2")
# current resolution: 720x576
# deinterlacing
ConvertToYUY2(interlaced=true)
AssumeTFF()
QTGMC(Preset="Fast", ediThreads=2)
SelectEven()
# cropping
Crop(16,4,-16,-12)# 688x560
# filtering
ConvertToYV12(matrix="Rec601")
PreFetch(8)
return last
I get:
'I:/Hybrid/32bit/AVISYN~1/PlanarTools.dll' cannot be used as a plugin for AviSynth.
same script works fine with Avisynth+ 3.5 (r3106, 3.5, i386)

Using:
LoadCPlugin("I:\Hybrid\32bit\AVISYN~1\ffms2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\mvtools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\masktools2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\MedianBlur2.dll")
LoadPlugin("I:\Hybrid\32bit\AVISYN~1\SSE2Tools.dll")
Import("I:\Hybrid\32bit\avisynthPlugins\SMDegrain.avsi")
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
# loading source: F:\TestClips&Co\test.avi
# input color sampling YV12@8
# input luminance scale tv
FFVideoSource("F:\TESTCL~1\test.avi",cachefile="E:\Temp\avi_0197468a3716844ade54f3f30f60eeda_853323747_1_0.ffindex",fpsnum=25,colorspace="YV12")
# current resolution: 640x352
# filtering
# grain handling
SMDegrain(interlaced=false)
PreFetch(8)
return last
I get:
Script error: expected `)' ((null), line 1, column 4) (I:\Hybrid\32bit\avisynthPlugins\SMDegrain.avsi, line 879) (I:\Hybrid\32bit\avisynthPlugins\SMDegrain.avsi, line 75) (E:\Temp\tempPreviewAvisynthFile17_00_53_414.avs, line 16)
Line 75 of SMDegrain.avsi is
"sisphbd = AvsPlusVersionNumber > 2294"
which calls line 879:
function AvsPlusVersionNumber()
{
IsAvsNeo ? eval(MidStr(VersionString(),20,4)) : IsAvsPlus ? eval(MidStr(VersionString(),17,4)) : 0
}


-> did I miss some change that broke old plugins and scripts? (couldn't see anything about it in the release notes)

Cu Selur

[StainlessS]

Selur, Get new SMDeGrain and Zs_RF_Shared.avsi from Real.Finder repository:- https://github.com/realfinder/AVS-Stuff/tree/master/avs%202.5%20and%20up
things changed [everything currently in turmoil].
Also, post in the new thread maybe, this one nearly dead.

[real.finder]

this thread should closed

and new thread should mention this one as an archive (edit: it's already did)

@Moderators

[Selur]

@StanlessS: Thanks for the info about the new scripts.