Andreas Rheinhardt (12020-04-12): > Currently uncoded frames (i.e. packets whose data actually points to an > AVFrame) are not refcounted. As a consequence, calling av_packet_unref() > on them will not free them, but may simply make sure that they leak by > losing the pointer to the frame. > > This commit changes this by actually making uncoded frames refcounted. > In order not to rely on sizeof(AVFrame) (which is not part of the public > API and so must not be used here in libavformat) the packet's data is > changed to a (padded) buffer containing just a pointer to an AVFrame. > Said buffer is owned by an AVBuffer with a custom free function that > frees the frame as well as the buffer. Thereby the pointer/the AVBuffer > owns the AVFrame. > > Said ownership can actually be transferred by copying and resetting > the pointer, as might happen when actually writing the uncoded frames > in AVOutputFormat.write_uncoded_frame() (although currently no muxer > makes use of this possibility). > > This makes packets containing uncoded frames compatible with > av_packet_unref(). This already has three advantages in interleaved mode: > 1. If an error happens at the preparatory steps (before the packet is > put into the interleavement queue), the frame is properly freed. > 2. If the trailer is never written, the frames still in the > interleavement queue will now be properly freed by > ff_packet_list_free(). > 3. The custom code for moving the packet to the packet list in > ff_interleave_add_packet() can be removed. > > It will also simplify fixing further memleaks in future commits. > > Suggested-by: Marton Balint <c...@passwd.hu> > Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com> > --- > How embarrassing! The earlier version forgot to check the allocation.
I am confused: does it not make unwrapped frames behave exactly the same as wrapped frames? AFAIU, Marton intends to remove all this code, and I think he is right, because it was a hack. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
