[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 Paul
> B Mahol
> Sent: Tuesday, April 5, 2022 11:19 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> architecture
> 
> On Tue, Apr 5, 2022 at 11:06 PM Soft Works <softworkz at hotmail.com>
> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Tuesday, April 5, 2022 9:46 PM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > > architecture
> > >
> > > 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.
> >
> > Hi,
> >
> > do I understand it right that there won't be a single-thread
> > operation mode that replicates/corresponds the current behavior?
> >
> > 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.
> >
> >
> Can you elaborate more?, otherwise this is PEBKAC.

You mean like WKOFAIT?