AviSynth 2.6.1 alpha 1 [May 17th, 2016] [Archive]

View Full Version : AviSynth 2.6.1 alpha 1 [May 17th, 2016]

Wilbert

17th May 2016, 22:54

This release is intended to be near feature identical to 2.6.0.

There are currently 3 build versions, all should be bug identical: https://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.1%20Alpha%201%20[20160517]/

These versions do not include the local help files so as to speed the fast swapping between versions by over installing the required version. The 2.6.0 local help is still current.

The alpha installers do not provide installation of runtime components. The user must download the relevant packages from Microsoft and install them.

All versions now ship with DevIL 1.7.8, which needs VC 2K5 runtimes. DevIL.dll is now delay loaded, so Avisynth.dll can be used without it, in which case ImageReader/Writer would support only ebmp mode.

AviSynth_20160517_VC6.exe

Uses the systems MSVCRT.dll only.
There is no longer any dependance on msvcp60.dll
Requires a processor supporting MMX instruction set.

AviSynth_20160517_VC2005Exp.exe

Needs the VC 2K5 runtimes.
Requires a processor supporting MMX instruction set.

AviSynth_20160517_VC2008Exp SSE2.exe

Needs the VC 2K8 runtimes.
Requires a processor supporting SSE2 instruction set.

Users encountering problems should compare the behaviour of each version and also the official 2.6.0 version. Different behaviour between 2.6.0 and 2.6.1VC6 are likely to be coding errors. Different behaviour between the VC6 and 2K5 or 2K8 version are probably caused be incompatibilities in the development environments.

During development most incompatibilities have shown up in the error reporting and the error handling. The VC 2015 Community build environment version currently fails the acceptance tests and has been withdrawn from this release.

As you make mistakes writing your Avisynth scripts please ensure the error messages are appropriate and the line number and column counter are consistant. Erroneous scripts that cause inconsistant error reporting gratefully accepted.

BRIEF CHANGE LOG
================

ENVIRONMENT CHANGES and UPDATES

Update to SoundTouch 1.9.2(Wilbert+IanB).
Update to DevIL 1.7.8
TCPDeliver update to zlib 1.2.8 and lzo-2.09.
TCPDeliver complete Klaus's last work for 2.6 API.
Updated 2.6.1 VC6 build scripts.
Initial 2.6.1 VC2005 build scripts.
DirectShowSource add BaseClasses project to Avisynth solution.
MSVC 2008 Express project and solution files.
Experiment with 2K8 SSE2 build.

CODE CHANGES

Add offset parameter to conditional functions(Wilbert).
Replace convert_a.asm for yuy2 to rgb.
Redo SEH exception handling code.
VirtualQuery/GetModuleFileName + Trap on Invoke(SEt).
Use LoadLibraryEx/LOAD_WITH_ALTERED_SEARCH_PATH for plugins.
Use GetVarDef() extensivly.
Handle exceptions from DevIL.dll now being delay loaded.
Explicitly catch stray std::bad_alloc and report.

BUGFIXES

Supereq gain arguments can only be int, enforce it.
Fix handle leak with "Exists"(SEt)
Fix VDub plugin race on cleanup
Fix TCPDeliver crash with bad hostnames.
Fix ShowSMPTE non-integer fps message not being thrown (raffriff42).
Fix avisynth_c plane=0. Default params are not allowed in plain C.
Fix MergeLuma allow any Planar test(Wilbert).
Remove redundant self class spec from definition(Wilbert).

ENHANCMENTS

Evaluate Invert arguments once in Constructor not every GetFrame, Doh!
Move matrix decision into Convert constructor, overcome exceed cacheline.

BUILD CHANGES

Remove msvcP*.dll dependances.
Add AsFloatF(), compiler sugar!
Move to /W4 compiler warnings.
Isolate void BitBlt(...) & long GetGPUFlags() functions.
Add VDCall as __cdecl to VDub api calls
Add __cdecl declaration to all api calls(SEt).
Code cleanup(SEt).
Improve precompiled header usage.
Use #pragma comment to control link options.
Turn off RuntimeTypeInfo for the rest of the solution.
Patch BaseClasses to avoid ATL/MFC dependance.
Add build environment tags to various filenames and values.
Amend template AVS_BUILD strings.
Link with nothrownew.obj.
Remove writable system32\avisynth.dll dependency.
Dodge 2005-2015 compiler bug with nested try/catch.
Fix missing advapi32.lib for debug builds.

Chikuzen

18th May 2016, 03:27

Is this bug fixed ?
https://github.com/AviSynth/AviSynthPlus/commit/ab4ea303b4ca78620c2ef90fdaad184bc18b7708

Reel.Deel

18th May 2016, 03:48

ENVIRONMENT CHANGES and UPDATES

Update to SoundTouch 1.9.0(Wilbert+IanB).

Any plans to update to SoundTouch 1.9.2? v1.9.1 introduced a couple of quality enhancements:

1.9.1:

Improved SoundTouch::flush() function so that it returns precisely the desired amount of samples for exact output duration control
Redesigned quickseek algorithm for improved sound quality when using the quickseek mode. The new quickseek algorithm can find 99% as good results as the default full-scan mode, while the quickseek algorithm is remarkable less CPU intensive.
Added adaptive integer divider scaling for improved sound quality when using integer processing algorithm

I asked about a while back here (http://avisynth.nl/index.php/Talk:TimeStretch) but didn't get a reply.

MysteryX

18th May 2016, 05:45

These SoundTouch 1.9.1 improvements sound like the difference between using TimeStretch in v2.6 where there the audio got slightly out of sync and in AVS+ where the sync is perfect.

real.finder

18th May 2016, 07:00

what about this? http://forum.doom9.org/showpost.php?p=1736293&postcount=55

jpsdr

18th May 2016, 09:21

Has some pinterf bug corrections and improvement to match last VDub version for VDub load plugin here (https://github.com/pinterf/AviSynthPlus/commit/da3c42a03d0a44d466c7421fe4a1688ac5c8d450) been included ?

Wilbert

18th May 2016, 21:53

@Chikuzen,

Nope not included. Why is this a bug? It only makes a difference if align is negative correct?

@Reel.Deel, MysteryX
Will be updated in 2.6.1 if it has a bug. Say if audio goes out of sync or something like that. Otherwise it has to wait for 2.6.2.

@real.finder,
We need to look at this.

@jpsdr,
Nope not included. Are there any virtualdub plugins which will not load if this change is not included? Otherwise it's for 2.6.2.

bilditup1

18th May 2016, 23:52

Figures that on the day I decide I've had it with avs mt (is it less stable because of Windows 10? I'm really at a loss) a new mainline avs is released. So far, so good (ie everything is fine, nothing is ruined, no crashes, no corruption that I can tell, using AviSynth_20160517_VC2008Exp SSE2 version)

Chikuzen

19th May 2016, 03:09

@Chikuzen,

Nope not included. Why is this a bug? It only makes a difference if align is negative correct?

some my plugin filters require 32bytes aligned pointer and pitch to support AVX2.
https://github.com/chikuzen/YV12To422

However, even if I call env->NewVideoFrame(vi, 32), avisynth returns 16 bytes aligned frame.
Because it uses hard coded FRAME_ALIGN value to calculate offset.

jpsdr

19th May 2016, 08:57

@jpsdr,
Nope not included. Are there any virtualdub plugins which will not load if this change is not included? Otherwise it's for 2.6.2.
2.6.2 will be good enough.

And i support Chikuzen on his issue, it's clearly a bug if you have the possibility to choose aligned value but it's not respected.

Reel.Deel

19th May 2016, 14:22

@Reel.Deel, MysteryX
Will be updated in 2.6.1 if it has a bug. Say if audio goes out of sync or something like that. Otherwise it has to wait for 2.6.2.

Ok. Any plans to update the TimeStretchPlugin for the meantime?

Wilbert

22nd May 2016, 15:58

Ok, i see that aligned frames > 16 are not respected. Will ask IanB to fix it.

@Reel.Deel,
csv is updated to SoundTouch 1.9.2.

Groucho2004

22nd May 2016, 17:51

Operation and exception handling seems identical to the 2.6.0 release for all 3 versions after the few tests I did.

I see that UPX is still used to compress some of the binaries.
The size argument really doesn't apply any more since hard drives nowadays are slightly bigger than they were 20 years ago.
For some reason many people use anti virus programs, most of which are so bad that they instantly throw up false positives when they come across a UPX packed file.
You're also introducing more complexity into the DLL loading process. You might think this argument is ridiculous but no software is bug free.

A comment on the VC2008/SSE2 version:

I made a VC2010 test build and played around with the compiler switches a bit, "/arch:SSE2" or "/arch:SSE" have almost zero impact on speed. In fact, "/arch:SSE" is a tiny bit faster than "/arch:SSE2".
Therefore I suggest to omit these switches since they also may have an influence on floating point accuracy in under certain circumstances. I highly recommend reading the "Remarks" section for the "arch" switch on MSDN (https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.100%29.aspx).

Motenai Yoda

22nd May 2016, 19:31

@Groucho2004 If I'm not wrong the precision problem is only with /arch:SSE, which has single precision, while booth x87 FPU and /arch:SSE2 have double precison...
Also you can try with /fp:fast too?

LoRd_MuldeR

22nd May 2016, 20:24

@Groucho2004 If I'm not wrong the precision problem is only with /arch:SSE, which has single precision, while booth x87 FPU and /arch:SSE2 have double precison...

Actually the original x87 FPU has 80-Bit precision, which is more than double precision (64-Bit). It's sometimes called "extended" precision.

Furthermore, with /arch:SSE set, the compiler is allowed to use SSE instructions, but it is not restricted to SSE instructions. In particular, if you program contains double precision math, the compiler has to pick CPU instructions, from the set of available instructions, that satisfy your code. Which means that, if SSE doesn't contain suitable instructions for your code and SSE2 is not available, then the compiler has to fallback to x87 FPU.

Groucho2004

22nd May 2016, 20:59

Here (https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/) is a nice article analysing the SSE/SSE2 switches. Scroll down to "/arch:SSE/SSE2" if you're impatient.

None of this may matter for Avisynth but it's something of which a developer should be aware.

Motenai Yoda

23rd May 2016, 10:34

@Lord yep but vs defaults use 53bit precision and 15bit exponent for x87 FPU instead of the 80bit one, this way precision is "compatible" with the SSE2 (53+11) one, but not with SSE which is 24+8...

@Groucho that article is unclear about the speeds he measure, 35% is about SSE2 vs SSE2 or SSE2 vs x87 ?

Groucho2004

23rd May 2016, 10:45

@Groucho that article is unclear about the speeds he measure, 35% is about SSE2 vs SSE2 or SSE2 vs x87 ?It seems clear that it is SSE2 vs no SSE2 (i.e. x87).

Anyway, let's not drag this out any further, my point was simply that adding "-arch:SSE2" brings virtually no speed advantage so it makes sense to omit it.

Motenai Yoda

23rd May 2016, 12:48

[OT mode ON]
well it says MulFloat vs MulDouble booth SSE2 optimized, and MulFloat slower coz internally cast Floats to/from Double.
(I don't think a SSE2 assembler code can be +36% slower than a x87 one anyway)
Also says that with vs2012+ the issue about intermediate precision should be almost fixed.
[OT mode OFF]
Anyway as most of the hot stuff is in assembly, targeting a specific arch shouldn't give noticable changes, would be nice compare a build without devs assembly and made compiler generate it.

real.finder

7th July 2016, 06:28

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToY8()
orig = last
Blur(1)
compare(last,orig)

in avspmod

Traceback (most recent call last):
File "avsp.pyo", line 9061, in OnMenuVideoToggle
File "avsp.pyo", line 13855, in ShowVideoFrame
File "avisynth.pyo", line 462, in GetFrame
WindowsError: exception: access violation reading 0x05B98000

this happened in 2.6.0 too

Wilbert

8th July 2016, 22:00

I can't replicate your issue. If i open the script in Virtualdub (with either 2.6.0, 2.6.1a1 (AviSynth_20160517_VC2008Exp SSE2.exe) or latest csv) i get no errors.

I got an error though if i convert the solution to msvc2010, compile a debug build and run the script

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToY8() # crashes on this line
ConvertToRGB32()

If i click on negeren (= ignore) the script loads fine. If i compile a release build the script runs also fine :confused:

Groucho2004

8th July 2016, 22:42

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToY8()
orig = last
Blur(1)
compare(last,orig)

This is what I get when running that script with AVSMeter:
AVSMeter 2.3.0 (x86) - Copyright (c) 2012-2016 Groucho2004
AviSynth 2.61, build:May 17 2016 [16:06:18] VC2008Exp (2.6.1.0)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: D:\WINNT\system32\avisynth.dll
Address: 0x00ABFC0B
This also happens with 2.6.0. The script runs fine with AVS+.

sqrt(9801)

9th July 2016, 02:03

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToY8()
orig = last
Blur(1)
compare(last,orig)

Getting an access violation as well, on 2.6.1 and 2.6.0.

It looks like using Compare() on two Y8 clips causes it, unless you specify channels="Y".

StainlessS

9th July 2016, 09:29

What sqrt(9801) said.

Maybe need special case here

text-overlay.cpp, line 1379 [ Compare::Compare() ]

if (channels[0] == 0) {
if (vi.IsRGB())
channels = "RGB";
else if (vi.IsYUV())
channels = "YUV";
else env->ThrowError("Compare: Clips have unknown colorspace. RGB and YUV supported.");
}

EDIT: Could probably also add some kind of channel legality check, below also has access violation

ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToY8()
compare(last,Last,Channels="u")
return ConvertToRGB24

Wilbert

11th July 2016, 21:56

if (channels[0] == 0) {
if (vi.IsRGB())
channels = "RGB";
else if (vi.IsY8())
channels = "Y";
else if (vi.IsYUV())
channels = "YUV";
else env->ThrowError("Compare: Clips have unknown colorspace. RGB and YUV supported.");
}

if ((vi.IsY8() || vi2.IsY8()) && !(channels[0] == 'Y') && !(channels[0] == 'y')) {
env->ThrowError("Compare: One of the clips is Y8. In this case only channels = \"Y\" is supported.");
}

fixes both issues. Will be fixed in next release.

bcn_246

23rd July 2016, 12:15

Any word on an MT build of v2.6.1?

jackoneill

23rd July 2016, 16:51

Any word on an MT build of v2.6.1?

http://forum.doom9.org/showthread.php?t=168856
http://forum.doom9.org/showthread.php?t=165771

bcn_246

30th July 2016, 16:04

I chose to stick with StaxRip v1.2.2.0 which doesn't play nice with AviSynth+ (newer x64 builds were to buggy). A big effort has been made to port common filters to as x64 a lot of (especially older more obscure filters) are still x86 only.

I do some transfers that relay on some pretty obscure filters which it could be some time before a x64/VS port.

The speed benefit of x64 is undeniable for simple rips that use just common De-block/De-interlace/Crop/Resize, but if my processing chain looks like you will see why I have stuck with AviSynth v2.6 MT

Source decode -> AviSynth x86 filters -> Lossless AVI render -> Load AVI -> AviSynth x64 filter -> x264/x265 encode
rather than ...
Source decode -> AviSynth x86 filters-> x264/x265 encode

Peace

jackoneill

30th July 2016, 17:51

StainlessS

5th September 2016, 06:57

:SOLVED: :)
No idea where I should post this, dont know if Avisynth, Grunt, VSFilter problem, or something daft that I've done.

Problem exhibited in AVS v2.6 (Standard and ICL) and also v2.58.

Changing pretty much anything below will remove the "Avisynth: Unknown Exception".

Function TestXXX(clip c,int q) {Return c}

Function FindXXX(clip c) {
q=0
return c.ScriptClip("TestXXX(q)",args="q") # args, req Grunt()
}

Colorbars
#ConvertToRGB24
TextSub("Cabaret.srt")
FindXXX()

Also tried with different subtitle file.

EDIT: Can anybody else confirm/reproduce similar problem.

EDIT: Same with empty plugins, except for VSFilter[v2.39.5.1 - 980 KB (1,003,520 bytes)] and Grunt.
EDIT: Same avs v2.61 (AviSynth_20160517_VC2008Exp SSE2.exe).

EDIT: Avisynth+ r2772 MT i386, "An error occurred while playing the file. (Error=80004005)"
Seems to be general unspecified error.
Troubleshooting Code Error 80004005 - Unspecified Error

Think of error 80004005 as meaning the script could not access your data. The most likely reason is a permissions related problem. Your best chance of resolving this problem is to study carefully any associated message, for example, 'File already in use', or 'Logon Failed'.
Opening in VirtualDubFilterMod, "CAVIStreamSynth: unhandled C++ exception".
EDIT: And MPC-HC reports this
kernel32!RaiseException+0x53
WARNING: Following frames may be wrong.
vcruntime140!CxxThrowException+0x65
avisynth+0x33aac
vsfilter!VirtualdubFilterModuleDeinit+0xe70
avisynth+0x19d08

Maybe VSFilter problem (disappears if ConvertToRGB24 [or almost any other mod]).

EDIT: XP32SP3.

EDIT: Also tried VSFilter v2.39.5.2 with same result.

Went back to old version VSFilter v1.0.1.1, and no more problem (dated 20050301), gonna stay with that one [From WarpEnterprises].

:SOLVED: :)

StainlessS

18th October 2016, 12:36

Is This new to v2.6 ? (I know I could install v2.58 and check but I'm lazy)

x=2 # False
#x=3 # True
#x=4 # True
#x=5 # True
#x=6 # False
Z=(3 <= x <= 5) # I would usually use something like (3 <= x && x <= 5)
MessageClip(String(z))

Thought I'de found a bug in my script Assert() but seems to work just fine.
Is there anything to be aware of when using as above ? (I've never noticed any similar usage before).

EDIT: This also works

x=2.0 # False
#x=3.0 # True
#x=4.0 # True
#x=5.0 # True
#x=6.0 # False
Z=(3.0 <= x <= 5.0)
MessageClip(String(z))

Groucho2004

18th October 2016, 15:33

StainlessS

18th October 2016, 15:48

Thanx G2K4, but is it intended to work like that, or just a happy accident.
Dont see nuttin in docs about it.

By the way, in next ICL AVS 2.6, can you please ensure VersionString includes the comma separator after version number
"AviSynth 2.60, build:Mar 31 2015 [16:38:54]"
I use it to strip off just the version in Builtin AVS functions script, without build number [EDIT: Date] etc.
Maybe something like "AviSynth 2.60, (ICL) build:Mar 31 2015 [16:38:54]", I dont recall exactly how it was formatted.

Cheers :)

EDIT:
or
"AviSynth (ICL) 2.60, build:Mar 31 2015 [16:38:54]", to include ICL in stripped out version.
EDIT: I think same script works fine with AVS+. (I was gonna fix for ICL anyway)
EDIT: I strip off the build etc because I use it to produce a filename without ':' in it (guess I could scan/replace all non valid filename chars).

Groucho2004

18th October 2016, 15:59

Thanx G2K4, but is it intended to work like that, or just a happy accident.
Who knows. You'll have to look at the script parser code to find out.

By the way, in next ICL AVS 2.6, can you please ensure VersionString includes the comma separator after version number
"AviSynth 2.60, build:Mar 31 2015 [16:38:54]"
I use it to strip off just the version in Builtin AVS functions script, without build number [EDIT: Date] etc.
Maybe something like "AviSynth 2.60, (ICL) build:Mar 31 2015 [16:38:54]", I dont recall exactly how it was formatted.

Cheers :)

EDIT:
or
"AviSynth (ICL) 2.60, build:Mar 31 2015 [16:38:54]", to include ICL in stripped out version.
I doubt that I'll ever make a new one (based on 2.6.1) but I can update the current build.

StainlessS

18th October 2016, 16:04

but I can update the current build.

No please dont go to the trouble, Ill find a way around it, thanx anyway.

Gavino

19th October 2016, 00:40

is it intended to work like that, or just a happy accident.
As far as I know, it's deliberate and has always worked like that.
The parser accepts a chain of comparisons (see function ParseComparison() in scriptparser.cpp).
You can even do things like:
a < y > b == c # ... and more conditions if you want
which is interpreted as:
(a < y) && (y > b) && (b == c) # ...

StainlessS

19th October 2016, 01:32

which is interpreted as:

WOW, I is totally GobSmacked, that should not go un-noted in docs. (beautifully succinct)

see function ParseComparison() in scriptparser.cpp

Hmm, I am reasonably capable of parsing text/numbers, but that may I think be a bit beyond me (although I have not looked at it).

Just tried this too

x="a" # False
#x="b" # True
#x="C" # True
#x="d" # True
#x="E" # False
Z=("b" <= x <= "D")
MessageClip(String(z))

Still works OK (case insignificant).

Cheers big G, or should I say (to use your full name), Albus Percival Wulfric Brian Gavino. :)

StainlessS

9th January 2017, 02:40

We seem to have a little bit of inconsistency between RGB24 and RGB32 conversions from YV12 in Avisynth 2.6 and v2.61. (v2.5 and Avs+ immune).

Avisource("F:\v\StarWars.avi").Trim(10000,-1)
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
Subtract(A,B)
current_frame=0
return subtitle(String(averageLuma,"%f"))

On above particular frame of movie shows 126.001534 for ShowBlue Channel, other channels always 126.0.
Did not try other Planar, YUY2 -> RGB seems ok.

EDIT: YV24 also affected, no other planar tried.
EDIT: Problem resides down the left edge of frame, ie first byte blue channel (RGB32 I think).

EDIT: Show Difference (Amplified)

Function ClipDelta(clip clip1,clip clip2,bool "amp",bool "show") {
amp=Default(amp,false)
show=Default(show,false)
c2=clip1.levels(128-32,1.0,128+32,128-32,128+32).greyscale()
c1=clip1.subtract(clip2)
c1=(amp)?c1.levels(127,1.0,129,0,255):c1
return (show)?c1.Merge(c2):c1
}

Avisource("F:\v\StarWars.avi").Trim(10000,-1)
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
return ClipDelta(A,B,True)

FranceBB

10th January 2017, 18:58

Does compiling avisynth itself with anything greater than SSE2 bring any speed benefits?

StainlessS

11th January 2017, 22:35

Wilbert

16th January 2017, 22:34

Can someone at least acknowledge post #38, not sure if [Edit: above] post obscured it. Thanx.

EDIT: v2.6 anv2.61 are producing BAD (Blue channel) pixels down LHS of frame (RGB32, I think, could be wrong there).

[I'm guessin that its sumimck like < instead of <= that is the prob).
1) Please post the info of

Avisource("F:\v\StarWars.avi").Info

2) Could you replicate the issue with blankclip() as source?

StainlessS

17th January 2017, 01:49

Sorry Wilbert, I had not tried with BlankClip(pixel_type="YV12") nor ColorBars, tried now and it dont exhibit the same prob.
Also tried with several other test clips (also UT_Video ULY0 encoded), 4 out of five of further test clips showed same prob, fifth no prob. ???

Here a 10 frame avi showing prob:- http://www.mediafire.com/file/72qz2sotbedjrcc/Cab.7z

and similar-ish test script

Fn="Cab.avi"
Avisource(Fn)
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
Subtract(A,B)
Return ScriptClip("""subtitle(String(current_frame)+"] "+String(averageLuma,"%f"))""")

EDIT:
Just to totally take UT_Video out of the picture, I just tried RandomSource() source filter:- https://forum.doom9.org/showthread.php?t=166546&highlight=randomsource
and it also produces the problem. (direct link to RandomSource zip [~32KB]:- http://www.mediafire.com/file/56elg7a22ju41uj/RandomSource-v1.00-20151029.zip)
[RGB32 640x480@24FPS, random colored pixels]

RandomSource.ConvertToYV12
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
Subtract(A,B)
Return ScriptClip("""subtitle(String(current_frame)+"] "+String(averageLuma,"%f"))""")

I did not post the requested Info() result, its just an ordinary YV12 AVI, and above should be enough to locate the prob.

EDIT: RandomSource.ConvertToYV24, same problem.

EDIT: This script

RandomSource.ConvertToYV24
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
Subtract(A,B)
crop(0,0,120,120)
ScriptClip("""subtitle(String(current_frame)+"] "+String(averageLuma,"%f"))""")
PointResize(640,480)

Produces this [EDIT: Above changed from Spline36Resize to PointResize and below updated result (png)].
https://s20.postimg.org/mm3jdsnel/Random_zpsbklajvvh.png (https://postimg.org/image/8fnsikcjd/)

EDIT: Tried this mod
A=ConvertToRGB24.ConvertToRGB32.ShowBlue(pixel_type="YV12")
and this,
B=ConvertToRGB32.ConvertToRGB24.ShowBlue(pixel_type="YV12")
Same problem results, would seem to exonerate RGBxx->ShowBlue (ie prob is in one of the YUV -> RGBxx conversions).

EDIT: Below mod, add GreyScale, same result.
RandomSource.ConvertToYV24.GreyScale

EDIT:
This produces no problem

c=0
GScript("""
for(i=0,255) {
color=((i*256+i)*256)+i # 256 lines, Grey $000000 -> $FFFFFF
c1=blankClip(height=1,width=32,color=color,Pixel_type="YV24")
c=(c.IsClip)?StackVertical(c,c1):c1
}
c
""")
A=ConvertToRGB24.ShowBlue(pixel_type="YV12")
B=ConvertToRGB32.ShowBlue(pixel_type="YV12")
Subtract(A,B)
PointResize(320,256) # Make more visible (if there)
Return Last

got me stumped, previous 'GreyScale()' call did not remove prob, yet Greyscale created clip has no prob ???
[EDIT: As in prev script, lines created with random luma level (grey), still no problems]

EDIT: Here, original StarWars.avi Info (post cropping of black frame), dont think of much use though.
The clip is from DVD VOB, cropped letterboxing, and used from SSD as a standard test clip (encoded as UT_Video FourCC 'ULY0',also 44.1 KHz audio).
https://s20.postimg.org/lxuouuoot/Info_zpsgd4de6mg.jpg (https://postimg.org/image/hopysolfd/)

EDIT: Similar problem on a P4.

EDIT: ShowBlue completely exonerated,

RandomSource
ConvertToYV24.GreyScale # Note, GreyScale
A=ConvertToRGB24
B=ConvertToRGB32.ConvertToRGB24
# Alternative, similar result
#A=ConvertToRGB24.ConvertToRGB32
#B=ConvertToRGB32
#
Subtract(a,b)
PointResize(640,480,0,0,8,0)
Return Last

https://s20.postimg.org/c1tlv7iwt/Rand4_zps0qv0dxpm.jpg (https://postimg.org/image/n1et6t9bt/)

EDIT: I was wrong, problem definitely in ConvertToRGB24

RandomSource
ConvertToYV24.GreyScale # Note, GreyScale : EDIT: or ConvertToY8
#Crop(4,0,0,0) # Removes problem
ConvertToRGB24 # Problem in ConvertToRGB24
#ConvertToRGB32 # Alternative, NO Problem in ConvertToRGB32
A=ShowRed
B=ShowBlue
Subtract(A,b)
PointResize(640,480,0,0,8,0)
Return Last

https://s20.postimg.org/v71x233wd/Rand5_zps5n5qnoze.jpg (https://postimg.org/image/6qjr7m35l/)

EDIT: Adding Crop(4,0,0,0) to above script (in Blue) removed the problem (maybe uses C code).
Adding Crop(16,0,0,0) instead, does not remove problem (still asm).
Adding Crop(4,0,0,0,align=True) also removes problem, (maybe vi.width has to be mod 16 too for asm), not sure if I'm confused again :)
Adding Crop(0,0,-4,0,align=True/False), also removes problem, and Crop(0,0,-16,0,align=True/False) does not, asm must also need mod 16 vi.width as well as mod 16 base alignment..
Conclusion:- Problem in YUV -> ConvertToRGB24 asm.

EDIT: The UT_Video Avi clip (Cabaret) that did not have problem was (after all around border cropping) 668x396 PAL ie not mod 16 width.

EDIT: By Default, RandomSource uses seed of 0, ie frames repeatable across sessions.
EDIT: For RandomSource, I just used default align for NewVideoFrame, perhaps reason why exhibits problem.
From Avisynth VERSION 3 HEADER (v2.58)

// align should be 4 or 8
virtual PVideoFrame __stdcall NewVideoFrame(const VideoInfo& vi, int align=FRAME_ALIGN) = 0;

StainlessS

1st April 2017, 12:51

OMEM Errors, Avs Standard v2.6 and v2.61.

#####################################################################################################
# #
# GetFrameBuffer: returned VFB with a 0 data pointer! etc, I think we have run out of memory folks! #
# #
#####################################################################################################

#Blankclip(width=-20)
#Blankclip(height=-20)
#colorbars(width=-20)
colorbars(height=-20)

#Blankclip(length=-20) # OK, well no crash

Groucho2004

1st April 2017, 14:59

OMEM Errors, Avs Standard v2.6 and v2.61.

GetFrameBuffer: returned VFB with a 0 data pointer! etc, I think we have run out of memory folks!
colorbars(height=-20)
AVS+:
Requested buffer size of 4294916127 is too large

StainlessS

8th September 2017, 06:23

Would be nice if this worked.

Colorbars.killaudio.Subtitle("""Some text line 1\nline 2\nline3\n""",lsp=0,align=2)

Shows only top line.

FranceBB

2nd February 2018, 11:51

TheFluff

2nd February 2018, 16:46

Any news? Can we expect a release soon? Like an alpha2 or a beta or maybe a stable?
It's been a while since May 2016.

Out of curiosity:
1) will Avisynth support BT2020 and HDR in the next release?
2) will Avisynth officially implement high bit depth, without using Dither Tool / HDRCore?
3) would Avisynth get any speed improvement if compiled with SSE4.2 instead of just SSE2?

I look forward for the next release and I really look forward to get BT2020 support.
Don't get me wrong, post-processing in 16bit with Dither Tool is fine, but it would be really helpful to get official high bit depth support like in Avisynth+ instead of using an "hack".

Thank you in advance.

It is highly unlikely that it will ever be updated again. SourceForce made CVS repositories read-only a long time ago and there have been no attempt to move it to any new form of source control. Whoever intended to work on it would have to start there.

Avs+ is the only active version of Avisynth now. If you don't like it, I suggest trying Vapoursynth for a more modern experience.