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 EC02C40B62 for ; Thu, 7 Apr 2022 08:32:44 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id AD0CF68B21F; Thu, 7 Apr 2022 11:32:41 +0300 (EEST) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 49F6368AB00 for ; Thu, 7 Apr 2022 11:32:34 +0300 (EEST) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 392C6240179 for ; Thu, 7 Apr 2022 10:32:33 +0200 (CEST) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ub2iftOIz03J for ; Thu, 7 Apr 2022 10:32:32 +0200 (CEST) Received: from lain.red.khirnov.net (lain.red.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.red.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id 6CEDF2400F5 for ; Thu, 7 Apr 2022 10:32:32 +0200 (CEST) Received: by lain.red.khirnov.net (Postfix, from userid 1000) id ED3DA1601AD; Thu, 7 Apr 2022 10:32:31 +0200 (CEST) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CDM8P223MB0365578F1CE056F4081C563EBAE79=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?= References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> =?utf-8?q?=3C?= =?utf-8?q?DM8P223MB036517C3185EE467B97EF6B6BAE49=40DM8P223MB0365=2ENAMP223?= =?utf-8?q?=2EPROD=2EOUTLOOK=2ECOM=3E?= <164923451378.24258.12863595879743109558@lain.red.khirnov.net> =?utf-8?q??= =?utf-8?q?=3CDM8P223MB0365578F1CE056F4081C563EBAE79=40DM8P223MB0365=2ENAMP2?= =?utf-8?q?23=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches Date: Thu, 07 Apr 2022 10:32:31 +0200 Message-ID: <164932035193.21047.13588447156789154824@lain.red.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture 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: Quoting Soft Works (2022-04-06 18:29:53) > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Wednesday, April 6, 2022 10:42 AM > > To: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > Quoting Soft Works (2022-04-05 23:05:57) > > > do I understand it right that there won't be a single-thread > > > operation mode that replicates/corresponds the current behavior? > > > > Correct, maintaining a single-threaded mode would require massive > > amounts of extra effort for questionable gain. > > The gain is not to be seen in having an alternate run-mode in > longer-term term perspective. It is about avoiding a single > point-of-no-return change which may have fundamental consequences > and impose debt on other developers when it would no longer be possible > to compare to the previous mode of operation. I don't understand where your apocalyptic language is coming from. Yes, overall this will be a very big change. But it will also be composed of many individual patches that can be understood on their own. And I am not a drive-by contributor, you can always just ask if something is unclear. Threads are not magic. It is ubiquitous well-understood technology that has been around for decades. Yes, they do involve their own challenges, but so does everything else, including the status quo. The current architecture of ffmpeg.c is, in my opinion, unsustainable. There is barely any separation of responsibilities. E.g. filtering code will modify muxer state, etc. It is very hard to understand the code behaviour in various scenarious (we have SO MANY options), and how will some code change affect it. This makes adding new major features much more painful than it should be. I am firmly convinced that these patches will make the code significantly easier to understand. > > If I understand correctly what you're suggesting then I don't believe > > this approach is feasible. The goal is not "add threading to improve > > performance", keeping everything else intact as much as possible. The > > goal is "improve architecture to make the code easier to > > understand/maintain/extend", threads are a means towards that goal. > > The > > fact that this should also improve throughput is more of a nice side > > effect than anything else. > > > > This patchset already changes behaviour in certain cases, making the > > output more predictable and consistent. Reordering it somehow to > > separate "semantically neutral" patches would require vast amounts of > > extra work. Note that progressing at all without obviously breaking > > anything is already quite hard --- I've been working on this since > > November and this is just the first step. I really do not want to make > > my work 10x harder for the vague benefit of maybe making some > > debugging > > slightly easier. > > I understand that, but I'm not talking about re-development. Let me try > explain it in a different way: > > What I mean is to go through your patches one after another but apply > only those parts that do not affect the current single-threaded execution > flow - effectively separating out those parts. Then, you go through > the remaining changes and make corresponding "similar" changes to the > working code, making it get as close as possible to your original code. > It's an iterative process. At the end you should have just a small set > of changes left which make up the difference between the working code > (still following the traditional flow) and the threaded execution flow. > That last set of differences can be finally applied in a way that it > can be activated/deactivated by an option. > > When you have been working on this for so long already, then this would > make up just a small part of the total work. Sorry, this does not seem a reasonable request to me. For one thing, the only advantage you claim involve highly hypothetical doomsday scenarios where you cannot compare to the old code and so ALL IS LOST. That smells like a cargo cult. The current code is not holy scripture determining how things should work for all eternity. It has bugs, inconsistencies, and poorly handled corner cases (some of which are fixed by this very patchset). Furthermore, remember that this is just the first step. There will be further patchsets converting the other components. I intend to upstream them gradually one after the other. Your suggestion would require me to instead write the whole thing at once, fighting rebase conflicts all the way, and then submit it as a giant utterly unreviewable patchset. That is a good recipe for never getting this finished. -- Anton Khirnov _______________________________________________ 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".