|
The decision to drop support for anything below 2.6 RC1 was due to catastrophic header incompatibilities between 2.5 and 2.6 RC1* and the maintenance burden (and potential licensing minefield that could mean any additional 2.5 support would violate GPL) that would be incurred by trying to continue to support 2.5 while using properly updated 2.6 headers.
*technically, between 2.6a5 and RC1 too.
The gory details:
2.6 RC1 changes several functions in avisynth_c.h from AVSC_INLINE to AVSC_API, functions that libavformat's AviSynth demuxer uses. These changes mean that using the up-to-date version of the header from either classic or Plus would cause libavformat's AviSynth demuxer to fail compilation. The only solution was to change those standalone calls into struct-sourced calls from LOAD_AVSC_FUNC, which allows for supporting the up-to-date headers but breaks all prior versions. 2.5 was supported through a compat header sourced from FFMS2, and only contained the pieces that had been adapted there (regarding the internal functionality of avs_get_row_size_p/avs_get_height_p that changed between 2.5 and the 2.6 alphas).
Attempting to continue supporting 2.5 would require - similarly to what happened in AviSynth itself - moving the baked-in code from the old header into the compat header, swelling the latter with more things. But the compat header is under the MIT License, not the GPL. Moving GPL code into a non-GPL header is a no-no. So that would require trying to reverse engineer it. Further, the reverse engineered form would then require forcing more special-casing and code branching into the libavformat demuxer, which would work against the goal of it being [at least relatively] clean. And no one - not me, nor anyone else in the discussion on the FFmpeg-devel mailing list - were willing to or expressed any kind of interest in reverse engineering that for the sake of supporting a less stable, nearly 7 year old version of AviSynth when more stable and higher performance versions exist. Or for trying to support the 2.6 alphas when the support from the classic AviSynth devs for non-final versions has never lasted longer than the next alpha or RC release (see the CACHE_* changes in 2.6a4 requiring rebuilds of masktools-26).
In short, it was the state of the AviSynth headers themselves that burned this particular bridge. The real preference is for using official headers rather than the transitional form header it used to use.
The primary problem for Plus is that AviSynth+ 0.2 has yet to be formally released, so while we can say '2.6 RC1 or higher' for classic, users that go to avs-plus.net see the current stable version 0.1 (a.k.a. r1576), which is still in a pre-RC1 state and thus suffers from the same problem as classic 2.6a1-5 on this point.
|