Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
17th May 2016, 22:54 | #1 | Link |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
AviSynth 2.6.1 alpha 1 [May 17th, 2016]
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.
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
Last edited by Wilbert; 21st June 2016 at 13:03. Reason: typo |
18th May 2016, 03:27 | #2 | Link |
typo lover
Join Date: May 2009
Posts: 595
|
Is this bug fixed ?
https://github.com/AviSynth/AviSynth...ad184bc18b7708
__________________
my repositories |
18th May 2016, 03:48 | #3 | Link | ||
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,666
|
Quote:
Quote:
|
||
18th May 2016, 07:00 | #5 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
what about this? http://forum.doom9.org/showpost.php?...3&postcount=55
__________________
See My Avisynth Stuff |
18th May 2016, 21:53 | #7 | Link |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
@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. |
18th May 2016, 23:52 | #8 | Link |
Registered User
Join Date: Feb 2004
Location: NYC
Posts: 124
|
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)
Last edited by bilditup1; 18th May 2016 at 23:52. Reason: added avs version I was using |
19th May 2016, 03:09 | #9 | Link | |
typo lover
Join Date: May 2009
Posts: 595
|
Quote:
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.
__________________
my repositories Last edited by Chikuzen; 19th May 2016 at 06:29. |
|
19th May 2016, 08:57 | #10 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Quote:
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. Last edited by jpsdr; 19th May 2016 at 09:01. |
|
22nd May 2016, 17:51 | #13 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
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. Last edited by Groucho2004; 22nd May 2016 at 17:58. |
22nd May 2016, 19:31 | #14 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
@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?
__________________
powered by Google Translator |
22nd May 2016, 20:24 | #15 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 22nd May 2016 at 20:28. |
|
23rd May 2016, 10:34 | #17 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
@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 ?
__________________
powered by Google Translator |
23rd May 2016, 10:45 | #18 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
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. Last edited by Groucho2004; 23rd May 2016 at 10:50. |
|
23rd May 2016, 12:48 | #19 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
[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.
__________________
powered by Google Translator |
7th July 2016, 06:28 | #20 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Code:
ColorBars(width=720, height=480, pixel_type="RGB32") ConvertToY8() orig = last Blur(1) compare(last,orig) Code:
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
__________________
See My Avisynth Stuff |
|
|