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 4376E4237F for ; Thu, 14 Apr 2022 10:00:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 9089468B334; Thu, 14 Apr 2022 13:00:02 +0300 (EEST) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 311D868B2BE for ; Thu, 14 Apr 2022 12:59:56 +0300 (EEST) Received: by mail-yb1-f174.google.com with SMTP id e71so8457480ybf.8 for ; Thu, 14 Apr 2022 02:59:56 -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=EkXNmle5JGHYx8QhqJlfNcFnqG6tIT+LEpBVsShfQmw=; b=GSatDXkJpJPwlaYmjXXAbEN699Qp+KDa80vRB1MuPjrm09RqjPWBW1w0YqhvIMdKQv tQW5C+MI6rZ0LxiwQilZugM9MnffyMRIY0ktvNod5VOimvojdBK6NHkJQYc3j6ORXZCB yyPXilOLCFWy4pbK6StCETbZYwv0xQPeSFsCDvjTZE23l/uvipyek9MinqpUj72dm/6t Usct7CIH32mVLKmtc4RTzANs5LQKYoS2QVAuLmaVrXs1rRts6gJM6H2OU3dedWNr2PJ0 giLTIrgjp9nBGJs9A8olX4owlfcT5A2DnveRVpK9zR4wI6nyzGYjgcqPfvFgfTzuj9en NRzQ== 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=EkXNmle5JGHYx8QhqJlfNcFnqG6tIT+LEpBVsShfQmw=; b=XuPQhX0Quu2RWnbYoQGGo8TxizFNrJYtKnuW2YvheRuvaVgMBpNISO06wVOAs4W8ax dObseCskK5wI1EDLqVV1jQyCNivdEOQJ/jhL19Rg4ydM5x2ajUY7HWirMiG1D8m+xmhR W75JeXZ0MQHudvLU14q/6X8W2mwVaERG5H0MA7orNBnIAKyFXcZkMp+pHENEsoOvoj5t AeZtt7jY5sUpSdz2zZiFuKsrweI2hasJoJJBYRdHR//ebtT6ikMbOk4m1pVNKD0xNn2U A8UvcoCP90brqJmJp4fQNtjo6waDBMcU661LoCeViHlBI4P/UJ2vHAdMZx7e1IozO2dF lXeg== X-Gm-Message-State: AOAM531ZmWa2aQs6OKj3rJloa9KV4GX5LLPZfWfkOxfelKvHmDX/kFid 5AQtdQh7/VmZMvtSiLoKOPJdl4StDupG201zil0ImgcA X-Google-Smtp-Source: ABdhPJwoKwPy45XflrjL/2sZ8flqCezvdREbCCOPru+xmO5+SdaYY+DIgur3bTkKMjtY+EsU0u8RDotaaAewza7NBBk= X-Received: by 2002:a25:e051:0:b0:641:dd06:e2da with SMTP id x78-20020a25e051000000b00641dd06e2damr1144042ybg.586.1649930394612; Thu, 14 Apr 2022 02:59:54 -0700 (PDT) MIME-Version: 1.0 References: <20220404113037.13070-1-anton@khirnov.net> <20220405191542.GV2829255@pb2> <164918796468.24258.6158464741625303482@lain.red.khirnov.net> <164923451378.24258.12863595879743109558@lain.red.khirnov.net> <164932035193.21047.13588447156789154824@lain.red.khirnov.net> <164966573624.21047.5872909837014503123@lain.red.khirnov.net> In-Reply-To: From: Paul B Mahol Date: Thu, 14 Apr 2022 12:02:14 +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 Wed, Apr 13, 2022 at 12:43 AM Soft Works wrote: > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 12, 2022 11:29 AM > > To: FFmpeg development discussions and patches > devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > > wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: ffmpeg-devel On Behalf Of > > Paul > > > > B Mahol > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > To: FFmpeg development discussions and patches > > > devel@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > > architecture > > > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ffmpeg-devel On Behalf > > Of > > > > > > Anton Khirnov > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > To: FFmpeg development discussions and patches > > > > > devel@ffmpeg.org> > > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > > threaded > > > > > > architecture > > > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > > Furthermore, remember that this is just the first step. > > There > > > > will > > > > > > be > > > > > > > > further patchsets converting the other components. I > > intend to > > > > > > > > upstream > > > > > > > > them gradually one after the other. Your suggestion would > > > > require > > > > > > me > > > > > > > > to > > > > > > > > instead write the whole thing at once, fighting rebase > > > > conflicts > > > > > > all > > > > > > > > the > > > > > > > > way, and then submit it as a giant utterly unreviewable > > > > patchset. > > > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > > discussing > > > > when > > > > > > > it's a minority opinion. > > > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > > When do you plan to start > > > > > > > > > > > > If you mean "start pushing the patches", then I intend to do > > that > > > > as > > > > > > they are reviewed and approved. I hope to send the > > upstreamable > > > > > > version > > > > > > of this set this week, if nobody has strong objectsions then I > > > > might > > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > > > and for how long do you think it will take until all further > > > > > > patchsets > > > > > > > will be submitted/applied? > > > > > > > > > > > > This is very hard to estimate accurately. A pessimistic guess > > > > assuming > > > > > > I > > > > > > get stuck on every stupid thing would be end of this year, but > > I > > > > hope > > > > > > for things to go much faster. > > > > > > > > > > Thanks for the reply. I'm asking because I need to decide about > > the > > > > > way I'm going to proceed with the subtitle filtering patchset. > > > > > > > > > > I think I will have to keep and continue this in private during > > this > > > > > procedure as I don't have the resources to regularly adapt and > > sync > > > > > from my (5.0 based) working branch back to the master branch. > > > > > > > > > > > > > > That is big waste of resource when not implementing thing > > properly. > > > > > > From my point of view, somebody who has never given any detailed > > > reviews, didn't state what exactly(!) he would consider to be > > "improper" > > > and never made any suggestion how the implementation would need to > > > be changed to become "proper" - doesn't have the right to make such > > > claims. > > > > > > > You never asked kindly. > > I have always asked you kindly, probably more kindly than many > others do (going through history, I just found many very kind > questions I've been asking you). > > For the specific issue about the subtitles patchset, you jumped > in on IRC, saying "it's a hack". I had asked you (kindly!) what > makes you think that it would be a hack and what you would think needs > to be changed. You never answered the question since that time, > instead you kept labeling it in all those ways. > > > I think the fundamental problem about the current situation is > that there were discussions with several other developers whose > arguments were based on theoretical considerations after reviewing > the code but without having actually worked with it and gone > through all the real-world situations that exist. > > My code though, is made to provision for all cases by providing > a high level of flexibility, which is done by having timing fields > that are redundant in some cases but are needed (and non-redundant) > in other cases. Full coverage of cases is elementary for me, though; > I can't drop it, like somebody had suggested. > > As a matter of fact, I see two chances: > > - others believe what I'm telling > or > - another developer of sufficient reputation and credibility > gets to look into the details for confirming my reasoning > > > > > That is big waste of resources > > Inclusion in ffmpeg master has always been a secondary objective > only with the intention to contribute something useful and keep > the diff-to-official at a moderate level, avoiding the effort for > adapting to upstream changes. > > Now that ffmpeg.c is about to undergo changes for the next months, > it would really be a "big waste of resources" to regularly keep > up with those changes. On the other side, I think exactly those > changes would have benefitted from many of the subtitle changes > in my patchset, as this eliminates a lot of all the special treatment > which is in place for subtitle stream handling. > > I recognize though, that interest and intentions for improvement > in this area are low; otherwise, a disagreement about two fields > more or less in AVFrame, wouldn't probably be blocking the story > as a whole. > Please provide current version of your work via link to repository. Changing AVFrame is sign that something is not implemented carefully. > > 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". > _______________________________________________ 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".