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 38B7643133 for ; Sat, 21 May 2022 09:58:46 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CBBC968B457; Sat, 21 May 2022 12:58:43 +0300 (EEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (unknown [40.92.19.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C869B68B070 for ; Sat, 21 May 2022 12:58:36 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HaX6vSDvYX8pzclYRL7eUp1lShwafjXlIJcqW+tmALDKhFH60lasW1xcz2htJOwpg8Imlne6nWdnqOaeqcGXzPtRuJcGWWvcQE37lpcgvxN5sXCoDaK2s/WsWEu+nVMON3M5qlKKmAe8/c8njsLNnwMbr2yH4DgA148nTQfWFLV3l5ndsQRWCdV9hbGwiy2hycAE4ZSdteFEZc43w82dCscJCnMLMRcSao1X6c2ZW8Ua4rcQXDfbMZuRiJeHHqHNZrMcZctn1yh/xUDmShC22UdOFvJAQkLGOotEkrv8QG9i4MgIZ2X8vhrvVzTpt2AuU1ewpLdUltQB4ak9zGbIjg== 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=+t5mzItSfSlTb87CmHA5c5PPc0RxXpChAcyBJhrKNug=; b=XiXT+qr8fBuOrmXzeGiLaLNsOfwgZBq2ep0vd6dMH9wIaTA8glvL1plYwGSLqh27x1FEZY4Fb3yyHKfxls4VMk++Wt/pQ090tNWBSUgGI+jT1mhOamDYcEQjYaJNbOgWVUF/5x7aBo2rvcuJkfYLN6nlVnVnrSemWAD85uGHWQK+JJsWflxxMeGxNBYYog/EqwAGEly2BxzOP831lFxNFqNHr2R4RG3T7jzfEfknv8i/GmemvSTb2RMqSDA7MIkUW0wtKL/q1lLMTS6wbKbUGyPy/BOnakzhmFk6Rus5Uom9jVGERjp9Oq7TqSpIx8dC3UvIotwLcBgzCu3Kn++Zpg== 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=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+t5mzItSfSlTb87CmHA5c5PPc0RxXpChAcyBJhrKNug=; b=L/lATEDKa+O7X414gZSe8MUA6JY7MDswAAhkjlgN4gCDd5/yIp9ftjY+/Nww5RCAWcbHvE7Ker0UKZDV2vyuA8dVSR87b+A27I44hGKUUu+4/Ixa5RuMEK79EaY3SB7kbd+aMwmjZX7S3aUWmi47WQ9/uT+Y0/l+5rkcK6w+8jVH+NxkX6cEQ4fiIm5k2Yvs1DZ+LVWbh90mBsssVsh9EKbQQ+Rgii6z2MNREu8Npb9vclHLmxX5GF7VPpkp7eZ2BcyNSud3k/sSu9cjto2mgisSPwmcf77VoXbatQqjMkN+STQbKiNW2uWYfxTmkT8UbIC+VChTQUzbnWXXlcMh6Q== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by BN0P223MB0248.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:147::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.14; Sat, 21 May 2022 09:58:33 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::c536:493f:7cda:53dc]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::c536:493f:7cda:53dc%3]) with mapi id 15.20.5273.020; Sat, 21 May 2022 09:58:32 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: AVBufferRef from AVBuffer Thread-Index: Adhs8QHqeirEZ/OzShKwrAFtaNJZhw== Date: Sat, 21 May 2022 09:58:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [f0qxnhrGGlrOAZxMSs9PEGtF4gEGBy1U] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55766c3d-e08c-4715-a144-08da3b1076f0 x-ms-traffictypediagnostic: BN0P223MB0248:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ixHLvuLn+kWdf47ZdYEydnl0QZxxUoki8f54DbXkiK79Buv/1Zo1vfILcHQpsHll/rrnCPcQmDmmCWAnjju/83dZRETxX6tCNt65XvHhapHIpVLEm+qeR9wQNAf9MTwf3Ks0rs3++jXn+uYSFahx1vTD7Hs52dMn9gSZc0H2wKuMFWXHcrf113Em0767AbGBX6YO1OELd282lcV1pPgitM5JgSgRfB7626ZS2q5/p+eY0BtBlMP4j8Gw6f6OlZpvij/pENd99Rntq/oNC9N5Tni82QrixqTBzUVO87nVL6As7vHZ9wMK0n3ktgLJ5f4RyaNMIxfWYO+pACA0i7PWdZIYNQ/5YYUf5jsFKeUPebzCmXBWMtkydBi1ViWR26wTY+0hD0LWZ+wi9AHMJ3wPe/XsikSgyNT80WTHFxeYQGNfodJhIBXWN6Qam31oZj+uENnC+1bjCEh1gZBOwiBSiZpBrjbOjgz75mk9zx2rC4gNG3Y3nDjM9GueMH8RfV7qSln0qWy96okM+TR9/szhdWq2pC36L3VVHCMhLIJRR7T6hwGmfu7tekkXEj/X/cGZIpvW50lCNV6lX7rW8ZHMFQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VjAxNnpHdGdmWXl6cFpuQUxkMklQSFNOWkk4RWJvMjhVRGFGQTdESVQ2VDdn?= =?utf-8?B?eE53dFVybThxcmFZa3FmSWExSnFON0VBeURqanNmdFZUOUFhUk9heEUvc2xJ?= =?utf-8?B?THdsUkJkRUd5VEJzSDNMaTdMMm5LL2JrYWdmcWJCb1d6N1doRmQ1a3Rqb2xa?= =?utf-8?B?ZVdBZXNMYi9CMnVsaDZaWmhlRlZ1VDFoa1ZJQUFWalVwZkw4dktZUXl5TFZt?= =?utf-8?B?ZW5TbHBJa0o1ZGU4S25pZ1lHZDlFQ3V0Z0hSaE9kckxvb1FnN2JkZWVsUEgr?= =?utf-8?B?MnFTTHBoUDdwUGxEN29wdm14NzNXTEFCYkI5b1poYXZURlFOblBESkhHTDZa?= =?utf-8?B?SkY4RXluR2o0VWZKZDlUcEFZQnZXT0RZdzFlY1VnQXppZkltQllMSW53bjRr?= =?utf-8?B?eVVJTm1DU05tem1QZlVsQ3B3eFg0MUFueEZKS2JNZG81QjFCY0pTc0dOVity?= =?utf-8?B?R0ZsSkJuQXNFSlRqbElGQUgwcEcvb3Y4bGRpUmhXUTRPMDl0bUd5M2NmQjBz?= =?utf-8?B?b0pRS0IwWjJqdE96M21DdklrdmtYL21IbmlObnIvZnc1TTE0OVZPUk9lWkZm?= =?utf-8?B?TmhmcjlRT2xmWEp3L0VuR3NKSnhTSjlHbkRXQzQvZUxNSy9VWnNtTlh2NUhM?= =?utf-8?B?Zk9HaW5Mak1ZOENTM2JtcTlUTy9FZUg2S2JiL0F1cDVKRWsxNCs4YlhlMEVm?= =?utf-8?B?bk11NDNwa0ZXMUlKb3QzWFNKUjEwdm5qQVJzYlNIcVRNUTFLWnNCcy9kOU9L?= =?utf-8?B?cHpoQi9BR2VLQnlSbjNxdzlXallXdWczSUpNTWF1aWdxZFowRjJCL0VQdGR0?= =?utf-8?B?L3BuYnp1Z1BNcGV4VlVmV0EvanY2WlE3RXF4QzJhSFRtZkFjZW9wYXIwNjFR?= =?utf-8?B?NjZYbFIrUGt1WlJmcnVqSm1FblFvRkRpbSsyUHl4SlZIUUVZbW5oMnNCTG14?= =?utf-8?B?YjhBd3AreWw2cjVadVlaOEllRUpNaTFYTzUwNWNiZlVFSEkxRDNqdWVjZCtq?= =?utf-8?B?YndvNWhkdk5SaTh4WTdtN0I2MDUwMWdtQWd5UFR5bzgzYVlYSzE4dmh3VktY?= =?utf-8?B?UW9WY2NMN1h6ZkJQVmtnVUlSbFdHK3FXbFdwS1FIWUMyMjNUNW1IOW1yRnVz?= =?utf-8?B?eXhCR1hOKzBCWFVtZlZqM3hPV0dHR2ZhajVMV1pKQlF0cG1kaE5WQUlGcXpy?= =?utf-8?B?WkJFbFZ0TFVkQXpEa0VzRGlZNU04UDhrMmJjNnJwSnFPMUw2ZHJqMXJxQXRT?= =?utf-8?B?OTFhWHdKTkdKZGFSeXpjZnBvN2d4RlRjS3oraUcvQ2FnUjdvODhDcWQ0QWlr?= =?utf-8?B?dmNZa2RKMXlMRGpXa1Jkc2MzQ0VqVXNwaFFQUm5QYXY0cmhMNUlreEJLN1Nv?= =?utf-8?B?QXByQ2YzMFBINHU5bE5Wc1JQZkZvZmwxTjdGU3ZWRGY3eUErRFZWSVFlUGZ5?= =?utf-8?B?YlFBSGd5UEFKbnBLdzc4eHlSTUpOd2h0SnZBSWtOdkgyMlRMemt0V3pGdHNr?= =?utf-8?B?Y3Fpb2tlUUNvNFJNYnNzNmkwbk1LV1BBbWozd3pjWTVJSWJSTlBEVnNjbUVH?= =?utf-8?B?b1ZXZm05VStMd05HZ2h2R0QrcVFmYllORHdMWTlmVUU0UU5UTzY4MVdpZm81?= =?utf-8?B?cjZWRmV0aXNITFlIb0U1bndDS0laaE1GLzlzQ25nQzRzU0JrT3ZpdDVrTFVK?= =?utf-8?B?b1FIQ2tFaHcvV2FXa1pLaCtKVkRoUE1RV0tjMThuTEJoeDB0aE9URjJxQ1dN?= =?utf-8?B?c0gyVXFsZzkvbHA2dWlDV3Fwcy9vMkdPMjhQNzBCYWYxU3NmR1NjdVpjTmdH?= =?utf-8?B?RlBlRVNKZnFUalBaYW8vSXlJL0Iza0JqV0dqdUNFQ0U1V2ppSUM2aUpHZEpZ?= =?utf-8?B?U1lpY1NrZ2pienVQRUt3dzk0UFg3U1I0aktWaXVKdmVnSjlTVDFzaWhLaGhZ?= =?utf-8?Q?nbDngFXJDjU=3D?= MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-1ff67.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 55766c3d-e08c-4715-a144-08da3b1076f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2022 09:58:32.6718 (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: BN0P223MB0248 Subject: [FFmpeg-devel] AVBufferRef from AVBuffer 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: Hi, I have a question. I wonder whether it would be acceptable to add the following function to buffer.c? ----------------------------------------------------------------------- AVBufferRef *av_buffer_ref(AVBuffer *buf) { AVBufferRef *ref = av_mallocz(sizeof(*ref)); if (!ref) return NULL; ref->buffer = buf; ref->data = buf->data; ref->size = buf->size; atomic_fetch_add_explicit(&buf->refcount, 1, memory_order_relaxed); return ref; } ----------------------------------------------------------------------- Probably some will immediately say that this would be wrong and not the way it's meant to be used, that AVBuffer needs to be treated as an opaque data structure and similar. After thinking about this for a while, I tend to think that it still fits into the picture of the AVBuffer API. The only "risk" when dealing with AVBuffer without an AVBufferRef is that the AVBuffer can get freed at any time. But "any time" doesn't mean that there's no control over it; with a custom "free" function, it is easy possible to know about the lifetime of those buffers, and thus still allowing a safe implementation. Why would I want that? I need some kind of "weak reference" mechanism, and of course not something totally new but something in the context of the AVBufferRef mechanism. The use case in brief: there's a need to have bidirectional references (some 1:1, some 1:n) between hardware device contexts and when using AVBufferRef for all of them, it would lead to circular references and device contexts wouldn't get released anymore. All this should be done in a clean and clear way and avoid having references hanging around where you might not now whether still valid or already freed and invalid. To overcome that I started with a very simple concept: - When a device context is created it is registered in a global array (with thread-safe access) and gets a reg number (1, 2, 3, ...) - When a device context is freed, it gets unregistered (removed from the array) - Now, a device context can reference other device contexts just through that number (of course not knowing whether the corresponding device is still "alive" - But this can easily be queried from the array which can return an AVBufferRef to that device on success. But here comes the problem: how to store references to the device contexts in that array? - When creating new AVBufferRefs for the device contexts, none of them would get freed anymore due to the additional reference - Storing the first AVBufferRef which is available during device creation doesn't work either, because that one could get freed while other references still exist, and the reference would be invalid then - Storing a plain pointer in the array doesn't work out either, because in that case it wouldn't be possible to return an AVBufferRef with reference counting. None of that can work, but one way that does work would be to store AVBuffer (not ..Ref) in that array. With the function above, it's possible to create AVBufferRef from AVBuffer without needing another AVBufferRef. As the registration will be unregistered when freed, there's no concern about invalid AVBuffer references. Please let me know what you think and whether that would be acceptable. Of course, other ideas are welcome as well! Thanks, softworks _______________________________________________ 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".