On 2021-09-02 11:27, Andreas Rheinhardt wrote:
Steve Lhomme:
When using slice decoding vp9_free_entries is called before vp9_alloc_entries
is ever called. It should destroy properly initialized variables (or check it
was never called before).

It usually works undetected as pthread implementations allows NULL as a special
value (and should return EINVAL but doesn't). But pthreadGC2 doesn't allow NULL
in pthread_mutex_destroy() and crashes when that's the case.
---
  libavcodec/vp9.c | 4 ++++
  1 file changed, 4 insertions(+)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 874005a5ae..d40e90b70e 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1796,6 +1796,10 @@ static av_cold int vp9_decode_init(AVCodecContext *avctx)
s->last_bpp = 0;
      s->s.h.filter.sharpness = -1;
+    if (avctx->active_thread_type & FF_THREAD_SLICE)  {
+        pthread_mutex_init(&s->progress_mutex, NULL);
+        pthread_cond_init(&s->progress_cond, NULL);
+    }
for (int i = 0; i < 3; i++) {
          s->s.frames[i].tf.f = av_frame_alloc();

1. progress_mutex and progress_cond don't exist if compiled without
threading support, so your patch will lead to compilation failures in
this case.

Ah yes, I missed that the 2 functions are conditionally compiled.

2. I don't see a reason why these mutexes need to be initialized and
destroyed when the dimensions/number of tile cols change at all. They
should be initialized once during init (if slice threading is used) and
freed during close (if they have been successfully initialized).

Yes, it makes total sense.

3. Initializing this condition and mutex is currently not checked.

I can fix this if you want.

Sure. This is currently leading to a crash in VLC 3.0 because we use a pthread implementation that doesn't like this case (the only lib compatible with XP).
https://code.videolan.org/videolan/vlc/-/issues/26017
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to