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

[Reimar Döffinger]

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.

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.
Also, how would a portable application use this reliably on a system that
may or may not have pthreads available and similar things?
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.

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"