Opened 6 years ago

Closed 2 years ago

Last modified 2 years ago

#5551 closed defect (fixed)

av_bsf_send_packet can't take ownership on not reference-counted packets

Reported by: mrlika Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Because it doesn't know how to release it. And caller also doesn't know when to delete the packet passed to black-box algorithm.

For not reference-counted packets it is more correct to create referenced-counted copy of the packet and leave ownership to the caller.

For example av_grow_packet h264_mp4toannexb and h265_mp4toannexb already call av_grow_packet on input packets that just overwrites pkt->data field with newly allocated buffer for not reference-counted packets. It leads to memory leak.

Change History (7)

comment:1 by mrlika, 6 years ago

Component: undeterminedavcodec
Version: unspecifiedgit-master

comment:2 by gjdfgh, 6 years ago

Simple: don't pass non-refcounted packets to these APIs.

in reply to:  2 comment:3 by mrlika, 6 years ago

Replying to gjdfgh:

Simple: don't pass non-refcounted packets to these APIs.

Yes it is simple but not obvious unless you investigate the source code. And in this case it is better to validate input packets for reference-countness.

comment:4 by gjdfgh, 6 years ago

Maybe it should be better documented. Still, "taking ownership" implies the user can't access the packet after passing it to the API.

comment:5 by mrlika, 6 years ago

I see the following ways to fix this:

1) Restrict to use the API with not reference-counted packets by updating documentation and\or adding asserts validation for reference-countness.

2) Create referenced-counted copy of not reference-counted packets and leave ownership to the caller. Update documentation.

3) Change API to always leave paket ownership to the caller. Update documentation.

comment:6 by mrlika, 6 years ago

And latst variant:

0) Do not touch anything

Do you have any thoughts on this?

comment:7 by mkver, 2 years ago

Resolution: fixed
Status: newclosed

Since ed1f08bfb5500340463e630290360609a90d2886, a copy of the data of non-refcounted packets is made, i.e. your second option has been implemented.

And h264/hevc_mp4toannexb called (and call) av_grow_packet() on the output packet, not the input packet. So there was no danger of memleaks by non-refcounted input packets.

Last edited 2 years ago by mkver (previous) (diff)
Note: See TracTickets for help on using tickets.