On 3/21/2021 9:28 AM, Anton Khirnov wrote:
Quoting James Almer (2021-03-05 17:32:52)diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 7da2f3d98e..783cc1b591 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -954,7 +954,11 @@ typedef struct AVStream { * decoding: set by libavformat, must not be modified by the caller. * encoding: unused */ +#if FF_API_INIT_PACKET AVPacket attached_pic; +#else + AVPacket *attached_pic; +#endifSorry I'm late to the party, but as we are changing the type of an existing field, we need to explicitly spell out a way for the callers to make their code forward compatible. E.g. similarly to what I made for thread_safe_callbacks deprecation.
What do you suggest? The field is not printing deprecation warnings, so would a doxy comment be enough for people to notice it? Have we done a similar change before? I know at least for symbols like public functions we never change their signature in an incompatible way, and instead replace them altogether.
Maybe we could add the deprecated attribute to attached_pic, introduce a temporary getter function that returns a pointer to the packet, mention in the doxy that the field is not going away, is just changing types, and they have the option of using the getter for a fire-and-forget migration process, then maybe deprecate and eventually remove the getter after the switch is done.
_______________________________________________ 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".
