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

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

Regards,
softworkz