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 009CF42997 for ; Wed, 6 Apr 2022 17:36:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DB92668B137; Wed, 6 Apr 2022 20:36:30 +0300 (EEST) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 45D6F68AE7C for ; Wed, 6 Apr 2022 20:36:25 +0300 (EEST) Received: by mail-yb1-f182.google.com with SMTP id y38so5279291ybi.8 for ; Wed, 06 Apr 2022 10:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HiASVsQGTby1jd5139NjiswX9fB8EvekwaVmV7WzP1A=; b=ZrqZ91zA8kZq31wdtgDTeorFukyaOgBeMgX+6F20AXOVDJopyS0Cer/nw+1lI7/IG4 PMqCU76AwIbn0D1o5+SQRJYRib46TeYb/MrGVRrlkq6EH7KDNy23JKhHxfG1jwyAkd6w uBX+LqxzpMsrlXeKcWxliGHGXbkG04C4mxaPMWkMwKTXi2e/JkdQvdu/z9BZ3zozUGRm Zzkm70q8WzosBMnn1Z7ortxvJgN/5e/U6sx5rRwF/lq2vN5alHQjqX2IHn6VQx0Q3V5c SNCOeDNzCtF7UAqjd5//G9/+IIKGJoIwyb18wtzDSc76oUI5OikGxjAnv1jtxbIVhGZY HJmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HiASVsQGTby1jd5139NjiswX9fB8EvekwaVmV7WzP1A=; b=pW3lTDckw8qAGaRoT6rxK71chiot7XNcUdLdyDQf9RRWxnXz4mVZEtE4LSIWMvNPaE xMJVqItYidPY/8vlN58uWjWX/mWzE1XMOExTc+LvOTLhx9ZH2wNEGaHGnuiQuxOFpztS fmOnTezUrz2EtZxKNA7TH05JMfsZDvcO5dAdS/l3iinrRn3FJZrdulMdq6sdvBYWDmbQ utAZeyxpDFQEEX5icK66nYWbHsqjp5CS5BUNfGaBPLPL0fV2+mSdtGbaIo3eduyqZZXl yjL394ks7P23oCfx0mS2ahPWgr6htvOEFDzOC0wWCd0ESllAyQ8tHcTKGHVDG1R8fQrq T2Yw== X-Gm-Message-State: AOAM5312ycetypZiyJpIRh356H/Y4oIWNWa+5UuR4jjeKGXV9a6mAtao 2VF2KCWX7wBGzQOrAj5bHpyrnI9NfvVQFdDPLYPv7nj6 X-Google-Smtp-Source: ABdhPJxtsZcg36zngycpYHbxvFUrfhDP4HstMrHNP2LInFJ7qDRr7+8WBKCyif8I1tRIYz3XDX6Vlp7lJHtimLvij3Y= X-Received: by 2002:a05:6902:50a:b0:63d:b158:a306 with SMTP id x10-20020a056902050a00b0063db158a306mr7104418ybs.571.1649266583696; Wed, 06 Apr 2022 10:36:23 -0700 (PDT) MIME-Version: 1.0 References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> <164923451378.24258.12863595879743109558@lain.red.khirnov.net> In-Reply-To: From: Paul B Mahol Date: Wed, 6 Apr 2022 19:38:36 +0200 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: On Wed, Apr 6, 2022 at 6:30 PM Soft Works wrote: > > > > -----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. > > > 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. > > Not gonna happen, not gonna block progress because of whim of single random contributor. > Regards, > softworkz > _______________________________________________ > 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". > _______________________________________________ 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".