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

[Reimar Döffinger]

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.

> >>> 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?

> 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.