ffmpeg now building with AviSynth+ rather than AviSynth

[hydra3333]

Of interest, I see that around 5 April, a few ffmpeg source commits deprecated building an ffmpeg.exe with AviSynth and instead now requires headers for AviSynth+.

https://git.videolan.org/?p=ffmpeg.git;a=shortlog

It broke not-yet-updated building processes of course, however with a few trivial changes to the build process to cater for the required new headers, ffmpeg seems to at least build.

Has anyone had any experience with running the updated feature ?

[qyot27]

It didn't deprecate building with AviSynth in favor of AviSynth+. It's been using AviSynth+'s headers for the last several years, because there would have been no other way for it to support the new high bit depth, YUV+alpha, or planar RGB(A) formats if it didn't (the headers are backward compatible, so 2.6 didn't/doesn't care). It did, however, remove AvxSynth support in favor of using AviSynth+, but that only applies to non-Windows OSes.

What happened is that FFmpeg had never been too happy with the AviSynth headers supplied in compat. They were in there mostly because of the historical issues with procuring the headers in a cross-build environment. AvxSynth, being a Linux project, had an autotools-based build system that properly installs its headers when it's built. But because classic AviSynth was built with MSVC solutions/projects and paid no attention at all to the conventional Unix directory layout (why would it?), it meant users would have to go spelunking around in the FilterSDK or in the CVS repository to get them, and make sure they were copied to the correct spot. Since that was an undue burden, and because the old AviSynth demuxer didn't require any headers outside of the ones supplied by MinGW, the headers were allowed to be in compat/ so that users wouldn't have to go searching. And AvxSynth's were supplied alongside them because it would have been weird to allow for compat/ for the feature when built for Windows but not anywhere else. Fast-forward a few years, and AviSynth+ had both a CMake-based build system which supported doing FHS-aware installs, and thanks to it gaining GCC compatibility in 2016, could also be cross-compiled (although Win32/GCC builds of AviSynth+ are...a bit special).

But there were complaints about this every so often on the FFmpeg-devel mailing list. Generally, the expectation was that when AviSynth+ gained cross-platform support (which it did publicly at the beginning of March this year), and therefore would be able to install the headers just like any other project that adheres to the conventional layout, then the compat headers could be removed and it would start to rely on the headers supplied by upstream (which also means the headers would be more up-to-date as well, instead of having to periodically update the ones in compat).

So when the patches to make sure we could use AviSynth+ on Linux, macOS, and BSD were submitted, the compat headers had to go. On non-Windows, using AviSynth+ instead of AvxSynth is a major upgrade, because AvxSynth was a bit decrepit even when it was new, having been based on 2.5.8 instead of the current state of 2.6, and it disabled a bunch of stuff internally because of the limitations of some of the code (all the assembly was disabled, and the resizers were actually dependent on the FFMS2 AvxSynth plugin to function instead of being internal). AviSynth+ rewrote all of that stuff just as part of modernizing it on Windows, and that made the code more portable. So AviSynth+ on non-Windows has all of the intrinsics, its own internal resizers, and there were very few parts of the code that had to be handled specially for Linux, macOS, or BSD - most of it was already prepped and ready because of the GCC compatibility work.

On Windows, it's just a matter of making sure you install the headers first using CMake or the GNUmakefile. There is no difference in features (as of right now).

[hydra3333]

That was a really interesting view of it, thanks !