View Full Version : AviSynth 2.6.0 [May 31st, 2015]


Wilbert
2nd June 2015, 20:53
A few days but 2.6.0 has gone live!

Get AviSynth_260.exe and Avisynth_260_src.zip (https://sourceforge.net/projects/avisynth2/files/AviSynth%202.6/AviSynth%202.6.0/) from Sourceforge. Six years and five months have passed since the last stable release ;) Hopefully the next one will be a bit sooner ...

AviSynth_260.exe is x86 only (so there is no x64 version).

The changelog can be found here (http://sourceforge.net/projects/avisynth2/files/AviSynth%202.6/AviSynth%202.6.0/readme.txt/download). (It's too long to put it in one post, that's why the link.)

Sparktank
2nd June 2015, 21:04
I was pretty excited over the email notice from SourceForge.

Great job for everyone who contributed thus far. :)

Feels like there should be a speech with each stable release.

mastrboy
4th June 2015, 23:13
Off topic, mods should delete if too inappropriate

Those who keep projects on sourceforge should carefully monitor their exe installers, as sourceforge lately injected ad-ware into popular project installers.

Reference material:
http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/

mariner
5th June 2015, 01:51
Can 2.6 coexist with 2.58?

l33tmeatwad
5th June 2015, 04:05
Can 2.6 coexist with 2.58?Why would you want to do that?

Groucho2004
5th June 2015, 09:42
Can 2.6 coexist with 2.58?
The question is too general.
Could you install both in parallel and have the client application choose between them? No.
You can however switch between Avisynth versions very quickly as described here (http://forum.doom9.org/showthread.php?t=172124).

Unless you have to use a program that demands an older version of Avisynth there is no apparent reason not to use 2.6.

manolito
5th June 2015, 12:43
Could you install both in parallel and have the client application choose between them? No.


Well, in same cases applications can choose between different versions... ;)

I found out about this by pure coincidence. Until recently I was still using AviSynth 2.57 because my good old DVD2SVCD would not show a preview with any newer version.

But now I can use AviSynth 2.60 and still make the DVD2SVCD preview use 2.57. How?

I installed 2.60 normally, AviSynth.dll resides in the System32 folder. Additionally I copied AviSynth.dll 2.57 into the DVD2SVCD root folder. Now the preview (which is done by the DVD2SVCD executable itself) uses the AviSynth.dll it finds in its own folder, while any encoder (which resides in a different folder) uses the installed AviSynth version 2.60. Very nice...


Cheers
manolito

Groucho2004
5th June 2015, 12:51
I installed 2.60 normally, AviSynth.dll resides in the System32 folder. Additionally I copied AviSynth.dll 2.57 into the DVD2SVCD root folder. Now the preview (which is done by the DVD2SVCD executable itself) uses the AviSynth.dll it finds in its own folder, while any encoder (which resides in a different folder) uses the installed AviSynth version 2.60. Very nice...
I was referring to a normal install without any modifications. One install would simply overwrite the other.
Also, some applications load avisynth.dll explicitly from system32/syswow64 so your trick would not work in that case.

qyot27
6th June 2015, 00:01
That's actually not the application choosing to use a different version, that's normal Windows DLL loading behavior (I would assume if the program simply queries the system %PATH% rather than hardcoding a DLL location). Windows itself has a loading hierarchy; it starts with the program's directory, and then moves to the system. Although Windows won't let you override some system DLLs with this method, but it should work for most %PATH%-aware queries (you can also swap avisynth.dll copies in and out of FFmpeg's folder if you need to use different versions there as well - and in its case, yes, it does just query the system by using LoadLibrary(AVISYNTH_LIB)).

I'd mentioned this tactic in some of that discussion in the MKVToolNix thread regarding the idea of substituting Wine DLLs (which turned out to be one of those cases where Windows won't let that work, although DirectX DLLs can be overridden with Wine's).

jmac698
6th June 2015, 09:07
Big news.. congratulations on completing this

8-BaLL
9th June 2015, 20:10
Is there a freaking reason, why the Install Folder which is automatically created, still called Avisynth 2.5?

I mean with the betas and RCs Id understand it, but in the final? Come on...

You know its freaking irritating every single time Im trying to paste something in the folders or work with the plugin paths.

Wilbert
9th June 2015, 20:34
Just uninstall, and enter Avisynth as install folder when doing a fresh install.

foxyshadis
10th June 2015, 08:00
The installer defaults to just %ProgramFiles%\Avisynth now, but for existing installs it'll pick up and continue to use your old folder, as you'd expect. You don't even need to uninstall, just rename it and reinstall with the new folder name.

YamashitaRen
11th June 2015, 13:54
Even better, you can rename the folder and regedit the relevant key :p
(tested on Wine)

StainlessS
11th June 2015, 16:09
Great stuff guys, lovely to have Officially stable v2.6 :thanks:

Is there a published machine minimum requirement for v2.6 (or v2.58 for that matter, on windows) ?

Also,

from v2.6 docs
Future plans
AviSynth v2.61:
This version will use the free Microsoft compiler. It will be feature identical to 2.60 i.e. Source new syntax changes only!


Has it been decided yet which of the free compilers will be chosen (there are a few of them) ?

Thanxs

Groucho2004
11th June 2015, 16:40
Is there a published machine minimum requirement for v2.6 (or v2.58 for that matter, on windows) ?

It will probably run on a Pentium 1 or even below but who would want to do that? Even masochistic people would run it at least on a P4 / Athlon64.

StainlessS
11th June 2015, 17:42
Thanx Grouchy, had not seen any official requirement post anywhere, suspected P1.
I, is one of them there masochisticals with 3 (or is it 4) P4's and 1 Athlon64.
Thanx for the answer.

Groucho2004
11th June 2015, 18:40
Thanx Grouchy, had not seen any official requirement post anywhere, suspected P1.
I have not found a system requirements statement either.

There are a lot of factors that determine the minimum CPU requirement. Avisynth.dll itself is probably the easiest to please, assuming that there are C/C++ variants for all functions (no MMX/SSE/3DNow only functions).

Once you add external filters, things will change since many plugins are built with newer compilers and these may produce binaries which won't run on ancient CPUs.

I'm not sure about DevIL.dll, the newer versions may require a newer CPU.

StainlessS
11th June 2015, 19:55
Thanx again Grouchy.
Dont want to step over and above what is officially supported by the Avisynth dll, so I guess that may put it about PIII (I think Manolito
and at least one of the devs/contributors to Vapoursynth use PIII), guess I'll just stick with straight CPP and avoid anything non-standard.

Ive got one of those Elonex ONE+ things (300MHz i386 [equivalent], bit faster than my original Pentium I @ 133MHz), but alas not the MIPS variant that
was hacked to install a more open (usable) version of Linux (LLL, The Little Linux Laptop). So I guess there could be some i386/i486's out there running
Windows that could be faster (on paper) than Pentium I (with/without FPU).

I've been targetting XP, is W2K officially supported by AVS ?, also, are there C/CPP variants for all functions ?

Some kind of System Requirement entry could be a good idea on the Wiki, even if it has to be a bit vague.

EDIT:
From AVS+,
Shortcomings compared to Avisynth
- Support for Windows 98/Me/2000 dropped. Oldest supported OS in Windows XP.

From Vapoursynth homesite:
http://www.vapoursynth.com/2012/11/minimum-requirements/
Unfortunately that post was quickly followed by "R25 – Death to Windows XP!":- http://www.vapoursynth.com/2014/11/r25-death-to-windows-xp/

So I guess that rules out my ever trying Vapoursynth :(

innocenat
12th June 2015, 05:20
also, are there C/CPP variants for all functions ?


No. In Avisynth you need at least MMX processor, so minimum is PMMX. Resizer is one of the code that doesn't have C/C++ code, not sure if any other. Avisynth+, however, supports all the way down to 80386 with 80387 coprocessor, 486DX, or 486SX with 487 coprocessor, given than you re-compile it with no ISE, since the official one use SSE for floating point calculation :D

StainlessS
12th June 2015, 08:12
Most informative, thanx innocenat :)

Wilbert
13th June 2015, 14:02
Great stuff guys, lovely to have Officially stable v2.6 :thanks:

Is there a published machine minimum requirement for v2.6 (or v2.58 for that matter, on windows) ?

Also,

from v2.6 docs
Future plans
AviSynth v2.61:
This version will use the free Microsoft compiler. It will be feature identical to 2.60 i.e. Source new syntax changes only!


Has it been decided yet which of the free compilers will be chosen (there are a few of them) ?

Thanxs

v2.61 will have the following features/updates:

support for 2K5, 2K8 and 2K10.
external libraries will be updated and converted to plugins.
convert_a.asm will be converted to softwire.
rewrite exception handling.
bugfixes.


As for your other question. What innocenat said. The resizers, but also layer and mask don't have c/c++ equivalents (they have minimal mmx).

StainlessS
13th June 2015, 14:19
Dank u vel Wilbert :)

RRD
18th June 2015, 10:25
Is it normal that Version() reports

AviSynth 2.60, build: Mar 31 2015 [16:38:54]
© 2000-2014 Ben Rudiak-Gould, et al.
http://www.avisynth.nl

? While I understand that no recent change was made to AviSynth (http://forum.doom9.org/showthread.php?p=1722669#post1722669), it can be very confusing for users who may think they downloaded an older version.

Groucho2004
18th June 2015, 10:54
Is it normal that Version() reports

AviSynth 2.60, build: Mar 31 2015 [16:38:54]
© 2000-2014 Ben Rudiak-Gould, et al.
http://www.avisynth.nl

? While I understand that no recent change was made to AviSynth (http://forum.doom9.org/showthread.php?p=1722669#post1722669), it can be very confusing for users who may think they downloaded an older version.
I'm not sure if it was an oversight or intentional to not rebuild avisynth.dll (and other components) for the release. The problem with the info from "Version()" is that it just uses a couple of compiler macros to reflect the build time and date. The version info is a bit ambiguous to some.

I think the copyright notice should also have been updated to "© 2000-2015 ...".

Wilbert
18th June 2015, 18:54
It was intentional. I understand it might be confusing.

real.finder
28th July 2015, 20:45
I note that DevIL.dll in AviSynth_260.exe is too old

Groucho2004
28th July 2015, 21:07
I note that DevIL.dll in AviSynth_260.exe is too old
Too old for what? You're free to update to v1.78 from here (http://openil.sourceforge.net/download.php), it should be compatible with AVS 2.6. If you do so, use the non-Unicode, 32 Bit version for Windows.

real.finder
28th July 2015, 22:23
Too old for what? You're free to update to v1.78 from here (http://openil.sourceforge.net/download.php), it should be compatible with AVS 2.6. If you do so, use the non-Unicode, 32 Bit version for Windows.

I already did this from years, I mention this for upcoming releases

Groucho2004
28th July 2015, 23:06
I already did this from years, I mention this for upcoming releases
From what I recall, DevIL 1.7.8 was not included because of its dependency on the dreaded msvc*80 DLLs.

Wilbert
29th July 2015, 20:56
From what I recall, DevIL 1.7.8 was not included because of its dependency on the dreaded msvc*80 DLLs.
That's indeed the reason.

Overdrive80
3rd August 2015, 16:58
Hey, I have installed win10 and autoload plugins in avisynth not working now, did you know?

Groucho2004
3rd August 2015, 17:49
Hey, I have installed win10 and autoload plugins in avisynth not working now, did you know?
The detail in your bug report is staggering. :rolleyes:

Clean Win10 install or upgrade? If upgrade, did you (have to) re-install Avisynth?
With which software are you testing this and are there any error messages? Did you check the registry for the auto-load directory pointer ("PluginDir2_5" in Software/Avisynth in HKCU or HKLM)?

Overdrive80
3rd August 2015, 21:35
The detail in your bug report is staggering. :rolleyes:

Clean Win10 install or upgrade? If upgrade, did you (have to) re-install Avisynth?
With which software are you testing this and are there any error messages? Did you check the registry for the auto-load directory pointer ("PluginDir2_5" in Software/Avisynth in HKCU or HKLM)?

Really its not bug report but you are right.

I upgrade from win7. I have reinstalled avisynth. I have testing with vdub. No, I dont check registry, could you put complete direction for creating reg file??

Thanks, bro.

Groucho2004
3rd August 2015, 21:45
No, I dont check registry, could you put complete direction for creating reg file??
:confused:
The installer is supposed to write the reg entry. Just check if it's there.

Overdrive80
4th August 2015, 07:52
Keys registry was missing. I solved with:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"
"plugindir2_5"="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AviSynth]
@="C:\\Program Files (x86)\\AviSynth 2.5"
"plugindir2_5"="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"

Thanks and apologize for disturbing. :thanks:

Groucho2004
4th August 2015, 08:06
Keys registry was missing. I solved with:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]
@="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"
"plugindir2_5"="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AviSynth]
@="C:\\Program Files (x86)\\AviSynth 2.5"
"plugindir2_5"="C:\\Program Files (x86)\\AviSynth 2.5\\plugins"

Thanks and apologize for disturbing. :thanks:
As I mentioned, the installer should have written this entry. It seems that you (or rather the installer) did not have sufficient rights to write it. I think you need admin rights to write to HKLM.

Overdrive80
4th August 2015, 08:19
As I mentioned, the installer should have written this entry. It seems that you (or rather the installer) did not have sufficient rights to write it. I think you need admin rights to write to HKLM.

I ever execute with admin rights if fails. --

kuchikirukia
9th August 2015, 03:36
Reasonable speedup in QTGMC. 12.23fps --> 13.03 in AVSMeter on this 480p source. Xeon X3450, Win10. Though I get exactly the same in 2.6MT single-threaded.

Groucho2004
9th August 2015, 08:11
Reasonable speedup in QTGMC. 12.23fps --> 13.03 in AVSMeter on this 480p source. Xeon X3450, Win10.
What exactly did you compare?

Though I get exactly the same in 2.6MT single-threaded.
Which is to be expected:
4. Short guide to SetMTMode
SetMTMode is the command that switches Avisynth into MT mode. Without it MT Avisynth works like the usual one.

RRD
9th August 2015, 11:40
I installed AviSynth 2.6.0 [May 31st, 2015], three files were created in the /AviSynth/plugins folder:
http://abload.de/img/avisynth_2.6.0_201505uysej.png (http://abload.de/img/avisynth_2.6.0_201505uysej.png)

Whenever I try to use SoundOut() I get “Script error: there is no function named "SoundOut"”.

I downloaded Wilbert's SoundOut26-1.1.1.zip (http://www.wilbertdijkhof.com/SoundOut26-1.1.1.zip) (that he posted in http://forum.doom9.org/showpost.php?p=1654982&postcount=185). If I put SoundOut.dll and libsndfile-1.dll in the /AviSynth/plugins folder, SoundOut() works.

Several pages indicate that the SoundOut plugin is included in AviSynth from 2.6.0 on (http://avisynth.nl/index.php/SoundOut), so I believe the behaviour I am experiencing is not normal.

Oddly, it is not mentioned in the 2.6.0 changelog (AviSynth/Docs/English/changelist26.htm file).

The same issue occurred on my two PCs (Windows 7 32-bit and Windows 7 64-bit) and I fail to see what I did wrong.

Groucho2004
9th August 2015, 13:27
Several pages indicate that the SoundOut plugin is included in AviSynth from 2.6.0 on (http://avisynth.nl/index.php/SoundOut), so I believe the behaviour I am experiencing is not normal.
Oddly, it is not mentioned in the 2.6.0 changelog
All I can tell you is that SoundOut is not part of the Avisynth core no matter what is written on some pages.
The change log is the most reliable source.

Wilbert
9th August 2015, 15:45
Yes it's not part of the core yet, i will update the documentation.

ryrynz
15th August 2015, 03:18
Wilbert, using ffdshow and Avisynth 2.6 with Tritical's NNEDI3 using the following syntax

nnedi3_rpow2(rfactor=2)

is causing display issues (interlaced, stretched and wrong colors) in the media player MPDN, this issue does not occur with MPC so the developer thinks it's related to to memory corruption which .NET is quite strict on. I haven't encountered any issues using any other filters in MPDN with ffdshow.

Any chance I could get you track down where the issue lies?

The only thing that seems to affect it is setting RGB out in ffdshow, this changes the colors to match the original frames.

This issue occurs also with Avisynth MT and jpsdr's NNEDI3.
Cheers.

hello_hello
15th August 2015, 07:44
The only thing that seems to affect it is setting RGB out in ffdshow, this changes the colors to match the original frames.

I don't know about the stretching, but I've found (using XP) that MPC-HC uses the wrong colorimetry for HD video (rec.601) when opening Avisynth scripts, unless ffdshow's raw video decoder is enabled in which case it displays using rec.709. I don't understand why, but a different set of filters is used.

With ffdshow's raw video decoder enabled (for YUV):
AVI/wav file source
ffdshow video decoder
WMR9 (renderless)

With ffdshow's raw video decoder disabled:
AVI/wav file source
AVI decompressor (YV12)
colour space converter
WMR9 (renderless)

In the second case I assume the colour space converter is converting to RGB using the wrong colorimetry.

Groucho2004
15th August 2015, 08:47
causing display issues (interlaced, stretched and wrong colors) in the media player MPDN, this issue does not occur with MPC so the developer thinks it's related to to memory corruption
I can't follow the logic here. How does this point to Avisynth being the cause?

You should start with the most likely candidates for this problem,
- player/renderer
- ffdshow

Have you tried with AVS+?

Groucho2004
15th August 2015, 08:48
I don't know about the stretching, but I've found (using XP) that MPC-HC uses the wrong colorimetry for HD video (rec.601) when opening Avisynth scripts, unless ffdshow's raw video decoder is enabled in which case it displays using rec.709. I don't understand why, but a different set of filters is used.
Why is this in the Avisynth thread?

ryrynz
15th August 2015, 13:30
I can't follow the logic here. How does this point to Avisynth being the cause?

You should start with the most likely candidates for this problem,
- player/renderer
- ffdshow

Have you tried with AVS+?

The logic is to start where you think someone can help :)

Player - I've already asked as above, perhaps his conclusion could be wrong, IDK, that's what I'm trying to figure out.
Renderer - No options to switch renderer in MPDN, but I've already tried all the options for output. Either I get no image or a distorted one.
ffdshow - no dev, no help. Again I've already looked at all the options, no difference.

Yes, same issue with AVS+ too (1576) Also occurs on my Intel graphics system running 7 (the other is running 10 with a 750Ti) so it's not related to any Windows version or graphics card drivers.

It would be quite simple to replicate, just need someone who can determine what's causing it and my first thought was Wilbert. Any help is appreciated.

Groucho2004
15th August 2015, 14:01
The logic is to start where you think someone can help :)

Player - I've already asked as above, perhaps his conclusion could be wrong, IDK, that's what I'm trying to figure out.
Renderer - No options to switch renderer in MPDN, but I've already tried all the options for output. Either I get no image or a distorted one.
ffdshow - no dev, no help. Again I've already looked at all the options, no difference.

Yes, same issue with AVS+ too (1576) Also occurs on my Intel graphics system running 7 (the other is running 10 with a 750Ti) so it's not related to any Windows version or graphics card drivers.

It would be quite simple to replicate, just need someone who can determine what's causing it and my first thought was Wilbert. Any help is appreciated.
OK. All Avisynth versions show the same behaviour. I'm quite certain that you can rule out Avisynth.
You mentioned MPC, I would try MPC-HC and/or MPC-BE (or any other suitable player you can think of). If your problem doesn't show up with those I think you have found your culprit.

Edit: One more thing you could try is setting the internal number of threads to 1 in nnedi3.

ryrynz
15th August 2015, 14:29
OK. All Avisynth versions show the same behaviour. I'm quite certain that you can rule out Avisynth.
You mentioned MPC, I would try MPC-HC and/or MPC-BE (or any other suitable player you can think of). If your problem doesn't show up with those I think you have found your culprit.

No issues with HC, BE, Zoomplayer or Potplayer. Guess I'll need Zach to look into it further.. I do wonder though what's different about the output of NNEDI3 that causes this to happen. I've had no issues with any other filters.

Groucho2004
15th August 2015, 14:33
I do wonder though what's different about the output of NNEDI3 that causes this to happen. I've had no issues with any other filters.
Have you tried what I suggested in my edit above?

ryrynz
15th August 2015, 14:42
Tried it, threads=1 and 0, also tried opt=1 and fapprox=0, no change.

foxyshadis
17th August 2015, 05:14
Try ending the scripts with Info() to figure out what colorspace nnedi3 is converting to. Maybe that'll sort it.

real.finder
29th August 2015, 00:32
ColorBars(width=640, height=480, pixel_type="RGB32")
ConvertToYV12(interlaced=true,chromaoutplacement="dv")
SeparateFields
uToY



ColorBars(width=640, height=480, pixel_type="RGB32")
Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true)
SeparateFields
uToY


there are a noticeable difference in vertical shift between them, I think the ConvertToYV12 do the dv-pal chroma with reverse u and v in shifting

----


edit: look like it not in ConvertToYV12 only

test with yv16

ColorBars(width=640, height=480, pixel_type="RGB32")
ConvertToYV16(interlaced=true)
SeparateFields
uToY



ColorBars(width=640, height=480, pixel_type="RGB32")
Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true)
ConvertToYV16(chromainplacement="dv", interlaced=true)
SeparateFields
uToY


edit: YToUV(VToY8(), UToY8(), ConvertToY8()) (or SwapUV()) before and after ConvertToXXX will solve the problem

ryrynz
24th September 2015, 11:39
Try ending the scripts with Info() to figure out what colorspace nnedi3 is converting to. Maybe that'll sort it.

Info() just shows that YV12 being used. Subtitles delivered by xysubfilter appear perfectly normal on top of the stretched pink and green distorted display. Still no closer to figuring this one out. One thing I didn't mention is that nnedi3 used with awarp4 delivers the proper output.

Also if I launch a script playing that doesn't have nnedi3 in it and then change to one that does via ffdshow raw the output is correct, if I start with that script then the picture is distorted.

Another thing I've noticed is that when using MPC and nnedi3/ffdshow any subtitles displayed get processed by nnedi3, with MPDN they don't.. could that be related somehow? Disabling subtitles completely in MPDN doesn't change anything so I guess not.

StainlessS
8th December 2015, 05:13
Below Fails in v2.5 but works ok in v2.6.


INPUT=avisource("F:\V\cabaret.avi")
return last


Only mentions of 'Last' in v2.6 ChangeList below


Fixed AviSource NULL GetWritePtr() failure due to premature setting of last_frame.
WriteFileStart/End save current_frame and set Last.
Change implicit Last parsing for argless, bracketless calls to match bracketed cases. (Gavino)


Is it a bug or undocumented change ?

EDIT: Same for

INPUT=Directshowsource("F:\V\cabaret.avi")
return last


EDIT: IGNORE ABOVE ...
Uninstalled Avisynth completely. Deleted remaining Avisynth directory. Ran CCleaner and Cleaned registry too.
Re-installed Avisynth v2.6. No longer succeeds with above code snippit.
No idea at all why it succeeded before :confused::confused::confused::confused::confused::confused:

Groucho2004
12th December 2015, 19:20
Hello. Anyone compiled Avisynth using Visual C++ 2015?
Don't do it.
Newer compilers expect the code to be compliant with SEH (Microsoft Structured Exception Handling) which the current code base is not.

Apparently, Avisynth 2.6.1 will be compatible with newer compilers (http://forum.doom9.org/showthread.php?p=1726246#post1726246).

Groucho2004
12th December 2015, 19:38
Groucho2004, /SAFESEH:NO
Never used it, I'd have to research what it does and if/how it would help.

Groucho2004
12th December 2015, 22:18
I have successfully compiled it (with SEt MT mod). It seems work correctly and exceptions are work too.
Ok. Please run this script with AVSMeter and tell us what happens:
setmemorymax(9999)
n = 12
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 9999)
pointresize(width() - 64, height() - 64).turnleft()
temporalsoften(2,4,8,15,2)
pointresize(width() + 64, height() + 64).turnright()
temporalsoften(2,4,8,15,2)
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)

Groucho2004
13th December 2015, 10:08
Groucho2004,
You mean benchmark or memory usage? It works with the same speed as the reference mt 2.6 build and it eats the same memory (using your script or my real usage scripts). The difference is +/-1 %
That script causes Avisynth to throw an out of memory exception after reading 1 or 2 frames. I just wanted to know if your DLL behaves correctly in this situation.

It works with the same speed as the reference mt 2.6 build and it eats the same memory (using your script or my real usage scripts).I'm surprised, to say the least, that the script actually worked for you. :eek:

Groucho2004
13th December 2015, 21:35
Groucho2004, I edited "n" to get it working, because it seems to me as a benchmark code for huge frames. A non-edited state gives a memory exception, of course.
Can you post the DLL so we can try it?

Also, did you build the 2.6.0 release code or did you use a current CVS snapshot?

Groucho2004
14th December 2015, 21:52
Groucho2004, /SAFESEH:NO
FYI - Ultim and the other AVS+ developers spent many hours re-writing the exception handling code in Avisynth to make it compatible with new compilers.
IanB is doing the same with Avisynth 2.6.1, check the Avisynth CVS.
Yet, you think they are all wasting their time and a simple linker switch would solve the problem?

Groucho2004
15th December 2015, 10:27
What problem do you mean? Currently it seems I have no issues yet. If you have any real test case that will crash my build or my build will work incorrectly, please post it. Probably this potential issue is long away from my usage. And, I will try the dev version 2.6.1 later, thanks for a point.
Here (http://stackoverflow.com/questions/550451/will-new-return-null-in-any-case) is some info on one of the issues.
In AVS+, all "new" allocations were checked regarding dependency on returning "NULL" and changed to the non-throwing (std::nothrow) version where applicable.
You can test this by running the script I posted and check the thrown exception. It should look like this:
GetFrameBuffer: Returned a VFB with a 0 data pointer!
size=2123366464, max=2108096512, used=4246732928, free=2113339392, phys=2847870976
I think we have run out of memory folks!
But you're probably just getting something like this:
Evaluate: Unrecognized exception!

The other thing is to implement a way to handle Win32 exceptions (C structured exceptions) as C++ typed exceptions. This can be done by implementing a SEH translator function, that also was done in AVS+.

Yes, your DLL will probably work but it's up to you if you can live with heavily crippled exception handling.

Edit: I just noticed that SEt's modified version does include a SEH exception translator.

Myrsloik
3rd January 2016, 23:02
This is a less insane version of AVSValue::Assign() in interface.cpp that actually works in both 32 and 64 bit builds:
void AVSValue::Assign(const AVSValue* src, bool init) {
if (src->IsClip() && src->clip)
src->clip->AddRef();
if (!init && IsClip() && clip)
clip->Release();
// make sure this copies the whole struct!
array_size = src->array_size;
type = src->type;
string = src->string;
}

I had to fix it when adding my own 2.6 compatibility...

Fizick
21st March 2016, 22:58
I tried to recompile C-plugin Yadif with 2.6.0 headers.
GCC and VS compilers detect error in avisynth_c.h with =0 at line:
AVSC_API(int, avs_row_size)(const AVS_VideoInfo * p, int plane=0);
Without =0 compiling is normal.

Wilbert
17th May 2016, 22:28
I tried to recompile C-plugin Yadif with 2.6.0 headers.
GCC and VS compilers detect error in avisynth_c.h with =0 at line:
AVSC_API(int, avs_row_size)(const AVS_VideoInfo * p, int plane=0);
Without =0 compiling is normal.
Should be fixed in 2.6.1. Please try.

@rean, your bug should be fixed too in 2.6.1.