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 C586C428EE for ; Tue, 5 Apr 2022 21:06:10 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4B4C168B1F8; Wed, 6 Apr 2022 00:06:08 +0300 (EEST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12olkn2107.outbound.protection.outlook.com [40.92.22.107]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EB97468AF88 for ; Wed, 6 Apr 2022 00:06:00 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=epcDRVoheRhR+kiURajlRVYdUm5LPutfidZhyWIdvm6ydpqxlnAQBVrLQ/zmOBQinD/Hgz/r6G8LsPiV8h/r5+Der/yzEiOV7hI3pj+PCsYTGTbQcaIxOOJNzcNQuKHIWpJ+DATQJIHndeH2R1dazq28bNP0WcQ4mCojB0QVuoVbur3r6MeZG3sMCRH+91yqOy6jFLkbW60jAzSBM9N/W4YCK5Zn2AUYI7VGTWbr1buNyPfQWUKnK2nupH1r561dvyrPuDYy/8N6IcavqTbkAFgt3RyeR7Kxp7WVEHSGCqQKJp/BhqhWtdiNMs/gONQxvt+5Cedpi98bjVYTTMW4Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=x/waA2BawhhdLpNJAzoEkSAUgllM7qx7jxPthbSP+A8=; b=kAlTAi/aR548qQg2dv/12vVvUqKLS/SIywKxMepao606sXH/pBIpvbiwjSFRPBw3M3wfyk5Oq3QcG93CBRR+hwcH9GRI1MseinM2gxG9igTM6knfBArQ8rp+9wEdHU24lDgDVSxnVk4y42z2abFfJDjPrBPdgAzzRa4MTe1oR3C9bY/DKpcbMwOmVhxq6YX6sUIz0Av3qHl8y2VKKAKPo/B2AipuSPYqEkUJyT6MxF2+BQR/XsYVMyGtQ3exc+mw/0OhrpOrxuwYYClWVh1O2Mt0806w57ZjlzhEuPxfBpGjU6F9hzzM20SkArsDBrjvAoxNb5GwdHRgxA8+rpKWfQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x/waA2BawhhdLpNJAzoEkSAUgllM7qx7jxPthbSP+A8=; b=H3spQKpAD8UsD8aVLn6DQXQ+zH114Lt1/53kz7lg18MGB8mKeC3Bjqu/4fa2U5d9mCKWz/pVz9YU5fSb9I5AL7CR7ilwK+p/WcpkoOPfWBMWXc3P3lbqgbq5+BCrgd/XjDuHC6Qd8LvU1PaC9aVUvyywTEFW/Y5BBV7REY2Ft201CUWYvoYGT06RQ3edy/P0lMmRYxEixNjrYDnmtIC1wWhohAAtzboFmPSEySxjLQXJNo7PIsJp0i5NMTLTaLvjHvy61K2QuoVf6Wz+36OUMYqni2d03KGs9Yuk6tCht681SqydGOkWpov0ld6sQX8RCZ0FoLCYLbfkoHJAeEjFKA== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by BN0P223MB0037.NAMP223.PROD.OUTLOOK.COM (2603:10b6:408:147::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.19; Tue, 5 Apr 2022 21:05:58 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::1d14:8778:3a51:ed0]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::1d14:8778:3a51:ed0%5]) with mapi id 15.20.5123.031; Tue, 5 Apr 2022 21:05:58 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture Thread-Index: AQHYSBeuHAE+RPuGxESL7bK+MVIG+KzhsuYAgAAIfACAAAOyUA== Date: Tue, 5 Apr 2022 21:05:57 +0000 Message-ID: References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> In-Reply-To: <164918796468.24258.6158464741625303482@lain.red.khirnov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [l/HfOl8ZmbtDCXxufPYQTu1IJod7Lkmc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 628c73ae-2cc7-43d4-1d9e-08da174814cd x-ms-traffictypediagnostic: BN0P223MB0037:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2x+nysG/N/fxvrY7r8lNqqxy2SF8NQgheZ5IcCgUkvEUgezga9YMiGdXgwghKKYSgo3QbxaFZ7g4zs6fey5OAe4+aTOESfMOUKeiT4u3c06Y6oC3XTKZdWRgBvWY+9l8Oyl5xcAzJ26RBNU8SqC87sd81JGKkNMvrwDRg8h8kFC8Pn7l2iji3bezTTYvnXcFfCBfej7UDj9El5C7rWDwPvBRGCLDGW8vy8MFbUp5X1YLDwasBRGQiZ8aXA/ge8zT6jGp+2exjWadp1JxSjjvbCgJgvUK4C21yrvHe9rGmdIu23Wl0926Sb1iH5RtaJGF4XpgXHWngbd4cdFfaDLmNrcizJlNVkpkSJzVlvHkFtkyScczHUMTgD6y9XoDsqNiGvXFh8eLuarlOi2lHZ8FwDQB4ziAouRRIm3ob6CWu/ZQ//hmZvkHrbkyNEzhk8QvhJ1Er+2WoHhnuM/tQHH3WMO/py0Nn8lgkKd5m79E7EI/uNuD5jqmiJhHZxLlyHPa4NfDd131kGH9/qpaYH0EOdVkhOvwyKbWuFhuf/QxYwmh5GnN2j+HVO0ZSvqaQ0A2dBLEbIBl/4u8WfDNe8q/8A== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OHE0TlJ0c2E4QkVFYXdjWnUvdk1GeFhZMWVjQ25WcjBUKzZiODZhQ2dZSFRM?= =?utf-8?B?V0VNRXBoaG1zT1M3Qjk1QnZEMzVDcUpVRkV5dHdWcFNRUGRDSGo1dWMzbzVN?= =?utf-8?B?NEdEV1lFVDRzT2hPUkJlb2wvRHdDa1F5cWdISGoxcXRucE9qYnVnOTNveGtw?= =?utf-8?B?S0hDc2ovQ1R4eTFUV3pwaTdJcmRvSFhvRzkrR3FseDVpSkxKY1FhQ3pzNnMy?= =?utf-8?B?SWlRblJMaEJIVlVTM3owdDNuQmFudjZMSFRzYTQ2UzdnejNneUJjTE41dWR1?= =?utf-8?B?MHNEMDZZSXhsbVhVejhGazV2bkJpNG1CRmUyend2bGtJSkRyNVFkejIwc1la?= =?utf-8?B?NVYzOW9GQmtTQitxd3REUzBZN3dLSkE2MDhVM0JHMDZSZTB6SG42NTQ1dzZo?= =?utf-8?B?azYwMmhmdWl5c2w5U2FLVElvUVZVOE12SmowUnNOTVl0ejlJNnBCSTh2YWtv?= =?utf-8?B?cmxvWE1kc2k0N2ZHdFh4amIwREVjbDJJa25oNFpCa1JITk4vaWFJV2tnNktC?= =?utf-8?B?anMyd09LaUpDTmZrdDBoSWNBY0ZjTHRsMWJxK0M5VGVjamkyd2l4cDdyYm81?= =?utf-8?B?alZVMHZZNnBqUFA2aUNyOTJVWmkvSFBLUFpjVVZZdkpZdldVU0RqME0vMVF4?= =?utf-8?B?U2Q5SlArdFF2MXJMWWtXVk5uUjk3c3V4ZDdpMjBUYlA3MjRZR3M3YWxWZjAz?= =?utf-8?B?RFpwK1BoRDRtalp4K1k4TGwzUDF4azdBUE5OTlY5dmljbmVvd2ZyNXcwZ0ll?= =?utf-8?B?VFcrRVVqaEkwNW00UG02NmpmRE5sTDFVL0RjTXpHUXRqdldDUG00dlBwK1hv?= =?utf-8?B?YzVrQjNKUEE3S1NxL1NENC9sNkFxU1UvQmVlQzNsRk14bURSbDVDZUtvaWZV?= =?utf-8?B?bUhTNjZ4Mm8wZjM0MzMrV096enpZMXR4cmhrS2xVa2l0ZWVuRUJaOXZjeWo3?= =?utf-8?B?L2Zoc2haMElmNGxaU2V4L3RWUm5EU2NvOFZCek9mdDRDT3lmTnZ2eG5rZUdC?= =?utf-8?B?VVQ0SFZTaXNPdnhyVW5kbWZxdjBveVQ3cEdmaS9xc1A0clJqZmtkZ3Bnb09l?= =?utf-8?B?SkVvU0x2ZlhJaStaVUY0UHVpNlNzYkxZU294SWdVTWFpSGZoTlNCOHFRdGtv?= =?utf-8?B?UGFhWElEUTNINEVyWUhkMjVQUUJJS0ZPOWdCTER0ZkpvL3U3VjBTNTB0UW5S?= =?utf-8?B?cW55SUFFNGxYajZyTnRPQjlDNEtjRTZidjlVZzJpeEFENmFkY28xU2NJQWdB?= =?utf-8?B?TmhnM1lMbmlBRWFmQXU4NkpFc3lFcjZjSHJ0THlOVEVIbDlzcmNiZi93UG9P?= =?utf-8?B?c01LSEk1YVUxdklnaFV0cmwrUTJEY3NGOXBxZUZVeVAxOTlpd3ArU1FoQnNB?= =?utf-8?B?akhQWDBPR1l2ckkzUUliNzVNcC8wcDR0cHBzWk1MK0NCNEFMSXg2MXdaeE5Y?= =?utf-8?B?bWNiUThNak5pQjZLRWVLNlVVeDBESEhQM3ozdnlPV1Z1NkxLWHExZlZBYnlS?= =?utf-8?B?VUZmQ2dqSmQ2VGcxWXZEYjROVGZ0THNibHNxeUhKbFlOQmMxQ2ZjdEhxRmZr?= =?utf-8?B?UjNDK2w5TDBURmlkT0tWS0FsVVdocGRXWEp4MHE1MmxhT0Y3MjVIY0FVNHN2?= =?utf-8?B?Vm1ibDZ1UngyZzcwMXZjREFuRDhIY09RaWFwb2dzV0NzQk1KYzBNU0c4ajlK?= =?utf-8?B?TXlIMlVOaEtxS0tIMjVOaXEwemFGbDVoS05HUTE1T1dSbjhURUYwem9mZGtj?= =?utf-8?B?WXVKZVRIdWJLcEExZStlOS9EZTM4OUpSYjlzc1piTy9CWUpMbFRmeEY5K3Fr?= =?utf-8?B?ZDlBSnQ1TXZDTWYyQmNieEdOQnRadzVjRzNvQ1V2SXlHN2tPbmJRbGtYeWpk?= =?utf-8?B?dzJhNHRjcnAvM3lSMlJCTWFrQk9XSU9Dem1XUFNpK3JyVDJaT040QlRDZ2VQ?= =?utf-8?Q?eEqfiGPtOOM=3D?= MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-1ff67.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 628c73ae-2cc7-43d4-1d9e-08da174814cd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2022 21:05:57.9636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0P223MB0037 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: > -----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. >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".