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 8FEA9431FC for ; Mon, 25 Jul 2022 11:32:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6566268B7FA; Mon, 25 Jul 2022 14:32:10 +0300 (EEST) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 69B1A68B59D for ; Mon, 25 Jul 2022 14:32:03 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 8BA86240004 for ; Mon, 25 Jul 2022 11:32:02 +0000 (UTC) Date: Mon, 25 Jul 2022 13:32:01 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220725113201.GU2088045@pb2> References: <20220703170714.GF396728@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022 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="===============8430710695361251747==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============8430710695361251747== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zltv+KEU+AMUCOPj" Content-Disposition: inline --Zltv+KEU+AMUCOPj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 24, 2022 at 05:10:17PM +0200, Nicolas George wrote: > I hesitated a long time before replying, but all considering, at this > point expressing what is weighing on my heart cannot make things worse. >=20 >=20 > Michael Niedermayer (12022-07-03): > > What is the timeline for the audio+video merge ? >=20 > I cannot give a timeline because I do not work on FFmpeg on a schedule, > I work on FFmpeg in my free time, for fun. And lately, working on FFmpeg > has been really un-fun. Recently, my contributions have been met with I think many if us, myself included have had un-fun periods in ffmpeg. This on its own is already bad and we should strive to make project contributions more fun to all. > indifference at best (see when I proposed a XML parser six months ago: > nobody cared), outright hostility at worst. Under these circumstances, > whenever I am considering working on something FFmpeg-related, I usually > find something else more fun to do. If we add a XML parser to FFmpeg. Such a thing would be used by several bits and we need to ensure it has redundant maintainership. So i think a xml parser needs broad support by developers otherwise we run the risk that if it has a single maintainer only and that maintainer stops maintaining it that could be annoying to more than just the parser itself. I cannot remember exactly without re-reading the old thread what the issues people had with the xml parser. If it was some component of it or in genera= l. But i think its mostly a question if theres more than one person who wants to maintain it. [...] > It illustrates what it means to be a maintainer. It does not only mean > the task of reviewing and applying bug fixes. The maintainer holds in > their head a knowledge of the code that cannot be fully shared in > writing. The maintainer also holds in their head plans to evolve and > extend the code. >=20 > I have plans for libavfilter. Not just vague ideas, but precise plans on > how to reach the goal. I have plans for subtitles filtering, of course. > But not only. >=20 > I have plans for filtering data packets, so that bistream filters do not > need to have a separate and redundant API and ffmpeg does not need a > separate code path for -c copy. >=20 > I have plans for threading, or more precisely integrating filters in a > global parallelized task and I/O scheduler. >=20 > I have plans for seeking, with the seek target going back from the > output to the input(s). >=20 > I have plans for partial graph reconfiguration, to accommodate format > changes mid-stream and let applications alter filtering in the middle. >=20 > All of this is exciting. I am eager to work on any of this. >=20 > Unfortunately, before it can happen, boring things need to be done. > Parts of the framework of libavfilter are very fragile. Working on any > of these is likely to break cases that were specifically fixed in the > past. >=20 > I can work on boring things if they are necessary to reach the exciting > parts. >=20 > What I cannot do is motivate myself to work on the boring things with > the threat that the exciting things will be snatched under me by an > inferior version from somebody who just refuses to engage with the > boring necessary things. If you work on libavfilter, noone will snatch it from you. If you dont work on it, eventually someone else will attempt to take over and push libavfilter in the direction he feels best which may or may not=20 match what you want. If theres something i can do to make libavfilter work more fun for you please tell me. I think it would be best if people worked a bit more together on this. The current situation where work is split between your vission and this patchset is kind of a bad thing. Its a bit unfortunate noone involved seems to have the carismatic leader skills to pull everyone on his side and then get that side to the point that everyone is happy with the code=20 and neither has a consensus emerged based on technical arguments. I think maybe more a "what is best for the project to move forward" and a less "how can i get my hard work in first" approuch might help but we can also try the technical commiitee of course=20 but iam not sure how much that would really help, it would be better if some consensus would be reached and everyone would then work together on implementing that theres of course also the fork and merge approuch. Each side does whatever they like in their repository and then we at some point compare and merge o= ne or both into ffmpeg. Iam not sure thats a good idea or not. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. --Zltv+KEU+AMUCOPj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYt5/KQAKCRBhHseHBAsP qw3uAJ9xL/4eD8kS3cBAIAv7Jxl/TVHfuACcDXoTw9uehwT7sYsfy0w6o9m97cc= =VnWN -----END PGP SIGNATURE----- --Zltv+KEU+AMUCOPj-- --===============8430710695361251747== 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". --===============8430710695361251747==--