[FFmpeg-devel] How to use threads inside custom encoder

[FFmpeg-devel] How to use threads inside custom encoder

[Alex]

Hi!
I write custom encoder codec and want to use threads to speed up encoding process. I know what ffmpeg have frame level threads and slices threads, but in my case best option is to use frame level threads with FF_CODEC_ENCODE_CB() function.
But I have couple of questions:

1) Then I add AV_CODEC_CAP_FRAME_THREADS flag to capabilities of my encoder then ffmpeg call init function of my encoder for each spawned threads (for example 9 times because I have 8 core cpu ). How to prevent this and call init function only once? (I need to reuse encoder context.)
2) Is it possible to request more decoded frames inside encode callback function?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] How to use threads inside custom encoder

[Ronald S. Bultje]

Hi,

On Thu, Feb 23, 2023 at 1:28 PM Alex <3.14pi@ukr.net> wrote:

> Hi!
> I write custom encoder codec and want to use threads to speed up encoding
> process. I know what ffmpeg have frame level threads and slices threads,
> but in my case best option is to use frame level threads
> with FF_CODEC_ENCODE_CB() function.
> But I have couple of questions:
>
> 1) Then I add AV_CODEC_CAP_FRAME_THREADS flag to capabilities of my
> encoder then ffmpeg call init function of my encoder for each spawned
> threads (for example 9 times because I have 8 core cpu ). How to prevent
> this and call init function only once? (I need to reuse encoder context.)
>

In frame threading, each "frame instance" has its own context. They can be
synchronized and use dependent data. See how other codecs do this, e.g.
h264 decoder (the concept is identical between encoder & decoder). You can,
for example, use avcodec->internal->is_copy for this. See
update_thread_context() for synchronization between threads.

If this design doesn't work for you, you don't have to use the frame-level
API. Just mark them as slice threads and everything can be managed inside
your codec without the frame-threading API "overhead".

2) Is it possible to request more decoded frames inside encode callback
> function?
>

Encoders can simply buffer frames and output only when ready (this is why
send/receive are separate API), see AV_CODEC_CAP_DELAY.

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] How to use threads inside custom encoder

[Andreas Rheinhardt]

Ronald S. Bultje:
> Hi,
> 
> On Thu, Feb 23, 2023 at 1:28 PM Alex <3.14pi@ukr.net> wrote:
> 
>> Hi!
>> I write custom encoder codec and want to use threads to speed up encoding
>> process. I know what ffmpeg have frame level threads and slices threads,
>> but in my case best option is to use frame level threads
>> with FF_CODEC_ENCODE_CB() function.
>> But I have couple of questions:
>>
>> 1) Then I add AV_CODEC_CAP_FRAME_THREADS flag to capabilities of my
>> encoder then ffmpeg call init function of my encoder for each spawned
>> threads (for example 9 times because I have 8 core cpu ). How to prevent
>> this and call init function only once? (I need to reuse encoder context.)
>>
> 
> In frame threading, each "frame instance" has its own context. They can be
> synchronized and use dependent data. See how other codecs do this, e.g.
> h264 decoder (the concept is identical between encoder & decoder). You can,
> for example, use avcodec->internal->is_copy for this. See
> update_thread_context() for synchronization between threads.
> 

This is absolutely wrong: The frame-threaded-encode API is very simple
and is only intended for encoders with only intra packets. There is no
way to indicate progress to threads encoding later packets. It is
different from the decode API.

- Andreas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".