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

Alexander Strange astrange
Sun Feb 6 00:55:52 CET 2011


On Sat, Feb 5, 2011 at 1:35 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Feb 05, 2011 at 12:28:25AM -0500, Alexander Strange wrote:
>> @@ -1238,6 +1255,10 @@ typedef struct AVCodecContext {
>> ? ? ? * decoder to draw a horizontal band. It improves cache usage. Not
>> ? ? ? * all codecs can do that. You must check the codec capabilities
>> ? ? ? * beforehand.
>> + ? ? * When multithreading is used, it may be called from multiple threads
>> + ? ? * at the same time; threads might draw different parts of the same AVFrame,
>> + ? ? * or multiple AVFrame, and there is no guarantee that slices will be drawn
>> + ? ? * in order.

Spotted a typo here "multiple AVFrame", fixed locally.

>
> I think this is _mostly_ the same as before, so my comments should probably
> not be considered objections.
> Is this tested with the scale filter? I think that libswscale or something
> at some point had some strange hacks that assumed some relation between the
> order of slices and upside-down images.

Yes, the lavfi scale filter works because ffplay/ffmpeg don't use
draw_horiz_band.
mplayer + this patch series +
http://samples.mplayerhq.hu/V-codecs/Theora/controlled-60.ogv will use
it and break.

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

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

>
> The same applies to dr1 really, since e.g. many OpenGL implementations have
> issues with multiple threads, even when reentracy is not required.
>
>
>> @@ -1491,6 +1512,9 @@ typedef struct AVCodecContext {
>> ? ? ? * if CODEC_CAP_DR1 is not set then get_buffer() must call
>> ? ? ? * avcodec_default_get_buffer() instead of providing buffers allocated by
>> ? ? ? * some other means.
>> + ? ? * If frame multithreading is used and thread_safe_callbacks is set,
>> + ? ? * it may be called from a different thread, but not from more than at once.
>
> "than one at once"

Fixed locally.



More information about the ffmpeg-devel mailing list