From patchwork Sat May 11 20:50:45 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Rheinhardt X-Patchwork-Id: 48791 Delivered-To: ffmpegpatchwork2@gmail.com Received: by 2002:a05:6a21:1706:b0:1af:cdee:28c5 with SMTP id nv6csp301529pzb; Sat, 11 May 2024 14:04:32 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCWsFh5W+W4/OwWAcpNP8i1Lo/0ZsoV3bueXx77FjoG8C6xhUtW1ufCezU1eHCM5mk+pN0T62tjIxT8LC9KVi3j7qaky8Kvj1DSDgw== X-Google-Smtp-Source: AGHT+IHJK0sB+m3XrQBMd8B2baem+BrxAcSDE1oudkCZvGl5FdK4v4naUsrSnC6X2ZKeFbijpBco X-Received: by 2002:a05:6512:398a:b0:519:2a88:add6 with SMTP id 2adb3069b0e04-5220fe7999amr4579590e87.55.1715461472536; Sat, 11 May 2024 14:04:32 -0700 (PDT) Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org. [79.124.17.100]) by mx.google.com with ESMTP id 4fb4d7f45d1cf-5733bec05fesi3298172a12.147.2024.05.11.14.04.32; Sat, 11 May 2024 14:04:32 -0700 (PDT) Received-SPF: pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) client-ip=79.124.17.100; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@outlook.com header.s=selector1 header.b=rfPXg34X; arc=fail (body hash mismatch); spf=pass (google.com: domain of ffmpeg-devel-bounces@ffmpeg.org designates 79.124.17.100 as permitted sender) smtp.mailfrom=ffmpeg-devel-bounces@ffmpeg.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=outlook.com Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BDEBE68D669; Sat, 11 May 2024 23:53:05 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn2013.outbound.protection.outlook.com [40.92.91.13]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D834068D664 for ; Sat, 11 May 2024 23:53:03 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NySJ8bxozEEhzqca2JaNr/R0Sq9LHnXA4HBYQQVQi7Huz1Obu7NdnRFgAy3tyuJaFhk6Do8eV6HEc8pgtvziWNuWKCMFNp33aD0bTjiYeLz9By+0sTASO+vyB3/2Fel7Ep5dIKn6xUMa0LlqrCpYltN0Cf4/pBbZz0oSgjmwh7WowhLzIxV96Lzu5GMVpXGzdlSzZqtldP515MPd5LGYYzoR5pOjV/znipCTAr2bh9UO20Xt6o+XwiydQ55gkjmpcP7U8Nv/iQvn/ere5n2ZQ8P44M+xvQW5VVWcMQvRLEc0pPd3KPkjgxWXY6X1bIHJ2xGmz01XheQfwKDctbKiOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T5lxUYwyxo3HncNBZeBFZGtB51ROocELdc0fOoRbLgE=; b=AE1tL5jmIoLcOIhdcWcJccgZMo8i7byMB1743tPHL4GOTkNBKICcTYgoCsMcnu1HZeTrP8iihK1MqT18I+hkZm3UnOzvdKOPVeiiZ16TrBc4gqpYGWdhiNof2q+t9L+e+esfp73ngB/z9hDFcAlEgv9YTqhblP8dN/ImxjQe9sQKQa8R/tKMkIeObjW83xmlEV39KvYOX0m3EcDt+q04A8+A9tlF3fDrpBpgedBWtp9jBOCWIYPcTZHRfGQ428+0qOgVipTJY5g/1pS3aM3PM0T1SCbLtVvnLo6+wuVDFYMom52b+/LilJKN1sNdjBPbmOUXqe9JvN0vuvS+Cw6pOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T5lxUYwyxo3HncNBZeBFZGtB51ROocELdc0fOoRbLgE=; b=rfPXg34X+WW+YgSNwwTR0DDbEHWLMzy050htLrdHpo4/m3HOtLu7ZkKzrKDzqU6vXLT7vs5fvs+sLY+ekEqaYZNLGI0Y958k0Lu6+vfcSz/X/bYCMfRmaajoGcHGZRBrvEgozGunzT2ZFr8v4SkGJTzSr3RPP41bLUTxvelk6/4AIRnP8VV8xbr6hbVsYs1g11EiHlZX/mnl0S9+ldloQz1anFcIUzPAOzIjX9YBu8X/O7nb1zhQ560syquk3XXnHKbWthqctbzFiN0YKbFaSqwCPQMfvM91sGsumkuGkKO+OHoD33xJsMZt0yQjUoM8yTR2oBqwGszxjrHELOD/0A== Received: from GV1P250MB0737.EURP250.PROD.OUTLOOK.COM (2603:10a6:150:8e::17) by PR3P250MB0370.EURP250.PROD.OUTLOOK.COM (2603:10a6:102:17d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7544.55; Sat, 11 May 2024 20:53:02 +0000 Received: from GV1P250MB0737.EURP250.PROD.OUTLOOK.COM ([fe80::d6a1:e3af:a5f1:b614]) by GV1P250MB0737.EURP250.PROD.OUTLOOK.COM ([fe80::d6a1:e3af:a5f1:b614%7]) with mapi id 15.20.7544.052; Sat, 11 May 2024 20:53:02 +0000 From: Andreas Rheinhardt To: ffmpeg-devel@ffmpeg.org Date: Sat, 11 May 2024 22:50:45 +0200 Message-ID: X-Mailer: git-send-email 2.40.1 In-Reply-To: References: X-TMN: [9VK6nfTD+V3kWDib1JTMBHUJyyiOPtJHHp8PgIY9OTM=] X-ClientProxiedBy: ZR0P278CA0172.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:45::6) To GV1P250MB0737.EURP250.PROD.OUTLOOK.COM (2603:10a6:150:8e::17) X-Microsoft-Original-Message-ID: <20240511205135.2411886-20-andreas.rheinhardt@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: GV1P250MB0737:EE_|PR3P250MB0370:EE_ X-MS-Office365-Filtering-Correlation-Id: 5aa822b6-9e13-4170-09db-08dc71fc590a X-Microsoft-Antispam: BCL:0; ARA:14566002|461199019|3412199016|440099019|1710799017; X-Microsoft-Antispam-Message-Info: VCJHl8uncczS4/4I7uWRdv6UVRoI5sOxoEtzhNSIgK8r4hxdpyYUcg2QWfudvK1pF9eW2kaUNiSh93U7Nzu0dnIg7OblEhVZdbi44D55NiZGT9h27B6CIE3YYhD9/wRq0XXjIaLFyG8j70eYz2uwRuW9OfzFjdKthLZRDEoemhNWqLhE/tcF5I4WQQjf1sw+GPUz4ghRyhTVviHSMRK1PZOTdDFduBRpbf0add8ugT7OqchOLZPPKDRAgMlIOVJ6Oq4j+Jzeur0vnhleHVwEkC/mzIhtNidR3W2awFb12B/vMfh7CYjSlSEkCGnBSrzqCDMTrYfmdUaPvt9N+W3wCMJWCfjKOLTYjmum/gIexpuYzkxhcFbIjRPMs+OdtHdfmEnKXt+xJeI+v2xxsz+WEYDyOd9xaLG0/iCduZ4TJBcmNFPjsmY20AHNZg8mXdJFyTWtUY91TuYFCouvMAtvLwwzBqpJxNBxfiJqHmjO7/zMJYebBzqDjSWfl09jW5Ni2carPV43A/nr62xxpUHq0ty33F789kzciqqVSkOhElNS6MVlrIGMSm2mPs/6b7h9N+eu8PXYm3OX3ouE5INdwsKDwc8ze1yAPsDJ1fSra8XyK7EdhbErdHz5crhm2e2R X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 4oI4tuV8ZkA7yhkXJTCis7Z4n1hRRgcUTe+hiieJ7OGjWIY8PtW6f/8An2gL7a/2mn9R8dv6+42mzX+c3IY0lyc3yMCRTQMasYj04xPoOvnuCHHHlaHbQdVtViCK74ShCBgvjTXTjcZrTHmmUKKByupo4zoVyuJqrxaitcE7Zu9vLvIh/wWAYIXfagU4gbUci+/KBQ+DZBmleswCBjKZjo5FyWP58PKrGgVVLVm4aIM5fRxqtPBqAkDmSjY+PdVy/ZFvFQ1m62Vy3coF2NEkefJ/6r8crOIpPgdVW3Kp+I4cRNmQc+NxpzJjAipZ4xOBEc3JgeM1IqERiIs76WH6BPIcDsSv/2kSEcCNCHioLf3KBittnwv3u9THTukeY9JY5T5UDX3wAqCUHu4sAHxo5LH3fCQcUNGxxYjK1bGz48llhSVKe9swfJXCWgotQWunP4IBT0CB0saipMZ1oBsLSPPtCINboSV3lRntyMeYB6nK33IB4Rnq87L5W76WRFiciB9skkasGH4QcLey5PZCnyof0Z/08xgjypka8104TQz2Z1GqQh3Sa7ncQwo084WFyzUUP0sejlBjG5VnXR6iFRQuMdbzb/D2NcDc4y+XB+zNLZ3pkn1I4dPy0K7+oQqPCmsWji5Wg6nbT+ZZRC/djP1zN9jbFXkF98auj3C9UuFoCvWiD7Pw2ozPXXjcz+KCD13/bbXfu662xUCIKDIGMPnP+1tahSWHrMtantBH/9lKgcnJF8ei2oI1RtGYTiaLJ9Q45K2I4KojZumYVbqP1Rnu8Od1fYGDAqKR2+N0D6YO3sAzeTqsJRtN5z6WBWBpgldswKZqEF8EsGeSHMFfs0vL4z+DbG8kwxYWYA/WeABkOpA65RZ3KGnqjjwlGjj0ODkxbQQfFGRphH+CSbR0D03XmowvDwft+V3Y/fhEVi4++/8Q9D+ZRcWDMxXaWkvJWvUmPrCvAAbA3Sf2CO7TEpXu2vKxtr+zEluqQud3ue+eteuduGSRpvXb/4LnifO1eCeI/eCC+Ni5HeDZukNUQOXtQO6gIJiAE2Gu9MwvmgnUrYrXLZ3XcGkqI8vG2SB9gotOgg84S3l4izmdYoludsGQ7qLgd3mIR9LJk1HMolMrqatY8bvlIdLqf0pxXtlQ5vX3iZnRvM/NZlgX1hXDsluzPOe3a7C1KX86ZSBvtcrOHBzMSa4n/1xhI2EDlcntteUV578nDlwsyD7NtmpL5EpAVLBZNVBcLzD1kdDySdA9MFBcDmAyKyb9XLZBWk3M9Z+QKYt6qhJt5mwgQvyXFQ== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5aa822b6-9e13-4170-09db-08dc71fc590a X-MS-Exchange-CrossTenant-AuthSource: GV1P250MB0737.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 May 2024 20:53:02.1980 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3P250MB0370 Subject: [FFmpeg-devel] [PATCH v2 21/71] avcodec/mpegpicture: Always reset mbskip_table 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 Cc: Andreas Rheinhardt Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" X-TUID: ywv9oTmb2Ncy Codecs call ff_find_unused_picture() to get the index of an unused picture; said picture may have buffers left from using it previously (these buffers are intentionally not unreferenced so that it might be possible to reuse them; they are only reused when they are writable, otherwise they are replaced by new, zeroed buffers). They should not make any assumptions about which picture they get. Yet this is not true for mbskip_table and damaged bitstreams. When one returns old unused slots randomly, the output becomes nondeterministic. This can't happen now (see below), but it will be possible once mpegpicture uses proper pools for the picture tables. The following discussion uses the sample created via ffmpeg -bitexact -i fate-suite/svq3/Vertical400kbit.sorenson3.mov -ps 50 -bf 2 -bitexact -an -qscale 5 -ss 40 -error_rate 4 -threads 1 out.avi When decoding this with one thread, the slots are as follows: Cur 0 (type I), last -1, Next -1; cur refcount -1, not reusing buffers Cur 1 (type P), last -1, Next 0; cur refcount -1, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount -1, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 2, not reusing buffers Cur 0 (type P), last 0, Next 1; cur refcount 2, not reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 1, reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 2, not reusing buffers Cur 1 (type P), last 1, Next 0; cur refcount 2, not reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 1, reusing buffers Cur 2 (type B), last 0, Next 1; cur refcount 2, not reusing buffers Cur 0 (type I), last 0, Next 1; cur refcount 2, not reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 1, reusing buffers Cur 2 (type B), last 1, Next 0; cur refcount 2, not reusing buffers Cur 1 (type P), last 1, Next 0; cur refcount 2, not reusing buffers After the slots have been filled initially, the buffers are only reused for the first B-frame in a B-frame chain: a) When the new picture is an I or a P frame, the slot of the backward reference is cleared and reused for the new frame (as has been said, "cleared" does not mean that the auxiliary buffers have been unreferenced). Given that not only the slot in the picture array, but also MpegEncContext.last_picture contain references to these auxiliary buffers, they are not writable and are therefore not reused, but replaced by new, zero-allocated buffers. b) When the new picture is the first B-frame in a B-frame chain, the two reference slots are kept as-is and one gets a slot that does not share its auxiliary buffers with any of MpegEncContext. current_picture, last_picture, next_picture. The buffers are therefore writable and are reused. c) When the new picture is a B-frame that is not the first frame in a B-frame chain, ff_mpv_frame_start() reuses the slot occupied by the preceding B-frame. Said slot shares its auxilary buffers with MpegEncContext.current_picture, so that they are not considered writable and are therefore not reused. When using frame-threading, the slots are made to match the one from the last thread, so that the above analysis is mostly the same with one exception: Other threads may also have references to these buffers, so that initial B-frames of a B-frame chain need no longer have writable/reusable buffers. In particular, all I and P-frames always use new, zeroed buffers. Because only the mbskip_tables of I- and P-frames are ever used, it follows that there is currently no problem with using stale values for them at all. Yet as the analysis shows this is very fragile: 1. MpegEncContext.(current|last|next)_picture need not have references of their own, but they have them and this influences the writability decision. 2. It would not work if the slots were returned in a truely random fashion or if there were a proper pool used. Therefore this commit always resets said buffer. This is in preparation for actually adding such a pool (where the checksums for said sample would otherwise be depending on the number of threads used for decoding). Future commits will restrict this to only the codecs for which it is necessary (namely the MPEG-4 decoder). Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegpicture.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c index 06c82880a8..a1404c1d09 100644 --- a/libavcodec/mpegpicture.c +++ b/libavcodec/mpegpicture.c @@ -238,6 +238,7 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, MotionEstContext *me, goto fail; pic->mbskip_table = pic->mbskip_table_buf->data; + memset(pic->mbskip_table, 0, pic->mbskip_table_buf->size); pic->qscale_table = pic->qscale_table_buf->data + 2 * mb_stride + 1; pic->mb_type = (uint32_t*)pic->mb_type_buf->data + 2 * mb_stride + 1;