[FFmpeg-devel] [PATCH] pthread: Allow thread_count==0
Sun Feb 20 12:56:12 CET 2011
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.
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) *
> 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.
mans at mansr.com
More information about the ffmpeg-devel