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 94EEF4BD85 for ; Thu, 24 Jul 2025 11:12:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 18DCB68D73E; Thu, 24 Jul 2025 14:12:02 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 4C75E68D1ED for ; Thu, 24 Jul 2025 14:11:55 +0300 (EEST) Received: from haasn.dev (unknown [10.30.1.1]) by haasn.dev (Postfix) with UTF8SMTP id 0F109418EF for ; Thu, 24 Jul 2025 13:11:55 +0200 (CEST) Date: Thu, 24 Jul 2025 13:11:54 +0200 Message-ID: <20250724131154.GB95314@haasn.xyz> From: Niklas Haas To: FFmpeg development discussions and patches In-Reply-To: References: <20250723135626.1390296-1-ffmpeg@haasn.xyz> <20250723171838.GB1401694@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline 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: 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 different kind of alpha or > sending this kind of frames to a muxer with uncoded frames. That is no worse than the status quo, so I fail to see how this patch is a regression in this regard. 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. 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 (perhaps a good STF 2025 candidate?), I think that rather exceeds the scope of this patchset. > > 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". _______________________________________________ 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".