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

[John Stebbins]

On 12/02/2017 06:32 PM, James Almer wrote:
> 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.
>

I'll add back the support for libx265 <= 2.4 then.  There's technically no ifdef'ery required.  But it requires using a
field in a struct (x265_frame_stats) that is really meant for logging.  My concern with using it is that logging could
change in the future and break this. So I'll ifdef it anyway so that it's more future proof.

-- 
John      GnuPG fingerprint: D0EC B3DB C372 D1F1 0B01  83F0 49F1 D7B2 60D4 D0F7


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171203/e6c553ba/attachment.sig>