This is because the codec->decode() call in frame_worker_thread may be modifying that avctx at the same time. This data race is reported by ThreadSanitizer.
Although submit_thread holds two locks simultaneously, it always acquires them in the same order because |prev_thread| is always the array element before |p| (with a wraparound at the end of array), and submit_thread is the only function that acquires those two locks, so this won't result in a deadlock. --- libavcodec/pthread_frame.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index b77dd1e..e7879e3 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -330,7 +330,9 @@ static int submit_packet(PerThreadContext *p, AVPacket *avpkt) pthread_mutex_unlock(&prev_thread->progress_mutex); } + pthread_mutex_lock(&prev_thread->mutex); err = update_context_from_thread(p->avctx, prev_thread->avctx, 0); + pthread_mutex_unlock(&prev_thread->mutex); if (err) { pthread_mutex_unlock(&p->mutex); return err; -- 2.7.0.rc3.207.g0ac5344 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel