Avisynth+

[ultim]

Ok, figured out the problem, I had FFMS2.avsi file in there as well from an earlier FFMS2 version. The odd thing is that is has always been there and have not had a problem until now.

Edit: The ffms2.avsi was from v2.21. updating to the latest script fixed it.

Ok, that helps. Fix in next build.

[Groucho2004]

Muli-threading support: Yes
Damn, I only now noticed that typo. Must have been there for quite a while.

[ryrynz]

Is the difference really significant? I mean, are you sure it's not within the tolerance of measurement errors?

I'm sure, I did multiple runs and each time the CPU usage was a few percent lower, significant.. not really but then this script is only using ~25% CPU so this equates to 10% less CPU.
I'll upload the pics from Task manager later and also perform it again with some settings that push the CPU harder.

The differences are significant when I increase the load by substituting spline36 with nnedi3, here's the script.

ffdshow_source()
input4x = last.nnedi3_rpow2(rfactor=2, nsize=4, nns=1).nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
edgemask = last.aSobel.aBlur
aWarp4(input4x,edgemask,depth=2)
Prefetch(4)

With SetFilterMTMode("DEFAULT_MT_MODE", 2) at top of script
http://i.imgur.com/RmP5a7Xl.png

Without
http://i.imgur.com/9yPiuEcl.png

What's going on? Am using latest build 2082 with nnedi3 0.9.4.24 and pinterf's Awarpsharp.

[ultim]

I'm sure, I did multiple runs and each time the CPU usage was a few percent lower, significant.. not really but then this script is only using ~25% CPU so this equates to 10% less CPU.
I'll upload the pics from Task manager later and also perform it again with some settings that push the CPU harder.

The differences are significant when I increase the load by substituting spline36 with nnedi3, here's the script.

ffdshow_source()
input4x = last.nnedi3_rpow2(rfactor=2, nsize=4, nns=1).nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
edgemask = last.aSobel.aBlur
aWarp4(input4x,edgemask,depth=2)
Prefetch(4)

...



Tried to reproduce it but cannot, with or without ffdshow_source.

https://cloud.pados.hu/index.php/apps/files_sharing/ajax/publicpreview.php?x=1920&y=779&a=true&file=ryrynz_sfmm.jpg&t=eYWUU07xwdC1sTe&scalingup=0

I also do not yet see how this could be possible. Anyone else seeing this on their computer?

[ryrynz]

I also do not yet see how this could be possible. Anyone else seeing this on their computer?

I am using ffdshow raw with 16 read ahead buffers and MPC-BE if it makes any difference.

[ultim]

r2085 (http://avs-plus.net/builds) solves "Parse: Unrecognized exception!", and the problem with eedi3 (actually any plugin that uses OpenMP).

[Wilbert]

Bit-depth conversions (no dithering, no range conversion, etc...)
[LIST]
ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()
[/L IST]


Btw, regarding the functions ConvertTo8Bits(), etc ...
What about replacing them with a single one:
ConvertToBitDepth(bit-depth=8/16/float, dither=none/random/ordered/...)
http://forum.doom9.org/showthread.php?p=1773217#post1773217

[pinterf]

http://forum.doom9.org/showthread.php?p=1773217#post1773217
Didn't forget. And since there seem to be more new functions, once hight bit-depth rgb, planar rgb and the 10-14 bit things get added, somehow we'll have to keep order.

[Sparktank]

r2085 (http://avs-plus.net/builds) solves "Parse: Unrecognized exception!", and the problem with eedi3 (actually any plugin that uses OpenMP).

:thanks: No more crashes with .avsi in plugin_dir.

[yup]

Hi all!
Please advice way overwrite existing Avisynth.dll under Windows 10.
I am try using Freecommander run like admin, I do not see Avisynth.dll Windows/system32, but windows search show me at Windows/system32.
On my PC also run Avira antivirus.
yup.

[LigH]

If you use a 32 bit application as file manager, you have only access to the 32 bit system directory which is camouflaged as "Windows\system32" to a 32 bit application, but instead is "Windows\SysWOW64" in the file system under a 64 bit Windows OS. You need to use a 64 bit application as file manager to have access to both locations if you have a 64 bit Windows OS.

Being old enough to have used the Norton Commander during the DOS era, I still enjoy the Far manager (http://www.farmanager.com). It is abailable as both 32 bit and 64 bit application.

Once again for a clarification:

a) You have a 32-bit version of Windows (usual up to Windows 7, later deprecated):

Windows\system32 is your system directory for 32 bit DLLs and tools.


b) You have a 64-bit version of Windows (most probable from Windows 8 on, although already available earlier):

Windows\system32 is your system directory for 64 bit DLLs and tools. Only 64 bit applications will see this directory at all. It is hidden from 32 bit applications.
Windows\SysWOW64 is your system directory for 32 bit DLLs and tools. Only 64 bit applications will see this directory with this name. 32 bit applications will see this with the fake name Windows\system32.

This technique will ensure that each kind of application (32 or 64 bit) will look for their matching system DLLs always in a directory named "Windows\system32", and only the matching one is visible to them under this name.

[yup]

LigH!

Thanks for clarification.
I am install Multi Commander 64 bit and lucky.

yup.

[yup]

"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.
Thanks for advice!
Problem was related with jpsdr build nnedi3, after update all O'k.
yup.

[burfadel]

"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.

14.0.24210 is buggy. Microsoft released an update for it, but have seemed to have stuffed up the distribution of it! The updated version is 14.0.24212.

You can use my Redist installer, it has all the last runtimes for 2005 through to 2015, x86 and x64 versions (including the new 24212):

Visual C++ Redist Installer V44 - https://1drv.ms/u/s!AmGuHbW3zvrBmJFCnPBSK-pMSdxshA

[jpsdr]

14.0.24210 is buggy. Microsoft released an update for it, but have seemed to have stuffed up the distribution of it! The updated version is 14.0.24212.


And so, how did you get it ?

[yup]

After update to last version avs+ i am changed my script from
SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",3)
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
SetFilterMTMode("DEFAULT_MT_MODE",2)
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
PreFetch(8)
to
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
PreFetch(8)
All work stable, speed little lower if comparing to Set Mt version, but stability more important.
I am using 32 bit version because not all plugin available for 64.
yup.

[burfadel]

And so, how did you get it ?

The 24212 runtime packages are available to download from Microsoft if you know where to look. It appears they haven't updated the articles properly, but there are Microsoft download links that direct to the new version.

[real.finder]

And so, how did you get it ?

14.0.24212-x86
http://download.microsoft.com/download/9/a/2/9a2a7e36-a8af-46c0-8a78-a5eb111eefe2/vc_redist.x86.exe
14.0.24212-x64
http://download.microsoft.com/download/2/a/2/2a2ef9ab-1b4b-49f0-9131-d33f79544e70/vc_redist.x64.exe

[Groucho2004]

I made a new installer (https://www.dropbox.com/s/t6yg2cc900tkcgz/AviSynth%2B%20r2085.7z?dl=0) with the latest r2085 binaries.
Also, ricktendo updated his AIO runtime installer (http://repacks.net/forum/viewtopic.php?f=6&t=125) to include the 14.0.24212 runtimes.

With ricktendo's installer you can also selectively install runtimes. I made a batch file for that:
@echo off
:VS2005
start/wait VBCRedist_AIO_x86_x64 /ai5
:VS2008
start/wait VBCRedist_AIO_x86_x64 /ai8
:VS2010
start/wait VBCRedist_AIO_x86_x64 /aiX
:VS2012
start/wait VBCRedist_AIO_x86_x64 /ai2
:VS2013
start/wait VBCRedist_AIO_x86_x64 /ai3
:VS2015
start/wait VBCRedist_AIO_x86_x64 /aiV
There are a few more options, use "VBCRedist_AIO_x86_x64 /?".

[tormento]

I made a new installer

:thanks:

[thescrapyard]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail


Installed avisynth+ again, using the latest package installer for r2085, AVStoDVD still insists its version 0.1.0 and won't run the avisynth code as its looking for version 2.6.0 and above

I've directly edited the fileversion using FVIE I found trying to find a way to change just the version numbers

http://www.carifred.com/fvie/

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version

[LigH]

The "DLL version" is an attribute in the "manifest" addendum (IIRC), read by the operating system.

But the "AviSynth version" will probably rather be the return value of an API function; this you can't patch with a PE patcher. I wonder if AviSynth+ would need an override feature to camouflage its own version and pretend a compatible one.

[MysteryX]

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version
Again, I was right :)

[LigH]

Oh, then I misread this post, sorry. :o

[Groucho2004]

The "DLL version" is an attribute in the "manifest" addendum (IIRC), read by the operating system.

But the "AviSynth version" will probably rather be the return value of an API function; this you can't patch with a PE patcher. I wonder if AviSynth+ would need an override feature to camouflage its own version and pretend a compatible one.
In case of AVS+, the FILEVERSION/PRODUCTVERSION (which are read by AVS2DVD) come from "version.h.in" (-> avisynth.rc -> avisynth.res -> link with avisynth.dll).

The Avisynth version string is indeed exported by IScriptEnvironment() ("VersionString").

[Groucho2004]

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version
I'm glad it worked for you. Still, hacking the version info this way is generally a bad idea. There may be some scenarios where it will crash since the 2.6 and AVS+ APIs are not the same.
So, do it at your own risk and don't blame the developers if something goes wrong.

[Groucho2004]

Again, I was right :)
Yes, you were right. Giving terrible hacking advice is a great idea.

[ryrynz]

Oi.. ಠ_ಠ

[MysteryX]

I'm glad it worked for you. Still, hacking the version info this way is generally a bad idea. There may be some scenarios where it will crash since the 2.6 and AVS+ APIs are not the same.
So, do it at your own risk and don't blame the developers if something goes wrong.
AviSynth+ is designed to be compatible with AviSynth 2.6, that's its principal selling point.

Yes, you were right. Giving terrible hacking advice is a great idea.
A better idea is for the software developer to update its software, and until that's done, some temporary "hack" has to be applied. Not ideal, but it's just temporary. The idea is to get it working for now. It needs to be hacked some way or the other anyway.

Do you realize that for almost everything you insulted me on, it turns out that what you said was false and I was right?

You did give me great answers and feedback to various questions too, so I thank you for that. You make great contributions. Just a little bit of respect would be appreciated.

[qyot27]

Except that AVStoDVD has no problems using AviSynth+. thescrapyard isn't complaining about a fatal error, it's just a warning. MrC told them the exact same thing (http://forum.doom9.org/showpost.php?p=1775066&postcount=2968):
@thescrapyard

wait, if the AviSynth release check routine reports "0.1.0", then A2D will give you just a warning. Just ignore the warning and go ahead. Instead there is a show stop when AviSynth.dll is not found from the path taken from "HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth" registy key.

Which is your case?
If it's a fatal error, then it's not the version check doing it. There's something else wrong.


And I also just independently verified this with AVStoDVD 2.8.4. It has no problem:
<7/30/2016 11:41:20 AM>
START PROCESS
<>

<7/30/2016 11:41:20 AM>
PROJECT SETTINGS

DVD Video Standard: NTSC
DVD Titles number: 1
DVD Size: 159/4450 MB (4%)
DVD Output Setup: DVD Folder
DVD Label: DVD
DVD Menu: No Menu
Output Folder: C:\Users\Stephen\Documents
Delete Temp Assets Files: Yes
Delete Temp Working Files: Yes
Edit Command Parameters: No
Post Process Task: Show Progress Status window

PREFERENCES

MultiThread: 1
AVS Video Source Filter: A2DSource
AVS Audio Source Filter: A2DSource
AVS UpSize/DownSize Filter: Lanczos4Resize/Spline16Resize
Frame Adjust Strategy: 0
FPS Hard Conversion: 0
PAL SpeedUp: 0
NTSC SlowDown: 0
Video Resolution: 0
Video Encoder: 0
Video BitRate Min: 2500
Video BitRate Max: 8500
Keep DVD Compliant Video: 1
AC3 Audio Encoder: 0
Force FFmpeg for Long Audio: 1
DVD Audio Format: 0
DVD Audio BitRate: 192
Keep DVD Compliant Audio: 1
Normalize Audio: 0
Auto Delay Audio: 1
DVD Audio Language (Primary): EN - English
DVD Audio Language (Secondary): EN - English
DVD Subs Language (Primary): EN - English
DVD Subs Language (Secondary): EN - English
DVD Subs Font: Tahoma 16pt (255,255,255)
Chapters Interval: 5
Use Source Chapters: 1
DVD Burning Drive:
DVD Burning Speed: 4x
Auto Erase DVD RW: 1
Execute with Elevated Privileges: 0
Unload ActiveMovie Library: 1
Adjust DirectShow Filters at runtime: 1
Save General Settings: 0

SYSTEM INFO

Processor Name: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz
Operating System: Windows 10 (10.0.10586) 32 bit
User has Admin Rights: YES
Running with Elevated Privileges: NO (3)
Available Output Disc Space: 4 GB
AviSynth is installed: YES (release 0.1.0)
LAV Filters is installed: YES (release 0.68.1)
ffdshow is installed: YES (release 1.3.4515)

CODECS REPORT

H.264/AVC: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
Xvid: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
DivX 4/5/6: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
Other MPG4: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
DV: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MPEG1: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MPEG2: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MP2: Microsoft DTV-DVD Audio Decoder {E1F1A0B8-BEEE-490D-BA7C-066C40B5E2B9}
MP3: MP3 Decoder DMO {BBEEA841-0A63-4F52-A7AB-A9B3A84ED38A}
AAC: Microsoft DTV-DVD Audio Decoder {E1F1A0B8-BEEE-490D-BA7C-066C40B5E2B9}
AC3: No Preferred Filter set

<>

<7/30/2016 11:41:20 AM>
TITLE 1 SOURCE FILES
Video: D:\test.avs
Info: AviSynth - 0 kbps - 1920x816 - DAR 2.353 - 23.976 fps (CFR) - 2:31 minutes - 3630 frames
Audio 1: D:\test.avs
Info: AviSynth - 0 kbps - CBR - 2 ch - 44100 Hz - 16 bit - 2:31 minutes (0 ms delay)
[AVSMeter.exe]
<>

<7/30/2016 11:41:20 AM>
AVISYNTH SCRIPT
Video = Import("D:\test.avs")
Audio = Import("D:\test.avs")

Video = Video.ConvertToYV12()
Video = Video.AddBorders(0,132,0,132)
Video = Video.Spline16Resize(720,480)
#PullDown: using DGPulldown/HCenc to upsize FPS

Audio = Audio.SSRC(48000)

AudioDub(Video, Audio)
<>

<7/30/2016 11:41:20 AM>
DIRECTSHOW AUDIO MIXER OPERATIONS:
No ffdshow mixer ON/OFF adjustment required at runtime
No ffdshow mixer SETTING adjustment required at runtime
No LAV Filters mixer ON/OFF adjustment required at runtime
<>

<7/30/2016 11:41:20 AM>
START VIDEO ENCODING OPERATIONS
Video Encoding Profile: FFmpeg CBR 1-pass
Target Video FileSize: 153 MB
Encoding Parameters: -i "C:\Users\Stephen\AppData\Local\Temp\DVD_test_1.avs" -threads 4 -aspect 16:9 -c:v mpeg2video -b:v 8500k -minrate 8500k -maxrate 8500k -bufsize 2000k -dc 10 -y "C:\Users\Stephen\Videos\DVD_test.m2v"
<>

<7/30/2016 11:43:06 AM>
END VIDEO ENCODING OPERATIONS
Created File: C:\Users\Stephen\Videos\DVD_test.m2v (153.4 MB)
OUTPUT VIDEO INFO: MPEG-2 Video - 8500 kbps - 720x480 - DAR 16:9 - 23.976 fps - Progressive - 2:31 minutes - 3630 frames
<>

<7/30/2016 11:43:06 AM>
START PULLDOWN OPERATIONS
DGPulldown Parameters: "C:\Users\Stephen\Videos\DVD_test.m2v" -srcfps 23.976 -destfps 29.97 -inplace -tff
<>

<7/30/2016 11:43:17 AM>
END PULLDOWN OPERATIONS
DGPulldown executed on File: C:\Users\Stephen\Videos\DVD_test.m2v (153.4 MB)
OUTPUT VIDEO INFO: MPEG-2 Video - 8500 kbps - 720x480 - DAR 16:9 - 23.976 fps - Progressive (2:3 Pulldown) - 2:31 minutes - 4534 frames
<>

<7/30/2016 11:43:17 AM>
START AUDIO ENCODING OPERATIONS (Track 1)
Wavi+Aften Parameters: "C:\Users\Stephen\AppData\Local\Temp\DVD_test_1.avs" - | "C:\Users\Stephen\Documents\AVStoDVD_284_NoInstall\Aften\aften.exe" -b 192 -pad 0 -dynrng 5 -bwfilter 0 - "C:\Users\Stephen\Videos\DVD_test_1.ac3"
<>

<7/30/2016 11:43:41 AM>
END AUDIO ENCODING OPERATIONS (Track 1)
Created File: C:\Users\Stephen\Videos\DVD_test_1.ac3 (3.5 MB)
OUTPUT AUDIO INFO: AC3 - 192 kbps - CBR - 2 ch - 48000 Hz - 2:31 minutes (0 ms delay)
<>

<7/30/2016 11:43:41 AM>
START DVD AUTHORING OPERATIONS
BatchMux Parameters: -arglist "C:\Users\Stephen\AppData\Local\Temp\DVD_BatchMux.ini"
BatchMux ini file:
-bmlog "C:\Users\Stephen\AppData\Local\Temp\DVD_BatchMux.log"
-d "C:\Users\Stephen\Documents\DVD\VIDEO_TS"
-mxp "C:\Users\Stephen\AppData\Local\Temp\DVD_MuxMan.mxp"
-l "C:\Users\Stephen\AppData\Local\Temp\DVD_MuxMan.log"
-muxman "C:\Users\Stephen\Documents\AVStoDVD_284_NoInstall\MuxMan"
-prio LOW
-palette "C:\Users\Stephen\AppData\Local\Temp\DVD_Palette.txt"
-v "C:\Users\Stephen\Videos\DVD_test.m2v"
-vidmode LB
-a1 "C:\Users\Stephen\Videos\DVD_test_1.ac3"
-a1lang en

<>

<7/30/2016 11:44:00 AM>
END DVD AUTHORING OPERATIONS
Created Folder: C:\Users\Stephen\Documents\DVD (159.5 MB)

CHECK DVD SIZE
DVD Folder (actual) Size: 159.5 MB
vs Assets Size: 156.8 MB -> OK
vs Estimated Size: 159 MB -> 0.3% oversize
<>

<7/30/2016 11:44:00 AM>
AVStoDVD Project ended successfully.
<>

<7/30/2016 11:44:00 AM>
Log file created by AVStoDVD Release 2.8.4
<>

[Groucho2004]

Do you realize that for almost everything you insulted me on, it turns out that what you said was false and I was right?
Do you realize that your opinions don't turn into facts just because you think you're always right?

[MysteryX]

Do you realize that your opinions don't turn into facts just because you think you're always right?
From now on I won't reply to any junk you throw at me; I'll leave your gifts to you.

I'm not here to argue as to who's right and who's wrong, and who's better than who. I'm here to contribute in what I can and share ideas. Taking other people's junk is not part of it.

Do whatever you want. I'll keep my center and focus. This is the last comment regarding any of your junk unless you really cross the line.

now AVStoDVD is accepting the avisynth.dll as a legitimate version
and there's no point in talking about a temporary problem that is already solved. At some point AVStoDVD will update their software. I certainly wouldn't hack AviSynth+'s source code to fix this.

[qyot27]

and there's no point in talking about a temporary problem that is already solved. At some point AVStoDVD will update their software. I certainly wouldn't hack AviSynth+'s source code to fix this.
There was no problem, temporary or otherwise, to 'solve' in the first place. What was being asked for was a frivolous revert of AviSynth+'s DLL versioning so that a harmless yellow warning sign and its corresponding warning message in AVStoDVD's GUI log widget would go away. A harmless warning sign/message that in no way stopped/stops the '0.1.0' versioned AviSynth+ from being used by AVStoDVD.

[thescrapyard]

There was no problem, temporary or otherwise, to 'solve' in the first place. What was being asked for was a frivolous revert of AviSynth+'s DLL versioning so that a harmless yellow warning sign and its corresponding warning message in AVStoDVD's GUI log widget would go away. A harmless warning sign/message that in no way stopped/stops the '0.1.0' versioned AviSynth+ from being used by AVStoDVD.

Sorry, but on my version of AVStoDVD 2.8.4 (very latest portable release) it was stopping me doing anything. All I hacked was the version being reported. It worked for me until things get updated or altered

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault

[Reel.Deel]

@thescrapyard

Maybe you should of posted these links ([1] (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199), [2] (http://forum.doom9.org/showpost.php?p=1775067&postcount=2201)) in the AVSToDVD thread.

[Chikuzen]

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.

[Groucho2004]

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.
You forgot the FILEVERSION/PRODUCTVERSION that is stored in the DLL version resource. This is for example "2.6.0.6" for 2.6 release and "0.1.0.0" for AVS+.
This is also what AVS2DVD checks since it does not use the Avisynth API.

[qyot27]

Sorry, but on my version of AVStoDVD 2.8.4 (very latest portable release) it was stopping me doing anything. All I hacked was the version being reported. It worked for me until things get updated or altered

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault
As I demonstrated above with the NoInstall package of AVStoDVD 2.8.4, it could recognize and use AviSynth+ (I was using a personal build ca. r2067) without any problem. Windows 10 Home 32-bit, with AviSynth+ installed in Program Files and AVStoDVD unpacked to a folder in Documents. So neither AVStoDVD's version detection nor AviSynth+'s change of versioning are at fault there. Version checks don't spontaneously work on one setup and fail on another in a case like this, unless there's something else in your personal configuration causing a problem, and it's whatever that problem is that's the real issue.

When reporting bugs, report everything about your setup, no matter how trivial you think it might be. Windows version, AviSynth+ build version (the revision number reported by Version(), not the stable release number), version of AVStoDVD if relevant. Whether you're using Administrator or User restricted privileges, where the programs are installed. If you've troubleshooted by moving the contents of AviSynth's plugins away from the autoload folder to ensure any one of those aren't causing an issue.


AviSynth+ changed its versioning during the early stages of the forking process because it had added so many new things that it no longer counted as merely a superset of AviSynth 2.6 but increasingly as its own project. Since the approved methods of checking the version number do not include the DLL versioning metadata, that was eventually also changed to match the canonical AviSynth+ versioning as well.

[Groucho2004]

As I demonstrated above with the NoInstall package of AVStoDVD 2.8.4, it could recognize and use AviSynth+ (I was using a personal build ca. r2067) without any problem. Windows 10 Home 32-bit, with AviSynth+ installed in Program Files and AVStoDVD unpacked to a folder in Documents. So neither AVStoDVD's version detection nor AviSynth+'s change of versioning are at fault there. Version checks don't spontaneously work on one setup and fail on another in a case like this, unless there's something else in your personal configuration causing a problem, and it's whatever that problem is that's the real issue.
I finally figured why AVS2DVD always complained that Avisynth is not installed. It checks the existence of this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]

I'm using my Avisynth switcher which writes this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]

See the difference? The check is case sensitive and therefore fails. I still stand by what I wrote in this (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199) post about how to properly validate an Avisynth install.

[MysteryX]

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.
In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

As for what value it returns, it's doing what it should: returning its version number. It may have the AviSynth 2.6 interface, but it's AviSynth+, and that's what I wanted to know.

If a software is specifically checking for an AviSynth version and it's not what it expects, then it's that software that must be udpated.

I finally figured why AVS2DVD always complained that Avisynth is not installed. It checks the existence of this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]

I'm using my Avisynth switcher which writes this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]

See the difference? The check is case sensitive and therefore fails. I still stand by what I wrote in this (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199) post about how to properly validate an Avisynth install.
I personally wouldn't use this because AviSynth.dll can work as a stand-alone DLL. But if one wants to know if it's "installed", which is different than "whether an AviSynth DLL is available", then yes that's the way to do it.

[Groucho2004]

In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

As for what value it returns, it's doing what it should: returning its version number. It may have the AviSynth 2.6 interface, but it's AviSynth+, and that's what I wanted to know.

...

I personally wouldn't use this because AviSynth.dll can work as a stand-alone DLL.
All that won't tell you if all dependencies are present. Not just the VC runtimes, the "official" Avisynth depends on devil.dll being present in the same directory.

So, I certainly wouldn't call avisynth.dll a "standalone" DLL (whatever that means).

Don't forget the first axiom for developers:
"Assumption is the mother of all f*ck-ups" :D

[LigH]

So, I certainly wouldn't call avisynth.dll a "standalone" DLL (whatever that means).

Don't forget the first axiom for developers:
"Assumption is the mother of all f*ck-ups" :D

Still, I assume :sly: ... that he may mean: The avisynth.dll does not necessarily need to be installed and hooked into the VfW API; an application may as well load it dynamically and use it via native interface.

[Groucho2004]

Still, I assume :sly: ... that he may mean: The avisynth.dll does not necessarily need to be installed and hooked into the VfW API; an application may as well load it dynamically and use it via native interface.
I can't bring myself to call a DLL stand-alone even if it is statically linked and has no dependencies (apart from system DLLs like kernel.dll). The DLL can't do anything on its own, it has to be loaded by an application.
Semantics - perhaps.

[LigH]

Well, yes ... maybe rather call it "indirect use" (using a system-wide registered DLL via VfW API) versus "direct use" (using a local DLL via native AviSynth interface, regardless of its system-wide installation into the VfW API).

[MysteryX]

Yeah, just copy AviSynth.dll and Devil.dll into either the system folder or the app folder and you're good to go.

Or more common, AviSynth 2.6 (or perhaps even 2.5.8) was installed and the DLL got replaced by AviSynth+ (before the new installer got released). In that case I wouldn't rely on the way the installer sets things up.

[TheFluff]

In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

That's retarded. It doesn't give you what you or the user wants at all. What you want is to know if you can load and successfully use the DLL. Checking metadata does not tell you anything at all about that and will lead to both false positives and false negatives (like in this AVS2DVD case).

The robust way to do feature detection is to try it and see if it works. Doing it this way also gives you graceful error handling unless you're being actively terrible about it.

[MysteryX]

That's retarded. It doesn't give you what you or the user wants at all. What you want is to know if you can load and successfully use the DLL. Checking metadata does not tell you anything at all about that and will lead to both false positives and false negatives (like in this AVS2DVD case).

The robust way to do feature detection is to try it and see if it works. Doing it this way also gives you graceful error handling unless you're being actively terrible about it.
No, what I want to know is whether to generate scripts using the 2.6 MT syntax or the AVS+ MT syntax. There are small script differences.

"Try and see" won't tell me this.

Plus in .NET, I cannot instantiate the DLL to call its API unless there is a DLL wrapper to expose its interface, and I don't use it directly in my code. I generate the script, then call avs2yuv or x264 or ffmpeg

[jpsdr]

As we are with internal mode creations (like uint16 and float), i would like to make a suggestion : An RGB planar mode.
This could be interesting for people who work with RGB video, don't want to convert them in YUV, but want good speed processing, because RGB32/RGB24 mode are not the easier data storage mode to process. The work will be minimal, because an RGB planar mode is somehow exactly the same thing than YV24. Your picture has 3 planes of the same size. You call for YV24 and RGBplanar exactly the same functions with the exact same parameters. Except, of course, format convertion functions.
What do you think ?

[qyot27]

As we are with internal mode creations (like uint16 and float), i would like to make a suggestion : An RGB planar mode.
This could be interesting for people who work with RGB video, don't want to convert them in YUV, but want good speed processing, because RGB32/RGB24 mode are not the easier data storage mode to process. The work will be minimal, because an RGB planar mode is somehow exactly the same thing than YV24. Your picture has 3 planes of the same size. You call for YV24 and RGBplanar exactly the same functions with the exact same parameters. Except, of course, format convertion functions.
What do you think ?
https://github.com/AviSynth/AviSynthPlus/pull/84

The big pixel type pull request, opened on July 26th. Not everything in there is working yet, but Planar RGB was there from the start.

[jpsdr]

Ah... Ok...