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

[Paul B Mahol]

On Wed, Apr 6, 2022 at 6:30 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: Wednesday, April 6, 2022 10:42 AM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded
> > architecture
> >
> > 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.
>
> The gain is not to be seen in having an alternate run-mode in
> longer-term term perspective. It is about avoiding a single
> point-of-no-return change which may have fundamental consequences
> and impose debt on other developers when it would no longer be possible
> to compare to the previous mode of operation.
>
> > 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.
>
> I understand that, but I'm not talking about re-development. Let me try
> explain it in a different way:
>
> What I mean is to go through your patches one after another but apply
> only those parts that do not affect the current single-threaded execution
> flow - effectively separating out those parts. Then, you go through
> the remaining changes and make corresponding "similar" changes to the
> working code, making it get as close as possible to your original code.
> It's an iterative process. At the end you should have just a small set
> of changes left which make up the difference between the working code
> (still following the traditional flow) and the threaded execution flow.
> That last set of differences can be finally applied in a way that it
> can be activated/deactivated by an option.
>
> When you have been working on this for so long already, then this would
> make up just a small part of the total work.
>
>
Not gonna happen, not gonna block progress because of whim of single random
contributor.


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