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. |
15th September 2013, 23:32 | #1 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Avisynth+
[MODERATOR EDIT:]
Current branch as of November 2019: The pinterf fork was integrated in main line like AviSynth+ 3.4.0 Download and sources: From GitHub Older superseded branch/fork: [Download: From GitHub (use version with vc_redist when installing for the first time) Sources: https://github.com/pinterf/AviSynthPlus] [END MODERATOR EDIT] Avisynth+ compared to Avisynth 2.6 - 64-bit version compatible - Multithreaded - High bit-depth support - Faster script startup and substantially faster core filters - Support for multiple ("shadow") plugin directories - Autoloading of C-plugins - Script language extensions, with support for multiline conditionals and loops. - Improved still image support and TimeStretch … and more to come as development continues Avisynth+ features for developers - Easy and fast compilation, with current compilers - 2x increased compilation speed - Improved debugging experience - Leaner and more logical project structure - Large parts of the code refactored … and being continuously improved How to install Use installer for the latest release from here. If classic AviSynth is already installed, you will be offered the choice of either upgrading or replacing it. In the first case you'll be able to switch back to classic AviSynth by simply uninstalling AviSynth+. Your existing plugins will be kept in both cases. Can I just replace the old avisynth.dll with the new one from AviSynth+? Yes, with some caveats. In Avisynth+ some core plugins have been moved to external plugin DLLs (but are still shipped with the core), so you'll manually need to copy those too. Avisynth+ uses a different C++ runtime, which needs to be installed separately. And last but not least, this will make your Avisynth and Avisynth+ plugins mix in the same folders, which you might not want (though it is harmless ATM). All in all, I recommend you use the Avisynth+ installer instead, which will take care of all these problems for you. Compatiblity to Avisynth Avisynth+ tries to provide a superset of Avisynth's features while staying compatible to existing code. This means you should be able to use plugins and scripts written for Avisynth without any problems with Avisynth+. The contrary however might not be true: Plugins and scripts written explicitly to take advantage of Avisynth+ might not work using the official Avisynth. Shortcomings compared to Avisynth - Support for Windows 98/Me/2000 dropped. Oldest supported OS in Windows XP. - TCPDeliver not included in the sources. However, TCPDeliver from official Avisynth can be used with Avisynth+. - Ability to load VFAPI filters is missing, hopefully temporarily. How to compile (without DirectShowSource) - Get Git for Windows. - Get CMake. - Get Visual Studio 2013 Community Version. - Clone the repository from GitHub. - Configure the project using CMake. No manual changes to CMake variables are necessary, just hit Configure, select yout compiler then Generate. - Load generated VC++ solution and compile. - Done. - OR alternatively to the above steps: For people who prefer to compile from the command line, qyot27 was kind enough to provide detailed compilation instructions from an Msys environment. See http://forum.doom9.org/showthread.ph...29#post1643929 . This is a community project and you are welcome to work on improving Avisynth+. Let us know what you're working on either here or on #avs-plus on Rizon, and join the discussions. Feel free to work on any feature you'd like, or if you are feeling unsure where to start, choose an open issue from the GitHub page. Testing, documenting, and giving any kind of feedback is also a great help. Avisynth Plugin Writing Tips Series Tip #1: Exceptions Tip #2: Parallel execution Tip #3: Choosing your AviSynth header Last edited by tebasuna51; 17th November 2019 at 00:52. Reason: New version |
16th September 2013, 00:17 | #2 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
A couple of observations after running a bunch of my test scripts:
Exception handling is different than the official (and my ICL) DLL. When Avisynth runs out of memory, this dialog is displayed: The official version(s) properly throw an error message like this: Code:
GetFrameBuffer: Returned a VFB with a 0 data pointer! size=12912704, max=2109149184, used=1564790336 I think we have run out of memory folks! However, this is rather academic since the plugins and filters determine the performance by a large margin. You should mention that the DLL is dynamically linked and that one needs the VC2012 runtime DLLs. I had to figure this out with Dependency Walker. All this was tested on XP32, SP3. |
16th September 2013, 00:47 | #3 | Link |
Registered User
Join Date: Aug 2006
Posts: 2,229
|
Both static and dynamically loaded libraries have their advantages and disadvantages. Static libraries give the benefit that you don't need to have other stuff installed, but the downside is that it will most likely be an outdated version of that library (say, VS2010). The same goes with programs with the VC++ libraries in their folder, the program will use that version instead of the one on the system. The real issue with this is that newer versions of the runtime libraries fix bugs and improve stability, possibly improve performance, and close security holes. Also having things static and the individual files means using space on the hard drive that really isn't required. Since the VC++ runtime libraries are basically universally required there should be no need to have the libraries statically loaded.
Most systems don't have the latest runtimes loaded and (unless you delete them, which is 99 percent safe to do so) have old versions of the libraries in varies program folders. Anyways, so far testing that build I haven't had any issues. Last edited by burfadel; 16th September 2013 at 01:18. |
16th September 2013, 01:44 | #4 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,992
|
If it dont compile well with later version compiler, then have a go at them.
VS6 is just fine and any later problems come from later lack of compatibility. Really annoys me when you need the latest version IE v...whatever to view a web page, misguided at the very least. I'm sure that you mean well but it dont need that kind of upheaval. Several posts preceded my outburst, was aimed at Ultim.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 16th September 2013 at 01:51. |
16th September 2013, 02:20 | #6 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,992
|
Not much different there then.
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
16th September 2013, 03:34 | #7 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,443
|
If for no other reason, this certainly makes the sources dead simple to build for those of us used to cross-compiling.
Ah, what the heck. Build instructions suitable for copy-and-paste: This guide assumes a familiarity with a more *nix-centric command line compilation methodology, because it's easier to provide direct instructions for this that can just be copy/pasted. MSys and 7zip should already be installed, and the user should know what a phrase like 'adding the directory to the system PATH' means. [AviSynth+ prerequisites] Code:
r1576 is the last milestone version that can built on XP with VS2010. Newer versions (which is what we care about) need at least VS2012. XP compatibility is still do-able by adjusting the toolset CMake uses. Install CMake: http://www.cmake.org/cmake/resources/software.html Add CMake's directory to the system PATH manually if the installer won't. Add 7zip to the PATH. Make sure that MSys' root directory (the one holding msys.bat) is also on the PATH. DirectShowSource requires a couple of big pieces here that building the AviSynth+ core itself does not. It's not a requirement to build DirectShowSource, especially with the options of using either FFmpegSource2 or LSMASHSource, but the guide wouldn't be complete if I didn't cover it. DirectShowSource requires strmbase.lib, the C++ Base Classes library, which for some reason isn't included in a standard install of Visual Studio. The source code for the library is provided with the Windows SDK, and requires the user to build it first. Code:
Download the Windows SDK 7.1: http://www.microsoft.com/en-US/download/details.aspx?Id=8442 Download the following ISO for x86: GRMSDK_EN_DVD.iso Verify against CRC32 or SHA1: CRC#: 0xBD8F1237 SHA1: 0xCDE254E83677C34C8FD509D6B733C32002FE3572 For convenience, you can use Pismo File Mount (if you've already got it installed for AVFS) to mount the ISO. Then just launch setup.exe and follow the wizard. Install only the Samples, uncheck everything else. Intellisense stays checked, though. Open VS2013 Express (or what is it, Community now?), and open the .sln file in the 7.1 SDK, at C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses Allow VS2013 to convert the project, switch it over to Release, and Build. That's it. For pre-SSE2 CPUs, make sure you switch the ARCH to either IA32 or SSE rather than leaving it disabled. This is buried in the Properties dialog. Code:
Download the DirectX SDK (February 2010): http://www.microsoft.com/en-us/download/details.aspx?id=10084 Only install the headers and libs from it. Uncheck everything else. Unlike the strmbase.lib stuff, there's no post-install stuff required. Code:
export STRMBASELIB="C:/Program Files/Microsoft SDKs/Windows/v7.1/Samples/multimedia/directshow/baseclasses/Release/strmbase.lib" export DIRECTXSDK="C:/Program Files/Microsoft DirectX SDK (February 2010)/Include" [Building AviSynth+] Start the Visual Studio Command Prompt You can use Visual Studio's stuff from MSys by launching MSys from the Visual Studio Command Prompt. So type 'msys' and hit Enter. Download the AviSynth+ source: Code:
git clone git://github.com/AviSynth/AviSynthPlus.git mkdir avisynth_build cd AviSynthPlus Code:
AVSDIRNAME=avisynth+_r$(git rev-list --count HEAD)-$(date --rfc-3339=date | sed 's/-//g') mkdir ../$AVSDIRNAME Code:
sed -i '4 s/^/#/' plugins/CMakeLists.txt Code:
cd ../avisynth_build For 32-bit: cmake -G "Visual Studio 12 2013" -T "v120_xp" -DDSHOWSRC_BASECLASSES_LIB="$STRMBASELIB" -DDSHOWSRC_DX_INCLUDE_PATH="$DIRECTXSDK" cmake --build . --config release mv Output avsplus_x86 mv avsplus_x86 ../$AVSDIRNAME rm -R * For 64-bit (DirectShowSource isn't really worth the effort on 64-bit, and most 64-bit users won't be on XP Pro 64-bit): cmake -G "Visual Studio 12 2013 Win64" cmake --build . --config release mv Output avsplus_x64 mv avsplus_x64 ../$AVSDIRNAME rm -R * cd ../ If you decided not to build DirectShowSource, omit the -DDSHOWSRC_BASECLASSES_LIB and -DDSHOWSRC_DX_INCLUDE_PATH options from the (32-bit) cmake command above. Packing the newly-built DLLs with 7zip: Code:
7za a -mx9 $AVSDIRNAME.7z $AVSDIRNAME Last edited by qyot27; 18th August 2015 at 04:47. Reason: Seriously, update these instructions |
16th September 2013, 07:08 | #8 | Link | |||
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
Quote:
Quote:
That is one of my long-term goals, it will probably take a lot of time though and I'm not working on that directly right now. Last edited by ultim; 16th September 2013 at 07:52. |
|||
16th September 2013, 08:02 | #9 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
I find your comparison to a webpage needing the latest browser version highly flawed. Needing only a newer version just for the sake of upgrading sure is misguided. But I didn't upgrade the project to compile only with VS2013. I left VS2005 (which is 8 years old!) and anything newer than that fully supported, and I upgraded for the sake of making it easier for people to compile. That makes 4 different Visual Studio generations supported! If you really want an analogon to webpages, I'd say my move is more like MS trying to banish IE6, which everyone is happy about, except for people who still develop for IE6. If you intend to keep Avisynth stuck to VS6, it will be an entry barrier for many people who'd otherwise try to contribute to the project. So this is why I think compatibility with VS2005+ is more important than VS6. |
|
16th September 2013, 09:43 | #11 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
It's obvious you have done a lot of work and are quite keen. You say you want your changes accepted upstream, yet you randomise the location of files and you make copious white changes to the sources. Hell, I would have love to restructure the tree to the way I think it should be, but I resist that urge very strongly. If you want to contribute changes you need to make them easy, very easy, extremely very easy to incorporate back into the original tree. If I download and apply a set of patches and compare the changes and see a small handful of very neat, very tidy and very concise changes, I will probably show a fair amount of interest and actively review the changes, checking the boundary conditions, inspecting the performance and considering the side effects. If I download a set of patches and they won't even apply because the files and directories have been moved and/or renamed, I probably won't bother looking any further. And if I do look further and I find a pant load of spurious white changes hiding the important differences then almost certainly I won't bother investigating further.
|
16th September 2013, 11:40 | #12 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
It is true that there is a lot of noise. However, I disagree that they hide the useful differences, because I always kept them separate. For example, any time I moved files I did that in a separate commit without changing contents, so that Git can clearly tell that it was only a rename, and I only changed the files in the next commit. Never in the same commit so that Git recognize moved files and not flag them as removed/added.
Also, important commits which fix bugs or affect well-defined features are also committed separately, to prevent them from mixing with "unimportant" changes. I was under the impression that you are also using Git, because your latest changes are in Git on GitHub. If you are in fact using Git, my changes will apply cleanly if you merge from my repository, and not export/import patchfiles. And even if you are using SVN, there are working bridges between Git and SVN so you can still pull my changes. So I don't really see your problem, especially because I *did* keep noise and useful changes in separate commits. Edit: Btw, telling me that I have randomized the file locations went a bit overboard. Anyone who checks out my repository can tell that the project structure is a thousand times cleaner than it ever was in the history of Avisynth. Last edited by ultim; 16th September 2013 at 14:22. |
16th September 2013, 20:10 | #15 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
Avisynth 2.6 is still a late 90's project at its core. Even when someone finally got around to breaking the API (after ten years), high bitdepth video still isn't supported, nor is 64-bit compilation (there are even a few comments in avisynth.h going "this will break on 64-bit!", gee thanks, it's almost 2014 now), all the old braindamaged API restrictions that sorta made sense in 2001 are still there and you still need to use CVS and support VC6, Windows 98 and pre-SSE CPU's because that's how it's always worked. Nobody is interested in developer friendly changes because nobody is developing Avisynth except poor IanB, and he understandably doesn't want to change his own environment. If you want to get anything done, I suggest you either fork or start contributing to VapourSynth. Last edited by TheFluff; 16th September 2013 at 20:20. |
|
16th September 2013, 20:28 | #16 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Thanks for contributing to Avisynth! You really made it hard to merge upstream though, since you have a lot of changes at once and with the project files reshuffling, it is sort of like a "code dump" for the upstream/original developers.
Ideally, the changes should be reviewed and then adopted, but in this form, it will be hard to do... |
16th September 2013, 21:21 | #17 | Link | ||
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
EDIT: I'd like to make it clear just once more, that me shuffling files should not make it that much harder to incorporate the changes. Because I have always done the "moving files" and "changing contents" in separate commits. So if upstream ever comes to a commit of mine which moved files, all he has to do is move files. Anything that changes contents will show up as a new commit, so there is never a case of a change being hidden just because the whole file shows up as new falsely. There is no friendlier or more respecting way to move files than this (except for the case when Ian moved to Git or SVN, in which case he wouldn't even have to move the files by hand). Quote:
Then, about this time, a "strange" (LOL) idea struck me: What if others have also started to make something that I was just planning to? So I fired up Google, and have found VapourSynth and Avxsynth. I saw that VapourSynth set mostly the same goals as I did, which was cool, but I was *very* annoyed by its choice of Python. Yes, it is a more powerful language, but also much harder to learn and use, and the syntax as implemented in VapourSynth is just too verbose. Anyway, I decided it is better if I help out one of the projects instead of just starting yet a another fork/alternative, and my decision fell to Avisynth. So after yet another few months of doing-other-things (diploma thesis, some free software, and looking for work), here I am contributing to Avisynth. Btw, I updated my announcement post with a new binary that only requires a much older VC++ runtime. I also looked at the exception handling reported by Groucho2004, and right now my best bet is that the "old" behavior is pure luck. Because even in the old code (and there is no difference to this in my changes), if we run out of memory, new memory must still be reserved for the red error clip (unless there is a frame in the free-list). Now, if there was not enough memory to reserve a new frame, there is also the probability that there won't be enough memory to construct the error clip either -> in which case the code can only crash, both old and new. I have verified my code on countless other exceptions and for me they always correctly resulted in an error clip, and the only time my build crashed was when constructing the error clip failed due to low memory. Last edited by ultim; 16th September 2013 at 21:54. |
||
16th September 2013, 22:05 | #18 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
|
|
17th September 2013, 05:26 | #19 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,443
|
Quote:
For that matter, my recommendation of hooking it into MSys isn't actually required either, but I'm not as comfortable with using variables and for loops through cmd.exe (also, the variables and for loops aren't necessary either if the user doesn't plan on using UPX packing or packing the generated .dlls up into a nicely-named archive). It can be done strictly through the Visual Studio Command Prompt. |
|
17th September 2013, 08:43 | #20 | Link |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Obviously, adding .avs syntax to VapourSynth crossed my mind too. The reason I chose Avisynth is because, even though VapourSynth has the same goals that I do, it is not quite there yet. It was built with threading in mind, yet it was (still is?) a gamble whether it locks up with Avisynth filters (and it doesn't have that many native fiilters). It also wants to be portable, but the tools for Linux are still missing (the best advice on the forums to step through a .vps script frame-by-frame is still to use VirtualDub under Wine, LOL). And just like me, VapourSynth also wants to be 64bit-compatible, but it cannot be built for x64 Windows. Furthermore, back then a few months ago, VapourSynth was missing widespread support in application like VDub, a console piper, ffms2 and so on. Plugin support is also larger, coz' AFAIK Vapour can't handle all Avisynth plugins. So as you can see, just because it has better goals than Avisynth, it doesn't mean it is more usable than Avisynth.
Avisynth of course also has most of these problems, yet due to better documentation, better support in applications, and the larger selection of plugins, it is still more usable. And given that I want to use it (not just develop it), these shortcomings played a large role when I've chosen Avisynth to contribute to. I see that some of the mentioned issues have been fixed in r18 and r19, but others are still current and will need a later release to actually fix. Another, less practical thing that discouraged me from working on VapourSynth as a developer was looking at its sources. Avisynth's code is in terrible shape, I'm not gonna beat around the bush. However, being 10 years old, and having been patched up with functionality that it wasn't designed to handle at all countless times, is at least an acceptable excuse. VapourSynth on the other hand, has similar spaghetti code, is even less documented, and just as hard to read. For a project that set out to correct Avisynth's mistakes, still young and with less features, this was unforgivable in my eyes. All these things being said, you can see I had more reasons to choose Avisynth than just the scripting language alone. |
Thread Tools | Search this Thread |
Display Modes | |
|
|