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 83582412F6 for ; Fri, 20 May 2022 11:53:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 96A1C68B48F; Fri, 20 May 2022 14:53:44 +0300 (EEST) Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 19ECE68AE3C for ; Fri, 20 May 2022 14:53:39 +0300 (EEST) Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-e5e433d66dso10016546fac.5 for ; Fri, 20 May 2022 04:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=sJXtyk0RiA1TvTQc7TiuqMAgCyo74WvgEMCSK3ggh6k=; b=df9aH0SCj34Q9Y+nl/UGzslBVudjuCrCdhaXIrv6LthGqWdyQnwlVBAbqd6IbJhboJ leuUTteR0+lfSeUwS1Hcai09i63hMs81YPHcolqUwZplTjIpiOw7hK0oTtTaENAcjPko 2cG/A82NwPlRKF0dck0lC4QH1gD24N9BWqdOmEszcx/q58xO6MostkCDGhEIA+gHPjrn wkZD+ljty5EPuK/MoOkmxNlZTbMXxLh6vG5tZ6xjr6/D9ztL7UoO+qkuK/jZ9ozpPGpm lyOdfIinqzwQ0/oJpHGAt77ieT7vxbhtjUvpPdty54g4pn4z2NAXFmNGD/6dAEZ4fML2 MeYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=sJXtyk0RiA1TvTQc7TiuqMAgCyo74WvgEMCSK3ggh6k=; b=3wtz9DvuB07avilbSSwo2/Hkvh/hnnsi3RD4DdPNq2uqMEXUROIvgudc0ViaV1FbP4 G3mZlmf/4nbgeR0amawshc2K53JHcvlgY2SwGM5M8kt2xtcwsZPbOnnaPoUiVdeQt8ka SlNSmSjRT26wNBZH863GKpFjOndTL/2S02XPImzIzjfoDmu4vRy7ZBvHYUDcxCH8IP/8 NUNskHP/0db8Metcq+UndWU46Oh9Ohhbefwxlg3NCE6qiWjaqDgfOuZqSL4ZZFwhVOp1 +eQ+00fkZ8n+D+X2COg0NK//gOQvEMqJMiikdEBF3Scno/t3QrlxeQfnuYm/nEWjav9+ W2/g== X-Gm-Message-State: AOAM5318todAviax2mOEc18qItxE+yXi5v+LMrnB28TKqHwWhx4dgHd0 0njIGq3yCBUIXaU+Mma0oD+OewYUwWg= X-Google-Smtp-Source: ABdhPJzxX4adNSNuKHzqK3waOpfFNZ2b1HlTRLxf8lUQECOVnZqaFX19DvxBKpCrSQNINEfjsApSpg== X-Received: by 2002:a05:6870:e3c1:b0:d7:2dc8:7fd0 with SMTP id y1-20020a056870e3c100b000d72dc87fd0mr5410810oad.104.1653047617291; Fri, 20 May 2022 04:53:37 -0700 (PDT) Received: from [192.168.0.13] ([186.136.131.95]) by smtp.gmail.com with ESMTPSA id n26-20020a9d64da000000b0060adbf4f89dsm754853otl.77.2022.05.20.04.53.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 May 2022 04:53:36 -0700 (PDT) Message-ID: <1d00bdb9-cf77-aa08-1799-db77d2548d0c@gmail.com> Date: Fri, 20 May 2022 08:53:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220518151817.21270-1-leo.izen@gmail.com> <20220518182338.GR396728@pb2> <20220518182748.GS396728@pb2> <20220520102815.GT396728@pb2> From: James Almer In-Reply-To: <20220520102815.GT396728@pb2> Subject: Re: [FFmpeg-devel] [PATCH v4] avutil/csp: create avpriv API for colorspace structs 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 5/20/2022 7:28 AM, Michael Niedermayer wrote: > On Wed, May 18, 2022 at 08:27:48PM +0200, Michael Niedermayer wrote: >> On Wed, May 18, 2022 at 08:23:38PM +0200, Michael Niedermayer wrote: >>> On Wed, May 18, 2022 at 11:18:17AM -0400, Leo Izen wrote: >>>> This commit moves some of the functionality from avfilter/colorspace >>>> into avutil/csp and exposes it as an avpriv API so it can be used by >>>> libavcodec and/or libavformat. >>> [...] >>>> +#ifndef AVUTIL_CSP_H >>>> +#define AVUTIL_CSP_H >>>> + >>>> +#include "libavutil/pixfmt.h" >>>> + >>>> +typedef struct AVLumaCoefficients { >>>> + double cr, cg, cb; >>>> +} AVLumaCoefficients; >>>> + >>>> +typedef struct AVPrimaryCoefficients { >>>> + double xr, yr, xg, yg, xb, yb; >>>> +} AVPrimaryCoefficients; >>>> + >>>> +typedef struct AVWhitepointCoefficients { >>>> + double xw, yw; >>>> +} AVWhitepointCoefficients; >>> >>> As said, these should not be floating point. >>> Adding a new public API and changing it later is messy, this >>> should be changed before its made public >> >> i now see you replaced some public by avpriv in the latest patch >> but still i think this should be changed to fixed point or AVRational >> first. Even as API between the libs its messy to change it later >> it would require us to keep the double API when its changed until >> the next major bump > > I see some discussion related to this on the IRC log from when i was > sleeping. Maybe it would be better to keep this on the mailing list > > Also iam not sure my concern was clearly worded so ill sort my argument > and concerns so its clearer below: > > 1. exactly representing values > if you have a 0.1 you can represent that exactly as AVRational 1/10 but > maybe shockingly a double cannot. > > Try a printf %f of 0.1 and it will do 0.100000 looks good but thats deception > try that with more precission %100.99f shows this: > 0.100000000000000005551115123125782702118158340454101562500000000000000000000000000000000000000000000 > > so if we want to use exactly the values from the spec, doubles with a > unit/base of 1 do not work. > int or even doubles with a base/unit of 30000 might work exactly if > AVRational is unpopular. 30000 instead of 10000 is for that one pesky 1/3 > > 1b. the exact value that 0.1 has in float/double depends on the precission > IEEE float > 0.100000001490116119384765625000000000000000000000000000000000000000000000000000000000000000000000000 > IEEE double > 0.100000000000000005551115123125782702118158340454101562500000000000000000000000000000000000000000000 > long double > 0.100000000000000000001355252715606880542509316001087427139282226562500000000000000000000000000000000 > So there will be slight differences if (intermediate) types anywhere arent > exactly the same > > 2. someone said, you need to pick a denominator when doing float -> rational > av_d2q() will pick the best denominator for you. > > 3. avpriv_ vs av_ > avpriv is evil, it combines the pain of ABI/API compatibility while the > public cant use it Not making it public allows us to not commit to a fixed design *now*. Unless there's a clear need for this to be part of the public API, i don't think it's a good idea to do so. This change is being made because this API is afaict needed in lavc, and not by some project using lavu. Removing/changing an avpriv symbol or struct is a matter or waiting for the nearest major bump. No need for an arbitrary 2 year wait period, compat wrappers, or anything crazy. > > 4. rounding, regressions and inexactness > doubles/floats have in the past broken regression tests. They do not > always but i suggest we avoid them when theres no clear advantage > like higher speed in speed relevant code or much simpler code > > thx > > > [...] > > > _______________________________________________ > 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". _______________________________________________ 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".