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

[Anton Khirnov]

Quoting Michael Niedermayer (2022-04-05 21:15:42)
> On Mon, Apr 04, 2022 at 01:29:48PM +0200, Anton Khirnov wrote:
> > Hi,
> > this WIP patchset is the first major part of my ongoing work to change
> > ffmpeg.c architecture such that every
> > - demuxer
> > - decoder
> > - filtergraph
> > - encoder
> > - muxer
> > lives in its own thread. The advantages of doing this, beyond increased
> > throughput, would be enforced separation between these components,
> > making the code more local and easier to reason about.
> > 
> > This set implements threading for muxers. My tentative plan is to
> > continue with encoders and then filters. The patches still need some
> > polishing, especially the last one. Two FATE tests do not yet pass, this
> > will be fixed in later iterations.
> > 
> > Meanwhile, comments on the overall approach are especially welcome.
> 
> I agree that cleanup/modularization to make the code easier to
> understand is a good idea!
> Didnt really look at the patchset yet.
> I assume these changes have no real disadvantage ?

Playing the devil's advocate, I can think of the following:
1) ffmpeg.c will hard-depend on threads
2) execution flow will become non-deterministic
3) overall resource usage will likely go up due to inter-thread
   synchronization and overhead related to new objects
4) large-scale code changes always carry a higher risk of regressions

re 1): should not be a problem for any serious system
re 2): I spent a lot of effort to ensure the _output_ remains
       deterministic (it actually becomes more predictable for some
       cases)
re 3): I expect the impact to be small and negligible, respectively, but
       would have to be measured once the conversion is complete
re 4): the only way to avoid this completely would be to stop
       development

Overall, I believe the advantages far outweigh the potential negatives.

-- 
Anton Khirnov