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
On Sat, 02 Aug 2025 11:40:54 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-29):
> > 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.
>
> N
Niklas Haas (HE12025-07-29):
> 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.
No it does not. You just need to add a flag “this filter supports
prem
On Mon, 28 Jul 2025 16:18:29 +0200 Nicolas George 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
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 t
Michael Niedermayer (HE12025-07-28):
> About STF, it depends on who does the work.
> If a FFmpeg developer does the work, then i think STF is a good idea.
> OTOH It would be an inappropriate task for a new contributor (like in GSoC).
Indeed, way too hard for somebody who does not already know liba
Hi Niklas
On Thu, Jul 24, 2025 at 01:11:54PM +0200, Niklas Haas wrote:
> On Wed, 23 Jul 2025 19:02:06 +0200 Nicolas George wrote:
> > Niklas Haas (HE12025-07-23):
> > > [PATCH v2 05/18] avcodec/encode: enforce alpha mode compatibility at
> > > encode time
> >
> > That handles it for encoders, I
On Thu, 24 Jul 2025 16:59:24 +0200 Nicolas George wrote:
> Right now, I an not demanding negotiation, I am just requiring
> protection:
>
> if (frame->is_premultiplied && !out->supports_premultiplied) {
> av_log(ctx, AV_LOG_ERROR, "Your data is about to be
> corrupted bec
Niklas Haas (HE12025-07-24):
> That is no worse than the status quo, so I fail to see how this patch is
> a regression in this regard.
Until now, premultiplied frames were an anecdotal experimental feature
with barely any documentation: only people who knew what they were doing
were supposed to us
On Wed, 23 Jul 2025 19:02:06 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-23):
> > [PATCH v2 05/18] avcodec/encode: enforce alpha mode compatibility at encode
> > time
>
> That handles it for encoders, I suppose. But I do not see anything
> protecting you from stacking images with differ
Niklas Haas (HE12025-07-23):
> [PATCH v2 05/18] avcodec/encode: enforce alpha mode compatibility at encode
> time
That handles it for encoders, I suppose. But I do not see anything
protecting you from stacking images with different kind of alpha or
sending this kind of frames to a muxer with unco
On Wed, 23 Jul 2025 16:11:45 +0200 Nicolas George wrote:
> Niklas Haas (HE12025-07-23):
> > Changes since v1:
> > - Correctly implement alpha mode tagging for JPEG XL
> > - Set correct alpha mode for OpenEXR (which is always premultiplied)
> > - Ensure -alpha_mode specified on the command line cor
Niklas Haas (HE12025-07-23):
> Changes since v1:
> - Correctly implement alpha mode tagging for JPEG XL
> - Set correct alpha mode for OpenEXR (which is always premultiplied)
> - Ensure -alpha_mode specified on the command line correctly propagates
> - Print out a warning when overriding the alpha
13 matches
Mail list logo
