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

[mrlika]

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.

[gjdfgh]

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

[mrlika]

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.

[gjdfgh]

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

[mrlika]

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.

[mrlika]

And latst variant:

0) Do not touch anything

Do you have any thoughts on this?

[mkver]

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.