[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: Wednesday, April 6, 2022 1:17 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:20 PM Soft Works <softworkz at hotmail.com>
> wrote:
> 
> >
> >
> > > -----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?
> >
> 
> You failed to provide useful facts to backup your claims above.
> 
> So I can not take your inputs seriously at this time.

I was just wondering What Kind Of F..funny Acronym Is That?
(knowing you won't find it, after being too lazy to lookup yours..)

Getting serious again - I will answer your question, but please 
give me some time until I'm back to work in this area, then I'll 
explain in detail and provide the callstacks that I meant.

Thanks,
softworkz