AviSynth plugin hangs on Linux

[SuNNjek]

Hello,

I've noticed that the AviSynth plugin doesn't seem to be working on Linux. When trying to load any .mp4 file with FFmpegSource2 and opening the script with ffplay or ffmpeg the programs just sit there and do nothing.

I've tried on three separate machines (all running Manjaro Linux using the ffms2-git AUR package) and it happens on all three. I've downloaded test files from here and created a script like this:

FFmpegSource2("example.mp4")

A normal test script like

ColorBarsHD()

works fine, so it's not like AviSynth or ffmpeg aren't working on my system.

[qyot27]

This was also reported to AviSynthPlus in https://github.com/AviSynth/AviSynthPlus/issues/194, and at least when I tested it in Ubuntu, the issue wasn't that it doesn't work or hangs, it's that FFmpeg's probing info and progress indicator is somehow suppressed when FFMS2 is used in the script (it also happens on Haiku with a static FFmpeg, so it's not just Linux). But since there's only been a couple of commits on FFMS2's side since building the AviSynth plugin on Linux was added, I'm more inclined to think something in FFmpeg is going sideways when dealing with chainloaded dlopen-ed libraries. I haven't had time to try bisecting it yet, though.

[myrsloik]

Probably an issue with how it was built. Closed.

[jmuchemb]

I had the same issue and the only solution I found was to revert the recent changes in ffmpeg about avisynth.

We're different people, on different OS (Debian here), not following a same how-to: I find hard to conclude it was « an issue with how it was built ».

Are you unable to reproduce ? Note that my main usage is to play .avs files with mpv.

Since then, I didn't try to upgrade anything in my environment, and because of this I understand my comment has little value. But without any progress on the related issues in other projects, I have the feeling the issue is still there.

[myrsloik]

Feel free to experiment with compilation and linker options further and report your findings. Or as suggested bisect a compile with a shared ffmpeg to actually add useful information. If you find the breaking commit things will probably be fixed. I have no idea which changes you're referring to.

[SuNNjek]

I can still reproduce it on Manjaro with latest avisynthplus, ffmpeg and the following AUR package for ffms2 installed: https://aur.archlinux.org/packages/ffms2-git/

It's still affecting people across multiple distros (since @jmuchemb already said it's also happening on Debian), so I also find it a bit weird to just say it's "probably" an issue how "it" (ffms2, ffmpeg, avisynth?) was built. If there is currently no working solution that's ok, but then the issue should stay open since it is very much not resolved.

[jmuchemb]

I have no idea which changes you're referring to.

commit 3158a5dc58aa2c43dac700c24df6b196f3899c44
Author: Julien Muchembled <...>
Date:   Sun Dec 13 18:53:11 2020 +0100

    Revert "compat/avisynth: remove avisynth headers"

    This reverts commit 0c75acb4ce5db623f4c1c2729468e66c3e28ad67.

commit ae34b7c32d1c7ed7e88b5e4d283ae2e67758ee46
Author: Julien Muchembled <...>
Date:   Sun Dec 13 18:52:35 2020 +0100

    Revert "avformat/avisynth: switch to AviSynth+ on Linux"

    This reverts commit 6d8cddd1c67758636843f6a08295b3896c2e9ef8.

    Changelog entry not reverted to avoid Debian multiarch conflict
    if other archs aren't rebuilt.

commit 7ca31046d91ec6a98c915d86451fcc239db505ca
Author: Julien Muchembled <...>
Date:   Sun Dec 13 18:51:44 2020 +0100

    Revert "doc/general: AviSynth+ works on Linux now, AvxSynth is gone."

    This reverts commit 6e959ad680288e34eccb4ee2dd205e4ffa495f95.

commit adfab819bac786794e39a0a9cfb210e5ba4b42d8
Author: Julien Muchembled <...>
Date:   Sun Dec 13 18:51:39 2020 +0100

    Revert "avformat/avisynth: fix deprecation warning"

    This reverts commit 56f59246293de417d27ea7e27cb9a7727ee579fb.

commit 1b0fd17bbd5e07ee1f0fd1c8366d327f0891b317
Author: Julien Muchembled <...>
Date:   Sun Dec 13 18:50:58 2020 +0100

    Revert "doc/general: update avisynth docs with a way to install just the headers using CMake"

    This reverts commit 7b0f7a7f3b6bf09c076c23d0701bf42a2c997ca2.

commit 6b6b9e593dd4d3aaf75f48d40a13ef03bdef9fdb (tag: n4.3.1)
Author: Michael Niedermayer <...>
Date:   Sat Jul 11 00:26:17 2020 +0200

    Changelog: update

    Signed-off-by: Michael Niedermayer <...>

[qyot27]

The problem is the circular dependency between FFMS2 and FFmpeg CLI both depending on the same set of shared libraries when FFmpeg has been built shared and FFMS2 was linked to that shared FFmpeg. Regardless, I have not experienced it actually hanging, only that the probe info and progress are not pushed to stdout and displayed in the Terminal session (the probe info still appears in the output of ffmpeg -report, the output file is still created, FFplay and mpv still play the script back normally).

Solution 1: Build the system FFmpeg as static, link FFMS2 to it as usual. Most distros don't like this idea (read: hate, detest, etc., will flatly refuse to do it), but it works exactly as you would expect it to work. If the distro provides both static and shared versions of the libraries (meaning they don't explicitly pass --disable-static), link FFMS2 against the static ones.

Solution 1.1: Build a minimal version of FFmpeg as static, install it somewhere else on the system (like /opt or somewhere in $HOME), and link FFMS2 against that one using PKG_CONFIG_PATH. Less overtly objectionable, but puts the onus on the user to keep that minimal copy somewhere. FFMS2 doesn't use things like the muxers and encoders anyway, so this option is more tailor-made for what FFMS2 actually requires to function (it's also basically what Windows builds have always done). Because the FFmpeg libraries are static, FFMS2 itself is fine with it, and it never touches the system libraries the CLI uses, so the conflict never appears.

Solution 2: Build a minimal FFmpeg (like in 1.1) as shared, and install it to somewhere else on the system. Link FFMS2 against it using LDFLAGS="-Wl,-rpath-link=/path/to/alternate/ffmpeg" (only so ffmsindex will actually link and the compilation process finishes) and pass LD_LIBRARY_PATH=/path/to/alternate/ffmpeg to the client (FFmpeg) when you open an FFMS2-using script. Same disadvantages as 1.1. Some distros may be more kind about this one, since the libs are shared now, but will probably object to having to use RPATH (Debian would, for sure; as I'm testing on Ubuntu, that may be why using LD_LIBRARY_PATH was necessary; other distros may be okay with it with just RPATH set).

I did just test this one, and it does allow the probe info to appear again.

Solution 3: Bypass the conflict with avs2yuv. Only suitable for video encoding, since avs2yuv doesn't pass audio, and only works with YUV (unless you pass the -raw option, but then you have to ensure the receiving application allows you to set the video properties).

If I had to hazard a guess as to why AvxSynth was not affected by the circular dependency problem (and I'm not really sure that it wasn't, but I don't recall seeing anyone mention it), my gut reaction is that it probably had something to do with the namespace wrapping that was littered all over the AvxSynth code and even crops up in the AvxSynth FFMS2 plugin sources. Declaring the AvxSynth FFMS2 plugin as being under the avxsynth namespace (which FFmpeg had no knowledge of in the demuxer, mind you) doesn't feel like it should have stopped duplicate versions of libavcodec, et al, from colliding, but maybe that was what did it.

[myrsloik]

Obviously FFMS2 can't be the one to drop the dependency either...

[AlexFolland]

The hang when using the FFMS2 function in AviSynth+ affects me on Manjaro with the latest ffms2, ffmpeg, and avisynthplus packages with default configurations.

'justtheclip (copy).avs' file contents

``` source = FFMS2("/run/media/alex/everything/media/video/capture/rawcap/cactus 2017-02-01 18-18-30-705.avi") Trim(source, 85983, 0) ```

ffplay terminal output

``` [alex@alex-pc rawcap]$ ffplay -i 'justtheclip (copy).avs' ffplay version n5.0 Copyright (c) 2003-2022 the FFmpeg developers built with gcc 11.2.0 (GCC) configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librav1e --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-nvdec --enable-nvenc --enable-shared --enable-version3 libavutil 57. 17.100 / 57. 17.100 libavcodec 59. 18.100 / 59. 18.100 libavformat 59. 16.100 / 59. 16.100 libavdevice 59. 4.100 / 59. 4.100 libavfilter 8. 24.100 / 8. 24.100 libswscale 6. 4.100 / 6. 4.100 libswresample 4. 3.100 / 4. 3.100 libpostproc 56. 3.100 / 56. 3.100 nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0 ```

Can this be reopened? As SuNNjek said, this issue affects multiple people, even with default configurations. Even if compilation was "wrong" somehow, maybe the compilation system could be fixed to not be able to be wrong or something like that. I'm not sure what the real solution is, but my point is that this is a valid issue that needs addressing. Even if not fixed immediately, acknowledgement in an open issue ticket instead of a closed one would be helpful for others who were in the same situation and found only this closed ticket referencing the observed behavior.

[SuNNjek]

@AlexFolland In case you need a workaround, you can compile ffmpeg statically yourself with [...] --enable-static --disable-shared --prefix=/home/.../ffmpeg. By passing the script to the statically compiled ffmpeg the deadlock can be avoided.