From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id C529B493A6 for ; Thu, 8 Feb 2024 22:46:19 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0C0A868D09F; Fri, 9 Feb 2024 00:46:17 +0200 (EET) Received: from sender11-op-o11.zoho.eu (sender11-op-o11.zoho.eu [31.186.226.225]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 308ED68C9F6 for ; Fri, 9 Feb 2024 00:46:10 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; t=1707432367; cv=none; d=zohomail.eu; s=zohoarc; b=QyPoM0bSCacttg0mojlmVIQv75b6YN+vkgclBe32qj6qyxPcJdoKlAoyUsOFs90kBfyIURK9NmrsZkzndTmvGmk+8AP0enfKSKvInQhYY9xTCrpqd6MWRM6g9X1k0aDrh0Nray9fuILeGRLUI57VtHC4WkUu69uGBjqnKW0NDAI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1707432367; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To:Cc; bh=L1GIgXD3/SD1lOBe6Juw2OYL4kQffVBKLYBIMpRXyf4=; b=JK+3wpWlmeP5mJ3r7/nbD6GEntBDUq3dBPFaQKS0FC0NYLuvQp9dRcEq5kwsUr+L/Znl7MyDvSzY2TyG0c7Y5QqLpOvsr7heuvf5XC5P2w5U86N+NW4TQbiDG/Hn9VFxyICRaNzSddGBAsZz0JfBMJ5QMEwclN1YKBJdZhf1Ow8= ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=frankplowman.com; spf=pass smtp.mailfrom=post@frankplowman.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1707432367; s=zmail; d=frankplowman.com; i=post@frankplowman.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=L1GIgXD3/SD1lOBe6Juw2OYL4kQffVBKLYBIMpRXyf4=; b=Z3zIshD/P5AQhqcVzjBW0eeDVyx5qhWWOgqxi3x4A+yTLvHbFKeSxf8jYE+/XVHa 4huDIGgZ/iii+PBPIcuqWhhH4ucEr4LAYBUse4Yg7hpvp9W8Tux3GovWTmqfYkaPxVs yI7XabRwOHAGHlel+Xn2I6q/Uv83GYw+URVa8pOc= Received: from [192.168.0.137] (78.32.118.75 [78.32.118.75]) by mx.zoho.eu with SMTPS id 1707432366710992.5938554478222; Thu, 8 Feb 2024 23:46:06 +0100 (CET) Message-ID: <632a0536-a339-4649-b8b2-9acdefa2cb01@frankplowman.com> Date: Thu, 8 Feb 2024 22:46:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB To: ffmpeg-devel@ffmpeg.org References: <20240208211623.74716-1-post@frankplowman.com> From: Frank Plowman In-Reply-To: X-ZohoMailClient: External Subject: Re: [FFmpeg-devel] [PATCH] lavc/vvc: Check fc->ref contains valid reference X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 08/02/2024 21:50, Lynne wrote: > Feb 8, 2024, 22:16 by post@frankplowman.com: > >> From: Frank Plowman >> >> Depending on where exactly decode_nal_unit failed, it is possible that >> fc->ref holds a VVCFrame which has had ff_vvc_unref_frame called on it >> and not yet had ref_frame called on it. In this case, fc->ref most of >> the fields of fc->ref are NULL and attempting to call >> ff_vvc_report_frame_finished on it will result in a null dereference. >> >> Patch fixes the error described above by checking fc->ref has not only >> been allocated, but also references a valid AVFrame before attempting to >> call ff_vvc_report_frame_finished on it. >> >> Signed-off-by: Frank Plowman >> --- >> libavcodec/vvc/vvcdec.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c >> index 8163b5ecb6..246ee79299 100644 >> --- a/libavcodec/vvc/vvcdec.c >> +++ b/libavcodec/vvc/vvcdec.c >> @@ -820,7 +820,7 @@ static int decode_nal_units(VVCContext *s, VVCFrameContext *fc, AVPacket *avpkt) >> return 0; >> >> fail: >> - if (fc->ref) >> + if (fc->ref && fc->ref->frame->buf[0]) >> ff_vvc_report_frame_finished(fc->ref); >> return ret; >> } >> > > In general, for other codecs, if a reference does not exist, > we simply allocate it and pretend it existed and was correctly decoded. > This has better resilience against corrupt bitstreams or just bad muxing, > and yields an (maybe corrupt) output, which is better than nothing. > > Is this not possible for VVC? I think the naming is confusing here. fc->ref is a pointer to the VVCFrame currently being decoded. -- Frank _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".