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

[Lynne]

May 21, 2023, 17:06 by nuomi2021 at gmail.com:

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

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.