[FFmpeg-devel] [PATCH 01/50] avcodec/packet: deprecate av_init_packet()

[James Almer]

On 2/8/2021 11:43 AM, Andreas Rheinhardt wrote:
> James Almer:
>> On 2/8/2021 11:37 AM, Andreas Rheinhardt wrote:
>>> James Almer:
>>>> On 2/4/2021 4:09 PM, James Almer wrote:
>>>>> Once removed, sizeof(AVPacket) will stop being a part of the public
>>>>> ABI.
>>>>>
>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>> ---
>>>>>     libavcodec/avpacket.c  | 23 +++++++++++++++--------
>>>>>     libavcodec/packet.h    | 23 +++++++++++++++++++----
>>>>>     libavcodec/version.h   |  3 +++
>>>>>     libavformat/avformat.h |  4 ++++
>>>>>     4 files changed, 41 insertions(+), 12 deletions(-)
>>>>
>>>> Will add APIChanges entry and version bump, and apply soon.
>>>
>>> Why the hurry? In fact, I have just sent a patchset that makes 3/50
>>> redundant.
>>
>> I'm talking about this patch, not the whole set. I'll give the rest some
>> more time in case others want to review or test (The vaapi stuff i can't
>> test, for example).
>>
>> And yes, i saw the patches you sent that supersede 3/50, so assuming
>> your set is ok i was going to withdraw it.
>>
> I still don't see the reason to hurry things;

We're overdue for the bump and a new release before it, so it's best to 
move forward at least a bit. And this change, if committed, should go in 
before either of them.

> actually I don't even this
> direction at all, as it just leads to more allocations and frees. The dv
> stuff is a good example of this, the mpegvideo_enc another.

The mpegvideo_enc was an extreme case the way i wrote it at first, yes. 
And the DV stuff is not an issue for needing allocs, but for being 
shared code between lavd and lavf, with one of the modules, the lavd 
device, being undertested (Does any developer here use libiec61883? The 
massive leak i fixed years ago was there for while, i recall).

New AVPacket fields are being discussed to be added, and if 
sizeof(AVPacket) is public then the window to add them is very small 
(About one month every 2 to 4 years). There's also the issue of field 
initialization. Any new fields could end up uninitialized in the 
scenario of users not calling av_init_packet, which is the reason 
av_read_frame, av_packet_copy_props and av_get_packet do it on their own 
(and it can lead to leaks if you pass them a valid, non empty packet, 
for example).

So I suggested putting AVPacket in line with AVFrame, and two other 
developers agreed. This change removes the above corner cases, relaxes 
the requirements to add new fields, and forces the user to do things 
right, and now that the old decode/encode API is being removed, it's the 
ideal time to do it.