AviSynth 2.6.1 alpha 1 [May 17th, 2016]

[Wilbert]

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/avi...#91;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]

Is this bug fixed ?
https://github.com/AviSynth/AviSynth...ad184bc18b7708

[Reel.Deel]

Originally Posted by Wilbert

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 but didn't get a reply.

[MysteryX]

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]

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

[jpsdr]

Has some pinterf bug corrections and improvement to match last VDub version for VDub load plugin here been included ?

[Wilbert]

@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]

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]

Originally Posted by Wilbert

@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]

Originally Posted by Wilbert

@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]

Originally Posted by Wilbert

@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]

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]

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.

[Motenai Yoda]

@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]

Originally Posted by Motenai Yoda

@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]

Here 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]

@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]

Originally Posted by Motenai Yoda

@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]

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

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