[FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

Lynne dev at lynne.ee
Wed Jan 27 19:40:58 EET 2021


Jan 27, 2021, 16:07 by jamrial at 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.


More information about the ffmpeg-devel mailing list