On Mon, 23 Jan 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-01-21 23:00:52)
On Sat, 21 Jan 2023, Michael Niedermayer wrote:
On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote:
Quoting Michael Niedermayer (2023-01-20 03:05:09)
PS: iam not sure i fully understood the reason behind why versions should be
set to "wrong" values during some period, so as always i might be missing
something
The reason is that after the major bump, the API and ABI are declared to
be unstable for some period, so people can freely
- break ABI, e.g. by reordering struct members
- modify API added during the instability period in an arbitrary way
without a new major bump for every such change, that would be normally
required.
My concern is that the instability period is quite long and there is
very little indication for our users that they cannot depend on the
ABI/API being stable. So I'm proposing to introduce some mechanism to
make this more visible for our callers.
Alternatively, we could just not have an instability period at all.
Does anyone plan to use the next bumps instability period for anything ?
If so, i assume theres a good reason why it cannot be done without such
period easily?
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.
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".
