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

[Anton Khirnov]

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. But it will also be composed of
many individual patches that can be understood on their own. And I am
not a drive-by contributor, you can always just ask if something is
unclear.

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

> > If I understand correctly what you're suggesting then I don't believe
> > this approach is feasible. The goal is not "add threading to improve
> > performance", keeping everything else intact as much as possible. The
> > goal is "improve architecture to make the code easier to
> > understand/maintain/extend", threads are a means towards that goal.
> > The
> > fact that this should also improve throughput is more of a nice side
> > effect than anything else.
> > 
> > This patchset already changes behaviour in certain cases, making the
> > output more predictable and consistent. Reordering it somehow to
> > separate "semantically neutral" patches would require vast amounts of
> > extra work. Note that progressing at all without obviously breaking
> > anything is already quite hard --- I've been working on this since
> > November and this is just the first step. I really do not want to make
> > my work 10x harder for the vague benefit of maybe making some
> > debugging
> > slightly easier.
> 
> I understand that, but I'm not talking about re-development. Let me try
> explain it in a different way:
> 
> What I mean is to go through your patches one after another but apply 
> only those parts that do not affect the current single-threaded execution
> flow - effectively separating out those parts. Then, you go through 
> the remaining changes and make corresponding "similar" changes to the
> working code, making it get as close as possible to your original code.
> It's an iterative process. At the end you should have just a small set 
> of changes left which make up the difference between the working code
> (still following the traditional flow) and the threaded execution flow.
> That last set of differences can be finally applied in a way that it 
> can be activated/deactivated by an option.
> 
> When you have been working on this for so long already, then this would
> make up just a small part of the total work.

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).

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
is a good recipe for never getting this finished.

-- 
Anton Khirnov