Avisynth+

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

Originally Posted by ultim

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]

Originally Posted by Groucho2004

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]

Originally Posted by Mystery Keeper

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.

Originally Posted by turbojet

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

[turbojet]

All I could find for avsynth is https://github.com/LRN/gst-avsynth which seems abandoned, does ffmpeg have something in the pipe named AVsynth?

I agree avi is still useful but modern lossy encoders have given it a bad name and often seen as a last resort or unsupported.

[ultim]

Originally Posted by qyot27

... and it's still subject to the huge caveat that C plugins aren't included in the autoloading feature.

Since when? Oh sorry, I've forgot you're not using ultim's build
I wanted to get a release out yesterday in the evening (CET), but I've realized last minute that the new shadow plugin folder feature's API could be improved, so I've delayed. I hope I'll be able to release tonight, but no guarantees, since I'll be getting home later today.

And yes, the above means C plugins are autoloaded with my rewritten plugin management, I worked on that since I was also missing that feature, and find it very useful and even necessary to encourage using it.

Originally Posted by Groucho2004

Yes, simply linking with "nothrownew.obj" (which ships with VC10) keeps "new" from throwing "bad_alloc".

That works too, but I prefer a standards compliant implementation so I've chosen another way. I went ahead and inspected where "new" is used to find places where we depended upon it returning NULL, and changed those occurrences to the non-throwing (std::nothrow) version. This way we are not only compliant to the c++ standards, but we also don't require to link with special MS-specific object files.

p.s. I still haven't decided on a name so keep 'em coming

[qyot27]

Originally Posted by turbojet

All I could find for avsynth is https://github.com/LRN/gst-avsynth which seems abandoned, does ffmpeg have something in the pipe named AVsynth?

That's not what I was saying. Naming conventions for lots of API and function stuff in the libav* libraries start with AV_ - so steering clear of stuff approaching that would be advisable.

Originally Posted by ultim

Since when? Oh sorry, I've forgot you're not using ultim's build
I wanted to get a release out yesterday in the evening (CET), but I've realized last minute that the new shadow plugin folder feature's API could be improved, so I've delayed. I hope I'll be able to release tonight, but no guarantees, since I'll be getting home later today.

And yes, the above means C plugins are autoloaded with my rewritten plugin management, I worked on that since I was also missing that feature, and find it very useful and even necessary to encourage using it.

I was hoping as much when plugin management got mentioned before. Huzzah.

I've been refining the build instructions some, now that I've also got the DirectShowSource-related stuff documented step-by-step.

[raffriff42]

Just brainstorming here...
MediaSynth
Avisinthe
ASST (AviSynthyServerThingy)
AINRA (AINRA Is Not Really Avisynth)
AVI Normal (does this need explaining? Young Frankenstein?)

[kypec]

ModAviSynth is my proposal which should define this fork as modern and modified project at the same time. Thumbs up, ultim and for all your hard work on improving AviSynth.
VapourSynth looks promising but not yet quite there.

[ultim]

Thank you everybody for the suggestions. Right now I'm leaning towards qyot27's "AviSynth+". I find it good because it expresses exactly what the project is, and what its intention is. It makes it easy to distinguish between the two projects, while it still notes that it is rooted in Avisynth, and has a clear message that it is supposed to be an enhanced version of the original project.

[mastrboy]

Wouldn't a single "+" make it a little hard to search for? Considering it's interpreted as an operator by most search engines?

[qyot27]

The + could simply be the stylized name that appears in say, the output of Version(). Having it written out as 'Plus' in other places like the Github repo URL would be fine.

[Reel.Deel]

+1 for "AviSynth+", I've tried to think of other names but that's a tough one to beat.

[raffriff42]

Buy the domain name now, or it might get squatted upon.