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

[Anton Khirnov]

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.

> 
> Not that I wouldn't welcome the performance improvements, but one
> concern I have is debugging filtergraph operations. This is already 
> a pretty tedious task in itself, because many relevant decisions 
> are made in sub-sub-sub-sub-sub-functions, spread over many places.
> When adding an additional - not even deterministic - part to the 
> game, it won't make things easier. It could even create situations
> where it could no longer be possible to replicate an error in a 
> debugger - in case the existence of a debugger would cause a variance
> within the constraints of the non-determinism range. 

I don't think debugging filtegraph internals will get significantly
harders, it might even become slightly easier because you will have a
thread entirely dedicated to filtering, with nothing else going on in
it.

> 
> From another point of view, this is a change, so fundamental like
> ffmpeg(.c) hasn't seen in a long time.
> I would at least suppose that this could cause issues at many ends,
> and from experience, there may be additional ends where it's rather
> unexpected to  have effects.
> 
> In that context, I think that doing a change of such a wide scope
> in an irreversible way like this, would impose quite a burden on
> many other developers, because sooner or later, other developers
> will run into situations where something is no longer working like 
> before and you'll regularly wonder whether this might be a consequence
> of ffmpeg.c threading change or caused by other changes.
> But then, you won't be able anymore to bisect on that suspicion,
> because the threading change can't be reverted and (as long as it's
> not shortly after the change) there might have been too many other 
> changes to easily port them back to a state before the threading
> change.
> 
> I wonder whether this couldn't be done in a way that the current
> behavior can be preserved and activated by option?
> 
> Wouldn't it be possible to follow an approach like this:
> 
> - Assuming the code would be fine and it would mark the desired 
>   end result
> - Put it aside and start over from the current HEAD
> - Iteratively morph the code current code in a (possibly) long
>   sequence of refactoring operations where every single one
>   (and hence in sum) are semantically neutral - until the code
>   is turned more and more into what has already been developed
> - eventually, only few differences will be left, and these can 
>   be made switchable by an option - as a result, both - old and
>   new operation modes would be available.

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.

-- 
Anton Khirnov