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:
Quoting Marton Balint (2023-01-21 23:00:52)
AVCodecContext->frame_number should be changed to int64_t. I guess you
could do something similar which was done for buffer_size_t, but that
seems like a lot of extra work and ifdefry for questionable benefit.
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 and AVCodecContext->frame_number64?
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
