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

[Alexander Strange]

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:
>>> Also, how would a portable application use this reliably on a system that
>>> may or may not have pthreads available and similar things?
>> 
>> Sorry, what do you mean? If threads aren't available multithreading
>> isn't used and it's reliable. If w32threads are used this still
>> applies.
> 
> I don't think there is any way for an application to know whether
> threads are available or not.

What kind of available? They're compiled in by default if the system has pthreads. Presumably the client is built the same way.
They aren't used by default, because we don't autodetect # threads to use. But I see no reason not to do that, and afterwards you might as well always assume they're in use.

Threads help more than slices/DR1 too so I don't think it's worth optimizing for the chance that they won't be used. The only exception is saving power, in which case you can turn them off.

>>> 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.
I think it's better to write callbacks that can handle it rather than making this more accurate - after all, threading will only get more popular.