[FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
The code can also be obtained from branch ffmpeg_mt/mux in my tree git://git.khirnov.net/libav -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
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 ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ 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".
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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Tuesday, April 5, 2022 9:46 PM > To: FFmpeg development discussions and patches 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. >From another point of view, this is a change, so fundamental like ffmpeg(.c) hasn't seen in a long time. I would at least suppose that this could cause issues at many ends, and from experience, there may be additional ends where it's rather unexpected to have effects. In that context, I think that doing a change of such a wide scope in an irreversible way like this, would impose quite a burden on many other developers, because sooner or later, other developers will run into situations where something is no longer working like before and you'll regularly wonder whether this might be a consequence of ffmpeg.c threading change or caused by other changes. But then, you won't be able anymore to bisect on that suspicion, because the threading change can't be reverted and (as long as it's not shortly after the change) there might have been too many other changes to easily port them back to a state before the threading change. I wonder whether this couldn't be done in a way that the current behavior can be preserved and activated by option? Wouldn't it be possible to follow an approach like this: - Assuming the code would be fine and it would mark the desired end result - Put it aside and start over from the current HEAD - Iteratively morph the code current code in a (possibly) long sequence of refactoring operations where every single one (and hence in sum) are semantically neutral - until the code is turned more and more into what has already been developed - eventually, only few differences will be left, and these can be made switchable by an option - as a result, both - old and new operation modes would be
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Tue, Apr 5, 2022 at 11:06 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Tuesday, April 5, 2022 9:46 PM > > To: FFmpeg development discussions and patches > 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. > From another point of view, this is a change, so fundamental like > ffmpeg(.c) hasn't seen in a long time. > I would at least suppose that this could cause issues at many ends, > and from experience, there may be additional ends where it's rather > unexpected to have effects. > > In that context, I think that doing a change of such a wide scope > in an irreversible way like this, would impose quite a burden on > many other developers, because sooner or later, other developers > will run into situations where something is no longer working like > before and you'll regularly wonder whether this might be a consequence > of ffmpeg.c threading change or caused by other changes. > But then, you won't be able anymore to bisect on that suspicion, > because the threading change can't be reverted and (as long as it's > not shortly after the change) there might have been too many other > changes to easily port them back to a state before the threading > change. > > I wonder whether this couldn't be done in a way that the current > behavior can be preserved and activated by option? > > Wouldn't i
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Tuesday, April 5, 2022 11:19 PM > To: FFmpeg development discussions and patches 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 > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Tuesday, April 5, 2022 9:46 PM > > > To: FFmpeg development discussions and patches > > 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? ___ 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".
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. > > 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. I don't think debugging filtegraph internals will get significantly harders, it might even become slightly easier because you will have a thread entirely dedicated to filtering, with nothing else going on in it. > > From another point of view, this is a change, so fundamental like > ffmpeg(.c) hasn't seen in a long time. > I would at least suppose that this could cause issues at many ends, > and from experience, there may be additional ends where it's rather > unexpected to have effects. > > In that context, I think that doing a change of such a wide scope > in an irreversible way like this, would impose quite a burden on > many other developers, because sooner or later, other developers > will run into situations where something is no longer working like > before and you'll regularly wonder whether this might be a consequence > of ffmpeg.c threading change or caused by other changes. > But then, you won't be able anymore to bisect on that suspicion, > because the threading change can't be reverted and (as long as it's > not shortly after the change) there might have been too many other > changes to easily port them back to a state before the threading > change. > > I wonder whether this couldn't be done in a way that the current > behavior can be preserved and activated by option? > > Wouldn't it be possible to follow an approach like this: > > - Assuming the code would be fine and it would mark the desired > end result > - Put it aside and start over from the current HEAD > - Iteratively morph the code current code in a (possibly) long > sequence of refactoring operations where every single one > (and hence in sum) are semantically neutral - until the code > is turned more and more into what has already been developed > - eventually, only few differences will be left, and these can > be made switchable by an option - as a result, both - old and > new operation modes would be available. 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. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
To clarify futher, the [RFC] tag applies mainly to patches 34-49/49, which will certainly require some changes, possibly substatial ones. Previous patches should IMO be acceptable for master as they are. I would appreciate reviews for those, so I can push them sooner rather than later and thus reduce the number of future rebase conflicts. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Tue, Apr 5, 2022 at 11:20 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 5, 2022 11:19 PM > > To: FFmpeg development discussions and patches > 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 > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Anton Khirnov > > > > Sent: Tuesday, April 5, 2022 9:46 PM > > > > To: FFmpeg development discussions and patches > > > 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Wednesday, April 6, 2022 1:17 PM > To: FFmpeg development discussions and patches de...@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 > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > Paul > > > B Mahol > > > Sent: Tuesday, April 5, 2022 11:19 PM > > > To: FFmpeg development discussions and patches > > 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 > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > > > Anton Khirnov > > > > > Sent: Tuesday, April 5, 2022 9:46 PM > > > > > To: FFmpeg development discussions and patches > > > > 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 b
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Wednesday, April 6, 2022 10:42 AM > To: FFmpeg development discussions and patches de...@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. Regards, softworkz ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Wed, Apr 6, 2022 at 6:30 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Wednesday, April 6, 2022 10:42 AM > > To: FFmpeg development discussions and patches > de...@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@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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> > Not gonna happen, not gonna block progress because of whim of single random > contributor. > Agreed, this patch series is as important as buffer referencing. We can't let holdouts block progress. Kieran ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Kieran Kunhya > Sent: Wednesday, April 6, 2022 7:57 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > > > > Not gonna happen, not gonna block progress because of whim of single > random > > contributor. > > > > Agreed, this patch series is as important as buffer referencing. We > can't > let holdouts block progress. RFC Patch => Opinionated Response != Blocking ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
Quoting Soft Works (2022-04-06 18:29:53) > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Wednesday, April 6, 2022 10:42 AM > > To: FFmpeg development discussions and patches > de...@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. I don't understand where your apocalyptic language is coming from. Yes, overall this will be a very big change. But it will also be composed of many individual patches that can be understood on their own. And I am not a drive-by contributor, you can always just ask if something is unclear. Threads are not magic. It is ubiquitous well-understood technology that has been around for decades. Yes, they do involve their own challenges, but so does everything else, including the status quo. The current architecture of ffmpeg.c is, in my opinion, unsustainable. There is barely any separation of responsibilities. E.g. filtering code will modify muxer state, etc. It is very hard to understand the code behaviour in various scenarious (we have SO MANY options), and how will some code change affect it. This makes adding new major features much more painful than it should be. I am firmly convinced that these patches will make the code significantly easier to understand. > > 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. Sorry, this does not seem a reasonable request to me. For one thing, the only advantage you claim involve highly hypothetical doomsday scenarios where you cannot compare to the old code and so ALL IS LOST. That smells like a cargo cult. The current code is not holy scripture determining how things should work for all eternity. It has bugs, inconsistencies, and poorly handled corner cases (some of which are fixed by this very patchset). Furthermore, remember that this is just the first step. There will be further patchsets converting the other components. I intend to upstream them gradually one after the other. Your suggestion would require me to instead write the whole thing at once, fighting rebase conflicts all the way, and then
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Thursday, April 7, 2022 10:33 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > Quoting Soft Works (2022-04-06 18:29:53) > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Wednesday, April 6, 2022 10:42 AM > > > To: FFmpeg development discussions and patches > > de...@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. > > I don't understand where your apocalyptic language is coming from. > Yes, > overall this will be a very big change. Should it turn out that the switch will go smoothly and easily without (minimal) issues, then I'll sincerely admit that my concerns were exaggerated and unjustified. > > Threads are not magic. It is ubiquitous well-understood technology > that > has been around for decades. Yes, they do involve their own > challenges, > but so does everything else, including the status quo. > > The current architecture of ffmpeg.c is, in my opinion, unsustainable. Agreed. > There is barely any separation of responsibilities. E.g. filtering > code > will modify muxer state, etc. It is very hard to understand the code > behaviour in various scenarious (we have SO MANY options), and how > will > some code change affect it. This makes adding new major features much > more painful than it should be. I am firmly convinced that these > patches > will make the code significantly easier to understand. No doubt about that. > Sorry, this does not seem a reasonable request to me. For one thing, > the > only advantage you claim involve highly hypothetical doomsday > scenarios > where you cannot compare to the old code and so ALL IS LOST. That > smells > like a cargo cult. The current code is not holy scripture determining > how things should work for all eternity. It has bugs, inconsistencies, > and poorly handled corner cases (some of which are fixed by this very > patchset). As mentioned, the concern is about the transition not about carrying this for a long time. > Furthermore, remember that this is just the first step. There will be > further patchsets converting the other components. I intend to > upstream > them gradually one after the other. Your suggestion would require me > to > instead write the whole thing at once, fighting rebase conflicts all > the > way, and then submit it as a giant utterly unreviewable patchset. That's not what I meant, but anyway it's not worth discussing when it's a minority opinion. Just a practical question instead for planning purposes: Which timeframe do you expect for the whole process? When do you plan to start and for how long do you think it will take until all further patchsets will be submitted/applied? Thanks, sw ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
Quoting Soft Works (2022-04-08 17:27:10) > > Furthermore, remember that this is just the first step. There will be > > further patchsets converting the other components. I intend to > > upstream > > them gradually one after the other. Your suggestion would require me > > to > > instead write the whole thing at once, fighting rebase conflicts all > > the > > way, and then submit it as a giant utterly unreviewable patchset. > > That's not what I meant, but anyway it's not worth discussing when > it's a minority opinion. > > Just a practical question instead for planning purposes: > > Which timeframe do you expect for the whole process? > When do you plan to start If you mean "start pushing the patches", then I intend to do that as they are reviewed and approved. I hope to send the upstreamable version of this set this week, if nobody has strong objectsions then I might push it after vacation, i.e. late April/early May. > and for how long do you think it will take until all further patchsets > will be submitted/applied? This is very hard to estimate accurately. A pessimistic guess assuming I get stuck on every stupid thing would be end of this year, but I hope for things to go much faster. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Monday, April 11, 2022 10:29 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > Quoting Soft Works (2022-04-08 17:27:10) > > > Furthermore, remember that this is just the first step. There will > be > > > further patchsets converting the other components. I intend to > > > upstream > > > them gradually one after the other. Your suggestion would require > me > > > to > > > instead write the whole thing at once, fighting rebase conflicts > all > > > the > > > way, and then submit it as a giant utterly unreviewable patchset. > > > > That's not what I meant, but anyway it's not worth discussing when > > it's a minority opinion. > > > > Just a practical question instead for planning purposes: > > > > Which timeframe do you expect for the whole process? > > When do you plan to start > > If you mean "start pushing the patches", then I intend to do that as > they are reviewed and approved. I hope to send the upstreamable > version > of this set this week, if nobody has strong objectsions then I might > push it after vacation, i.e. late April/early May. > > > and for how long do you think it will take until all further > patchsets > > will be submitted/applied? > > This is very hard to estimate accurately. A pessimistic guess assuming > I > get stuck on every stupid thing would be end of this year, but I hope > for things to go much faster. Thanks for the reply. I'm asking because I need to decide about the way I'm going to proceed with the subtitle filtering patchset. I think I will have to keep and continue this in private during this procedure as I don't have the resources to regularly adapt and sync from my (5.0 based) working branch back to the master branch. Thanks, softworkz ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Mon, Apr 11, 2022 at 10:10 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Anton Khirnov > > Sent: Monday, April 11, 2022 10:29 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > Furthermore, remember that this is just the first step. There will > > be > > > > further patchsets converting the other components. I intend to > > > > upstream > > > > them gradually one after the other. Your suggestion would require > > me > > > > to > > > > instead write the whole thing at once, fighting rebase conflicts > > all > > > > the > > > > way, and then submit it as a giant utterly unreviewable patchset. > > > > > > That's not what I meant, but anyway it's not worth discussing when > > > it's a minority opinion. > > > > > > Just a practical question instead for planning purposes: > > > > > > Which timeframe do you expect for the whole process? > > > When do you plan to start > > > > If you mean "start pushing the patches", then I intend to do that as > > they are reviewed and approved. I hope to send the upstreamable > > version > > of this set this week, if nobody has strong objectsions then I might > > push it after vacation, i.e. late April/early May. > > > > > and for how long do you think it will take until all further > > patchsets > > > will be submitted/applied? > > > > This is very hard to estimate accurately. A pessimistic guess assuming > > I > > get stuck on every stupid thing would be end of this year, but I hope > > for things to go much faster. > > Thanks for the reply. I'm asking because I need to decide about the > way I'm going to proceed with the subtitle filtering patchset. > > I think I will have to keep and continue this in private during this > procedure as I don't have the resources to regularly adapt and sync > from my (5.0 based) working branch back to the master branch. > > That is big waste of resource when not implementing thing properly. > Thanks, > softworkz > > > > > > ___ > 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Monday, April 11, 2022 10:52 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Anton Khirnov > > > Sent: Monday, April 11, 2022 10:29 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > architecture > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > Furthermore, remember that this is just the first step. There > will > > > be > > > > > further patchsets converting the other components. I intend to > > > > > upstream > > > > > them gradually one after the other. Your suggestion would > require > > > me > > > > > to > > > > > instead write the whole thing at once, fighting rebase > conflicts > > > all > > > > > the > > > > > way, and then submit it as a giant utterly unreviewable > patchset. > > > > > > > > That's not what I meant, but anyway it's not worth discussing > when > > > > it's a minority opinion. > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > Which timeframe do you expect for the whole process? > > > > When do you plan to start > > > > > > If you mean "start pushing the patches", then I intend to do that > as > > > they are reviewed and approved. I hope to send the upstreamable > > > version > > > of this set this week, if nobody has strong objectsions then I > might > > > push it after vacation, i.e. late April/early May. > > > > > > > and for how long do you think it will take until all further > > > patchsets > > > > will be submitted/applied? > > > > > > This is very hard to estimate accurately. A pessimistic guess > assuming > > > I > > > get stuck on every stupid thing would be end of this year, but I > hope > > > for things to go much faster. > > > > Thanks for the reply. I'm asking because I need to decide about the > > way I'm going to proceed with the subtitle filtering patchset. > > > > I think I will have to keep and continue this in private during this > > procedure as I don't have the resources to regularly adapt and sync > > from my (5.0 based) working branch back to the master branch. > > > > > That is big waste of resource when not implementing thing properly. >From my point of view, somebody who has never given any detailed reviews, didn't state what exactly(!) he would consider to be "improper" and never made any suggestion how the implementation would need to be changed to become "proper" - doesn't have the right to make such claims. softworkz ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Mon, Apr 11, 2022 at 10:58 PM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Monday, April 11, 2022 10:52 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Anton Khirnov > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > > architecture > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > Furthermore, remember that this is just the first step. There > > will > > > > be > > > > > > further patchsets converting the other components. I intend to > > > > > > upstream > > > > > > them gradually one after the other. Your suggestion would > > require > > > > me > > > > > > to > > > > > > instead write the whole thing at once, fighting rebase > > conflicts > > > > all > > > > > > the > > > > > > way, and then submit it as a giant utterly unreviewable > > patchset. > > > > > > > > > > That's not what I meant, but anyway it's not worth discussing > > when > > > > > it's a minority opinion. > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > When do you plan to start > > > > > > > > If you mean "start pushing the patches", then I intend to do that > > as > > > > they are reviewed and approved. I hope to send the upstreamable > > > > version > > > > of this set this week, if nobody has strong objectsions then I > > might > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > and for how long do you think it will take until all further > > > > patchsets > > > > > will be submitted/applied? > > > > > > > > This is very hard to estimate accurately. A pessimistic guess > > assuming > > > > I > > > > get stuck on every stupid thing would be end of this year, but I > > hope > > > > for things to go much faster. > > > > > > Thanks for the reply. I'm asking because I need to decide about the > > > way I'm going to proceed with the subtitle filtering patchset. > > > > > > I think I will have to keep and continue this in private during this > > > procedure as I don't have the resources to regularly adapt and sync > > > from my (5.0 based) working branch back to the master branch. > > > > > > > > That is big waste of resource when not implementing thing properly. > > From my point of view, somebody who has never given any detailed > reviews, didn't state what exactly(!) he would consider to be "improper" > and never made any suggestion how the implementation would need to > be changed to become "proper" - doesn't have the right to make such > claims. > You never asked kindly. > > softworkz > > > > ___ > 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Tuesday, April 12, 2022 11:29 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > Paul > > > B Mahol > > > Sent: Monday, April 11, 2022 10:52 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > architecture > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > > > Anton Khirnov > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > threaded > > > > > architecture > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > Furthermore, remember that this is just the first step. > There > > > will > > > > > be > > > > > > > further patchsets converting the other components. I > intend to > > > > > > > upstream > > > > > > > them gradually one after the other. Your suggestion would > > > require > > > > > me > > > > > > > to > > > > > > > instead write the whole thing at once, fighting rebase > > > conflicts > > > > > all > > > > > > > the > > > > > > > way, and then submit it as a giant utterly unreviewable > > > patchset. > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > discussing > > > when > > > > > > it's a minority opinion. > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > When do you plan to start > > > > > > > > > > If you mean "start pushing the patches", then I intend to do > that > > > as > > > > > they are reviewed and approved. I hope to send the > upstreamable > > > > > version > > > > > of this set this week, if nobody has strong objectsions then I > > > might > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > and for how long do you think it will take until all further > > > > > patchsets > > > > > > will be submitted/applied? > > > > > > > > > > This is very hard to estimate accurately. A pessimistic guess > > > assuming > > > > > I > > > > > get stuck on every stupid thing would be end of this year, but > I > > > hope > > > > > for things to go much faster. > > > > > > > > Thanks for the reply. I'm asking because I need to decide about > the > > > > way I'm going to proceed with the subtitle filtering patchset. > > > > > > > > I think I will have to keep and continue this in private during > this > > > > procedure as I don't have the resources to regularly adapt and > sync > > > > from my (5.0 based) working branch back to the master branch. > > > > > > > > > > > That is big waste of resource when not implementing thing > properly. > > > > From my point of view, somebody who has never given any detailed > > reviews, didn't state what exactly(!) he would consider to be > "improper" > > and never made any suggestion how the implementation would need to > > be changed to become "proper" - doesn't have the right to make such > > claims. > > > > You never asked kindly. I have always asked you kindly, probably more kindly than many others do (going through history, I just found many very kind questions I've been asking you). For the spe
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
Soft Works (12022-04-12): > I have always asked you kindly You have been repeatedly rude towards the people who know libavfilter well. On top of that, you have shown that you do not understand how libavfilter currently works. On top of that, you have refused to learn how libavfilter currently works. You made your bed. -- Nicolas George ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Wednesday, April 13, 2022 11:43 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > Soft Works (12022-04-12): > > I have always asked you kindly > > You have been repeatedly rude towards the people who know libavfilter > well. That treatment was exclusively reserved to yours. You had called for it. You got it. You deserved it. > On top of that, you have shown that you do not understand how > libavfilter currently works. > On top of that, you have refused to learn how libavfilter currently > works. Exactly that's one of the reasons. You keep throwing around exactly those kinds of statements without substantial content. That's purely demagogic behavior. As a long as you continue like that, you don't deserve any better responses. softworkz ___ 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".
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
On Wed, Apr 13, 2022 at 12:43 AM Soft Works wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Paul > > B Mahol > > Sent: Tuesday, April 12, 2022 11:29 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > architecture > > > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > > wrote: > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > Paul > > > > B Mahol > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > > architecture > > > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On Behalf > > Of > > > > > > Anton Khirnov > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org> > > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > > threaded > > > > > > architecture > > > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > > Furthermore, remember that this is just the first step. > > There > > > > will > > > > > > be > > > > > > > > further patchsets converting the other components. I > > intend to > > > > > > > > upstream > > > > > > > > them gradually one after the other. Your suggestion would > > > > require > > > > > > me > > > > > > > > to > > > > > > > > instead write the whole thing at once, fighting rebase > > > > conflicts > > > > > > all > > > > > > > > the > > > > > > > > way, and then submit it as a giant utterly unreviewable > > > > patchset. > > > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > > discussing > > > > when > > > > > > > it's a minority opinion. > > > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > > When do you plan to start > > > > > > > > > > > > If you mean "start pushing the patches", then I intend to do > > that > > > > as > > > > > > they are reviewed and approved. I hope to send the > > upstreamable > > > > > > version > > > > > > of this set this week, if nobody has strong objectsions then I > > > > might > > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > > > and for how long do you think it will take until all further > > > > > > patchsets > > > > > > > will be submitted/applied? > > > > > > > > > > > > This is very hard to estimate accurately. A pessimistic guess > > > > assuming > > > > > > I > > > > > > get stuck on every stupid thing would be end of this year, but > > I > > > > hope > > > > > > for things to go much faster. > > > > > > > > > > Thanks for the reply. I'm asking because I need to decide about > > the > > > > > way I'm going to proceed with the subtitle filtering patchset. > > > > > > > > > > I think I will have to keep and continue this in private during > > this > > > > > procedure as I don't have the resources to regularly adapt and > > sync > > > > > from my (5.0 based) working branch back to the master branch. > > > > > > > > > > > > > > That is big waste of resource when not implementing thing > > properly. > > > &
Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded architecture
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul > B Mahol > Sent: Thursday, April 14, 2022 12:02 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > architecture > > On Wed, Apr 13, 2022 at 12:43 AM Soft Works > wrote: > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > Paul > > > B Mahol > > > Sent: Tuesday, April 12, 2022 11:29 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a threaded > > > architecture > > > > > > On Mon, Apr 11, 2022 at 10:58 PM Soft Works > > > > wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > Paul > > > > > B Mahol > > > > > Sent: Monday, April 11, 2022 10:52 PM > > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > threaded > > > > > architecture > > > > > > > > > > On Mon, Apr 11, 2022 at 10:10 PM Soft Works > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: ffmpeg-devel On > Behalf > > > Of > > > > > > > Anton Khirnov > > > > > > > Sent: Monday, April 11, 2022 10:29 AM > > > > > > > To: FFmpeg development discussions and patches > > > > > > de...@ffmpeg.org> > > > > > > > Subject: Re: [FFmpeg-devel] [RFC] Switching ffmpeg.c to a > > > threaded > > > > > > > architecture > > > > > > > > > > > > > > Quoting Soft Works (2022-04-08 17:27:10) > > > > > > > > > Furthermore, remember that this is just the first > step. > > > There > > > > > will > > > > > > > be > > > > > > > > > further patchsets converting the other components. I > > > intend to > > > > > > > > > upstream > > > > > > > > > them gradually one after the other. Your suggestion > would > > > > > require > > > > > > > me > > > > > > > > > to > > > > > > > > > instead write the whole thing at once, fighting rebase > > > > > conflicts > > > > > > > all > > > > > > > > > the > > > > > > > > > way, and then submit it as a giant utterly > unreviewable > > > > > patchset. > > > > > > > > > > > > > > > > That's not what I meant, but anyway it's not worth > > > discussing > > > > > when > > > > > > > > it's a minority opinion. > > > > > > > > > > > > > > > > Just a practical question instead for planning purposes: > > > > > > > > > > > > > > > > Which timeframe do you expect for the whole process? > > > > > > > > When do you plan to start > > > > > > > > > > > > > > If you mean "start pushing the patches", then I intend to > do > > > that > > > > > as > > > > > > > they are reviewed and approved. I hope to send the > > > upstreamable > > > > > > > version > > > > > > > of this set this week, if nobody has strong objectsions > then I > > > > > might > > > > > > > push it after vacation, i.e. late April/early May. > > > > > > > > > > > > > > > and for how long do you think it will take until all > further > > > > > > > patchsets > > > > > > > > will be submitted/applied? > > > > > > > > > > > > > > This is very hard to estimate accurately. A pessimistic > guess > > > > > assuming > > > > > > > I > > > > > > > get stuck on every stupid thing would be en
