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 47D424997A for ; Sun, 23 Jun 2024 18:40:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5874E68D5CA; Sun, 23 Jun 2024 21:40:18 +0300 (EEST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E252168D194 for ; Sun, 23 Jun 2024 21:40:11 +0300 (EEST) Received: from 3.4.3.5.7.1.0.f.c.9.9.9.9.3.2.a.0.5.8.0.9.1.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:819:850:a239:999c:f017:5343] helo=andrews-2024-laptop.sayers) by painless-b.tch.aa.net.uk with smtp (Exim 4.96) (envelope-from ) id 1sLS8J-00GfS0-0c for ffmpeg-devel@ffmpeg.org; Sun, 23 Jun 2024 19:40:11 +0100 Date: Sun, 23 Jun 2024 19:40:04 +0100 From: Andrew Sayers To: FFmpeg development discussions and patches Message-ID: References: <20240622151334.GD14140@haasn.xyz> <71963a4a-467b-4355-90d2-6be61d96d5f1@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <71963a4a-467b-4355-90d2-6be61d96d5f1@gmail.com> Subject: Re: [FFmpeg-devel] [RFC]] swscale modernization proposal 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 Sun, Jun 23, 2024 at 02:57:31PM -0300, James Almer wrote: > On 6/22/2024 7:19 PM, Vittorio Giovara wrote: > > Needless to say I support the plan of renaming the library so that it can > > be inline with the other libraries names, and the use of a separate header > > since downstream applications will need to update a lot to use the new > > library (or the new apis in the existing library) and/or we could provide a > > thin conversion layer when the new lib is finalized. > > I don't quite agree with renaming it. As Michael already pointed out, the av > prefix wouldn't fit a scaling library nor a resampling one, as they only > handle one or the other. > There's also the precedent of avresample, which was ultimately dropped in > favor of swresample, so trying to replace swscale with a new avscale library > will be both confusing and going against what was already established. It wouldn't confuse users, because the meaning isn't documented. Can you summarise what information "av" vs. "sw" prefixes conveys to API users? Preferably in the form of a patch to @mainpage section of libavutil/avutil.h :) _______________________________________________ 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".