[FFmpeg-devel] [PATCH 01/14] vvcdec: add thread executor

[Nuo Mi]

On Sun, May 21, 2023 at 10:11 PM Lynne <dev at lynne.ee> wrote:

> May 21, 2023, 15:03 by nuomi2021 at gmail.com:
>
> > 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.

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