Re: [FFmpeg-devel] [PATCH] lavfi: protection against premultiplied alpha (was: The patch series about premultiplied alpha)

[Niklas Haas <ffmpeg@haasn.xyz>]

On Mon, 11 Aug 2025 11:32:56 +0200 Nicolas George <george@nsup.org> wrote:
> Niklas Haas (HE12025-08-11):
> > I still think this series overall is a step in the wrong direction; and that
> > our goal should be to move towards negotiation, and not towards some IMO hacky
> > flag that is already deprecated on arrival.
>
> In terms of work, this patch series is 5% trivial code easily removed
> and 95% work that is necessary for real negotiation.
>
> Which means this patch series is a step in the right direction anyway.

Updated https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20031 with full negotiation
for the alpha mode. I also went ahead and fixed the drawutils filters to support
premultiplied alpha, since it was low-hanging fruit.

Now all the filters you were concerned about should be protected from receiving
premultiplied alpha, at filter graph configuration time.

>
> > However, I decided I would rather just implement the full negotiation at this
> > point, to save ourselves the continued discussion; especially in light of the
> > TC's inaction / radio silence.
> >
> > Can you confirm that, if we implement full negotiation (thus allowing every
> > filter to decide for itself which alpha modes it can ingest), your remaining
> > your remaining objection to this series would be withdrawn?
>
> Of course. I suspect you widely underestimate the amount of work
> necessary for real negotiation, but I would be happy to be proven wrong
> on this issue.
>
> As I said multiple time, work on negotiation in libavfilter must start
> with adding test coverage to avoid breaking the myriad of corner cases
> that have been implemented over the years. I would be happy to review
> your patches in this direction. Feel free to take over the old
> preliminary ones I had posted a few years ago and never pushed.
>
> But whatever you choose, negotiation or hackish flag, I will stand firm
> on the fact that the default must be to protect users from creating
> invalid output.
>
> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> 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".