[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: 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.

softworkz