| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
Quoting Andreas Rheinhardt (2020-11-27 02:02:41) > Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset > can be initialized at the same time: a mutex in avcodec_open2() > ensures this. This implies that one cannot simply open a codec > with a non-threadsafe init-function from the init function of > a codec whose own init function is not threadsafe either as the child > codec couldn't acquire the lock. > > ff_codec_open2_recursive() exists to get around this limitation: > If the init function of the child codec to be initialized is not > thread-safe, the mutex is unlocked, the child is initialized and > the mutex is locked again. This of course has as a prerequisite that > the parent AVCodecContext actually holds the lock, i.e. that the > parent codec's init function is not thread-safe. If it is, then one > can (and has to) just use avcodec_open2() directly (if the child's > init function is not thread-safe, then avcodec_open2() will have to > acquire the mutex itself (and potentially wait for it), so that it is > perfectly fine for an otherwise thread-safe init function to open > a codec with a potentially non-thread-safe init function via > avcodec_open2()). > > Yet several of the users of ff_codec_open2_recursive() have the > FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because > all the child codecs' init functions were thread-safe themselves > so that ff_codec_open2_recursive() didn't touch the mutex at all. > But of course the real solution to this is to directly use > avcodec_open2(). > > Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> > --- > libavcodec/avrndec.c | 2 +- > libavcodec/imm5.c | 4 ++-- > libavcodec/tdsc.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) ok
diff --git a/libavcodec/avrndec.c b/libavcodec/avrndec.c index c5a60acd4f..d85e3c2000 100644 --- a/libavcodec/avrndec.c +++ b/libavcodec/avrndec.c @@ -65,7 +65,7 @@ static av_cold int init(AVCodecContext *avctx) a->mjpeg_avctx->width = avctx->width; a->mjpeg_avctx->height = avctx->height; - if ((ret = ff_codec_open2_recursive(a->mjpeg_avctx, codec, &thread_opt)) < 0) { + if ((ret = avcodec_open2(a->mjpeg_avctx, codec, &thread_opt)) < 0) { av_log(avctx, AV_LOG_ERROR, "MJPEG codec failed to open\n"); } av_dict_free(&thread_opt); diff --git a/libavcodec/imm5.c b/libavcodec/imm5.c index 917b414e66..5f8faa4dd0 100644 --- a/libavcodec/imm5.c +++ b/libavcodec/imm5.c @@ -63,7 +63,7 @@ static av_cold int imm5_init(AVCodecContext *avctx) ctx->h264_avctx->thread_count = 1; ctx->h264_avctx->flags = avctx->flags; ctx->h264_avctx->flags2 = avctx->flags2; - ret = ff_codec_open2_recursive(ctx->h264_avctx, codec, NULL); + ret = avcodec_open2(ctx->h264_avctx, codec, NULL); if (ret < 0) return ret; @@ -76,7 +76,7 @@ static av_cold int imm5_init(AVCodecContext *avctx) ctx->hevc_avctx->thread_count = 1; ctx->hevc_avctx->flags = avctx->flags; ctx->hevc_avctx->flags2 = avctx->flags2; - ret = ff_codec_open2_recursive(ctx->hevc_avctx, codec, NULL); + ret = avcodec_open2(ctx->hevc_avctx, codec, NULL); if (ret < 0) return ret; diff --git a/libavcodec/tdsc.c b/libavcodec/tdsc.c index dfd80f6dbc..7c888b6ec8 100644 --- a/libavcodec/tdsc.c +++ b/libavcodec/tdsc.c @@ -125,7 +125,7 @@ static av_cold int tdsc_init(AVCodecContext *avctx) ctx->jpeg_avctx->flags2 = avctx->flags2; ctx->jpeg_avctx->dct_algo = avctx->dct_algo; ctx->jpeg_avctx->idct_algo = avctx->idct_algo; - ret = ff_codec_open2_recursive(ctx->jpeg_avctx, codec, NULL); + ret = avcodec_open2(ctx->jpeg_avctx, codec, NULL); if (ret < 0) return ret;
Normally no two codecs with FF_CODEC_CAP_INIT_THREADSAFE unset can be initialized at the same time: a mutex in avcodec_open2() ensures this. This implies that one cannot simply open a codec with a non-threadsafe init-function from the init function of a codec whose own init function is not threadsafe either as the child codec couldn't acquire the lock. ff_codec_open2_recursive() exists to get around this limitation: If the init function of the child codec to be initialized is not thread-safe, the mutex is unlocked, the child is initialized and the mutex is locked again. This of course has as a prerequisite that the parent AVCodecContext actually holds the lock, i.e. that the parent codec's init function is not thread-safe. If it is, then one can (and has to) just use avcodec_open2() directly (if the child's init function is not thread-safe, then avcodec_open2() will have to acquire the mutex itself (and potentially wait for it), so that it is perfectly fine for an otherwise thread-safe init function to open a codec with a potentially non-thread-safe init function via avcodec_open2()). Yet several of the users of ff_codec_open2_recursive() have the FF_CODEC_CAP_INIT_THREADSAFE flag set; this only worked because all the child codecs' init functions were thread-safe themselves so that ff_codec_open2_recursive() didn't touch the mutex at all. But of course the real solution to this is to directly use avcodec_open2(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> --- libavcodec/avrndec.c | 2 +- libavcodec/imm5.c | 4 ++-- libavcodec/tdsc.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)