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.
Regards,
Marton
If theres noone -> easy solution, we need no instability period ATM.
If theres someone, i would ask that someone how long it needs to be
and write that down in APIchanges. Maybe as in "API is unstable becuase
of X until 2033-11-11
a new #define LIBAVCODEC_UNSTABLE could be added but izt feels a bit
overengeneered. This whole thing is more a exception, isnt it?
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
_______________________________________________
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".
