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. |
21st June 2016, 11:01 | #1762 | Link | |
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Quote:
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. |
|
21st June 2016, 13:58 | #1763 | Link |
AVS+ Dev
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 14:04. |
21st June 2016, 14:22 | #1764 | Link |
AVS+ Dev
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+ |
21st June 2016, 15:56 | #1765 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
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.
__________________
FrameRateConverter | AvisynthShader | AvsFilterNet | Natural Grounding Player with Yin Media Encoder, 432hz Player, Powerliminals Player and Audio Video Muxer Last edited by MysteryX; 21st June 2016 at 16:00. |
21st June 2016, 17:08 | #1766 | Link |
AVS+ Dev
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+ |
21st June 2016, 17:12 | #1767 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,666
|
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? |
21st June 2016, 18:12 | #1768 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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. 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. |
|
21st June 2016, 18:15 | #1769 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
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. |
|
21st June 2016, 18:27 | #1771 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
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 |
21st June 2016, 18:48 | #1772 | Link | |
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
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 19:20. |
|
21st June 2016, 19:32 | #1773 | Link | |||
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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:
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. 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 19:35. |
|||
21st June 2016, 19:38 | #1774 | Link | ||
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,666
|
Quote:
Quote:
Yes, 64-bit AviSynth+ r1576 is rock solid. |
||
21st June 2016, 20:18 | #1775 | Link | |||
AVS+ Dev
Join Date: Aug 2013
Posts: 359
|
Quote:
Quote:
Quote:
__________________
AviSynth+ Last edited by ultim; 21st June 2016 at 21:10. Reason: Typos |
|||
21st June 2016, 22:00 | #1776 | Link | |||||
Registered User
Join Date: Mar 2009
Posts: 3,650
|
Quote:
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:
Quote:
that could deal with scripts and support loading conditions. Quote:
Quote:
Last edited by ryrynz; 21st June 2016 at 22:10. |
|||||
21st June 2016, 23:41 | #1777 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
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. |
|
22nd June 2016, 02:45 | #1778 | Link | |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Ultim is back; why is there so much aggressiveness in the air?
Quote:
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. |
|
22nd June 2016, 04:13 | #1779 | Link | |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,666
|
Quote:
Post #1773 and #1778. Last edited by Reel.Deel; 22nd June 2016 at 04:16. Reason: typo |
|
22nd June 2016, 06:36 | #1780 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
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.
__________________
FrameRateConverter | AvisynthShader | AvsFilterNet | Natural Grounding Player with Yin Media Encoder, 432hz Player, Powerliminals Player and Audio Video Muxer Last edited by MysteryX; 22nd June 2016 at 06:39. |
|
|