Avisynth+

[ultim]

[MODERATOR EDIT:]
Current branch as of November 2019:
The pinterf fork was integrated (https://forum.doom9.org/showthread.php?p=1888102#post1888102) in main line like AviSynth+ 3.4.0
Download and sources: From GitHub (https://github.com/AviSynth/AviSynthPlus/releases)

Older superseded branch/fork:
[Download: From GitHub (https://github.com/pinterf/AviSynthPlus/releases) (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 (https://github.com/AviSynth/AviSynthPlus/releases). 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 (https://git-scm.com/download/win).
- Get CMake (http://www.cmake.org/cmake/resources/software.html).
- Get Visual Studio 2013 Community Version (https://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx).
- Clone the repository (https://github.com/pylorak/avisynth) 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.php?p=1643929#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 (http://forum.doom9.org/showthread.php?p=1647262#post1647262)
Tip #2: Parallel execution (http://forum.doom9.org/showthread.php?p=1649886#post1649886)
Tip #3: Choosing your AviSynth header (http://forum.doom9.org/showpost.php?p=1712979&postcount=938)

[Groucho2004]

Feedback?
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:
http://www.iol.ie/~schubert/crash.png

The official version(s) properly throw an error message like this:
GetFrameBuffer: Returned a VFB with a 0 data pointer!
size=12912704, max=2109149184, used=1564790336
I think we have run out of memory folks!

The performance is about the same as with the official DLL, sometimes a little bit better. The ICL DLL is in some rare cases much faster.
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.

[burfadel]

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.

[StainlessS]

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.

[TheFluff]

VS6 is just fine and any later problems come from later lack of compatibility.

this statement is so bizarrely wrong that I am unable to formulate a polite response to it

[StainlessS]

this statement is so bizarrely wrong that I am unable to formulate a polite response to it

Not much different there then. :)

[qyot27]

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

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.

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.
DirectShowSource also needs the DirectX SDK, so we'll grab that too.
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.

To make the AviSynth+ build instructions more concise, we'll set a couple of environment variables. Open up MSys' /etc/profile and copy the following two lines into it somewhere:
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"
Thankfully, all of this setup only needs to be done once.


[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:
git clone git://github.com/AviSynth/AviSynthPlus.git
mkdir avisynth_build
cd AviSynthPlus
Set up the packaging directory for later:
AVSDIRNAME=avisynth+_r$(git rev-list --count HEAD)-$(date --rfc-3339=date | sed 's/-//g')
mkdir ../$AVSDIRNAME
If DirectShowSource won't be built, comment out the reference to its subdirectory in plugins/CMakeLists.txt:
sed -i '4 s/^/#/' plugins/CMakeLists.txt
Now, build AviSynth+. We'll do this out-of-tree so it's easy to clean up afterward:

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 ../

You can't build 32-bit and 64-bit at the same time.

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:
7za a -mx9 $AVSDIRNAME.7z $AVSDIRNAME

[ultim]

A couple of observations after running a bunch of my test scripts:
Exception handling is different than the official (and my ICL) DLL.
...
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.

Thanks, later today (after work) I'll reupload a version built with VS2005 to decrease the probability of VC runtimes needing to be installed. I'll also take a look at the exception handling problem.

The performance is about the same as with the official DLL, sometimes a little bit better. The ICL DLL is in some rare cases much faster.
That is about expected. As I mentioned in my original post, the optimizations are mostly to the initialization path. During frame-processing most time is spent in the plugins, BitBlt, and video frame allocation. I wasn't able to make BitBlt conclusively faster for now, and I've yet to take a closer look at the frame allocation path. Either way, most time is still spent in the plugins, so the only way to really speed Avisynth up is to improve the plugins.

If for no other reason, this certainly makes the sources dead simple to build for those of us used to cross-compiling.
Making it easy to build was the primary goal for now after all. Thanks for the additional instructions too. But as a note to others, you don't need the command line to compile if you are not familiar with it. Using CMake GUI and the VS IDE allows you to accomplish everything, even disabling the build of DirectShowSource (just unload the project in the IDE).

What would be great is if we could start working on making the AVS core 32/64-bit safe.
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.

[ultim]

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.

Hehe, I don't think I've made an upheaval, but if I did I'm sorry, I didn't intend to. But where I think you're wrong is that you are neglecting most of the community. Certainly, Avisynth doesn't strictly "need" a VS newer than VS6 to compile: compiled with VS6 it will work fine (not too surprising given it was mostly developed on VS6). But the people need newer VS versions. VS6 is so old that most people are used to newer environments, which by the way also brings better features for both debugging and comfort, as well as better compatibility for new OSs.

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.

[Groucho2004]

You should mention that the DLL is dynamically linked and that one needs the VC2012 runtime DLLs.
Thanks, later today (after work) I'll reupload a version built with VS2005 to decrease the probability of VC runtimes needing to be installed.
I only mentioned this so people know that the VS2012 runtimes are a requirement.

[IanB]

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.

[ultim]

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.

[Groucho2004]

I was under the impression that you are also using Git, because your latest changes are in Git on GitHub.
Avisynth is hosted here (http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/) and as far as I know, Ian is only maintaining it using CVS.

[ultim]

So Avisynth is only accepting contributions in the form of exported patch files? I have a full repository with cleanly separated changes and fully preserved history, and it is termed useless?

[TheFluff]

So Avisynth is only accepting contributions in the form of exported patch files? I have a full repository with cleanly separated changes and fully preserved history, and it is termed useless?

Avisynth is in many ways a project that is permanently stuck in the past, and all efforts have tried to modernize it are either forks (Avisynth-MT, Avisynth 64) or completely different projects (Avisynth 3, VapourSynth). You've found the reason for this the hard way.

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.

[mandarinka]

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...

[ultim]

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...

I understand that my "patches" are a lot of code. However, nobody is forcing IanB to review and merge them in one night. My commits are on GitHub and they won't go anywhere. He could take them one-by-one, and review and merge them over a course of 2-3 weeks or more. Just because I published them all at once does not mean they need to be reviewed all at once, especially because they are broken up into lots of small commits, with only a few exceptions towards the beginning.

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).

... and all efforts have tried to modernize it are either forks (Avisynth-MT, Avisynth 64) or completely different projects (Avisynth 3, VapourSynth). ...
If you want to get anything done, I suggest you either fork or start contributing to VapourSynth.

Well, I guess it is time for me to present my full story. I have known Avisynth for a very long time, but until about 8-9 months ago, I only new about some of its forks. So I've began laying out plans how I could implement a better Avisynth, because no matter how much I liked Avisynth, its flaws did (and do) bother me. Off the top of my head my ideas were: built for multithreading in its core, video frames should be taggable by custom information, 64-bit compatbility, cross-platform support, just to name a few. In one word: very (too?) ambitious. I had absolutely no time to implement this though until a few months passed. About half a year ago then, I started laying out an improved .avs scripting language, with full support for old scripts, but better language features, like proper multiline if-blocks, multiple return values, and some more. Actually, that was the sole reason I ported the Gold Parser to C++ (https://github.com/pylorak/GoldCPP). But I've done more than just port Gold Parser, I've even written and tested its language definition input file for my improved .avs syntax, in correct EBNF(-like) form and being able to parse!

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.

[TheFluff]

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.
As Stephen says, VapourSynth isn't tied to its scripting language like Avisynth is. VapourSynth is really just an API; the Python scripting component is just a module that calls that API. You can implement a new VapourSynth API wrapper in any language you want.

[qyot27]

Making it easy to build was the primary goal for now after all. Thanks for the additional instructions too. But as a note to others, you don't need the command line to compile if you are not familiar with it. Using CMake GUI and the VS IDE allows you to accomplish everything, even disabling the build of DirectShowSource (just unload the project in the IDE).
This is true. I just hate having to open up the Visual Studio IDE. Terminal-based compilation has me spoiled.

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.

[ultim]

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.

[ultim]

On a (not-so-) unrelated note, given that Avisynth's development has been mostly dormant with only very few contributors, it is not very motivating when somebody steps up with work and willingness to make the situation better, to tell him "go and work on that other project". Especially because nobody has said anything wrong about my proposals. If it had problems like breaking existing functionality or making code worse I'd understand. Or if IanB had reviewed them and told me "you should fix that differently because...", or any kind of constructive criticism, I'd go back and fix those things ASAP. But literally the only problem some of you had with my changes is that "there are too many", which makes me LOL in sadness. Should I beg for forgiveness that I contribute to the project at all?

[MasterNobody]

ultim
I think problem with review is not that you have too many functional changes but due your move/rename files commits. You can't really review/apply patches after it if you not going to apply this file structure refactoring patch (and as I understand IanB don't want to change file structure only because you don't like it). And so you can't cherry pick only ok commits. This way patches have "all or nothing" condition to apply which is not good.

[ultim]

There are multiple solutions to this problem, off the top my head (without any particular order of preference):

IanB could check out my repository in Git without merging any patches, to look at the directory structure I have arrived at. If he doesn't like the placement of some files, he can make suggestions to me how I should rebase the code, and ofc I'd be willing to help.
IanB could at least look at the directory structure I have arrived at. Maybe he'll come to the same conclusion that the new structure really is better than the old one, in which case he can merge the code. Selectively picking commits after the commits that move files (which come at the very beginning) is not a problem any more in this case.
IanB could reorder the files as I did, then selectively pick commits (which will be trivial since he moved the files too), and then move the files back to their original places. He'll need to fix up some #include lines, but this is basically not much work either. But this method allows him to cherry-pick my commits without accepting the new directory structure.


So the only thing left to 'solve' is the manual work needed to actually move the files for the first commit. This can be done fully automatically, even if he is using CVS, because all my work is based on Ian's latest commit. All he needs to do is copy his CVS repo into a new folder, delete the sources without deleting the history, and then check out my Git repo into the same folder. Bang, no need for patches, no need to merge, and no need to move files manually. At this point he can start committing to his CVS if he decides he likes my work. And if he does not like it (after inspecting it), he still has his own repository untouched.

The problem is, is that IanB does not even want to take a look if I have created a logical directory structure. He simply decided that he will not take a look at my changes just because I have moved files, even though they do not hide my changes, because I kept moves from changes separate.

Note that looking at the first commit of mine looks much scarier than it really is. A lot less files have been moved than it looks like, because a large part of the additions come from not moves, but from adding the HTML sources of the FilterSDK to the repository. 99% rest of the moves are whole directory moves, like the 'src' folder being renamed to 'core', or moving the pfc and soundtouch directories into plugin folders. I think you can probably count the number of files I have moved within the core itself on one hand. The rest are as described.

Please, tell me honestly: If you compare the structure of the CVS repository and my Git, isn't the new folder structure much better? Because if it is, then this whole discussion is meaningless. And if it is not better, I have still described two methods in the bulletpoints above, how Ian can fully or partially reject my folder structure while still picking other commits from me.

[Guest]

Here's another option. Make your patches to the existing directory structure.

[ultim]

Here's another option. Make your patches to the existing directory structure.

That falls within my first bulletpoint. And honestly, I'd even be willing to comply (even if not completely happy) if he said, that my directory structure was looked at seriously, but he found it inferior to the original because such and such. I don't think this is an unreasonable request from a contributor, to at least take a look at his work, and only reject it if there are founded objections. This goes for moving files too.

What I am disappointed at, is if Ian decided not to inspect my new structure just because, out of spite. Unfortunately, from his last post it looks like that this is pretty much the case, but I still have some hope left. I hope he'll post soon again to let us know his course of action.

[Guest]

Saying IanB rejects your stuff out of spite is way over the top and won't endear you to our members!

Maybe he doesn't even have GIT, or doesn't have the time to come up to speed on it. Personally, I would have to spend (waste?) many hours just to get to the point of being able to look at your changes.

And you are asking *him* to undo your directory structure changes?! There's some major chutzpah there, no?

[ultim]

Saying IanB rejects your stuff out of spite is way over the top and won't endear you to our members!

Maybe he doesn't even have GIT, or doesn't have the time to come up to speed on it. Personally, I would have to spend (waste?) many hours just to get to the point of being able to look at your changes.

And you are asking *him* to undo your directory structure changes?! There's some major chutzpah there, no?

Please don't stir up emotions. If you read my previous post carefully, you'll see that I have written, "... if Ian decided to...", which is hypothetical, and I ended my post by saying I hope this is not so, and that I hope for the better. I never said that he is doing it out of spite, I said I am hoping he is not.

I also wasn't asking him to undo my changes, it was one of the multiple possibilities, just like the one where he tells me what to change, and I'd do it myself (1st point). Grabbing isolated sentences out of my post and changing the overall meaning is not fair. Again, I'm trying to cooperate here, offering further work to fix what you ask me to, all I ask for is a fair review with arguments. There is no need to install Git or spend hours just to start taking a look as you mention it, because you can browse the source online on GitHub.

So no, no chutzpah.

[Guest]

You said this:

"if Ian decided not to inspect my new structure just because, out of spite. Unfortunately, from his last post it looks like that this is pretty much the case"

That is crystal clear to anyone with a brain.

[ultim]

I also said that "grabbing isolated sentences out of my post and changing the overall meaning is not fair", and you left off the end of the other sentence, which is again, changing the meaning. But since you look like you honestly misunderstood it, I'll say: Sorry. I'm, sorry. I didn't mean it that way, but because you obviously don't believe me, let me apologize.

[ultim]

Please let me try to express myself just once more, one last time, because there was some bad choice of words in the discussion with neuron2 that lead to misunderstandings.

I have made multiple commits over the course of a month, IMHO improving Avisynth's code in many different aspects. When submitting my changes, I ...

published my changes with full history on GitHub,
I based my work on the latest commits by upstream,
I have clearly separated commits,
I moved files in different commits than I made changes, so that changes are not obscured,
I am willing to further patch up my work based on suggestions after a review,
and the code I submit is commented.


Hence, I think that my commits are upstream-friendly, with the worst offender being the file moves. The friction between us is that you tend to view my changes as a bunch of patches, where I, unfortunately, messed up by reorganizing files before the patches. However, I'd like you to look at my file moves as part of the improvements too. I didn't reorganize the folder just because I was feeling like it. They are meant to be part of the improvements, and I feel the new folders make the project structure much more logical, because:

I have moved files and libraries which are part of the core into the core.
I have moved files and libraries which are NOT part of the core out of the core.
I have separated non-essential filters into plugin DLLs.
I have reduced the dependencies on 3rd-party code.
And, by all the above, I also have made it easier for new contributors to find the files they are looking for,
and easier to get a grip on the project.


So, me moving files around is meant to be part of the changes, not some extra stuff that I messed up by chance. And I sure have not "randomized" the locations like IanB put it.

This work took me a month, and as an example, my whole last weekend. In total more than a full day was spent merging, rebasing and cleaning up commits, because there were orignally about 1.5x-2x as many. So yes, I think I've been a good and diligent contributor. The only "bad" things left are the file moves, but I'd prefer not to get rid of them as they ARE part of the improvements, because of the numerous reasons that I have listed above. (And yes, please also note that I can argument why the folder structure is better this way.)

And when I publish my work, people tell me they don't even want to take a peek at any of my work just because they wouldn't have moved files in the first 2-3 commits (which are also improvements), even though it would take them only a fraction of the time that I needed to implement the whole thing. Whereas, if they did, they might even find that the moves make sense.

I hope I managed to bring you closer to my point of view.

[Keiyakusha]

I haven't read the whole stuff, only last post and I don't quite get it. You say "published my changes with full history on GitHub". Well ok, and what do you expect to see after that? If I would be on IanB's place I wouldn't even move my ass unless you'll send me patch for my own repo that I can review and apply. Maybe if avisynth was a super-active project with some devs that have tons of motivation... But that's not the case.
Whatever you fork it and maintain your own repo, or provide patches that can be easily applied. Dunno about IanB, but personally I don't even know how git works. I usually use SVN for my stuff which does everything that I need, so I don't want to learn git, nor clutter up my system with useless software. If things are the same for IanB (just with CVS in this case) I can understand this.

[IanB]

@Ultim,

Okay I made some time to look at your repository. From that I found 3 new very minor bugs. Very poor time invested per bug. I don't understand why you did not just reported them back in post #189 on 1st September 2013 instead of complaining about my going all red on you. Sorry you took the red text personally it was aimed at a much wider audience, it's a sad fact some simply cannot be bothered succinctly reporting the bug they find. Fortunately there are also many who do actually make the effort.

Yes I can see you have many ideas. Some I had already thought about for future versions, some new ones that I will take on board. Congratulations you are the first other person to recognise that we need _set_se_translator for MSVC versions later than 2K3.

It's a genuine pity that you could not resist the urge to move files around. You have a certain biased perspective (i.e it's Ultim's way only) that we did not share in so your restructuring just creates loss of reference without any personal benefit.

[ultim]

It's a genuine pity that you could not resist the urge to move files around. You have a certain biased perspective (i.e it's Ultim's way only) that we did not share in so your restructuring just creates loss of reference without any personal benefit.

*Sigh* You still don't give any reason why the files should not be moved, or why the places I moved them to are the wrong ones.

And please don't tell me that I only accept my way. I see it quite the contrary. I have written down literally half a dozen arguments why the structure matters and why the new structure is better, and even told you that I'll use any other structure as long as there is a reason for it. On the other hand, you just tell me "No, I won't move any files" without giving any justification. And of the two of us, I'm the biased?

But ok, I guess this is the most I will get. So I'll try to approach it from a different perspective. You told us yourself a couple of posts back that you've been itching to move file too, but you resist. Why do you resist? It is not like there are other code bases depending on your CVS, except for AvisynthMT.

So maybe after consulting with SEt, we could do it according to your dream-structure. Because it sure doesn't have to be my structure, I'd just like it to change, because the current structure sure is bad right now.

Maybe some background why I find it important to change: My goal is not just for me to improve Avisynth, but to allow it for more people from the community to join the development too. Currently it is very hard for anyone to do so, because of multiple reasons, like: unorganized files, the outdated development environment (VS6), unreadable code, missing commenting, the huge amount of exceptions thrown, and the choice of CVS is not the most contributor-friendly either.

This is why my current changeset focuses on improving developer friendliness, so that we lower the barrier for entry for new contributors. I understand, that unfortunately this means changes for existing developers too, mostly for you. But if we manage to attract more developers over time, this will pay off. The project structure plays a large role here. When a newbie comes, and sees source .cpp file of the core being in the distrib folder, some parts of non-essential plugins in the core, others parts in completely unrelated directories, "include" directories containing source files etc., he'll be confused, and with every right!

So, IanB, can we maybe reorganize the files according to how you've been wanting to have them?

[qyot27]

Some basic things related to the git history that I find I do want to comment on now as actual feedback, related to the file structure and general practices with git (and this also applies to generating out patches with 'git format-patch' for submission upstream).

I do feel the new structure is an improvement, but it's the presentation that I think needs to be done a bit better so it can be discussed and a more solid case can be made for why the individual choices made were made.

The renames, moves, adds, and deletes should be split into many smaller and separate commits, and the commit messages should fully (or as fully as possible) explain what is happening in each one, such as where files are getting moved/renamed to, or why binary files are deleted, etc.

Things that should have their own dedicated commits, based on what I've observed about the new structure:
Expanding the Examples out of their .zip archive
Deleting binary files from the git repository/history
The basic rename of the 'src' directory to 'avs_core' (and nothing else); this is probably 90% of the difference in the first place
Adding the docs to the history and noting where they are stored
Adding the CMake build system (if the CMake files for the newly-split plugins is purely for making these into separate plugins, leave those CMake files out for now; if they actually do have relevance for basic compilation as traditionally done, leave them in)
Removing the old build system's files, and explaining why they are being removed
Minor file renames - and make sure the renames are listed in the commit message itself.
Reorganizing of files to more appropriate locations (such as putting all source files related to converting things in the 'convert' directory); this should be separated into as many distinct commits as there are distinct subtopics for reorganizing (in other words, in the convert example I just gave, that is one commit; if there's another one related to some other destination directory, do it in a second commit, and so on)
Making Shibatch/ImageSeq/SoundTouch their own plugins (and each one should have its own commit) - IMO it's okay if any renaming and moving is consolidated into here in one patch, just so long as the moving/renaming is immediately pertinent to the goal of making the plugins distinct, and the rationale is - once again - explained in the commit message
Having these split into distinct commits makes it easier to take it piece by piece, explain the rationale for each change, and get approval or critiques from the upstream devs on what should be done. Explaining things in the commit messages and keeping them small in subject matter also doesn't give off the impression of a dramatic change and it's easier to see the immediate connection between where a file was and where it was moved to.

Another point more immediately related to git itself, is that the formatting of the commit messages should have a single concise summary as its headline, and then a longer explanation further down after a double-space. The lines in the commit message should be wrapped at 80 characters (the headline should be <= 80 characters in length). This is to make it easier for users pulling up the history with git log to view it without it overflowing their Terminal's width buffer (since most default to 80 characters), or for any need to use git rebase -i - if the lines exceed the width buffer, then it has the potential to interfere with git rebase -i in a really bad way.

Also, somewhat of a minor point, but let's say you want to focus on the development of a single issue, like multithreading. The work on this should be in its own branch, separate from master. This keeps the master branch clean so that integration of newer changes from upstream and rebasing the branches against master is easier and keeps the general noise down (IMO, development branches should always be considered volatile and subject to rebasing, even if the git repository is public; but never, ever, ever rebase master).

So another list of general git management points I think would make this easier:
Checkout a new branch for the changes you've made. All 54 of them that are currently on the github repo should be in a separate branch, and then reset --hard master's HEAD back to where upstream leaves off
Use git rebase -i on the new branch to edit the commit messages to comply with the 80 char limit and separate headline/explanation format, without changing the contents of any of the actual commits.
Use git rebase -i again, but this time to split the file structure changes into many smaller, more topical commits.



Also, I think there should be a new thread to discuss the changes ultim is proposing, so that the alpha4 thread doesn't get dragged any more off-topic (especially now that alpha5's been released).

[ultim]

Currently, the reason everything is on the main branch in my repo, is because it is my repo. Meaning it is set up so that if anyone clones my master, he'll get the latest stable version of my changes. That makes the most sense to me. Why would anyone clone my repo if they want the official branch of Avisynth? So my stable work is in the master of my repo, while I'd be using branches for non-stable or work-in-progress of other features I'm working on, and for upstream. This is not a problem for IanB, because he can pull changesets/patches from any of the branches, his master does not need to be the same as my master branch. If I were in the official repo though, I'd obviously be working in a seperate/private branch, though I doubt IanB will let me do that.

Concerning your other idea of splitting up the large file-moving commit, I'm okay with that. As long as I know beforehand that IanB is not gonna reject it again, I'd redo my changeset and split it up further as you proposed. So if he lets me know that he's willing and ready to integrate/merge the file moves that way, count me in. Of course we can discuss where files should go before I start redoing everything, so that I won't have to do it a 3rd time.

[qyot27]

Currently, the reason everything is on the main branch in my repo, is because it is my repo. Meaning it is set up so that if anyone clones my master, he'll get the latest stable version of my changes. That makes the most sense to me. Why would anyone clone my repo if they want the official branch of Avisynth? So my stable work is in the master of my repo, while I'd be using branches for non-stable or work-in-progress of other features I'm working on, and for upstream. This is not a problem for IanB, because he can pull changesets/patches from any of the branches, his master does not need to be the same as my master branch. If I were in the official repo though, I'd obviously be working in a seperate/private branch, though I doubt IanB will let me do that.
That suggestion was mostly to make sure that there's no potential conflicts if you try to pull in changes from upstream - having all of it in master means that there's the potential for changes to be sandwiched between runs of cvsimport, or for conflicts in the tree to arise that might be more unexpected (for that matter, the stuff from cvsimport could go in a different branch like 'trunk' or something, with master the way it currently is; the same basic idea applies - letting whatever happens upstream have its own branch). Github does allow the ability to set alternate branches as main so that a user doing a clone gets the branch you want them to get (I had it set up that way for my FFMS2* repo for a long time, where the 'patches' branch was the one you'd get from a normal clone).

*which is now the ffms2-old repo; I re-forked my main one against the official repo after the move to Github

[ultim]

Very unfortunately, me and IanB seem to have reached an impasse. I have received constructive PMs though from forum readers, some relating to how I present my patches, some regarding communications, but all encouraging. I'll be continuing my slow-ish efforts at improving Avisynth, and because upstream acceptance does not seem realistic ATM, I'll be forking the project (well, technically speaking, I already have). I wanted to avoid this, because forking has many downsides. Downsides like even more fragmentation, a lessened likelyhood of both projects benefitting from each other's improvements, and a bitter aftertaste in the mouth on both sides, I guess. The more optimistic amongst you can however spot advantages too, like not having to be constrained by the ideals and rules of the father project. I'll post more information about goals and such in my own thread.

Anyway, I just wanted to give you an update, to prevent you from thinking that I'm gone. This will be my last post "contaminating" this thread, and I'll create a thread of my own the next time, which will be when I post my next release. I have already synched with 2.6 alpha5 (synching was not a big deal), and have a large chunk a new code in place which completely (like, from scratch) replaces the plugin handling and loading. Also, Groucho2004 was right after all when he found something was off with out-of-memory handling in my build, so we'll see what I can do about that. It has to do with me using set_seh_translator and /EHa, which IS the correct thing to do on all VS2003 and above, but AFAICT it causes unhandled std::bad_alloc exceptions not to be swallowed silently anymore... which the project seemingly has relied upon? I've still got to take an exact look at that, but I know I'm on the right track. Anyway, back to my plugin-handling code, it makes script loading percievably faster if you have a lot of plugins, and it is also much cleaner from a developer's perspective. Oh, and expect support for multiple plugin directories too.

To finish forking, I guess the only thing left to do is to find a name for the fork. Feel free to send me any suggestions, I am torn between using something "Avisynth"-like or not. First of all, it'd be natural to do it, because my fork is Avisynth in its core. Admittedly, I am still relying on a large existing code base, so it'd be misleading to try to present the fork as something completely different. On the other hand, it would also be aggressive and disrespectful from me to have a name like Avisynth 3-4-5-6..., Avisynth-X, -NG, or who knows what suffix. So let me know what you think or if you have any ideas. I'm very interested in Ian's oppinion too, so I'd be thankful if he shared his preferences on naming with us. Of course I'm not asking him to come up with specific names for me, I'd just like to know what kinds of names are okay for me to use from an official perspective.

Cheers

[Groucho2004]

Also, Groucho2004 was right after all when he found something was off with out-of-memory handling in my build, so we'll see what I can do about that. It has to do with me using set_seh_translator and /EHa, which IS the correct thing to do on all VS2003 and above, but AFAICT it causes unhandled std::bad_alloc exceptions not to be swallowed silently anymore... which the project seemingly has relied upon?
Interestingly, SEt's MT DLL (built with VC2010) exhibits the same exception handling behaviour as the official one that is built with VC6.
No idea what he did, but I think he mentioned something about "hacking" the compiler.

[ultim]

Interestingly, SEt's MT DLL (built with VC2010) exhibits the same exception handling behaviour as the official one that is built with VC6.
No idea what he did, but I think he mentioned something about "hacking" the compiler.
That's because he is using different compiler settings. If I switch to /EHsc (which is the theoretical equivalent of VC6's /GX), I get similar exception behavior as in the official build. Of course then set_seh_translator falls apart. The official project solved set_seh_translator's absence using custom ASM-hacks, and I guess those are the hacks that SEt referred to. I got rid of those hacks in my build, as I prefer to use methods that are officially supported by the compiler. But now I need to fix up parts of the code to properly support this scenario.

On the other hand, it would also make sense to completely remove handling SEH-exceptions, because there are very few valid reasons to handle them, and even less that are worthy of showing to the user, as they indicate coding errors in Avisynth or in the plugins. I might really remove them in a later build of mine, but not now, to take it step-by-step.

[Groucho2004]

That's because he is using different compiler settings. If I switch to /EHsc (which is the theoretical equivalent of VC6's /GX), I get similar exception behavior as in the official build.
Not true for Windows XP. I tried that with VC7.1, VC9 and VC10, I always get this silly runtime message box instead of the actual message from "ThrowError()". I think it has something to do with msvcrt.dll on XP, not sure.

It would be nice if Avisynth could be built with newer compilers since there certainly have been improvements since VC6 but on the other hand, I have not come across any problems for which VC6 could be blamed exclusively.

[SEt]

Let me add some thought to the discussion.

Avisynth in current 2.6 form is effectively dead. I.e. it will work ok, but isn't endangered by any major improvements. There are several reasons for that:

1) The unsolvable one that makes it really dead and not just in bad shape or unmaintained: license. GPLv2 was bad choice – it should've been LGPL. I don't see any realistic way to change it to LGPL, so for that change all existing code needs to be thrown out and rewritten.
2) Bad interfaces. No one sane uses С++ for open plugin system. C interface with trivial wrappers to C++ or whatever else is what should've been done. In 2.6 we break old interfaces but get the same C++ hell.
3) No care for threading. Can you guess how many people need what was added in recent years (!) to official 2.6 and how many need working threading?
4) No care for submitted patches. Besides MT my build differs by several important source clarifications (specified calling conventions where they are needed, improved exception handling). How many years have they been open? Were they merged? (Note: most time I spend on updating my build to official is manually re-merging these small but extensive changes since CVS is often unable to automerge them.)
5) Absolutely refusing to remove old hacks, clean code and move to newer software. Who uses CVS today? With words VC6 most modern developers jump in panic or start to cry. How about this nice quote from sources:
// Warning! : If you modify this routine, check the generated assembler to make sure
// the stupid compiler is saving the ebx register in the entry prologue.
// And don't just add an extra push/pop ebx pair around the code, try to
// convince the compiler to do the right thing, it's not hard, usually a
// slight shuffle or a well placed "__asm mov ebx,ebx" does the trick.
And that is not a single case. The actual problem here is that, for example, SVN and VS2010 aren't any worse in general, much less buggy (no need for those register saving hacks) and actually used by people today. But do we need new developers? Not as much as we need CVS and VC6 obviously.


But saying that all I have to add that while Avisynth has plenty of problems there isn't anything better. And it works quite ok too.
I thought many times of rewriting it but still don't have enough resolve (due to 1 it's quite a daunting task) and it does what I need from it reasonably well (I would be pressed to write better threading if i had like 16-thread CPU, but no hardware upgrade here in 3 years and future doesn't look bright at all – looks like all focus of manufactures is shifted towards mobile).

[Mystery Keeper]

You're wrong about hardware, SEt. I'm currently aiming to get myself new PC with double 12-core Xeon. Which makes it 48 threads. As for "nothing better" - VapourSynth looks promising. You could join the development. Manao, Fizick and Tritical certainly should, so we could have motion compensation and high quality deinterlacing and denoising in VS.

[ultim]

Nice to see you SEt! Some of the problems you have listed are exactly why I started my fork. Obviously, I can't correct all of them, like the GPL issue. But we can help the rest! I agree that there isn't anything better yet than Avisynth, and while VapourSynth looks promising, Avisynth is still better in many aspects ATM, which is why I'm putting my energy into Avisynth.

CVS, VC6, the hacks, the C++ interfaces and all those /are/ bad, but these can be helped. I'm removing hacks like the one you listed one by one (many of them are already gone in my sources), and AFAICT porting to new software is finished - with the exception of a last bug that Groucho reported, but I've found the reason for that too. My hope is that by porting to newer software, getting rid of the old and deprecated cruft, and by being more open to submitted patches, we'll be able to breath some new life into Avisynth and invite new development. Additionally I'll be making small improvements here and there too. I hope to push my next set of changes to GitHub soon.

Groucho2004:
After some more investigation, I believe I have found the real reason for the changed exception behavior: http://stackoverflow.com/questions/550451/will-new-return-null-in-any-case .

[qyot27]

RE: naming, since all the other forks are in the same boat and just tack on a suffix (MT or 64 for example, although those are really just descriptive titles), I'd think it safe to just go ahead and do the same thing. As previously noted, I like 'AviSynth+', since it is a more general-purpose fork.

Also, the developer(s?) that worked on the dead 3.0 branch seem to be different than 2.x, and 3.0 changed things around too, yet it still kept the AviSynth name, so I wouldn't think that to be too aggressive either (especially if you pair it with a new fork name). I wasn't around for the early history, but if it seems to be a tendency for each of the major versions to have different groups of contributors working on them then there is a historical precedent involved.

How about collecting whatever suggestions there are for names and then putting it to a forum poll?

[vcmohan]

Request all who fork from the official version to please start separate threads and do not use the main thread. I request the moderators to remove already posted fork related matter to different threads

[turbojet]

I agree this talk should be moved into another thread once ultim comes up with a name and makes a thread but now that alpha 5 is out this thread would become inactive anyways.

To continue OT, I look forward to a fork with proper 64 bit handling and improved threading (if possible). Many FOSS go through forks and it gives ultim control to do what they want to do as opposed to being approved by IanB, which is a current issue. As far as name goes, isn't 'avi' a bit old now, would 'AVSynth' work?

[Groucho2004]

After some more investigation, I believe I have found the real reason for the changed exception behavior
Yes, simply linking with "nothrownew.obj" (which ships with VC10) keeps "new" from throwing "bad_alloc".

[Wilbert]

I moved all the relevant posts to this new thread. Let me know if i need to change the title.

[Mystery Keeper]

Not true for Windows XP. I tried that with VC7.1, VC9 and VC10, I always get this silly runtime message box instead of the actual message from "ThrowError()". I think it has something to do with msvcrt.dll on XP, not sure.

It would be nice if Avisynth could be built with newer compilers since there certainly have been improvements since VC6 but on the other hand, I have not come across any problems for which VC6 could be blamed exclusively.

The worst crime of VC6 is not following the standard. For example, a variable you declared as "for" loop counter continues to live outside the loop and you can't declare it again. That's only an example. I don't know how bad is its deviation. But I couldn't build AviSynth plugin with GCC. Meaning AviSynth headers code doesn't follow the standard either.

[qyot27]

But I couldn't build AviSynth plugin with GCC. Meaning AviSynth headers code doesn't follow the standard either.
Clarification: plugins using the [default] C++ interface can't be compiled with GCC. Part of the raison d'être for the C interface is to enable GCC to build plugins - the C interface itself also forms the backbone of the AviSynth input support in x264 (since late 2009) and FFmpeg (since March of this year).

But there's only a few plugins currently that actually make use of the C interface (off the top of my head, FFMS2's C plugin variant, AssRender, and yadif), and it's still subject to the huge caveat that C plugins aren't included in the autoloading feature.

As far as name goes, isn't 'avi' a bit old now, would 'AVSynth' work?
'AVSynth' seems like an FFmpeg function name conflict waiting to happen; if the desire is for a more general name, 'MediaSynth' would be more unique and less likely to conflict name-wise (but personally I'd view that as a last resort since the scripting language is still basically going to be AviSynth's, which is another reason why I think suffixing would be fine; other languages usually take a descendant diverging from them dramatically to invoke a name change, and often they use suffixing rather than completely changing the name, look at all the different C family members, all of which probably diverge from C more than ultim's changes will end up diverging from current AviSynth's scripting language).

IMO, 'avi' being old has little bearing on the name. When using NLE software, lossless codecs are still usually best transported in AVI (if you aren't using something Apple-specific or device-specific, anyway) due to the least common denominator familiarity with that container and the simple one frame in, one frame out I/O mechanism of Video for Windows, and the basic I/O features of an AviSynth script still match the way AVIs are used with lossless codecs (even with projects moving away from accessing AviSynth through Video for Windows and just accessing the library directly).