"Unknown error occurred" when using Avisynth+ on Linux

[seankhl]

I followed the posix compilation directions for installing Avisynth+ and a corresponding ffmpeg build but ran into this problem that using ffplay (or ffmpeg) with any avs script (including Version() etc) results in the following message:

test.avs: Unknown error occurred

The compilation of both Avisynth+ and ffmpeg both went fine. I'm using gcc 9.3.0 and I'm running Void Linux. When I searched for the error some 32-bit vs 64-bit incompatibility problems came up, but as I compiled both by hand, I can't imagine that this is the same problem. Hopefully it's just something silly I'm overlooking. Please let me know what info I can provide to help debug this.

[qyot27]

My first guess would be it's something about the ld path. I don't have any experience with Void so I don't know if there's any particulars around install path or the ld cache. The easiest way to test that would be to try

LD_LIBRARY_PATH=/path/to/avsplus/install ffmpeg -i test.avs

Since if it's something like that, LD_LIBRARY_PATH will force it to be able to find libavisynth.so.

[qyot27]

Also, this brings to mind that I probably need to mention in the docs that Linux users that opt not to use checkinstall will need to follow [make|ninja] install with ldconfig.

[qyot27]

Another possibility, and I mention this only because I've encountered it recently, is that sometimes the install process doesn't seem to want to install or update the libavisynth.so symlink that's supposed to exist in the install directory. FFmpeg looks for 'libavisynth.so' in order to load it, and if it's missing, it won't be able to find AviSynth+ and throw a message like that one.

But I've never encountered it in a fully-reproduceable way so as to actually figure out if there's an issue with the CMakeLists.txt install routines or if it lies elsewhere.

[SuNNjek]

I have the same problem, however this only occurs on the newest version of FFmpeg. Here are the two outputs:

The version that still works:

ffplay version N-97830-gb707abf091 Copyright (c) 2003-2020 the FFmpeg developers
  built with gcc 10.1.0 (GCC)
  configuration: --enable-avisynth --enable-libx264 --enable-libx265 --enable-gpl --enable-version3 --prefix=/home/robin/ffmpeg_avisynth3
  libavutil      56. 46.100 / 56. 46.100
  libavcodec     58. 84.100 / 58. 84.100
  libavformat    58. 43.100 / 58. 43.100
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 81.100 /  7. 81.100
  libswscale      5.  6.101 /  5.  6.101
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Input #0, avisynth, from 'test.avs':KB vq=    0KB sq=    0B f=0/0   
  Duration: 00:15:03.43, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 60 fps, 60 tbr, 60 tbn, 60 tbc
  11.38 M-V:  0.009 fd=  10 aq=    0KB vq=15188KB sq=    0B f=0/0

Using the newest git tag I get this:

ffplay version n4.2.3 Copyright (c) 2003-2020 the FFmpeg developers
  built with gcc 10.1.0 (GCC)
  configuration: --enable-avisynth --enable-libx264 --enable-libx265 --enable-gpl --enable-version3 --prefix=/home/robin/ffmpeg_avisynth2
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
test.avs: Unknown error occurred
    nan    :  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

[qyot27]

4.2.3 is not 'new' (in the sense we need) and does not contain the changes needed for AviSynth+ on non-Windows. It's a maintenance release of the 4.2 branch, which stopped main development in August 2019. What 4.2.3 expects on non-Windows is AvxSynth, not AviSynth+.

4.3 will be the first point release to have the AviSynth+-on-*nix support. Whenever it gets released.

[qyot27]

Revisiting this once again (also, for posterity, FFmpeg 4.3 was released about a month ago), I think I may have stumbled onto a possible source of the original issue reported here.

I was testing Adélie Linux in a QEMU (ppc) VM so that I could see what worked/didn't on big endian, and despite both AviSynth+ and FFmpeg compiling successfully for the test, neither FFmpeg nor the Linux port of avs2yuv could open it, and failed early: during the library load phase. libavisynth.so was installed correctly, so that wasn't it. I didn't know if maybe it was something about big endian (I mean, there still might be), but then I found this list of differences between musl-libc and glibc:

https://wiki.musl-libc.org/functional-differences-from-glibc.html

In this summary, there are things directly related to atexit constructors/destructors (which FFmpeg uses during the libavisynth.so load phase), as well as more broadly with dlclose being a no-op under musl. These things, separately or together, might be the real problem. AFAIK, Void can use either musl or glibc, and it very well could be that the tactics to dlopen libavisynth.so in these two client programs are causing problems with musl-based setups.