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

[Paul B Mahol <onemda@gmail.com>]

On Tue, Apr 5, 2022 at 11:20 PM Soft Works <softworkz@hotmail.com> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Paul
> > B Mahol
> > Sent: Tuesday, April 5, 2022 11:19 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@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@hotmail.com>
> > wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > Anton Khirnov
> > > > Sent: Tuesday, April 5, 2022 9:46 PM
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > devel@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.

_______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".