[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
> Anton Khirnov
> Sent: Thursday, April 7, 2022 10:33 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-06 18:29:53)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Wednesday, April 6, 2022 10:42 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-05 23:05:57)
> > > > do I understand it right that there won't be a single-thread
> > > > operation mode that replicates/corresponds the current behavior?
> > >
> > > Correct, maintaining a single-threaded mode would require massive
> > > amounts of extra effort for questionable gain.
> >
> > The gain is not to be seen in having an alternate run-mode in
> > longer-term term perspective. It is about avoiding a single
> > point-of-no-return change which may have fundamental consequences
> > and impose debt on other developers when it would no longer be
> possible
> > to compare to the previous mode of operation.
> 
> I don't understand where your apocalyptic language is coming from.
> Yes,
> overall this will be a very big change.

Should it turn out that the switch will go smoothly and easily 
without (minimal) issues, then I'll sincerely admit that my concerns 
were exaggerated and unjustified.

> 
> Threads are not magic. It is ubiquitous well-understood technology
> that
> has been around for decades. Yes, they do involve their own
> challenges,
> but so does everything else, including the status quo.
> 
> The current architecture of ffmpeg.c is, in my opinion, unsustainable.

Agreed.

> There is barely any separation of responsibilities. E.g. filtering
> code
> will modify muxer state, etc. It is very hard to understand the code
> behaviour in various scenarious (we have SO MANY options), and how
> will
> some code change affect it. This makes adding new major features much
> more painful than it should be. I am firmly convinced that these
> patches
> will make the code significantly easier to understand.

No doubt about that.

> Sorry, this does not seem a reasonable request to me. For one thing,
> the
> only advantage you claim involve highly hypothetical doomsday
> scenarios
> where you cannot compare to the old code and so ALL IS LOST. That
> smells
> like a cargo cult. The current code is not holy scripture determining
> how things should work for all eternity. It has bugs, inconsistencies,
> and poorly handled corner cases (some of which are fixed by this very
> patchset).

As mentioned, the concern is about the transition not about carrying
this for a long time.

> 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 and for how long do you think it will 
take until all further patchsets will be submitted/applied?

Thanks,
sw