Niklas Haas (HE12025-02-27):
> Any further comments about this series?
As I said the reply I just sent: the code that prevents a component not
ready from receiving a premultiplied frame must be there immediately,
not to be added sometime later (i.e. never).
Regards,
--
Nicolas George
Niklas Haas (HE12025-02-20):
> This is true; I am thinking about adding negotiation to this in libavfilter
> down the line as well, for the same reason. I just want to get the basic
> infrastructure in place first.
Ok, but... see later.
> I don't see it as being worse than the status quo of silen
On Wed, 19 Feb 2025 21:45:37 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
> assume alpha is premultiplied, others assume it is independent. If there is
> to be any hope for order in this chaos, we need to start by de
On Thu, 20 Feb 2025 10:39:56 +0100 Nicolas George wrote:
> Niklas Haas (HE12025-02-19):
> > FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
> > assume alpha is premultiplied, others assume it is independent. If there is
> > to be any hope for order in this chaos, we ne
Niklas Haas (HE12025-02-19):
> FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
> assume alpha is premultiplied, others assume it is independent. If there is
> to be any hope for order in this chaos, we need to start by defining an enum
> for the possible range of values
> On Feb 20, 2025, at 04:45, Niklas Haas wrote:
>
> From: Niklas Haas
>
> FFmpeg currently handles alpha in a quasi-arbitrary way. Some filters/codecs
> assume alpha is premultiplied, others assume it is independent. If there is
> to be any hope for order in this chaos, we need to start by de
