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.