[FFmpeg-devel] Again pre-multiplied alpha

[Nicolas George]

Niklas Haas (HE12025-08-02):
> I don't think you understand the problem here.

… says somebody who has misunderstood what I was suggesting twice in a
row.

> Such a flag would accomplish
> nothing, since there are no filters that would actually set it.

Yes, your job involves setting this flags on filters you know will not
corrupt output when subjected to premultiplied alpha.

> What you are doing amounts to letting perfect be the enemy of good.

No, that would be require real negotiation.

What I am asking is called a compromise: I demand less than I would want
but more than what you are offering.

And I do not think that adding a flag is too much to ask.

>								I don't
> see anything "sloppy" in my commits; they are introducing a well-scoped feature
> with well-defined semantics that correspond to user expectation, and you
> are essentially blocking it because you want it to do more than it does?

It is not true that it corresponds to user expectation. Quite the
opposite, it increases the risk of user corrupting their data.

> Would it be nice if libavfilter could negotiate all AVFrame properties? Yes.
> Is that a reasonable requirement for adding new AVFrame field? No.

For the third time, it is not what I am asking you to. So please refrain
from burning that straw man a fourth time.

> Last time I checked, you do not pay me to implement your desires, so why
> should I invest undue effort implement your feature requests?

Last time I checked, we are all volunteers.

My purpose is to keep the code and behavior as good as possible.

Yours is…? I do not know? Score a few commits? Get a feature in quickly
because you need it in another project?

> But also according to you, it is an "obscure expert-level feature"; so
> which is it? A super useful user-facing feature that needs to be documented
> meticulously, or an obscure option for experts who know what they are doing?

Even an obscure expert-level feature requires documentation.

> Anways, unless you have more concrete feedback, I am going to consider the
> current version of this series (on ForgeJo) as final and merge it in ~72H
> if there is no further (legitimate) objection.
> 
> If you disagree with that, I suggest we involve the TC, as I don't see us
> making more grounds here.

Then I will.

-- 
  Nicolas George