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 D66C8428F1 for ; Tue, 5 Apr 2022 21:16:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4ED1068B1B2; Wed, 6 Apr 2022 00:16:49 +0300 (EEST) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 5F0C668AECD for ; Wed, 6 Apr 2022 00:16:42 +0300 (EEST) Received: by mail-yb1-f178.google.com with SMTP id w134so655900ybe.10 for ; Tue, 05 Apr 2022 14:16:42 -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=M4/Lfs5uvVAw1V+mWPoZxnt8nI+mXR9ltguqapr7/l4=; b=qWA9Goa6b/+R3FsxCmouhAjUEqCjVDjef0k1dcGxCz+rlKIrwFCBPn/p81XPKhT/sK uLbtgmQaDIL5FnEFYI9ME9i+TOtvMKkD+TDyAjqSEnuK8ig1KYxtMbwPKET7okbwUL3Z CUbQrEfD8RzzcrL6R2dlxoe5p1WedKKqw+h6b2WurDWEiylPFSQ/pbcvL+DsvSbneRry 719jaCsR59lGOqcwcX9E3vqIs7kwPAUkxvMLe74lsGhJqXFOLDJEykvRj09BXoZi1ycP B6FsMcLsb3p+HZ66mRua2uxxvLlYynQbZWQnQZkq7SpJu32P0GF1qE45rk9TGvl67RqV XkNQ== 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=M4/Lfs5uvVAw1V+mWPoZxnt8nI+mXR9ltguqapr7/l4=; b=jq/g2LXFKe3AfJMzp9pLGJWcXkMAUKj2ZUB64eTasG2iDl5117COhGTRC8B+0WvQIE F2XopyhIOUMhve0pidr63dhUJDTjlY0moddZNjnCvs1xaVz9wbPbie3jsKy9MRYhLCTs 5oDu7oMQBY6ZV5b+82Pr29iP5Nbj/bnPM+zI/5A5HhQiBnfiuN1CdvJXHc2T7ejsTbNb zxLtC6vthbSlGUtpg28QFmuXEFT8ubGaxaXJYdzbCKnXEB+be76AZkpCVEBkfKd8GoYV YYPWr30FL2cAP3pH7yiau3bMMqSghsC4T8fCzIpau78E4SlQMGIwSzMec5yEhzi2YUnA rG4A== X-Gm-Message-State: AOAM530Vcb66RpCsWKJ1r+Zb2t0DHE+JfhlIBgep5Vy2OZEHDMgvTHgi yO1JpXqUGfCbY2sMpJt+H3x5Whyb0HuJ6zP0q+8N3UsF X-Google-Smtp-Source: ABdhPJzZ/8SggEqZITM8qQMgbEvBm3La04CEgtUOQNfqlTpVjpZEHE2EArGESEndo7T6FYGuQEemuO8UQplrxaTtOu0= X-Received: by 2002:a5b:8cc:0:b0:634:7343:9953 with SMTP id w12-20020a5b08cc000000b0063473439953mr4298857ybq.142.1649193400541; Tue, 05 Apr 2022 14:16:40 -0700 (PDT) MIME-Version: 1.0 References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> In-Reply-To: From: Paul B Mahol Date: Tue, 5 Apr 2022 23:18:52 +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 Tue, Apr 5, 2022 at 11:06 PM Soft Works wrote: > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Tuesday, April 5, 2022 9:46 PM > > To: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > Quoting Michael Niedermayer (2022-04-05 21:15:42) > > > On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote: > > > > Hi, > > > > this WIP patchset is the first major part of my ongoing work to > > change > > > > ffmpeg.c architecture such that every > > > > - demuxer > > > > - decoder > > > > - filtergraph > > > > - encoder > > > > - muxer > > > > lives in its own thread. The advantages of doing this, beyond > > increased > > > > throughput, would be enforced separation between these components, > > > > making the code more local and easier to reason about. > > > > > > > > This set implements threading for muxers. My tentative plan is to > > > > continue with encoders and then filters. The patches still need > > some > > > > polishing, especially the last one. Two FATE tests do not yet > > pass, this > > > > will be fixed in later iterations. > > > > > > > > Meanwhile, comments on the overall approach are especially > > welcome. > > > > > > I agree that cleanup/modularization to make the code easier to > > > understand is a good idea! > > > Didnt really look at the patchset yet. > > > I assume these changes have no real disadvantage ? > > > > Playing the devil's advocate, I can think of the following: > > 1) ffmpeg.c will hard-depend on threads > > 2) execution flow will become non-deterministic > > 3) overall resource usage will likely go up due to inter-thread > > synchronization and overhead related to new objects > > 4) large-scale code changes always carry a higher risk of regressions > > > > re 1): should not be a problem for any serious system > > re 2): I spent a lot of effort to ensure the _output_ remains > > deterministic (it actually becomes more predictable for some > > cases) > > re 3): I expect the impact to be small and negligible, respectively, > > but > > would have to be measured once the conversion is complete > > re 4): the only way to avoid this completely would be to stop > > development > > > > Overall, I believe the advantages far outweigh the potential > > negatives. > > Hi, > > do I understand it right that there won't be a single-thread > operation mode that replicates/corresponds the current behavior? > > Not that I wouldn't welcome the performance improvements, but one > concern I have is debugging filtergraph operations. This is already > a pretty tedious task in itself, because many relevant decisions > are made in sub-sub-sub-sub-sub-functions, spread over many places. > When adding an additional - not even deterministic - part to the > game, it won't make things easier. It could even create situations > where it could no longer be possible to replicate an error in a > debugger - in case the existence of a debugger would cause a variance > within the constraints of the non-determinism range. > > Can you elaborate more?, otherwise this is PEBKAC. > From another point of view, this is a change, so fundamental like > ffmpeg(.c) hasn't seen in a long time. > I would at least suppose that this could cause issues at many ends, > and from experience, there may be additional ends where it's rather > unexpected to have effects. > > In that context, I think that doing a change of such a wide scope > in an irreversible way like this, would impose quite a burden on > many other developers, because sooner or later, other developers > will run into situations where something is no longer working like > before and you'll regularly wonder whether this might be a consequence > of ffmpeg.c threading change or caused by other changes. > But then, you won't be able anymore to bisect on that suspicion, > because the threading change can't be reverted and (as long as it's > not shortly after the change) there might have been too many other > changes to easily port them back to a state before the threading > change. > > I wonder whether this couldn't be done in a way that the current > behavior can be preserved and activated by option? > > Wouldn't it be possible to follow an approach like this: > > - Assuming the code would be fine and it would mark the desired > end result > - Put it aside and start over from the current HEAD > - Iteratively morph the code current code in a (possibly) long > sequence of refactoring operations where every single one > (and hence in sum) are semantically neutral - until the code > is turned more and more into what has already been developed > - eventually, only few differences will be left, and these can > be made switchable by an option - as a result, both - old and > new operation modes would be available. > > I don't know whether there's a name to this approach, probably > there is, yet I never cared. Way more important is that I always > had good results following this methodology. > The funny thing about it is, that when you have a reliable tooling > for refactoring, you can even stop thinking (well, sort of..) > while transforming the code. Also, when you can't imagine how > the end result would look like or wonder whether it would > work out at all, it's fun to watch the morphing (if you're > doing it no-brain-wise) > > 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".