Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH v4] avutil/csp: create avpriv API for colorspace structs
Date: Fri, 20 May 2022 12:28:15 +0200
Message-ID: <20220520102815.GT396728@pb2> (raw)
In-Reply-To: <20220518182748.GS396728@pb2>


[-- Attachment #1.1: Type: text/plain, Size: 3686 bytes --]

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

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
    

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

  reply	other threads:[~2022-05-20 10:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 15:18 Leo Izen
2022-05-18 18:23 ` Michael Niedermayer
2022-05-18 18:27   ` Michael Niedermayer
2022-05-20 10:28     ` Michael Niedermayer [this message]
2022-05-20 11:26       ` Ronald S. Bultje
2022-05-20 13:11         ` Michael Niedermayer
2022-05-20 13:39           ` Ronald S. Bultje
2022-05-20 11:53       ` James Almer
2022-05-20 13:23         ` Michael Niedermayer
2022-05-20 15:50         ` Anton Khirnov
2022-05-20 16:02           ` Leo Izen
2022-05-20 16:33         ` Niklas Haas
2022-05-20 12:08       ` Leo Izen
2022-05-20 17:20       ` Niklas Haas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220520102815.GT396728@pb2 \
    --to=michael@niedermayer.cc \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git