On Mon, 9 Dec 2013 19:59:21 +0100 Hendrik Leppkes <[email protected]> wrote:
> On Mon, Dec 9, 2013 at 7:46 PM, wm4 <[email protected]> wrote: > > On Mon, 9 Dec 2013 12:11:41 +0100 > > Anton Khirnov <[email protected]> wrote: > > > >> avcodec_get_frame_defaults() will be deprecated. > >> --- > >> libavcodec/utils.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/libavcodec/utils.c b/libavcodec/utils.c > >> index 25f16c0..e078a11 100644 > >> --- a/libavcodec/utils.c > >> +++ b/libavcodec/utils.c > >> @@ -1433,7 +1433,7 @@ int attribute_align_arg > >> avcodec_decode_video2(AVCodecContext *avctx, AVFrame *pi > >> return ret; > >> } > >> > >> - avcodec_get_frame_defaults(picture); > >> + av_frame_unref(picture); > >> > >> if ((avctx->codec->capabilities & CODEC_CAP_DELAY) || avpkt->size || > >> (avctx->active_thread_type & FF_THREAD_FRAME)) { > >> if (HAVE_THREADS && avctx->active_thread_type & FF_THREAD_FRAME) > >> @@ -1494,7 +1494,7 @@ int attribute_align_arg > >> avcodec_decode_audio4(AVCodecContext *avctx, > >> return ret; > >> } > >> > >> - avcodec_get_frame_defaults(frame); > >> + av_frame_unref(frame); > >> > >> if ((avctx->codec->capabilities & CODEC_CAP_DELAY) || avpkt->size) { > >> ret = avctx->codec->decode(avctx, frame, got_frame_ptr, avpkt); > > > > This is pretty nice. > > > > With patch 02/11 (making avcodec_free_frame() call av_frame_free()) is > > there any reason left not to enable refcounting by default? > > Like i said on IRC a while ago, you can't rely on users to re-use the > same AVFrame, they may create a new one for every decode call - and > thus leak memory if they don't explicitly free it. > It would be an API break as such. They must still free the old AVFrame, otherwise they can't avoid a memory leak. AVFrame is not allowed to be allocated on the stack, and AVFrame always had to be freed with special functions, instead of av_free. They can't memset() or assign it either (at least technically speaking, because sizeof(AVFrame) is not part of the ABI). I guess they could overwrite the buffer array explicitly, but then it gets really weird: just what valid behavior do we want to not break? And while it would be nice to perfectly emulate the old behavior, with all the broken assumptions users might have done, this would probably be more error prone and do more damage than a clean break. Maybe I'm still missing something... _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
