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 CD5E348760 for ; Sat, 16 Dec 2023 15:18:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AA9D068D154; Sat, 16 Dec 2023 17:18:17 +0200 (EET) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DB60468D140 for ; Sat, 16 Dec 2023 17:18:10 +0200 (EET) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-551437d5344so2026984a12.1 for ; Sat, 16 Dec 2023 07:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702739889; x=1703344689; darn=ffmpeg.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=HoJs9LturZz2dTjR7Pe+9EgBHVZI9eJ4WcW4JmvBp6I=; b=bLoLmyJsC5O1/S3+Z6VsXJkq1nt41q2OJFUGZRhOv6Gev2FWFscyPP2+a9vLUOI00p KTsIPnLkEGkN2PvdVpje4ip3SZV3+AM52YCv/cvsl3hAajgYCqJraFbEaLhNKR5nTYxo nTtu8mHH/pBASQaU9/4EspQVR618m0mc7qNt8h1m9T5IXmgm4o7Iv9ibnD/2tYE51zsm zk9TZTNH9lYCZCDMF6/MFGa9p+PCYtb8YNluo4/26t9MmMy0TYmLV5PLV65mm0qN5hfO erfS2HZMMfyqeGcqyzMVNX8xmhY4FQUW/06p93wsV2c2Vc6CFUAEUA8JDq7dJ0qjB9u9 9BnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702739889; x=1703344689; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HoJs9LturZz2dTjR7Pe+9EgBHVZI9eJ4WcW4JmvBp6I=; b=OL+8qQkO+B2ntrXkNegphs9jcYT1Bh6FIthqJs7jhNmKUoUWfoAX0FTY6J2RDdx3ro 8pKgVtcejpGwl67eZV5cQ0Pvkuz+GUQt/XrgceoOxVnAZiGECX8G3LujvKZLMiyI+AaH fOIyuA+ESRPMQwngaaT2KLnvHg1qWi3DgClZ58ngS1A6REWUPEWI6ffdZq2HvAF0YRmG jvREASDEZTBqIXf1Kd8BVwUrsxDqEJvNAxtEZ7NnVLJGAA3cR23SW8zFzWrSDied6Jbj vQB/Y3lwdPxr5AMiZL8fN2QFU4dgpvkwUna6W45S9Mthe2kTLKX41akTfxpGYfY8hHd4 To4Q== X-Gm-Message-State: AOJu0YyBWsh/MS9VKt5Ih2vkkjrcFw86HT4ImKsvn6Rc7KM8fuXeBSKF F/nm0CbxGSanm8yK+W0jfp77O2JoWSU= X-Google-Smtp-Source: AGHT+IF4c6VS3nBWKikOoVwvwytQmVRMNLqaBUiUvODfdORDmtvOdTQGSo6MGFRBimdPU1MphhOwpg== X-Received: by 2002:a50:d499:0:b0:552:e362:ea4f with SMTP id s25-20020a50d499000000b00552e362ea4fmr1116160edi.69.1702739889438; Sat, 16 Dec 2023 07:18:09 -0800 (PST) Received: from mariano (dynamic-adsl-84-220-189-10.clienti.tiscali.it. [84.220.189.10]) by smtp.gmail.com with ESMTPSA id o23-20020aa7dd57000000b00552cf686df3sm1399433edw.52.2023.12.16.07.18.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Dec 2023 07:18:08 -0800 (PST) Received: by mariano (Postfix, from userid 1000) id A8F2DBFCDA; Sat, 16 Dec 2023 16:18:07 +0100 (CET) Date: Sat, 16 Dec 2023 16:18:07 +0100 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: Mail-Followup-To: FFmpeg development discussions and patches References: <170245852534.8914.12550775596488175101@lain.khirnov.net> <170254011817.8914.11563902500718557350@lain.khirnov.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) Subject: Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue 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 date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote: > Anton Khirnov (12023-12-14): [...] > > I have to strongly disagree. This is neither practically workable, > > nor a good goal to aim at. > > And I strongly agree with Stefano. Having the tools just thin wrappers > around the libraries is the only way to ensure the libraries are > maximally useful for other applications. Otherwise, useful code will > only reside in the tools and be only available through a clumsy > command-line interface. > > > This mindset IMO inevitably leads to (among > > other problems): > > * endless scope creep Scope creep is a general tendency in software, as it tends to grow with more functionality and use cases in mind (FFmpeg itself started as an MPEG decoder). OTOH there is good and bad scope creep, it is bad if the functionality goes beyond the original design and core use case, or if the extension is not carefully designed and suffers from assumptions which limit how the software can be used. For example, making constraints about where the main thread can be executed. (Unrelated note: I greatly appreciate Anton's threaded architecture endeavor, and I'm fine with the idea that something can result broken as a consequence of a major redesign, but I also think we should fix what can be fixed rather than just dismiss that as "not useful". Also this is a community project, so it's not only Anton's responsibility to fix that, since we all benefit from his work). > > * bloated, inefficient, and buggy libraries, trying (and failing) to > > support every use case under the sun > > * myopic API design aimed at fulfilling the needs of precisely one > > caller; this is a problem e.g avfilter badly suffers from, and to a > > lesser extent avformat Note that these two statements conflicting. If you try to support most of the use cases, it will be flexible by definition. For example, if we design the API to be only usable from ffmpeg.c, it will be limited in scope and usefullness. Desigining something which is generic, flexible, and efficient at the same time is hard, but that does not mean that it cannot be done. > I see no argument supporting this opinion of yours. Quite the opposite, > over the years, Stefano and others, including me, have made some headway > in this direction without hitting these pitfalls. Same here, these sound like vague statements, and I fail to see how they are related to that very generic design vision. _______________________________________________ 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".