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 1303B46568 for ; Mon, 18 Dec 2023 19:58:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 53FA068CF5E; Mon, 18 Dec 2023 21:58:48 +0200 (EET) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1D09668CC0A for ; Mon, 18 Dec 2023 21:58:41 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 160B6E0007 for ; Mon, 18 Dec 2023 19:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1702929520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PZfnKfFC+z3RFhMDRO1zll1swbb229zDy6L4Cn+gNBQ=; b=EBcB4r3WVsTrHkv+MeZtpQ5OBnpQEDMX7RaXBnZIwBDY31UYZsrHc2ouEPX0emJC6Ib90V 04W2QhX1el6sZccqeqr0BXKr2nD9tFZp6BZMjxnFmK1OGZzEJozoAX0/wej3S2NBj8q0Gj krwGctIzZ/KassIjJd5K5/KoMZKFU2Iu5ElxvSS/3UApYTSnQlN+jKum4K1hBQ2Hnp00p1 ppzg4Ctilf+kjFCQpSjNAp92yF1D3fm3qGOwy2+kCbYv6/KsAMViImfEfsgis4X+x4Rdpa yopNIdlQ3q7UpDjG6oR5LDStZGJeXJKwy5JLEA86aHayo5+bqDeVcxZgYiGddg== Date: Mon, 18 Dec 2023 20:58:39 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231218195839.GX6420@pb2> References: <170245852534.8914.12550775596488175101@lain.khirnov.net> <170254011817.8914.11563902500718557350@lain.khirnov.net> <170292082501.8914.10077474434835822133@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: <170292082501.8914.10077474434835822133@lain.khirnov.net> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue 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: multipart/mixed; boundary="===============2366980785857694086==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2366980785857694086== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b/3kIrr+SWblMf9a" Content-Disposition: inline --b/3kIrr+SWblMf9a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2023 at 06:33:45PM +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2023-12-16 16:18:07) > > On date Thursday 2023-12-14 10:35:56 +0100, Nicolas George wrote: > > > Anton Khirnov (12023-12-14): > > [...] > > > > I have to strongly disagree. This is neither practically workable, > > > > nor a good goal to aim at. > > >=20 > > > And I strongly agree with Stefano. Having the tools just thin wrappers > > > around the libraries is the only way to ensure the libraries are > > > maximally useful for other applications. Otherwise, useful code will > > > only reside in the tools and be only available through a clumsy > > > command-line interface. > > >=20 > > > > This mindset IMO inevitably leads to (among > > > > other problems): > >=20 > > > > * endless scope creep > >=20 > > Scope creep is a general tendency in software, as it tends to grow > > with more functionality and use cases in mind (FFmpeg itself started > > as an MPEG decoder). OTOH there is good and bad scope creep, it is bad > > if the functionality goes beyond the original design and core use > > case, or if the extension is not carefully designed and suffers from > > assumptions which limit how the software can be used. For example, > > making constraints about where the main thread can be executed. > >=20 > > (Unrelated note: I greatly appreciate Anton's threaded architecture > > endeavor, and I'm fine with the idea that something can result broken > > as a consequence of a major redesign, but I also think we should fix > > what can be fixed rather than just dismiss that as "not useful". >=20 > The entire question here is whether SDL muxing is useful enough to > warrant massive hacks in ffmpeg CLI. I think the first question is, does this actually need "massive hacks in ffmpeg CLI" ? If you ignore the recommandition that SDL should be run from the main thread then iam not sure what change would be needed in ffmpeg CLI at all. If you do want to run it in the main thread, well theres the option for the muxer to launch a seperate process by some way internally. then it has its own main thread (not great but its a clean solution) teh 2nd question is, is SDL the only thing requireing "main thread" or some "single thread" or other limitation ? does any other decoder, encoder, muxer, demuxer, filter ... use an external lib thats not fully thread safe ? or has funny limitations ? The last option would maybe be to run some sort of AVExecutor on the main thread and allow things like muxers to que operations on it. The muxers would totally unchanged be running on a random thread but que some operation on the main thread if an external lib, driver or other needs it. Naively that feels relatively clean to me thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. --b/3kIrr+SWblMf9a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZYCkaAAKCRBhHseHBAsP q0ruAJ9BIXf1Ok8X8xiPGSGcjS4a3NB3mQCeMNFaCYwMGaQnpZIYapDhUhe0hnU= =wMJU -----END PGP SIGNATURE----- --b/3kIrr+SWblMf9a-- --===============2366980785857694086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============2366980785857694086==--