Segfault on Launch After Successful Build on macOS arm64 (M1 iMac)

[Cee-JayM13]

1. Environment:

• Hardware: M1 iMac (arm64)
• OS: macOS Tahoe 26.1
• Rust: rustc 1.91.1 (ed61e7d7e 2025-11-07)
• Cargo: cargo 1.91.1 (ea2d97820 2025-10-10)
• Python: Homebrew Python 3.14.2 [main] // pyenv Python 3.12.12 (framework build) [tested, result was unsuccessful]
• VapourSynth: R73 (installed via Homebrew → "build install --build-from-source vapoursynth" [Note: The default "brew install vapoursynth" Homebrew VS R73 installation has also been tested & similarly encounters the same following issue(s)]
• Homebrew: Homebrew 5.0.4-68-g70badad // Homebrew/homebrew-core (git revision a9f969c41ca; last commit 2025-12-07)
• av1an: Cloned from main branch (v0.5.0 or latest commit)
• Other deps: ffmpeg (Homebrew), innumerable Homebrew-installed libraries for video processing

All components are arm64-native (confirmed via file on binaries and dylibs).

2. Reproduction Steps:

brew install vapoursynth python@3.14 ffmpeg
git clone https://github.com/rust-av/Av1an.git
cd Av1an

Required for linking on macOS (otherwise undefined vsscript* symbols)_

mkdir -p ~/.cargo && cat > ~/.cargo/config.toml <<EOF
[target.aarch64-apple-darwin]
rustflags = ["-C", "link-arg=-undefined", "-C", "link-arg=dynamic_lookup"]
EOF

cargo build --release
./target/release/av1an --version → immediate segfault (zsh: segmentation fault)

3. Issue Description:

I've been attempting to build and run av1an on my M1 iMac for roughly the last ~two weeks; initially failures were primarily centered on compilation errors (ex. linking issues, "ld: symbol(s) not found for architecture arm64" errors & vsscript issues). After extensive troubleshooting (including mostly failed DIY patches, shim.c files, attempts at creating various build.sh scripts with patches contained within, etc. I ultimately ended up creating a custom ~/.cargo/config.toml file [to which I attribute my minimally made progress towards - in furtherance of obtaining a fully functional, feature-complete arm64 M1 iMac compatible av1an executable]), I can now successfully compile the executable without errors. However, it segfaults immediately on launch, even for basic commands like path/to/av1an --version. No output is produced since the process crashes before loading anything meaningful.

4. Past attempts (pre-successful build):

• Frequent (99%+) failure rate during cargo build, often resulting from arm64-specific linking errors with vapoursynth-sys or pyo3.
• The rare successeful av1an executable builds required manual patches/shims, but the resulting binary was unusable (i.e. wouldn't execute at all).

Current state (post-successful build):

• Build completes in ~2-4 minutes depending on clean/rebuild/background programs running.
• Binary is created at target/release/av1an (arm64, confirmed).
• Segfaults on any form of invocation: ex. zsh: segmentation fault /path/to/av1an --version
• Standalone Python tests (ex. importing vapoursynth) work perfectly.
• Disabling VapourSynth plugins (mv /opt/homebrew/lib/vapoursynth /opt/homebrew/lib/vapoursynth.disabled) does not prevent the crash, suggesting it's not a plugin issue.
• LLDB backtraces show the crash in libvapoursynth-script.0.dylib during vapoursynth::script::Environment::create() (environment.cpp:49), with EXC_BAD_ACCESS (null pointer dereference). Example backtrace:

  * frame #0: 0x0000000104e9f0a4 libvapoursynth-script.0.dylib`vapoursynth::script::Environment::create(this=0x000000016b4e1d00) at environment.cpp:49:18
    frame #1: 0x0000000104e9ef7c libvapoursynth-script.0.dylib`vapoursynth::script::Environment::Environment(this=0x000000016b4e1d00) at environment.cpp:25:5
    [truncated; full backtraces show Python C API calls leading to this]
  

• otool -L on the av1an binary shows correct links, ex.:

  /Users/Cee-JayM13/Av1an/target/release/av1an:
    /opt/homebrew/opt/vapoursynth/lib/libvapoursynth.dylib (compatibility version 0.0.0, current version 0.0.0)
    /opt/homebrew/opt/vapoursynth/lib/libvapoursynth-script.0.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
  

• otool -L on vapoursynth.abi3.so confirms links to Homebrew libs.

5. Troubleshooting:

• Performed av1an build tests with venvs and pyenv framework Python 3.12.x to align build/runtime interpreters - no success.
• Set PYTHON_SYS_EXECUTABLE during build to match runtime Python - no success.
• Verified architectures (all arm64) and paths (ex. site-packages, dylibs in /opt/homebrew/lib) - to no avail regardless.
• Tested DYLD_LIBRARY_PATH and DYLD_FRAMEWORK_PATH workarounds (ex. export DYLD_LIBRARY_PATH="/opt/homebrew/opt/vapoursynth/lib"), but segfault annoyingly persists.
• Checked for ABI mismatches, outdated wheels, or missing dylibs - none apparent.
• Extensive debugging with LLDB, otool, and file commands; standalone VapourSynth works.

6. Suspected Points of Failure (Summarized):

Through extensive troubleshooting including repeated LLDB sessions, detailed crash backtraces, runtime analysis, reviewing of terminal build logs supplemented by AI-assisted interpretation/result summarization & targeted research on Stack Overflow & related Rust/macOS forums, the following represent what I believe are the most likely root causes of the immediate segfault on launch:

• 1.) Outdated PyO3 in Dependency Tree: The av1an dependency, vapoursynth-rs (v0.4.1), relies on an older version of PyO3 (likely ~0.17.x). PyO3 versions prior to 0.18+ are known to contain bugs that cause segfaults during Python embedding on macOS arm64, typically during interpreter initialization or module imports.

• 2.) VapourSynth Script Library Crash: The crash consistently appears to happen deep inside libvapoursynth-script during the Environment::create() call. This strongly suggests a failure in the C++/Python bridge's initialization, possibly due to arm64-specific symbol or ABI mismatches that are not caught at build time.

• 3.) macOS Framework Strictness: The arm64 ecosystem on macOS is notoriously strict regarding framework builds (like those from pyenv or Homebrew). The dynamic linker (Dyld) seems to be failing to correctly resolve the embedded Python paths within the av1an binary, leading to null pointers when VapourSynth tries to create its scripting environment.

Unfortunately, I am nowhere near experienced enough to dive deeper into the code than I already have. I've been DIY troubleshooting this for over a week, and while I finally won the battle to get it built, getting it to actually link and execute properly has proven to be outside my capabilities. From the poking & prodding around I've done and from what I've learned online, the information points toward a compatibility bug in the embedding stack rather than simple user error, likely due to the strictness of the macOS arm64 environment. I suspect, perhaps, that the project just hasn't had adequate testing on this specific platform recently.

I’d appreciate any guidance (if currently possible) on meaningful ways to get av1an up and running with full VS compatibility and support on my system architecture/OS. At the very least, I wanted to get this problem out into the public conciousness and hopefully heard by someone with more knowledge, know-how & most crucially -> the means to actively create a permanent fix(es)/solution(s) to this problem. Thanks for reading!

[Uranite]

Av1an is currently incompatible with VapourSynth R73, please use VapourSynth R72 instead.

[Cee-JayM13]

VapourSynth R73 is currently incompatible with Av1an, please use VapourSynth R72 instead.

Will perform some testing and get back with you. Oddly enough, when I reinstalled VapourSynth via Homebrew the other day, I noticed the version was actually indeed R72. That's odd, since I'm fairly confident these errors above were encountered even with VS R72.

Edit: It appears I must've incorrectly gone about obtaining VapourSynth R72 the first time around, most likely due to the fact I was simultaneously both creating a custom tap for the first time as well as performing (in hindsight) completely unnecessary & irrelevant nonsense that ultimately lead to me pushing my (disfunctional) tap of VS R72 onto Github here as a repository; it still didn't even work after that [User Error].

Thanks for the help! Tthe easiest solution is sometimes the last thing on one's mind.

Edit 2: Unfortunately I'm finding myself encountering a sigsev error again, even with VS R72... It's been finicky both with VS R72 and VS R73 on my system unfortunately. I'll come back on tomorrow woth more detailed information and can hopefully solve this issue once and for all.

[Line-fr]

I get this exact bug on my ubuntu if I use av1an without my python venv in which I did pip install vapoursynth
Did you use pip install vapoursynth?

[windigerbus]

I get this exact bug on my ubuntu if I use av1an without my python venv in which I did pip install vapoursynth Did you use pip install vapoursynth?

i had the same issue because i had installed the r73 bindings from pip but used the r72 libraries, might have to use pip install vapoursynth==72

[Cee-JayM13]

I get this exact bug on my ubuntu if I use av1an without my python venv in which I did pip install vapoursynth Did you use pip install vapoursynth?

Yes, sir, I did indeed. That said however, I would take my findings from that specific test with a grain of salt for now. I hesitate to make a definitive claim because I now believe I was unknowingly testing av1an inside a Python venv in which I had installed VS R73 via pip, while simultaneously (and unknowingly) having VS R73 installed via Homebrew. As if that weren't reason enough to question my test results, I was also performing all of the following while using a Homebrew pyenv Python 3.12.12 framework build & therefore cannot make any conclusive claim(s) as to what, if any role specific Python version(s) contribute to my current issue(s).

I’ll re-run the experiment in a clean environment but this time using my system-wide Homebrew Python 3.14.2 (not pyenv) and likewise ensure to specifically install the VapourSynth R72 bindings via pip, which should more closely mirror the situation you described on Ubuntu while simultaneously testing the added information provided by windigerbus. I’m somewhat of the belief the results will be reproducible across macOS and Linux since both are Unix-like (although I'll be the first to admit I'm not in any way, shape or form savvy enough in any relative/tangentially-related sense to make any definitive claims on the topic). My aim in laying out these details is to give y'all, and any Av1an developers who may or may not find themselves reading this, useful context that might help reproduce the issue or, if someone with the necessary access finds it, implement a permanent fix. I’ll post the retest results here later tonight when I get around to performing them.

[Cee-JayM13]

After a fair bit of configuring on my end including appropriate & proper (re)formatting of my system's ~/.zshrc contents to ensure VS 72 can access the necessary Python version it needs (while also ensuring each individual system-wide program has access to it's uniquely required Python version),...:

# -------------------------
# Python & VapourSynth Setup
export PATH="/opt/homebrew/opt/python@3.13/bin:$PATH"
export PYTHONPATH="/opt/homebrew/Cellar/vapoursynth/72/lib/python3.13/site-packages${PYTHONPATH:+:$PYTHONPATH}"
export VAPOURSYNTH_PLUGIN_PATH="$HOMEBREW_PREFIX/lib/vapoursynth"

# Try functions instead of aliases
python3() { /opt/homebrew/opt/python@3.13/bin/python3 "$@"; }
pip3()    { /opt/homebrew/opt/python@3.13/bin/pip3    "$@"; }
python()  { /opt/homebrew/opt/python@3.13/bin/python3 "$@"; }
pip()     { /opt/homebrew/opt/python@3.13/bin/pip3    "$@"; }
vspy()    { /opt/homebrew/opt/python@3.13/bin/python3 "$@"; }

# Make Python 3.14 still available if/when I explicitly want it
if [ -x "/opt/homebrew/opt/python@3.14/bin/python3" ]; then
  python314() { /opt/homebrew/opt/python@3.14/bin/python3 "$@"; }
  pip314()    { /opt/homebrew/opt/python@3.14/bin/pip3    "$@"; }
fi

...performing VS plugin rebuilding when explicitly necessary, testing all of my pre-existing plugins for VS R72 functionality & arm64 compatibility & finally - upon confirming that my VapourSynth is indeed VapourSynth 72 and that both av1an and VS are fully functioning (av1an can properly perform a standard AV1 encode* [*with --photon-noise]) & x265 encode with typical, default non-av1an exclusive encoding settings), I now am running into a new, unique error.

Return of the Target Quality sigsev Error & Encoder Bit-Depth Misconfiguration Error

• Preface: My current av1an --version output:

xxxxxxx@Cee-JayM13's-iMac ~ % av1an --version

av1an 0.5.0-unstable (rev 93b4948) (Release)

* Compiler
  rustc 1.91.0-nightly (LLVM 21.1)

* Target Triple
  aarch64-apple-darwin

* Date Info
  Commit Date:  2025-12-08

* VapourSynth Plugins
  systems.innocent.lsmas : Not found
  com.vapoursynth.ffms2  : Found
  com.vapoursynth.dgdecodenv : Not found
  com.vapoursynth.bestsource : Found
  com.julek.plugin : Not found
  com.julek.vszip : Found
  com.lumen.vship : Not found

* Available Encoders
  aomenc  : AOMedia Project AV1 Encoder 3.13.1
  SVT-AV1 : SVT-AV1-HDR v3.1.3-1-g83568e10b (release)
  rav1e   : rav1e 0.8.1 () (release)
  x264    : x264 0.165.3223 0480cb0
  x265    : HEVC encoder version 4.1+211-9e551a994
  vpxenc  : Not found

The following includes the specific AV1 encoder used with av1an as well as the encoder's/av1an's settings (other encoding commands have been tested with differing settings but all suffer the same sigsev & chunk error due to incorrect bit-depth [& I'm sure other unseen error(s) as well - knowing my luck]):

• Encoder: SVT-AV1 : SVT-AV1-HDR v3.1.3-1-g83568e10b (release)

• --target-quality ssimulacra2 → Currently the only target quality metric I care to perform target quality encoding for... sans Butteraugli (unfortunately my most recent attempt with the VS julek plugin proved unsuccessful for some unknown, long-forgotten reason)

• Encoding Command:

av1an \
  -i input.mkv \
  -o output.mkv \
  -e svt-av1 \
  -w 4 \
  --split-method av-scenechange \
  -x 300 \
  --chunk-method ffms2 \
  -f "-vf libplacebo=deband=1:deband_iterations=2:deband_threshold=3.75:deband_radius=14:deband_grain=6.0:dithering=blue:dither_temporal=1" \
  -c mkvmerge \
  --no-defaults \
  --ignore-frame-mismatch \
  --photon-noise=5 \
  --chroma-noise \
  --photon-noise-width=1920 \
  --photon-noise-height=1080 \
  --pix-format yuv420p10le \
  --video-params "--preset 2 --crf 32.5 --input-depth 10 --rc 0 --irefresh-type 2 --tune 0 --enable-overlays 1 --aq-mode 2 --variance-boost-strength 3 --variance-boost-curve 1 --variance-octile 5 --keyint -1 --enable-cdef 0 --enable-restoration 1 --lookahead 48 --enable-tpl-la 1 --qm-min 5 --qm-max 12 --luminance-qp-bias 50 --chroma-qm-min 10 --chroma-qm-max 15 --enable-dlf 2 --qp-scale-compress-strength 2 --enable-tf 2 --color-primaries 1 --transfer-characteristics 1 --matrix-coefficients 1 --color-range 0 --complex-hvs 1 --noise-norm-strength 3 --ac-bias 1.35 --tx-bias 1 --hbd-mds 1" \
  --target-metric ssimulacra2 \
  --target-quality 82-84 \
  --probe-video-params "--preset 4 --crf 32.5 --input-depth 10 --rc 0 --irefresh-type 2 --tune 0 --enable-overlays 1 --aq-mode 2 --variance-boost-strength 3 --variance-boost-curve 1 --variance-octile 5 --keyint -1 --enable-cdef 0 --enable-restoration 1 --lookahead 48 --enable-tpl-la 1 --qm-min 5 --qm-max 12 --luminance-qp-bias 50 --chroma-qm-min 10 --chroma-qm-max 15 --enable-dlf 2 --qp-scale-compress-strength 2 --enable-tf 2 --color-primaries 1 --transfer-characteristics 1 --matrix-coefficients 1 --color-range 0 --complex-hvs 1 --noise-norm-strength 3 --ac-bias 1.35 --tx-bias 1 --hbd-mds 1" \
  --qp-range 30-35 \
  --probes 6 \
  --probing-stat percentile=15 \
  --interp-method quadratic-natural

• Constant, Reproducible Error(s):

00:00:15 [0/50 Chunks] ▐                      ▌   0% 0/5361 (0 fps, eta unknown)ERROR [chunk 1] Target Quality failed after 3 tries on chunk 1:
encoder crashed: signal: 11 (SIGSEGV)
stdout:

stderr:
        Svt[info]: -------------------------------------------
        Svt[info]: SVT [version]:	SVT-AV1-HDR Encoder Lib v3.1.3-1-g83568e10b "Cyclonus"
        Svt[info]: SVT [build]  :	Apple LLVM 17.0.0 (clang-1700.4.4.1)	 64 bit
        Svt[info]: LIB Build date: Dec  8 2025 01:07:14
        Svt[info]: -------------------------------------------
        Svt[info]: Level of Parallelism: 4
        Svt[info]: Number of PPCS 148
        Svt[info]: [asm level on system : up to neon_dotprod]
        Svt[info]: [asm level selected : up to neon_dotprod]
        Svt[info]: -------------------------------------------
        Svt[info]: SVT [config]: main profile	tier (auto)	level (auto)
        Svt[info]: SVT [config]: width / height / fps numerator / fps denominator 		: 1920 / 1080 / 24000 / 1001
        Svt[info]: SVT [config]: bit-depth / color format 			: 8 / YUV420
        Svt[info]: SVT [config]: preset / tune / pred struct 			: 4 / VQ / random access
        Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type 	: 0 / 32 / key frame
        Svt[info]: SVT [config]: BRC mode / rate factor 			: CRF / 32.50 
        Svt[info]: SVT [config]: AQ mode / Variance Boost strength / octile / curve 		: 2 / 3 / 5 / 1
        Svt[info]: SVT [config]: sharpness / luminance-based QP bias 		: 1 / 50
        Svt[info]: SVT [config]: Temporal Filtering strength			: auto
        Svt[info]: SVT [config]: QP scale compress strength 			: 2.00
        Svt[info]: SVT [config]: AC Bias Strength / TX Bias 			: 1.35 / full
        Svt[info]: SVT [config]: Noise Normalization Strength 			: 3
        Svt[info]: -------------------------------------------
        Encoding          
source pipe stderr:

ERROR [chunk 0] Target Quality failed after 3 tries on chunk 0:
encoder crashed: signal: 11 (SIGSEGV)
stdout:

stderr:
        Svt[info]: -------------------------------------------
        Svt[info]: SVT [version]:	SVT-AV1-HDR Encoder Lib v3.1.3-1-g83568e10b "Cyclonus"
        Svt[info]: SVT [build]  :	Apple LLVM 17.0.0 (clang-1700.4.4.1)	 64 bit
        Svt[info]: LIB Build date: Dec  8 2025 01:07:14
        Svt[info]: -------------------------------------------
        Svt[info]: Level of Parallelism: 4
        Svt[info]: Number of PPCS 148
        Svt[info]: [asm level on system : up to neon_dotprod]
        Svt[info]: [asm level selected : up to neon_dotprod]
        Svt[info]: -------------------------------------------
        Svt[info]: SVT [config]: main profile	tier (auto)	level (auto)
        Svt[info]: SVT [config]: width / height / fps numerator / fps denominator 		: 1920 / 1080 / 24000 / 1001
        Svt[info]: SVT [config]: bit-depth / color format 			: 8 / YUV420
        Svt[info]: SVT [config]: preset / tune / pred struct 			: 4 / VQ / random access
        Svt[info]: SVT [config]: gop size / mini-gop size / key-frame type 	: 0 / 32 / key frame
        Svt[info]: SVT [config]: BRC mode / rate factor 			: CRF / 32.50 
        Svt[info]: SVT [config]: AQ mode / Variance Boost strength / octile / curve 		: 2 / 3 / 5 / 1
        Svt[info]: SVT [config]: sharpness / luminance-based QP bias 		: 1 / 50
        Svt[info]: SVT [config]: Temporal Filtering strength			: auto
        Svt[info]: SVT [config]: QP scale compress strength 			: 2.00
        Svt[info]: SVT [config]: AC Bias Strength / TX Bias 			: 1.35 / full
        Svt[info]: SVT [config]: Noise Normalization Strength 			: 3
        Svt[info]: -------------------------------------------
        Encoding          
source pipe stderr:

As it clearly shows in the above included stderr: ... Svt[info], although all of my personal settings are clearly set for 10-bit encoding (albeit they somehow revert to 8-bit somewhere between my hitting the Enter key and the program initalizing), & despite the fact that the particular encoding command in totality takes advantage of a pre-existing, personally tested formatting structure within which are included target quality/metric settings/parameters which have been successfully employed countless times before in the past on my very same system, av1an currently cannot perform any target quality encoding on my macOS arm64 iMac M1 system.

Any help tackling this new hurdle would be greatly appreciated!