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 C9CE747C3E for ; Fri, 13 Oct 2023 22:55:07 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 11EEE68C832; Sat, 14 Oct 2023 01:55:04 +0300 (EEST) Received: from haasn.dev (haasn.dev [78.46.187.166]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B5ADF68C651 for ; Sat, 14 Oct 2023 01:54:57 +0300 (EEST) Received: from haasn.dev (unknown [10.30.0.2]) by haasn.dev (Postfix) with ESMTP id 6F51643518 for ; Sat, 14 Oct 2023 00:54:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=haasn.xyz; s=mail; t=1697237697; bh=yVlr2MZg3dlhDReYmqXTKz+NKgQ3Xd6X4LeYiDWIpjI=; h=Date:From:To:Subject:In-Reply-To:References:From; b=Ke2PAPouCk8MtTeVypAkK6THop5BLhmCP79cmK5poqjj3y/AY6NRs055nAe6TcmUL oCPEvAhJDqvr/CjU9NBZIVcq1VQu9mlEgwFzuQEZS0fbq0KD6yp+bupeaDcXUlp68Q gIcWitPhrUeJbQu7SbpT+c97AGtziRVTf+GlkVZY= Date: Sat, 14 Oct 2023 00:54:57 +0200 Message-ID: <20231014005457.GB123737@haasn.xyz> From: Niklas Haas To: ffmpeg-devel@ffmpeg.org In-Reply-To: <22919b35-2f3a-494f-8f34-e40e628263f2@gmail.com> References: <20231013191934.GQ3543730@pb2> <20231014003409.GB5462@haasn.xyz> <22919b35-2f3a-494f-8f34-e40e628263f2@gmail.com> MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion 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 Fri, 13 Oct 2023 19:42:44 -0300 James Almer wrote: > Anton wrote and pushed an AVFrame based API. It can surely be > improved/extended to use AVFrame metadata. Yes, this is actually a good idea. This API endpoint already has the "correct" signature, so we could definitely re-use it (and SwsContext) instead of introducing a new header file. But to be clear, even with this sws_scale_frame API, you currently still need to configure the SwsContext up-front - and that is the source of problems IMO. I think the entire family of sws_getContext/sws_init_context/sws_setColorspaceDetails are buggy, unmaintainable nightmares. Starting from scratch, this context would not exist at all. All required metadata is available in the AVFrame itself, and it's trivial to invalidate the internal state when something changes. The function itself should be effectively stateless, with the SwsContext serving as a mere cache. So maybe a good path forwards is: 1. Make sws_scale_frame explicitly ignore the configured colorspace details in favor of AVFrame metadata. 2. Allow using sws_scale_frame with an SwsContext that has not been initialized, but merely allocated. 3. Deprecate sws_scale and the old configuration API Then SwsContext would be serving double-duty between being the configuration struct for the legacy API, while also being a cache for the new API, until eventually being just the latter. _______________________________________________ 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".