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

[Alexander Strange]

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:
>>>>> 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.
> 
> There is no way to presume that the compiler options for a client
> will be the same as for FFmpeg.
> So no, unless FFmpeg has some way to tell an application does
> not know if FFmpeg does support pthreads.

Oh, I should mention that active_thread_type will be 0 if there's no threads enabled. So that is one way to tell.

> 
>>>>> 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 it's better to write callbacks that can handle it rather than making this more accurate - after all, threading will only get more popular.
> 
> If pthreads aren't available to the application for some reason but are for
> FFmpeg that's not possible.
> Also I don't see the point of burdening applications with it if it's
> not necessary.
> And lastly, if we know threads won't be used, non-thread-safe callback
> functions will give better performance so a "perfect" app would
> implement them twice.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel