May 21, 2023, 17:06 by [email protected]: > On Sun, May 21, 2023 at 10:11 PM Lynne <[email protected]> wrote: > >> May 21, 2023, 15:03 by [email protected]: >> >> > The executor design pattern was inroduced by java >> > < >> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/Executor.html >> > >> > it also adapted by python >> > <https://docs.python.org/3/library/concurrent.futures.html> >> > Compared to handcrafted thread pool management, it greatly simplifies >> the thread code. >> > --- >> > libavcodec/Makefile | 1 + >> > libavcodec/vvc/Makefile | 4 + >> > libavcodec/vvc/vvc_executor.c | 193 ++++++++++++++++++++++++++++++++++ >> > libavcodec/vvc/vvc_executor.h | 73 +++++++++++++ >> > 4 files changed, 271 insertions(+) >> > create mode 100644 libavcodec/vvc/Makefile >> > create mode 100644 libavcodec/vvc/vvc_executor.c >> > create mode 100644 libavcodec/vvc/vvc_executor.h >> > >> >> I'd like a unified API, since for AV1, we'd want something similar. >> Having a custom one for each codec is a bad idea and prone to bitrotting. >> > Hi Lynne, > Thanks for the comment. > > dav1d has not merged to mainline yet. > It uses the same idea, but all codes are hand-crafted. Did not use any > existing patterns. > I guess the executor will simplify the dav1d's code. > Let us find out when it is sent to FFmpeg for review. > > Current ffmpeg's thread management has limitations: > 1. Slice thread bound to frame, it can't not us by another frame even > current frame has no job. > 2. It is a one-shot mechanism. Can't support multi-stage decoder. So it > can't fully use the multiple cores. > This is why we need a new one. >
I don't mind a new one, I'd like for it to not be specific for VVC from the start so it can be reused and improved. _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
