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

Reimar Döffinger Reimar.Doeffinger
Mon Feb 7 18:35:18 CET 2011

On Mon, Feb 07, 2011 at 02:57:16AM -0500, Alexander Strange wrote:
> On Feb 7, 2011, at 1:42 AM, Reimar D?ffinger wrote:
> >> 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.

The case I wanted to suggest thinking of is when a decoder can tell from
extradata whether it will be able to use threads or not.
I'd like an API where the codec can pass that info on.
But anyway, I just wanted to make you think of this, I do not
want to hold up patches.

More information about the ffmpeg-devel mailing list