From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id D2D294BDB4 for ; Thu, 24 Jul 2025 14:59:35 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id A08F568D724; Thu, 24 Jul 2025 17:59:31 +0300 (EEST) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTPS id 06EF968D6DA for ; Thu, 24 Jul 2025 17:59:24 +0300 (EEST) X-ENS-nef-client: 129.199.129.80 ( name = phare.normalesup.org ) Received: from phare.normalesup.org (phare.normalesup.org [129.199.129.80]) by nef.ens.fr (8.14.4/1.01.28121999) with ESMTP id 56OExOtm018768 for ; Thu, 24 Jul 2025 16:59:24 +0200 Received: by phare.normalesup.org (Postfix, from userid 1001) id 347342EFE3; Thu, 24 Jul 2025 16:59:24 +0200 (CEST) Date: Thu, 24 Jul 2025 16:59:24 +0200 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20250723135626.1390296-1-ffmpeg@haasn.xyz> <20250723171838.GB1401694@haasn.xyz> <20250724131154.GB95314@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250724131154.GB95314@haasn.xyz> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Thu, 24 Jul 2025 16:59:24 +0200 (CEST) Subject: Re: [FFmpeg-devel] Again pre-multiplied alpha X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 use it, and if they corrupted their output by getting it wrong the blame was on them. With this patch series, it becomes an officially supported feature, people who know nothing will start using it. That requires more guardrails against accidental corruption of the output. > That aside, there is also not anything preventing you from doing the same > for images with a different chroma sample location, or different HDR metadata, > or different sample aspect ratios, or any of the other oodles of properties > (including arbitrarily extensible frame side data) that are not currently > participating in libavfilter format negotiation. The fact that we have played it fast and loose in the past should not be considered a justification to play it fast and loose now. > In a perfect world, we would have automatic format negotiation for every > AVFrame property; but as it stands, the libavfilter code is too obnoxious, > brittle and inflexible to permit such while remaining sane. While redesigning > libavfilter to make it more extensible would certainly be a useful exercise I know how to redesign the format negotiation to make it modular. But the current code requires test coverage. > (perhaps a good STF 2025 candidate?), Increasing test coverage, certainly yes. Reworking the negotiation in depth to make it modular, almost certainly no: too hard. > I think that rather exceeds the scope > of this patchset. 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 because it comes as premultiplied alpha."); return AVERROR_PATCHWELCOME; } 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".