AviSynth+ 3.5: Linux, macOS, and BSD support

[StainlessS]

Well, I'de already written this so posting.

Originally Posted by stax76

C:\Users\frank\Desktop\bin>mklink /h .\Apps\Support\mpv.net\AviSynth.dll .\Apps\Support\AviSynth.dll
The system cannot find the file specified.

I know dick bout this but should it not be

C:\Users\frank\Desktop\bin>mklink  .\Apps\Support\mpv.net\AviSynth.dll ..\..\AviSynth.dll

Relative to the first "Avisynth.dll" link, ie up two parent levels, above the link itself.


EDIT: And I presume that above marked in blue could be an absolute [ie drive relative] path without disrupting anything.

EDIT: Maybe not, I just tried it on Win7 and it converted it to an absolute path in the link.

EDIT: Ignore above, it DOES WORK, it shows as absolute path in link properties box, but move the containing folder and it still works.
(absolute path changes to the changed absolute path when shown in the link properties)

[stax76]

You got it!!! Working perfectly, tested with ffmpeg as mpv.net already has a workaround.

But if the link is relative, why does the github thread say it's not portable across machines? I've used a cmd terminal without admin rights to create the symlink and it works, this is important as I think a portable app should not bother asking for admin rights.

Looks like we got a solution, thank you qyot27 and StainlessS!

[StainlessS]

Maybe means not portable to have relative SOFT link on machine A pointing to a file/folder on machine B.

The link shown in Properties [to target] is [on Win7] converted to an absolute path just for the Properties dialog box display,
it must actually still be relative in reality.

EDIT: Probably also not possible to have soft link pointing to a different drive.

EDIT: Changed my mind, can have soft link to another drive, "Send To Desktop" works from any drive,
but suspect in such cases it is an absolute path with drive letter.
Create Shortcut probably makes the decision for you as to relative or not based on whether relative path is possible.

[StainlessS]

Under Win7, if you just right click and New Shortcut(Soft Link), and create shortcut to where target is in the folder one above the shortcut.
And then you rename the folder containing the target, to something else, then the shortcut still works.
So, at least under W7 (and WXP I think), you dont have to go to the command line [or have admin rights].
(XP has cmd line FsUtil.exe which is related to mklink.exe, and also exists under W7)

From FsUtil on W7

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\root>fsutil
---- Commands Supported ----

8dot3name       8dot3name managment
behavior        Control file system behavior
dirty           Manage volume dirty bit
file            File specific commands
fsinfo          File system information
hardlink        Hardlink management
objectid        Object ID management
quota           Quota management
repair          Self healing management
reparsepoint    Reparse point management
resource        Transactional Resource Manager management
sparse          Sparse file control
transaction     Transaction management
usn             USN management
volume          Volume management

C:\Users\root>

No idea how to use it [probably need admin rights].
EDIT: RED, Not avilable on XP64.

Hardlink on XP/W7

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\root>fsutil hardlink
---- HARDLINK Commands Supported ----

create          Create a hardlink
list            Enumerate hardlinks on a file

C:\Users\root>fsutil hardlink list
Usage : fsutil hardlink list <filename>
   Eg : fsutil hardlink list c:\foo.txt

C:\Users\root>fsutil hardlink create
Usage : fsutil hardlink create <new filename> <existing filename>
   Eg : fsutil hardlink create c:\foo.txt c:\bar.txt

C:\Users\root>

EDIT: fsutil hardlink list, not available on XP [EDIT: XP64].

[MeteorRain]

Soft links -- Do you mean Symbolic Links? Because shortcuts and symbolic links are different things.

[StainlessS]

Dont know what I mean't there, I was just bluffing.

[qyot27]

And FFmpeg 4.3 has been released, so there's now actually a fully qualified point release that contains AviSynth+ on *nix support. Hopefully this means more uptake by distributions.

[MysteryX]

It would be good to have a document with clear instructions for plugin developers on how to make it cross-platform compatible.

And for the matters -- cross-platform with support for both Avisynth and VapourSynth should be the standard by now. Anyone wants to write clear instructions on how to achieve that the right way?

[qyot27]

Generally, rather than including avs/win.h, you'd include avs/posix.h (ifdef it). And ideally, use stdint types (int64_t), not the old MSVC ones (__int64). Beyond that, you're dealing with things far more basic to OS differences in how things are coded, not anything specific about the avsplus codebase.

I am mulling the possibility of having a repository solely for a skeleton CMake project so that potential plugin ports can have a jumping off point that lets them build for more than just MSVC.

[ChaosKing]

Originally Posted by MysteryX

It would be good to have a document with clear instructions for plugin developers on how to make it cross-platform compatible.

And for the matters -- cross-platform with support for both Avisynth and VapourSynth should be the standard by now. Anyone wants to write clear instructions on how to achieve that the right way?

"Neo Gradient Mask is the hello-world type of project for dual synth wrapper based source filter."
https://github.com/HomeOfAviSynthPlu..._Gradient_Mask

[MeteorRain]

However please do note dual synth wrapper is still in pretty early stage, and needs to be polished during the time.

I'd love to share permissions on those repos so you can participate in improving it.

Also Gradient Mask is a source filter project. For regular filter examples, minideen or fft3d may be easier to read.

[feisty2]

Well, I think there should be no base class (interface) and no virtual functions, it’s definitely possible since it’s how I designed my vs wrapper. Duck typing (via templates) is easier to the user and provides richer type information as there is no goddamn type erasure. You can introspect a filter type and see which members/behaviors are defined and which are not using requires expressions, and play with lots of dynamic-typing-like magic. And the runtime overhead of virtual functions also gets eliminated

edit: and duck typing is more consistent with the core language design of c++, take range-for syntax for example, it's a duck typing syntax, it's automatically enabled for any type that defined begin() and end(), the type does not need to implement any interface or inherent any base class.

[magiblot]

Is there a list of plugins that are available on Posix platforms? We probably should make one, just like there's one for 64-bit plugins in the wiki.

Originally Posted by feisty2

Well, I think there should be no base class (interface) and no virtual functions, it’s definitely possible since it’s how I designed my vs wrapper. Duck typing (via templates) is easier to the user and provides richer type information as there is no goddamn type erasure. You can introspect a filter type and see which members/behaviors are defined and which are not using requires expressions, and play with lots of dynamic-typing-like magic. And the runtime overhead of virtual functions also gets eliminated

As far as I understand, AviSynth is built without the source code of external filters, and viceversa. How would external filters link against the library?

[feisty2]

Originally Posted by magiblot

As far as I understand, AviSynth is built without the source code of external filters, and viceversa. How would external filters link against the library?

I only developed an API wrapper for vs but I guess the avs API should be more or less the same. the low level vs API consists of a bunch of (pointers to) C functions and obviously there's no inheritance and virtual functions since everything is written in C. so I'm not sure what you're trying to say.

anyways, here, here and here are the snippets that are relevant to exposing the plugin and its filters to vs.

[qyot27]

Originally Posted by magiblot

Is there a list of plugins that are available on Posix platforms? We probably should make one, just like there's one for 64-bit plugins in the wiki.

I'd suggested roughly the same thing a week or so ago (plus CPU arch, since there's fewer that run on ARM at the moment), but AFAIK, the closest we have currently is the result of searching for 'avisynth' on the AUR:
https://aur.archlinux.org/packages/?O=0&K=avisynth
(even though the one ffms2 entry that's labelled as my 'fork' isn't really much of the sort, and it's not really necessary to include it since upstream ffms2 now includes AviSynth+ support on POSIX in the regular autotools build system)

And then figuring it out from which ones are actually for avsplus, rather than the core library or actually for VS.

FluxSmooth-pfmod also added *nix support, and I have a test branch that enables the TimeStretch plugin when building the core. There's probably others.

[MeteorRain]

Not sure if you noticed, but new users probably don't have the permission to create new pages.

We can start copying entries from old external filters to modern external filters, including those that are popular, under active maintenance, or are important and unique.
Old, lack of maintenance filters can be left in the old page just like the old old filters page.

Then we can start adding fields to the table.

== Deband Filters ==

| Name | Description | YV12 | YV16/24 | HBD | Win64 | Linux | macOS | ARM | Download |
| f3kdb | ... | y | y | hacked | y | n | n | n | GitHub |
| Neo f3kdb | ... | y | y | y | ...

[Reel.Deel]

Originally Posted by qyot27

I'd suggested roughly the same thing a week or so ago (plus CPU arch, since there's fewer that run on ARM at the moment), but AFAIK, the closest we have currently is the result of searching for 'avisynth' on the AUR:
https://aur.archlinux.org/packages/?O=0&K=avisynth
(even though the one ffms2 entry that's labelled as my 'fork' isn't really much of the sort, and it's not really necessary to include it since upstream ffms2 now includes AviSynth+ support on POSIX in the regular autotools build system)

And then figuring it out from which ones are actually for avsplus, rather than the core library or actually for VS.

FluxSmooth-pfmod also added *nix support, and I have a test branch that enables the TimeStretch plugin when building the core. There's probably others.

I'll start a page on the wiki if you tell me what to name the page and a few plugins to add (just to start a table like the x64 plugins page).

[qyot27]

Something like 'AviSynth+ plugins' in a general chart (where even the native x64 support could be noted as well), or extend the existing x64 plugins table with a few extra fields to denote OS and CPU architecture, changing the page title as necessary.

The reason it may not all fit under a catch-all page title including a term like POSIX is that Windows for ARM exists, and in the release for 3.6.1 there's a WinARM test build. Not that any plugins have yet been built for that apart from ConvertStacked (because it's in the main AviSynth+ sources). But it is possible as a configuration.

[qyot27]

Note: it's a month old at this point, but there's now a thread to track which plugins have been ported to other OSes and CPU architectures (also in my signature). When I get around to rewriting the first post I'll add the link there, too.

[qyot27]

And with the release of version 3.7, we now support a couple more things: Haiku, and PowerPC CPUs.

Haiku is a re-implementation of BeOS, an OS that had its day in the spotlight in the early-mid 90s as a competitor to Windows and the Classic Mac OS. It's not a Unix-like system like Linux, BSD, or macOS are, but it is largely POSIX compliant and uses Bash as its shell.

PowerPC-wise, the real target here is the potential to use AviSynth+ on Linux or BSD running on the newer (currently POWER9 or POWER10) CPUs, but a side effect is that it can also run on old PPC versions of OSX Tiger and Leopard (with some help). Like the ARM support added in 3.6, PowerPC support is very basic at this point - single-threaded and no AltiVec instructions.