[FFmpeg-devel] [PATCH 2/6] Frame-based multithreading framework using pthreads

Ronald S. Bultje rsbultje
Mon Feb 7 15:08:56 CET 2011


On Mon, Feb 7, 2011 at 2:57 AM, Alexander Strange <astrange at ithinksw.com> wrote:
> On Feb 7, 2011, at 1:42 AM, Reimar D?ffinger wrote:
>> On Sun, Feb 06, 2011 at 06:49:17PM -0500, Alexander Strange wrote:
>>> On Feb 6, 2011, at 5:43 AM, Reimar D?ffinger wrote:
>>>> On Sat, Feb 05, 2011 at 06:55:52PM -0500, Alexander Strange wrote:
>>>>>> IMO what would be really good if the following would be possible:
>>>>>> - application sets up multithreaded decoding
>>>>>> - application figures out if the FFmpeg version+codec combination actually
>>>>>> supports/will use multithreading
>>>>>> - if it does it will disable slices (since it's too complex to handle and might
>>>>>> also cause speed issues and probably has no cache benefits), if not use
>>>>>> slices.
>>>>> After calling avcodec_open(), check AVCodecContext.active_thread_type.
>>>>> It will be 0 if thread_count <= 1.
>>>> But what if thread_count is e.g. 10, but the codec does not support threads?
>>>> Or it only supports slice multithreading?
>>>> Or the codecs supports frame and slice multithreading but it knows that
>>>> due to some special feature set in extradata it cannot use either?
>>> FF_THREAD_SLICE will always be set if thread_count>1 since there's no way to tell from outside if execute() is going to be used.
>> But FFmpeg can easily tell that for example the cdgraphics decoder will
>> never use threads no matter what, why should FF_THREAD_SLICE be set in that case?
> The easiest way to handle this would be to add CODEC_CAP_THREADS if the codec can call execute().
> Exporting whether or not the codec will use it for a specific file looks complicated and the information would arrive too late - at that point, you could just disable your incompatible things if the callback gets called and finds it's on another thread.

I think CODEC_CAP_SLICE_THREADS would be useful. I do see that as
independent of this patch and so would prefer to not hold back this
patch for that. We should add that after this patch has been
committed, though. Reimar, is that OK for you?


More information about the ffmpeg-devel mailing list