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 D4851480A7 for ; Thu, 8 Feb 2024 20:32:32 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0CF8A68D145; Thu, 8 Feb 2024 22:32:31 +0200 (EET) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 30A0D68CACA for ; Thu, 8 Feb 2024 22:32:24 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1707424343; bh=lDm/xkq8Z8lhrXxkd6UMScbRy9cJZU4sqRxjnejcTEg=; h=Date:From:To:Subject:In-Reply-To:References:From; b=Ru6EsVs57rubsY3P03LZrHpHjCr/2cuGPsygw1euApAM0Zt6z+QVxMXZgG0vd7y0L ttokSemvNGxn2eeUWBRJZCsEkF82ke/sZDvunu//hVy9Hl2HVDLPwyrylg3tUhNmVH HhuKjHtbAnUPi2ribqNwop1HEfKK9DeNoV9+xIfM= Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id C45B540B0C for ; Thu, 8 Feb 2024 21:32:23 +0100 (CET) Date: Thu, 8 Feb 2024 21:32:23 +0100 Message-ID: <20240208213223.GC52345@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: References: <20240205174413.92730-1-ffmpeg@haasn.xyz> <20240205193748.GB37488@haasn.xyz> <20240208123001.GD8023@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline 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: On Thu, 08 Feb 2024 13:33:51 +0100 Andreas Rheinhardt wrote: > 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. OTOH this design will necessarily either result in exponential explosion, or end up requiring the caller to make assumptions about which fields are independent (and should thus be queried separately), the moment a codec imposes *any* restriction (cartesian or not) on multiple fields at the same time. I also think that a `test()` callback, as I previously proposed, is also overkill and doesn't actually solve anything. Codecs can already error out on invalid configurations at open() time, and any practical use of such an API would also end up having to make the cartesian assumption one way or the other. So in summary, I still think that we should enforce the assumption that these fields form a cartesian set - it's simple, fast, useful and doesn't overengineer for hypothetical constraints that we couldn't realistically address one way or the other. Afaict, all current codecs support a cartesian set of metadata, but feel free to correct me if I'm wrong. _______________________________________________ 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".