[FFmpeg-devel] [PATCH] pthread: Allow thread_count==0

[Måns Rullgård]

Alexander Strange <astrange at ithinksw.com> writes:

> 2011/2/19 M?ns Rullg?rd <mans at mansr.com>:
>> Takashi Mochizuki <mochi at da2.so-net.ne.jp> writes:
>>
>>> Some codec like libx264 uses thread_count==0 as Automatic mode.
>>>
>>> But, "Frame-based multithreading framework using pthreads"
>>> ?(commit: 37b00b47cbeecd66bb34c5c7c534d016d6e8da24)
>>> does not allow thread_count==0.
>>>
>>> Here is a tiny patch.
>>>
>>> Takashi Mochizuki
>>>
>>> //
>>>
>>> ---
>>> ?libavcodec/pthread.c | ? ?2 +-
>>> ?1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c
>>> index 0e033d3..6b989ac 100644
>>> --- a/libavcodec/pthread.c
>>> +++ b/libavcodec/pthread.c
>>> @@ -877,7 +877,7 @@ int ff_thread_init(AVCodecContext *avctx, int thread_count)
>>> ? ? ? ? ?return -1;
>>> ? ? ?}
>>>
>>> - ? ?avctx->thread_count = FFMAX(1, thread_count);
>>> + ? ?avctx->thread_count = FFMAX(0, thread_count);
>>
>> I'm pretty sure this has come up before, and that there was some reason
>> for things being as they are. ?I don't remember the details without
>> digging in the archives.
>
> The issue only just appeared.
> https://roundup.ffmpeg.org/issue2609

I was thinking of the old threading model.  Sorry for the confusion.

> This patch actually does work ATM (didn't test it, just thought a
> little), but I think I have other pending code that expects
> thread_count >= 1, because it allocates things with sizeof(obj) *
> thread_count.
>
> The best approach would be a CODEC_CAP_AUTO_THREADS defined for
> external libraries that can decide on # threads themselves; it could
> pass through 0 as a value to them, but otherwise cap it to 1. I would
> apply this first to fix x264 and then come back to it.

Sounds reasonable.

-- 
M?ns Rullg?rd
mans at mansr.com