On 27/06/2025 22:49, Marvin Scholz wrote: > The ret value is already checked earlier, making this condition > impossible to ever happen. > > Fix CID 1648350 > --- > libavcodec/vvc/refs.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c > index 79967b77d3..e52cc0c10d 100644 > --- a/libavcodec/vvc/refs.c > +++ b/libavcodec/vvc/refs.c > @@ -310,8 +310,6 @@ int ff_vvc_output_frame(VVCContext *s, VVCFrameContext > *fc, AVFrame *out, const > ff_vvc_unref_frame(fc, frame, VVC_FRAME_FLAG_OUTPUT | > VVC_FRAME_FLAG_BUMPING); > else > ff_vvc_unref_frame(fc, frame, VVC_FRAME_FLAG_OUTPUT); > - if (ret < 0) > - return ret; > > av_log(s->avctx, AV_LOG_DEBUG, > "Output frame with POC %d.\n", frame->poc);
I agree there shouldn't be two checks on ret here. I am not sure this is the right one to remove however. Perhaps it is better to remove the first check and only check ret after having unreferenced the source frame, as was the behaviour prior to a8d949bd96364892903bedbbc2eef11b712e5500 ? I'm not certain, but it looks to me as though that commit might have introduced a memory leak: if av_frame_ref fails, then the source frame is never unreferenced and its data never freed. -- Thanks, Frank
OpenPGP_0x03A84C6A098F2C6B.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital 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".
