Log in

View Full Version : Vapoursynth on Mac (ARM), setup?


Selur
11th November 2024, 21:01
Can anyone in detail describe how to setup Vapoursynth on MacOS for ARM?

Is using brew the recommended way to install Vapoursynth?
Should one use vsrepo to install plugins?
(doesn't seem like brews Vapoursynth install comes with vsrepo)
Any step-by-step for n00bs on how to get this working?

Cu Selur
:stupid:

Myrsloik
12th November 2024, 12:24
Can anyone in detail describe how to setup Vapoursynth on MacOS for ARM?

Is using brew the recommended way to install Vapoursynth?
Should one use vsrepo to install plugins?
(doesn't seem like brews Vapoursynth install comes with vsrepo)
Any step-by-step for n00bs on how to get this working?

Cu Selur
:stupid:

Brew is the easiest way by far and as such probably what I'd recommend. Vsrepo has experimental support I haven't even tried myself so the rest (any plugin/editor not in brew) you'll have to compile manually.

Have fun

Selur
12th November 2024, 19:18
Thanks for the info. :)

yuygfgg
13th November 2024, 16:14
I do a lot of encoding with Vapoursynth on Apple Silicon Macs. You can find some of the plugins I’ve ported (or just built) in this repository: https://github.com/yuygfgg/Macos_vapoursynth_plugins.

These plugins are built on an M2 Pro CPU, so they may not work on M1 (not sure), and they don’t use SVE on M4.

A few tips:

std.Expr is slow on non-x86 platforms; akarin.Expr (LLVM-based) performs better.
sse2neon.h and the Simde library can help port almost all SIMD code to ARM, which is crucial for certain plugins (e.g., BM3DCPU).
KNLM compiles and runs without errors or warnings, but the output is broken, so it’s better to use nlm_ispc.
vsmlrt’s ort_coreml sometimes crashes on large clips (≥1080p) and keeps generating files in a directory, so you’ll need to manually clean them up.

You may also want to translate SSE routines inside vapoursynth, but I modified the VS-C fork and found hardly any improvement and it's probably the same in upstream.

amayra
13th November 2024, 17:26
we need a new plug-in system that run in every architecture and platforms

but i don't think this is possible with one developer for rewriting code and complexity of this task

Selur
16th November 2024, 20:21
@yuygfgg: dependencies of the plugins in your repository seem to be broken (created an issue entry over @github)
=> got an answer on github (https://github.com/yuygfgg/Macos_vapoursynth_plugins/issues/2).
(read https://github.com/yuygfgg/Macos_vapoursynth_plugins/blob/main/.github/workflows/main.yml)

Julek
25th November 2024, 14:37
You can get a faster boxblur and bilateral by compiling vszip plugin (https://github.com/dnjulek/vapoursynth-zip), Zig can generate SIMD for ARM natively.

Selur
25th November 2024, 18:43
Does it work with zig 0.13.0 (this is the version homebrew offers) ?
( ran into that with zsmooth (https://github.com/adworacz/zsmooth/issues/2))

Julek
25th November 2024, 18:50
Does it work with zig 0.13.0 (this is the version homebrew offers) ?
( ran into that with zsmooth (https://github.com/adworacz/zsmooth/issues/2))
just download the executable from the site:
https://ziglang.org/download/

zig-macos-aarch64-0.14.0-dev.2293+6d781e095.tar.xz

And run this:

git clone https://github.com/dnjulek/vapoursynth-zip
cd ./vapoursynth-zip
PATH-TO/zig-macos-aarch64-0.14.0-dev.2293+6d781e095/zig build -Doptimize=ReleaseFast


vszip always uses the latest zig-master version

Selur
26th November 2024, 19:11
vszip always uses the latest zig-master version
good to know. Should it also work with 0.13.0 ?

Adub
27th December 2024, 16:55
Just FYI - I'm going to look into building binaries for Mac for Zsmooth going forwards, which removes the need for consumers to care about specific Zig versions. I already do this for my Windows DLL builds today.

This will all be part of a refactor to use Github Workflows to autobuild everything when I make releases.

It will likely be a month or two, since I'm finishing up some projects with work, but after that I'll have a lot more time on my hands.

Selur
27th December 2024, 17:03
Thanks for the info. :)

Selur
30th December 2024, 12:13
Anyone has an idea how to build d2vsource and d2vwitch for Apple Silicon?

Selur
8th February 2025, 11:02
Does anyone have build instructions how to build https://github.com/sekrit-twc/timecube.git on MacOS (silicon) or an alternative filter that can be built on MacOS, which can be used to apply LUTs?

elcoyote
14th February 2025, 23:12
Does anyone have build instructions how to build https://github.com/sekrit-twc/timecube.git on MacOS (silicon) or an alternative filter that can be built on MacOS, which can be used to apply LUTs?

I managed to modify the makefile and compile it. Tested with a .cube file and it seems to do what it's supposed to. It's not very fast, though.

elcoyote
14th February 2025, 23:21
btw, here's the modified makefile.

I also had to download the vsxx and graphengine and fill in the files manually since they don't get downloaded with "git clone ..."

Selur
15th February 2025, 08:13
Thanks, I can confirm that vscube works fine here. :) (MacOS 15.3.1, M4 pro)

elcoyote
15th February 2025, 19:11
I'm pretty noob/unconfident with Github. For posterity and to help other fellow mac vapoursynth users, what should I do to preserve the macOS arm64 "buildability"?

- Post an issue in timecube's repo and ask the dev to integrate macOS in the makefile?
- Create a Pull Request?

Thanks

LoRd_MuldeR
15th February 2025, 20:23
I'm pretty noob/unconfident with Github. For posterity and to help other fellow mac vapoursynth users, what should I do to preserve the macOS arm64 "buildability"?

- Post an issue in timecube's repo and ask the dev to integrate macOS in the makefile?
- Create a Pull Request?

Thanks

Fork the original repo → commit your changes into your own fork → create a pull request to get your changes integrated into upstream.

Selur
15th February 2025, 20:25
imho a pull request might be the better approach, but if the change really small an issue entry usually is fine too :)

elcoyote
16th February 2025, 20:24
Thanks for the help. Unfortunately, after a lot of fiddling I can't compile the windows version (the original, not my fork), so I can't be sure that the modified makefile works for windows. What's funny is that linux and macOS versions compile effortlessly. So I guess I would keep my fork and won't pull request.

https://github.com/grosbecyk/timecube