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 D17404936A for ; Thu, 8 Feb 2024 12:32:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0F38D68D147; Thu, 8 Feb 2024 14:32:07 +0200 (EET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04olkn2038.outbound.protection.outlook.com [40.92.73.38]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EFB256801F2 for ; Thu, 8 Feb 2024 14:31:59 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RWliBu8mx5BiWe5B6Ek0wBUtSe9HLT8QAMOQhdNPh8KaRBZ3N1mSTffwm2MlJctfKkht81WkUZcJJDtrXswG6h4dK+coKLLOvjIU96JxrYRGjPG8MZqUGnHqRVE+RkSRplWoYspD7NI2LJ6sCjFjth/bfck7HCD/FLHlFM3nFFyCfW2u3tYwD9VCMIdrhU+L4Us0TX+BQSko7CciS1OJeitwIppl+ar4jkAdVey5LJOZOJN04k+QFiZRzXgaWOrz/u13g+3GmJWpYAn+R1Z3XzBUOmP8qN4lTRSLvqTvCNUxu0K0cY8H4gcF/ihG5dnR5GFrgE+EnsdBMZcmrDIQhg== 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=eSqxcS6cAIr/SD/MgI76wJJYj2Mp7k+8FtNkxKgb3jo=; b=gK34RswX8fSG28St2lq8LnpCUgxKHCOFZBhupgAxEk+NEb6k8NE9aoxk9xdGAWBDkpRv0ddze81TRVt4uoiEV81uFPc3eWNG3aGPXlRetb+gnKOyhJ4EyBkw4rRqvCTV5BSYDcv3R/Qm0IGtwHUbbysCR5PVtKLQEUptzO1tMOvTmfH3ugFZhwW4QeLhgyyxIZsC2tUbSwFJwudxajiJYblAk99L/BFA3xf3VKtse9/M4QBYx2YaEZVIp0wkUIYj/MVSrTV9K2my0eN9aWiC28+7CLPmHx/eYc/uRNm8AZEFZV2qa1BDD/Kn6m1Ojpk8GWZ2Ubp4RCesXjLB/gOkNw== 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=eSqxcS6cAIr/SD/MgI76wJJYj2Mp7k+8FtNkxKgb3jo=; b=VPpu1105WeecbWJ2Goy/AYiC9JCw8a1JhHUzO2/JW81HT9Q7z1imiOawsNhey8tyi0it3qe2m+ii+fc/VPSB87OPo/q1IrEfpUTsgdQtF8PsHY4y1MWEEv5b4UN7eLZCXIFCmvbrfEYEgn9F89HenZM+8zElfT8UDl/PORBrWUjwSC5TSTKMmboonzAv9TIY+k+9ssXEiHhW/fdwNuAArp6/sUD/DbKgUIUkfRf1ze/eZ+0A0XddWofjwYHfL3MybV1HvdL6blE4VWMmxqhAQJcf6KIBGnczTM2TzbiaVZvQ6+ClHmDET6mCmd4Dciv10klnNy+3jS7wNGmFwxAogw== Received: from AS8P250MB0744.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:541::14) by PR3P250MB0308.EURP250.PROD.OUTLOOK.COM (2603:10a6:102:17f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.24; Thu, 8 Feb 2024 12:31:57 +0000 Received: from AS8P250MB0744.EURP250.PROD.OUTLOOK.COM ([fe80::65aa:deb0:a18e:d48d]) by AS8P250MB0744.EURP250.PROD.OUTLOOK.COM ([fe80::65aa:deb0:a18e:d48d%5]) with mapi id 15.20.7249.039; Thu, 8 Feb 2024 12:31:57 +0000 Message-ID: Date: Thu, 8 Feb 2024 13:33:51 +0100 User-Agent: Mozilla Thunderbird To: ffmpeg-devel@ffmpeg.org References: <20240205174413.92730-1-ffmpeg@haasn.xyz> <20240205193748.GB37488@haasn.xyz> <20240208123001.GD8023@haasn.xyz> Content-Language: en-US From: Andreas Rheinhardt In-Reply-To: <20240208123001.GD8023@haasn.xyz> X-TMN: [lKA73dWePjEkyZlVJ8u4bxdGLzEY45Yw6Hkw6LbHBTY=] X-ClientProxiedBy: FR0P281CA0220.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ac::15) To AS8P250MB0744.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:541::14) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AS8P250MB0744:EE_|PR3P250MB0308:EE_ X-MS-Office365-Filtering-Correlation-Id: 98878072-ea6c-4b5a-30a4-08dc28a1f0af X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: OmR1rd0MD4XIGIy/+LOCvHi0mVOBFKn2RcCCal2iSjzANMMrf2KK7JDC9RVDhHC+hrQkaYVMCm01zRYidvCp86Ndapk2Ck4FQCppWHIEkehynopzN80RylpurtdVmBmqYsaY8yhIiQLCKjbT2sRuwqmwc/dQF8GywD7YSiOWyDWMigJo7bkEQeaunfXVuUkX2yznVhG+Nwb/fC6mfdq461PTjR63y5WdcBZ3nZf8v9oOoCtLzDWqnRq2JwNjxhPmmcGVfF2sIFYXdUGlGmSux3g71+i9F3Goqfj5xioQuw6+h6fR0Ij3FBp5rGMdnVT0NYNChyyvEoRzUWDXzMrV50q+lHs42ldse27s8XrN+0Zhi4wczWDYAlfvD4r65uQsIO4z+NcguC5BuakNu/Qu6hSoYj4KSFfxGn6IE1sr2u/Cc1tnHjdu4/vO3HghNF3ln2ZQZOsngdHkRif48bdJQZhKYNruE4K+8AXPRI3//lZaTqstOlQXN9/RQwy+jh0Iq5THXnWofS2wDSUKzBe0UnMwM7tr0blqlCsaCcVR3BW/XOnwxcJZutVWpeYCa06X X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q3NJb1JSQi9oRXp4dk4xcnFzcS91SVZoY1R0NGY4cnoxdis3QkZoWURyVXp4?= =?utf-8?B?WHJON1RyOUhDKzRuS2dyTE15QkpIRGlsTE5uRVVnczRUanNQTTNXTzFtc1hZ?= =?utf-8?B?RStLQ1JTaitRV3RPbnBSbVIzd2xpQXMyTmwrbnRmUmpDQVVBa1lSbVltTFJT?= =?utf-8?B?aitsbGN4ZkkzR1UrYXJxTnlyRm5pRnJLRnRUdFZRSzhIRkVzUzVUWEhXMkNt?= =?utf-8?B?VzNsMlUvcnZRZjhadVdUeDBZYVF2Qk40Ni9ET3lpSmM0RVoyWUpjOWNlNm5P?= =?utf-8?B?NTJrYm1aZFhMRUlDRGtURVJZOFRYL2JDdHZPS1BFcy9RZU9iNWMwQUJOMUE5?= =?utf-8?B?L0NjM1hNaVdrK3JSNEloVGdwVEtkOXY5NFJpRDJ0d0N1WkhlUGRqQlZqNys5?= =?utf-8?B?VmU2d0tRUHFTUUJxTzJ1b3VMTVQ1czNmN2Z6Wm9WMitRKy9ZUElyVkJkdU13?= =?utf-8?B?VE0yL1ZEYkZHbm5wTU1QMnhwTEtmWTdoZ0VuUG5zVU5PcHc4L2hVWmF6aGFZ?= =?utf-8?B?RUtLVXhLTThNQnNMcE5INDdSZGV2bGwwd1d2TmJPQm5RSVhYTEhMcmQ0N2dQ?= =?utf-8?B?ZHltMFhmS0V5SVVWaDZkdjl6dU5xR2h1Qzcvb2tINlVXMUhpUEtEanVQbFlS?= =?utf-8?B?bHVHYlk5Z0Y2UkliWWtwZzdLRE9zZG1kYUpWY201dUNqUXFOeUdKSk1UQWxS?= =?utf-8?B?bE9HN1VvdWZTMnB4ZHVWVDkwUnhIM256N25hVkpOYmJTK2UyRUJQQWZHK29N?= =?utf-8?B?STB0SFJhUnFidkhCRFhzZ1JxZEVzY2xianQySWpPU2cxMmNsUzhwVk5TZk9i?= =?utf-8?B?K2MrS2lYdm9wamxqSys0eGJxemlwZnl6ck9aWU96cmk3OWcxTnFMc1BRQWQ1?= =?utf-8?B?Ui9seTYvd05kZ0t0SmUyN3RoZGJrM1NUWVNRMFIvalIrUjE2ZjAwZGdvS0Vh?= =?utf-8?B?TGZrSmFvMmJlaXVxQjVpZUNPVUpiNDkwVHNwN2JtU1ExT0ZBVERsODdSK0tp?= =?utf-8?B?Tm9zMzVkWWlvSlpLL0tTWWFzdkFjTVNvemFtblRvVGh2SWpxVkdxUWN1bmVO?= =?utf-8?B?UnNEN1ZhYVVGdEVoSVgwRkNRaUk4aHh2WGxMekI5djhCUDRBd2RSZEZXQ2dX?= =?utf-8?B?TlRjZHkwZUlMbmE3UG9uK25HTWhxcUUwcU1jUmNJVThVNW5ESmNOQzk2NEVH?= =?utf-8?B?b2FQaUNmem45MDY2OG5IOGRqbDFKT1FWN1UzdnN3bVNDNVVQTllVR2R6SVZK?= =?utf-8?B?N0NacDdncS90bXhsdExCNUtWcnZSemRiSWw4dmltZ0xaMmF6RFB5UFRWNm1K?= =?utf-8?B?amZhV01mOFZPSFJ0T2YyWkxkM21NRzVrSHlpNFhIV1NJQVFEWTlmODRGblpq?= =?utf-8?B?RXl4ZXROR0orOHZ0OTMvcEtRR2YxeW42a25pTkVXaWMrZmhKclhHVEwwYWQ2?= =?utf-8?B?aEFGb3Y2UlNHZHpjeXkvVk1GM1FLMmZHbldONi85aTRQSVBFNlNJZkNGNmZZ?= =?utf-8?B?K2FBdVp0OXQweE12ZGR0M2F3Wk0xaEo4cWZiKytxemVrNWQyQW9kV1F5MURK?= =?utf-8?B?ZXB3cXFhZUNrTFU1bFF6Y0x4V21PMmdKdzA2ZC8wQ1NpV01aV2xqMTV3RWNK?= =?utf-8?B?QytONHZCa3Z5K0pyNDRWUHc0Y2xxUTRUaTZNVmk0WU05RTZjVVJZaCtoUGoz?= =?utf-8?Q?pOf6GJq1r3U7LiXWX90c?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98878072-ea6c-4b5a-30a4-08dc28a1f0af X-MS-Exchange-CrossTenant-AuthSource: AS8P250MB0744.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2024 12:31:57.4909 (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: PR3P250MB0308 Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add YUV color space metadata to AVCodec 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: Niklas Haas: > On Mon, 05 Feb 2024 19:37:48 +0100 Niklas Haas wrote: >> On Mon, 05 Feb 2024 19:04:30 +0100 Andreas Rheinhardt wrote: >>> This presumes the relevant states to be a cartesian product. Which need >>> not be true. A callback would be better; this would also allow to base >>> the list on other values already set in an AVCodecContext. And if this >>> were extended, it would also allow to remove init_static_data one day. >>> It is furthermore quite wasteful to store color_ranges in a list, >>> although there are only very few states for it. >> >> What signature would you propose for such a callback? > > Well, there are two fundamental approaches here: > > 1. The callback somehow sets or returns a list of supported colorspaces. > 2. The callback accepts a particular configuration and simply returns if > it's supported or not, with fields set to AVCOL_*_UNKNOWN being > ignored. > > The first case has the pro of simplicity, and the ability to enumerate > more easily, but the drawback of only being scalable if we return > a cartesian set (i.e. set each attribute list independently, rather than > generating one big list). > > The second case has the pro of flexibility, and the ability to handle > non-cartesian use cases, but the con of being slightly more awkward to > recover a list (for e.g. filtering purpose). Fortunately, we can recover > the minimal cartesian superset of the actual supported set in O(n) time, > and then still verify the exact format chosen at encode time. > > One possibility could be to add a `test()` callback which simply tests > if the current codec context has valid parameters. For example: > > struct AVCodecContext { > ... > int (*test)(const AVCodecContext *ctx); > } > > But this suggests a very stateful API, where you have to mutate > AVCodecContext in order to query what formats would be supported. > I don't like this. > > So probably it makes more sense to just directly ingest a new struct > for this purpose, which we can then extend easily. (Or should we just > ingest AVFrame directly, i.e. int (*test_avframe)(ctx, AVFrame *frame)?) Sorry for not answering earlier. My intention is to allow users who only want to deal with the common case of a cartesian product to continue to do so, but to also support other usecases. The public function would look like int avcodec_get_supported_config(const AVCodecContext *avctx, const AVCodec *codec, int **supported_configs, unsigned desired_configs, unsigned flags, void *logctx); avctx can be NULL (in which case this allows to return all potential configurations, irrespective of e.g. the level of strictness). codec can be omitted if avctx->codec is set, but if both are supplied and avctx->codec is set, they have to match (like in avcodec_open2()). desired_configs is a bitfield of configs that the user wants to get information about; your patch would have to add flags for color_ranges and color_spaces. supported_configs will on return point to something like an array of struct { int desired_config0, desired_config1,...;}. The order of the entries will be fixed (say coincide with the order of the bits in the desired_configs bitfields). If one member is the unspec value for its type, then this means that it works with everything. supported_configs will be allocated; ownership passes to the user. Using a multidimensional sentinel (that would depend on desired_configs) is clumsy, so there will be two supported ways for this (depends upon a flag to be supplied in flags): One method that really adds a multidimensional sentinel, the other method that writes the number of entries into **supported_configs, so that the first entry starts at (*supported_configs)[1]. This allows users that only want to deal with the factors of a cartesian product separately to continue to do so. - 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".