From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 3D07044F84 for ; Tue, 13 Dec 2022 11:58:18 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6FDE868BD28; Tue, 13 Dec 2022 13:58:15 +0200 (EET) Received: from nef.ens.fr (nef2.ens.fr [129.199.96.40]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B375668BC16 for ; Tue, 13 Dec 2022 13:58:07 +0200 (EET) 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 2BDBw5dv019950 for ; Tue, 13 Dec 2022 12:58:06 +0100 Received: by phare.normalesup.org (Postfix, from userid 1001) id D6A9DE0082; Tue, 13 Dec 2022 12:58:05 +0100 (CET) Date: Tue, 13 Dec 2022 12:58:05 +0100 From: Nicolas George To: FFmpeg development discussions and patches Message-ID: References: <20221209124941.GB66771@haasn.xyz> <20221209165011.GF3806951@pb2> <20221213122347.GB31360@haasn.xyz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20221213122347.GB31360@haasn.xyz> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef.ens.fr [129.199.96.32]); Tue, 13 Dec 2022 12:58:06 +0100 (CET) Subject: Re: [FFmpeg-devel] Towards YUVJ removal 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 (12022-12-13): > So, the biggest roadblock I see with regards to making color range etc. > part of filter negotiation is that, currently, color range (and > colorspace and so on) are part of AVFrame, which can (in theory and > possibly also in practice) change suddenly mid-stream. That is not a problem, a lot of properties are part of AVFrame yet are not supposed to change mid-stream in libavfilter, starting with the resolution. The real issue is not a hard one, but an expensive one: the negotiation code requires a lot of refactoring, and before that testing coverage, before we can comfortably add new negotiated properties. I am not familiar with color ranges. Are they orthogonal to pixel formats or do they depend on them? In other words, should we negotiate them both at once, like sample rate, sample format and channel layout, or should we decide the pixel format first and then the color range? The plan I have for refactoring the negotiation can do both, but the second one will require more work. > How about having a special conversion layer exist only in front of > encoders (e.g. inside avcodec_send_frame) to deal with incoming frames > that have mismatched metadata relative to what the encoder supports? I do not like that idea. But since the real negotiation requires a lot of work, I will not oppose. Just make sure it is unobtrusive and easily removed later. 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".