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

[Paul B Mahol]

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.



>
> softworkz
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>