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".
