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 3198A42946 for ; Wed, 6 Apr 2022 11:15:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id F1A2A68B23A; Wed, 6 Apr 2022 14:15:22 +0300 (EEST) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A2EFB68B0D3 for ; Wed, 6 Apr 2022 14:15:16 +0300 (EEST) Received: by mail-yb1-f170.google.com with SMTP id o62so3461681ybo.2 for ; Wed, 06 Apr 2022 04:15:16 -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=GJtH0WzS3y2CH5LU9dMLSc0JvabBGui0H5a+AtOQTRk=; b=Wb4b3xChB7UIpJPiCLQLh62hSYECywvyKa+7WFaR3j14ucZhDkIUmImyO1/ngaQExf 0rqEceGH61PORqxw74msVNLHsX0xectY/U/5tT5LLoElGTEauNn9RVdEKILbq8xSVpk6 a/Vj05TdtARIXAIOFdApcZRmyF0P4UOIUtatXH7cNwo6LocOtL3ZDjBnKfNbJR+ujq4X EsdNGYBLQwP9HJEEc43+1GyLkf0pUJBJ4u5msjp7C/NR9BxR6TGCjU1FPbdSCoshZiDW ckVgHXf5j2c9Ha70t0GMSg5gxs+MiI75viCis97RswJx4+5K3mr6zDMjhmPdQWgCffUM 8+sQ== 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=GJtH0WzS3y2CH5LU9dMLSc0JvabBGui0H5a+AtOQTRk=; b=sRsLHkb7a2/WErKrKB6rpWGkkeU1rPCuEDdXhrvVdJL2xMMTnBkLQm4NhPYe6pk5OR khHvfhZIXO4zApXeuuvTKKCLkqQwIuj0R8LS6N3mz8Vi9EErEp5OY9En5lOQs8/RQMjV gJqDF/uuIOFgDfYTpVgefY8RTf5Iw+aDV8v/djREb+zoWmIKZDSPFD5eMzwnWOkOLbTD c+oay/HHUku0IdW92h8tS6XVbHDVmQ0hgj2skXMMH/WnDZFOcy7qZWbZkuD8B263lnAD AUDZISH4x8LF1SLiYHtk7X5rJjGOzuAbb+OEj8rZAz1FVAAKAwScY6ezi52FY+3P4X49 gU7g== X-Gm-Message-State: AOAM532tJJbzlG7SX6u8g+x4MmAFDhsTTQE3tkMvzRlg6nq/c4GeIP4U kwTniTnZMQ+RRJMPtTOCwJi+kwUczhr7zaTIIatS9acf X-Google-Smtp-Source: ABdhPJyUHZehIZB2ZC1ehwfWc9AqZj2ayfAN221rAi5hevY0eP89fe6QqFb9X65tCa2l9vqZJkgxQJSQGXOl+XsuN5o= X-Received: by 2002:a25:8551:0:b0:62c:2928:6f06 with SMTP id f17-20020a258551000000b0062c29286f06mr5857318ybn.586.1649243715087; Wed, 06 Apr 2022 04:15:15 -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: Wed, 6 Apr 2022 13:17:27 +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:20 PM Soft Works wrote: > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 5, 2022 11:19 PM > > To: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > 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. > > You mean like WKOFAIT? > You failed to provide useful facts to backup your claims above. So I can not take your inputs seriously at this time. _______________________________________________ > 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".