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

Alexander Strange astrange
Wed Mar 2 17:48:29 CET 2011


On Wed, Mar 2, 2011 at 3:13 AM, Jason Garrett-Glaser <jason at x264.com> wrote:
> 2011/2/20 M?ns Rullg?rd <mans at mansr.com>:
>> 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.
>
> If nobody fixes this, I'm ripping threads support out of libx264.c by
> Friday, i.e. forcing auto threads. ?This is an ultimatum.

I approved the patch...

>
> Also, a user is reporting that on his system, -threads 32 uses 6
> threads in x264.



More information about the ffmpeg-devel mailing list