[FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Paul
> B Mahol
> Sent: Thursday, April 14, 2022 12:02 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architecture
> 
> On Wed, Apr 13, 2022 at 12:43 AM Soft Works <softworkz at hotmail.com>
> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Paul
> > > B Mahol
> > > Sent: Tuesday, April 12, 2022 11:29 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at 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
> <softworkz at hotmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf
> Of
> > > Paul
> > > > > B Mahol
> > > > > Sent: Monday, April 11, 2022 10:52 PM
> > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > devel at 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
> > > <softworkz at hotmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On
> Behalf
> > > Of
> > > > > > > Anton Khirnov
> > > > > > > Sent: Monday, April 11, 2022 10:29 AM
> > > > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > > > devel at 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.

Yup, will do shortly, please give me a few days.

Thanks,
sw