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

[chetan mathad]

Hi all;

Can you let me know what all information you need so that i can provide the
max i can to fix this bug.

Thanks
Chetan

2011/3/2 M?ns Rullg?rd <mans at mansr.com>

> Jason Garrett-Glaser <jason at x264.com> writes:
>
> > 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.
>
> Take it easy.
>
> > Also, a user is reporting that on his system, -threads 32 uses 6
> > threads in x264.
>
> Without more information on this, it is impossible to debug.
>
> --
> M?ns Rullg?rd
> mans at mansr.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
Thanks & Regards
Chetan.M