Avisynth+

[wonkey_monkey]

That seems like a lot of work to solve a problem that hardly anyone will ever face, and it could introduce unforeseen problems.

[StainlessS]

That seems like a lot of work to solve a problem that hardly anyone will ever face, and it could introduce unforeseen problems.

Not really, the guy above has already foreseen these unforeseen problems.

[Myrsloik]

No problem.
1. Do a discovery of all DLLs and what's in them
2. Once the script is loaded and started rendering, unload everything that is not in use
NOTE: We still know what functions are available and where
3. If a function is later called that is unloaded, load it.

Otherwise, while we have any script playing that uses auto-loading, we cannot update any dll files.

I think this was actually the original Avisynth strategy. Mostly due to processes at the time being very limited in the number of simultaneous dlls that could be loaded so if you stuffed the autoload directory full you could actually encounter this problem.

Nowadays you can load a gazillion of dlls as long as you compile them with a shared runtime so there's really no reason to do things like that.

[Groucho2004]

I think this was actually the original Avisynth strategy. Mostly due to processes at the time being very limited in the number of simultaneous dlls that could be loaded so if you stuffed the autoload directory full you could actually encounter this problem.The limit was 50 DLLs and still is in AVS 2.6.1 Alpha.

[qyot27]

What that sounds like is akin to the plugin cache index idea I'd proposed way way back when the fork had just happened. I can't even remember what the actual reason was; I think it may have been to save resource usage by not going through the 'autoload everything->unload everything->load only what the script uses' dance when the environment starts. Certainly nothing to do with files being locked (and because it's still autoloading everything at startup, it's not saving anything resource-wise).

Found it. (https://forum.doom9.org/showpost.php?p=1646355&postcount=70) And the actual reason: it was to avoid bad plugins (the example given was one of the versions of WarpSharp) crashing the environment even when they aren't being used in the script, just because they were being autoloaded (https://forum.doom9.org/showpost.php?p=1646457&postcount=75).

[Myrsloik]

What that sounds like is akin to the plugin cache index idea I'd proposed way way back when the fork had just happened. I can't even remember what the actual reason was; I think it may have been to save resource usage by not going through the 'autoload everything->unload everything->load only what the script uses' dance when the environment starts. Certainly nothing to do with files being locked (and because it's still autoloading everything at startup, it's not saving anything resource-wise).

Found it. (https://forum.doom9.org/showpost.php?p=1646355&postcount=70) And the actual reason: it was to avoid bad plugins (the example given was one of the versions of WarpSharp) crashing the environment even when they aren't being used in the script, just because they were being autoloaded (https://forum.doom9.org/showpost.php?p=1646457&postcount=75).

As a bonus some compilers (looking at you borland) would change the FPU rounding mode so some other poor plugin would crash. Good times!

[real.finder]

well, it's still case problems https://github.com/pinterf/AviSynthPlus/issues/11#issuecomment-463595150 and https://forum.doom9.org/showpost.php?p=1865961&postcount=4508

[StainlessS]

Dont know if any longer the case, but,
I used to have problems with Script Function Named Difference(), (probably back in either v2.58 or early v2.6 Alpha), I tracked it down to similar named plug func
in (I think) one of Kassandro's dll's. No idea why, as Script Functions are supposed to Override dll which are supposed to Override Builtin.

I just renamed Script function to something else (ClipDelta which I figured would not be chosen by anyone else).

EDIT: (Plugin_Autoload_and_Name_Precedence AND Plugin Autoload and Conflicting Function Names ):- http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Name_Precedence

[LouieChuckyMerry]

Hello. After much kind help I've finally made the switch to AviSynth+ and native 16-bit, and I'm wondering if there's any way to improve my encoding speed. My usual script, on a quad-core x64 Windows 7 setup, using x86 MeGUI with x86 AviSynth+ and the latest versions of all necessary plugins-filters is:

DGSource Information Here
SetFilterMTMode("Default_MT_Mode",2)
SMDegrain(TR=x,ThSAD=xxx,RefineMotion=True,Plane=0,Chroma=False,n16=True,n16_Out=True)
FastLineDarkenMod4()
ConvertToDoubleWidth()
F3KDB(Y=100,Cb=100,Cr=100,GrainY=0,GrainC=0,Input_Mode=2,Output_Mode=2)
PreFetch(5)
# Sent To 10-bit x264

I ask because I'm achieving ~75% of the encoding speed I had with SEt's AviSynthMT and stacked 16-bit using older versions of the necessary plugins-filters, and I figure that I missed something along the way ;) . Thanks for any suggestions.

Edit: Any ideas anyone?

[wonkey_monkey]

Just out of curiosity:

VirtualDub2 can load various filetypes (MKV, MPEG2, MP4, etc) instantly, without - I assume - having to do any indexing. Is there are any reason why an AviSynth source filter couldn't work the same way, so as to do away with the slow first load? Or is there a source plugin that already does this?

[ChaosKing]

The only plugin I know of is LSMASHVideoSource. But it only supports ISO file containers, like *.mov, *.mp4, *.m4v, *.3gp, *.3g2, *.mj2, *.dvb, *.dcf, *.m21,

[poisondeathray]

DirectShowSource , DSS2 can too , but it can be unreliable

[wonkey_monkey]

The only plugin I know of is LSMASHVideoSource. But it only supports ISO file containers, like *.mov, *.mp4, *.m4v, *.3gp, *.3g2, *.mj2, *.dvb, *.dcf, *.m21,

Hmm, so it probably shouldn't say "It uses FFmpeg (libavcodec) to decode all supported audio and video formats." on the wiki, then (the bold text links to an FFmpeg page).

I'm somewhat wary of a filter which throws an exception for a missing file, as well...

[ChaosKing]

Hmm, so it probably shouldn't say "It uses FFmpeg (libavcodec) to decode all supported audio and video formats." on the wiki, then (the bold text links to an FFmpeg page).

As long the video is in a mp4 container it should be decoded. So not entirely false.:)

[qyot27]

It'd only be false if it said FFmpeg (libavformat, rather) was being used to demux it when using LSMASH[Video|Audio]Source. It isn't. LSMASH is demuxing it and passing the video and audio over to libavcodec. The LwLibav[Video|Audio]Source functions, on the other hand, do use only FFmpeg (libavformat->libavcodec).

[stax76]

@pinterf

Maybe you like this idea too:

https://forum.doom9.org/showthread.php?p=1876802#post1876802

[ryrynz]

Yeah please. 32-bit x86 can stop to stop being relevant.

[pinterf]

using x86 MeGUI with x86 AviSynth+
[...]
I ask because I'm achieving ~75% of the encoding speed I had with SEt's AviSynthMT and stacked 16-bit using older versions of the necessary plugins-filters, and I figure that I missed something along the way ;) . Thanks for any suggestions.

Edit: Any ideas anyone?
Without seeing the real memory consumption (avsmeter is a good help for that), I'd say that the default memory is too small for Prefetch(5). Try giving a larger SetMemoryMax value. Or change for x64.

[LouieChuckyMerry]

Without seeing the real memory consumption (avsmeter is a good help for that), I'd say that the default memory is too small for Prefetch(5). Try giving a larger SetMemoryMax value. Or change for x64.

Thanks for your reply, pinterf. I'll try various combinations of "SetMemoryMax()" and "PreFetch()" and see if I can improve my speed (and thanks for the AVSMeter reminder). I'm keen to try AviSynth+ x64; any suggestions for a good place to find the required x64 plugins-filters?

[Zetti]

http://avisynth.nl/index.php/AviSynth+_x64_plugins

[LouieChuckyMerry]

http://avisynth.nl/index.php/AviSynth+_x64_plugins

:thanks:

[wonkey_monkey]

converttoyv24, converttoyv16, converttoyv12, converttoy8 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)

[ChaosKing]

converttoyv24, converttoyv16, and converttoyv12 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)

You can unconfuse yourself here :D http://avisynth.nl/index.php/Convert

[pinterf]

converttoyv24, converttoyv16, and converttoyv12 don't do quite what they claim, in that they don't alter the bit depth (the 24 and 8 indicating how many bits per pixel). Deliberately confusing, or confusingly accidental? ;)
Perhaps once it did then from one point it didn't, when it was mapped directly to ConvertToYUV420 (and ...422, ...444). It should throw an error for non-8 bit colorspaces.

[wonkey_monkey]

You can unconfuse yourself here :D http://avisynth.nl/index.php/Convert

Nope, still just as confusing. Nothing on the page indicates whether a change in bit depth should be expected or not with those functions. I've also added converttoy8 to the list, as you really shouldn't expect this after using it:

https://i.imgur.com/8ujb2Jn.png

Perhaps once it did then from one point it didn't, when it was mapped directly to ConvertToYUV420 (and ...422, ...444). It should throw an error for non-8 bit colorspaces.

converttoyuy2 still does, presumably as it doesn't have a comparable function to be remapped to.

[ChaosKing]

There is also a table if you click on avisynth+ formats http://avisynth.nl/index.php/Avisynthplus_color_formats

As you can see YV12 is a shortcut for YUV420P8. Y10 is Luma channel in 10bit. But yes this shit is confusing and I have to look it up too. What's why I like this notation more YUV420P8.

But I guess it makes a bit more sense with this graphic:
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0d/Yuv420.svg/640px-Yuv420.svg.png
YV12 needs 12bytes for storage. (https://en.wikipedia.org/wiki/YUV)

[qyot27]

There is also a table if you click on avisynth+ formats http://avisynth.nl/index.php/Avisynthplus_color_formats

As you can see YV12 is a shortcut for YUV420P8. Y10 is Luma channel in 10bit. But yes this shit is confusing and I have to look it up too. What's why I like this notation more YUV420P8.

But I guess it makes a bit more sense with this graphic:
https://upload.wikimedia.org/wikipedia/commons/thumb/0/0d/Yuv420.svg/640px-Yuv420.svg.png
YV12 needs 12bytes for storage. (https://en.wikipedia.org/wiki/YUV)
The point wonkey_monkey was making was that you can do:
Version()
ConvertToPlanarRGB()
ConvertBits(10)
ConvertToYV12()
and this results in YUV420P10. Which is not YV12, and trying to use ConvertToYV12 should have errored out in this case.

The reason is, as pinterf noted, the old ConvertTo[Y8|YV12|YV16|YV24] functions from 2.5 (YV12) and 2.6 (the other three) were turned into aliases for the subsampling-oriented ConvertTo[Y|YUV420|YUV422|YUV444] functions when high bit depth support was added in Summer 2016. There aren't individual functions to go directly to X color format @ specified bit depth, apart from the ones for packed RGB (ConvertToRGB[24|A32|48|A64]).

ConvertToYUY2 is still 8-bit-only because YUY2 is a packed format, and there is no support for packed YUV422 formats for >8bit. They literally don't exist in the AviSynth+ source code (the global option OPT_Enable_V210 notwithstanding, but that's a separate thing done on output through Video for Windows only).

[wonkey_monkey]

Deleted because I solved it. It was caused by a timing issue with a lookup table in my filter. Typical that I figure it out after posting about it!

[pinterf]

and this results in YUV420P10. Which is not YV12, and trying to use ConvertToYV12 should have errored out in this case.

Fixed in source on my github repo.
- Fix: ConvertToY8, ConvertToYV12, ConvertToYV16, ConvertToYV24 are now allowed only for 8 bit inputs.
Formerly these functions were allowed for 10+ bit colorspaces but were not converted to real 8 bit Y8/YV12/16/24.
Use ConvertToY, ConvertToYUV420, ConvertToYUV422, ConvertToYUV444 instead which are bit depth independent

[ChaosKing]

Maybe now it is time for a new release? :)

[pinterf]

Maybe now it is time for a new release? :)
Yep, since months, I will do it as soon as I have time. Probably soon.

And then? Since ultim recently gave us access to the original Avisynth+ repo, we'll have to think about what to do next.

[ChaosKing]

Does this mean http://avs-plus.net can be updated too?

[pinterf]

Does this mean http://avs-plus.net can be updated too?
We'll discuss the topic as well.

[wonkey_monkey]

ultim recently gave us access to the original Avisynth+ repo

What a time to be alive. Thanks for all the hard work, pinterf!

[Groucho2004]

Thanks for all the hard work, pinterf!Indeed, thanks for keeping Avisynth alive and the updates for mvtools2, masktools and many more.

:thanks:

[VoodooFX]

Any idea why InpaintFunc.avs(1.13-1.15) crash AviSynth+ r2772? "Inpaint" mode works ok, "Deblend" and "Both" modes instantly crash AviSynth+.
No problems with AviSynth 2.6.

How to quickly test it:
1) video file (short!)
2) bmp file (RGB24, same resolution as video, all solid black and small solid white "blob" at top-left corner.
3) InpaintFunc.avs and AVSInpaint.dll ( http://avisynth.nl/index.php/InpaintFunc )
4) script:
LoadCplugin("C:\AVSInpaint.dll")
Import("C:\InpaintFunc.avs")
InpaintFunc(mask="c:\test.bmp", loc="tl",mode="Inpaint",speed=1)


Report from AVSMeter:
AviSynth+ 0.1 (r2772, MT, i386) (0.1.0.0)
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\SysWOW64\VCRUNTIME140.dll
Address: 0x72DC282E

I can reproduce this, VDub also reports an access violation. However, my culprit is avisynth.dll, not VCRUNTIME140.dll.

Works fine with classic Avisynth 2.6. You should post this in the AVS+ thread.

[pinterf]

Any idea why InpaintFunc.avs(1.13-1.15) crash AviSynth+ r2772? "Inpaint" mode works ok, "Deblend" and "Both" modes instantly crash AviSynth+.
No problems with AviSynth 2.6.

How to quickly test it:
1) video file (short!)
2) bmp file (RGB24, same resolution as video, all solid black and small solid white "blob" at top-left corner.
3) InpaintFunc.avs and AVSInpaint.dll ( http://avisynth.nl/index.php/InpaintFunc )
4) script:
LoadCplugin("C:\AVSInpaint.dll")
Import("C:\InpaintFunc.avs")
InpaintFunc(mask="c:\test.bmp", loc="tl",mode="Inpaint",speed=1)

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.

[VoodooFX]

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.

Did you changed mode="Inpaint" to mode="Deblend" to check if it crash? ("Inpaint" doesn't crash)

[pinterf]

Did you changed mode="Inpaint" to mode="Deblend" to check if it crash? ("Inpaint" doesn't crash)
It worked O.K.
But when I was trying to call it more than once
InpaintFunc(mask="test.bmp", loc="tl",mode="Deblend",speed=1)
InpaintFunc(mask="test.bmp", loc="tl",mode="Both",speed=1)

Now it crashes, we are happy now :)

EDIT: The plugin somehow clears or is overwriting an existing framebuffer pointer?
The crash itself occurs at an internal RGB24-RGB32 conversion but since the destination frame does not exist (zero pointer) it will show "access violation".
I'll have a look at the dll source.

[qyot27]

I could not reproduce. Could you upload your samples and send me a links? Mask and probably a small video.
They can be artificially generated:

Video:
ffmpeg -f lavfi -i testsrc -vcodec libx264 -preset ultrafast -crf 18 -t 10 test.mkv

Mask script:
v1=BlankClip(1,320,240).KillAudio()
v2=v1.Invert().PointResize(60,60)
Overlay(v1,v2,mode="blend")

Mask:
ffmpeg -i maskscript.avs test.bmp

The (not helpful, because all the binaries in the chain have been stripped) output of gdb seems to point at the cause of the Deblend and Both modes segfaulting being within DevIL, but some of the build warnings when compiling AVSInpaint itself may point more to internal API usage not being correct in those modes when used with modern AviSynth.

This is what happens when building it with only the minimal amount of fixes (avsplus r2883/7c334a0/HEAD (https://github.com/AviSynth/AviSynthPlus/commits/MT) header/lib, adjusting the Makefile to use 32-bit lib and -m32 flag, fix typo in AVSInpaint.c avs_is_yuy->avs_is_yuv):
$ make
gcc -m32 -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=i386 -c -o AVSInpaint.obj AVSInpaint.c
In file included from AVSInpaint.c:94:
AviSynth_C.h:99:21: warning: enumerator value for 'AVS_CS_PLANAR' is not an integer constant expression [-Wpedantic]
99 | AVS_CS_PLANAR = 1 << 31,
| ^
In file included from AVSInpaint.c:94:
AviSynth_C.h:690:1: warning: missing initializer for field 'array_size' of 'AVS_Value' {aka 'const struct AVS_Value'} [-Wmissing-field-initializers]
690 | static const AVS_Value avs_void = {'v'};
| ^~~~~~
AviSynth_C.h:675:9: note: 'array_size' declared here
675 | short array_size;
| ^~~~~~~~~~
AVSInpaint.c: In function 'Inpaint_Create':
AVSInpaint.c:254:93: warning: unused parameter 'Data' [-Wunused-parameter]
254 | AVS_Value AVSC_CC Inpaint_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Deblend_Create':
AVSInpaint.c:929:93: warning: unused parameter 'Data' [-Wunused-parameter]
929 | AVS_Value AVSC_CC Deblend_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Analyze_Create':
AVSInpaint.c:1245:93: warning: unused parameter 'Data' [-Wunused-parameter]
1245 | AVS_Value AVSC_CC Analyze_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'Analyze_GetFrame':
AVSInpaint.c:1432:81: warning: unused parameter 'FrameNo' [-Wunused-parameter]
1432 | AVS_VideoFrame * AVSC_CC Analyze_GetFrame(AVS_FilterInfo * FilterInfo, int FrameNo)
| ~~~~~^~~~~~~
AVSInpaint.c: In function 'DistanceFunction_Create':
AVSInpaint.c:1449:102: warning: unused parameter 'Data' [-Wunused-parameter]
1449 | AVS_Value AVSC_CC DistanceFunction_Create(AVS_ScriptEnvironment * Env, AVS_Value Args, void * Data)
| ~~~~~~~~^~~~
AVSInpaint.c: In function 'CreateGaussKernel':
AVSInpaint.c:2415:49: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
2415 | for (k=-Size ; k<=Size ; k++) Kernel[k] = (abs(Center-k)<1.0)?(1.0-abs(Center-k)):0.0;
| ^~~
AVSInpaint.c:2415:73: warning: using integer absolute value function 'abs' when argument is of floating point type 'double' [-Wabsolute-value]
2415 | for (k=-Size ; k<=Size ; k++) Kernel[k] = (abs(Center-k)<1.0)?(1.0-abs(Center-k)):0.0;
| ^~~
gcc -m32 -fdiagnostics-show-location=once -funsigned-char -mthreads -Wextra -pedantic -Wall -Wdeclaration-after-statement -Wundef -Wpointer-arith -Wstrict-prototypes -Wredundant-decls -O2 -fomit-frame-pointer -malign-double -s -march=i386 -shared -o AVSInpaint.dll AVSInpaint.obj AviSynth32.lib


In one build test a day or two ago, I did notice a warning emitted concerning avs_is_same_colorspace, which given what pinterf just noted about the RGB24/32 conversion, might be where this is coming from.

[VoodooFX]

It worked O.K.
But when I was trying to call it more than once
InpaintFunc(mask="test.bmp", loc="tl",mode="Deblend",speed=1)
InpaintFunc(mask="test.bmp", loc="tl",mode="Both",speed=1)

Now it crashes, we are happy now :)

EDIT: The plugin somehow clears or is overwriting an existing framebuffer pointer?
The crash itself occurs at an internal RGB24-RGB32 conversion but since the destination frame does not exist (zero pointer) it will show "access violation".
I'll have a look at the dll source.

It should crash with one call (InpaintFunc is not meant to work in two instances).

Here I prepared example (should work extracted to "C:"): https://drive.google.com/open?id=1fKu1PIr3oDQdiUN5eu0cezjsVcIL5iHb

[pinterf]

Please test this build
https://drive.google.com/open?id=1AQ1ZmRvVbGhXuL_xxuGX2ukXE4Uy7nWV

[VoodooFX]

I tested new build, and both 32 & 64 bits doesn't crash. Thank you.

[hello_hello]

I also posted in the other thread, but the new AVSInPaint build is fine on XP too.

Thank you!

[wonkey_monkey]

It is stated in the Wiki that:

In AviSynth each frame is most of the time aligned to an address divideable by 16. The exception for this rule is when crop() has been used.

But when I use crop it seems like I always get an aligned address from GetReadPtr(). Is frame alignment now always enforced?

Follow up question: what is GetOffset() for?

[StainlessS]

Default crop align for Avs+ is now (I think) True, wheareas False for Std Avs [EDIT: if not aligned via eg RoboCrop, then produces an error alert from AVS+, on return].

from Avs v2.58 Version Header 3 [the compressed help with SDK has both Version 6 (avs+) and v2.58 version 3 headers, for easy perusal],

// generally you shouldn't use these three
VideoFrameBuffer* GetFrameBuffer() const { return vfb; }
int GetOffset() const { return offset; }
int GetOffset(int plane) const { switch (plane) {case PLANAR_U: return offsetU;case PLANAR_V: return offsetV;default: return offset;}; }

For Planar, is usual to allocate single buffer, where Y plane is aligned at start of buffer, and U, and V somewhat later, GetOffset returns the offset from buffer base (methinks).

EDIT: When you swap U and V, all it probably does is swap offsets.
EDIT: Above also (I think) mirrors official standards for file based layout of raw YUV streams [with some alignment padding for offsets and also each individual raster line].

[wonkey_monkey]

Oh okay, phew, I thought I'd be going wrong all these years.

After aligned cropping it seems that Offset ends up non-zero (e.g. 16). Not sure why, probably doesn't matter.

[StainlessS]

I think current AVS+ alignement is 32 [EDIT: Actually 64] (avs std 16) (probably thinking about 64 next, or whatever eg AVX2/later requires).

EDIT: As shown above, having v2.58 Version 3 header Baked Code, is quite handy to have [the raw cookie dough code tells you very little].

EDIT: Below some meanderings, no idea why I just wrote it.


malloc/new

Library writers long ago found that it is inefficient to allocate small blocks of memory, as that produces memory fragmentation, and so slower finding of suitable sized mem block.
So, was usual in C library, when user requested block size of eg 1 bytes, to carve off 8 bytes, and hand pointer back to user. Only 1 byte of this block belonged to the user,
but there would be no error encountered if user used up to 8 bytes as carved out from free memory lists.
Memory size returned was rounded up to a multiple of 8 bytes, so requesting 1 to 8, would carve out 8 bytes, 9 to 16, 16 bytes etc.
An additional bonus of this round up to 8 bytes, was that the memory block when free'ed, there was always enough room in that block to create a link in a linked list, for use in the
free memory list arrangement. The free memory block kept track of 'itself', without any additional overhead, and mem fragmentation was much less and also faster to find block of
sufficient size. [link list struct would hold 32 bit int size of mem block, and 32 bit pointer to next link in list, both 4 byte values on 32 bit system].
Above round up to 8 bytes also enabled the ANSI spec that malloc() returns a pointer to mem bock that is castable to a memory block structure of any type [or words something like that],
ie, some structures need be located on a memory boundary of maybe 2 bytes, 4 bytes or 8 bytes. If the initial heap base pointer is rounded to multiple of 8 bytes, and all mem blocks are a multiple
of 8 bytes, so all malloc blocks will return a mem bufer on 8 byte boundary.

Unfortunately, above used to cause novice C proggers to cock up when allocating string buffers, for small strings (less than 8 chars), as there were no problems produced when forgetting
to add 1 bytes for the nul term sentinel (zero byte) at end of string. This due to habit of writing C examples using "fred" and "ted" sized strings.
Novice C proggers would get the impression that it was unnecessary to add that 1 extra byte for the nul term because they never experienced any errors,
but of course this is bad, and perhaps the hardest of all bugs to track down.

Imagine you created a DBase for some project, and that it held Name field, and Title field, and Address etc, but that in the title field, you forgot to add the 1 byte for nul term.
Your DBase might go on seemingly OK for 5 or more years without any trouble at all, then one day you get new accound created for title "Princess", exactly 8 bytes in length, but
requiring 9 bytes in total for the buffer. you ask for 8 bytes, and this time you actually need 9, kaboom!!!, you blast a byte that does not belong to you, belongs to some other
structure or maybe even a link in the free memory list. As you repeatedly save and load (at day end/start) the DBase, each and every time, the problem is likely to move about, causing
corruption in differeing parts of your DBase, and eventually it will be noticed and become a problem.
Where do you start to look for the problem ???, you got 5 years spare to keep tabs on your next newly created DBase?

Because of the C libs malloc/calloc/new etc optimisation stuff, you have to be paranoid about that 1 extra byte, and suggest always allocate string buffers via a single function
which auto adds the required extra nul term byte. [look up the non ANSI function 'strdup()' and knock it up yourself if not supplied with your compiler
[STRICT_ANSI (or whatever the define is) will exclude it even if it does exist in your compiler].

For x64, it is most likely [ie definite] that the 8 byte fragment size mentioned above will be 16 bytes, so if you request 1 bytes from malloc, you will actually get 16, making the
above mentioned failure to add 1 byte for nul term on string buffer, an even bigger problem for string buffer bug hunting.

Also, a little aside,
Some C docs for calloc() seem to have ommitted the fact that calloc will auto zero memory [where malloc does not], think maybe MicroSoft (or someone, forgot about this more than insignificant
fact and just missed it out), and everybody else copied the erroneous docs. Perhaps your compiler mentions this clearing of memory by calloc, perhaps not [somewhere about year 1992->2000, they all/many
[cross platform] seemed to have forgotten about it].

[pinterf]

Avs+ alignment is 64. Crop parameter align=false does nothing. Avx2 needs 32, but it's only the present (probably processors from the last five years all support Avx2) Avx512 is the future which likes 64. However Avx2 code in Expr likes 64 byte alignment as well.
Plugin writers would safely omit pre-Avx2 optimization nowadays. C, Avx2, avx512 (at least for avs+ plugins)

[StainlessS]

Avs+ alignment is 64
Is that a recent change in avs+ ?

EDIT:- https://github.com/pinterf/AviSynthPlus/releases

Avisynth+ r2542 (20171114)
Fixes
...
modification, additions

Add: Expr filter
Add: Levels: 32 bit float format support
Optimized: Faster RGB (full scale) 10-16 bits to 8 bits conversion when dithering
Other: Default frame alignment is 64 bytes (was: 32 bytes). (independently of AVX512 support)
Built with Visual Studio 2017, v141_xp toolset
some fixes in avisynth_c.h (C interface header file)
experimental x64 build with size_t frame offsets for testing more properly written C interfaces