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

[Niklas Haas via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

On Thu, 14 Aug 2025 16:00:12 +0200 Nicolas George <george@nsup.org> wrote:
> Niklas Haas (HE12025-08-13):
> > 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.
>
> Nice. I must confess, I was not paying enough attention when the new
> fields were added to the negotiation. I will need a little time to
> re-familiarize myself with the code.
>
> The new patch series is not arrived on the mailing-list, apparently the
> link is random. I tried reviewing on the web thing, it is way too
> inconvenient, especially for jumping between related parts of the code.
> Please send it to the mailing-list.

You can get a raw list of patches here:

https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20031.patch

I've done you the courtesy of attaching it to this e-mail.

>
> > Now all the filters you were concerned about should be protected from receiving
> > premultiplied alpha, at filter graph configuration time.
>
> Uh… no, absolutely not. Filters using drawutils were only an obvious
> example, with drawbox a very easy test case, but the list I gave was
> never supposed to be exhaustive, it was only meant to explain the issue
> to you. There are a few other obvious examples and certainly several
> less obvious cases.
>
> Furthermore, it would not be reasonable to demand that the authors of
> future filters implement it or even think about it.

This argument works both ways.

filter authors to remember to enable support
for premultiplied alpha, even if they don't even touch the alpha plane?

>
> Which is why the default, i.e. the alpha format list set by the famework
> if the filter did not set it, must not include premultiplied.
>
> Note that it is not a sudden random requirement from me. We did it the
> same way when we added support for unknown channel layouts while keeping
> API compatibility with the forks: filters that had not been explicitly
> vetted for support were assumed to not support them. Now like before, it
> is the only reasonable way to do things.

This is not at all what I see in the commit log, which clearly states that
whether to use a whitelist or a blacklist was a matter of disagreement between
FFmpeg and libav, and upon merging the two, the FFmpeg behavior (accept all
by default) was chosen as the new default. (See commit 7ceb9e6b11)

Unlike the alpha mode, which merely affects the colorimetric interpretation
of pixel values, the channel layout actually affects the layout in memory, so
it would even be *reasonable* to be conservative when it comes to them, and
still, the default was chosen to be permissive rather than restrictive.

So if anything, the precedent, and the existing code, supports my proposal.

Lastly, I also think that turning this option into a whitelist is
unnecessarily restrictive, not to mention more invasive/bloated, because
practically all filters are compatible with both alpha types - a blacklist is
much shorter and more practical than a whitelist.

So I respectfully disagree with your preference, unless you can provide a more
sound technical argument for why this property is exceptional enough to
deserve special handling. I personally don't find it more exceptional than,
say, chroma location or color range.

---

Anyways, to avoid dragging out this discussion longer (and in light of the
TC's lack of interest), and given that we already missed the 8.0 target for
this change, I suggest we just merge this series for now; then, you can
submit a follow-up series wherein you make your proposed change of changing
the default. (Or, assuming the TC responds with a clear preference, I would
be happy to change the default behavior at that point in time)

As it stands, there is no actual regression or new bug introduced by this
series, so it is already an improvement over the status quo - delaying it
further is just letting perfect be the enemy of good, and is clearly getting
us nowhere.

With that in mind, I will push this series at the end of the week; assuming
I get another LGTM for the latest changes.

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

[-- Attachment #2: 20031.patch --]
[-- Type: application/mbox, Size: 374314 bytes --]

[-- Attachment #3: 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".