On Tue, Apr 5, 2022 at 11:20 PM Soft Works <softwo...@hotmail.com> wrote:
> > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 5, 2022 11:19 PM > > To: FFmpeg development discussions and patches <ffmpeg- > > de...@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 <softwo...@hotmail.com> > > wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > > > Anton Khirnov > > > > Sent: Tuesday, April 5, 2022 9:46 PM > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > de...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
