From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
by master.gitmailbox.com (Postfix) with ESMTP id 1CD18428E1
for <ffmpegdev@gitmailbox.com>; Tue, 5 Apr 2022 19:46:13 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C8BCF68B1FE;
Tue, 5 Apr 2022 22:46:11 +0300 (EEST)
Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DEBDF68B186
for <ffmpeg-devel@ffmpeg.org>; Tue, 5 Apr 2022 22:46:05 +0300 (EEST)
Received: from localhost (localhost [IPv6:::1])
by mail0.khirnov.net (Postfix) with ESMTP id 4EFBC240179
for <ffmpeg-devel@ffmpeg.org>; Tue, 5 Apr 2022 21:46:05 +0200 (CEST)
Received: from mail0.khirnov.net ([IPv6:::1])
by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024)
with ESMTP id mLHxknFfzpxm for <ffmpeg-devel@ffmpeg.org>;
Tue, 5 Apr 2022 21:46:04 +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 95F3F2400F5
for <ffmpeg-devel@ffmpeg.org>; Tue, 5 Apr 2022 21:46:04 +0200 (CEST)
Received: by lain.red.khirnov.net (Postfix, from userid 1000)
id AEEF21601AD; Tue, 5 Apr 2022 21:46:04 +0200 (CEST)
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
In-Reply-To: <20220405191542.GV2829255@pb2>
References: <20220404113037.13070-1-anton@khirnov.net>
<20220405191542.GV2829255@pb2>
Mail-Followup-To: FFmpeg development discussions and patches
<ffmpeg-devel@ffmpeg.org>
Date: Tue, 05 Apr 2022 21:46:04 +0200
Message-ID: <164918796468.24258.6158464741625303482@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 <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/164918796468.24258.6158464741625303482@lain.red.khirnov.net/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>
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.
--
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".