Avisynth+

[chainik_svp]

I've got your point in the end

It's not very hard to test ffdshow with Avisynth (2.5.8) x64, right? It should give the very same behavior.

And again, we can wait forever for someone to look into ffdshow code.
As I'm the only one who needs it here, I'll do it...

[chainik_svp]

I can't find any WIN64 specific code in ffdshow.

struct Tinput : Tavisynth_c {
...
    IScriptEnvironment* env;
    PClip* clip;
...
    ~Tinput() {
        if (clip) {
            delete clip;
        }
        if (env) {
            delete env;
        }
    }
};

But I'm scared of:

struct Tavisynth_c : public Tdll, w/o destructor at all
...
struct Tinput : Tavisynth_c
...
~Tinput()

I'm done for today...

[innocenat]

Just a quick chime in: ffdshow use Avisynth C interface, with Avisynth API version 2 (according to tryout-trunk). The IScriptEnvironment and PClip are just facade with same interface as the Avs C++ interface, but internally call Avs C interface.

EDIT: There is one mismatch between C interface and C++ interface, mainly in VideoFrame and AVS_VideoFrame structure. It is long vs int problem, though it would only matter if ffdshow is compiled with LP64 data model (not commonly used on windows, but widely on *nix)

[jpsdr]

Originally Posted by ultim

EDIT: Notes on using the correct avisynth header. Avs+'s header is compatible with all previously compiled x64 plugins, even those not compiled for Avs+. So using Avs+'s header makes sure you use the correct one as it is also the latest. The very recent Avisynth 2.6 RC1 introduced modifications to the x64 interface which is NOT compatible to any x64 plugin from before, so until the situation is cleared up, I strongly advice you not to use the Avisynth 2.6 header in 64-bit mode, as it will break any and all 64-bit plugins.

I didn't take a look at this new interface, but according your saying, it seems that they finaly want to do what they should have done since the begining, and what was done since the begining in VirtualDub : size_t for pointer, and ptrdiff_t for memory offset. But with all the x64 pluggin allready done, this may be a little to late...

Edit : I took a look... It's not even made properly (at least, from my point of view). Some pitch became size_t, when the right choice would be ptrdiff_t, alowing this way positive and negative offset.

[ultim]

Originally Posted by jpsdr

Edit : I took a look... It's not even made properly (at least, from my point of view). Some pitch became size_t, when the right choice would be ptrdiff_t, alowing this way positive and negative offset.

That'd be still fine in this case. In Avisynth buffer offsets shouldn't be negative anyway, so here a size_t actually fits better than a ptrdiff_t, because it mirrors the developer's intentions more closely. What bothers me is that they did this for... what reason exactly? This change in the interface has no present or future benefit for Avisynth, yet it breaks all existing 64-bit plugins.

[Stereodude]

Originally Posted by ultim

This change in the interface has no present or future benefit for Avisynth, yet it breaks all existing 64-bit plugins.

Maybe that was the reason.

[Wilbert]

Yes sure that was the reason. If it isn't done correct in the past, that's shouldn't be a reason to do that too in the future. I understand it is very inconvienient for the users of existing 64-plugins and i guess for Avisynth+ users too, and apologies for that, but it shouldn't be too much hassle to recompile the important 64-bit plugins. Or do i miss something and is it a lot of work?

[LoRd_MuldeR]

Originally Posted by Wilbert

Yes sure that was the reason. If it isn't done correct in the past, that's shouldn't be a reason to do that too in the future. I understand it is very inconvienient for the users of existing 64-plugins and i guess for Avisynth+ users too, and apologies for that, but it shouldn't be too much hassle to recompile the important 64-bit plugins. Or do i miss something and is it a lot of work?

Is there any mechanism that prevents the "old"-style x64 plug-in's from loading with the "new"-style x64 Avisynth, or will they simply cause undefined behavior (crash)?

[ultim]

I'd agree if these changes were any more correct. But you weren't storing pointers in smaller-size integers or doing stupid stuff like that previously, you were just merely limiting the size of an image plane to 2 gigabytes. Since a frame size that large is not in any way realistic, please elaborate how the previous types were more wrong than the new interface. Your reasoning cannot be "because these are pointer offsets", because with that puristical and theoretical argument, the choice of a size_t is equally wrong, as it should be ptrdiff_t then. Fortunately, both size_t and int work perfectly without disadvantages in any real use case. The only practical difference is breaking old plugins or not.

[qyot27]

What would be necessary for (as mentioned in the RC1 thread concerning what VapourSynth does) storing planes in separate pointers, or for >8bit processing? Or both of those together. Because it sounded like it could be needed by the case of using separate pointers per-plane, and if that's a feature that is planned for 2.6 or some future version, that would be a rationale even without high bit depth support.

I'm mostly just curious about what those things would actually need. libavformat handles the frame size calculation issue by casting to int64_t when reading in the width and height, as you can see here. If the problem shows up around 9k x 9k @ 8bit, then >8bit would spark it at resolutions that are within cases we might very well see in the near future (like 8K UHD). If it's the same for plugins, anyway (or not a libavformat-specific thing); libavformat is simply taking input from the AviSynth library, not from the plugins.

EDIT: Not that I've tried doing the math to figure out what the maximum allowable frame sizes in a 2GB plane case is. I'm mostly just thinking out loud.

[ultim]

Storing planes in separate pointers like VS is purely a design decision, and has zero effect on the supported feature set. At most it allows some negligible performance optimizations. The most important thing that Avisynth would need to support more features is to be able to store additional data members in Clip and VideoFrame classes. In a clean solution, that would also be a breaking change to plugins. But even this is solvable without breaking plugins, using hacks in the code and additional complexity, but definitely possible. For supporting >8bit, not even that is necessary, the main thing inhibiting higher bitdepths is upgrading all the plugins and internal functions to work with >8bits: a crazy amount of coding necessary, lot of time, and relatively few people capable at all.

As for handling UHD: a full 9k x 9k frame, even if you take something very odd, like 16bits, no subsampling, RGB interleaved, with alpha transparency (this is about as large as you can get), still only consumes about 618 Mbytes of memory. So even for something crazy like this, the old datatypes were more than enough. So you cannot justify breaking the interface by that.

[ultim]

Originally Posted by LoRd_MuldeR

Is there any mechanism that prevents the "old"-style x64 plug-in's from loading with the "new"-style x64 Avisynth, or will they simply cause undefined behavior (crash)?

Undefined behavior.

[TheFluff]

I think you are a bit overly attached to an ABI from like 2002. Especially since almost nobody actually uses 64-bit Avisynth (there was a poll about this a year back or so, IIRC basically nobody claimed to be using 64-bit Avisynth). I was about to say this is a golden opportunity to finally man up and fix that hilariously retarded plugin interface, but then I realized this is Avisynth we're talking about and obviously everything needs to work just like in the 90's or people will hurf a durf.

[ultim]

Originally Posted by TheFluff

I think you are a bit overly attached to an ABI from like 2002. Especially since almost nobody actually uses 64-bit Avisynth (there was a poll about this a year back or so, IIRC basically nobody claimed to be using 64-bit Avisynth). I was about to say this is a golden opportunity to finally man up and fix that hilariously retarded plugin interface, but then I realized this is Avisynth we're talking about and obviously everything needs to work just like in the 90's or people will hurf a durf.

Yes, if you are going to break the interface anyway, just man up as you say and do it correctly, and correct all the other mistakes too. Oh wait, you cannot, because then for those other changes you'd have to break to 32-bit interface too, and that interface /is/ used by a lot of people.

You make it sound like I just want to stay by the old interface no matter what. Wrong! I am not against this change because it touches some old stuff. I am against it because it doesn't bring any kind of benefit, but causes problems. If there is a good reason, like correcting design mistakes, modernizing it, adding new features, or anything along these lines, I'd just go with it. But this change was none of them, yet makes all plugins from the past 6+ years unusable.

Avisynth+ will break the interface in the future, moreoever, it will do it drastically. It is already being planned. But, very importantly, it will do it only once, for real benefits and progress, and will do it in a sustainable way such that breaking modification won't be necessary again after that. And I am waiting for it eagerly, and I won't shed a single tear for the old interface. But this needs preparation, both on Avisynth's core's side as well on the plugins' side.

Make it personal if you really want to. But in the end, every real programmer should see this is not about "manning up", or throwing false accusations around that I just love stuff from the 90's. It is about careful preparation, waiting out until stuff is ready, then doing the change responsibly in the end.

[Stereodude]

Originally Posted by TheFluff

Especially since almost nobody actually uses 64-bit Avisynth (there was a poll about this a year back or so, IIRC basically nobody claimed to be using 64-bit Avisynth).

I use it extensively along with MP_Pipeline for mixing 32-bit and 64-bit. Even if all the scripting is really in 32-bit at the very least its very handy to feed x264 64-bit without having to pipe it.

[jpsdr]

Originally Posted by TheFluff

Especially since almost nobody actually uses 64-bit Avisynth

ME !!! ME !!! ME !!!
I am, i am, i am !!!


And i love stuff from 90's, even 80's, it was my youth.

[kaefert]

I also use 64bit, since with avisynth 32bit my scripts simply won't work at all. I'm using avisynth as a non-linear video editor therefore my scripts have A LOT of input streams which simply bursts the memory limitations of 32bit.

[ultim]

So you are writing your own AviSynth plugin (cool!), and obviously one of the first things you have to do in your code is to include the AviSynth header. But which one? With all the different header variants lying around it is easy to get lost if you haven't been following AviSynth's development for a long time. Should you copy the header from another plugin? Should you copy it from the AviSynth64 project to be 64-bits compatible? Should you take the 2.5 header as it is the latest release that is officially stable? Do you need SEt's AviSynth-MT header if you want multithreading compatibility? Do you need seperate headers for 32- and 64-bits like most plugins ship it? Should you just take the latest header from the AviSynth 2.6 project? And what about AviSynth+'s header?

Fortunately, no matter how you answer the above questions, there is one (and just one) solution that is easy to implement and fits all needs: Use AviSynth+'s header. And if you'd like to know why, read on.

So let's tackle the above questions.

Should you copy the header from another plugin?
No. Most plugins are older then AviSynth project releases, and so they ship with outdated (and sometimes buggy) headers. Also, some plugins have both separate 32- and 64-bit sources, so you still wouldn't know which one to take. And if you are really unlucky, you might stumble on a plugin that was written for AviSynth 2.5, and using that header would be the worst of all your header-related options.

Should you take the 2.5 header as it is the latest release that is officially stable?
No. 2.5 is no more. Most plugins that have originally been written for 2.5 have been already recompiled for 2.6. Don't try to be smart and support both versions, because they are not compatible. 2.6 has been around for many years now, and the existing plugin ecosystem builds exstensively around this version. Technically speaking, it is stable. Nobody uses 2.5 any more.

Should you copy it from the AviSynth64 project to be 64-bits compatible?
No. While AviSynth64's header will work perfectly if you want your plugin to *only* run in 64-bit mode, that is most likely not the case. That project isn't maintained any more, and thanks to that the 32-bit part is out of date.

Do you need seperate headers for 32- and 64-bits like most plugins ship it?
No. You will see plugins around that have both avisynth.h and avisynth64.h. Same for many applications hosting avisynth.dll. This is because the original AviSynth project never supported 64-bit processing (not even today), so these other projects took the 32-bit header from the latest AviSynth version that was available when they were created, and they took the 64-bit header from the AviSynth64 project. This resulted in an ecosystem where the 64-bit versions didn't see any improvements over the years. On the upside, avisynth64.h stayed stable. On the downside, the 32-bit and 64-bit headers started drifting apart. Nevertheless, a merge of the avisynth.h and avisynth64.h headers is easily possible, which is exactly what AviSynth+ has done. There is no need for two separate headers, it only results in additional code, complexity, and maintenance burden.

Do you need AviSynth-MT's header if you want multithreading compatibility?
No. While properly supporting multithreaded versions does require special coding considerations from plugin writers (see this other article), none of those considerations affect the choice of header. There is no API or ABI difference between multi-threaded and single-threaded AviSynth versions. You can perfectly support MT-capable AviSynth versions even if using the header from an AviSynth variant that has no MT-support.

Should you just take the latest header from the AviSynth 2.6 project?
No. This project (sometimes people refer to it as the "original" or "official" AviSynth, though somewhat incorrect) always has the latest version, but it will do you no good if you want to support 64-bit processing. You cannot compile your plugin using its header in 64-bit mode, which is why people started using avisynth64.h in the first place. Even if it decided to support 64-bit in the future, it wouldn't be compatible to the existing (and pretty large) 64-bit ecosystem anymore, throwing away all the 64-bit plugin and application development that has been done in the past 6 years or so. And as already said, using two separate headers is completely unnecessary and only leads to additional complications down the road.

What about AviSynth+'s header?
The headers of AviSynth+ are up to date in every aspect and provide the greatest possible compatibility. By using AviSynth+'s headers, applications and plugins can cleanly compile and run in 32-bits and 64-bits. It is 100% compatible to the latest 32-bit development on the old AviSynth 2.6 project, while supporting all 64-bit binaries. And of course, you can use it regardless if you support multithreading or not. Furthermore and importantly, it is fully compatible to installations of the AviSynth 2.6, AviSynth-MT, AviSynth64, and of course the AviSynth+ projects, so your plugin/application will be able to run on any user's machine.

[chainik_svp]

ultim
Use AviSynth+'s header.

So why it still contains that "normal licence conditions will be reapplied in a future version" thing from AVS 2.6 header?

[ultim]

Originally Posted by chainik_svp

ultim
Use AviSynth+'s header.

So why it still contains that "normal licence conditions will be reapplied in a future version" thing from AVS 2.6 header?

The 2.6 header is originally written by Ianb, and even though we have made a derivative work of it, we cannot legally relicense the header without his explicit permission. LGPL-like condiitons (even if technically not LGPL) will be restored when 2.6 exits the RC stage, or when Avisynth+ creates a 100% new header, whichever comes first.