Jan 27, 2021, 16:07 by jamr...@gmail.com: > On 1/27/2021 6:16 AM, Anton Khirnov wrote: > >> Quoting James Almer (2021-01-26 20:11:16) >> >>> On 1/26/2021 1:17 PM, Anton Khirnov wrote: >>> >>>> We could start by adding a field to AVPacket that would be set to a >>>> magic value by av_packet_alloc(). >>>> Then have e.g. AVCodecContext/AVFormatContext warn when they see a >>>> packet without this magic value. >>>> >>> >>> I don't like much the idea of adding a public field just to emit a >>> deprecation warning. >>> >> >> >> int internal_do_not_touch; // do not touch >> >> is not really public. It is visible in the public headers, but so are >> all the AVFooInternal. I agree that it is not the prettiest thing ever, >> but it's not too bad. >> >> And I believe it would solve a real problem, since we have few other >> ways to let our users know they need to change something. Most of them >> do not follow development closely, I'd think. >> > > If sizeof(AVPacket) stops being part of the ABI, then av_init_packet() > becomes unnecessary, right? av_packet_unref() will be the only valid way for > the user to reuse the AVPacket. So that deprecation warning might be enough > for stack users. >
I think just a compile-time deprecation on av_init_packet() would be enough. > Regarding a new internal field that lavf could check, i don't think it's > enough since it may be uninitialized for packets on stack. And you can't make > av_init_packet() set it to 0/NULL because then av_packet_unref() will also > reset it, and lavf will start printing bogus warnings for allocated packet > users. > I'd really rather not spam the log of users with API deprecation messages. We're already guilty enough of doing that with color_range. _______________________________________________ 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".
