[FFmpeg-devel] [PATCH 3/6] lavc/libx265: mark disposable frames

[James Almer]

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 <jamrial at gmail.com>:
>>>> On 12/2/2017 2:40 PM, Carl Eugen Hoyos wrote:
>>>>> 2017-12-02 18:37 GMT+01:00 John Stebbins <stebbins at 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.