Avisynth+

[pinterf]

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

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

[StainlessS]

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

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

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

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

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

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

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

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

[StainlessS]

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

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

AvsVersion.avsi

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

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

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

######

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

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

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

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

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


Client

# AvsVersion_Client.avs

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

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

[poisondeathray]

This is a RGB24 => YUV444P10 => RGB24 conversion

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

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

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

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

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

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

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

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

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

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

return da



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

[pinterf]

This is a RGB24 => YUV444P10 => RGB24 conversion

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


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

[StainlessS]

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

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

EDIT: Added nul string BUG CHK's to Clients

[StainlessS]

Is me doin' summick rong agen :(


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

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

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

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

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

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

[pinterf]

Is me doin' summick rong agen :(


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

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

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

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

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

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

[pinterf]

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

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

[Groucho2004]

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

[pinterf]

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

[manolito]

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

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

[StainlessS]

Maybe lets get all bugs fixed first, yes :)

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

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

[real.finder]

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

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

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

[Groucho2004]

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

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

Edit: QED:
Script

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

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

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

return last
}

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


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

[StainlessS]

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

Mobile:

[manolito]

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

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

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

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

[Groucho2004]

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

[StainlessS]

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

[real.finder]

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

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

[manolito]

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

[jpsdr]

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

[pinterf]

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

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

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

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

[StainlessS]

Lil bit Errata for Layer on Wiki,


Layer

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

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

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

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

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

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

[pinterf]

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

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

[StainlessS]

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

[2ndR]

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

Does not work

[poisondeathray]

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


Starting from YV12? Try going through planarRGB


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

[FranceBB]

is there anybody still using XP?


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

[Stephen R. Savage]

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

[wonkey_monkey]

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

[qyot27]

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

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

[2ndR]

Starting from YV12? Try going through planarRGB

Thank you very much. Recent worries have been resolved

[pinterf]

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

[pinterf]

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

[pinterf]

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

[StainlessS]

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

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



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


Thanks in advance. :thanks:

[Stereodude]

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

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

[StainlessS]

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

[Groucho2004]

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

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

[qyot27]

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

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

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

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

[Groucho2004]

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

[FranceBB]

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

Thank you, Ferenc! :)

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

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

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

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

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

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

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

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

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



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

[Stereodude]

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

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

[tormento]

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

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

[pinterf]

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

[StainlessS]

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

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

[real.finder]

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

[pinterf]

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

[TheFluff]

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

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