Avisynth+

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