Re: [FFmpeg-devel] Again pre-multiplied alpha

[Niklas Haas <ffmpeg@haasn.xyz>]

On Mon, 28 Jul 2025 16:18:29 +0200 Nicolas George <george@nsup.org> wrote:
> Niklas Haas (HE12025-07-24):
> > On what component are you missing an error here?
>
> Recently I wrote: “stacking images with different kind of alpha or
> sending this kind of frames to a muxer with uncoded frames”
>
> So: at least filters and muxers with uncoded frames. The protection must
> of course go in the framework, not in individual components, that the
> ABC of proper design.
>
> And this is only what I can think of right away. Every place that uses
> the alpha component for anything other than copying must be protected.

I think this would involve more invasive changes (i.e. adding negotiation to
the avfilter code for this and ideally other properties) that you and I both
agreed is out of scope of this series.

If it makes you feel better, I could add an error message to the stacking
filters specifically, for now?

I will reiterate, I am still not sure I follow why this is the straw that
break's the camel's back in regards to miscellaneous image properties which
are not important enough to be worth full negotiation on the link layer.

You argue that premultiplied frames were an "anecdotal experimental feature"
only up until this series, but this is flat out untrue; because this series
does not change how files are decoded. In every scenario that you worry about
now getting the wrong result, you would have gotten the wrong result even
before my changes. aAide from an extra way to override the properties with
`vf_setparams`, this series adds no *new* ways of accidentally getting the
wrong result. Messing with vf_setparams without knowing what you're doing is
already generally understood as a way to shoot yourself into the foot - that
is the very purpose of the filter. (Ditto regarding intentionally mislabeling
a file using the command line options on encode)

I think that the burden falls on you to demonstrate how my changes regress
the status quo in any meaningful way rather than "users may see a new option
on vf_setparams and may start playing with it". Do you have a specific command
line, which does not involve manually overriding image properties, that would
previously give a correct result but will now give an incorrect result?

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