On Sat, 02 Aug 2025 11:40:54 +0200 Nicolas George <geo...@nsup.org> 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. > > No it does not. You just need to add a flag “this filter supports > premultiplied alpha” and have the framework throw an error if the flag > is not set.
I don't think you understand the problem here. Such a flag would accomplish nothing, since there are no filters that would actually set it. > > 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. > > That is the point: you are making a change to make it work. You are > officializing support, do it properly. > > [...] > > I do not understand why you want to use past sloppiness to justify > present sloppiness when you could treat it as low-hanging fruits. What you are doing amounts to letting perfect be the enemy of good. I don't see anything "sloppy" in my commits; they are introducing a well-scoped feature with well-defined semantics that correspond to user expectation, and you are essentially blocking it because you want it to do more than it does? Would it be nice if libavfilter could negotiate all AVFrame properties? Yes. Is that a reasonable requirement for adding new AVFrame field? No. > You want the glory? Do the work. As I pointed in the first paragraph, it > is quite easy. It certainly would have taken you less time than arguing > with me. I could easily mirror this sentiment back at you. If you want libavfilter to negotiate everything and the kitchen sink, you are more than welcome to submit patches yourself. That's how open source works. Last time I checked, you do not pay me to implement your desires, so why should I invest undue effort implement your feature requests? The nice thing about open source is that entitled users can just be ignored. > By the way, there is another flaw that I just noticed in this series: it > does not have any transverse user documentation. Sure you added the > documentation for the options, but it also need a few paragraphs to > explain to the user what premultiplied alpha is and what to do with it. But also according to you, it is an "obscure expert-level feature"; so which is it? A super useful user-facing feature that needs to be documented meticulously, or an obscure option for experts who know what they are doing? Personally, I am more inclined to believe in the latter, so I don't see what all the fuss is about. --- Anways, unless you have more concrete feedback, I am going to consider the current version of this series (on ForgeJo) as final and merge it in ~72H if there is no further (legitimate) objection. If you disagree with that, I suggest we involve the TC, as I don't see us making more grounds here. > > -- > 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".
