On Fri, 27 Jan 2023, Marton Balint wrote:
On Fri, 27 Jan 2023, James Almer wrote:
On 1/27/2023 3:04 PM, Anton Khirnov wrote:
Quoting Marton Balint (2023-01-27 18:59:39)
On Fri, 27 Jan 2023, Anton Khirnov wrote:
I still think we should do a deprecation+replacement like we do for
everything else.
You mean you want to introduce a new 64 bit member and deprecate the
old
32 bit field?
E.g.
int64_t frame_num;
attribute_deprcated
int frame_number
And during the transition you want to sync the value between the 64bit
and
the 32bit ?
yes
We did make changes like int -> size_t without adding new fields in places
like AVBufferRef. See 14040a1d91.
Or AVFormatContext bit_rate sometime before.
It does however probably need an FF_API_ dance, much like in that example.
If no new field is added, and no old field is deprecated, then if the type
change is done directly before the bump, then the dance is not needed,
beacuse you'd just remove the dance at the bump.
Anyhow, I will send and alternate patch series which is introducing a new
field for the 64-bit variant. That series is not dependant of the API
bump, can be applied before or after.
If people prefer that, fine with me.
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".
