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

[Alexander Strange]

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

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.