On Mon, 28 Jul 2025 16:18:29 +0200 Nicolas George <geo...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
