Avisynth+ [Archive] - Page 36

Reel.Deel

20th June 2016, 13:48

Hey there ultim. Nice too see you around :).

I've recently started to work on the documentation (http://forum.doom9.org/showthread.php?p=1769249#post1769249), so far almost all of it comes from cherry picked posts from this thread. There are a few things here and there that may need a bit of elaborating/clarification, unfortunately I do not know too much about these things to do so. Maybe once I'm done you can give it a quick review. Right now it's just a sloppy word file, some of it is what's already on the AviSynth+ wiki.

It made it a lot easier for me to proof the changes between old (HTML) and new (Sphinx) versions by using the Tile View extension in Firefox, so I could see both side-by-side instead of needing to switch between tabs, with Notepad2 (or Leafpad, since I was under Linux while doing this) off to the side to edit the actual RST files.

It's really as simple as 'make html' in the distrib/docs/english directory, so long as you've installed Python and Sphinx. Sphinx will tell you if there are syntax errors in the files, and if the built HTML version is open in your browser, you can see the errors and work them down until it complies. And it'll also only rebuild the files that have been touched, rather than needing to rebuild the entire doc tree.

I installed Python 2.7.11 and the latest Sphinx, I also updated to the latest pip(8.1.2). Whenever I click 'make.bat', a command prompt window quickly opens and closes. Am I missing something here?

pinterf

20th June 2016, 17:03

I came to visit the forums, and after catching up with this thread, boy I cannot express how glad I am that pinterf picked up where I left....
Hi! I'm glad you are back, and yes, I have so many questions, contrary to the fact that (unfortunately) I'm the kind of a man that first tries to make sure of things alone, in order not to ask obviously stupid questions. Not the fastest way of getting the knowledge, though. I'm still on the learning curve on both avisynth internals, sometimes even syntax elements that I never use.
I am still a humble maintainer of the avisynth plus code. I wish I were a young student again with plenty of free time :)

MysteryX

20th June 2016, 18:01

Humble, courageous and patient.

Reel.Deel

20th June 2016, 19:03

In classic AviSynth I can load plugins like this:
LoadPlugin("AddGrainC", "MedianBlur2.dll")

ColorBars(pixel_type="YV12")
AddGrainC(100)
MedianBlur()

However, in AviSynth+ the second plugins does not load:
Script error: There is no function named 'MedianBlur'.

Is this the expected behavior or is it a bug?

qyot27

20th June 2016, 19:12

I installed Python 2.7.11 and the latest Sphinx, I also updated to the latest pip(8.1.2). Whenever I click 'make.bat', a command prompt window quickly opens and closes. Am I missing something here?
Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

LigH

20th June 2016, 19:15

In classic AviSynth I can load plugins like this:
LoadPlugin("AddGrainC", "MedianBlur2.dll")
...
...

Probably:

LoadPlugin("AddGrainC.dll", "MedianBlur2.dll")
...

Still, I don't remember anyone using this syntax, even if it is allowed. So I could imagine that AviSynth+ did not implement it as variable parameters...

Reel.Deel

20th June 2016, 19:38

Probably:

LoadPlugin("AddGrainC.dll", "MedianBlur2.dll")
...

Still, I don't remember anyone using this syntax, even if it is allowed. So I could imagine that AviSynth+ did not implement it as variable parameters...

Oops, even if I add .dll to AddGrainC the second plugin still fails to load. Kinda odd that it loads without .dll at the end.

Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

Thanks, I'll try it when I get back at home.

Chikuzen

20th June 2016, 20:32

However, in AviSynth+ the second plugins does not load:

Is this the expected behavior or is it a bug?

It's a bug.

patch

diff --git a/avs_core/core/PluginManager.cpp b/avs_core/core/PluginManager.cpp
index 517f713..5141866 100644
--- a/avs_core/core/PluginManager.cpp
+++ b/avs_core/core/PluginManager.cpp
@@ -867,7 +867,7 @@ AVSValue LoadPlugin(AVSValue args, void* user_data, IScriptEnvironment* env)
IScriptEnvironment2 *env2 = static_cast<IScriptEnvironment2*>(env);

bool success = true;
- for (int i = 0; i < args.ArraySize(); ++i)
+ for (int i = 0; i < args[0].ArraySize(); ++i)
{
AVSValue dummy;
success &= env2->LoadPlugin(args[0][i].AsString(), true, &dummy);

Reel.Deel

21st June 2016, 04:10

Install Sphinx from pip:
pip install sphinx

Navigate with the Command Prompt/Terminal to the right directory and run the Makefile:
cd distrib/docs/english
make html

I always have trouble with the command line, got it working though. Now I can start messing around with the documentation. :)

Shift and right click (I learned something new):

http://i.imgur.com/fnR4hup.gif

It's a bug.

patch

Thanks Chikuzen.

pinterf

21st June 2016, 10:52

It's a bug.
patch
Thank you, applied.

ryrynz

21st June 2016, 11:01

I'm getting instability using the 2012 64 bit build and it's (Awarpsharp) the only filter keeping me from a full 64 bit work flow, cheers.

Actually found out that it's Hysteria (Uses masktools) that hates working in MT mode 2 on 64 bit. Works fine in 32 bit using that mode, switched to mode 3 and no more crashes (am using tp7's most recent version)

Would still love to see a up to date 64 bit build of Awarpsharp though :)

FWIW It's really nice to be able to run 64 bit Avisynth using MT now.. was such a long wait.

ultim

21st June 2016, 13:58

ultim

21st June 2016, 14:22

Just by following the questions from my previous post further, we can get into really deep woods. Like for example, without trying to imply anything: What are our expectations of our community? Where do we want Avisynth to go long-term? Do we want it to go anywhere long-term? If we'd like to change Avs to a great extent, should people invest in a re-write of Avs or just adopt VapourSynth? Do both projects have unique selling points? What about existing plugins? What about future plugins?

It's not like these questions are being asked now for the first time, but IMHO it surely wouldn't hurt to finally discuss these, since we're talking about possibly diverging from Avs2.6, which basically means making Avs+ a community of its own. And even if that split doesn't happen, which is also fine, it would help to lay the future, survey opinions, and plan resources.

MysteryX

21st June 2016, 15:56

I wasn't even aware v2.6 had a x64 version, and I haven't heard of anyone using it. I'd say v2.6 is at least 95% used in x86 mode, and AviSynth+ should be compatible with v2.6 x86 and further provide x64 support.

If someone really wants to use v2.6 x64, then correcting that version to make it compatible again is an option but I don't think many care.

The main advantage of AviSynth is its compatibility with a large library of plugins. If we were to rewrite all plugins, better as well rewrite them in VapourSynth.

I think VapourSynth has great potential but it still lacks major features:
- audio support
- ffdshow support
- extensive library of plugins

There's also the issue of AviSynth+'s extended interface. I think we can write plugins that make 'optional' use of AviSynth+'s extra features while also working without, by first checking whether the functions exist. That way, we can maintain compatibility without being limited to the old interface.

ultim

21st June 2016, 17:08

Avs2.6 does not yet have a x64 version. But the changes in question make me think IanB is working on 64-bit support and might be adding that in the future, because the changes only make a difference for 64-bits. So if he is not planning on 64-bit support, why did he change it in the first place? And if Avs2.6 really introduces it, then the same plugins wouldn't work correctly on both Avs2.6 and Avs+.

About the extensibility: Avs+ is built exactly like that. It maintains compatibility with all plugins, but each has the possibility to selectively make use of Avs+ features if it decides so at runtime. The interface is still limiting though and is hindering a lot of modernization efforts. Even up to now there have been multiple occasions where we needed to find a workaround at the expense of increased code complexity, just because the old interfaces aren't accommodating enough, and we also didn't want to break them. This results in various levels of ugliness, like an increased amount of compatibility layers, a sub-optimal compromise of features, or illogically/badly placed functions or hidden functionality out of necessity.

Reel.Deel

21st June 2016, 17:12

I started making some changes to the documentation and need some opinions. Here's the difference between the two: http://diff.pics/JbQx0fvGOTeM/1

I added a syntax and parameters section and I also highlighted the syntax and listed all the parameters and their descriptions. I would like to do this to all the internal filters. Yea or nay?

TheFluff

21st June 2016, 18:12

Last night I was going through all the outstanding commits and pull requests. Basically two big groups, one for catching up to Avs 2.6, the other from pinterf (which has most if not all other PRs against Avs+ already integrated). pinterf's changes are mostly alright, I still need to inspect in detail the changes regarding the FrameRegistry, but I'm gonna pull it anyway simply because it works. There were maybe 2 other small commits that I'd like to offer feedback on, but nothing major. We can discuss if necessary after pulling.

I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).

But summing it up, meh... I don't like any of these options. Not to mention I see this as a very important and key decision. I don't mean to over-dramatize, but given the already fragile state of Avs, one wrong step here could mean the end of Avisynth as a whole. Maybe we could just ask IanB to roll back the corresponding changes? Arrrrgh... I have no idea what we should do.
This is a problem of your own making. You introduced a sorta working 64-bit Avisynth version without making the plugin API properly 64-bit. There were a few x64 plugins before Avs+ but nothing really useful and nobody used 64-bit Avisynth anyway because it was really broken. IanB did the right thing when he fixed those pointer sizes and you should have done it too - it would've been less painful to you early on.

What you should have done back then (and you can still do it) was to create a new plugin API and emulate the old one (like Vapoursynth does). I believe this was pointed out to you at length, back then.

I also think you overestimate the effort required to recompile "all" plugins. I would estimate the number of commonly used and actually conceivably useful (with a very wide definition of "useful") Avisynth plugins today, in 2016, to be less than two dozen.

- ffdshow support
Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.

qyot27

21st June 2016, 18:15

I am much more concerned about some changes relating to Avs 2.6. One is that back in 2015 IanB changed the x64 binary interface in an incompatible way, ignorant of the fact that there is already a significant x64 plugin ecosystem, and he just broke it. This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call. On one hand I'd very much prefer to stay in sync and compatible to Avs 2.6 in all aspects. On the other hand I'd prefer not to have to follow Avs2.6 and its inexplicable decisions any further, but this comes at the great price of splitting the community. The community needs to be united if anything, not further segmented. And actually there is a 3rd alternative, 3) if we'd need to break many plugins anyway just by following Avs 2.6, we could break with the old interface completely. On one hand this brings the disadvantages from both worlds (breaking plugins AND splitting the community), but would allow us break free of the very limiting old interfaces, to sanitize and upgrade them in a future-proof way. Of course this presumes the support of plugin writers for Avs+ even more than if we took option 2).
At one point I remember someone bringing up the idea of eliminating the C++ compiler difference in the event of MinGW builds by having a compatibility shim that wraps C++ plugins and loads them through the C interface.

Would something like that be able to also eliminate the compatibility problems with 2.6's switch to size_t to support 64-bit? Alternately, have a separate loader for size_t-based 64-bit plugins that the user can do specific overrides for if necessary (e.g., LoadPlugin("Plugin.dll", alt_loader=true), or Load_New64_Plugin("Plugin.dll")). If that'd even work, that is.

On a purely philosophical level, I'd say break with the old interface completely and start fresh. On a practical level, I know that's ill-advised. I'd prefer that we have some kind of fallback so that plugin devs can migrate to the new interface organically without shocking users. But design the new interface so it doesn't collide at all with the old and is completely self-contained. This way plugins can simply add another interface for AviSynth+ alongside their interfaces for classic AviSynth (which avsplus could still load in this scenario) and VapourSynth without any real hiccups.

MysteryX

21st June 2016, 18:19

Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.
I use SVP and it remains the only way to use it. Although they recently added a VapourSynth version but only with mpv player. So far AviSynth+ can't be replaced for that here.

Groucho2004

21st June 2016, 18:27

I use SVP and it remains the only way to use it.
The point is that a broken 64 bit ffdshow has nothing to do with Avisynth(+). Why don't the SVP guys fix it themselves?

ultim

21st June 2016, 18:48

This is a problem of your own making. You introduced a sorta working 64-bit Avisynth version without making the plugin API properly 64-bit. There were a few x64 plugins before Avs+ but nothing really useful and nobody used 64-bit Avisynth anyway because it was really broken. IanB did the right thing when he fixed those pointer sizes and you should have done it too - it would've been less painful to you early on.

I don't agree. Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, dozens because I collected links to all of what I could find.

Second, those changes, while "correct" on a theoretical level, bring absolutely zero advantage to any realistic use case or application. At least not unless you have video frames which are each 4GB-sized. Even in the era of UHD this is irrealistic, and so the whole change is unnecessary. Yes I'd have taken size_t for data type too if developing a new interface from scratch, but once you consider you have a far-from-zero existing ecosystem to support and not to break, I wouldn't change to it unless it brings some important (and, importantly quantifiable) technical benefits - which it does not.

Changing something which only causes breakages and brings zero advantages whatsoever, is, I'd argue, inexplicable and questionable, so honestly, I don't see why I should be held responsible for future problems to arise. I can justify my decision like above, unlike the other side which is "I ruin a bunch of things for no gain, but at least this is how I should have done it at the beginning, provided there had been any real benefits."

And besides, our result was not a "sorta working 64-bit Avisynth version without making the plugin API properly 64-bit", but a fully functional one, supporting 64-bits perfectly in the core as well as in the plugin interface. The only 64-bit-related problems we have are not due to errors in the interface, but due to non-64-bit-ready external plugins, for example due to hand-written asm.

TheFluff

21st June 2016, 19:32

I don't agree. Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, literally dozens because I collected links to all of what I could find.
You did it wrong. You just counted links without any concern for actual usefulness or popularity. Last time I called you out on this (http://forum.doom9.org/showthread.php?p=1712704#post1712704) you mainly cited JoshyD's and squid80's ports of an eclectic bunch of about two dozen plugins, most made in the first half of 2010 and never updated after that, and without any attempts at modernization whatsoever. I think they just ripped out a bunch of things that didn't work in many cases and some of the ports were pretty buggy. There were like three people who used this x64 version of 2.5.8 and it died a peaceful death within a year or two. I don't think many people ever were aware these plugin versions even existed (burying mediafire links deep in some thread on d9 isn't a great marketing strategy).

Other than that you also cited tp7's modernized plugins, which should have been trivial to recompile for a new API. Even JoshyD's and squid80's plugins should have been fairly trivial to just recompile against a new header.

This wasn't an "ecosystem", it was an abandoned garbage dump.

Second, those changes, while "correct" on a theoretical level, bring absolutely zero advantage to any realistic use case or application.
From a strict API standpoint perhaps, but you gotta consider that it locks both you and your users into a particular allocation strategy.

And besides, our result was not a "sorta working 64-bit Avisynth", but a fully functional one.
Remind me again, for how many months did the latest release version have a critical slowdown issue?

Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar. If all these people who have attempted to hack on Avisynth in the last ten years would have spent half as much effort on a well designed and thought out rewrite instead of hacking on the increasingly broken 90's garbage we would have been in an infinitely better situation today.

Reel.Deel

21st June 2016, 19:38

I also think you overestimate the effort required to recompile "all" plugins. I would estimate the number of commonly used and actually conceivably useful (with a very wide definition of "useful") Avisynth plugins today, in 2016, to be less than two dozen.

That's your opinion, what you consider useless might not be to another person.

Yes this problem is more pronounced than a year ago because now there are even more 64bit plugins. But even back then there have been more than enough, dozens because I collected links to all of what I could find.

Indeed, the amount of 64-bit plugins has definitely grown. There's over a 100 plugins now: http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins

And besides, our result was not a "sorta working 64-bit Avisynth version without making the plugin API properly 64-bit", but a fully functional one, supporting 64-bits perfectly in the core as well as in the plugin interface.

Yes, 64-bit AviSynth+ r1576 is rock solid.

ultim

21st June 2016, 20:18

From a strict API standpoint perhaps, but you gotta consider that it locks both you and your users into a particular allocation strategy.

All it locks down is that Avs can only allocate frame planes in a single allocation call. That is hardly the part of frame allocation strategy that matters for speed or features.

Remind me again, for how many months did the latest release version have a critical slowdown issue?

Remind me what that had to do with either the stable release or with the 64-bit port. The slowdown that pinterf has recently solved was in a testing release of the MT-branch. The stable one, with already existing 64-bit functionality, didn't suffer from it AFAIK. The problem you are pointing out has nothing to do with the quality of our 64-bit port, and there is a reason why the buggy build was not issued as stable.

Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar. If all these people who have attempted to hack on Avisynth in the last ten years would have spent half as much effort on a well designed and thought out rewrite instead of hacking on the increasingly broken 90's garbage we would have been in an infinitely better situation today.
Amen, unfortunately. This I can agree with. As for me, I didn't dare to gut out Avisynth and refactor it in an even more extreme way, because I see its existing support for its greatest plus. And frankly I do not see a way of completely rewriting everything AND keeping compatibility with existing plugins. VapourSynth tried something similar, but AFAIK not even he succeeded completely, though the results are more than commendable. At this point, if somebody went ahead and threw out all the existing code base AND existing plugin support, it might be worth considering to rather implement an Avisynth-language frontend for VapourSynth instead - I'm not sure though but I think Myrsloik at some time stated that it wouldn't be possible for some reason. Which kind of leads to the questions I noted down a few posts earlier.

ryrynz

21st June 2016, 22:00

This leaves Avs+ the following options: 1) Pull IanB's corresponding changes and recompile all x64 plugins. Or, 2) diverge from Avs2.6 when it comes to x64 plugins. IMHO it is a tough call.

Avisynth is going nowhere. He's what, the only person working on it? His code changes don't appear to be significant, I could be wrong but to me it seems pinterf has done more work on this branch than IanB has done on Avisynth recently, will Avisynth 2.7 ever come?

One can basically conclude that after 2.6, Avisynth is going nowhere fast. I guess it's a prime opportunity for Avisynth+ to take over, this was basically the intention wasn't it?

I think VapourSynth has great potential but it still lacks major features:
- ffdshow support

Stop repeating this as if it means anything. ffdshow has been dead software for half a decade or more. People need to drop support for it, not add support.
Would've been more accurate to say piping to Directshow, I agree ffdshow should go, but while it would seem an easy task based upon what you said below.. nobody has yet to write a replacement
that could deal with scripts and support loading conditions.

Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?

Not at this time. It'd be pretty easy to implement for someone who is familiar with dshow though (and that's usually the bottleneck for dshow-related stuff anyway).

Anyone able to poke around for someone capable of doing this?

Wilbert

21st June 2016, 23:41

Avisynth is going nowhere. He's what, the only person working on it? His code changes don't appear to be significant, I could be wrong but to me it seems pinterf has done more work on this branch than IanB has done on Avisynth recently, will Avisynth 2.7 ever come?

One can basically conclude that after 2.6, Avisynth is going nowhere fast. I guess it's a prime opportunity for Avisynth+ to take over, this was basically the intention wasn't it?
You are exaggerating a lot without checking your statements first. Note i'm not defending Avisynth here, i know that Avisynth+ has some nice features that Avisynth as not (and will not have in the short term).
Your last comment would have merit if several people would be working on Avisynth+ continuously (meaning without large breaks), but that's not really the case.

@Ultim, i talked with Ianb about that issue (size_t) more than a year ago, but he has a different opinion and won't revert those changes back. So that leaves us at a shitty situation with that many 64 bit plugins out there nowadays.

MysteryX

22nd June 2016, 02:45

Ultim is back; why is there so much aggressiveness in the air?

Really, the main problem with Avs+ is that it's based on Avisynth, with all the baggage that comes with that. Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work. The right thing to do is to keep the parts the users care about (i.e. the parts they see, the plugin loading and the scripting language) and throw most of the old garbage out completely. Vapoursynth did this but also threw out the scripting language, so it's more powerful but people don't like it because it's unfamiliar.
I don't agree.

Pinterf's efforts have already paid off in great ways. AviSynth+ MT is very solid.

I don't think learning a new scripting language is a big deal at all. The reason me and many are staying with AviSynth instead of going with VapourSynth is mostly because VapourSynth is still early in its development stage. It has advantages but also lacks features, and most importantly, has much less plugins (although that's growing). Many plugin writers nowadays write it for both. I haven't ported my plugin AviSynthShader to VapourSynth because I haven't used it yet and because it would provide no performance advantage. If VapourSynth was to include audio support and support all the plugins I'm using, I would consider switching over.

There seems to be an ego battle as to who's version we're using. For those who spent so much time developing one of the branches, there's a lot of pride associated to that and it can be hard to let it go to focus on what's best for all.

AviSynth 2.6, AviSynth+ or VapourSynth? I really don't care. Let's just use whatever works best.

I like Pinterf's mindset: just do your stuff and don't care what people think. He wants to add native 16-bit support that way. As long as it doesn't break existing plugins, some plugin developers can use it while others won't. It won't hurt anyone.

About the specific x64 problem, considering that there is no AviSynth 2.6 x64 out there and that AviSynth+ x64, I don't see why put any efforts in releasing a AviSynth 2.6 x64. If he does release it, then it's his job to ensure its compatibility with existing plugins unless he can take responsibility for recompiling every plugin -- which I doubt will go smoothly.

The most important point is to leave our egos on the side. Whether AviSynth has a future is irrelevant. It's here, it is working and it will remain useful to many. It gets better over time, slowly. Will VapourSynth take over AviSynth? Maybe. I hope it so. But that may take a lot of time and AviSynth still can't be replaced in most cases.

Reel.Deel

22nd June 2016, 04:13

Just look at pinterf's insane attempts at getting MT to kinda sorta maybe work.

Have you even tried it? The last time I checked, QTGMC in AviSynth+ MT performed a bit better than VapourSynth. So if you call that kinda sorta maybe working, then there's something really wrong with VS. I also love that you keep saying that AviSynth is 90's software yet a good percentage of the VapourSynth plugins and scripts are just ports from AviSynth. I have nothing against VS, in fact I was one of the early testers back in 2012 through 2014 and still use it to this day. You on the other hand, it seems you have some sort of personal vendetta against AviSynth. If you really care about VS so much than why is it that I've yet to see anything productive from you? Not a single bug report, or a plugin, or any help with the development, nothing, all you do is talk.

Ultim is back; why is there so much aggressiveness in the air?

Post #1773 and #1778. :)

MysteryX

22nd June 2016, 06:36

Blaming and arguing what could have been done in the past won't lead anywhere, I think we can all agree on that. So let's look at what's the best course of action for now.

If we're to require every plugin writer to adapt their plugins, better as well ask them to make them VapourSynth-compatible. IMO that's not a good idea.

In terms of code ugliness, honestly, I really don't care about the code being "theoretically correct" or "politically correct" as a user, as long as it's stable.

I see AviSynth continuing with its interface, and evolving with an extended interface that will need to be clearly defined at some point.

If IanB decides to release a version of AviSynth 2.6 x64 that isn't compatible with all the plugins already out, that will be his problem. Convincing everybody to recompile won't work when most are using AVS+ x64 anyway. He'll then have 2 options: adjust his x64 to match the existing libraries, or that version will end up in the abyss of times. Personally I don't see the need for AviSynth 2.6 x64 but the x86 version is still widely used. Here's another thing to consider, if we did get every plugin developer to re-compile, every single user would have to replace every single one of their plugins. That would be a mess. The forum would be flooded with newbies asking why their plugins aren't working anymore. Not counting DLL mixups and confusion all around the Internet, never knowing whether you're downloading the right version. Just think of what happened when the video industry decided to shift Rec.601 to Rec.709 to make it "better". We're still dealing with the side-effects.

I would see 2 points of improvements.

1. Clearly defining the extended interface of AviSynth+

2. Writing guidelines about how to write plugins that work with both AviSynth and VapourSynth. As a developer, it would be useful to have a comprehensive list of the differences and a roadmap to make them compatible.

ultim

22nd June 2016, 07:41

@Ultim, i talked with Ianb about that issue (size_t) more than a year ago, but he has a different opinion and won't revert those changes back. So that leaves us at a shitty situation with that many 64 bit plugins out there nowadays.

Thank you for talking to him. Knowing he won't revert takes at least one variable out of the equation.

Ultim is back; why is there so much aggressiveness in the air?
That's kind of a side-effect of my exchange with TheFluff, for which I am sorry, we both didn't mean it this way. And about me being back, please don't give me too much credit, I've told earlier that while I may help out now, others will have to start to take over my place.

You on the other hand, it seems you have some sort of personal vendetta against AviSynth. If you really care about VS so much than why is it that I've yet to see anything productive from you? Not a single bug report, or a plugin, or any help with the development, nothing, all you do is talk.
TheFluff doesn't have any vendetta, I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth. Also, as for his contributions, I think he is the maintainer of one of the most important source filters, FFMSSource and the associated library ffms2. Correct me if I'm wrong.

MysteryX

22nd June 2016, 08:40

I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth.
AviSynth was never dead. It will live for as long as it serves its purpose.

I use it for
- SVP live video conversion to 60fps
- Auto-attune video playback from 440hz to 432hz
- Video/audio processing and encoding

Out of all this, so far, VapourSynth can only do video processing and encoding. And that has nothing to do with the limited set of plugins available in it. That's just my personal situation -- AviSynth can't be replaced at this point.

burfadel

22nd June 2016, 11:51

I prefer Avisynth myself, I guess I'm not used to Vapoursynth.

There's a consideration for Avisynth in that legacy support should be offloaded, and have Avisynth primarily 'clean'. Basically to use a plugin requiring legacy support, you call the plugin for legacy support plugin commands, like:
legacyplugin(dooflakey(str=2.5))

Ideally thought the legacy plugins should be updated, not Avisynth. It's coming up to 2017, really should only be using 64-bit anyway :). That would probably make things a lot easier if only the 64-bit side of things were developed, and have the corresponding plugins updated.

ryrynz

22nd June 2016, 13:01

tormento

22nd June 2016, 13:56

As pinterf is now an active contributor, I feel it is time to submit again an old problem I introduced months ago.

Here (http://www59.zippyshare.com/v/mHO2J20t/file.html) is the original sample from BD.

When I apply the following script, using AviSynth 2.6 MT, I have good encodings.

13HoursAV26.dgi (http://www76.zippyshare.com/v/rRxxLkBo/file.html)

SetMTMode(3)
SetMemoryMax(2048)
LoadPlugin("D:\eseguibili\media\DGDecIM\dgdecodeim.dll")
DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAV26.dgi", silent=true)
ChangeFPS(last,last,true)
SetMTMode(2)
crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)

Result (http://www59.zippyshare.com/v/hIE3KfV0/file.html).

When I use AviSynth+, I have image corruption.

13HoursAVS+.dgi (http://www76.zippyshare.com/v/BEQF0P24/file.html)

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)
SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursAVS+.dgi")
#SetFilterMTMode("DGSourceIM", 3)
#LoadPlugin("D:\eseguibili\media\DGDecIM\x64\dgdecodeim.dll")
#DGSourceIM("E:\in\2_24 13 hours — The secret soldiers of Benghazi\13HoursCUT.dgi", silent=true)
ChangeFPS(last,last,true)
#Crop(0, 140, 0, -140)
SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6)
Prefetch(8)

prefilter=1 (http://www62.zippyshare.com/v/HuSWnCqY/file.html) OK
prefilter=2 (http://www62.zippyshare.com/v/5NkG9ias/file.html) OK
prefilter=3 (http://www62.zippyshare.com/v/AXzb0Vqj/file.html) OK
prefilter=4 (http://www62.zippyshare.com/v/EU1MjUsM/file.html) CORRUPTION

Memento:

prefilter

[int: "-1", 0, 1, 2, 3, 4] or [clip: - ]

-1 = off (Default)
0 = light controlled gauss blur
1 = mild median/gauss blur
2 = strong median/gauss blur
3 = dfttest (spatial)
4 = KNLmeansCL (spatio-temporal GPU filter)
variable = prefiltered clip input variable

I have tried to use x86 version of AviSynth+, even DGIndexIM.

Results does not change.

The plugin versions I use are the following for both AviSynth and AviSynth+.

[Avisynth CPP 2.6 plugins]
D:\Programmi\media\AviSynth+\plugins64\KNLMeansCL-0.7.6.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MaskTools-2.1b1-tp7.dll (2.1.0.0)
D:\Programmi\media\AviSynth+\plugins64\MedianBlur2-0.94-tp7.dll (n/a)
D:\Programmi\media\AviSynth+\plugins64\MVTools-2.7.0.22-pfmod.dll (2.7.0.22)
D:\Programmi\media\AviSynth+\plugins64\RgTools-0.92.1-tp7.dll (n/a)

[Avisynth CPP 2.5 plugins]
D:\Programmi\media\AviSynth+\plugins64\DFTTest-1.9.4.dll (1.9.4.0)
D:\Programmi\media\AviSynth+\plugins64\Dither-1.27.2.dll (n/a)

I can provide other movie examples too.

Ideas? Fixes?

P.S.: Previous post is here (http://forum.doom9.org/showthread.php?p=1739893#post1739893).

Reel.Deel

22nd June 2016, 14:06

TheFluff doesn't have any vendetta, I think he'd just like to see people not resurrecting Avisynth again and again, but to put our efforts into VapourSynth instead of Avisynth. Also, as for his contributions, I think he is the maintainer of one of the most important source filters, FFMSSource and the associated library ffms2. Correct me if I'm wrong.

It certainly seems that way (here and in other threads in the past year). He has helped maintained FFMS2, but not in recent times nor anything to do with VS: https://github.com/FFMS/ffms2/graphs/contributors

Anyways, lets get back on topic. :)

TheFluff

22nd June 2016, 16:33

I haven't contributed to any open source projects in many years now. In fact I don't even code for a living anymore, I've switched careers. I don't use Avisynth or Vapoursynth myself either since I don't encode any video anymore and haven't done so for at least four or five years. For some reason though I still hang around with people who do work with these things and for some reason I still care. You are of course always free to disregard my opinions on any grounds you prefer.

To be clear, when I'm talking about pinterf's insane things, I'm referring to the recent problems with eval() having to be treated as a MT_NICE_FILTER. This is of course patently insane, eval() isn't a filter and should be seen as a component of the script parser, but nope, this is what you get for trying to tack on multithreading to a hobbyist project from the 90's. The amount of "cleverness" (to put it nicely) required to keep it working in all cases just keeps growing until you have a completely unmaintainable mess.

What the Avisynth community definitely needs the least these days is more fragmentation. It's been pretty bad for many years with all the different MT versions and official versions and Avxsynth and god knows what else, but at least they had compatible plugins and script interpreters. When pinterf showed up I thought it was going to take yet another alarming turn for the worst with another fork and new version but fortunately that didn't happen. Instead, though, we now have, what, five different MVTools versions? Jeez, people, consolidate! I really don't think the plugin interface thing is such a huge deal either, it should be fairly easy to write wrappers to let you load other/older plugin interface versions in Avs+. Just ignore the "official" version IMO - you have the userbase on your side, the people who are still using the official version today are the kind of people who are still using Windows XP and are likely never going to upgrade either Avisynth or their plugins or their computers, even if a new version actually was released. 2.5.0 was released in 2003, 2.5.8 in 2008 and 2.6 last year, so at this rate, if you want a "final" 2.6 in the style of 2.5.8, expect to wait until 2020, and for "2.7" you're going to have to wait at least until 2027 or so. There's no point in trying to have a half-hearted fork that doesn't even attempt to supplant the parent project, either. Aim for the stars.

TheFluff

22nd June 2016, 16:38

If VapourSynth was to include audio support and support all the plugins I'm using, I would consider switching over.
Out of curiosity, what plugins are you missing in VS? Also, are you aware it can load Avisynth plugins? I'm not trying to sell you a bridge or anything, I just believe you have a mistaken view of the state of VS.

MysteryX

22nd June 2016, 17:13

Out of curiosity, what plugins are you missing in VS? Also, are you aware it can load Avisynth plugins? I'm not trying to sell you a bridge or anything, I just believe you have a mistaken view of the state of VS.

This is one of the scripts I use for live playback at 432hz. This can't be done in VapourSynth.

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA\In Your Eyes.mkv"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Preroll(int(FrameRate*3))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)

I haven't looked into what filters are or are not available in VapourSynth. RoboCrop to detect cropping isn't x64 compatible so I don't think that's in VapourSynth unless there's a replacement. If I crop the video and change the speed, I need to process the audio in the same way and I then call WriteToWAV and process the audio file separately.

As for "MT not working", I just realized something. There are two types of plugins out there. There are stand-alone plugins that just require a DLL to work, and there are "throw it all on the wall"-type plugins that depend on a chain of plugins that each depend on another chain of plugins. The first type is generally very stable with MT. The second type is not.

I was experimenting with SMDegrain and was surprised by the results, especially when combined with KNLMeans.

This did a great job on my SD videos and worked with MT.

SMDegrain(thsad=2000, contrasharp=true, lsb_in=true, lsb_out=true)

With HD content, it failed miserably. In fact I still can't get ContraSharp to run at all. With contrasharp=false, I can get it to work as long as MT is off, as MT causes deadlocks.

That's not an issue with AviSynth+ MT; but these plugins that depend on a whole chain of other plugins tend to be very unstable.

real.finder

22nd June 2016, 17:21

This is one of the scripts I use for live playback at 432hz. This can't be done in VapourSynth.

P="Encoder\"
LoadPlugin(P+"LSMASHSource.dll")
LoadPlugin(P+"TimeStretch.dll")
file="INNA\In Your Eyes.mkv"
LWLibavVideoSource(file, cache=False)
AudioDub(LWLibavAudioSource(file, cache=False))
Preroll(int(FrameRate*3))
ResampleAudio(48000)
TimeStretchPlugin(pitch = 100.0 * 0.98181819915771484)

I haven't looked into what filters are or are not available in VapourSynth. RoboCrop to detect cropping isn't x64 compatible so I don't think that's in VapourSynth unless there's a replacement. If I crop the video and change the speed, I need to process the audio in the same way and I then call WriteToWAV and process the audio file separately.

As for "MT not working", I just realized something. There are two types of plugins out there. There are stand-alone plugins that just require a DLL to work, and there are "throw it all on the wall"-type plugins that depend on a chain of plugins that each depend on another chain of plugins. The first type is generally very stable with MT. The second type is not.

I was experimenting with SMDegrain and was surprised by the results, especially when combined with KNLMeans.

This did a great job on my SD videos and worked with MT.

SMDegrain(thsad=2000, contrasharp=true, lsb_in=true, lsb_out=true)

With HD content, it failed miserably. In fact I still can't get ContraSharp to run at all. With contrasharp=false, I can get it to work as long as MT is off, as MT causes deadlocks.

That's not an issue with AviSynth+ MT; but these plugins that depend on a whole chain of other plugins tend to be very unstable.

try this http://pastebin.com/6Czuj5s0

Myrsloik

22nd June 2016, 20:42

The binary compatibility stuff is really the smallest problem. You can always write a shitty wrapper. See the VapourSynth compatibility code on how to wrap things to something not completely identical.

Btw, the size_t thing is also possibly the smallest problem ever. I just realized that I'd implemented my own x64 compatility with the plain 2.6 header. Guess what? IT WROKSKSKSSS!!!!!!!1111 So just recompile everything with a 2.6 header and you're good.

Btw, TheFluff is the chief VS evangelist so you have to respond to all his trolling. No excuses.

And in regards to VS and plugins. I believe all popular unported plugins should work using the avisynth compatibility. If you find one that doesn't just post about it and I'll take a look.

StainlessS

22nd June 2016, 21:55

TheFluff is the chief VS evangelist
What, you mean he does a lot of shouting, we all knew that !

ryrynz

22nd June 2016, 22:06

Just ignore the "official" version IMO - you have the userbase on your side, the people who are still using the official version today are the kind of people who are still using Windows XP and are likely never going to upgrade either Avisynth or their plugins or their computers, even if a new version actually was released. 2.5.0 was released in 2003, 2.5.8 in 2008 and 2.6 last year, so at this rate, if you want a "final" 2.6 in the style of 2.5.8, expect to wait until 2020, and for "2.7" you're going to have to wait at least until 2027 or so.

Yup, that's what I said too. It's going nowhere fast. Wrap away.

qyot27

22nd June 2016, 23:31

Wouldn't it be pretty straight forward to just fork it, have a legacy branch that receives whatever updates Avisynth gets, plus any easily portable updates and one branch where everything goes it's own way.
Simpler than that, actually; the AviSynthPlus repo on Github was itself forked from jeeb's, which (on a good day) was/is up-to-date with the CVS*. Cherry-pick and adapt whatever patches are relevant into an integration branch, and open a pull request to merge the integration branch into AviSynth+ HEAD. This is exactly how the RC1 and still-yet-unmerged RC2 integration was done, and how I'm currently slogging through the remainder of the 2.6a1/CVS stuff up to the beginning of June.

*and when it hadn't been updated with cvsimport in a while, I went ahead and pushed up a classic_avisynth (https://github.com/qyot27/AviSynthPlus/commits/classic_avisynth) branch into my personal avsplus repo that exists alongside MT and co.

StainlessS

22nd June 2016, 23:59

I find myself asking why IanB would not want to sit back and relax, if others are prepared to take what has been achieved and carry it forward, great,
Ian deserves a rest and to watch whilst others add to his baby, no way should it be perceeived as anything less than total success, because that is what it is.
For myself I could not desert the current official state, and would I think not do so, but I do recognise the vigour of the new pretenders.
I dont know why Ian has chosen to isolate himself from the world, I at one time had my suspicions as to why, but rightly or wrongly, it is the path he has chosen to take,
however isolation cannot be good for anyone here. One cannot oversee or steer from afar something akin to Avisynth, perhaps Ian should forgo his ownership
of avs and let the new lads have a go.

Above was so very hard for me to say.

MysteryX

23rd June 2016, 01:21

try this http://pastebin.com/6Czuj5s0
That's the version I have.

I'm discussing that issue in this thread (http://forum.doom9.org/showthread.php?p=1771486#post1771486)

pinterf

23rd June 2016, 09:48

Btw, the size_t thing is also possibly the smallest problem ever. I just realized that I'd implemented my own x64 compatility with the plain 2.6 header. Guess what? IT WROKSKSKSSS!!!!!!!1111
For historical reasons my mvtools2 mod is also using that size_t version of the classic avs 2.6 header, and encountered no problem.
Why? Because these fields are accessed through methods instead of direct reference? I suppose it would break in a plugin running under avs+ x64 if we used avs 2.6 header and access pitch instead of calling GetPitch()?

int GetPitch(int plane = 0) const AVS_BakedCode(return AVS_LinkCall(GetPitch)(plane))

Classic
class VideoFrame {
public:
volatile long refcount;
VideoFrameBuffer* const vfb;
const size_t offset;
const int pitch, row_size, height;
const size_t offsetU, offsetV; // U&V offsets are from top of picture.
const int pitchUV, row_sizeUV, heightUV;

avs+
class VideoFrame {

volatile long refcount;
VideoFrameBuffer* vfb;

// Due to technical reasons these members are not const, but should be treated as such.
// That means do not modify them once the class has been constructed.
int offset, pitch, row_size, height, offsetU, offsetV, pitchUV; // U&V offsets are from top of picture.
int row_sizeUV, heightUV;