[FFmpeg-devel] [PATCH 00/26] Major library version bump

[Marton Balint]

On Tue, 24 Jan 2023, Anton Khirnov wrote:

> Quoting Marton Balint (2023-01-24 01:06:46)
>> On Tue, 24 Jan 2023, Michael Niedermayer wrote:
>>> On Tue, Jan 24, 2023 at 12:22:52AM +0100, Marton Balint wrote:
>>>> On Mon, 23 Jan 2023, Anton Khirnov wrote:
>>>>> Quoting Marton Balint (2023-01-23 23:41:11)
>>>>>> On Mon, 23 Jan 2023, Anton Khirnov wrote:
>>>>>>> Not breaking callers seems like a very solid benefit to me.
>>>>>>
>>>>>> I am not sure if I see your point, during unstable, you can break callers,
>>>>>> and I planned to do the change during unstable.
>>>>>
>>>>> My understanding of this instability period is that it's mainly for ABI
>>>>> changes like reordering struct fields and such, you're still not allowed
>>>>> to arbitrarily break random APIs. The entire point of having deprecation
>>>>> periods is that callers can prepare in advance and never actually be
>>>>> broken.
>>>>
>>>> If some fields or API is deprecated, then yes, it makes sense. But if no
>>>> deprecation / replacement API is provided, then how will anybody prepare?
>>>> For type changes, fields are usually not deprecated. Ifdefs are only used to
>>>> prepare the changes for the next API bump. For example, buffer_size_t was in
>>>> the codebase for 2 months only.
>>>>
>>>> It is not that big of a deal to make a patch if #ifdefs, I just really don't
>>>> see the benefit.
>>>>
>>>> An actual problem however, is that printf() like functions expect type
>>>> specifiers, and unlike buffer sizes, there is a good chance the users
>>>> sometimes print AVCodecContext->frame_number or AVFrame->xxx_picture_number,
>>>> which will become undefined behaviour. And yes, the compiler will usually
>>>> warn, but still, type changes can cause silent breakage. But using #define
>>>> API guards will not fix this, whenever you change the type, code will get
>>>> broken, I am not sure if anything can be done about it.
>>> if you want to avoid this then, new type, new identifer
>> Sure, but do we want AVFrame->coded_picture_number64,
>> AVFrame->display_picture_number64
>
> Are these even useful for anything? The don't seem like they belong in
> AVFrame.

It might have some users as some decoders (Dirac or AVS3-P2) set it based 
on bitstream values. Plus mpegvideoenc is also using it for something...

Regards,
Marton