On 12/2/2017 10:48 PM, Michael Niedermayer wrote: > On Sat, Dec 02, 2017 at 03:26:34PM -0300, James Almer wrote: >> On 12/2/2017 3:00 PM, Carl Eugen Hoyos wrote: >>> 2017-12-02 18:51 GMT+01:00 James Almer <jamr...@gmail.com>: >>>> On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote: >>>>> 2017-12-02 18:37 GMT+01:00 John Stebbins <stebb...@jetheaddev.com>: >>>>>> That should be done, or I should add back support for earlier versions. >>>>>> Is there any desire by anyone to keep support for earlier versions? >>>>> >>>>> How old is 2.5, is 2.4 used by current versions of distributions? >>>>> (How ugly is the support for earlier versions?) >>>> >>>> It's four months old, and rolling release distros are using it and will >>>> move on to 2.6 soon. >>>> >>>> By the time non rolling release distros switch to ffmpeg > 3.4, they >>>> will also switch to whatever is newest for x265 at the time. >>> >>> I was mostly thinking about users who build FFmpeg by themselves >>> on current distributions. (And about developers who like to test on >>> vanilla systems.) >> >> Those on rolling release ditros are covered, and those compiling ffmpeg >> git head on non rolling release distros are most likely also compiling >> any required libraries for it. >> Hell, 2.5 is even in Debian testing right now. >> > >> I very much rather avoid ifdeffery to support old releases from projects >> with a rapid update schedule like x265. > > I understand why you prefer this but i think its nicer to our users > also the stricter version deps are the more one runs into issues > > for example the "recent" libvpx min version bump required me to > update my libvpx
How? 1.4.0 is two years and a half old. Even Debian ships 1.6.x in stable by now. > and it promptly broke many older FFmpeg versions > ive patched my release branches locally and that would be in the next > point releases of course but versions released previously require > a libvpx that master doesnt build with and what master builds with > they dont. > > If we accumulate too many of these things bisect will become > increasingly painfull We can't keep external libraries hostage of bisect attempts for unrelated modules... You don't need libvpx or libx265 compiled in when hunting down a bug in mpeg2/h264/snow code. We'd never be able to update anything that way. I'm surprised for that matter that the libvpx wrappers in old FFMpeg versions don't work with >= 1.4.0. I don't recall any kind of API break that we had to work around in them. > > short version, my "vote" is for keeping support for the older version > by #if or any other solution I'm fine keeping libx265 as is for now. Unlike libvpx 1.4.0, which is two years and a half old, libx265 2.5 is admittedly somewhat recent. But bisecting bugs in unrelated modules is definitely not a reason to maintain ugly support for old and potentially buggy/unstable/insecure versions of optional, non system external libraries. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel