Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st June 2016, 11:52   #1761  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,256
Quote:
Originally Posted by Chikuzen View Post
It's a bug.
patch
Thank you, applied.
pinterf is offline   Reply With Quote
Old 21st June 2016, 12:01   #1762  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,229
Quote:
Originally Posted by ryrynz View Post
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.
ryrynz is offline   Reply With Quote
Old 21st June 2016, 14:58   #1763  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
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.
__________________
AviSynth+

Last edited by ultim; 21st June 2016 at 15:04.
ultim is offline   Reply With Quote
Old 21st June 2016, 15:22   #1764  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
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.
__________________
AviSynth+
ultim is offline   Reply With Quote
Old 21st June 2016, 16:56   #1765  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
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.

Last edited by MysteryX; 21st June 2016 at 17:00.
MysteryX is offline   Reply With Quote
Old 21st June 2016, 18:08   #1766  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
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.
__________________
AviSynth+
ultim is offline   Reply With Quote
Old 21st June 2016, 18:12   #1767  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,117
Thoughs on documentation?

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?
Reel.Deel is offline   Reply With Quote
Old 21st June 2016, 19:12   #1768  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
Originally Posted by ultim View Post
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.

Quote:
Originally Posted by MysteryX View Post
- 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.
TheFluff is offline   Reply With Quote
Old 21st June 2016, 19:15   #1769  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,084
Quote:
Originally Posted by ultim View Post
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.
qyot27 is offline   Reply With Quote
Old 21st June 2016, 19:19   #1770  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Quote:
Originally Posted by TheFluff View Post
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.
MysteryX is offline   Reply With Quote
Old 21st June 2016, 19:27   #1771  |  Link
Groucho2004
Fossil
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Location: A wretched hive of scum and villainy
Posts: 4,470
Quote:
Originally Posted by MysteryX View Post
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?
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Old 21st June 2016, 19:48   #1772  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by TheFluff View Post
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.
__________________
AviSynth+

Last edited by ultim; 21st June 2016 at 20:20.
ultim is offline   Reply With Quote
Old 21st June 2016, 20:32   #1773  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,073
Quote:
Originally Posted by ultim View Post
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 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.

Quote:
Originally Posted by ultim View Post
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.

Quote:
Originally Posted by ultim View Post
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.

Last edited by TheFluff; 21st June 2016 at 20:35.
TheFluff is offline   Reply With Quote
Old 21st June 2016, 20:38   #1774  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,117
Quote:
Originally Posted by TheFluff View Post
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.

Quote:
Originally Posted by ultim View Post
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/AviSynt...2B_x64_plugins

Quote:
Originally Posted by ultim View Post
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.
Reel.Deel is offline   Reply With Quote
Old 21st June 2016, 21:18   #1775  |  Link
ultim
AVS+ Dev
 
ultim's Avatar
 
Join Date: Aug 2013
Posts: 359
Quote:
Originally Posted by TheFluff View Post
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.

Quote:
Originally Posted by TheFluff View Post
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.

Quote:
Originally Posted by TheFluff View Post
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.
__________________
AviSynth+

Last edited by ultim; 21st June 2016 at 22:10. Reason: Typos
ultim is offline   Reply With Quote
Old 21st June 2016, 23:00   #1776  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,229
Quote:
Originally Posted by ultim View Post
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?

Quote:
Originally Posted by MysteryX View Post
I think VapourSynth has great potential but it still lacks major features:
- ffdshow support
Quote:
Originally Posted by TheFluff View Post
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.

Quote:
Originally Posted by Clsid
Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?
Quote:
Originally Posted by TheFluff
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).
Quote:
Originally Posted by ryrynz View Post
Anyone able to poke around for someone capable of doing this?

Last edited by ryrynz; 21st June 2016 at 23:10.
ryrynz is offline   Reply With Quote
Old 22nd June 2016, 00:41   #1777  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
Quote:
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.
Wilbert is offline   Reply With Quote
Old 22nd June 2016, 03:45   #1778  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Ultim is back; why is there so much aggressiveness in the air?

Quote:
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.
MysteryX is offline   Reply With Quote
Old 22nd June 2016, 05:13   #1779  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,117
Quote:
Originally Posted by TheFluff View Post
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.


Quote:
Originally Posted by MysteryX View Post
Ultim is back; why is there so much aggressiveness in the air?
Post #1773 and #1778.

Last edited by Reel.Deel; 22nd June 2016 at 05:16. Reason: typo
Reel.Deel is offline   Reply With Quote
Old 22nd June 2016, 07:36   #1780  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
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.

Last edited by MysteryX; 22nd June 2016 at 07:39.
MysteryX is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.