[FFmpeg-devel] [PATCH] pthread: Fix ff_thread_get_format issues when called outside frame decode.

[Hendrik Leppkes]

On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> When ff_thread_get_format is called from the main thread, e.g.
> during codec init it will access the thread_ctx as a PerThreadContext
> even though it is a FrameThreadContext.

Where is this a problem exactly? I don't see a single codec that calls
it during codec init.
The only codecs that actually call it are h264 and hevc, and thats in
slice header decoding, not codec init (and mpeg12, which doesn't do
frame threading)

> In addition, when ff_thread_get_format is called during the context
> update it would get confused because the state is not as expected.
> Make it handle that case by adding a new state for this, signalling
> that we are actually executing in the main thread and thus can
> call get_format directly in all cases.

When would this ever happen? MT decoding works perfectly fine in a
number of applications as it is.

> @@ -743,7 +754,10 @@ void ff_thread_flush(AVCodecContext *avctx)
>  int ff_thread_can_start_frame(AVCodecContext *avctx)
>  {
>      PerThreadContext *p = avctx->internal->thread_ctx;
> -    if ((avctx->active_thread_type&FF_THREAD_FRAME) && p->state != STATE_SETTING_UP &&
> +    if (avctx->active_thread_type&FF_THREAD_FRAME)
> +        return 0;
> +    av_assert0(!p->main_thread);
> +    if (p->state != STATE_SETTING_UP &&
>          (avctx->codec->update_thread_context || !THREAD_SAFE_CALLBACKS(avctx))) {
>          return 0;
>      }

This hunk looks rather suspicious. Returning 0 unconditionally on
active_thread_type & FF_THREAD_FRAME?

In general, I'm rather cautious with any changes to the threading
model, so these should be clearly warranted and explained properly.

- Hendrik