On Wed, Apr 13, 2022 at 12:43 AM Soft Works <softwo...@hotmail.com> wrote:
> > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 12, 2022 11:29 AM > > To: FFmpeg development discussions and patches <ffmpeg- > > de...@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 <softwo...@hotmail.com> > > wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Paul > > > > B Mahol > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > de...@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 > > <softwo...@hotmail.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf > > Of > > > > > > Anton Khirnov > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > > > de...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
