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 82F63423BA for ; Tue, 15 Mar 2022 13:59:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BCD2A6809C4; Tue, 15 Mar 2022 15:59:26 +0200 (EET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068089.outbound.protection.outlook.com [40.92.68.89]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5FD3A6800DD for ; Tue, 15 Mar 2022 15:59:20 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jX51sRT7PBGsjpFpjg84QQfV1Jtt0EGkVE1mqeMiqowMcmMrir8pUxVkZowG1BajzE8VxqnsVkYCv8Ud24eZ/E7C+xQHlnKRO+A+rl1KXOMUPBsbrv+HkIjOgZ89yfweLhK0wezCKRvQZxrqAJdmYcoRrGIHBzOLrC5CtlSPp/3YCeWZwYKqTFDvuDbz6VRuLYbNU6jyq3pHJhq23fRlKq++mWsqmzEp4cmN1zD97Sn4KdGIh6SLdOxS3bMD0z+tieAMyVfgUxZ+ydpQ2eL7kmiYhrVImUsCGHswUgFPuip/wh+plTcHBRIT+Z0s5nR5JjeYGjyrqm/wx9A4ntl4ew== 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=pophU3q9yJnjyPpUMVJX49uRHqy9F6w+CoTZ+3g+PHI=; b=DZUleeQNHks163HLLuW8Ay1mpf7BdPgShWdbk+KqPCn5W5EsBDFQbVv5im/3Oeo7t09vJgxE6RINN+qDsyy/8YnWwg6Yu5SzfB274nXlIbwszuLPx6tsxMHHxI4GQgPlPBXL07J7Npb4BROZfYls0vctNcL+17shqxKDGv+k/ymUL5zr4dw6ksh4pTeOmtr3mWbgj/clSKMj4sqfKCSYN2QjFOCSF1E6P4jCdwxf0aZVLfvpK1dNhq0Vib1KtRhniVE9sgVIh7n4pynJYr/vlprN/iOGxL4eKZWlXNfUUw0YSmKeqEy78Q7Nu0aiQDbbBjjCRqwyMyXBxf/H+Parqg== 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=pophU3q9yJnjyPpUMVJX49uRHqy9F6w+CoTZ+3g+PHI=; b=nNeBR1pVzMMPJcjUbn5kgrlh//ysi6DrC8FNbRsp6NhEJ5dpgLWFseaICzcHXrPM/vTzPNch/3c/o3rea2IE03nVLtwGFC96jyaY1DTIprIuVrZAt6Cplf7QBZXsO36R6z4LqiDZ8Z16xlFGDx1RHAO/w2EFY+O6JW4Pvui1kFglnqS6FLp+pc5b9Kdxyp9is3r3zEs6nTUQVLH8R3ztw8povn3rkjdeLxTw2TCmEpI7YC3S0WMWOhDVZ4r1JKa3SIwLW5agflMhEYDZ+oKcO5fUZHhBxU2zmgLx/SkBcwmsdLDqx/R0QE8Ak4YaueVrahGGM8QSBobbbUwIrNGAIA== Received: from AS1PR01MB9564.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4d1::16) by PAXPR01MB8171.eurprd01.prod.exchangelabs.com (2603:10a6:102:1da::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.25; Tue, 15 Mar 2022 13:59:18 +0000 Received: from AS1PR01MB9564.eurprd01.prod.exchangelabs.com ([fe80::9070:a5fd:e532:bdf8]) by AS1PR01MB9564.eurprd01.prod.exchangelabs.com ([fe80::9070:a5fd:e532:bdf8%4]) with mapi id 15.20.5061.028; Tue, 15 Mar 2022 13:59:18 +0000 Message-ID: Date: Tue, 15 Mar 2022 14:59:14 +0100 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220315104932.25496-1-anton@khirnov.net> From: Andreas Rheinhardt In-Reply-To: <20220315104932.25496-1-anton@khirnov.net> X-TMN: [y5bMA9RFW3inzGvz5UcSYZ89zd0hMVri] X-ClientProxiedBy: AM6PR0502CA0052.eurprd05.prod.outlook.com (2603:10a6:20b:56::29) To AS1PR01MB9564.eurprd01.prod.exchangelabs.com (2603:10a6:20b:4d1::16) X-Microsoft-Original-Message-ID: <3769f817-1edb-bb2a-1caa-233460e83aa8@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 768dda98-4f02-4720-b2fd-08da068bfe05 X-MS-TrafficTypeDiagnostic: PAXPR01MB8171:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8iN9BAOjq+u9DdKyvkMt1+HWAeE0OEFxzgn3GqrrjSZ3YgM7EqoTZ1+kQxMQl6xp45W6qVD+dwTbKhYfvwJSQ0roF3ezISKMGDI2czJqRsHyjWd4oPL0eyXXZK7bBnpkiJ4EbSPwuKNlKz+Q3jz/GiVJm6opkfeVrTMaT2U7uQvrmS19H5sqz+ke7RF2qpYng339dPGTNhr9yB6pElnfKSZseodxsF+3ZHDTAwfDFmg9ImL1zmvQ6Jx421TyR0AvcRqwxWQPVFcMWrKJwBqbomuzh1iSX8EQz5ItAwV1XkWr06zJyob+V9QtOnfOGt68WO8O9Go/M56VVgrFmp+TqQ7no11LGaRYq6Up8Fxisryu7Wo5cK0mi/0bTGNj2s8mvZ55D0cN3kTml5apDm2Cmg1H6K9Unp7qcgNugRsUEFvzET+OTH47NOuxzbRR/AiyB4hAaqHLTBWoEqENDzZqzpqoyoLgNgT19Q3Lwi8ClK6CIj2iuTiCSRFUE2/ZZ3836k9KHQigvhe3NmWIVB10jS04YFW1nX3ubH3hucxluNIHiqimYE4kbk6SyzfZuc3qpxU93IU8NgUTUa37Vjb6aQ== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a0xQTHRDZEh4bzdnV3Q1a3NGVERtb3dxMzFIbGI3Q3Bpc0hHWkRiYnpvMVN6?= =?utf-8?B?QWhaeXBnL3RGbzE4a09rQ3krMkp1bkwxSklCaU1JSXZWdmdSSk1UWDlmWHZR?= =?utf-8?B?OCtaUDRQcjZvNGRRdUdlNHdsbEx6TmxBcGNWNkhPMnhLaUdMbUd6N2pBMWhL?= =?utf-8?B?dTVBWnpQRzZqVnJTOUhvNlU2OWd0cFFMZWQ2Um9xOXFrUCtWeFRGa2ZqUFU0?= =?utf-8?B?QnZmMmNYYUMwN2Y4VllSRXdvQTFKUU9lSHg1UnBuR3RTVS9DOVJNN3RMMFRt?= =?utf-8?B?Uzg1WXFSOU9zck0rcTFzb1JKNDJKYkJyRU9qRTM2UU9rbmVKOXkyU25TRzdz?= =?utf-8?B?Q1ZUeUkyTW5zT0lwUnZ0d0hnNmhON0lmOWhTTTRNRnNHNFRTalJidGF1cGpH?= =?utf-8?B?OUEwbzlNVUljbXh2Ulc4U3liV09idWgvdHdFaVY3bS9Dbjcvb25vYW5HQTN4?= =?utf-8?B?cjZZWjNYK3FwMHEwRXJPWk0wWExTR1M5WDlHOWs4OVhKTGRyUGJKNVdHWW1R?= =?utf-8?B?a3RialptZXczSi9HS0ZEelNyaTlSR29RN1RiMWNQR3VzNzdkaFhXUWYxSmtV?= =?utf-8?B?U3BtcVFBaHVZdGt1Z2dlcEVZaWRCbzVpaUJqUlErdUpRRDQrUHI4NU93ckZ3?= =?utf-8?B?N3ZQWVE0UEt0YWwvV3RmRUJ4YUMyZDZUd3AvVkhhR24wOU43SWhnMmpzS21s?= =?utf-8?B?NXZBNXZtcjl3Yy9wamJBSUxJY08yZ2tuMWJSbTBFZXpIMGlCRFpRSFZxaVV4?= =?utf-8?B?MDFuWXNJR25STnlmaUI4MXcyR1c2TmNpY0h5RGtvVXVEQlhDZ25kbVo4RC9t?= =?utf-8?B?aWdqSVp6RDN0dlU4Y3JVWjYydTRpdDVZZTlVRzBGNlQ4clIxR0JLL2ZNN05w?= =?utf-8?B?ZEREajREU0pUb3ZuYXdPN3VlQnl1TTdISjhqc2VtOGMzQi9sb2crZ2hBNTFZ?= =?utf-8?B?SHUzUk01TVpuS0UwUlVnOXVhTGxxd2psSW56SC9Bd05tMUNQNVdKa1dpK3Nj?= =?utf-8?B?MEZYd2FqTEdySXIrQ1ZPZ3RYOFZ5VDY4M2w1Vk1mN01yem1jTVRwWVJmcWVQ?= =?utf-8?B?V1EvcGErS2xEUVE4YmtlMm5QSGVnQXlxNHVPV0N1M0JuK0FZZDA3djBnSDJI?= =?utf-8?B?aWJ4bG90ZHdtdkZCa2VxRjd1c1FkaHowajJnQitWeHhSZkNBS1ovbWQ2YUM1?= =?utf-8?B?c0NCbnBwV3RxWEhNKzVXVEZ5RUdZKzU5a0tvdTRlWFlJSWVoY1JCNWhWdEhY?= =?utf-8?B?Nm5FR1pZa05URlU1MmNwemZuOUFmY084WklxakpUNGlVUHRRcW15QkRwY2Y3?= =?utf-8?B?ZXZrSWR2MEZHMUZSRmpsV2ttRURubkp4aWVTZVVjaWxhcmFyT2hGN21BUHZ5?= =?utf-8?B?SlFXV0ZnUmpqNWxWZWJoUTlFVzJiUHRIS0RsWWFId0t0cTh6Z05NZG93S3Z5?= =?utf-8?B?d1JvQlEzN1oxWTU3MFVJV2l0dTFPZ2VZMyswVlF3TElWczFicmNWUUtMbzZW?= =?utf-8?B?Q2JTYUNNbFFMV28xMFgvQ1dGazlFMXlqRkVTcGdNM2ZoMW5GWXg0K1U2K2lo?= =?utf-8?Q?MA8ehbBqCmg5J51QSnI6Fd57XIwVHBtiS9jiDFp9tGnwqU?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 768dda98-4f02-4720-b2fd-08da068bfe05 X-MS-Exchange-CrossTenant-AuthSource: AS1PR01MB9564.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2022 13:59:18.6354 (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: PAXPR01MB8171 Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/threadframe: allow decoders to attach buffers to ThreadFrame 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: Anton Khirnov: > This may be useful for synchronizing side data that only becomes > available after ff_thread_finish_setup() is called. > --- > libavcodec/pthread_frame.c | 1 + > libavcodec/threadframe.h | 3 +++ > libavcodec/utils.c | 7 +++++++ > 3 files changed, 11 insertions(+) > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c > index 33b5a2e628..4da3832942 100644 > --- a/libavcodec/pthread_frame.c > +++ b/libavcodec/pthread_frame.c > @@ -1138,6 +1138,7 @@ fail: > void ff_thread_release_ext_buffer(AVCodecContext *avctx, ThreadFrame *f) > { > av_buffer_unref(&f->progress); > + av_buffer_unref(&f->priv_buf); > f->owner[0] = f->owner[1] = NULL; > ff_thread_release_buffer(avctx, f->f); > } > diff --git a/libavcodec/threadframe.h b/libavcodec/threadframe.h > index dea4dadc6d..c2ddc2969f 100644 > --- a/libavcodec/threadframe.h > +++ b/libavcodec/threadframe.h > @@ -30,6 +30,9 @@ typedef struct ThreadFrame { > // progress->data is an array of 2 ints holding progress for top/bottom > // fields > AVBufferRef *progress; > + > + /* arbitrary user data propagated along with the frame */ > + AVBufferRef *priv_buf; > } ThreadFrame; > > /** > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index 066da76e16..cc2c2715b3 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -881,6 +881,12 @@ int ff_thread_ref_frame(ThreadFrame *dst, const ThreadFrame *src) > return AVERROR(ENOMEM); > } > > + if (src->priv_buf) { > + dst->priv_buf = av_buffer_ref(src->priv_buf); > + if (!dst->priv_buf) > + return AVERROR(ENOMEM); > + } > + > return 0; > } > > @@ -913,6 +919,7 @@ void ff_thread_release_ext_buffer(AVCodecContext *avctx, ThreadFrame *f) > f->owner[0] = f->owner[1] = NULL; > if (f->f) > av_frame_unref(f->f); > + av_buffer_unref(&f->priv_buf); > } > > void ff_thread_finish_setup(AVCodecContext *avctx) This approach has the downside that you have to add the priv_buf before ff_thread_finish_setup(). So in case it is not apparent initially whether one needs this one is forced to add it (even if it turns out not to be needed); it will also necessitate two av_buffer_ref() in. A better approach would be to replace the progress array (of two atomic ints) with a struct containing these two atomic ints and whatever data needs to be shared. The owner should logically also be part of this struct, yet I could not figure out if this is compatible with current h264dec last time I looked at this (when I wrote the patchset containing 02220b88fc38ef9dd4f2d519f5d3e4151258b60c); the current way of doing things allows different threads to have different opinions about the ownership of the frames. (My actual aim with this patchset was to move the AVFrame into the aforementioned structure like so: struct { atomic_int progress[2]; AVFrame *f; }; This would avoid the need for the av_frame_ref() in ff_thread_ref_frame(); therefore all the frame's properties could be set directly on the AVFrame by its owner as long as the frame is not finished. The non-owners could read the data subject to the current limitations (i.e. they have to wait for progress) and could read anything after the frame is finished (progress == INT_MAX; codecs could of course use their own semantics here if they wished). There were two reasons why I didn't finish this approach: 1. How to synchronize in case of two owners? (Happens only for h264dec.) 2. This would add an av_frame_alloc() for every frame, even when not using frame threading. The latter can be easily avoided, but avoiding this with frame-threading would require a smarter pool-implementation. And I hate to use/extend the AVBuffer-API for something for which it is simply the wrong tool and use something that does not require an allocation for every ref. (It would nevertheless have been advantageous allocation-wise, because one saves the allocations implicit in av_frame_ref().)) - Andreas _______________________________________________ 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".